EBA rejects Commission amendments on screen scraping under PSD2

The latest twist in the ongoing row between banks and fintech companies over the future of customer data sharing under the revised Payment Services Directive (PSD2) comes courtesy of the European Banking Authority, which has rejected a proposed amendment to the rules from the European Commission that would have allowed for the continuation of screen scraping.

  63 16 comments

EBA rejects Commission amendments on screen scraping under PSD2

Editorial

This content has been selected, created and edited by the Finextra editorial team based upon its relevance and interest to our community.

Writing in response to the European Commission's (EC) intention to amend the EBA's draft Regulatory Technical Standards (RTS) the EBA voices its distaste for the political meddling.

"The EBA...is of the view that the suggested changes would negatively impact the fine trade-off previously found by the EBA in achieving the various competing objectives of the PSD2," the oversight body writes.

The EBA published its final draft report in February 2017, following 18 months of intensive policy development work and consultation with the different payment market players. Having overcome previous industry objections to the implementation of over-onerous customer authentication standards, the published RTS also dropped an unexpected bomb shell in a commitment to outlaw screen scraping in favour of bank-led access to client data under APIs.

The suggestion caused an outcry among mature fintech startups, who have lobbied hard for a reversal of the decision, claiming that the reforms will provide banks with the means to control what data is shared, putting new entrants at a disadvantage.

The European Commission subsequently intervened on their behalf, asking the EBA not to ban screen scraping outright but to hold it in reverse as a back-up mechanism should bank interfaces fail to function properly.

This has led to a strong push back from banks, who claim that the amendments take no account of the burden of compliance and would jeopardise the privacy of client data, cybersecurity and innovation.

In response, the EBA has come down firmly on the side of the banks: "The EBA is of the view that imposing such a fallback requirement would go beyond the legal mandate given to the EBA under Article 97 PSD2. The EBA is also sceptical about the extent to which the proposed amendment would achieve the desired objectives and efficiently address market concerns. Indeed, the EBA has identified a number of risks that would arise were PSPs to implement the Commission’s proposal."

Instead, the rule-marker has suggested a compromise entailing more rigorous checks and balances on bank APIs alongside a set of minimum performance and availability standards that would release compliant banks from the burden of providing a screen-scraping fall back.

"It is now for the EU Commission to make the final decision on the text of the RTS and to adopt the standards as a delegated Act in the Official Journal of the EU," says the EBA. "During the adoption process, the EU Council and EU Parliament have a scrutiny right. Once the RTS have been published in the Official Journal, they will enter into force the following day and will apply 18 months after that date."

Sponsored [Webinar] Unifying Card Programmes: The cost-reduction imperative

Comments: (16)

Jonathan Williams

Jonathan Williams Principal Consultant at Mk2 Consulting Ltd

Screen scraping is a red herring, but I agree with the EBA. The move to TRA for corporate payments, anonymous payments and removal of references to ISO20022 may be more significant.

Arjeh Van Oijen

Arjeh Van Oijen Head of Product Management at Icon Solutions

Unclarity on the status of the response, that is returned by a bank on a payment initiation API call, is a much bigger issue for TPPs and Fintechs. If this status does not imply a commitment of the bank that the payment is guaranteed, the PSD2 API is not suitable to pay for online and in-store purchases (where it essential to know as a merchant that you are going to receive the money in order to hand over/send goods). Taking into account that one of the key reasons to launch XS2A by EC was to increase the competition on the card brands (besides the cap on interchangre fees). Without a guarantee of payment, it is very unlikely many merchants are going to accept PSD2 enabled payment instruments.

Robert Kiszely

Robert Kiszely Member of the Management Board at Capsys

@Arjeh - I agree that the lack of guarantee will substantially reduce the usability of PSD2 enabled payment services. However, the guarantee is not up to the banks entirely, but the underlying payment services. Even SCT Inst allows exceptions where execution of a payment will be pending (and not accepted neither rejected!). Taking all these into account, I believe that the TPPs should rather make sure they have mechanisms to discover when a payment is completed. But isn’t that the case already? Aren’t current Fintechs using payment services without guarantee upon initiation? I do have a view on the ban of screen-scraping myself – but I find it far more important that the RTS is getting more and more delayed, and that leaves banks and TPPs with a huge uncertainty about what and when to implement.

Charmaine Oak

Charmaine Oak Co-Founder/Director at Shift Thought Ltd

While banks/fintechs may differ, for me it is the customer who is most important. Anything that bypasses customer ability to restrict sharing or adds risk to their data security is of first concern in my view.

Karl Cherry

Karl Cherry Managing Director of Devliery at CheckAlt

