An area of increasing focus by both Regulators and Banks is in the area of Misdirected Payments and the need for Payee identification. The newly created UK Trade Association for Payments (Payments UK) has, in its most recent update on its World Class Payments Programme, highlighted that one of the four main areas it will be focussing on is Payee confirmation, in particular, confirmation prior to the payment being made. The reason for this focus is that payments both in the UK and elsewhere are routed solely using identifier codes (in the UK, the Sort Code and Account number), with no reference to the Beneficiary name being used in the routing of the payment to the destination account.
Outside of the Industry, many may wonder why this is the case? When setting up an online payment, writing a cheque or filling in direct debit mandates, you are normally asked for the beneficiary’s name. Well, the answer is not as straightforward as you may first think and, to explain further, it is necessary to go some way back in time to briefly cover the origins of payment routing.
In many respects, there is a strong analogy between the background of payment routing and telephone call routing. In days gone past, there were Telephone Operators in towns or villages who would route telephone calls in their specific area to other numbers elsewhere. People could have the same phone number in different cities given the closed nature of each local network. When telephones became automated, Subscriber Trunk Dialling (STD) codes were introduced so that you first dialled an area code, followed by the number of the person you want (which is why, to this day, if you dial a local number, you do not need to put the STD code in front of it). International Subscriber Dialling (ISD) codes added an additional prefix which then enabled international calls to be directly dialled. To map this analogy to the UK system of payments, the local phone number equates to the Customer Account number assigned by a particular bank, the STD Code to the Bank’s Sort Code and, for some international payments, the ISD would map against the country code at the beginning of the IBAN (International Bank Account Number).
Prior to electronic transfers being introduced, the principal means of transferring value from where a person banked other than the risky transfer of cash or a physical commodity such as gold was by the use of bearer drafts or promissory notes. Via evolving legislation (principally the 1882 Bills of Exchange Act and the 1957 Cheques Act) these evolved into the more recognisable “negotiable instruments” we know today. Processes evolved whereby the instrument could be endorsed and passed through the hands of several beneficiaries thereby avoiding the need for encashment. Local standards continued to develop for their clearing which, for the UK, meant that Sort Codes evolved in the 1960s from the earlier clearing codes which, in conjunction with the Bank Account number of the originator and the beneficiary, meant the payment could be routed. This historical convention then persisted when electronic payment systems were introduced and remains so to this day.
The situation then became further complicated when it came to the routing and delivery of international payments given the proliferation of different account identification mechanisms from country to country. The two principle routing mechanisms subsequently established (and still in use today) effectively enshrined countries’ rights to maintain their own account numbering conventions. International Payments are currently routed either via a combination of the SWIFT Bank Identifier Code (BIC) together with a BBAN (Basic Bank Account Number) or an IBAN. The IBAN also incorporates the BBAN relevant to the specific country in the last 30 characters of its make-up.
As readers glaze over at this point, it is worth highlighting that all of the above have one thing in common. At no point in either the telephony system or the banking system does the name of the customer have any relevance in or to the routing process. You have to know the telephone number of the person you want to call in the same way that you need to know the bank account details of the person you wish to send a payment to. After this point, the analogy begins to break down. For landlines, people can choose whether they wish to have their phone numbers published in directories or not. Interestingly, mobile phone numbers have become more like Bank Account numbers insofar that it is a case of “if I want you to know my number, I shall tell you”.
Sadly, the impact of a “wrong number” written down is worse for a bank account. With a phone, at worst, you will dial a wrong number. If you “dial” the wrong bank account number, the payment will go to the incorrect payee.
That then brings us back full circle to the beginning of what can be done to prevent such mis-directed payments given the onus currently rests with the payment originator to ensure that the identity of whom they believe they are sending funds to is bona-fide.
Some steps have been taken to attempt to limit this risk. Most banks operate modulus checking algorithms which can detect a wrongly entered Bank Account format. Within the UK, Payments UK offers a Sort Code checker which both validates whether a Sort Code is valid or not and displays the name of the Bank and Branch if it is. Elsewhere, there is a similar checking tool for the validity of IBANs. However, no service is available to check whether the person to whom you wish to send a payment is associated with the account and sort code you have been provided with.
A code of best practice for misdirected payments was published in May 2014 by the UK Payments Council (the predecessor to Payments UK), where those Payment Services Providers that subscribe to the code (fifteen as at the date of publication of this post) will take action within two working days of being notified of the misdirected payment as well as outlining the various options open to the customer if the funds cannot be recovered within 20 working days. However, as these steps highlight, the process takes time and may still not result in funds being recovered. This is why there is now a renewed focus on Payee Identity verification.
Payee Identify verification is not straightforward (if it was, it would have been done before now), particularly when attempting to be performed as part of a real-time or batched Payments Process. Names on accounts often do not match the beneficiary name in a transaction. For example, forenames may be different (eg “Jim” vs “James”), joint accounts are often named using the account holders’ initials plus their common surname whereas a payment to one of the account holders is likely to be directed to a single individual, mis-spellings may be present and corporate names are often quite complex and may be different to the trading name the Payer specifies on the payment instruction. These challenges are well understood in the world of Anti-Money Laundering and Sanctions checking, where “fuzzy matching” algorithms and percentage sensitivity settings are present in the specialist software used for these purposes. Such checks will often highlight potential “bad transactions” which then need to be manually checked. Taking the millions of transactions that are processed and settled in the UK and Europe each day, the number of possible rejected payment instructions would be substantial thereby potentially leading to fewer genuine transactions reaching their destination in a timely manner.
It is for that reason that pre-payment validation options are being examined. It is far better for the Payer to establish the bona-fide credentials of the Payee prior to the payment instruction being initiated than have the payment either rejected by mistake or credited to the wrong individual.
That then brings the next key challenge of how such a mechanism could work. To some degree, this is already happening in the world of Mobile Payments. The UK PAYM service launched last year enables the payer to verify the name of the recipient before confirming the payment. The challenge is that PAYM effectively works on a Closed User Group of participating individuals who have signed up to the service. For normal banking transactions, we are dealing with a legacy structure of millions of bank accounts spread across numerous Payment Service Providers with no common participation agreement in place.
One possible approach would be for the industry to build a repository of account name/number information that would be securely accessed as part of the payment generation process. The payee would enter the details of who they wish to pay and, prior to the payment being committed, validation of the payee name would take place against the central repository with potential mis-matches highlighted in a manner that would need to not compromise the security of innocent parties (for example, “the payee is different to the name you have specified”). The Payee would then need to take steps to double check the identity of the payee prior to initiating the payment.
Such steps are a while off. However, given the identity assurance and richer data initiatives that are currently being pursued elsewhere in the UK Payments Industry, it is possible to see other benefits/synergies that could arise from a central repository of names, sort-codes and account numbers. As an immediate example, a separate directory of Sort Codes (The Extended Industry Sort Code Directory) is currently maintained by the industry owned Payment infrastructure operator Vocalink. Should a central repository be created, could all industry routing data be maintained within that infrastructure too?
There is little doubt that some substantial changes will arise on the back of payee identification verification (particularly if it becomes mandated via regulation). The question is, with pro-active and collaborative cross-industry planning, could other benefits arise from this?
As a final thought, the above highlights just some of the challenges that a domestic payee verification process would need to overcome. The challenges increase country by country if cross-border end-beneficiary validation was to be available. That will be the subject of a future post.