Blog article
See all stories »

PSD2 and EBA Update: The Good News and The Bad

On 21st February, Andrea Enria, the Chairperson of the EBA, presented at the Westminster Forum and provided some early insights into the progress of their PSD2 Regulatory Technical Framework (RTS) work. The publication of the PSD2 RTS has been delayed a number of times, so Andrea's comments provide some useful previews of the draft RTS which should be published shortly.

There are two specific areas within the RTS that are addressed by Andrea:

Strong Customer Authentication

Andrea outlined that the EBA is willing to accept three main changes to exemptions to the principle of Strong Customer Authentication (SCA):

  1. To allow “transaction risk analysis” to determine when SCA is applied. This will be linked to predefined levels of fraud rates, so as to provide incentives to strengthen the protection of customers. 
  2. To exempt unattended terminals” for transport or parking fares. 
  3. To increase from 10 to 30 the threshold for remote payment transactions.

The acceptance of a risk based approach to SCA is a major step forward in the implementation of the RTS and has to be welcomed with open arms. It is not clear at this stage who determines the level of risk – the issuer or the merchant, however this proposed approach is a significantly better outcome than a blanket introduction of SCA for all transactions over €10, which was initially feared.

The increase in transaction from €10 to €30 thresholds is also a positive outcome for those operating businesses with low average transaction values (such as digital subscription businesses) and will reduce the payment friction experienced by consumers when buying lower value items.

The EBA have proposed a review clause 18 months after the application date of the RTS in order to ensure that the nature of the exemption is “sufficiently conservative”. This allows for a change in approach if the outcome of the RTS is not as expected.

Common & Secure Communication

The second substantive area addressed by Andrea is Common & Secure Communication (C&SC). This covers the communication between account servicing payment service providers (ASPSPs), account information service providers (AISPs) and payment initiation service providers (PISPs).

Here the EBA wishes to maintain the obligation for the ASPSPs to offer at least one interface for AISPs and PISPs to access payment account information. However, the most important statement is that "the current practice of third party access without identification … referred to as ‘screen scraping’ … will no longer be allowed once the transition period under the PSD2 has elapsed and the RTS applies".

This is a very substantial move and potentially places at risk business practices which are currently used in the Online Banking ePayments environment. There is a significant concern that removing current forms of access may stifle innovation in the European payment market in the short term.

Despite an assurance that the RTS will require “banks to provide the same level of availability and performance as the interface offered to, and used by, their own customers” the opportunities for innovation before these new interfaces are ready are significantly reduced.

Both these topics have been hotly debated in the payments business over the past 6 months. However, until the full draft RTS has been published we will not know what other significant changes may emerge. We await the publication of the full document with bated breath.

The full text version of the presentation can be found here

 

 

10805

Comments: (8)

Tom Hay
Tom Hay - Payment Systems Europe - London 22 February, 2017, 08:10Be the first to give this comment the thumbs up 0 likes

I welcome the banning of screen scraping. It is inherently insecure technically, and it makes phishing attacks more likely by encouraging users to enter banking credentials into non-bank websites. The argument that there will be a problem "before these new interfaces are ready" is spurious. The new interfaces (APIs) have to be available from Jan 2018, and PSD2 Article 109 allows a 6 month transition period thereafter during which existing PSPs can continue screen-scraping while migrating to the new APIs.

The screen-scrapers' business model depends on free-riding on services that banks built and continue to pay for. There is a strong case that AISPs & PISPs should make a fair contribution to the costs of building and maintaining those information and payment services. They should be grateful that the only requirement placed on them is to access those services in a controlled and secure manner.

Ralf Ohlhausen
Ralf Ohlhausen - Pay Practice - Stuttgart 22 February, 2017, 11:21Be the first to give this comment the thumbs up 0 likes

I agree with Chris, the SCA related changes are good news, but banning screen scraping would definitely "stifle innovation" - big time, actually! Security wise, I can't see fundamental differences between direct and indirect access and the same applies to the free-riding argument. For the rest, let me re-post here what I commented earlier today to the article itself:

Driving competition into Financial Services by banning screen-scraping is like promoting electrical cars without allowing them on to public streets. Banks can always be a step ahead if competition is forced to use their (API) back entrance instead of their shiny (online banking) front door. Imagine where telecoms, electricity and railways competition would be today if incumbents had been allowed to keep their access infrastructure exclusively for themselves and lay new wires, powerlines and rail tracks for their competitors to use. How naive can one be?

On the other side, I can easily imagine many banks not wanting to bear the cost and effort of duplicating their access channels and maintaining them to the same performance level.

Allowing both direct and indirect access is a win-win, because banks are not forced into unnecessary API investments, but those who do are motivated to really keep it at par with the direct access offered to their own clients. Or – dare I say – make it even better, because that is the secret of companies who managed to build a whole ecosystem around them!

Tom Hay
Tom Hay - Payment Systems Europe - London 22 February, 2017, 11:39Be the first to give this comment the thumbs up 0 likes

Ralf, I don't follow your logic regarding free riding. If a company invests in new wires, powerlines, and rail tracks, do you think they should then be forced to allow other companies to use them free of charge? What would be the incentive to build them? That's not the way the market works!

Your example of public streets is misleading - streets are funded from the public purse, for the public good. If a private company funds the building of a road from its own pocket, of course it has a right to charge a toll for usage.

Regarding security, when I access Internet Banking direct from my browser, the data (including my security credentials) are encrypted end-to-end. When a screen-scraper is used, it introduces a break in encryption between my browser and the bank, presenting a new attack vector for hackers.

Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune 22 February, 2017, 12:26Be the first to give this comment the thumbs up 0 likes

IMO, fintechs - AISPs and PISPs in EBA parlance - are wasting their time over PSD2. If they focused on delivering a strong value proposition for their alternative products / services - instead of telling customers to skip that $5 coffee - customers will hand them their banking creds without blinking an eyelid.

Innovative Fintechs Don’t Need No PSD2 Regulation

If they're not convinced with this logic, let's see how they'd react to a two-sided regulation where banks - ASPSPs - should get fintechs' customer info. Like I pointed out on Instead Of Open Banking Should Industry Push For Open Everything?, if customers have the right to have their fintechs analyze their banking transaction data, they equally well have the right to have their banks analyze their fintech transaction data.

Naturally, each party must pay for what it accesses from the other party.

Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune 22 February, 2017, 12:29Be the first to give this comment the thumbs up 0 likes

On another note, if screen scraping happens without identification, *whose* screen-scraped info is piped into *my* PFM account?

Ralf Ohlhausen
Ralf Ohlhausen - Pay Practice - Stuttgart 22 February, 2017, 16:39Be the first to give this comment the thumbs up 0 likes

@Tom - rightly or wrongly, PSD2 forces banks to provide XS2A free of charge, no matter if direct or indirect. Forcing them to invest into an additional indirect (API) access possibility by denying the use of their existing direct (online banking) access makes it more costly to them. If they provide a great API, this investment may pay back. If they provide a bad one, it's a lose-lose for both sides of it. I think it is naive to believe that an RTS can force them to provide a "good one". That is impossible to measure and enforce, and naturally, banks will try to minimise their cost of compliance, unless they really see this as an opportunity, which only a few seem to do. The better way is to allow direct access and give banks the choice of a) do nothing and save their money or b) create a fantastic API and ecosystem around them.

A Finextra member
A Finextra member 23 February, 2017, 09:57Be the first to give this comment the thumbs up 0 likes

The Goods and The Bads have been nicely narrated by Chris. The Updates definitely plays a crucial role in psd2 and eba. Thanks for sharing, Chris. 

David Andrzejek
David Andrzejek - Datastax - Mountain View 28 February, 2017, 17:20Be the first to give this comment the thumbs up 0 likes

@Tom, @Ralf, If there's an API and screen scraping for account information, developers will take the API every time.  Screen scraping is horribly brittle and really nobody wants to do is that doesn't have to.  Fine if it is also banned but the ban is superfluous IMO.  

Now, rules aside, charging for API use is in all but a few cases a really bad idea, and will likely kill adoption for any bank that goes that route.  Savvy banks will be thinking about how to build both all their 1st party experiences on their APIs as well as built an ecosystem of 3rd party experiences on those same APIs.  Some of the most successful API programs I know of have figured out how to align business models to even pay developers to use their APIs.  

Now hiring