Screen scraping is a quick and effective way to create an interface to a legacy system.  It is also difficult to support as it scales.  This is an unfortunate decision in the short term, however, it sets the stage for better and more scalable interfaces in the long run.

Ralf Ohlhausen

Ralf Ohlhausen Executive Advisor at Pay Practice

Banks have numerously repeated that they are not willing to provide a payment execution guarantee, nor any other "risk-mitigation" data for free and PSD2 is not forcing them. However, as Arjeh points out above, payment initiation is useless if merchants cannot get a realtime confirmation.

@Robert: awaiting and checking execution (possbily overnight) or arrival of the funds (next day at the earliest) is not good enough.

@Charmaine: This is not about restricting customers to share anything, but enabling them to share their bank data with licensed and supervised PISPs, so that they can avoid sharing it (bank or card details) with the unlicensed and non-supervised merchants they want to buy from. Therefore, this reduces payment risk and fraud potential significantly. However, I think, first and foremost customers want their purchase ASAP, hence PSD2 PIS must be realtime.

For the past 15 years, this dilemma was resolved by PISPs using direct access via the user interface and then screen scraping to not just initiate the payment automatically, but prior to that retrieve some data, e.g. overdraft allowance, previously declined transactions, etc., to identify the risk of non-execution. Based on that, merchants could be given a sufficiently risk-mitigated, realtime "payment confirmation" - at least so far.

So unless any PISP wants to sign thousands of contracts with all the banks in Europe and pay for their execution guarantee or risk relevant data, there is no other alternative than keeping customer-permitted direct access plus screen scraping allowed. Otherwise all the existing PISPs get killed and PSD2 PIS will follow suit.

Ketharaman Swaminathan

Ketharaman Swaminathan Founder and CEO at GTM360 Marketing Solutions

@RalfOhlhausen:

Re. your comment addressed to @Charmaine, wasn't EBA Clearing's myBank meant to provide the kind of risk-free payment that PISPs are now supposed to provide? When I heard about plans for its launch in 2011, I predicted that it would be a big hit (https://www.finextra.com/blogs/fullblog.aspx?blogid=5453). But I haven't heard much about it since then. 

Robert Kiszely

Robert Kiszely Member of the Management Board at Capsys

@Ralf: I completely agree with you that the lack of guarantee reduces the usability of payment initiation services. Furthermore, I believe that if the banks receive proof that the payment has happened (such as an immediate payment being executed) within a reasonable time, it makes sense to provide that in the response towards the TPP (however, as you pointed out, they have no such obligation, so it's rather their decision). But the problem is, that in some cases the payment will not be executed immediately, and may finally be rejected for several reasons (f.e. AML regulations). Therefore banks cannot guarantee those executions, because they don't receive guarantee from the underlying payment system. In other words, the banks (even those that are happy to comply with the requirement of providing guarantee of execution) cannot provide more information than what they have and receive.

Arjeh Van Oijen

Arjeh Van Oijen Head of Product Management at Icon Solutions

@Robert : I suggest to make a distinction between guaranteeing of payment and crediting of beneficiary account. A card (authorisation) transaction is guaranteed by the debtor bank and in order to do so it carries out the fraud check and debits the customer account/makes a funds reservation before a confirmation is sent back to the merchant. That is most relevant for the merchant to hand over goods to the buyer. The actual funds are received days later (may be annoying, but not business critical). If a payment is not executed because of AML, the merchant needs to take it is not on the AML list. If a merchant is on such a list, it becomes hard to business anyway as you are not supposed to receive any (electronic) payments irrespectively they are PSD2 initiated or not. In case of instant payments and an AML check is applicable (mainly applicable for cross border), this needs to be carried out by the debtor bank before the payment is sent to the instant payment CSM. In case of possible suspect and further investigation is needed, the instant payment needs to be rejected unless resolution can be carried out within the instant payment processing timelines by making use of artificial intelligence (IBM recently announced a solution to make this possible).

Ralf Ohlhausen

Ralf Ohlhausen Executive Advisor at Pay Practice

@Ketharaman: Yes, MyBank exists and is doing well in the two countries they operate in (Italy and Greece). But MyBank is NOT a PISP, nor is iDEAL, giropay, eps or any other fully bank-integrated payment method. They just "assist" the customers, who are redirected to the bank site, and have to "initiate" the payment themselves, i.e. login, browse screens and click buttons there. This redirect without screen scraping is what banks want PISPs to do. The irony is that this then wouldn't need a PSD2 license anymore! PSD2 was designed to make direct access and screen scraping even more secure - not to kill it.

@Robert & Arjeh: Yes, even banks don't know 100% if a payment will go through, but they do give guarantees, e.g. card authorisations, iDEAL, giropay, eps, and take the risk of non-execution themselves or via an insurance, because it is very small once they have send it off. However, before they do so, there are many things that could get in the way - a risk which PISPs could not take without mitigating it themselves as described in my previous comment above. Instant Payments will mute many, but not all of the RTS discussion points and it's some years to go until all banks support it and don't charge a premium for it any more.

The Fintech Alliance just released their comments on the EBA's latest RTS twist, see here: https://futureofeuropeanfintech.com/assets/170704-EBAs-opinion-on-the-European-Commissions-amendments-to-the-RTS.pdf

Charmaine Oak

Charmaine Oak Co-Founder/Director at Shift Thought Ltd

Thanks for the background @RalfOhlhausen @Ketharaman and others. It is good to have experts such as yourselves share so as to move this important decision forward.

Ketharaman Swaminathan

Ketharaman Swaminathan Founder and CEO at GTM360 Marketing Solutions

@RalfOhlhausen:

TY for your reply. If I've understood this correctly, based on a onetime authorization given by the customer, a PISP can log in multiple times to the customer's bank account and initiate multiple payments on behalf of the customer without any customer intervention for each payment. I agree MyBank, iDEAL et al don't do this. But why is screen scraping required? Won't API / token / equivalent suffice for doing this? Hasn't PayPal been doing this already without screen scraping? (To be clear, I'm referring to the mode in which PayPal pulls funds from a bank account, not credit / debit card).

Ralf Ohlhausen

Ralf Ohlhausen Executive Advisor at Pay Practice

@Ketharaman: Screen scraping is required, because 1) TPPs cannot rely their lifelihood on banks providing equally reliable APIs to their competitors than online banking to their customers; and 2) banks refuse to provide execution confirmations or risk-mitigation data via API to PISPs, even if the customer consents; and 3) AISP customers expect non-payment account info as well, which is not covered by PSD2.

