This page is about product architecture, not law. Licensing, product classification and permitted parameters require product-level legal advice for each target market; primary sources such as the UK Gambling Commission register, the MGA licensee hub and the Curaçao CGA portal are where the current conditions live.
The fork that feels cheap
Entering a second regulated market almost always presents the same choice, usually under time pressure and usually framed as a delivery question rather than an architectural one:
| Approach | Cost in market #2 | Cost in market #5 |
|---|---|---|
| Fork the product | Lowest — copy, adjust, ship | Every regulatory change is implemented and tested five times; behaviour drifts between forks and nobody can say which is authoritative |
| Configure one product | Higher — the parameters have to be extracted from code first | A rule change is a configuration change with an audit record; the mechanism is tested once |
| Separate product | Highest, and correct when the product structure genuinely differs rather than being differently constrained | Justified only where the two things are not the same product |
The fork is not irrational — it is a real trade of future cost for present speed. It becomes a problem when it is made implicitly, by an engineer under a deadline, and nobody records that the debt exists.
Where the boundary goes
A workable rule: if a regulator can change it without changing what the product fundamentally is, it is configuration. Applied to the usual surfaces:
- Player-facing limits — deposit, loss, stake, session and cool-off values, plus whether each is mandatory, optional or prohibited.
- Verification triggers — what forces identity or source-of-funds checks, at what point in the journey.
- Responsible-gambling surface — which tools appear, where, how prominently, and what wording is required.
- Mandatory messaging — reality checks, disclaimers, help-line references, age statements.
- Payment methods and flows — which instruments are permitted, withdrawal timing rules, reversal policy.
- Product availability — which verticals, game types or bet types are permitted at all.
- Reporting — fields, granularity, cadence and destination for each regime.
Code owns the mechanisms these parameters drive: the limit engine, the verification state machine, the messaging framework, the reporting pipeline. Building the mechanism once and feeding it per-market values is the entire architectural idea, and it is unglamorous enough that it usually loses to the deadline unless someone defends it.
The compliance-surface inventory
Before writing the matrix, list every point where the product touches a rule. The inventory is the thing that makes the matrix finite:
| Surface | Question to answer per market |
|---|---|
| Registration | What must be collected, verified and stored before play, deposit and withdrawal respectively |
| Funding | Permitted instruments, limits, source-of-funds triggers, segregation requirements |
| Play | Permitted products, stake and speed constraints, mandatory interruptions |
| Promotion | What may be offered, to whom, with which terms and disclosures |
| Protection | Mandatory tools, exclusion registers, intervention obligations |
| Payout | Verification gates, timing expectations, withholding rules |
| Reporting | What the regulator receives, in what format, how often |
Seven surfaces is enough for a first pass in most operations. The value is not in the taxonomy but in forcing the answer "we do not know yet" into the open while it is still a planning problem.
Ownership, versioning and change
A parameter without an owner is a parameter that will be wrong eventually. Three rules keep the matrix honest:
- One named owner per market, responsible for noticing changes — not just implementing them once instructed.
- Every value versioned with an effective date. "What were we serving in this market on that date?" must be answerable in minutes, because that is the form the question takes when it arrives.
- Change goes through the same review as code. Configuration that can be edited in production without a record is not safer than code — it is less safe, because nothing captures who changed what.
Failure modes
- Rule as constant. A threshold hard-coded in three services, two of which nobody remembers at change time.
- Silent inheritance. A new market launched on another market's defaults because the matrix had no "unset" state and something had to be there.
- Configuration without audit. Values editable in production with no history, which turns any regulator question into an archaeology project.
- Matrix drift. The spreadsheet is updated; the system is not. The spreadsheet must be generated from the system, not maintained alongside it — see the configuration matrix.
Continue reading: The jurisdiction configuration matrix — the artefact this architecture produces. Enterprise operator solution — how Turbo Stars runs multi-brand, multi-market configuration.