Cross-Border Route Intelligence: The Cheapest Path Is Rarely the Right Route

For the past few months I have been building a cross-border route intelligence engine: a prototype that advises on how a payment should travel through correspondent banks and market infrastructures. It applies hard compliance gates, multi-objective cost modelling, and explainable output. It recommends routes and explains itself. It never moves money.

For the past few months I have been building a cross-border route intelligence engine: a working prototype that, given an origin, a destination, a currency, and an amount, advises on how a payment should travel through correspondent banks and market infrastructures. It recommends routes and explains itself. It never moves money.

The thesis behind it is simple: the cheapest path is rarely the right route. A payment route is a compliance decision, a data-readiness decision, and a timing decision before it is ever a cost decision -- and most of the tooling in this space treats it as a lookup.

The Idea

A cross-border payment route is a chain of choices: which correspondents to use, which market infrastructure to ride, which intermediary a currency demands, and whether every institution in the chain is compliant, capable of carrying structured data end to end, and actually open for business when the payment arrives. Today that knowledge is real but scattered -- static routing tables, bilateral habit, and the accumulated experience of operations teams. It mostly surfaces after something goes wrong.

What I wanted was decision support: given this payment, show me the routes I can defend, and for every route you refuse, show me the evidence. Not a black box that picks a winner, but a system whose viable routes come with a cost story and whose blocked routes explain themselves.

How a Route Gets Decided

The engine builds a routing graph of roughly 123,000 relationship edges -- correspondent relationships, market-infrastructure memberships, settlement instructions -- from a historical reference-data snapshot of about 4.25 million rows. On top of that graph, a multi-objective solver runs one of five explicit presets: cheapest, balanced, urgent wire, bulk reconciliation, and FX sensitive. Each preset is a stated weighting of hops, composite cost, and quality signals, not an opaque score.

Compliance is handled differently, and deliberately so. Sanctions exposure, currency-specific mandatory intermediaries (a 53-currency catalogue -- think of the currencies that must clear through their domestic infrastructure), and ISO 20022 readiness are hard gates, not weights. A sanctions hit is not a cost to be traded off; it is a wall. And at the product boundary the screen fails closed: if screening is unavailable, the route is blocked, not assumed clean.

The engine also keeps two cost numbers on purpose. One is the raw economics of a path, decomposed into four layers: FX spread, lifting fees, compliance friction, and transparent fees. The other is the solver's objective under your chosen preset. They agree only when your objective is "cheapest", and that is the point -- what a route costs and how much you should want it are different questions, and collapsing them into one number is how routing tools quietly lie.

Time is a first-class input too. Business calendars down to half-day holidays, timezones, and operating windows feed corridor status, because the best route on paper may simply be asleep.

What the Prototype Includes

• A versioned route-advice API that returns viable routes and blocked routes, every blocked route carrying a reason code and structured evidence.
• Pre-flight endpoints for message readiness, corridor status and operating windows, and FX and fee quotes.
• A "Why this route?" narrative for every decision, with per-claim citations back to structured fields. Deterministic by default; an LLM can polish the prose, but it is never allowed to invent a fact.
• A visual workbench that renders exactly the path the API selected -- pinned, not recomputed, so what you see is what was decided.
• Warm route advice returns in 117 to 312 milliseconds across representative corridors. Behind it sit more than six hundred automated checks, byte-exact parity baselines that freeze routing behaviour against regressions, and two rehearsed rollback switches for the riskiest engine changes.

From Prototype to Middleware

The most interesting work of the past few weeks was not another routing feature. It was taking an engine that was married to one dataset and splitting it into a source-neutral kernel and a platform around it: a provider SDK with black-box conformance probes, a manifested dataset-package format with per-stream digests and optional signatures, immutable dataset generations with atomic activation and audited rollback, an explicitly migration-owned schema, and a hardened single-tenant deployment profile.

That is the direction this is heading: routing intelligence as middleware that runs inside a customer's perimeter, on the customer's own reference data. Your data does not travel to the engine; the engine ships to your data. Import a package, validate it, activate a generation, roll back if you do not like it -- with every step recorded.

The Honest Boundary

This is a working prototype, not a product. It is powered by a historical reference-data snapshot; results are for technical demonstration and route-intelligence methodology only, not current payment-routing advice. The fee and FX models are transparent heuristics, not negotiated price cards. The dataset-import path is exercised against a fictional test corpus and has not yet been validated with a real design partner. And there is no public demo yet -- deliberately. The methodology is the disclosure; a link to a running system comes later, when the system is ready.

Why It Matters

Banks already carry the cost of weak routing decisions through repair queues, investigations, and payments that stall midway. The useful system here is not a black box that picks a route. It is decision support that shows the routes a team can defend, refuses the ones it cannot, and leaves evidence for both.

If you run payments operations, correspondent relationships, or a routing table you would rather not maintain by hand, I would like to compare notes. Tell me where this pattern breaks.

View the project page

Topics: Payments, Cross-Border, Correspondent Banking, Routing, ISO 20022, Compliance, Explainability