A regulator does not ask whether you comply. They ask you to show them.
Show them where the law says it, what you took it to mean, what you built, and how you know that it works. Then show them what you believed last quarter, before the rules changed.
Most compliance registers cannot do that. They live in a spreadsheet or a compliance tool, a long way from the code they describe, and they go stale the week after the audit. So for SentinelBet, our betting platform, we built the register into the platform itself.
Four kinds of record
Everything in the register is one of four things, and each one points at the next.
- A source is a piece of law or guidance: an Act, a statutory instrument, a regulator’s guidance note. We keep a copy of the original and a fingerprint of it.
- An obligation is one requirement taken from one source, with the exact section it comes from. One section can hold several obligations.
- A decision records how we read an obligation where the wording leaves room. It sets out the context, our interpretation, the alternatives we considered and what follows from them.
- A control is what meets an obligation: the code that does it, the tests that prove it, and where the evidence is kept.
So every claim of compliance can be walked back, from the test that passes, to the control it proves, to the obligation it meets, to the section of law that created it.
Files, next to the code
The register is plain text in the same repository as the platform: one file per record, each opening with a few lines of structured details. Here is an obligation from the Gambling Regulation Act 2024, which requires an operator to let a customer limit what they spend:
id: OBL-SG-002
title: "Provide a facility for a participant to set a monetary limit
on what they may pay to participate"
source: SRC-STAT-2024-GRA
citation: "s.164(1)"
applicability: applies
channels: [remote]
status: implemented
decisions: [CDR-0015]
controls: [CTL-003]
review_by: 2027-01-31
And here is the control that meets it. It names the files that do the work, and the tests and audit records that show it does:
id: CTL-003
type: technical
obligations: [OBL-SG-002, OBL-SG-003]
implementation:
- repo: betting-v2
refs: [app/models/spending_limit.rb,
app/controllers/spending_limits_controller.rb,
app/policies/spending_limit_policy.rb]
evidence:
- {type: test, ref: spec/models/spending_limit_spec.rb}
- {type: test, ref: spec/requests/spending_limits_spec.rb}
- {type: audit-log, ref: "Audited::Audit where auditable_type = 'SpendingLimit'"}
last_verified: 2026-10-19
review_cycle: quarterly
We looked at commercial compliance tools and turned them down for one reason. The register would live outside version control, away from the code that makes up most of our controls, and the walk from statute to evidence would break. We also looked at OSCAL, the full machine-readable standard for this kind of data. It was more than an organisation of our size needs, so we borrowed its shape instead. If we ever need OSCAL itself, the move is a translation, not a rethink. The words we use for things come from ISO 37301, the standard for compliance management systems, so an auditor recognises them.
Keeping it in git gives us three things a spreadsheet cannot:
- History. What we believed on any past date can be recovered, exactly.
- Review. A change to the register goes through the same review as a change to the code. The record of those reviews is the regulatory change log.
- Permanence. Nothing is deleted and no ID is reused. A record that no longer applies is marked superseded or withdrawn, so old references still lead somewhere.
Checked every time it changes
A register that falls behind is worse than none, because it gives false confidence. So the register comes with a check of its own. It runs over every record, from the command line or on any pull request that changes the register, and looks for six things:
- Every record is complete, with the fields its type requires and only the values they allow.
- Every reference resolves. An obligation cannot point at a control that does not exist.
- Every obligation that applies is covered, by a control or by a recorded decision to accept the risk.
- Nothing rests on old law. No obligation may cite a source that has been superseded.
- The originals are untouched. Each stored document must still match its fingerprint.
- Reviews are on time. An obligation past its review date, or a control overdue for its review, is flagged.
The same check builds a traceability matrix, from each source through its obligations and decisions to the controls and their evidence. It is the one document an auditor needs to start from.
Watching for change
Law does not wait for a review date. Every morning at half past six the platform reads the regulator’s website, the Irish Statute Book’s directory of gambling legislation and its index of new statutory instruments, and a notification on the EU’s register of draft technical rules.
- It only fetches what moved. It reads the regulator’s sitemap and fetches a page only when its date has changed, a polite half second apart.
- It keeps a copy. Regulators take pages and documents down, so every change is stored with its date and fingerprint.
- It reports even when nothing happened. The day’s report goes to Slack whether or not anything changed. A watcher that has quietly stopped is noticed the next morning, and the quiet days are on record too.
- It does not panic on a bad day. If the sitemap suddenly lists half the pages it did, the run is skipped rather than reporting half the site as removed.
A person reads the day’s changes and marks what matters. Those documents are bundled with their fingerprints and brought into the register, where each fingerprint is checked again on the way in.
The model drafts, a person decides
Turning a new statutory instrument into obligations is slow, careful work, and an AI model does the first draft well. It splits a document into candidate obligations, one requirement and one section reference each, and drafts the analysis for a decision.
It decides nothing. Whether an obligation applies to us, whether a decision is accepted and whether a risk is accepted all need a named person, recorded in the file. Every candidate starts as “pending” until that person has looked. A document from outside is treated as data, never as instructions: nothing written inside one is acted on. And where an interpretation is genuinely unclear, a penalty is criminal, or a decision carries real exposure, it goes to a lawyer, and the decision says so.
The gaps are the roadmap
An obligation that applies but has no control is open. The set of open obligations is the compliance backlog, and it is specific: each one names the section of law, so the gap between the obligation and the code is the feature’s specification.
Spending limits came about this way. So did the quarterly return to the regulator, which the platform now produces for each operator on the second day of each quarter, for the quarter just ended. Every figure in it carries the basis it was worked out on, and a return is never overwritten: a correction sits beside the original as a new version.
Today the register holds 41 sources, 61 obligations, 22 decisions and 19 controls, across safer gambling, licensing, identity checks, operations and data protection.
Not a tool you can buy
None of this is a product on its own. It is the way our platform is built, and it comes with it. An operator on SentinelBet gets the controls, and the trail behind them that shows a regulator why each one is there.
If you would like to see how a requirement in your own market would be traced through the platform, talk to us.
