The three-part core vocabulary — Foundations, Coordinate, Govern and Run — closed each intro with the same honest note. The twenty terms are the common vocabulary. Verticals extend it. Banking is the first vertical extension, because banking is where cmdev has done enough deep work that the extension is not hypothetical.
The five terms below are what an agent team building for a Nigerian Tier 1 bank, a pan-African insurer, or a European fintech under DORA actually needs on top of the twenty. Each of these is a term the core series would treat as one word, or omit entirely, because the general audience does not need it. In banking, each one is the load-bearing primitive that decides whether the agent can be trusted with a payment, an approval, or a customer-facing decision.
Key takeaways
- The deterministic ledger boundary is where the agent's non-determinism must stop. The agent proposes; the double-entry ledger commits. Everything after the boundary is deterministic, replayable, and auditable in the way a bank's accounting system already is.
- Every agent-initiated financial action pairs with a reconciliation step that closes the loop against the accounting system on the same day. Reconciliation-in-the-loop is the pattern that catches AI errors before the general ledger closes.
- The real-time fraud overlay that already scores human transactions must score agent-initiated transactions on the same substrate. Two overlays with different logic is two overlays worth of blind spots.
- The regulatory reporting trail — CBN CSAT for Nigerian banks, DORA for European, and the SAR / STR filings that follow from suspicious activity — is not the same as observability. Reporting is a distinct record with its own retention, its own audit surface, and its own regulator on the other side of it.
- The authorisation envelope is the pre-authorised financial and operational boundary the agent operates inside. Outside the envelope, actions require human authority. Inside it, the agent moves at its own pace.
The Deterministic Ledger Boundary
The agent is non-deterministic. The bank's accounting system is not. Somewhere between them is a line the agent's output must cross to become a real financial event, and that line is the ledger boundary.
- What it is — the point at which an agent's proposed transaction is committed to the double-entry ledger. Before the boundary, the agent can reason, revise, and retry. After the boundary, the transaction is deterministic, replayable, and auditable in the way every debit-and-credit entry in the bank has been for decades.
- Reach for it on every agent that touches money. Payments, refunds, transfers, fee waivers, credit-limit changes. Anything with a debit and a credit needs a hard boundary between the agent's reasoning and the ledger commit.
- Trade-offs — the boundary adds a synchronous checkpoint that agents cannot bypass without engineering effort. That checkpoint is the point of the design. The trade-off is design cost, not runtime cost.
- Cost and effort — the boundary is a two-to-three-week project done right. Skipped, it becomes a five-month recovery project when the first agent-driven ledger error hits the balance sheet.
Reconciliation-in-the-Loop
Every legitimate financial action in a bank has a reconciliation somewhere downstream. Agent-initiated actions cannot skip the reconciliation and pretend they are exempt.
- What it is — every agent-initiated financial event pairs with a reconciliation step that closes the loop against the accounting system on the same day. Same-day is the common commitment; near-real-time is the improvement.
- Reach for it on every agent whose actions land in the ledger. Reach for it especially on agents whose actions cross correspondent-bank rails, where the reconciliation window is the largest.
- Trade-offs — reconciliation-in-the-loop is the discipline that catches agent errors before the general ledger closes. Skipping it means AI errors accumulate into an end-of-day exception queue that operations has to unwind after the fact.
- Cost and effort — the pattern is a reuse of existing bank reconciliation infrastructure, extended to include agent-initiated events as first-class actors. Modest engineering; meaningful ops discipline. Assume the reconciliation team's headcount grows by one full-time equivalent per hundred million naira of monthly agent-processed volume.
The Real-Time Fraud Overlay for Agent Actions
The bank already runs a real-time fraud overlay for human-initiated transactions. Agent-initiated transactions must be scored on the same substrate, with the same latency budget, and against the same models — extended to include agent-specific features.
- What it is — the fraud-detection layer that scores every agent-initiated transaction independently, including features the human overlay does not need (which agent, which model version, which delegation chain, which policy layer approved it).
- Reach for it on every agent that initiates a card transaction, a fund transfer, or a value-bearing action visible to the card-authorisation layer. The FASTCash pattern is what happens when this overlay is not sensitive to agent-specific attack surface.
- Trade-offs — a fraud overlay with agent-specific features has a higher false-positive rate in the first quarter as the model calibrates to the new signal source. Assume a period of manual review overhead in the first ninety days.
- Cost and effort — extending an existing overlay to score agent actions is straightforward feature engineering plus retraining. Building an agent-specific overlay from scratch is not the recommendation; it duplicates infrastructure and creates the two-overlay blind spot.
The Regulatory Reporting Trail
Observability is what the engineering team debugs against. The regulatory reporting trail is what the bank sends to the regulator. The two are not the same, and treating them as the same is where compliance gaps land.
- What it is — the audit-chain record that surfaces to regulatory reporting requirements. In Nigeria that is CBN CSAT for cybersecurity posture, SAR (Suspicious Activity Reports) for money-laundering triggers, and STR (Suspicious Transaction Reports) for transaction anomalies. In Europe under DORA, the ICT-incident reporting timeline within 4 hours of major-incident classification.
- Reach for it the moment an agent has any action visible to any of the reporting regimes. Do not treat this as an observability derivation; design it as a separate record with its own retention, its own signing, and its own read path.
- Trade-offs — the reporting trail duplicates some data that observability already carries. That duplication is the point. Regulatory records need integrity guarantees (signed, immutable, retained for the statutory period) that observability platforms are not designed to enforce.
- Cost and effort — six-to-eight weeks of engineering for the initial reporting-trail infrastructure. Ongoing cost is the retention storage and the compliance-team review cadence. Under-invest here, and the audit finds it.
The Authorisation Envelope
Every human employee at a bank operates inside an authorisation envelope. Tellers can process transactions up to a limit. Loan officers can approve loans up to a threshold. Branch managers can escalate. Agents need the same construct.
- What it is — the pre-authorised financial and operational boundary the agent is allowed to operate inside without human intervention. Amount caps per action. Aggregate caps per day. Categories of action pre-approved by role. Categories requiring escalation.
- Reach for it as a first-class construct on every agent that takes financial action. The envelope is the human-readable expression of the policy layer as it applies to money, and it is what the compliance officer will ask about first.
- Trade-offs — the envelope is the alternative to human-in-the-loop for every action. HITL scales badly at high volume; the envelope defines the volume that does not need HITL. Set the envelope too broad and the agent takes actions that should have been reviewed. Too narrow and every action pauses for review and the productivity case collapses.
- Cost and effort — the design of the envelope is a business decision as much as an engineering one. Expect a three-to-six-week joint project between the AI team, the risk team, and the operations team to land the first version. Revisit quarterly.
If your bank's first agent goes into production in the third quarter and the compliance officer walks in with the questions from the Friday review scene in Part 2, the five terms above are the ones whose absence would make the answer hardest to write.
FAQs
Is the deterministic ledger boundary just a database transaction?
A database transaction is the mechanism; the ledger boundary is the discipline that says the agent's non-deterministic reasoning must stop before the transaction begins. The boundary carries additional semantics — the agent's proposed entry is treated as a candidate until it has passed policy, fraud, envelope, and reconciliation checks, and only then does it become a committed ledger entry. The database transaction is one part of the guarantee; the boundary is where the design commits to the guarantee.
How does the authorisation envelope interact with CBN CSAT?
CBN CSAT does not name the envelope construct explicitly, but the framework's requirements around segregation of duties, privileged access management, and change control map onto it directly. The envelope is the technical expression of the CBN CSAT expectations for who can authorise which class of action, extended to include AI agents as a class of actor. Under audit, describe it as the policy-enforced expression of your segregation-of-duties model.
Why is the fraud overlay not just an extension of the guardrails?
Guardrails are hard limits — a rate cap, an egress allow-list, a budget cap. The fraud overlay is a probabilistic assessment against a model — this transaction, given all the features, has a fraud score of 0.83, and the score exceeds the threshold for auto-decline. Guardrails and fraud overlays run in the same request path and are complementary. The overlay catches the sophisticated attack that the guardrails permit because it looks superficially legitimate.
Do we need all five terms for a simple back-office automation agent?
If the agent has no path to a ledger action, no path to a customer-facing decision, and no reporting-regime exposure, you may only need one or two of the five. Most agents that reach production in a bank end up touching at least three of them within six months — either because the scope expands or because the compliance officer's review surfaces exposure the original scope missed. Design the envelope, the ledger boundary, and the reporting trail from day one, and add the others as the scope demands.
Companion content
- Building the Agent — Part 1: Foundations — the seven foundation terms
- Coordinating the Agent — Part 2 — the six coordination terms and the delegation chain
- Governing the Agent — Part 3 — the seven govern-and-run terms
- The Card-Authorization Layer: Defending Pan-African Banks Against the Next FASTCash — the banking-adjacent controls
- KYC for AI Agents — the identity discipline for agents in regulated finance
How to engage
If your bank is designing its first AI agent for production and you want a vendor-neutral read on which of the five terms above have to be in the first release and which can wait for V2, talk to us at creativeminds.dev/contact.