With the Payment Systems Regulator’s (PSR) Confirmation of Payee (CoP) closing at the end of June (2021) we are pleased to feature a guest blog from Bob Ford.

Bob writes:

I have been involved in a number of discussions with @John Bertrand and @Dr Anthony Evans in recent weeks dissecting the questions from the Payments Systems Regulator in response to their public consultation on Confirmation of Payee (CoP) Phase II.

Whilst @JohnBetrand has looked at CoP from various perspectives as the increased vulnerability for customers of PSP’s who aren’t providing the CoP service, I have been contemplating issues surrounding access to the customer data for those PSP’s that don’t operate 24×7 systems – those who offer Payment Accounts (as could be defined by the Payment Services Directive 2 (PSD2)) but who operate a very concentrated Monday – Friday, 9-5 type operation. There are a number of international banks operating in such a manner as well as smaller building societies. Outside of these times, customers do not expect to make or receive payments hence there is no online access etc. In these situations, payments can be made to the account, but the payment instruction (Faster Payments/SWIFT etc) is held until business opening next working day. Whilst the number of accounts impacted in such situations is low in comparison to the BIG 6 who were mandated by the PSR to implement CoP, the absence of CoP validation provides an opportunity for fraudsters to exploit.

To these non realtime operating PSP’s the potential cost of implementing a CoP type solution that is available 24×7 would be excessive as there would not be a justifiable business case to move into a more online scenario to support CoP.

An opportunity therefore exists for one or more of the major PSP’s that operate realtime 24×7 systems (or even Pay.UK through, say, PayM) to offer an online database that could hold the customer data for the non realtime PSP’s and, through the CoP index, any CoP query would be routed to the online database rather than to the specific PSP. I can envisage that to meet the operating mandate of Pay.UK (or one of their subsidiaries) that the provision of a central database could be singular or multiple where other realtime operating PSP’s offer the CoP access as a competitive service.

The PSP using this service would need to upload their customer dataset of accounts which are designated as Payment Accounts to the appropriate database (either centrally operated or maintained by another PSP). After an initial upload (which might take some time based on account volumes) then the PSP’s data would be updated on a delta basis of updating new, closed and amended account information – likely to take a few seconds to complete.

Subject to this being provided as a service, API’s would need to be defined but these could be centrally defined (by the Pay.UK CoP Team) or by each provider of a hosting database. For these smaller PSP’s there may not be the capability to develop integrated CoP queries to meet their customer requirements therefore this may be an opportunity for hosting PSP’s to offer additional software and API’s to support the client PSP processes

As for charging, some form of charge will need to be levied to support such an initiative but the nature of the market should allow for a freely competitive envoirnment such that the hosting PSP can levy a fee based on account data held as well as CoP queries initiated and processed.