Confirmation of Payee vs Directory Verification
Two payments questions sound similar but are not. "Does this alias really belong to a verified account?" and "Is this the person I actually mean to pay?" The first is directory verification; the second is confirmation of payee. Both reduce misdirected payments, and a good system uses them together rather than confusing one for the other.
Directory verification: proof of ownership
Directory verification answers whether an alias has been proven to belong to whoever registered it. A phone confirmed by a reply-1 SMS, an email confirmed by a magic link, a bank account confirmed by a micro-deposit — each is a proof that the person controls that destination. Until that proof exists, the alias should not be payable.
- Verification is about control: did the owner prove they hold this destination?
- It gates payability: unverified aliases are not routable.
- It is a property of the directory entry, checked once and reused.
Confirmation of payee: proof of intent
Confirmation of payee (CoP) is different. It checks that the name you expect matches the name on the destination account before you send. Even a perfectly verified alias can be the wrong one — you meant to pay Amara the plumber, not Amara the stranger. CoP surfaces the resolved name so the sender can catch a mistake or a scam before money moves.
| Check | Question answered | When |
|---|---|---|
| Directory verification | Does the owner control this alias? | At registration |
| Confirmation of payee | Is this the person I mean? | At send time |
Why both, not one
Verification without CoP lets you confidently pay the wrong verified person. CoP without verification lets you name-match against a destination nobody has proven they own. Together they cover both failure modes: the destination is genuinely controlled by someone, and that someone is who the sender intended. This layered approach is central to fighting authorised push payment fraud, as we discuss in APP fraud and confirmation of payee.
The role of the resolved name
The most powerful anti-fraud UI in an alias-based system is simply showing the recipient's name at the moment of payment. It turns an abstract handle into a human the sender can recognise or reject. Scams that rely on a payer not noticing a swapped destination fall apart when the confirmation screen says a name the payer does not expect.
Handling mismatches gracefully
A name that does not exactly match should warn, not necessarily block — people use nicknames, initials, and business names. The system's job is to surface the discrepancy clearly and let the sender decide, while logging that they were warned. Hard blocks on close matches frustrate legitimate users; ignoring mismatches enables fraud. The middle path is honest disclosure.
How KibiPay combines them
KibiPay verifies aliases before they are payable and surfaces the resolved payee name at send time. The two checks reinforce each other so that "pay by alias" stays convenient without becoming reckless. For the addressing formats these checks run against, see addressing a payment.
Where the checks live in the flow
Sequencing matters. Directory verification happens once, offline from any particular payment, when an alias is first registered — it is a durable property of the entry. Confirmation of payee happens live, inline, every single time a payment is about to be sent. Putting them in the wrong place breaks both: verify at send time and you have added friction to every payment; name-check only at registration and you have missed the exact moment fraud actually strikes. The clean design is to do the expensive proof-of-ownership rarely and the cheap name-confirmation always. That way the sender sees a reassuring name on every payment without ever waiting on a verification they already completed weeks ago, and the system spends its effort where each check pays off most.
Verify that the alias is owned; confirm that the owner is who you mean. Two questions, two answers, one much safer payment.