A few months ago I had the pleasure of sharing a platform with Chris Skinner where we both gave the same message in rather different ways: many current core banking systems will struggle to meet the demands of the 21st century. Chris blogged about that session, APIs is all about trains, ships and standards.
The underlying point we were making will be brought sharply into focus by the latest PSD2 SCA requirements. These impose service levels on banks for information access and imply further processing load through fraud level requirements on remote payments. These fraud levels must be hit in order for banks to use frictionless risk based transaction analysis instead of instrusive two factor secure customer authentication.
PSD2 lays out two forms of remote payer initiated payment – card based payment and credit transfers. These have different authentication exemption fraud levels, with the transaction value permitted under the exemption rising as fraud levels reduce. And this has implications for existing bank systems.
Card transactions use existing systems: many of those weren’t originally designed for the online world, but are protected from the full horror of real-time access by buffering and caching systems. Overwhelm those intermediate systems with too many requests and you can push them into fallback mode, with limited access to real account data and into less than full authorisation processes. Which may be problematic, as we shall see.
The new PSD2 credit transfer systems will be built around modern web technology so should be able to handle the peaks and troughs of an on-demand world. But they still face the ultimate limitation of having to access the underlying account data in real time. Under PSD2 any appropriately authorised intermediary is allowed to access a consumer’s account in order to get real-time information up four times a day. That’s before we take into consideration customers requesting additional access to account information or the use of the other PSD2 APIs. Or SEPA instant payments, on the way later this year.
The risk is that core payments systems overloaded by peak transaction volumes may end up doing limited authorisation processing on live data, opening up potential security flaws. In fact, if payments are hitting bank systems from both the card and credit transfer side at the same time then fraud and risk systems may need to be reconfigured. And remember that at the heart of the new requirements is an exemption from two factor authentication if and only if some very difficult fraud rates are achieved.
The definition of fraud rate in the RTS is worth examining in this content (Article 16 4(d):
The overall fraud rate for each type of payment instrument should be calculated as the total value of unauthorised or fraudulent remote transactions, whether the funds have been recovered or not, divided by the total value of all remote transactions for the same type of payment instrument …
So a PSD2 fraud rate is not calculated based on the value of fraudulent transactions. Instead it’s calculated on the basis of the value of unauthorised transactions. But what, exactly, is an “unauthorised” transaction? Comment [1] on respondent feedback defines “authorisation”:
Authorisation refers to a procedure that checks whether or not a customer or PSP has the right to perform a certain action, e.g. to transfer funds or have access to sensitive data
If a bank lets the payment go through without performing full authorisation – as they may do if systems are struggling to cope with demand – then presumably this counts in the fraud statistics, even if the customer doesn’t request a chargeback? Well, it’s not clear but the targeted “fraud rates” to achieve exemption levels are pretty stiff anyway. The fraud rates for e-commerce fraud in the UK in 2015 were running at 0.124%, but that’s for fraud, not including unauthorised transactions. The minimum exemption level for PSD2 remote card payments – €100 – starts at 0.13%.
It should be pointed out that there’s lots of wriggle room for the authorities. The definition of a “remote electronic payment transaction” isn’t nailed down (which seems like a fundamental problem, frankly), and it’s unclear how exemptions work with each other. Remote transactions under €30 are exempt from strong customer authentication but presumably low value fraud counts towards the overall fraud rates. Or maybe not.
However, if we assume consumer behaviour remains constant and they prefer providers that allow frictionless authorisation then any bank that doesn’t hit the fraud rate exemption figures is going to lose business. With a little over 18 months before the RTS comes into force then making sure payments systems can meet these requirements should be a priority for most banks.
We’ll be discussing this further at our Tomorrow’s Transactions Annual Forum. Or follow us here on Tomorrow’s Transactions and yourself added to our mailing list.
