Which Payment Rail? Choosing Between Instant, RTGS, SEPA, and Correspondent

Choose on six dimensions, in order: reach, finality, speed, cost, data richness, and failure behaviour. Reach eliminates candidates before anything else matters. Finality is the one that reshapes your system design. And build the decision as a business-owned rules table, because encoding it in if-statements stops scaling at about the fourth scheme.

A corporate client asks why their supplier payment to Portugal took two days when their payment to Germany arrived in four seconds. Both were euro. Both went from the same account. The bank sent one over an instant scheme and one through a correspondent, and nobody in the conversation can explain why.

Rail selection is one of the least documented decisions in payments and one of the most customer-visible. This closes the scheme track of The ISO 20022 Reference, after bulk payments.

The six dimensions

Speed is what everyone asks about and it is rarely what decides.

Dimension	The question	Why it matters
Reach	Can this rail deliver to this beneficiary at all?	Eliminates candidates outright
Finality	Can the payment be unwound after settlement?	Determines where every control must run
Speed	When must the beneficiary actually have the funds?	Often less urgent than assumed
Cost	Per payment, and the liquidity it consumes	Decisive at retail volumes, negligible at high value
Data	Will the remittance detail survive?	Decides whether the beneficiary can reconcile
Failure	What happens when it goes wrong, and who handles it?	Sets your operational load

Work them in that order. Reach first, because it is a filter rather than a preference.

Reach: the filter that comes first

A rail that cannot deliver to the beneficiary is not a candidate, however good it looks otherwise.

Reachability is concrete and checkable: does the beneficiary’s institution adhere to this scheme, for this currency, for this payment type. Not every institution in the SEPA area is reachable for instant payments, even now that regulation has pushed adoption. Domestic schemes are bounded by their country. Correspondent routes depend on your own relationships.

So routing logic is, first and foremost, a reachability lookup, and it needs current data. A stale reachability table sends payments down a rail that rejects them, producing a failure that looks like a system fault and is actually a data problem. Put an owner and a refresh cadence on it, the same discipline as external code lists.

This is also the honest answer to the Portugal question in the opening: the German beneficiary’s bank was reachable for instant, the Portuguese one was not, and nobody surfaced that to the client.

Finality: the dimension that reshapes the system

Whether a payment can be unwound after settlement is the dimension with the deepest design consequences, and it gets the least attention in rail comparisons.

Irrevocable rails (RTGS, instant schemes) allow no unilateral recovery. Every control must run before settlement: screening, fraud, limits, duplicate detection. There is no queue to hold a suspicious payment in, and no ability to reverse when something is found afterwards. See SEPA Instant for what that does to screening, and RTGS for what it does to liquidity.

Recoverable rails, in the limited sense that a recall mechanism exists, give you a process. Not a guarantee: a recall is a request the beneficiary bank may decline, and the money may already be gone. But a process exists, and operations can work it.

The practical implication for an analyst: if you add an irrevocable rail to a product that previously used a revocable one, you are not adding a routing option, you are changing the control model. Fraud controls calibrated for a rail where suspicious payments could be held will not transfer. That is a scoping conversation to have at the start, not a defect to find in testing.

Speed, cost, and the question people get wrong

Speed is the dimension clients ask for and analysts should interrogate.

The useful question is not “how fast can it go” but “when does the beneficiary actually need the funds, and what breaks if they arrive later?” A supplier payment against 30-day terms does not need to arrive in four seconds. A property completion does need certainty on a specific day. A payroll needs to land on the value date, which is a deadline rather than a speed requirement.

Paying for instant settlement on payments where next-day would serve is a cost with no corresponding benefit, and at corporate volumes it is a visible one.

Cost has two components that behave differently:

• Per-payment fees, which are decisive at retail volume and irrelevant on a 40 million euro RTGS payment.
• Liquidity cost, which is the reverse: negligible for low-value schemes, real for RTGS where funds must sit in a central bank account at the moment of settlement.

Corporate clients frequently do not know they are choosing. Offering an explicit speed and cost choice at initiation, and defaulting sensibly, is usually a better product decision than optimising invisibly.

Data: does the remittance survive?

