Proxy Addressing: PIX, UPI, and Mojaloop Lookup
Some of the most successful payment systems of the last decade share one idea: a proxy that stands in for a bank account. Brazil's PIX keys, India's UPI virtual payment addresses, and Mojaloop's Account Lookup Service each let people pay a friendly identifier instead of raw account details. They are national implementations of the same pattern KibiPay generalises into a directory.
PIX keys in Brazil
PIX lets a user register a "key" — a phone number, email, tax ID, or random string — that resolves to their bank account. When someone pays a PIX key, the central directory returns the account behind it and the instant transfer settles. The genius is that the payer never handles account numbers; the key is the whole address.
UPI VPAs in India
UPI uses virtual payment addresses that look like name@bank. The VPA resolves through the UPI network to an underlying account, and payment happens in real time. Like PIX, it decouples the public identity from the private account, and it lets one person hold multiple VPAs across apps while pointing at the same money.
| Scheme | Proxy form | Resolver |
|---|---|---|
| PIX | Phone, email, tax id, random key | Central directory |
| UPI | name@bank VPA | UPI network |
| Mojaloop | MSISDN and other types | Account Lookup Service |
Mojaloop's Account Lookup Service
Mojaloop, the open-source engine behind many mobile-money interoperability projects, formalises this with an Account Lookup Service. A payer's provider asks the ALS "who hosts this MSISDN?" and gets back the recipient's financial service provider. Only then does the actual transfer negotiation begin. It is proxy addressing built as a first-class, standardised step.
The shared pattern
Strip away the branding and all three do the same three things: register a proxy, resolve it to a real account on demand, and keep the underlying details private. The differences are governance and reach — who runs the directory and which accounts it can see — not the core mechanic.
- Register: bind a friendly identifier to an account.
- Resolve: look it up at payment time to get the real destination.
- Protect: never expose the underlying account to the payer.
How a general directory extends the idea
National schemes each cover one country and often one rail. A general directory takes the same proxy pattern and stretches it across rails and borders: one handle can front a mobile-money wallet reachable via Mojaloop, a US bank account over ACH, and a Solana wallet on-chain. KibiPay's directory is that generalisation — the ALS idea, unbounded by a single scheme. For the underlying concepts, see aliases and proxy lookups.
Why it matters for interoperability
Proxy addressing is what makes cross-provider payments feel native. Without it, you are back to copying account numbers between apps. With it, the network absorbs the complexity and the user just names a person. To see how this plugs into rail selection, our page on the rails shows what sits behind each resolved destination.
Governance is the hard part
The mechanics of proxy addressing are well understood; the governance is where schemes differ most. Who is allowed to register a proxy, how disputes over a contested key are resolved, and how quickly a compromised proxy can be revoked are policy questions, not technical ones. National schemes answer them with a central operator and regulation behind it. A cross-rail directory has to answer them too, but across jurisdictions with different rules, which is genuinely harder. The technical resolution step is the easy twenty percent; the trust, consent, and revocation policies are the other eighty. Any directory that wants to be believed has to be as rigorous about governance as it is about lookups, because a proxy nobody can trust to be revoked is a proxy nobody should pay.
PIX, UPI, and Mojaloop proved the pattern at national scale. A directory's job is to carry it everywhere at once.