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.
There are broadly three models of Confirmation of Payee:
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.
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”.
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 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”.
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.
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.
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.
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.