Most banks also land one level below where they expected to sit, and there is a specific reason for that pattern. It comes down to a single question about ISO 20022 processing. Is the structured data native to your core, or is a translation layer converting it on the way in? That answer determines your architectural level regardless of how the rest of your estate performs.
What the payments orchestration maturity model actually measures
Search results for “payments orchestration” are dominated by checkout orchestration, which routes transactions across payment service providers and acquirers to optimize approval rates for a merchant. Bank-side payments orchestration is a different product for a different buyer entirely. It describes what an institution does across its own rails, channels, and exception queues to run one estate rather than several. Same word, unrelated problem, and worth separating before the model starts.
Level 1: Fragmented
At Level 1, each rail runs on its own processing system, with its own operations team and exception queue. Nothing gets shared across rails, and no consolidated view of the estate exists at any operational layer. This level describes the estates that grew rail-by-rail without any consolidating investment along the way.
The symptoms show up in daily operations rather than in architecture diagrams:
- Nobody can answer “how many payments failed today” without contacting two or three separate teams.
- Operations analysts specialize by rail, so the wire team cannot cover ACH and the ACH team cannot cover wires.
- Cross-rail reporting gets assembled by hand in spreadsheets, usually on a monthly rather than a daily cadence.
- Sanctions and AML screening runs separately per rail, sometimes through different vendors on different contracts.
Headcount at Level 1 scales close to linearly with rails, so twice the rails means roughly twice the operations people. Every new rail requires a new team, a new runbook, and a new screening integration standing up from scratch. Operating leverage is zero, and every rail addition compounds total run cost rather than distributing it.
The new-rail test at Level 1 is unambiguous. A pilot cannot even start without standing something new up: a new system, a new team, a new process, new integrations.
Level 2 changes connectivity. Payments can move between systems, and a route to a shared message format exists, even if that route runs through a converter. Payment Hub is the capability that gets a Level 1 estate to Level 2, and it is worth reading up on before the reallocation conversation starts.
Level 2: Connected
At Level 2, the systems talk to each other through point-to-point integrations. ISO 20022 works because a translation layer converts messages before they hit legacy processing. The estate looks modernized from the outside, but the architecture underneath hasn’t fundamentally changed. Most banks sit at this level, and it is where the payments orchestration maturity model does its most useful work.
The symptoms are subtle enough that operators often misread the level:
- Adding a rail means adding integrations, and the integration count grows faster than the rail count.
- ISO 20022 processing works, but one thing converts messages inbound, and another converts them outbound.
- Rich structured data arrives at the perimeter and gets truncated or dropped at the translation boundary before storage.
- Changing a routing rule requires a code change and a release slot on the engineering calendar.
- Exception queues remain largely per-rail.
Integration debt is the cost that defines Level 2, and it accumulates on every connection the estate carries. Data fidelity drops at every translation hop, and downstream analytics inherit gaps that no reporting layer can fix. Most consequentially, any regulatory change that touches data structure becomes a program rather than a configuration change.
At Level 2, remediation typically runs as a nine-month program because the systems behind the translation layer were never designed to hold structured party data. A converter can pass a compliant message through, but it cannot fix an underlying schema that has no home for the new fields.
The new-rail test at Level 2 also disappoints. The pilot succeeds and then becomes a permanent island, connected but never consolidated with anything.
At Level 3, one place processes payments, so one place changes when the rules change. Embedded Preprocessing is the capability that moves a Level 2 estate forward without replacing what already runs.
Why most banks land one level below where they think they sit
Banks feel like Level 3 because they have one hub interface and one operational dashboard. That impression is honest, but it measures the wrong surface of the estate. The payments orchestration maturity model asks a narrower question. Is structured data native to processing, or does a translation layer sit in front of it?
A translation layer in front of legacy processing caps you at Level 2, no matter how well you score on every other dimension. ISO 20022 compliance that works because something converts it is a message-format achievement, not an architectural one. The format complies; the estate underneath has not changed. This is why the November tell matters so much for accurate self-placement.
Level 3: Consolidated
At Level 3, a single hub processes messages across rails with a common operations view, but routing rules remain static and hard-coded. Changing a rule requires a release, which means commercial flexibility runs at engineering speed. The estate looks and feels consolidated, and in most respects it genuinely is.
The symptoms of Level 3 show up in what the operating model can and cannot do:
- One system, one operations view, and genuinely fewer people required to run the estate.
- A product manager who wants to change a routing rule raises an engineering ticket rather than editing a configuration.
- Launching on an existing rail takes a quarter because it needs a release slot on the engineering calendar.
- Exceptions are grouped and visible in one queue, but resolution still runs mostly through manual analyst work.
- ISO 20022 may be native inside the hub while legacy peripherals around it still require translation on the way in.
The cost at Level 3 is commercial rather than operational, and it shows up in time-to-market for anything new. Banks can execute what they planned for and struggle with what they did not. Product roadmap velocity becomes a function of the release calendar rather than the market opportunity in front of the team.
The new-rail test at Level 3 partially succeeds. The rail lands in the hub, but nothing can dynamically route to it because routing decisions were fixed at build time.
At Level 4, policy replaces code, and rule changes become configuration rather than engineering work. Embedded Preprocessing enables the dynamic routing layer, and Payment Hub sits underneath as the consolidated processing engine.
Level 4: Orchestrated
At Level 4, dynamic routing policy replaces hard-coded rules, and unified exception management covers every rail through one consistent workflow. Native ISO 20022 runs end-to-end across the estate, and new rails and products ship without new integrations. The payments orchestration maturity model treats Level 4 as the first architecturally complete level.
The symptoms are operational transformations rather than incremental improvements:
- A routing rule changes through configuration with no release cycle involved.
- One exception queue covers every rail, with one consistent resolution workflow for analysts.
- A corporate client sees one interface, one status view, and one exception process across all payment types.
- Launching on an existing rail takes days, not a quarter.
- Least-cost and best-fit routing become live decisions rather than design-time assumptions baked into code.
Two examples make Level 4 concrete for operators evaluating the model. A US instant payment can route to either FedNow or RTP based on live reachability, and a SEPA Credit Transfer can convert to SEPA Instant based on when receipt needs to occur. Both decisions happen through self-service configuration rather than release-gated engineering.
Level 4 has a cost worth naming, and saying so is what makes the maturity model credible. Most Level 4 estates still run manual exception handling they no longer architecturally need. The infrastructure supports considerably more automation than the operating model currently asks of it.
The new-rail test at Level 4 is decisive. A stablecoin rail gets added without creating a new silo underneath the interface layer.
At Level 5, the data finally runs clean, complete, and current enough for software to act on it unsupervised. Payments as a Service is the delivery model that gets banks to Level 4 without a multi-year build program.
Level 5: Autonomous
At Level 5, an agentic layer operates on top of the orchestrated estate, preventing, repairing, and predicting across the payment lifecycle. Autonomy expands as confidence gets demonstrated, payment type by payment type, rather than switching on across the whole estate at once. Level 5 sits on top of Level 4, and reaching it requires Level 4 as a foundation.
The symptoms describe an operating model that has changed shape:
- Exceptions resolve before an analyst ever sees them in a queue.
- Data errors get corrected before submission rather than repaired after a reject downstream.
- Straight-through processing runs above 95% consistently across payment types.
- Operations headcount stays flat or falls while transaction volume grows year over year.
- Autonomy is scoped and governed, starting with assisted and expanding as it earns trust.
The cost at Level 5 is nothing architectural. The constraint becomes commercial: which markets, which rails, and which product lines justify the autonomous layer. Not every bank needs Level 5, and saying so out loud buys the maturity model its credibility.
A Level 4 institution with modest volumes and a stable set of rails may see limited return from Level 5. The autonomous layer pays off where volume, exception rates, or rail count are high enough to make manual handling a persistent bottleneck. Level 4 is the destination for many banks, and treating Level 5 as universal would misread the economics.
The new-rail test at Level 5 is the strongest of the five. Exceptions on the new rail resolve before an analyst sees them, from day one of operation. Payments Intelligence is the agentic layer that runs on top of an orchestrated estate.
Closing the gap the maturity model reveals
Most banks find they sit one level below where they expected before running through the payments orchestration maturity model. Volante’s Payments Orchestration solutions close the gap without a rip-and-replace program, and Embedded Preprocessing moves an estate from Level 2 to Level 4 without touching the core. More than 75 banks worldwide already run on it.
The 14 November deadline gives Level 2 estates the most immediate reason to act, but every level in the model has a path forward that doesn’t require replacement. Every quarter of delay makes the reallocation case harder, not easier, to build. Reach out to Volante to see where your estate sits and what a realistic path looks like from here.
