Aliases and Proxy Lookups (MSISDN, Email) in Modern Rails

Nobody wants to type a 34-character IBAN to split a dinner bill. Modern instant rails solve this with aliases — also called proxies — that let you address a payment to a phone number, email, or national ID instead of raw account coordinates. Behind the convenience sits a directory service and a lookup protocol that most users never see. Getting this layer right is what makes instant payments feel effortless, and getting it wrong is a major fraud vector.

What a proxy alias is

An alias is a human-friendly identifier that maps to an underlying account. The most common alias type is the MSISDN — the technical name for a mobile phone number in international format, such as +447700900123. Others include email addresses, national identity numbers, business registration numbers, and randomly generated tokens. India's UPI uses Virtual Payment Addresses like alice@bankname; Australia's PayID supports phone, email, and ABN; Brazil's Pix uses "keys" that can be a phone, email, tax ID (CPF/CNPJ), or a random UUID.

The alias is deliberately decoupled from the account. A user can register several aliases pointing to one account, move an alias to a different bank, or revoke it — without ever exposing the account number to the person paying them.

The alias directory

Every proxy scheme needs a directory: a service that stores alias-to-account mappings and answers lookups. This can be a single central registry, as with Pix's DICT operated by Brazil's central bank, or a distributed model where each participant resolves its own aliases and a central switch routes the query. The directory holds, at minimum, the alias, the account it resolves to, and the institution that owns it.

Directories are sensitive infrastructure. Because an alias reveals that a phone number is linked to a bank account, schemes impose limits on lookups to prevent harvesting — Pix's DICT, for example, rate-limits queries and monitors for scraping. Registration usually requires the alias owner to prove control of the alias (a one-time code to the phone or email) before it can be claimed.

The lookup flow

When a payer enters an alias, the app performs a resolution step before the payment is sent:

• The payer's app sends the alias to the directory or switch.
• The directory returns the resolved account details and, critically, the registered account name.
• The app shows the name back to the payer for confirmation.
• Only after the payer confirms does the actual credit-push transaction go out.

In Mojaloop-based systems this is a distinct party lookup phase using a GET /parties request keyed by an identifier type (such as MSISDN) and value; the responding institution answers with the party's name and details before any quote or transfer. Separating lookup from transfer lets the payer verify who they are paying without moving money first.

Confirmation of payee and fraud

Showing the resolved name is not cosmetic — it is a core anti-fraud control. Confirmation of Payee, mandated in the UK, checks that the name the payer typed matches the name on the beneficiary account and warns on a close or no match. This directly attacks authorized push payment scams and misdirected payments, because the payer sees whose account an alias actually points to. The lesson is that a proxy directory is not just a convenience layer; the name it returns is a safety mechanism, and any scheme that resolves aliases silently without surfacing the name is inviting fraud.

Design considerations

If you are building on a proxy scheme, several things matter: how aliases are verified at registration, how quickly a revoked or ported alias propagates, how lookups are rate-limited against harvesting, and whether the returned name is displayed prominently enough that users actually read it. Aliases also have privacy implications — many schemes let users choose random tokens precisely so they can accept payments without exposing a phone number.

Key takeaways

• An alias (proxy) maps a human-friendly identifier — MSISDN, email, national ID, or random token — to an underlying account.
• A directory (central like Pix DICT, or distributed via a switch) stores and resolves these mappings.
• Lookup is a separate step before payment: resolve the alias, return the registered name, let the payer confirm, then push funds.
• Mojaloop models this as a GET /parties party-lookup phase keyed by identifier type and value.
• Surfacing the resolved name (Confirmation of Payee) is a key defense against misdirected and scam payments.