SWIFT Controls Framework Application to AI-Initiated Correspondent Transactions

SWIFT's Customer Security Controls Framework was built for a world where a person sits at a terminal, checks a payment, and hits send. That world still exists, but a growing slice of correspondent banking instructions now start with an AI agent picking a route, screening a beneficiary, or timing an FX trade, and the CSCF v2026 doesn't pause to ask who's driving before its mandatory controls kick in. Banks that map those controls onto AI decision points now, ahead of the 2026 attestation window, are better positioned to enter audit season with evidence already in hand. The ones that treat AI initiation as somehow outside the framework's reach are going to find that gap during the assessment, not before it.

How correspondent banking transactions flow, and where AI is beginning to enter that chain

A correspondent banking transaction stripped to its bones has three moves: a respondent bank sends an instruction, a correspondent bank executes it, and the two sides settle through nostro and vostro accounts. Each handoff has a documented point where somebody signs off. That's the whole reason CSCF controls exist: to secure the moment authorization happens.

For decades that moment belonged to a person. A human operator reviewed the payment, approved it, sent it. If a regulator asked who authorized a transaction, the answer was a name, a login, a timestamp. Clean.

AI is now working its way into several of those decision points at once. Routing logic is one: an agent picks among correspondent paths based on cost, speed, and available liquidity, no human comparing quotes. Beneficiary verification and sanctions screening is another, where an AI system renders a pass, refer, or block decision before the instruction ever leaves the building. FX execution timing is a third, agents choosing rate and moment in near real time. And exception handling, once a queue a compliance analyst worked through by hand, is increasingly something an AI system triages on its own, escalating based on a risk threshold instead of waiting for a person to notice.

The ISO 20022 migration is pushing this along faster than most banks expected. SWIFT had set a November 2026 deadline to migrate MT101 payments onto ISO 20022 MX messages. In August 2026, SWIFT deferred the payments-related SR2026 changes, so MT101 coexistence continues past November and unstructured addresses still work. But the direction hasn't changed: structured data fields are what an AI agent needs to act without a human translating the message first, and that substrate keeps expanding regardless of the deferred deadline.

SWIFT itself is part of this shift. Its AI-powered fraud detection service, live since January 2025, reads pseudonymized data across billions of transactions a year, in real time. SWIFT is an AI actor on its own network. That matters for how the rest of the network gets judged, because the traceability expectations built into the network's own fraud detection will inevitably shape what member institutions are asked to demonstrate.

The friction point is structural: KYC and multi-factor authentication were built to check that a human explicitly approved something. When the thing initiating a payment is an AI agent, verifying who the agent is and what the underlying human actually intended gets a lot harder. It's the seam where the old control model stops fitting.

The IMF's three-layer model as a map for where CSCF controls must sit

Sonja Davidovic and Hervé Tourpe, writing for the IMF in April 2026 ("How Agentic AI Will Reshape Payments"), lay out an architecture that names the actual tension precisely. Payment systems run on deterministic logic: if X, then Y, every time. Agentic AI runs on probability: it weighs options and picks the likeliest good outcome. The danger in putting those two next to each other isn't that AI reasons in probabilities. The danger is letting a probabilistic system make an irreversible payment without a deterministic gate standing between the decision and the money moving.

The IMF splits this into three layers. Layer 1 is Intent and Orchestration, where an AI agent interprets what it's being asked to do and selects among available options. This layer is adaptive and probabilistic by design; it's supposed to be smart, not fixed. Layer 2 is Authorisation and Control, a deterministic gateway. Only instructions that clear this gate move forward, full stop. Layer 3 is Settlement, and it's final. Rule-based, non-probabilistic, no room for an AI system to reinterpret anything once a payment lands here. Legal certainty depends on that.

Lining this up against a correspondent banking chain produces an almost too-clean mapping. AI agents operate at Layer 1, doing the routing and beneficiary work. SWIFT Payment Controls and CSCF's mandatory controls are the Layer 2 gate, the deterministic checkpoint. Nostro and vostro settlement is Layer 3, immovable.

