Cross-Rail Smart Routing by Cost, Speed, and Reach
Once a payment can travel by several rails, choosing among them becomes a real decision — and one the sender should not have to make. Cross-rail smart routing treats rail selection as a scoring problem: given the destinations behind an alias, score each viable rail on cost, speed, and reach, then pick the winner. It is the brain behind pay-by-alias.
The three axes that matter
Most routing decisions come down to three factors. Cost is what the transfer will incur in fees. Speed is how quickly the recipient gets usable funds. Reach is whether the recipient can actually receive on that rail at all. A rail that is cheap but cannot reach the recipient scores zero; reach is a gate before cost and speed even matter.
- Cost: ACH tends to win for large, non-urgent batches.
- Speed: FPS, Solana, and mobile money settle in seconds.
- Reach: only rails the recipient has verified are candidates.
Scoring in practice
The engine starts by filtering to destinations that are verified and reachable. It then scores each surviving rail against the specific payment's needs — a $5 transfer to a phone weighs differently from a $50,000 payout to a US bank. The highest score wins, and ties break toward reliability. The output is a single chosen rail plus a fallback order.
| Payment | Likely winner | Why |
|---|---|---|
| Small, urgent, to a phone | Mojaloop | Instant, reachable, low value |
| Large, routine, US bank | ACH | Lowest cost, timing tolerable |
| Instant, domestic UK | FPS | Fast and cheap for the amount |
| Crypto-native counterparty | Solana | On-chain reach and speed |
Fallback, not failure
Because the alias resolved to several destinations, the engine keeps a ranked list rather than a single choice. If the top rail fails — a timeout, a return, an outage — routing can try the next candidate instead of bouncing the payment back to the sender. That resilience is only possible because addressing was separated from routing, as covered in our post on aliases and proxy lookups.
Policy on top of scoring
Raw scoring is not the whole story. Businesses often want policy overlays: prefer a rail for compliance reasons, cap crypto usage, or force domestic rails for certain corridors. Smart routing has to let policy constrain the scoring without hard-coding it, so operators can express intent without editing the engine.
Why senders never see it
The best routing is invisible. The sender picks a person, confirms a name, and taps send; the engine quietly does the arithmetic and settles on the best rail available. In KibiPay, that invisibility is the point — complexity absorbed by the platform is complexity removed from the user. For the catalogue of rails the engine chooses among, see the rails.
Observability makes it trustworthy
An engine that silently picks rails is only trustworthy if operators can see why it chose what it did. Logging the candidates considered, the scores assigned to each, and the rail finally selected turns routing from a black box into something you can audit and tune. When a payment takes an unexpected path, that trail explains it in seconds; when a whole corridor underperforms, the accumulated scores show exactly where to adjust policy. Observability also underpins the fallback story — you want to know how often the top choice failed and the engine had to reach for a second option, because a rail that fails often should slide down the rankings on its own. Smart routing that cannot explain itself will eventually lose the operator's confidence, no matter how good its individual decisions happen to be. Transparency is the price of letting a machine make choices that used to be a human's, and it is a price well worth paying.
Cost, speed, reach — score them for every payment and the right rail chooses itself, no dropdown required.