One Alias Per Type Per Person: Why Constraints Matter
It is tempting to let users register as many aliases as they like. More flexibility, more convenience — what could go wrong? Quite a lot, it turns out. A directory that allows unlimited overlapping aliases invites ambiguity, and ambiguity in payments is how money ends up in the wrong place. Constraining each person to one alias per type is a small rule with outsized benefits.
The ambiguity problem
Suppose a person could register three phone numbers as payable aliases. When the routing engine wants to send mobile money, which one wins? Any answer requires extra policy, and every extra policy is a place for bugs and surprises to live. Limiting to one phone, one email, one bank account of record, and so on removes the question entirely.
- One phone alias means "the mobile-money destination" is unambiguous.
- One bank-of-record means payouts have a single, predictable target.
- One handle per person keeps the public identity singular.
Correctness over cleverness
Payments reward boring correctness. A model where each alias type maps to exactly one destination per person is trivial to reason about, easy to validate, and hard to misuse. You can always express richer needs — a business with multiple accounts, for instance — as separate entities rather than as overlapping aliases on one person.
| Model | Routing | Verification |
|---|---|---|
| One alias per type | Deterministic | One thing to prove |
| Many aliases per type | Needs tie-breakers | Combinatorial |
Verification gets simpler
Every alias needs proof of ownership before it is payable. If a person can only hold one phone alias, you verify one number, not a growing list. The verification workflow — and the audit trail behind it — stays linear instead of sprawling. Fewer verified things also means a smaller attack surface for someone trying to attach a destination they do not control.
Disputes and reconciliation
When something goes wrong, investigators ask "where was this supposed to go?" A one-alias-per-type model gives a single, defensible answer for each rail. With overlapping aliases, the answer becomes "it depends", and "it depends" is the enemy of clean reconciliation and quick dispute resolution.
Handling legitimate multiplicity
Real people sometimes do have two bank accounts. The right way to model that is not two competing aliases on one identity — it is an explicit choice the user makes about which account is their payable one, with the option to switch. The constraint does not deny reality; it forces a clear decision instead of an ambiguous pile.
Why KibiPay chose the constraint
KibiPay's directory enforces one alias per type per person precisely because it makes pay-by-alias trustworthy. When the routing engine resolves a handle, it gets an unambiguous destination for each rail, which is what lets it choose confidently. For how those destinations feed routing, revisit aliases and proxy lookups.
Migrating without breaking promises
A one-alias-per-type rule occasionally has to bend to reality: a user genuinely switches banks and wants their bank alias to point somewhere new. The right way to handle this is a deliberate switch, not an accumulation — the old destination is retired and the new one verified and promoted, so there is still exactly one bank alias, just a different one behind it. Recording the change with a timestamp keeps the audit trail intact and lets reconciliation explain any payment that landed on the old account during the transition. The constraint holds; only the target moves. That is how you keep correctness while still letting real life happen, and it is why the rule feels helpful rather than restrictive to the people living under it.
Constraints are not the opposite of good UX — here, the constraint is the good UX, because it guarantees the money goes exactly where everyone expects.