Adaptive Financial Infrastructure

What Is Banking Orchestration?

Banking orchestration is how a financial institution runs its systems, its people, and its processes as one operation, down to the ledger, the payment rails, and the evidence regulators examine. This guide defines it, separates it from the adjacent kinds of orchestration, and shows how it works.

Germán Zurro, VP Marketing, XYB

Published 29 October 2026 · 15 min read

What is banking orchestration?

Banking orchestration is how a financial institution runs its systems, its people, and its processes as one operation, down to the ledger, the payment rails, and the evidence regulators examine.

A bank runs on dozens of systems never designed to work together: a core that posts overnight, rails that settle in seconds, KYC, fraud and sanctions engines, channels, and now AI agents, each with its own data, clock, and log. Its people carry context from screen to screen, and the processes regulators care about run through several systems in sequence, with gaps in between.

Banking orchestration is not middleware. Middleware orchestrates messages between systems. Banking orchestration moves business processes, systems, and compliance as one package: across three synchronized vectors: Technology. People. Processes.

In practice, three things happen on one event-native substrate, with security and compliance built in:

Systems are connected once, on one event stream: legacy cores, payment rails, ledgers, data platforms, channels, and AI systems.
People, human operators and AI agents alike, work from the same live context, and every action that moves money passes a decision the bank controls: a person’s approval, a rule, or an AI agent acting within limits the bank sets.
Processes carry their governance with them: policy, approval, and audit are properties of the infrastructure, not features each product rebuilds.

Banking orchestration is the defining mechanism of Adaptive Financial Infrastructure (AFI), and the AFI Platform is what delivers it.

Payments hubs, workflow engines, API gateways, journey layers, and AI agent control planes each orchestrate one thing.

Banking orchestration orchestrates the bank.

Here is how they compare:

Discipline	What it orchestrates	Where it sits	Who works from it	What it keeps track of	Knows the ledger, the rails, the rules?
Payment orchestration (merchant side)	Routing of a payment across payment service providers and acquirers to maximize acceptance and minimize fees	Between a checkout and the payment providers	The merchant’s payments team	Per transaction	No. It optimizes collection, not banking operations
Payment hub (bank side)	A payment’s lifecycle across rails, from initiation to settlement	Inside the bank’s payments function	Payments operations	Per payment	Rails yes; the wider bank, no
Middleware and enterprise service bus	Messages between applications	Between systems	Integration engineers; no business user	Nothing; it passes data on	No. It moves data; it does not own a process
API orchestration	Chains of API calls, protocol translation, payload mapping	At the integration edge	Developers	Nothing	No
Process orchestration (business orchestration and automation platforms)	Workflow steps and task hand-offs across any industry	Above applications	Process owners, through generic task lists	Each workflow’s progress	Generic. It has no native notion of debits, credits, rails, or cut-offs
Journey orchestration (also called digital banking orchestration)	Customer journeys, data, and decisions across channels, and the back-end calls those journeys trigger	Above the core, on the customer-facing side	Customers and customer-facing staff	Each journey and session; the ledger stays in the systems of record	Calls them through connectors; the posting, settlement, approval, and audit record happen elsewhere
AI agent orchestration	Which AI agent, model, or tool runs next	In the AI stack	AI agents, without a shared view of the bank	Each task’s progress	No. It decides what to do; it does not guarantee what happened
Banking orchestration	Systems, people, and processes of the whole institution	One event-native substrate above what already runs	Everyone who runs the bank: operators, approvers, compliance, and AI agents, on one live picture	Every event, kept permanently	Yes, by construction: ledger, rails, policy, approval, and audit are platform objects

Why does banking orchestration matter now?

Three forces now require a bank’s systems, people, and processes to operate as one (What is Adaptive Financial Infrastructure? explains them in full). Each demands something specific of orchestration.

Agentic AI
one live context, and a decision someone owns.
Real-Time Payments
detection, a decision the bank controls, and an audit record within seconds, on every rail.
Decentralized Finance
tokenized money held as currency, under the same controls as fiat.

One Substrate for All Three

Agentic AI needs one live context and a human to answer for it. Every decision an AI agent takes has to trace to someone accountable, and every action that moves money passes a decision the bank controls. Bain & Company names the failure mode: “Agentic AI cannot orchestrate effectively against fragmented legacy architecture, and the strategy of wrapping legacy systems with digital veneers has run its course.”¹ It also names the remedy. “Enterprises that invest in centralized governance, reusable orchestration layers, unified agent registries, and platform-level policy enforcement move from concept to production in weeks, not months—and at far lower marginal cost.”²

