Pay by Alias: How the Orchestrator Picks Your Rail
The magic of paying someone by their alias — a handle, phone number, or email — is that you do not have to care how the money gets there. Behind that simplicity sits an orchestrator that resolves the alias and then chooses the best rail on your behalf. This post opens the hood on that decision: how KibiPay turns "pay @sam" into a concrete transfer over the right rail.
Step one: resolve the alias
Before anything can move, KibiPay has to figure out who you mean. The alias is looked up in the cross-rail directory, which maps it to a real recipient and the rail-specific destinations behind them. This is the same proxy resolution used by national schemes, described in aliases and proxy lookups. The payer sees the resolved display name confirmed back to them, a safeguard akin to Confirmation of Payee.
Step two: choose the rail
Once KibiPay knows the recipient can be reached on, say, Mojaloop, ACH, FPS, or Solana, the orchestrator weighs the options. It is effectively answering: of the rails that can deliver this payment, which is best right now? The factors it balances are the classic three:
- Cost. Some rails are cheaper per transfer than others.
- Speed. Instant rails settle in seconds; batch-style rails may take longer.
- Reach. Not every recipient is reachable on every rail; the rail must actually connect to them.
These trade-offs are the heart of smart routing, which we cover in depth in cross-rail smart routing. The orchestrator's job is to pick the rail that best fits the payment's needs without asking you to think about any of it.
Why let software decide?
Most payers do not know — and should not need to know — the fee schedule or settlement window of every rail. Delegating the choice to an orchestrator means each payment gets routed intelligently by default, the way a maps app picks a route without you naming every road. It also future-proofs the experience: when a new rail is added, the orchestrator can start using it without anyone changing how they pay.
Reach as a hard constraint
Cost and speed are preferences; reach is a requirement. If a recipient only has a mobile-money identity, a card rail is simply not an option, no matter how cheap. The orchestrator filters to rails that can actually deliver before it optimizes among them. This is why the directory mapping matters so much — it tells the orchestrator which rails are even on the table for a given recipient.
What the payer experiences
From your seat, paying by alias is three taps: choose the recipient, enter an amount, confirm. The rail selection is invisible unless you go looking for it. Your statement will record which rail carried the payment, so you can always see the choice after the fact. And before the send, the usual balance check ensures you can afford it.
Settlement still happens underneath
Choosing a rail is not the end of the story — the payment then clears and settles on that rail, which behaves differently depending on whether it is instant or batch. Newcomers can get oriented with multi-rail settlement explained and the classic clearing vs settlement distinction.
Watch the orchestrator work
When more than one rail could work
Often several rails can reach the same recipient, and that is where the orchestrator earns its keep. Faced with, say, both an instant rail and a cheaper batch rail, it weighs the payment's priorities: is speed essential, or is cost king? A small everyday transfer might favor the cheapest option, while an urgent payout leans toward the fastest. The beauty is that this reasoning happens every time, automatically, so each payment gets a sensible answer without you ever consulting a fee table. It is the same instinct a seasoned treasurer applies by hand, encoded so it runs in milliseconds.
Ultimately the orchestrator exists so that paying someone can be as simple as naming them. All the hard questions — which rails can reach this person, which is cheapest, which is fastest, which is available right now — are answered for you, every time, in the background. You keep the simple experience of paying an alias; the platform absorbs the complexity of choosing well. That division of labor is exactly what a good payments layer should provide.
The best way to see rail selection is to pay the same recipient a few times and inspect which rail each payment used. Open the KibiPay app, look someone up in the directory, and pay their alias. For a guided run, follow the two-minute walkthrough, and browse more on the blog.