I am not aware of any existing PISP storing customer data, hence every payment has to be authenticated and authorised separately. The PSD2 RTS defines new rules, hence this may change a bit, but of course only in return for PISPs getting licensed, i.e. audited and supervised. There are exemptions foreseen from strong customer authentication, but multiple payments must be at a set frequency and fixed amount, e.g. a monthly subscription.

PayPal is a pull payment, i.e. not having the push payment advantages (e.g. no chargeback) that PIS (credit transfer) has for merchants.

Ketharaman Swaminathan

Ketharaman Swaminathan Founder and CEO at GTM360 Marketing Solutions

@RalfOhlhausen:

When I onboarded MINT several years ago, I stopped dead on my tracks when it asked me to handover my NetBanking creds to it. And this was despite its undertaking that it'd use the access for "read only" purposes only i.e. it wouldn't make any transactions on my behalf. If I understand correctly, PISPs are seeking NetBanking creds for the purpose of making transactions OBO consumers. Good luck to PISPs for persuading consumers that their existing payment options are so rotten that their only salvation lies in handing over keys to their kingdom to PISPs. That too, without chargeback protection.

I suspect that PayPal works in PULL mode only when using credit / debit card as funding source and offers chargeback protection to consumers only under these two options. What I do know is that, when it uses PayPal account balance or linked bank account to fund a payment, there's no cashback. I'm no fan of PayPal but it has done rather well for itself by betting its livelihood that bank APIs are fit for purpose and has reached where it has without clamoring for screen scraping.

Ketharaman Swaminathan

Ketharaman Swaminathan Founder and CEO at GTM360 Marketing Solutions

*cashback - I meant "chargeback".

Ralf Ohlhausen

Ralf Ohlhausen Executive Advisor at Pay Practice

You are not the only one worried about disclosing your credentials. I was too before I had some insight into the matter. After 15 years and hundreds of millions of transactions this way there was not one instance of abuse. They get encrypted, are NOT stored and even the tech guys of the TPP can't see them. However, even if the shared (static) credentials were compromised, you need a second factor (one-time password) to authorize a payment. And with PSD2 such SCA is now mandatory and TPPs get audited to adhere to the necessary security standards. Paypal via bank account is a debit (pull), which you can charge back. PIS is a credit transfer, which you can't, but that downside to the consumer is offset by the fact that you don't need to disclose any data to the merchant, taking away the #1 cause of fraud. And to the merchant it's a major advantage for both these aspects!

[New Report] Managing Fraud Risks with Synthetic Data: A Practical Approach for Businesses ServicesFinextra Promoted[New Report] Managing Fraud Risks with Synthetic Data: A Practical Approach for Businesses Services Industry