Confirmation of Payee

Confirmation of Payee improves the user experience by giving the Sender reassurance that they are sending money to the correct account. This is particularly important in cross-border payments, where users may be entering account numbers or aliases in unfamiliar formats, or long IBANs that can be difficult to check character-by-character.
 More importantly, Confirmation of Payee helps to reduce:
1.Payments sent to the wrong account – for example, where the sender has mistyped the account details, but the mistyped details are still a valid account, meaning that the payment goes through, but the payment goes to the wrong recipient. The Account Validation process above will catch any errors where the account does not exist at all, but not errors where the account exists but belongs to the wrong person.

2.Fraud – “Authorised push payment fraud” occurs when the sender unwittingly sends a payment to account details provided by a fraudster. In payment systems where the recipient’s name provided by the sender is not checked against the real name on the account, fraudsters can provide the sender with account numbers for an account which they control, alongside a falsified recipient name. Authorised push payment fraud has been a significant problem in domestic payments, at great cost to victims and banks. It is more important to provide safeguards to prevent Nexus payments being used for authorized push payments fraud, given that it will be more complex for a defrauded sender to reclaim funds from foreign banks, legal and judicial systems than from domestic ones.
Models of Confirmation of Payee
There are broadly three models of Confirmation of Payee:
Nickname: Display a Nickname defined by the Recipient
Many alias schemes allow the user to define a nickname that is shown to potential senders. The recipient could choose to provide their full name, or an abbreviated form (eg FirstName Last Initial), or a completely unrelated (and un guessable) nickname.
When given an alias, the alias conversion service (or the Recipient’s bank) will provide the nickname. This will be shown to the Sender before they click “Send payment”.
In the case of a nickname that is not related to the real name, the Sender may have to ask the Recipient to confirm that this is the correct account.
This model addresses some data protection concerns, because the Recipient chooses what information they’re willing to share (e.g. a real name or an unrelated nickname). However, this model is also the least secure, because the user may be able to edit their nickname to impersonate another person or company. The following two options are preferred.
Real Name: Destination Bank provides the name on account
In this case, the Destination Bank provides the name on account, which is verified by the Destination Bank when the recipient opened the account.
Depending on the data protection rules and privacy agreement between the Destination Bank and the Recipient, the Destination Bank may return either:
The full name in clear text eg Jonathan Smith (preferred)
Part of the name with partial masking eg “Jo****** S****h
Initials eg “J. S.“
Again, the Source Bank would show the name to the Sender before they click “Send payment”.
Comparison: Expected Name is compared to Real Name
This approach, which is used in the UK Confirmation of Payee scheme , gives the user a greater degree of confidence without revealing the actual name on the account:
The Recipient first provides the Sender with their full name as it is recorded on their bank account
The Source Bank asks the Sender to input the full expected name of the recipient.
The Source Bank sends the expected name to the Destination Bank (via Nexus’s Payee API).
The Destination Bank compares the expected name against the true name
The Destination Bank returns the “Match Status’, which could be:
​
A full match: Name provided by sender exactly matches the name on account
Close match: Name is similar to the name on account, but the sender should confirm (example above)
No match
For example, if the expected name is “Jon Smith”, but the name on the account is “Jonathan Smith”, the matching algorithm should be able to define this as a “close match”. But if the name on the account is “Alison Jones”, it would be rejected as “No match”.
How Nexus Handles Confirmation of Payee
The Sender’s app needs to know which CoP model is used in order to set up the screens for the payment setup process in the Sender’s app.
1.The Confirmation of Payee model used is recorded in the Destination IPS’s SLD and synchronised across all Nexus Gateways
2.When the Sender chooses the Destination Country, the Source Bank asks the Source Gateway for the Destination IPS’s SLD. It checks the “ConfirmationOfPayeeType” field to identify the model used.
3.If the Nickname or RealName models are used:
1.the app does not need to request the Recipient name from the Sender. It only requires the alias or account details.
2.The app must show the name as provided by the Destination Bank to the Sender before they confirm the payment
4.If the Comparison Model is used, the Source bank must ask the Sender for the expected Recipient name at the same time as the alias or account number.
1.The app must show the degree of match to the sender and ask them to check or review the name, before they confirm the payment.
Absence of Confirmation of Payee
Some banks or domestic payment schemes will have no Confirmation of Payee process and may be unable to provide the Recipient’s name in response to an alias or account number lookup. This may be due to technical limitations of their systems or concerns about data protection limitations (which may be legally valid or simply overcautious).
In these cases, the payment would need to be sent without the Sender having any confirmation of whether the name on the recipient’s account is even close to the name they expect. Nexus would still allow these payments in order to avoid shutting certain IPSs out of the network, but there should be an expectation that IPSs and their member banks will work towards providing some form of Confirmation of Payee as a priority. There may also be an expectation of higher liability upon the banks (rather than the Sender) for fraudulent payments where Confirmation of Payee is not available.
Confirmation of Payee Options in Order of Preference
In general, Option 2, where the Destination Bank provides the real name on account, offers the most confidence for the Sender. However, this may raise privacy concerns for account holders and may indeed be prohibited by the bank’s terms and conditions or by broader data protection legislation.‌
Option 3 - the matching model – addresses some data protection concerns but has a higher chance of error because the Sender may not know the exact full name of the recipient. For example, they may know the recipient by a nickname, short name or middle name.‌
Example CoP Responses‌
The following table lists the different options in order of preference (in our view). However, national regulatory and legal factors may choose different IPSs to make different choices.
Model
Returns
Example shown to Sender
Notes
Real Name
Full unmasked name
You’re sending funds to Jonathan Michael Smith
Greatest certainty, but also greatest privacy and data protection concerns
Partially masked name
J******n M****l S***h
You’re sending funds to J******n M****l S***h
A good compromise between privacy for the recipient and security for the sender.
​
Initials
J M S
You’re sending funds to J. M. S.
Comparison
Match Status = Exact
You’re sending funds to Jonathan Michael Smith. We’ve checked that this is Jonathan’s account.
Good confirmation, but will fail if user enters eg nickname, abbreviated name or names in wrong order
​
Match Status = Close
The name you provided is similar to the name on the account, but not an exact match.
Creates some uncertainty and doubt for the sender
​
Match Status = None
The recipient’s name you provided doesn’t match the name on the account. Please ask the recipient for the exact name on the account, or proceed at your own risk.
Will require the Sender to communicate with the Recipient again to confirm the exact account name.
User-defined nickname (from alias scheme)
Nickname provided by user
You’re sending funds to JMSmith / J.M.S. / JonnyM
​
Prevention of "Phishing"
Confirmation of Payee does create the possibility that a malicious user could enter multiple account details or aliases (such as randomly selected phone numbers) to identify the names of the owners of those phone numbers. In some cases, this could be useful information for fraudsters.
There are two protections against this:
Many alias schemes have a limit on how many alias lookups can be done by a user without making a payment. For example, a user who enters five different phone numbers as aliases in five minutes and does not make a single payment, may be phishing for account names and would get “timed out” for an increasing period of time. Repeated misuse would lead to that account being locked. Nexus would rely on the safeguards defined in each country, rather than adding its own additional safeguards.

As mentioned above, many alias schemes ask users to define a nickname that will be shown to potential senders; so that users who are concerned about their name being revealed can choose a nickname that is abbreviated or unrelated to the real name.

IPS & Bank Functionality - Previous

Account Validation

Sanctions Screening

Last modified 1yr ago

Export as PDF

Copy link

Outline

Models of Confirmation of Payee

Nickname: Display a Nickname defined by the Recipient

Real Name: Destination Bank provides the name on account

Comparison: Expected Name is compared to Real Name

How Nexus Handles Confirmation of Payee

Confirmation of Payee Options in Order of Preference

Example CoP Responses‌

Prevention of "Phishing"