Real-Time Payments need controls at rail speed. Both US instant rails now carry up to $10 million per payment.^3,4 At that size and speed, detection, a decision the bank controls, and an immutable audit record have to happen within seconds, on every rail. Visa Consulting & Analytics locates where the answer sits: “The orchestration layer is where a lot of the strategic value lies.”⁵

Decentralized Finance needs tokenized money under the same controls as fiat. Stablecoins, tokenized deposits, and tokenized central bank money are reaching the balance sheet, with rules already live or dated in the US, the EU, and the UK.⁶ Each presupposes a ledger that treats a tokenized asset as a first-class currency type, under the same controls: sanctions screening, evidence an officer can attest to, and one audit trail across every rail.

How is banking orchestration different from payment orchestration?

Payment orchestration is a subset of banking orchestration. On the merchant side, payment orchestration chooses which provider processes a payment. On the bank side, a payment hub manages a payment’s lifecycle across rails. Banking orchestration includes payment routing as one process among many, alongside onboarding, risk scoring, treasury, and regulatory reporting, all on the same live picture, under the same controls, seen by the same people.

Visa Consulting & Analytics describes a multi-rail architecture whose orchestration tier stays the same across every rail, with only the rail adapters varying.⁵ Banking orchestration takes that constant tier and extends it from payments to the whole institution: on the AFI Platform, the Experience Layer sits above, open adapters sit below, and a policy or an approval applies the same way to every rail.

How is banking orchestration different from journey orchestration?

Journey orchestration covers the surface, not the operation. Journey orchestration, which some vendors call digital banking orchestration, coordinates the bank’s customer-facing work: journeys, data, decisions, and execution across fragmented systems. It reaches the back end through connectors, so a journey can trigger a payment or a credit check.

The difference is scope, on all three vectors:

Vector	Journey orchestration	Banking orchestration
Systems	Calls each system through its own connector; the posting, the settlement, the approval, and the audit record stay wherever they were produced	Integrates each system once and sequences every step across all of them
People	Serves the customer; the treasurer, the compliance officer, the approver, and the AI agents sit behind it	Gives everyone who runs the bank, human or AI agent, one live picture, with a decision the bank controls before money moves
Processes	Sequences the steps a customer sees	Governs the whole process, including the steps no customer sees, with policy, screening, and approval running from the infrastructure

Journey orchestration works from the customer inward. Banking orchestration spans the whole bank in both directions: from the customer’s screen to the ledger, the rails, and the evidence a regulator will ask for, and back again as every change happens.

Every system a bank runs keeps its own record of what it holds: the core for accounts, the payment engine for transactions, the KYC provider for checks. The orchestration becomes the system of record for what runs across them, including the process, every decision and who made it, human or AI agent, the controls that ran, and the positions and audit trail that result. Where a proposition runs entirely on the platform, its multi-currency ledger holds the accounts as well.

A journey layer runs on top of banking orchestration; it is not a substitute for it.

How is banking orchestration different from workflow and process orchestration?

Workflow orchestration knows the steps; banking orchestration also knows the money. Workflow orchestration and business process orchestration sequence tasks and hand-offs, the same way in any industry. That is their strength, and their limit in a bank: they have no native notion of a ledger, a payment rail, a cut-off time, or the evidence a regulator expects, so each institution builds those into every workflow itself. Banking orchestration includes the sequencing and carries the banking context, so a workflow that moves money posts, settles, and leaves its audit record by construction.

How is banking orchestration different from middleware and integration?

Middleware moves messages; banking orchestration owns the process. A message bus can deliver a payment instruction from a channel to a core. It cannot hold the approval that should have happened first, record who gave it, or guarantee that the ledger posting and the audit event committed together.

Banking orchestration does, because it manages the process, not the message. API orchestration and integration platforms are the same: they connect and translate, while the process, the approval, and the record live elsewhere. Middleware is something banking orchestration uses, not something it replaces.

How is banking orchestration different from multi-bank connectivity?

Multi-bank connectivity serves the corporate; banking orchestration serves the bank. Connectivity tools link a company to the banks it holds accounts with. Banking orchestration runs inside the bank, and lets it offer that same one-place experience to its commercial customers under its own brand.

How is banking orchestration different from an open banking orchestration layer?

An open banking orchestration layer governs outside access; banking orchestration governs the whole operation behind it. Open banking layers manage how third parties reach a bank’s data and payments: API gateways, consent, authentication, and connections to licensed providers. Banking orchestration sits behind that front door, so an open banking request becomes one more event on the same stream, under the same controls and audit trail as the bank’s own channels.

