Routing Numbers, Sort Codes, and Wallet Addresses
Every payment rail had to answer the same question — how do I name a destination? — and every rail answered it differently. The result is a zoo of address formats: nine-digit US routing numbers, six-digit UK sort codes, E.164 phone numbers, and base58 wallet strings. Understanding their shapes is the first step to hiding them behind a single alias.
US ABA routing numbers
In the US, a bank is identified by a nine-digit ABA routing number, paired with an account number to reach a specific account. The routing number carries a checksum in its last digit, computed from a weighted sum of the others, so many typos are caught instantly. It is a two-part address: institution plus account.
UK sort codes
The UK uses a six-digit sort code, usually written in three pairs, to identify a bank branch, combined with an eight-digit account number. Together they route a Faster Payment or Bacs transfer. The sort code is more granular than a routing number historically because it pointed at a specific branch, a relic of a branch-centric banking era.
| Address | Region | Shape | Checksum |
|---|---|---|---|
| ABA routing | US | 9 digits + account | Yes |
| Sort code | UK | 6 digits + account | Modulus check |
| MSISDN | Global | +E.164 number | Format only |
| Wallet | Solana | base58 public key | Encoding-derived |
MSISDNs as addresses
A phone number is an address that people already memorise. In mobile money and proxy schemes, an MSISDN in E.164 form stands in for an underlying wallet or account. It has no bank-style checksum, so verification of ownership — not arithmetic — is what makes it trustworthy, which is why a confirm step matters so much for phone aliases.
Base58 wallet addresses
On-chain, an account is a public key rendered in an encoding like base58. There is no institution to route through; the address is the account, and the network settles directly. Base58 avoids ambiguous characters, and the encoding itself provides a degree of error detection, but a mistyped wallet address usually just points at a different valid-looking account — which is why copy-paste and QR dominate.
Four formats, one alias
The reason these differences matter is that users should never have to care about them. A directory maps a friendly handle onto whichever of these addresses applies, validates each at registration, and hands the right one to the right rail at send time. That is the core job KibiPay's directory performs: normalise the zoo into a single payable identity.
- Validate each address format on entry, using its native checksum where one exists.
- Store the rail each address implies so routing can reason about it.
- Expose only the friendly alias to payers.
Why this unification pays off
When addresses are unified behind an alias, a sender's mental model collapses to "pick a person". The complexity does not vanish — it moves to the directory, where it can be validated once and reused everywhere. For a fuller treatment of aliases across these formats, see addressing a payment.
Validation is your first defense
Each address format ships with its own built-in error detection, and a directory should use every bit of it. An ABA routing number's checksum, a sort code's modulus check, and base58's encoding rules all catch a meaningful fraction of typos at the moment of entry — long before a payment is ever attempted. E.164 phone numbers lack arithmetic checks, so they lean on strict format validation plus proof-of-ownership instead. Running these checks at registration rather than at send time means a malformed address never becomes a payable alias in the first place. It is far cheaper to reject a bad number in a form than to chase a misdirected payment across a settlement network, and users forgive a clear "that doesn't look right" far more readily than they forgive a lost transfer.
Different rails will always name accounts their own way. The trick is to learn their shapes well enough that your users never have to.