How Correspondent-Banking Route Algorithms Choose a Cross-Border Payment Path: Graph Costs, Cut-Off Times, FX, Liquidity and Exceptions

Reader question: If Bank A must send money to Bank Z in another country and currency, but the two banks do not share a direct settlement relationship, how can a payment engine choose a workable path through one or more intermediary banks?

A correspondent-payment route can be modelled as a constrained path-finding problem on a financial network. Banks, settlement systems and eligible intermediaries form nodes. Reachable payment relationships form edges. Each edge can carry properties such as currency, cut-off time, expected processing time, fee, FX requirement, settlement account, message capability, compliance constraints and historical exception rate.

The mathematical task is not simply “find the shortest path.” It is closer to:

find a feasible path that satisfies hard constraints and minimises an approved cost function.

Page role and boundary

This article explains public, general mathematics behind cross-border payment routing. It is not instructions for bypassing bank controls, sanctions, anti-money-laundering requirements or payment-system rules. It does not describe any bank’s private routing engine or recommend how an individual should transfer money.

The page is deliberately narrower than Bukit Timah Tutor’s overview of payment systems, graphs, queues and routing. That article explains the broad system. This one isolates the cross-border path-selection problem: how reachability and constraints turn a payment network into an optimisation problem.

Why correspondent banking creates a graph

A bank does not necessarily hold settlement accounts in every country and currency. Instead, it can rely on correspondent relationships. In simplified form, suppose:

• Bank A can send USD through Banks B and C;
• Bank B can reach Bank Z directly in USD;
• Bank C can reach Bank D, which can then reach Z;
• another route requires converting USD to EUR and later to the destination currency.

The candidate graph might contain paths:

A → B → Z

A → C → D → Z

A → E → FX venue → F → Z

All three are topologically possible. They are not necessarily operationally feasible at the time the payment is submitted.

Hard constraints come before optimisation

A routing engine should first eliminate paths that cannot be used. Typical public examples of hard constraints include:

• the intermediary cannot process the required currency;
• the beneficiary bank is not reachable through the selected channel;
• the relevant cut-off time has passed;
• the settlement account or correspondent relationship is unavailable;
• message-format or identifier requirements are not satisfied;
• required compliance checks have not passed;
• the route would violate an internal or external risk limit;
• the value date is not valid because of a market holiday;
• the required payment-market-infrastructure connection is unavailable.

This produces a feasible subgraph G* from the larger network G. Only then does it make sense to compare candidate paths.

This order matters. If an optimiser ranks a forbidden route as cheapest and only later discovers it cannot be used, the system can waste time repairing or rerouting a payment that should never have been sent down that branch.

A simple route-cost function

For a candidate path p, define a generic cost:

C(p) = αF(p) + βT(p) + γL(p) + δE(p) + εR(p).

Here:

• F(p) = expected fees and explicit charges;
• T(p) = expected processing time or lateness penalty;
• L(p) = liquidity or prefunding cost;
• E(p) = expected exception or repair burden;
• R(p) = risk measure approved for routing;
• α, β, γ, δ, ε = weights reflecting the institution’s objectives and constraints.

This is an educational abstraction, not a claim that banks use this exact formula. The value of the model is conceptual: a route that is cheapest in fees can be worse after delay, liquidity and exception risk are included.

Worked example: shortest path versus best feasible path

Suppose three routes remain after hard constraints:

• Route 1: A → B → Z, fee 8, expected time 4 hours, exception score 1;
• Route 2: A → C → Z, fee 12, expected time 1 hour, exception score 0.5;
• Route 3: A → D → E → Z, fee 6, expected time 10 hours, exception score 3.

If the payment has a same-day deadline and lateness is expensive, Route 2 can dominate despite its higher fee. If the payment is not time-sensitive and Route 3 has enough liquidity and reliable processing, the cheapest route may become acceptable. If D’s cut-off has already passed, Route 3 is not merely expensive — it is infeasible and should be removed before optimisation.

