Summary / TL:DR
The PSR driven approach to authorised push payment (APP) fraud management that mandates the reimbursement in most cases of up to £415,000, to be shared equally by paying and receiving PSPs, is setting a demanding timeframe with its implementation deadline of 7 October 2024.
And yet the detailed rules are yet to be drafted, and the impacts so potentially far-reaching, that these rules will very likely change.
The last thing a firm wants to invest in is an immobile rigid fortification, like the French Maginot line leading up to World War II, that the tanks of the fraudsters and changing regulations will drive around very quickly.
Lucra is working with firms to devise agile solutions that evolve as the questions are redefined by the fraudsters and regulators alike. Firms that are interested to learn more and/or work with Lucra on these solutions should reach out to me at pdavey@lucra.cc or 07986 680 283.
The need for agility
As the Prussian Field Marshall, Helmuth von Moltke said: “No plan of operations reaches with any certainty beyond the first encounter with the enemy's main force.” Hence a plan of battle needs to be agile.
This principle is especially applicable to the new PSR reimbursement rules. Here, the PSR’s policy will demand a lot of work to translate it into faster payment system (FPS) rules. Once implemented, there is no doubt that a lot of the rules will need to flex. For example:
The restriction of the rules’ scope to Faster Payments, and later CHAPS, potentially leaves major issues unaddressed. The restriction to FPS seems arbitrary in relation to the need to give consumers certainty and confidence. But what happens when the fraud is perpetrated as a subsequent ‘hop’ beyond FPS? If the solution is restricted just to a fraud entirely encompassed within FPS it will be no more satisfactory than the regulatory perimeter regarding LIBOR rate-fixing. There seems to be an important unclarity if an FPS transfer that led to an FX or crypto transfer is in or out. It appears that they may well be out. In which case the solution will be easy to circumvent and not solve the issue for customers.
The potential existential capital hit for some firms. The maximum amount to be reimbursed (up to £415k) and time-window for customers to claim (13 months), poses an existential threat to all PSPs and VASPs that have small amounts of capital (i.e. most).
If hit with a series of high-value frauds, it may lead to the insolvency of these smaller players that deliver much needed innovation and competition.
Furthermore, these limits may also lead to banks increasingly de-banking PSPs and VASPs since they will rightly be perceived as riskier than they are today.
Muti-party complexity. Having multiple parties (banks, APIs, EMIs, PISPs etc) in the payment chain seems to create complexities beyond simple payer and receiver. Many questions come to mind, but in particular:
If there are multiple PSPs at either or both ends is the risk mutualised, or does the claimant get to chase any PSP on a ‘joint and several’ type basis?
Do the PSPs get to argue they are not at risk and others are?
If a PSP fails does the claimant get to go after the solvent party remaining?
Vulnerable customer complexity and unintended consequences:
The consumer standard of caution, the gross negligence test, and the inapplicability for vulnerable customers feels like an area that will have to evolve into more clarity with experience.
The apparent inability for a PSP to protect itself even with tailored and specific warnings could lead to de-banking customers, since banks will deem certain customers as too high-risk, which surely cannot be the intent.
Beneficiary PSPs
A particular issue the reimbursement model introduces is for recipient PSPs.
Today, if the beneficiary (who may be a fraudster, or a witting on unwitting facilitator of the fraud) does not have any funds available (because he/she spent it or transferred it all to another account), the beneficiary PSP will not reimburse the payor.
But under the new model, the recipient PSP will be obliged to cover 50% of the loss even if it has no funds in the recipient’s account. This is problematic given most MSBs and VASPs work on a model based on recycling receipts of funds as close to real time as possible, so very little funds are held available to fund the reimbursement. If not caught in time, this loss position will directly hit the bank’s pockets, as client funds would have already been paid away.
Given a reimbursement requirement of £415,000 per transaction, with a tail of 13 months, the implications of this could be existential for PSPs (and VASPs) that have small amounts of capital, i.e. most of them. Note, if the payor is judged ‘vulnerable’ by the paying PSP even any warnings given would be fruitless, and the reimbursement would be almost automatic. And presumably even if the paying PSP had not judged the customer vulnerable, the regulators (FCA and FOS) could overrule that determination in favour of the customer.
What can be done?
At Lucra we are working with PSPs to confirm what they see as the issue (‘the essay question’) and how our solution can evolve and adapt to help manage that risk. Examples of current thinking include:
Check what payor and payee say the payment is about. Is it the same? This will often reveal investment frauds. Also to ask some binary questions like ‘is the payment intended to be paid into or via any crypto or stablecoin process?’
For the pay-in PSP this may reveal the client is doing something other than they said in the account. E.g. the client says they are selling consumer goods, consulting etc when it is a front for investments, selling crypto etc.
A crucial piece of evidence from the payor bank (and potentially a separate payor PSP) is whether they had judged the payor ‘vulnerable’. This would make the pay-in much riskier for the recipient PSPs since there appears, per the PSR documents, to be nothing that means a vulnerable payor cannot just request the funds back, whatever warnings the payor has been given.
Call to action
Firms that are interested to learn more and/or work with Lucra to help devise agile solutions to these problems please feel free to reach out to me at pdavey@lucra.cc or 07986 680 283.
Peter Davey is Head of Compliance at Lucra. Previously he has worked in senior compliance and risk roles at Dubai Financial Services Authority (DFSA); Earthport (since acquired by Visa); VocaLink (since acquired by MasterCard); First Data (since acquired by Fiserv); Open Banking Implementation Entity (OBIE); and Zumo, a crypto on-off ramp; among others, and is a well-known expert, consultant and advisor in governance, risk and compliance in payments, open banking and crypto.