RTS on SCA: battle for the middle(ware) ground



It's fair to say that no one area of the Payment Services Directive 2 (PSD2) has caused as much controversy as the Regulatory Technical Standard (RTS) around Strong Customer Authentication (SCA), what it is and when it should be applied. Significant lobbying has gone on by incumbent banks, fintechs, the cards industry and vendors to exempt or rule on specific cases where this may apply. To help clarify some of these issues, the European Banking Authority (EBA) published an opinion on 13 June 2018. Regulators such as the FCA who are guided by the EBA are now publishing their own papers on how this might work in practice.

A brief re-cap: PSD2 gave the task to the EBA to develop this and other regulatory technical standards. This RTS went through two public consultations and then the final draft was partially re-written prior to publication by the European Commission. It's therefore confusing, but important, to understand how we got to where we are now, especially for treasurers who are just being made aware of the implications. The reason why this is so crucial is that Open Banking or XS2A is dependent upon SCA to verify that it really is the customer of the ‘real' PSP (the ASPSP) which is accessing their account via a third party. These third parties provide Account Information Services and/or Payment Initiation Services, which means they can both look at transactions and initiate them, on behalf of the accountholder, whether consumer or business.

For treasurers this may be an opportunity to get better visibility on their transactions and the ability to move money, whether between their own accounts or to other beneficiaries. Businesses may also want to help their clients make payment, including information vital for efficient reconciliation and the avoidance of fraud.

There have been several areas of concern, of which the following are a few, which the EBA's opinion helps in some part to clear up:

  • Fintechs believe that banks will put impediments in the way to stop them providing services
  • Traditional payment service providers, including banks, believe their regulatory obligations (PSD2, GDPR, 4MLD) present them with additional risk when using third parties
  • Some newer banks believe that the obligations are too onerous and are looking to minimise their compliance obligations
  • Existing third parties believe they should be allowed to continue to use their ‘screen scraping' solutions
  • Card acquirers and issuers are concerned that additional security measures are designed to push consumers to payment mechanisms other than cards
  • Vendors believe their own solution can solve (or help solve) a number of these problems, if the regulations would only state the requirements clearly

These are just the sort of disagreements which hampered the development of the original EBA draft of the RTS on SCA and, as I have consistently said, the EBA has done a good job of navigating a fair course. In any case, a lack of agreement will merely make life more difficult for treasurers as they cope with varying rules.

In its opinion, the EBA has gone back to basics with some of the interpretation. Strong Customer Authentication relies on two of three types of factor: knowledge, possession and inherence. The knowledge element is described in PSD2 as “something only the payment service user knows” and the EBA interprets this rigorously as meaning that data which could be known by others is not to be treated as an element. This means that the three or four digits of the CVV2 number on the back of payment cards do not constitute an authentication factor and neither does the customer's mother's maiden name. For treasurers, this may be the end of disclosing personal information for a corporate bank to authenticate you by it; this must surely be a good thing.

The European Commission's final draft included a measure that suggested that impediments to open banking would not be compatible with the RTS, giving redirection of authentication as an example. This would mean that any authentication would have to pass through the third party provider or possibly be done at a later time, although that may also be seen as redirection. An example of redirection would be if the bank asked the customer to log in via an online or mobile channel to confirm the action. EBA has firmly stated that redirection alone is not enough to breach the RTS and each case will be considered on its merits. This is important for treasurers and corporate accounts as multiple authentication factors and steps may be required, and requiring all ‘authorisers' to be present when a transaction is initiated may be impossible. Would a treasurer or CFO of a large organisation be prepared to accept a diluting of security measures or additional friction for improved competition?

‘Screen scraping' – the automated processing of web pages designed for humans – was always a red herring. The real issue is who has access to the unsecured authentication credentials. Currently some providers store usernames and passwords so that they can log in repeatedly into a consumer's account, but with Open Banking this could be applied to corporate accounts too. Sharing security details is normally against the customer's agreement with their PSP. In essence it means that it's possible to steal or intercept log-ins for online account management and take over the account. The ‘screen scraping' industry claims never to have caused a loss, but it's not clear that any customer would admit to using a third party – in breach of their banking terms – when suffering such a loss, as they might be personally liable. In the UK, consumers' terms for the major banks now accept that they may share their credentials with ‘trusted' third parties, as the initial stages of UK Open Banking roll out. I am concerned that this sets a precedent, as we have given the consumer insufficiently simple and effective tools with which to work out whether they should trust a third party.

Finally, are fintechs right to be concerned that banks, on which they depend for access to clearing and general banking services, will use their position to put them at a competitive disadvantage? Treasury is one function which is looking with keen interest at these new services, building on bank data to give better or broader services than a single bank could deploy. My view is that traditional banks are desperately trying to make their disparate legacy systems compliant with SCA; taking a single approach for each customer segment across all their channels, including PSD2 APIs, is the simplest method. If it appears clunky to fintechs, that's not because the bank has any particular advantage, it's the same for them too, with an arguably slightly better means of getting technical questions answered.

So I welcome the EBA's opinion: this is the sort of clarity we need. I completely agree that it doesn't meet the needs of all payment system participants, but I think that's impossible. Whether we can make this work is now down not to the legislators and regulators, but to the industries and groups as a whole to make sure it works in practice. Treasurers should hope that common sense and compromise prevail.