Verified vs Unverified Aliases: Gating Payability
There is a world of difference between an alias someone typed in and an alias someone proved they own. The first is a claim; the second is evidence. A payments directory that treats them the same will eventually send money to a destination nobody controls. Gating payability on verification is how KibiPay keeps that from happening.
What verification actually proves
Verification is proof of control: the person registering an alias has demonstrated they can act as its owner. For a phone, that is replying to an SMS. For an email, clicking a magic link. For a bank account, confirming a micro-deposit or an equivalent check. Each mechanism proves the registrant holds the destination, not merely that they know its address.
- Phone: reply-1 SMS double opt-in.
- Email: single-use magic-link click.
- Bank: micro-deposit or account confirmation.
The gate: what unverified aliases cannot do
An unverified alias can exist in the directory as a draft — the user has claimed it, but it is not yet live. What it cannot do is receive routed payments. The routing engine simply will not select a destination that has not been verified, so money never flows to an unproven address. The gate is enforced at routing time, which is the last safe checkpoint.
| State | Can hold in directory | Routable |
|---|---|---|
| Unverified | Yes, as a draft | No |
| Verified | Yes | Yes |
Why gate at routing, not at entry
You could refuse to store unverified aliases at all, but that hurts UX — users often add details before completing verification. Storing the claim while withholding payability lets people set up their profile now and finish proving it later, without ever exposing a window where an unproven alias could receive funds. The gate lives where it matters: the moment money would move.
Verification expires and revokes
Ownership is not permanent. Phone numbers get reassigned, emails get abandoned, bank accounts close. A robust system lets verification be revoked and re-checked, so a once-verified alias that changes hands does not keep receiving the original owner's payments. Treating verified status as durable-but-revocable, rather than forever, avoids a whole class of misdirected-payment problems.
Verification and confirmation together
Verification proves the alias is owned; it does not prove the sender means to pay that particular owner. That second question is confirmation of payee, and the two work as a pair — one gates payability, the other confirms intent. We cover the distinction in depth in APP fraud and confirmation of payee.
Why it is worth the friction
Verification adds a step, and friction is a real cost. But the alternative — payable aliases nobody has proven — is far more expensive in misdirected funds, fraud, and lost trust. In KibiPay, the small act of proving an alias is what makes the large convenience of pay-by-alias safe to offer. For how proven aliases feed resolution, see aliases and proxy lookups.
Communicating status to users
A verification gate only works if users understand it. An alias sitting unverified should say so plainly, with an obvious next step to finish proving it, rather than silently failing when someone tries to pay it. Equally, a verified alias should wear its status visibly, so both the owner and anyone paying them can see the destination is proven. The worst outcome is a user who believes they are payable but is not, discovering the gap only when an expected payment never arrives. Clear, honest status — draft, verifying, verified, revoked — turns the gate from a mysterious obstacle into a simple checklist the user can complete at their own pace, which is exactly how a trust boundary should feel.
Claim it freely, prove it once, and only then can the money find you — that is the bargain that keeps an alias directory honest.