This is the difference between objective functions and constraints. A cut-off time should not necessarily be represented as a small cost. Once missed, it may be a hard zero-one condition.

Cut-off times make the graph time-dependent

A payment network at 09:00 is not the same graph as the same network at 17:30. Edges can open and close as local systems, correspondents and currency markets pass cut-off times. Holidays can remove an edge for an entire value date.

Mathematically, edge availability becomes a function of time:

edge e is usable only if A_e(t) = 1.

A route found from yesterday’s reference data can therefore be invalid today. Current directories, market calendars and connectivity status are part of the state of the graph.

Currency turns one graph into a layered graph

If the payment must cross currencies, it is useful to imagine multiple currency layers. A node can have a USD state, EUR state, SGD state and so on. An FX conversion becomes an edge between layers.

Then a path can contain both bank-to-bank edges and currency-conversion edges:

(Bank A, USD) → (Bank B, USD) → FX → (Bank B, SGD) → (Bank Z, SGD).

The optimiser must consider more than the quoted FX rate. It may also need settlement timing, liquidity availability, spreads, value-date conventions and whether the chosen currency route introduces an extra intermediary. BIS experiments such as Project Rialto have examined how modular FX components can reduce frictions in cross-border instant payments, including cases where a vehicle currency is required.

Reference data are part of the algorithm

SWIFT’s public descriptions of its routing and reference-data services illustrate the importance of accurate identifiers and operational data. Relevant information can include BICs, clearing codes, payment-system participation, standing settlement instructions, currencies, connectivity, bank holidays, channels and intermediary roles.

A path-finding algorithm with stale reference data can fail even if its graph mathematics is perfect. The weak link may be a bank identifier that changed, a holiday calendar not updated, a correspondent no longer reachable in that currency, or an incorrect assumption about which intermediary participates in the destination RTGS system.

Message quality affects route feasibility

Cross-border payments carry structured information as well as money. Missing, malformed or inconsistent beneficiary and agent data can cause repair, rejection or delay. SWIFT has reported that a large share of payment exceptions in its analysis came from formatting errors, account issues and invalid data, which is why pre-validation has become an important friction-reduction mechanism.

The CPMI’s harmonised ISO 20022 data requirements for cross-border payments likewise aim to reduce fragmentation by encouraging a consistent minimum data set. This connects directly to Bukit Timah Tutor’s article on ISO 20022 validation algorithms: a route can exist physically but fail computationally because the transaction data cannot pass required validation.

Tracking changes the evidence available to the router

Modern payment tracking can feed back observed route performance. A unique end-to-end transaction reference allows a payment to be traced across multiple counterparties. Historical observations can estimate:

• median and tail processing time by route;
• frequency of repair or rejection;
• where fees are deducted;
• which intermediaries create repeated delays;
• how often a route misses a promised value date;
• whether performance changes by currency, amount band or time of day.

This turns route selection from a static shortest-path problem into an evidence-updated optimisation problem. But historical performance is not destiny. A route that was fast for months can fail because a system is down, a holiday begins, liquidity is scarce or a rule changes.

Compliance checks are constraints, not obstacles to be optimised away

A public-safe routing model must keep legal and compliance requirements outside the objective function in the sense that they cannot be traded away for a cheaper route. If a required check has not passed, the route is not feasible.

BIS Project Mandala is useful as a public example because it explored whether policy-compliance checks could be completed and represented before a cross-border transaction proceeds. The broader mathematical lesson is that some conditions are admissibility gates, not prices.

Failure modes

Stale graph: an intermediary relationship or channel is assumed available after it has changed.

Wrong currency reachability: the bank can reach the beneficiary institution, but not in the required currency.

Cut-off blindness: the chosen path is valid in topology but impossible at the current time.

Fee-only optimisation: the engine repeatedly chooses a low-fee route with high delay or exception costs.

Data-quality failure: an invalid BIC, account format or agent field causes repair after routing.

Hidden liquidity assumption: a route requires prefunding or available correspondent balance that is not present.

