Where are we now? What do we know about PSD2 work-in-practice after 9 months from being published?
PSD2, the new Payment Services Directive was published at the end of 2015 with the aim to open the payment market to new entrants leveraging the use of digital technologies to provide a wide scale of financial services to the consumers. As we all agree, PSD2 will definitely change the payment and banking landscape due to banks being obliged to open their payment infrastructure to data access requests by eligible 3rd parties.
In this article we are going to focus on the access-to-account (XS2A) obligation which is definitely the base for opening the market.
XS2A (Access-to-Account) – but to which account?
Payment account, and it could also be the credit account and the savings account. What about investments or securities account? What is the real scope of the regulation? Several interpretation we have read.
The Directive says that the data access requests shall only be provided if it comes from an eligible 3rd party and only if the request are for those data, which are needed for the specific service the AISP or PISP provides to the specific consumer. This gives room for different interpretation by the bank and the AISP/PISP.
How the access should be performed? With what SLA?
Preambulum section (93) of the Directive says: .. “regulatory technical standards should be compatible with the different technological solutions available. In order to ensure secure communication between the relevant actors in the context of those services”, EBA should also specify the requirements of common and open standards of communication to be implemented by all account servicing payment service providers that allow for the provision of online payment services. This means that those open standards should ensure the interoperability of different technological communication solutions.”
EBA together with the Open Banking Working Group are responsible for setting the detailed, working rules.
The long-awaited RTS draft (on the requirements of Strong Customer Authentication and Secure Communication ) was published by EBA on August 12, 2016. The RTS gives not enough clarification or may look like a step back from the mission of the Directive.
Banks are to define their own interface
– says the RTS. Does it mean we can say goodbye to pre-defined, interoperable standard for XS2A?
.. “Account servicing payment service providers shall make sure that the technical specification of their communication interface is documented, the documentation made available for free and publicly on their website.” ..
What does it mean? Surely will not help to quickly and effectively open the market.
Though RTS says “proper” APIs shall only be used to access the payment accounts and excludes screen scraping methodology(i.e. access by using the existing internet banking interfaces). But what is “proper API”? The interface “shall use ISO 20022 elements, components or approved message definitions.” Several interfaces use ISO20022 elements.
Eventhough banks are obliged to document and publish their API specs free of charge, still, new entrants shall meet different technical requirements which could cause costs for them and also makes more complex to connect to the banks.
API works as the “contractual agreement” and also the “SLA” for the access – lacking an interoperable standard, or set of standards will result in several different API SLA-s which could result in diversified service quality, service features.
What is the minimum set of data to be accessed? What is the timeframe of the data?
While the draft RTS has no clarification or definition for that, the Open Data Institute and the Open Banking Working Group actively work on categorizing the payment/banking data.
Similarly to the Directive, the RTS only goes for non-discrimination of the new entrants saying that the AISP or PISP shall be provided with “the same information from designated payment accounts and associated payment transactions made available to the payment service user when directly accessing the information online”.
We believe, that the Open Banking Standards will show us the good way to follow. The categorization they use might be a good choice for setting the frame for XS2A data scope as well. Supposing we read those documents right, individual customer transaction data for 25 months backwards from the authorization of the AISP/PISP by the consumer to use its data for service provisioning would be accessible in a read only access mode under PSD2. Besides, KYC or AML reference data on customers are to be accessed only for services used by the consumer on January 1, 2016 or after.
So, if our thoughts are right, and regulation will follow the Open Banking Standars concept, we have some knowledge on the minimum data scope.
Access at what cost?
Access shall be provided free to the AISP/PISP. That means, that the development costs arising in order to be compliant (or move ahead) will be covered by the banks.
Who is responsible for what?
Well, no contract is required between the banks and the 3rd parties. So, we have the APIs – which can be different by banks.
There is no liability shift, so the banks will bear the majority of the risks moneywise.
How should the 3rd party prove its eligibility?
The Directive says that every time the AISP or PISP initiates access it shall prove that it has the legal eligibility to do so. EBA would set the eIDAS certificate as the authentication method between the banks and the new entrant which would be an excellent solution if we could be certain that the eIDAS certification would be ready by the time PSD2 is to be implemented.
Important question since a complicated, lenghty process can decrease the customer experience. Especially, if we look at at it with the customer authorisation and authentication procedures – these are key issues to build a good, customer friendly service.
The Draft RTS didn’t help to clarify this issue. While the Directive wishes to reach to smooth procedures, easy service provisioning and customer experience to decrease the unbanked population throughout Europe, the authentication requirements we think the RTS makes it hard to fulfill. The RTS – at least how it looks like – recommends the use of a bearer token. It means that the customer has to go through the authentication process every time he wants to make a payment – this is far from a seamless service and from high customer experience and being so, will not support reaching the Directive’s mission.
Payment security procedures will be defined by the banks and – according to the Consultation paper – there has to be a contractual agreement – not defined by PSD2 – upon this between the bank and the new entrant. – Again, diversified requirements the new entrants are to meet with.
Who is in-charge regarding the APIs and XS2A?
We know, that EBA is responsible for the EU wide harmonized implementation of PSD2. EBA works closely together with the Open Banking Working Group initiated by the UK HM Treasury. The Working Group published its foundation document on Open banking standards framework and initated to set up a separate entity – the Open Banking Implementation entity – to manage the API standardisation procedure as follows:
- it will issue API provider licences, and will keep a register of the providers and also of the API documents,
- defines the secure process for data access, data sharing
- supervises regulatory compliance and regulatory awareness
- works out the MVP
- defines the scope of transaction data
- works out the standards.
So, we can say that the organizational framework and the basic responsibilities – as to API and access to payment accounts are concerned – are set, or at least the responsible entity has already been set up.
We touched only a few of the issues which are still not clear and as such, do not help the early mover banks or potential TPPs.