So what happens if a bank's CSCF scoping only accounts for Layer 2 actions that a human triggered? There's a gap sitting right at the border between Layer 1 and Layer 2, uncontrolled, exactly where the AI agent decides and the framework's evidence is supposed to begin. The recommended answer to this is a kill-switch architecture: governance built into the stack at multiple points, control spread out rather than centralized in one office, responses that scale up gradually instead of an all-or-nothing shutdown, and containment that keeps a problem local instead of letting it spread network-wide. These are design requirements from day one. They're design requirements from day one.

CSCF mandatory controls directly implicated when AI initiates a correspondent instruction

Start with scoping, because it's where most of the trouble begins. CSCF requires a bank to name every component of its SWIFT footprint that falls inside the framework. An AI agent that generates or transmits a SWIFT message is a SWIFT-connected component, plain and simple. Calling it middleware, or a pre-transmission process that sits conveniently outside the perimeter, is a scoping error. Not a gray area. An error.

Operator credentials come next. CSCF governs who's allowed to authorize a transaction on a SWIFT-connected system. If an AI agent holds operator-level access, that access needs the same lifecycle management, the same privilege limits, the same logging a human operator's credentials get. And agent identity has to be just as traceable as human identity: which system acted, under whose authority, on what instruction. No ambiguity allowed in that chain.

Anomaly detection gets trickier. CSCF requires flagging transactions that deviate from an expected baseline, but an AI agent's normal operating pattern (timing, volume, sequencing) can look nothing like the historical human baseline the detection system was tuned against. Recalibrate that baseline, or one of two bad things happens: AI-initiated transactions get flagged constantly as false positives, or worse, genuinely anomalous behavior slips through because it happens to look like typical AI activity. Neither is acceptable, and there's a coherence question sitting on top of this too. SWIFT's own AI fraud detection, running network-wide on pseudonymized data since January 2025, needs to work in the same direction as an institution's internal anomaly controls, not against them.

Evidence and audit trails are where the standard gets demanding fast. CSCF wants evidence produced as the work happens, not reconstructed afterward from whatever's lying around. For an AI-initiated transaction, that means a contemporaneous, structured log: what instruction the system generated, what rule or threshold triggered it, what data fed the decision, what came out the other end. A log that only captures the SWIFT message transmission, and skips the AI reasoning behind it, isn't incomplete in some minor way. It fails the attestation standard.

Independent challenge is the sharpest test of all. CSCF requires that a separate party, internal audit or a qualified external assessor, can actually examine the evidence and push back on it. An AI decision an assessor can't interrogate (what data went in, what rule fired, what threshold got crossed) fails this requirement even if the underlying transaction was completely fine. Explainability and transparency have emerged as leading regulatory concerns in the fintech compliance landscape, and that pressure lands directly on CSCF's independent challenge requirement. There's no getting around it with a good outcome. The process has to be defensible on its own terms.

What attestation requires when some transactions were AI-initiated during the attestation period

The attestation window runs July 1 through December 31 each year, and the evidence has to come from inside that window. No going back afterward to piece together logs that should have existed the first time.

Attestation has always asked one question: did the people authorized to act follow the controls? An AI agent taking on the role of one of those authorized actors changes the question. It becomes: did the AI system stay inside its defined parameters, and are those parameters themselves a control that auditors should examine? That's a different animal.

Three gaps appear in the attestation exercise when AI-initiated transactions aren't explicitly scoped into it. First, the authorization chain: the human who configured the AI agent isn't the same person who authorized any individual transaction, and CSCF evidence needs to trace both threads, not collapse them into one. Second, exception handling: when an AI agent refers a case to a human, the referral rationale is evidence just as much as the human's eventual decision is. Logging only the decision leaves a hole in the chain. Third, parameter changes: if a routing rule, a threshold, or a scoring model gets updated mid-period, that update is a control event. It needs a record. A model update with no change-control paper trail is an unattested modification sitting on a SWIFT-connected system, and that's exactly the kind of thing an assessor is trained to find.

A national government's Treasury's FS AI RMF isn't legally binding, but its control objectives around model validation, explainability, data integrity, and human oversight line up closely with what CSCF's independent assessment already expects. Don't be surprised if examiners start asking about it anyway, mandatory status or not.