How is banking orchestration different from AI agent orchestration?

AI agent orchestration chooses the next action. AI agent orchestration decides which AI agent, model, or tool runs next. It lives in the AI stack and does not guarantee the outcome: it holds no ledger, settles nothing, and keeps no record of who approved what. Banking orchestration is what those AI agents act on, so every action they take passes a decision the bank controls and leaves an event behind.

In every comparison the difference is scope: each adjacent discipline orchestrates one part of the bank, and banking orchestration orchestrates all of it.

How does banking orchestration work?

Three mechanisms turn the definition into something a financial institution can test, one per vector.

Systems integrate once

Each system is integrated once, to one canonical model of banking entities: Customer, Account, Beneficiary, Transaction, Balance. Every system maps to it, from cores and payment rails to KYC providers and AI systems, and every capability and channel reuses the integration.

Vendors sit behind adapter contracts, so the platform binds to no vendor’s roadmap, and an outage or breach at one third party stays at the integration boundary. The bank’s business logic is decoupled from what runs it: it lives in the orchestration, not in any one system.

Bain & Company explains why the old boundaries no longer hold: “Traditional IT architectures were built to route predictable, stateless transactions within clearly defined system boundaries. Agentic systems require something fundamentally different—that is, infrastructure that supports adaptive, multi-turn interactions.”²

People operate in one context

Treasurers, compliance officers, back-office operators, and AI agents read and act on the same record of the bank, one that gives the same answer every time. McKinsey counts the enterprise data sublayer, where a bank’s data is stored and made accessible, among the crucial investments for multiagent systems in banking,⁷ and one of its senior partners puts the human side simply: “Agentic access to data is the big liberator.”⁸

AI-enabled decisioning on live context needs that one picture, and a decision the bank controls before any action that moves money or changes an account: allow, deny, hold, step up, or refer.

People and AI agents decide what to do; the platform guarantees what happened.

Processes carry their governance

Workflow, rule, policy, task, approval, and audit event are platform objects, not features each product rebuilds. Every change is an event on one stream, so the audit trail comes by construction. A new capability arrives governed on day one. The bank’s compliance surface stops growing with its product count. Bain & Company describes the principle: “Security and governance are embedded across layers rather than applied after deployment.”⁹

Event-native architecture runs beneath all three

Every transaction, API call, and ledger update is an event carrying full context, captured on one event backbone and unified in a lakehouse that can reconstruct how any account, payment, or customer stood at any moment. Every event is immutable, which is what turns the record into evidence rather than a log. It runs on a container-first, cloud-portable Runtime Layer.

That is what makes banking orchestration testable: one integration per system, one live picture for everyone who acts, and governance every process carries by default.

How does banking orchestration keep ledger integrity when AI agents act?

Banking orchestration keeps the ledger correct with four engineering patterns, built in by design. They decide whether agentic AI can touch money.

An AI agent built on a language model reasons probabilistically: the same request can produce a different action on a different run. A ledger cannot work that way. Bain & Company frames the requirement from the ledger’s side: “The core deterministic engines that power banking products, ledgers, transactions, and decisioning will need to be modern, flexible, and interoperable with agent-executed experiences and processes.”¹

1. The posting and its event commit together, or not at all

The platform saves the posting and the event that announces it in one step, so both are saved or neither is, and only then tells the rest of the bank. Engineers call this the transactional outbox pattern.¹⁰

2. Repeated instructions cannot double-post

Every instruction that moves money or changes an account carries a unique key, a one-time reference engineers call an idempotency key. The first time an instruction arrives, it runs and its result is stored; if it arrives again with the same key, the platform returns that result instead of running it twice.¹¹

3. Multi-step processes have a way back

A payment that passes sanctions screening, posts to the sub-ledger, and then fails at the rail is not left half-done. Each step has a compensating action, so the process either completes or unwinds, with every step recorded.

4. A decision the bank controls stands in front of money

Before any action that moves money or changes an account, one evaluation returns one verdict: allow, deny, hold, step up, or refer. The AI agent proposes; the bank decides who releases it, whether a person, a rule, or the AI agent itself, within limits the bank sets. Banking orchestration makes it a property of the platform, present from day one.

Together, the four patterns keep the ledger correct

Pattern	What goes wrong without it	What it guarantees
1. Posting and event saved together	An AI agent acts on a posting that never happened, or a posting happens that nothing else hears about	Nothing posts without its event
2. A unique key on every instruction	An AI agent retries after a timeout and the payment goes out twice	Nothing posts twice
3. A way back for every step	A payment is screened and posted, then fails at the rail and is left half-done	Nothing is left half-done
4. A decision the bank controls	An AI agent moves money no one approved	Nothing moves money without a decision someone owns

