Ask what online casino software consists of and most answers describe the games: the RNG, the game engine, the lobby, the wallet.
That part is largely solved and largely bought in. Studios build the games, platform providers supply the aggregation layer, and an operator integrates rather than writes.
The interesting engineering is somewhere else. In a strictly regulated market, the architecture is shaped less by product decisions than by statutory ones, and several of those constraints would be rejected outright in any normal system design review.
Belgium is a good place to look at this, because its rules are unusually specific about implementation rather than outcomes.
Data residency, written into the statute
Most compliance regimes talk about where data may be processed. Belgium talks about where the server physically sits.
Article 43/8, paragraph 2, 3 of the Games of Chance Act requires that the server on which the data and the website are managed be located in a permanent establishment on Belgian territory.
The stated purpose is enforceability: the regulator wants to be able to intervene, for control or for sanction, against hardware inside its own jurisdiction. An application for an online licence has to specify where the site will be administered, and the site must be hosted in a data centre in Belgium.
For anyone who has designed a multi-region deployment, the consequences are immediate. There is no active-active across European regions for the regulated workload. Failover has to stay inside the country.
The convenient pattern of running the primary in one cloud region and the disaster recovery site in another is not available unless both are Belgian.
And the decision is not the operator’s to revisit when a provider changes its regional pricing, because the licence application named the location.
This also constrains the managed services you can use. Anything that silently processes or stores the regulated data outside the country becomes a licensing problem rather than a procurement one.
A hard dependency on a government API
Before a player places a bet, the operator has to check the national exclusion register, EPIS. Registration on it blocks a player across every licensed operator in Belgium rather than at one brand, which only works because the check happens centrally and in real time.
From an architecture standpoint, this is a synchronous dependency on a state-run service, sitting directly in the critical path of the core revenue action.
The design questions it raises are the ones you would ask about any third-party dependency, except that here the usual answers are unavailable. You cannot cache the result for convenience, because the whole point is that an exclusion takes effect immediately.
You cannot fail open, because allowing an excluded player to gamble is exactly the outcome the rule exists to prevent. Fail closed means the gaming floor stops when the register is unreachable.
In practice that pushes you toward careful timeout budgeting, tight circuit-breaker behaviour that degrades to a hard stop rather than a bypass, and monitoring that treats the external register as a first-class component of your own availability. Your uptime is capped by someone else’s.
A stateful rule that spans sessions, devices and payment rails
Belgium caps deposits at 200 euros per week per gambling account. The royal decree of 19 June 2022 brought it into force on 20 October 2022, and the window is a rolling seven days measured from the player’s first deposit rather than a calendar week.
Read that as a specification and it is more demanding than it looks. A rolling window per account means the system needs an accurate, continuously evaluated ledger of deposits across every payment method, every device and every session, with the boundary moving constantly. It is not a counter you reset on Mondays.
Payment method diversity makes it harder. Deposits arrive through domestic rails such as Bancontact and Payconiq, through prepaid instruments, and through different settlement timings.
The rule applies to the deposit, so the system has to decide what counts and when, consistently, including for transactions that settle asynchronously or fail after provisional acceptance.
There is also an escalation path to model. A player who wants a higher ceiling applies to the Gaming Commission, which consults the National Bank of Belgium’s Central Individual Credit Register to check whether the applicant is recorded as a defaulting debtor, and answers within three working days. If cleared, the limit rises to an amount of the player’s choosing.
So the ceiling is a per-account value that can change through an external administrative process, which the platform has to ingest and apply without manual intervention.
Identity as a first-class service, not a signup step
Three separate rules in that list only function against a resolved identity rather than an account: the age threshold, which rose to 21 on 1 September 2024, the exclusion check, and the deposit ceiling.
That pushes identity out of the registration flow and into a service that the rest of the platform depends on. Belgium has usable national digital identity infrastructure, including itsme, which makes strong verification practical rather than aspirational.
An operator such as https://madisoncasino.be/, licensed under B plus 3320, runs all three checks against that verified identity rather than against a self-declared profile.
The enforcement reach is worth noting because it shows the direction of travel. Since 1 May 2026, gaming machines in Belgian newspaper shops have had to run certified systems that verify age 21 and authenticate against EPIS. The same identity requirements now apply to a physical terminal in a shop.
Certified RNG and the re-certification treadmill
The random number generator gets the attention, but the operational burden is certification rather than cryptography.
A game has to be independently tested to confirm it behaves according to its stated rules and stated return, and that the generator is not predictable from its output.
The engineering consequence is that a game build is not a normal deployable artefact. Changing it, even for a bug fix that touches outcome logic, can trigger re-testing before it ships.
That has knock-on effects on everything CI/CD normally gives you. Continuous deployment does not apply uniformly across the stack.
You end up with two release cadences: one for the parts you can ship freely, such as the front end, the wallet UI and the CRM, and a much slower one for anything inside the certified boundary. Drawing that boundary precisely, early, is one of the higher-value architecture decisions on the project.
What it adds up to?
Put the constraints side by side and a shape emerges that is unusual for a consumer web platform. A pinned physical hosting location. A synchronous, non-bypassable dependency on a government service in the hot path.
A stateful financial rule with an externally mutable per-user parameter. Identity as infrastructure rather than as onboarding. And a release process split by a certification boundary.
None of that is visible to the player, and none of it appears in a feature comparison of online casino software. It is most of the engineering.