If the beneficiary needs invoice detail to reconcile, the rail decides whether they get it.

Domestic and single-scheme routes where every hop is ISO 20022 native carry structured remittance intact. Long correspondent chains degrade it at the first non-native hop, and often that hop is one you do not control. The truncation ledger documents the loss, and remittance information covers what can be done about it.

This dimension is the one to raise when a business case promises corporate clients rich remittance data. The promise is only true on routes where it survives, and the routing decision is what determines that.

Failure behaviour: your operational load

Every rail fails differently, and the differences decide how much operational effort a flow generates.

• Rejection speed. An instant scheme tells you in seconds. A correspondent chain may tell you in days, or through an investigation you have to initiate.
• Reason quality. Scheme rejections carry mapped reason codes. Correspondent failures often arrive as free-text investigation responses that a human has to interpret.
• Uncertainty states. Instant payments have a genuine timeout-with-unknown-outcome state, described in SEPA Instant, which needs its own resolution process.
• Who chases. Scheme failures are usually self-service. Correspondent failures mean contacting a bank and waiting.

An analyst estimating the operational cost of a new corridor should weight this heavily. A rail that is slightly cheaper per payment and generates ten times the investigations is not cheaper.

Build it as a rules table, not as code

The decision itself should be automated. The rules should not be in the application.

A workable shape:

Corridor	Currency	Amount from	Amount to	Urgency	Preferred	Fallback
Domestic EUR	EUR	0	100,000	Normal	SCT	SCT Inst
Domestic EUR	EUR	0	any	Urgent	SCT Inst	RTGS
Domestic EUR	EUR	100,000	any	Normal	SCT	RTGS
SEPA area	EUR	0	any	Normal	SCT	Correspondent
Non-SEPA	any	0	any	any	Correspondent	none

Owned by the business, versioned, reviewable, with an effective date. Rails, thresholds, and corridors change several times a year, and a decision encoded in if statements turns every commercial change into a software release. This is the same argument as per-scheme profiles in RTGS on ISO 20022, and it holds for the same reason: three options become seven, and branching code stops scaling around the fourth.

Every row needs a reachability check layered on top, because the table describes intent and reachability describes possibility.

Always specify the fallback

The most common gap: the preferred rail is unavailable and nobody decided what happens.

Three options, each requiring an explicit choice:

1. Fall back to the next rail. Convenient, and it may silently change cost, finality, and speed. If a payment falls back from an instant scheme to a correspondent route, the client expected seconds and gets days, and nobody told them.
2. Queue until the rail is available. Right for a scheduled payment, wrong for an urgent one.
3. Fail with a clear reason. Honest, and it pushes the decision back to the customer.

A silent fallback that changes finality is the dangerous one: a payment the customer believed was irrevocable and instant, delivered through a route where neither is true. If you allow fallback, the customer must be told, and the record must show what they were told, the same evidential logic as Verification of Payee.

What to test

• Each row of the rules table, asserting the selected rail.
• A beneficiary unreachable on the preferred rail, asserting the fallback behaviour and the customer message.
• An amount exactly at a threshold, and one either side.
• A payment where the fallback changes finality, asserting the customer is informed.
• A stale reachability entry, asserting the failure is diagnosable rather than looking like a system fault.
• A rules table change taking effect on its effective date, without a deployment.

That last one proves the configuration mechanism actually works, which is the whole point of building it.

The takeaway

Rail selection runs on six dimensions and speed is rarely the deciding one. Reach filters the candidates first. Finality determines where every control has to sit and is the dimension that changes system design rather than just routing. Cost splits into per-payment fees and liquidity, which matter on opposite ends of the value range. Data richness decides whether the beneficiary can reconcile. Failure behaviour decides how much operational work the flow creates.

Automate the decision from a rules table the business owns, with reachability layered on top and an effective date on every change. And specify the fallback explicitly, because a silent fallback that changes what the customer was promised is worse than a clean rejection.

That closes the scheme track. The full map, including the field-by-field track from the agent chain through sanctions screening, is on The ISO 20022 Reference.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: Payments, ISO 20022, Payment Schemes, Systems Analysis, Banking