Running this through the classic three lines of defense makes the division of labor clearer. The business line owns the AI agent's configuration and its operating parameters as a control in its own right, alongside the transactions the agent happens to produce. Risk and compliance, the second line, watch whether AI-initiated transactions stay inside policy limits and whether any parameter change went through proper authorization. Internal audit, the third line, checks independently that the evidence the AI system produces is actually enough to back the attestation claim, and that an assessor can genuinely challenge it rather than just nod along.

Singapore's IMDA released a Model AI Governance Framework for Agentic AI in January 2026 that speaks directly to delegation chains and multi-agent coordination, a genuinely thorny problem once one AI agent hands a task to another before a SWIFT instruction ever gets generated. Each handoff in that chain needs its own evidence record. Skipping one link leaves the whole chain unaudited from that point forward.

Extending CSCF scoping and control design to cover AI-initiated actions without rebuilding the compliance program

None of this calls for tearing up an existing compliance program and starting fresh. Most banks have already done the hard part: a CSCF scoping exercise that identifies every system touching the SWIFT messaging environment. The extension is one question, asked system by system: does any AI component here generate, modify, or authorize instructions that reach it?

From there, four moves do most of the work. Add every AI agent to the access and operator control inventory as a named principal, with defined privileges, the same way a human operator gets named and scoped. Write down the AI's operating parameters (routing rules, thresholds, scoring logic) as a formal control, with change-control procedures for any update and version history retained through the whole attestation period. Instrument the AI layer so it produces evidence as it works: every decision logged (instruction generated, rule applied, data used, outcome reached) in a format an auditor can read without needing the AI system itself to explain it. And build the independent challenge path before the attestation window opens, not during it: know who's assessing the AI-initiated evidence, confirm they actually have the explainability they need, and close any gaps while there's still time to close them.

One thing works in banks' favor here. Deploying AI on top of existing rails, rather than ripping out core infrastructure, keeps the CSCF scope that's already been mapped. An agent that operates above the core and transmits through systems already inside the SWIFT-connected perimeter inherits that scoping work. It doesn't trigger a scoping exercise from zero.

FORUM Credit Union's AgentFlow deployment integrated directly with their existing Temenos core, building a straight-through process without replacing the banking stack underneath it. Backbase's Sentinel layer shows the same design instinct from a different angle: an authority layer that enforces Decision Authority before any action executes, requiring a Decision Token that captures the governance record at the execution point itself. That's governance built into the execution point itself, not stapled on as a review step afterward. Named clients on that platform include Navy Federal Credit Union, TD Bank, Techcombank, Standard Bank Group, Eurobank, and KeyBank.

Regulators and industry observers have noted that human-in-the-loop approval delays can actually introduce liquidity risk in real-time payment settings. So a manual checkpoint isn't automatically the safer choice. It might just be the slower one, without buying any real improvement in oversight quality. The stronger argument is building the control into the AI's execution design directly, where a full audit trail gets generated for every action the agent takes as it happens, rather than assembled by hand after the fact when a regulator comes asking.

Expectations for compliance teams and auditors as SWIFT-connected AI deployment expands through the 2026 attestation window and beyond

The nearest forcing function is the November 2026 ISO 20022 deadline. Institutions automating their MT101-to-MX migration are going to push more AI into the actual construction of correspondent instructions, and any AI system building or validating MX message fields sits squarely inside CSCF scope by the time that attestation window closes.

SWIFT's retail payments framework raises the bar further. More than 25 banks had committed to live use across 11 corridors by June 2026, with roughly 50 expected to be on board by year-end. Meeting that kind of speed and transparency standard means more automation, not less. More AI-initiated volume will flow through systems that CSCF is supposed to govern.

The soft law isn't staying soft for long, either. The Treasury's FS AI RMF from February 2026 and Singapore's IMDA framework from January 2026 (updated again in May) aren't legally binding today. But both were built with an eye toward becoming examination reference points, the kind of document an auditor pulls out mid-review even when nothing forces them to. Institutions that have already done the work, mapping CSCF controls onto AI-initiated workflows before anyone required it, will have the paperwork these frameworks expect sitting ready. The ones that waited will be building it under deadline pressure, with an examiner watching.