Another hurdle for fraudsters: New ‘Confirmation of Payee’ rules and standards for PSPs
Published on 7th Nov 2018
On 18 October 2018, Pay.UK announced the release of new standards and rules for the confirmation of payee (CoP) service, alongside a set of guidelines that offer insights into how PSPs should meet users’ needs, in terms of language and customer experience.
These form part of a package of industry measures aimed at tackling the rising problem of authorised push payment (APP) fraud, including the Payment Systems Regulator’s ‘contingent reimbursement model’ (the APP Code) which is expected to be implemented in 2019. For more information on the APP Code, see our recent Insight.
New ‘name check’ requirement
Currently, banks use the customer’s sort code and account number to determine where a payment is sent. However, these checks do not protect against the risk that payments are misdirected due to customer error or certain types of APP fraud (such as ‘malicious redirection’ invoice scams where, by posing as a legitimate business known to the customer, payers are convinced to redirect a payment to an account controlled by the fraudster). Unless the sort code or account number are invalid, the payment will be sent by the bank as instructed.
CoP introduces an ‘account name checking service’ whereby banks will also be able to check the name on the account of the person or organisation a customer is paying, and advise the customer (or, where the CoP request has come from another PSP, that PSP) accordingly.
Assuming the account number and sort code match-up, there are three possible outcomes:
- the matching decision is made by the intended recipient’s bank; and
- the decision on whether to proceed with a payment will always rest with the sending customer, irrespective of the outcome of the name check. In the event of a ‘non-match’ the customer should be given clear warnings about the consequences and liability if the payment goes wrong.
Is the CoP documentation publically available?
According to a report carried out by an independent research agency on behalf of Pay.UK (Confirmation of Payee: Understanding consumer and stakeholder perspectives), in order to protect the confidential nature of some of the design and rules, CoP documentation will only be issued to participants in the service. This includes the CoP proposition, rules, operating and technical guide, plus the technical specifications for the CoP requests and responses.
However, a useful summary of the research findings and Pay.UK’s response is set out in the Report, which clarifies certain aspects of the CoP proposition, including around:
- consistency in messaging and functionality;
- provision of a frictionless journey, in particular the need for instant verification;
- liability where a customer chooses to proceed with a payment notwithstanding a negative CoP outcome. For example, it is anticipated that any customer who has taken due care and received a positive name match through CoP will receive greater protection from financial loss under the APP Code;
- meeting the needs of vulnerable groups; and
- ensuring PSPs engage with the customers to raise awareness and educate them on how to get the most out of the CoP service.
The Report further confirms that:
- Pay.UK’s design of the CoP proposition enables PSPs to engage third-party vendors to support them with the delivery of the CoP service, and doesn’t prevent PSPs from developing solutions that support collaborative CoP decision-making using third-party solution providers. Initial market testing undertaken by Pay.UK has identified more than 20 third-party solution providers with an interest in supporting the launch of CoP.
- For the purposes of the General Data Protection Regulation (GDPR), the applicable ‘data controllers’ for the CoP service are the PSPs and therefore the expectation is that each PSP offering the CoP service will undertake their own GDPR ‘legitimate interests assessment’, including where applicable assuring that any data processors they engage, such as third-party providers, comply with the GDPR.
The PSR proposes to further engage with potential participants during the rest of 2018 to support its implementation plans and refine recommendations around common terminology and language.
According to an announcement on 28 September 2018, the PSR also plans to consult during December 2018 on using its regulatory powers to give a General Direction to banks and PSPs to implement CoP. It is expected that the proposed direction would require banks and PSPs that are participants in Faster Payments to:
- be capable of receiving and responding to CoP requests from other PSPs by 1 April 2019; and
- send CoP requests and present responses to their customers by 1 July 2019.
Osborne Clarke comment
While the CoP service proposition is reported to have been generally well received by the consumers and stakeholders that were surveyed, it is by no means a ‘silver bullet’ in the fight against APP fraud. There will still be types of 'malicious payee' fraud that won't be impacted by CoP (for example where a customer is tricked into paying for goods that don’t exist). Nevertheless, CoP is an additional obstacle in the fraudster’s path.
Whether the initiative is successful and accepted by users will depend on a variety of factors, in particular whether the service can be applied consistently by PSPs (both in terms of language and in the matching algorithms that banks will use to check for name matches), and whether a smooth customer journey can be ensured. As acknowledged in the Report’s findings, what will ultimately drive this is a shift in consumer behaviour. People are used to giving out their account number and sort code; they will need to remember to also give the name on the bank account.
The PSR has indicated that the guidance will continue to develop organically in line with users’ experience as CoP is introduced to the market. This will help ensure that CoP evolves in line with its objectives and strikes the right balance between security and providing the consumer with as frictionless a payment journey as possible.