Coverage
16 SADC markets
← Back to work
Case study · AI governance for payments
Governing an AI model where one invented number ends the business.
The Corridor Register is a compliance register for the sixteen SADC markets: what the law requires of a payment business in each, which instrument imposes it, what happened when a real company applied to a provider, and what changed since you last looked. Its only asset is that every line is true, dated and cited. I used an AI model for the slow intake work, and built the system so the model can never be the source of a fact.
Publish gate
10 refusal rules
Model write access
None
01 / The problem
A compliance officer needs a citation, not a summary.
Anyone deciding whether to operate a payment business in a southern African market asks the same questions: am I obliged to register, under which instrument, and will anyone onboard me? The answers sit in 135-page draft directives, exemption notices, and rejection emails from providers. What the buyer needs is the instrument, the issuing authority, the date, and a link they can hand to their own lawyer.
Reading that material into structured records is slow, which makes it an obvious job for a language model. It is also where a model is most dangerous. A model that reads "we'd need to see audited financials" and records a capital threshold has invented exactly what a compliance reader acts on. So has one that turns "no rule was found" into "this is unregulated". One fabricated line, found once, and nothing else in the register is believed.
The design rule: the model is an intake clerk, not a source. It may restate what a document says. Anything the document does not say comes back empty and named as a gap. A figure or a reading the model worked out counts as fabricated, even when it happens to be right.
02 / How a fact gets in
The model proposes. Everything else decides.
- HumanA source arrives: a draft directive, a regulator's notice, a rejection email, notes after a call.
- Model · local by defaultProposes one candidate record. Its output is forced into the record's schema, so it cannot add fields, and it is never asked for fields a script or a person owns, such as review dates.
- InboxThe candidate waits beside the full source text and its hash, so the evidence travels with the claim.
- Approval gateEvery quoted phrase is checked against the source. A person reads the candidate. A validator runs, and if it fails the store is restored exactly as it was.
- RegisterThe only step that writes. Corrections supersede earlier records; nothing is deleted.
- Publish gateBefore anything reaches Twitter, email or Substack, ten refusal rules run against every record it cites. All three channels render from one record, so they cannot drift apart.
03 / Mapped to NIST AI 600-1
Twelve named risks. Here is where each one lands.
NIST's Generative AI Profile names twelve risks specific to generative models. This is how the register handles each one that applies, and where it does not.
| Risk | Control in the register |
|---|---|
| Confabulation | Schema-constrained output. Gaps are named, never guessed. No number is inferred from a neighbouring number. Absence is never recorded as "unregulated" without a source that positively says so. Quotes are verified against the source before approval. |
| Human–AI configuration | The model proposes, a person approves, a validator has the final word. Nothing else can write to the register. |
| Information integrity | Every line carries the date it was verified; a requirement past its review date is withheld, not caveated, from findings and from the change alerts subscribers receive. The regulator's words and our reading of them are separate fields. A reading needs the regulator's own text or an official source behind it, and "high confidence" is only allowed when the regulator's own text supports it. A provider's silence is always recorded as inferred. |
| Data privacy | Extraction runs on a local model, so correspondence stays on the machine unless a cloud model is chosen by name. Anything said by someone who did not expect to be quoted is never published, and anything under an NDA is refused at the gate. |
| Information security | Source documents are treated as data, not instructions; a provider's email may want to be described favourably. The schema and the human approval limit what an injected instruction could achieve. This is prompt injection, the top risk on OWASP's LLM list. |
| Value chain | The model is swappable, and a warning prints every time text is about to leave the machine. |
| Intellectual property | Quote fields hold under 25 words, copied exactly or left empty. |
| Harmful bias | Not yet addressed. Which providers get approached shapes what the register can say, and nothing measures that skew today. |
| CBRN, violent, obscene, environmental | Not applicable to a system that only extracts, with no generated text reaching readers. |
Across the AI RMF functions
- Govern: the business rules are written once, then compiled into schemas. Changing a schema is treated as changing the business.
- Map: every finding must pass a written test: could a journalist with a phone have produced this? If so it is news, not intelligence, and it is refused. A second line runs through the whole product: intelligence, not legal advice. Wording that reads as advice, such as "you do not need" or "we recommend", is rejected by the validator.
- Measure: a validator runs on every write, and freshness is checked per record type.
- Manage: the publish gate refuses rather than warns. Overriding it is a deliberate flag, never a default.
04 / What review found
A governance design is only as good as its weakest enforcement.
A review in October 2026 found three gaps. Each is now fixed.
The gate failed closed
A later regulatory layer stored its dates under names the publish gate did not know, so it read them as undated and withheld every finding that cited them. Over-withholding is the right way to fail, but it blocked sound findings too. The gate now reads every store's dates and enforces each record's own review date.
"Quote exactly" was asked, not checked
The prompt told the model to copy quotes character for character. Nothing verified it, so a paraphrase could reach the register as a provider's own words. Approval now refuses any quote that is not in the source.
Policy and code disagreed
The policy said extraction runs locally. The code switched to a cloud model whenever an API key happened to be set. Leaving the machine is now opt-in by name: a key in the environment is not consent to send someone's off-the-record remark to a third party.
05 / Limits and what transfers
What I would not claim.
- The controls are mapped to NIST AI 600-1 and the AI RMF, not certified against them.
- The register is pre-revenue. This case study is about the design, not traction.
- It is not legal advice. It gives a compliance team a sourced list to confirm, not a determination.
- Human approval is the real control, and it is also the bottleneck. The system is built for one careful operator, not for scale.
Scope was a governance decision too
In October I cut everything operational from the register: transfer costs, liquidity, payout rails, corridor sizes. The test was who asks the question. A compliance officer asks what obliges them; an engineer asks whether a payment will land. A product that answers both answers neither convincingly, and every field the model can fill is a field it can get wrong. A smaller scope is a smaller surface to govern.
Why it transfers
The same pattern fits anywhere a payments team wants a model to read what people read by hand today: KYB packs, dispute evidence, partner due diligence, regulatory change. The model does the reading. Schemas, provenance, freshness rules and a gate that refuses decide what counts as true.