AI agents can be fast and the ledger stays correct. Each pattern also leaves an event behind, which is what makes the audit record complete.

How do 24/7 instant payments work against a batch general ledger?

Banking orchestration keeps a real-time position on the event stream and posts it to the batch ledger exactly once, in the ledger’s own cycle. That matters because most general ledgers still close once a day, and instant rails never close. FedNow raised its transaction limit to $10 million in November 2025;³ the RTP network reached the same limit in February 2025.⁴ In the euro area, the Instant Payments Regulation makes 10 seconds a hard limit for an instant credit transfer.¹²

Every payment, on every rail, is an event with a single status model, so a FedNow credit, a wire, a SEPA Instant transfer, and a stablecoin transfer report through one lifecycle. The treasurer, the approver, and the controls work on the rail’s clock, not the ledger’s. As Visa Consulting & Analytics puts it, “multi-rail does not mean multi-stack.”⁵

Which regulations does banking orchestration help financial institutions meet?

Financial institutions comply; infrastructure supports them. The regulatory baseline now live across the US, the EU, and the UK presupposes three properties: real-time operation, event-level auditability, and governed third-party dependencies. Each comes with banking orchestration by construction, and each regulation lands on all three vectors at once, as a control on the systems, a decision a person is accountable for, and a process that leaves evidence.

Jurisdiction	Regulation	Systems: the control that runs	People: the decision someone owns	Processes: the evidence left
US	Nacha risk management rules (all participants since June 2026)¹³	Every ACH entry evaluated for fraud as it moves	Entries over a risk threshold go to a person	A record of the evaluation and the decision
US	GENIUS Act (January 2027)⁶	Sanctions screening on every stablecoin transfer	Reserve and redemption evidence an officer attests to	A real-time, auditable ledger
EU	DORA (since January 2025)¹⁴	Third-party failure contained where the provider connects	Incidents reach the people who report them, on time	Every incident recorded as an event
EU	AI Act high-risk obligations, including credit scoring of individuals (December 2027)¹⁵	Controls on how data is used	AI decisions traceable to an owner	Traceability of every AI decision
UK	PRA and FCA operational resilience¹⁶	Services kept within impact tolerances	Mapping of the people each service depends on	End-to-end resource mapping
UK	Senior Managers and Certification Regime	Deterministic records of every AI agent action	A named individual accountable for AI-driven decisions in their business area	An audit trail that proves oversight

The traceability the EU AI Act requires and the accountability SM&CR imposes rest on the same evidence. McKinsey states what makes it available: “[U]nlike humans, agents leave a full audit trail of every action they take.”⁸ That is only true when the platform records the trail by construction.

On a fragmented estate, the trail stops at every system boundary.

How can a bank modernize without replacing its core?

Banks answer fragmentation three ways: keep patching, and the silo count grows; replace the core, and the first win is years out; wrap the estate in cloud and APIs, and the surface changes while the substrate does not. The fourth move is orchestration, which deploys the substrate above what runs.

The estate stays. The fragmentation goes. Integrate once; reuse compounds.

Replacement programs miss their intended benefits

“More than 70% of mainframe exit projects initiated in 2026 will fail to produce the intended benefits”Gartner, 2026¹⁷
75% of mainframe-exit vendors will pivot or cease operations by 2030Gartner, 2026¹⁷
Up to 1.9 million customers locked out of online and mobile banking, and £48.65 million in fines from the FCA and PRATSB, April 2018²²; FCA and PRA, December 2022^19,20

The case against the second move is the record. Gartner expects most mainframe exit projects started in 2026 to miss their intended benefits, largely because they overestimate generative AI, and most of the vendors selling them to pivot or close by 2030.¹⁷

A cutover concentrates the risk

Even where a replacement succeeds, it concentrates the institution’s risk into a single cutover event. TSB’s 2018 migration cost the bank £330.2 million in post-migration charges¹⁸ and, in December 2022, a £48.65 million fine from the FCA and PRA for operational risk management and governance failures.^19,20

A replacement program also solves only one of the three vectors: it moves the systems and leaves people and processes to be rebuilt around the new core.

Orchestration modernizes without replacing what runs the bank

