Structure and process only. The values that belong in your matrix come from current licence conditions and product-level legal advice per market, not from a template.
What the matrix is for
The matrix answers three questions that arrive at the worst moments: what does this market require, what are we actually serving there, and when did that last change? An operation without it can usually answer the first from a memo, rarely the second without an engineer, and almost never the third.
The row: what a parameter needs to carry
| Field | Why it is on the row |
|---|---|
| Parameter | The thing the system reads — named the same way in the matrix and in the code path that consumes it |
| Value | Per market, with an explicit "unset" state that blocks launch rather than defaulting |
| Source | The licence condition, regulator instruction or advice memo the value comes from |
| Effective date | When this value started applying — the field that makes historical questions answerable |
| Owner | A named person for the market, plus the engineering owner of the mechanism |
| Last confirmed | Distinct from "last edited": a value unchanged for a year may be current or may be unreviewed |
"Last confirmed" is the field most matrices lack and the one auditors reach for first. An unedited row proves nothing about whether anyone has checked it against the current rules.
The columns: grouping markets without lying about them
It is tempting to group markets into tiers and configure by tier. This works for planning and fails for enforcement: two markets that look similar diverge on exactly the parameter you did not check. Use groupings as a drafting aid, then confirm each market's cells individually before launch.
A practical compromise: keep the matrix per market, and maintain a separate view showing where markets agree. The agreement view tells you where a change is likely to be cheap; it never becomes the configuration itself.
Which rows to start with
Derive the rows from the compliance-surface inventory in multi-jurisdiction product design. The rows that earn their place first are the ones that block a launch or trigger an intervention:
- Verification gates — what must be proven before play, before deposit, before withdrawal.
- Player limits and their mandatory/optional status, including who may change them and after what delay.
- Responsible-gambling tool set and placement, including exclusion-register integration where one exists.
- Promotional constraints — eligibility, terms and disclosure requirements.
- Permitted products and bet types.
- Reporting fields, cadence and destination — see regulatory reporting.
Keeping it from rotting
Every matrix decays in one of three ways, and each has a structural fix rather than a discipline fix:
| Decay | Structural fix |
|---|---|
| Document drifts from system | Generate the document from the system; never hand-maintain both |
| Change lands with no record | Configuration changes go through review and produce an audit entry, exactly like code |
| Nobody notices a rule update | Named owner per market with a standing review cadence, not only change-triggered review |
The test that tells you it works
Pick a market and a date six months ago and ask what the deposit-limit configuration was, why, and who approved it. If that takes an afternoon and a database query, the matrix is decorative. If it takes a minute and produces a source reference, it is doing its job — and the same query is what makes a certification or audit round uneventful.
Continue reading: Regulatory reporting — the rows with the shortest deadlines. Certification and go-live — where the matrix gets tested by someone else.