Banks not ready for 'confirmation of payee' service

Confirmation of Payee might help reduce APP fraud, as long as nobody tells the fraudsters exactly how it's going to work or how long they've got to adjust their MO to get around it......

There is a statement above that the 'technology has now been enabled'. What technology and where has this been enabled? As per my understanding, this service will be provided through a direct interaction between the banks so the technology will be ready only when any bank is ready.

I know bells and whistles can take time but I'd argue that the core functionality for CoP must be ready for a long time. Let's take the most rudimentary form of CoP: Barclays Customer enters Account # & Sort Code of Beneficiary in HSBC; Barclays CoP system pings HSBC's CoP system with these two pieces of data and asks for Accountholder Name. Ever since HSBC implemented a core system, which is probably decades ago, HSBC knows the answer to Barclays' question, and can give it to Barclays if it wished to; Barclays compares the name with the one entered by its Customer; either it matches or does not match.

So, the "perfect match" option of CoP should be ready to go already. Unless I'm missing something, I'm not sure what's holding up a rudimentary rollout of CoP for a year.

Completely agree with Ketharaman Swaminathan comments.  As each bank must already have the customers name(s) associated with their account and sot code details this should be fairly straightforward.

As an example (having been responsible for core banking implementation programmes), an Account Verification Service (AVS) - whereby beneficiary names are displayed to a user wishing to undertake an electronic transfer - has been in operation in Nigeria for at least 10 years now via the NIBSS switch.

Other than merely not being a priority, why is this not already in place.

@MichaelHarte: 

Nice to know that mine is not the only voice in the wilderness on this issue:)

My earlier comment was based on the assumption that CoP in UK would follow a P2P architecture i.e. it will entail direct communication between Sender Bank and Receiver Bank. Your reference to NIBSS switch in Nigeria tells me that there could be an alternative architecture in the form of hub-and-spoke. I'm not sure if UK CoP envisages P2P or H&S architecture.

On a side note, obviously-biased comments can provoke you to dig more deeply. That's what happened with me when I saw the following comment on LinkedIn:

QUOTE

My suspicion is that this is another service which exposes how poorly some of the banks have stored this data and the issue is being able to successfully retrieve it in a format in which it can be validated against.

ENDQUOTE

I replied as follows:

QUOTE

I don't think any bank could've survived this long by storing such basic data "poorly". IMO, the issue is proprietary format in which the data is stored, according to the core system used at each bank. While it's fit for purpose for a bank's internal use, it's not portable between multiple banks. So the real issue is for Bank A to hand over the account holder name to Bank B in an industry-standard format that's machine readable by Bank B's proprietary system in realtime while the customer is trying to initiate the payment. I won't blame banks for their inability to do this. I know a leading auto company that stores customer names so differently between its ERP, CRM, Service and Billing systems that it engaged my once-employer to carry out an MDM project to harmonize them. No way it could exchange name with another auto company, even in batch mode. And it won't need to because Auto companies don't need to share customer info with their competitors. Nor do companies in any other industry. Can Walmart ask Amazon to reveal name of Amazon customer? What banks are being asked to do under CoP - and Open Banking for that matter - is unparalelled in any other industry and for that, I'll cut banks some slack.

ENDQUOTE

I know this pov is not totally aligned with the one I'd expressed in my previous comment but I'm okay with letting the chips fall where they may...

A super easy way for the recipient bank to stop payments going to the wrong account is to match the recipient name themselves - they don't need to collaborate to do this and can cut out 90% of the errors.

There's no compelling reason for the recipient bank to stop payments going to the wrong account. In fact, the way things are, there's nothing like "wrong account". Sender Banks make it clear that beneficiary name is not considered anywhere. So payment will go to stated account as long as the stated account exists in the recipient bank's CIF. That's why we're where we are and a CoP service is required in the first place.  

You're absolutely right - no compelling reason. This is one of the reasons challengers will eventually win. They are building solutions for the customer. 

In Fintech Shouldn’t Stop Chanting The Disruption Mantra, I highlighted why it's naive to expect fintechs like challenger banks to improve CX. Ditto for solutions because it takes two to tango.

Challenger Bank can do nothing by itself if Sender Bank and / or Scheme truncates the Bene Name (per my experience in UK) or strips it out altogether (as it happens with IMPS in India) because of limitations in bank system's field length or scheme's ISO8587 messaging standard. 

Collaboration is mandatory. 

Exposing and consuming the API that can validate the payee name,the challenge would that all the banks have to have the capability and be ready to expose the APIs and the format in which the data is stored. Is it impossible, no, but then the implementation in itself will take its time see the daylight. The other way probably would be blockchain where one bank can share/ trust the data with the other, again all the banks participating in this would be a challenge. All the banks participating in itself is a challenge to implement the validation