11 December 2017
visit www.avoka.com

EBA rejects Commission amendments on screen scraping under PSD2

30 June 2017  |  23522 views  |  16 euro

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.

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."

Comments: (16)

Jonathan Williams
Jonathan Williams - Mk2 Consulting Ltd - Rugby | 30 June, 2017, 10:41

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.

2 thumb ups! 2 thumb ups! (Log in to thumb up)
Arjeh Van Oijen
Arjeh Van Oijen - IBM GBS - Amsterdam | 30 June, 2017, 22:20

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.

3 thumb ups! 3 thumb ups! (Log in to thumb up)
Robert Kiszely
Robert Kiszely - Capsys - Budapest | 02 July, 2017, 20:36

@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.

1 thumb up! 1 thumb up! (Log in to thumb up)
Charmaine Oak
Charmaine Oak - Shift Thought Ltd - Bristol | 02 July, 2017, 22:11

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.

5 thumb ups! 5 thumb ups! (Log in to thumb up)
Karl Cherry
Karl Cherry - CU Wallet - Pittsburgh | 03 July, 2017, 21:22

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.

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Ralf Ohlhausen
Ralf Ohlhausen - PPRO Financial Ltd - London | 04 July, 2017, 14:28

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.

2 thumb ups! 2 thumb ups! (Log in to thumb up)
Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune | 04 July, 2017, 19:06

@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. 

1 thumb up! 1 thumb up! (Log in to thumb up)
Robert Kiszely
Robert Kiszely - Capsys - Budapest | 04 July, 2017, 21:02

@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.

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Arjeh Van Oijen
Arjeh Van Oijen - IBM GBS - Amsterdam | 05 July, 2017, 09:29

@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).

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Ralf Ohlhausen
Ralf Ohlhausen - PPRO Financial Ltd - London | 05 July, 2017, 13:02

@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

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Charmaine Oak
Charmaine Oak - Shift Thought Ltd - Bristol | 05 July, 2017, 14:04

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.

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune | 05 July, 2017, 15:35

@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).

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Ralf Ohlhausen
Ralf Ohlhausen - PPRO Financial Ltd - London | 05 July, 2017, 16:53

@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.

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune | 05 July, 2017, 19:06

@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.

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune | 05 July, 2017, 19:07

*cashback - I meant "chargeback".

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Ralf Ohlhausen
Ralf Ohlhausen - PPRO Financial Ltd - London | 05 July, 2017, 20:03 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!
Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Comment on this story (membership required)

Finextra news in your inbox

For Finextra's free daily newsletter, breaking news flashes and weekly jobs board: sign up now

Related stories

Berlin Group to publish single API standard for PSD2

Berlin Group to publish single API standard for PSD2

13 June 2017  |  16905 views  |  0 comments | 29 tweets | 62 linkedin
European Commission calls on EBA to rethink screen scraping ban

European Commission calls on EBA to rethink screen scraping ban

22 May 2017  |  7496 views  |  0 comments | 17 tweets | 21 linkedin
European banks lobby Commission to push ahead with screen scraping ban

European banks lobby Commission to push ahead with screen scraping ban

16 May 2017  |  11437 views  |  6 comments | 29 tweets | 36 linkedin
Fintech coalition formed to fight EBA plans to outlaw screen scraping

Fintech coalition formed to fight EBA plans to outlaw screen scraping

05 May 2017  |  10805 views  |  5 comments | 30 tweets | 23 linkedin
EBA to relax controversial PSD2 authentication rules

EBA to relax controversial PSD2 authentication rules

21 February 2017  |  21594 views  |  8 comments | 56 tweets | 77 linkedin
EBA bends under weight of PSD2 mandates

EBA bends under weight of PSD2 mandates

07 December 2016  |  15468 views  |  2 comments | 39 tweets | 55 linkedin

Related company news

 

Related blogs

Create a blog about this story (membership required)
visit www.solutions.lexisnexis.comvisit www.response.ncr.comvisit www.atos.net

Who is commenting?

Top topics

Most viewed Most shared
Revolut lets customers buy Bitcoin, Litecoin and EthereumRevolut lets customers buy Bitcoin, Liteco...
18400 views comments | 26 tweets | 22 linkedin
Saxo Bank's 'Outrageous Prediction': Bitcoin to peak at $60k next year before spectacular crashSaxo Bank's 'Outrageous Prediction': Bitco...
11319 views comments | 7 tweets | 7 linkedin
Deutsche Bank paper hails 'huge' blockchain potentialDeutsche Bank paper hails 'huge' blockchai...
7624 views comments | 14 tweets | 21 linkedin
Santander UK poaches Barclays innovation chief Michael HarteSantander UK poaches Barclays innovation c...
6599 views comments | 8 tweets | 17 linkedin
Barclays, First Direct and Nationwide join FCA sandbox cohortBarclays, First Direct and Nationwide join...
6007 views comments | 5 tweets | 12 linkedin

Featured job

Find your next job