Cross-Border Route Intelligence Engine
Compliance-gated, explainable route advice for cross-border payments.
A working prototype that advises on settlement paths through correspondent banks and payment market infrastructures. It applies hard compliance gates, multi-objective cost modelling, and explainable, evidence-backed output. It advises on routes; it never moves money.
Introduction
Cross-border payments succeed or fail on decisions made before the first message is sent: which correspondents to use, which market infrastructure to ride, which intermediary a currency demands, and whether the chosen chain is compliant, capable, and awake. The Cross-Border Route Intelligence Engine is a working prototype that turns those decisions into reviewable output. Given an origin, destination, currency, and amount, it proposes viable routes and explains every route it refuses.
The Problem
Routing knowledge in correspondent banking is real but scattered: static routing tables, bilateral habit, and the experience of operations teams. The route that looks cheapest on paper can be non-compliant for the currency, blocked by sanctions exposure, unable to carry structured ISO 20022 data end to end, or simply asleep in the destination timezone. When a payment fails for one of those reasons, it shows up as repairs, investigations, and delay -- and the reason is usually reconstructed after the fact, not surfaced before the payment left.
The Build
The engine builds a routing graph of roughly 123,000 relationship edges from a historical reference-data snapshot of about 4.25 million rows: participants, correspondent relationships, market-infrastructure memberships, settlement instructions, calendars, and readiness data. A multi-objective solver runs five explicit presets (cheapest, balanced, urgent wire, bulk reconciliation, FX sensitive) and can return the Pareto-optimal set of alternatives across hops, cost, and quality. Compliance is handled as a hard gate, not a weight: sanctions exposure, a 53-currency catalogue of mandatory intermediaries, and ISO 20022 readiness block a route outright. The screen fails closed -- if screening is unavailable, the route is blocked, not assumed clean. Every viable route carries a cost story decomposed into four layers (FX spread, lifting fees, compliance friction, transparent fees), and every blocked route carries a reason code with structured evidence. Business calendars down to half-day holidays feed corridor status. Warm route advice returns in 117 to 312 milliseconds. The prototype has since been refactored into middleware form: a source-neutral routing kernel, a provider SDK with conformance probes, a manifested dataset-package format with per-stream digests and optional signatures, immutable dataset generations with atomic activation and audited rollback, and a hardened single-tenant deployment profile -- so the same engine can run inside a customer's perimeter on the customer's own reference data.
Why It Matters
Banks already carry the cost of weak routing decisions through repair queues, opaque exception handling, and payments that stall midway. The useful system 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. The middleware direction means a customer's reference data never has to leave their perimeter: the engine ships to the data.
Tags: Payments, Cross-Border, Correspondent Banking, Routing, ISO 20022, Compliance, Sanctions, Reference Data, Explainability, Middleware