Orchestration changes the shape of the risk: nothing is cut over. People keep their context and processes keep their governance, because both live in the orchestration, not in the system being changed. The first workload lands above existing systems, integrated once; the next reuses the integration; legacy systems are retired, if ever, when it makes economic sense. That is the Deploy, Expand, Modernize path. McKinsey has made the same case since 2020: for midcap banks, progressive modernization, rather than full replacement, costs a fraction of the typical investment and avoids years stuck in a replacement program.²¹ For a serial acquirer, the same holds deal after deal: integration debt comes due all at once in a conversion, and orchestration turns that conversion into coexistence.

So a bank can modernize without replacing what runs it: with orchestration, replacement becomes a choice, not a precondition.

What is an example of banking orchestration?

Take a hypothetical case: a commercial customer initiates a $5 million payment on FedNow at 11 p.m. on a Friday. Here is the flow.

Friday, 11 p.m.
SystemInitiation. The instruction arrives from the bank’s treasury channel as an event on the stream, carrying the customer, account, beneficiary, amount, and rail.
ProcessControls in real time. Sanctions screening and anomaly detection run on the event. The amount exceeds the bank’s approval threshold, so the process routes it for approval.
PersonHuman decision. An AI agent has already assembled the case and proposes a verdict with its reasoning: allow, because the beneficiary is new but matches invoices the customer has paid before. The on-call approver sees it next to the customer’s position, the beneficiary’s history, and the screening results, all from the same live picture, and decides to allow it. Both the AI agent’s recommendation and the approver’s verdict are recorded.
SystemSub-ledger posting. The real-time position updates. The posting and its event are saved together, in one step.
SystemSettlement. The payment is released to the rail and confirmed within seconds. Its status flows back as the same lifecycle every rail reports through.
Weekend: the general ledger is closed
Monday
SystemGeneral ledger. On Monday’s cycle, the posting reaches the batch ledger exactly once. The weekend’s position and the book agree.
Throughout
ProcessAudit. Every step, from initiation to settlement, is an immutable event with its actor, timestamp, and decision.

Nothing required replacing what runs the bank, designing a new reconciliation process, or a separate compliance workstream.

The systems did not change. Now they run as one.

How to evaluate a banking orchestration platform

Nine questions separate orchestration from the adjacent disciplines wearing its name.

Does each system integrate once, to a canonical model, or does every new product re-integrate it? Reuse is the economic test.
Is it event-native, or a batch system with an event layer bolted on? Ask where the audit trail lives. If it is a separate logging pipeline, it can drift.
Does it understand the ledger? Multi-currency by design, with stablecoin as a currency type rather than a module.
Is a new rail configuration, or a project? A rail-agnostic platform adds it as an adapter. If each rail needs its own build, the bank pays the integration again.
Do operators and AI agents work from one live picture of the institution? If each reads a different system, they decide on different facts. And every action that moves money should pass a decision the bank controls.
Are approval, policy, and audit platform objects, or features each product rebuilds? The compliance surface should not grow with the product count.
Is third-party failure contained at the integration boundary? This is the DORA and operational-resilience question.
How long to first production value? Weeks means the platform works with what the bank already runs. Quarters or years mean a replacement in disguise.
What has been independently examined? Ask for a SOC 2 Type II report and an ISO/IEC 27001 certificate, and check their scope covers the platform you are buying, not only the vendor’s offices.

How does banking orchestration relate to Adaptive Financial Infrastructure?

Banking orchestration is what Adaptive Financial Infrastructure is for. Financial institutions get it from the AFI Platform, through its Orchestration Layer. To learn more about the category, the three forces behind it, and the adjacent software categories it unifies, read What is Adaptive Financial Infrastructure?

Frequently asked questions

What is an orchestrator in banking?

An orchestrator is the software that runs banking orchestration: it connects a bank’s systems once, gives its people and AI agents one live picture, and applies the same controls to every process. The AFI Platform is XYB’s banking orchestrator.

Who provides banking orchestration?

Each adjacent discipline has its own vendors: payment orchestrators, journey platforms, workflow engines, and integration middleware. Each covers part of the bank. A banking orchestrator covers all of it, across systems, people, and processes, and the AFI Platform is XYB’s.

Is banking orchestration the same as cloud or workload orchestration?

No. Cloud and workload orchestration schedule computing: containers, servers, and the jobs that run on them, with tools such as Kubernetes. On the AFI Platform, workload orchestration is the job of the Runtime Layer. If what you need is a platform that orchestrates the bank’s operations, not its computing, that is banking orchestration.

What is an event-driven banking orchestration platform?

A platform where every transaction, decision, and change is recorded as an event the moment it happens, and every system, person, and AI agent works from that same stream. Event-driven is how banking orchestration keeps one live picture of the bank.