Correlation blindness: several apparently independent routes depend on the same infrastructure and fail together.

Historical overfitting: yesterday’s fastest route is treated as permanently optimal despite changing market state.

Diagnostics and verification

• Reachability test: for each candidate destination and currency, independently confirm that the proposed intermediary chain can actually deliver the payment.
• Time-window test: replay the same payment just before and just after each cut-off and verify that closed edges disappear.
• Holiday test: inject mismatched local holidays and check value-date logic.
• Reference-data lineage: record the source and update timestamp for identifiers, channels, settlement instructions and calendars.
• Counterfactual routing: compare the chosen path with the next-best feasible alternatives and explain the difference in cost components.
• Exception backtest: compare predicted route quality with actual repair, rejection, fee and timing outcomes.
• Outage test: remove a major intermediary or payment system from the graph and verify that the engine finds a legitimate alternative or stops safely.
• Loop test: reject cycles that would send a payment through the same institution unnecessarily unless a documented market structure requires it.
• Compliance gate test: verify that a cheaper path cannot bypass a mandatory control.

Counterexamples and alternatives

Correspondent routing is not the only possible architecture for cross-border payments. Multilateral platforms and interlinked instant-payment systems can reduce the number of bespoke bilateral connections required. BIS Project Nexus, for example, developed a model for connecting domestic instant-payment systems through a standardised multilateral arrangement rather than requiring every system to build a custom connection to every other system.

That does not make correspondent banking mathematically irrelevant. It changes the graph. A more connected platform can replace some long paths with shorter ones, alter where FX is performed, and shift which constraints dominate.

Similarly, payment-versus-payment and FX settlement mechanisms answer a different question: how to reduce principal settlement risk once currencies and settlement obligations have been chosen.

What would falsify confidence in the routing model?

Confidence should fall if the engine repeatedly chooses paths that cannot settle; if actual fees, delays or exceptions systematically exceed predictions; if reference data cannot be traced to a current source; if route choices do not change when cut-offs or outages change; if a supposedly independent alternative shares the same hidden point of failure; or if mandatory controls can be bypassed by changing objective weights.

A routing model earns confidence when its chosen path remains reproducible, feasible and explainable under changed conditions — not merely when one payment arrives successfully.

Connections across Bukit Timah Tutor

Route choice sits between message validity and settlement. Start with ISO 20022 validation for structured payment data, then connect to payment-system graphs and queues. Once obligations reach settlement systems, intraday-liquidity algorithms explain why a technically valid route can still depend on the timing and availability of settlement balances. If an exception occurs, transaction reconciliation shows how systems detect mismatches after movement.

Current status and update triggers

Cross-border payment infrastructure is changing quickly. BIS Project Nexus moved from prototype work to a live-implementation organisation involving central banks in Asia, while CPMI continues to maintain harmonised ISO 20022 cross-border data requirements through the G20 cross-border-payments programme. FSB targets continue to focus international work on cost, speed, access and transparency through 2027 and beyond.

Re-check this article when major payment networks change routing directories or message requirements, when ISO 20022 cross-border market practice changes materially, when new multilateral instant-payment links go live, or when legal and settlement arrangements alter the set of feasible routes.

Primary and high-quality references

• Bank for International Settlements, Project Nexus: enabling instant cross-border payments.
• Committee on Payments and Market Infrastructures, Harmonised ISO 20022 data requirements for enhancing cross-border payments — updated report.
• Bank for International Settlements, Project Mandala: compliance in cross-border transactions.
• Financial Stability Board, G20 Targets for Enhancing Cross-border Payments.
• Swift, SwiftRef Payments Directory, for public examples of routing reference data and intermediary selection use cases.
• Swift, Payment Pre-validation.
• Swift, Unique End-to-end Transaction Reference (UETR).

Educational boundary: This article teaches graph theory, constraint logic and operational verification using public payment-system concepts. It does not provide a method for evading financial controls or choosing a personal money-transfer service.