TL;DR - screen scraping has provided a range of services to customers which are now under threat. The EBA requires ASPSPs to enable Strong Customer Authentication by the end of the transition period, regardless of whether they have implemented an RTS compliant dedicated interface. The incompatibility of SCA and current ‘customer not present’ screen scraping practice has the potential to damage a range of businesses and their customers, should it not be contingent on a viable alternative in the form of an API platform.
Screen scraping is a process where a third party (TPP) application uses a customer’s (PSU) credentials to access their account for a specific purpose, usually to ‘scrape’ information about transactions. It pre-existed PSD2 and is widely (and largely safely) used for many of the purposes which are pointed to as being potential benefits of open banking APIs, such as account aggregation and transaction analysis. Envestnet Yodlee provides this service across an extremely wide range of ASPSPs, and even places an API layer on top for application integration. One TPP using this methodology currently has in excess of 350k customers using their service on a daily basis.
Preceding 2018, discussion hinged on the practice of credential sharing and whether it should be protected under PSD2. The European Banking Federation (a conglomerate of national banking federations) argued screen scraping to be outdated and present cybersecurity risks, where fintech groups pointed to the millions of customers using services, without significant incident due to fraud or data loss. Key to discussion was the fact that TPP services effectively impersonated customers, and whether this should be allowed to continue.
The regulations presented a quandry. Banks (ASPSPs) were told by art. 115 that services existing prior to 2016 were to be protected by national regulators, and they could not implement measures that would obstruct or block existing services in the event that they were non-compliant. Additionally, ASPSPs were instructed at art. 97 to ensure that Strong Customer Authentication (SCA) was applied every time a customer accessed their payment account. This is expanded at art. 1 of the Regulatory Technical Standards on SCA.
This caused a dilemma - screen scraping services rely on a lack of dynamic, multi-factor authentication, but instead assume knowledge-based authentication that a user can disclose once and a TPP can replay independently thereafter. SCA in the terms required by the RTS requires at least two factors of authentication, whether possession, inherence (biometrics) and knowledge. The introduction to the RTS makes clear the rationale for this at para. 6 - “in particular to mitigate the risk that those elements are uncovered, disclosed to and used by unauthorised parties”. Screen scraping is entirely reliant on the disclosure by the PSU of their credentials to the TPP. SCA in the terms required by the regulation inevitably requires the customer’s presence each time that an account is accessed, due to the nature of the factors of authentication required.
A common misconception in discussions on this subject is that screen scraping becomes illegal at the end of the transition period. The position is more complex, and involves a regulation-endorsed continuation of screen scraping in two circumstances;
Strategic option - ASPSPs are not required to implement a dedicated interface (API platform) by PSD2. They have the option to adapt their existing interface so that it enables TPP access, but this must include client identification using a qualified eIDAS certificate, and SCA of the payment service user - the provisions of the RTS still apply.
Fallback option - should they fail to be granted an exemption, an ASPSP is required to implement “a fallback mechanism that will allow such providers to use the interface that the account servicing payment service provider maintains” (RTS para. 24).
The problem is clear - unattended screen scraping today relies on a PSU sharing fixed serializable credentials with a TPP, so that the latter can continue to access an account in the customer’s absence, and build services on top. Many ASPSPs have implemented credential mechanisms that support this activity explicitly. Screen scraping is protected in two forms by the regulation, but with an additional requirement - SCA - which makes continued access in the customer’s absence impossible. The regulations therefore protect a method of access at the same time as making the most enabling feature of it impossible to continue to use.
API vs Screen Scraping.
Most assume that API driven transactions present a universally better option than screen scraping. API transactions do introduce greater security, granularity of control and traceability than available with the pre-existing service, but with some challenges.
90-day re-authentication - the API framework requires that a customer re-authenticate a consent every 90 days. This challenge does not exist whilst leveraging unattended screen scraping, where the TPP can continue access without customer intervention ad infinitum, until the customer decides to change their credentials. This provision is aimed at reminding the customer that they have an integration with a third party but, as a result of the current design, requires a full SCA journey involving redirect - considerably more friction than having to do nothing at all. Whether this approach protects anyone is debatable. Recent discussion of systems which require user passwords to be changed on a quarterly basis have suggested that this mitigates few risks, and serves to frustrate users with little tangible benefit. It is arguable that a customer accessing a TPP application serves as indication enough of their intention to continue the relationship, and they have options on both TPP application and ASPSP interface to revoke access should they so wish. Application controls have been introduced by some providers (e.g. Microsoft) to allow users to create long, unguessable, secure passwords for the explicit purpose of allowing other applications or TPPs to access resources owned by a consumer, whilst the consumer’s own channels, typically mobile, continue to have the benefit of MFA. These passwords have the benefit of allowing ASPSPs and PSUs to identify which application is accessing a resource.
Trusted Beneficiaries - art. 13 RTS provides that ASPSPs need not apply SCA where a payee is on a list of trusted beneficiaries. This means that an ASPSP has the discretion in its own interface to offer a smoother customer journey than when a TPP using the payment initiation API offers a customer this service. Should they do this (and some already do), screen scraping services can avail of the same functionality, and effect a ‘variable repeating payments’ trust relationship, where they can initiate payments of different amounts without the customer being present. PISPs using API interfaces could also avoid SCA in this circumstance, but it would be at the complete discretion of the ASPSP. Given that they have no access to the list of trusted beneficiaries (unlike screen scrapers) by right, for the purposes of creation or query, it is clear there is a gulf in functionality between what is available on the two methods of access.
Identity Information - screen scrapers use the customer credentials to access account resources, to the effect that there is a guaranteed link between the credentials used for authentication and the account resource. The EBA have at para. 27 of their draft guidelines, ruled out the inclusion of identity information in API payloads, hence making the link between the user of a TPP application and the account holder who authenticates on an ASPSP portal technically impossible.
Refresh Limits - the regulation applies a ‘4 times per 24 hours’ limit to non-customer present access of the APIs. Whilst it isn’t clear at what level (customer / account / resource) this limit is intended, or how a bank can distinguish whether a customer has been using a TPP application, or whether throttling is intended by any banks, this isn’t a problem faced by screen scraping based services.
The functionality of APIs is open to expansion, but this would only likely take place in the long term future, the consequence being that, without a relaxation of the regulation, many services in use today could be removed at the end of the transition period.
SCA is one of many challenges introduced by PSD2. It is clear from the regulation that existing screen-scraping based services have some degree of protection under art. 115 until the end of the transition period, but what then? In the event that ASPSPs implement RTS-compliant, fully functional API platforms, then these will present an option for transition. There is no guarantee that this will take place and, with the current regulatory requirement for ASPSPs to implement SCA, continuation of service looks like a technical impossibility. The idea of a customer performing SCA every time an application scrapes their transactions is unrealistic and will destroy several of the 115 TPPs utilising screen-scraping.
A goal of the regulation is to open ASPSP platforms for consumption by TPPs, and the utopian view of this is a wide range of highly functional API platforms. Given that the ASPSPs in the UK have faced such difficulty implementing against a narrow range of account products and payment types, it seems unlikely that September 2019 will see a complete slew of API platforms with exemptions, and no reliance on direct access as detailed at points 1 and 2 above. In the absence of viable reliance on APIs only, the EBA and NCAs must consult with existing service providers and product vendors, and consider revision of the guidelines so that a compromise/timeline adjustment which protects customers can be achieved.
A similar challenge faced the UK market in 2017 concerning client authentication methods. Whilst it was recognised at the time that MTLS and Private Key presented between options for client authentication, ASPSPs and product vendors were challenged to implement these. The OBIE Security Profile was relaxed for 6 months to allow for client secret based authentication, a relaxation which has now been recalled. During the inception of new technical ecosystems, flexibility in the application of rules should be considered where there is a clear customer benefit. In this case, it is very likely that a hard application of the rules will result in significant customer detriment, due to the loss of current services. This would be at odds with the aims of the regulation, as existing services would be destroyed, and no RTS-compliant API platform might be available as an alternative.