AI in payments compliance: a regulator-readable framework.

The test we hold ourselves to is uncomfortable but clarifying: if a regulator walked in tomorrow and asked to understand how AI works inside our payments compliance stack, could they get from question to evidence in thirty minutes, without needing one of us in the room?

If the answer is no, the framework is not regulator-readable. It is a set of practices held together by people who happen to remember them. That is the failure mode every AI-in-finance team eventually meets.

This post is the framework we use to keep ourselves on the right side of that test.

Key facts

01: Regulator-readable means navigable without a tour guide. A reviewer with finance domain experience but no inside knowledge of our team has to be able to find the control, the owner, the evidence, and the most recent test result. If they need to ask, the framework is not ready.
02: Four documents carry the framework. The control register, the use-case register, the metric pack, and the incident log. Everything else is supporting material. Each document has a single named owner and a fixed quarterly review date.
03: The metric pack is exposed, not promised. Six numbers, refreshed weekly, visible to compliance, risk, and audit without a ticket. Promised metrics rot. Exposed metrics get watched, which is the whole point.
04: The thirty-minute walkthrough is a forcing function. Once a quarter, someone outside the AI team runs the regulator walkthrough cold. The walkthrough either lands or surfaces a gap. The gap goes into the control register the same day.

What "regulator-readable" actually means

The word "transparent" gets used too often for this. What a regulator needs is not transparency in the metaphorical sense. They need a finite, ordered set of artefacts they can navigate to find the answer to a specific question.

A regulator-readable framework has four properties. The artefacts exist and are versioned. The artefacts are reachable without asking anyone where they live. The artefacts contain the evidence a regulator would expect, not a description of where the evidence might be found. The artefacts are written in the language of the discipline rather than the language of the engineering team.

If any of the four breaks, the walkthrough breaks with it. We have had each of them break at least once, and each break taught us where the framework was load-bearing and where it was decoration.

The four documents that carry the framework

01. The control register

The control register lists every control that applies to AI workflows inside payments compliance. Each entry has a stable identifier, a plain-English description, the regulation or framework it maps to, the named owner, the system it lives in, the test method, and the last test date. The register is the index for everything else.

Two things make the register useful rather than decorative. The first is that the test method is explicit. "Reviewed quarterly by the AI Steering Committee" is not a test method; it is a meeting. "Random sample of 50 transactions per week passed through the gate; pass rate logged in the metric pack" is a test method. The second is that the last test date is real, not aspirational. If the date is more than a quarter old, the control is presumed broken until tested again.

02. The use-case register

The use-case register is the index of every place AI does work inside payments compliance. It is described in detail in the use-case register pattern post, so I will skip the structure here. The relevant point for the framework is that each entry in the control register references the use cases it applies to, and each use case references the controls that apply to it. The two registers cross-link.

This sounds like bookkeeping, and it is. The cross-link is what lets a reviewer answer the question "what controls apply to alert triage?" without reading every document. They open the use case, follow the references to the controls, follow the controls to the metric pack, and finish in a few minutes.

03. The metric pack

The metric pack is the operational truth of the framework. Six numbers, refreshed weekly, visible without a ticket. Six is a count chosen for ergonomics: it is enough to cover the surface and few enough that everyone who looks at it can remember last week's reading.

The six we use are: first-read precision on alert triage, tail recall on the same surface, average decision latency on KYC review, draft acceptance rate from the Brain's external mode, audit-log integrity check status, and the count of gate violations caught and resolved in the last seven days. The numbers are not the point on their own. The point is that someone outside the AI team can watch them move week to week, and ask the right question when one moves.

04. The incident log

The incident log records anything that went wrong, anything that got close to going wrong, and anything that triggered a review. Each entry has a date, a one-line summary, a category, the system involved, the named responder, the resolution, and the follow-up items. The follow-up items have due dates and owners.

The point of the incident log is not the entries; it is the trend. A regulator reading the log can see whether incidents are decreasing, whether the same category keeps appearing, and whether follow-up items get closed on time. The log is its own report. We do not write a separate one.

The thirty-minute walkthrough

Once a quarter, someone outside the AI team runs the walkthrough cold. They are given the public name of one of our AI use cases (alert triage, KYC review, draft assistance) and asked to find:

The use-case entry for it.
The controls that apply to it.
The most recent test result for each control.
The metric pack reading for the surface.
Any incidents in the last quarter that involved the use case.
The named owner of the use case.

If they can find all six in thirty minutes without asking anyone, the framework passes. If they cannot, we have a gap. The gap goes into the control register on the same day, with a fix owner and a due date.

The walkthrough is the closest thing we have to a regulator visit without one happening. It is uncomfortable to fail, which is exactly the property that makes it useful.

What the regulator gets handed first

If a regulator does walk in, we hand them three things at the start of the meeting: the control register, the metric pack for the most recent six months, and the incident log. They are welcome to ask for anything else, but those three carry most of the questions a first-meeting tends to produce.

We do not hand over a deck. A deck is a story; we want them to be able to verify the story themselves. Slides are appropriate for the closing summary, not the opening evidence.

FAQ

Questions readers ask

What is AI in payments compliance?

AI in payments compliance is the use of machine-learning models to support compliance work in payments: alert triage on transaction monitoring, KYC file review, source-of-funds analysis, document parsing, and drafting of regulator-facing responses. The model assists; named human reviewers retain decision authority on every regulated action.

What does a regulator-readable AI compliance framework include?

Four documents, each with a named owner and a quarterly review date: a control register that maps every AI control to the regulation it satisfies, a use-case register that indexes every AI workflow, a metric pack of six exposed numbers refreshed weekly, and an incident log with follow-up items. The four cross-link so a reviewer can navigate from any question to its evidence in a few clicks.

How is this different from a responsible AI statement?

A responsible AI statement is a description of values. A regulator-readable framework is a set of versioned artefacts a third party can navigate without help. The statement is appropriate as a preamble; the artefacts are what a regulator examines. We publish the framework, not the values, because the framework is what gets tested.

What metrics should AI in payments compliance track?

We track six: first-read precision on alert triage, tail recall on the same surface, average decision latency on KYC review, draft acceptance rate from external Brain mode, audit-log integrity check status, and weekly gate-violation count. The number six is chosen for ergonomics: enough to cover the surface, few enough that everyone watching can remember last week's reading.

How often should the framework be reviewed?

The control register and use-case register are reviewed quarterly by the AI Steering Committee. The metric pack is refreshed weekly. The incident log is updated on the day of any incident. Once a quarter, someone outside the AI team runs a thirty-minute walkthrough cold, which is the framework's stress test.