Here is a question worth asking of any compliance system you work on: what was the transaction monitoring threshold for high-risk corporate customers on 14 March last year, who approved it, and what did the approval say?
At most firms this is genuinely unanswerable. The threshold lives in a config table. An operations user changed it through an admin UI. There is no history, no approval record, and no test. The system works exactly as designed and the design is the problem.
Meanwhile, three floors away, the same firm will not let an engineer change a constant in a service without a pull request, a review, a test suite, and a deployment record.
The fix is to treat controls as code. Not metaphorically — literally, with the same machinery.
What a control object contains
A control is a versioned, addressable artefact. Minimum contents:
control:
id: tm.corp.high_risk.cash_velocity
version: 7
obligation_refs:
- AML.MONITORING.STRUCTURING
- AML.MONITORING.LAYERING
applies_to:
segment: corporate
risk_rating: [high, very_high]
logic:
window: P7D
aggregate: cash_credit_sum
comparator: gt
threshold: 250000
currency: USD
data_dependencies:
- txn.cash_credits
- customer.risk_rating
- customer.segment
approval:
approved_by: mlro
approved_at: 2026-03-14T10:22:00Z
rationale_ref: doc://committee/2026-03/tm-review
effective_from: 2026-03-15T00:00:00Z
Three properties matter more than the exact schema.
It is versioned and immutable. Version 7 never changes. A threshold adjustment produces version 8 with its own approval and effective date. Every alert records the control version that produced it.
It declares its data dependencies. This lets the platform disable a control loudly when an upstream feed goes stale, instead of letting it evaluate against nothing and report green. That failure mode — a control silently evaluating on missing data — is one of the most common real causes of compliance gaps, and dependency declaration is the cheapest defence against it.
It maps to obligations. The chain from regulation to obligation to control to alert to decision is traversable in both directions. When a regulation changes, you can find every affected control in a query rather than in a meeting.
The pipeline
Controls move through the same stages as code, with one addition.
-
Change proposed — a diff against the current version, in version control, with a rationale.
-
Review — engineering reviews the logic, compliance reviews the intent. Both approvals recorded.
-
Replay — this is the addition. The proposed version runs against historical data using reference data as it stood at that time. Output is a concrete delta: alerts generated, overlap with the current version, coverage against known-true-positive cases.
-
Approval — the responsible officer approves with the replay report attached. This is the artefact that answers the examiner's question.
-
Deploy — with an effective-from timestamp. Controls are never retroactive; the old version remains in force for everything before the boundary.
Step 3 is the one that changes team behaviour. A threshold change that looks conservative can produce a forty percent alert volume increase, which the operations team absorbs by closing faster — a quality degradation nobody chose. Replay turns that into a number before deployment.
The replay requirement, technically
Replay needs historical reference data as it stood, which means the underlying data layer has to be bitemporal: each record carries when the fact was true and separately when the system believed it.
Evaluating control version 8 against last year's transactions using this year's customer risk ratings produces a meaningless result, because half those ratings changed in response to alerts the old control generated. You need the ratings as they were.
If you already built point-in-time reconstruction for audit purposes, replay is nearly free — it is the same substrate queried differently. If you have not, replay is the argument for building it, and audit reconstruction comes along as a bonus.
Where AI fits without breaking any of this
Two places, and neither of them is inside the control.
Regulatory change to control mapping. An agent monitors regulator publications, classifies relevance against your licence and product profile, and — because controls declare their obligation references — identifies exactly which control versions are implicated. It opens a change proposal with a drafted impact assessment. A human reviews and approves. The control pipeline is unchanged; the agent just populates step 1 well.
Alert triage after the control fires. Context assembly and queue prioritisation, discussed at length elsewhere. Crucially this sits downstream of the control, so the control's explainability is untouched.
What does not work is a model that adjusts thresholds autonomously. That is a control changing without approval, which is precisely what the versioning exists to prevent.
Cost
Roughly three engineering months to build the control object model, the pipeline, and the replay harness, assuming the bitemporal data layer exists. Double that if it does not, but you needed it anyway.
Against that: the ability to answer the examiner's question in ten minutes rather than six weeks, and the ability to know what a control change will do before it does it.
Full architecture guide: Financial Compliance Software: Architecture for AI-Native Controls . More on our agentic workflow development work.
Frequently Asked Questions
What does "controls as code" mean in compliance?
Treating every detection rule, threshold and policy as a versioned, immutable artefact in version control, with review, approval, testing and deployment records — the same machinery used for application code. Each alert records which control version produced it.
Why do compliance thresholds need version history?
Because examiners ask what a threshold was on a specific past date and who approved it. Thresholds stored in an editable config table cannot answer that. Versioned controls with approval records and effective dates answer it directly.
What is control replay and why does it matter?
Running a proposed control version against historical transactions, using reference data as it stood at that time, to produce a concrete delta in alert volume and detection coverage before deployment. It prevents the common outcome where a conservative-looking threshold change floods the alert queue.
Why must replay use historical reference data?
Because current reference data has already been influenced by the old control's outputs — risk ratings changed in response to alerts it generated. Evaluating a new control against today's ratings produces a circular and meaningless result.
Can AI adjust detection thresholds automatically?
No — that is a control change without approval, which is exactly what versioning exists to prevent. AI belongs upstream, proposing control changes from regulatory updates for human approval, and downstream, triaging alerts after the control has fired.
How do you prevent a control running on stale data?
Have each control declare its data dependencies explicitly, and have the platform disable the control loudly when a dependency goes stale. Silent evaluation against missing data is a common and largely invisible cause of real compliance gaps.