On 18th October 2018 Pay.uk - the re-branded New Payment System Operator - held a launch event and distributed brochures about their new service called Confirmation of Payee, or CoP. We have previously labelled Pay.uk’s approach to CoP as a “CoP-out” and
so it has proved.
CoP is the service that up to now was:
- Meant to solve Authorised Push Payments fraud (“APP fraud”);
- Able to permit a payer to confirm the name on the payee on the beneficiary account every time the payer made a payment to that payee;
- An “overlay service” on top of the New Payments Architecture ("NPA") for the UK's retail payments;
- Involving message exchanges through that architecture and therefore not deployable before NPA was in place;
- The responsibility of Pay.uk to deliver, front-to-back, as CoP was part-and-parcel of the NPA Blueprint that was handed by the Payment Strategy Forum to Pay.uk (in its then guise of New Payment System Operator) in December 2017 for delivery.
The brochure turns many of these assumptions on their head.
There is no timeline or pathway to the service becoming available. Pay.uk states that its own responsibility ends with the “proposition, rules and standards for CoP – providing the foundations PSPs (“Payment Service Providers”) need to start offering the
service to customers from 2019 onwards”. So Pay.uk will deliver some papers and then leave it to others to deliver the service, or not. The service may be available “from 2019 onwards”, so 2022 or 2032 would fit within that wording.
In limiting its role in this way, Pay.uk does not even ensure that there is one infrastructure solution through which two PSPs can exchange the CoP messages and thereby deliver a working service. The current infrastructure provider to the two Pay.uk schemes
that involve Authorised Push Payments – Faster Payments and BACS – is Vocalink, but there is no mention in the brochure, and nor was it mentioned verbally at the Pay.uk launch event, that the contracts with Vocalink will be broadened to include the CoP messaging.
Instead it seems to be envisaged that PSPs individually will engage with software vendors to develop the service themselves and to arrange secure exchanges of messages with other PSPs. It appears that the messages will be exchanged bilaterally between PSPs,
using whatever channel and security, or possibly multilaterally through software vendors acting for several PSPs – but not through one central infrastructure.
Given the propensity for market actors to interpret specifications slightly differently, this approach is a recipe for version proliferation. As there will be no central authority over implementation for market actors to test with, they will presumably test
bilaterally, or not at all. This is a recipe for a service that does not work in the many cases where the payer’s PSP has not directly tested with the payee’s PSP.
The initial focus appears to be to offer CoP only in relation to payments made through the Faster Payments scheme, not the BACS scheme. Pay.uk mentioned verbally that the initial engagement would be with the “Faster Payments participants”, which means the
20 or so PSPs that are direct participants in that scheme, and not the 1,600+ PSPs in the UK who are reachable through it.
Getting the Faster Payments membership on board with CoP might reach a numerical majority of accounts in the UK that are accessible to Faster Payments, but the CoP service is only of value if all accounts in all UK PSPs are reachable. Otherwise the fraudsters
will simply target the PSPs that do not support it.
Consumers should be grateful that, at long last, Faster Payments has been identified as the main completion channel for an APP fraud perpetrated on a private individual.
But that will be little comfort to fraud victims that are businesses.
FICO have recently pointed out how CoP may fail to have the desired effect on APP Fraud in general, and they have also highlighted that the major losers so far have been businesses – and businesses make payments in batches. CoP does not solve for that at
all. One could also add the absence of mention of the CHAPS service. CHAPS is a channel for Authorised Push Payments and usually for ones of large value: it is run by the Bank of England and is not included in the CoP scope at this stage.
There is then the question of the ambition level for the service.
The penultimate paragraph in the Executive Summary of Pay.uk’s brochure contains the phrase “As CoP is a service to mitigate against APP scams..”. This is akin to re-writing yesterday’s weather. CoP’s purpose is to solve the problem, not just to mitigate
it. The Findings and Recommendations section replays the feedback from “consumers and the industry”, namely that “it [CoP] was considered a step in the right direction”. That phrase is used to socialise the reduction in ambition level, but it could equally
well be taken as a criticism: “consumers and the industry” do not think CoP will solve APP fraud, although they feel it will not make it worse. That is not good enough, and FICO’s research indicates that CoP may indeed fail to improve the situation.
If all that was not bad enough, we have two further significant failings.
Firstly, the proposition is not what is represented in the Foreword of Pay.uk’s brochure: “CoP will be a service that customers can utilise to check the name on an account they wish to make a payment to, before they make a final decision to proceed”. In
fact the diagram on page 18 shows that CoP is only available at “Initial payment set-up”, and not when an existing template is re-used.
Secondly an even greater travesty sits behind these words in the Foreword: “under a new ‘Contingent Reimbursement Model’ industry code being introduced in 2019, it is anticipated that any customer who has taken due care and received a positive name match
through CoP will get greater protection from financial loss if they have fallen victim to APP fraud”:
- A customer must have used CoP to enjoy any protection under the ‘Contingent Reimbursement Model’: is this not a restrictive practice?
- The customer must have used CoP AND ‘taken due care’: what does this latter phrase mean?
- The customer must have received a positive name match i.e. the green tick option out of the three possible options. A partial match – the second outcome – will not be good enough, and FICO have pointed out that the partial match could be a very close match;
- The payer’s protection will be ‘greater’ than now, but not absolute. Since the current protection is zero, what is the actual value of ‘greater’?
- The burden of proof will fall on the payer, but, if the process is carried out by mobile device, how is the payer to collect and deliver that proof to their PSP? Their PSP will have the proof in the first instance. How is the payer to have confidence that
the proof the PSP holds and discloses is what actually happened? How will the payer disprove the PSP’s version?
- This situation is the polar opposite of the consumer protection under Payment Services Directive 2 when the payer uses a “payment instrument” like a card: in that case the burden of proof is on the payer’s PSP, who must reimburse the payer if they cannot
prove gross negligence on the payer’s part.
The ‘Contingent Reimbursement Model’ is your archetypal chocolate fireguard.
The CoP service as depicted in Pay.uk’s brochure falls many miles short of what is required to solve the problem of Authorised Push Payment fraud:
- Only individual payments covered, not payments within batches;
- Initially only accounts at Faster Payments participants covered, a subset of all UK PSPs;
- No cover on payments made by CHAPS or BACS;
- Only available when the payment template is initially set up, not when it is re-used;
- No timeline;
- No obligation on all the UK’s PSPs to become reachable;
- No infrastructure solution: Pay.uk will not establish a message pathway;
- Prone to version proliferation;
- No plan for multilateral testing, or testing against an authoritative deployment;
- Payer must have “taken due care”, whatever that means, to enjoy the protection that “it is anticipated” will be available under the ‘Contingent Reimbursement Model’;
- The protection will be ‘greater’ than now, but not absolute;
- The payer must have used CoP, and must have received the “green tick”, not a partial match;
- The burden of proof will be on the payer, but their PSP will possess the proof.
This is a complete row-back by Pay.uk on the basis was upon which it was given charge of this project. It has reduced the CoP ambition level down to “mitigate” APP fraud and to be “a step in the right direction”. That is unacceptable and it is to be hoped
that higher authority steps in to correct these errors.