All Banks in Europe must be production ready to support PSD2 by September 15th, 2019. This blog post analyses the legal base and the technical implications for the security measures that have evolved around PSD2.
The finance industry has a vested interest in retaining their customer base and they fiercely protect their relationship with their customers. With PSD2, Banks must provide account information and payment initiation functionality to third parties in production in the middle of September 2019. Doing so will allow third parties to aggregate financial information and payment instruction management across multiple Banks on behalf of their customers and to effectively become the first point of contact for these customers. To make matters worse, the costs of maintaining the customer accounts and to execute both account information and payment instruction transactions including all the associated liabilities remain with the Bank and are not compensated by the third parties.
The European Union created the Payment Services Directive in 2015 to force Banks to break their de-facto monopolies on the provisioning of financial services. This should allow smaller but more innovative organisations to participate in this market so that in the end customers will profit from more flexible, more convenient and more innovative financial products. As a target the EU included not only corporate use cases but specifically included consumer use cases and provided special provisions for small transactions.
An argument could be made that Switzerland is not part of the European Union and that Swiss Banks therefore are not directly affected by these laws. While this statement is legally correct, it is also true that many Swiss Banks have offices in EU member states and therefore are forced to comply with PSD2 regulation.
From the legal perspective, PSD2 seems rather simple and straightforward: Banks must provide interfaces for third party providers (TPP in PSD2 speak). To be allowed to access such interfaces, the law demands that the TPP must meet certain criteria and as proof show a certification. This evens the stakes between TPPs and Banks. All TPPs that want to participate in PSD2 must accept liability, meet equity targets and fulfil reporting and auditing requirements.
The technical aspects of PSD2 were not regulated in the law and this left a lot of room for interpretation on how interfaces should be designed that meet the legal requirements. To fill the void, various organisations were founded and some existing ones have adopted the PSD2 interface specification topic. As a result, there is now a number of standards that all are similar, since they are trying to solve the same problem but at the same time, they are all slightly different and therefore incompatible with each other.
To make matters worse, most of the standards do not detail the security aspects of the PSD2 interface and are rather more focused on the business functionality that the interface must provide.
Mutually Authenticated TLS
All PSD2 specifications agree that mutual authentication of all participants and TLS 1.2 encryption is a requirement. It is unclear why the specifications are explicitly specifying TLS 1.2 even though TLS 1.3 is already available, but for the time being this seems like a minor issue that a specification revision can address easily.
The basis for mutual authentication is a new class of qualified certificates that can only be obtained by Banks and TPPs for the purpose of using PSD2 interfaces. These certificates are named Qualified Website Authentication Certificates or QWAC for short. From a security perspective, this creates a mesh of trusted connections between Banks and TPPs where every single connection can be securely authenticated using the qualified certificates that must be used to establish the connections. One of the positive side effects of using X.509 certificates is that the solution is resilient against man in the middle attacks.
Once mutual TLS authentication is achieved, PSD2 specifications are starting to deviate from each other. While some make no specifications on how TPP client registration must be implemented, others adopt dynamic client registration from OIDC specification. This is unfortunate since many specifications agree on the fact that OAuth 2.0 should be used to authorise PSD2 interface access and that the scopes of the OAuth 2.0 access token must define which resource endpoints a TPP is allowed to access.
Inheriting Trust - eIDAS and PSD2
The “Directive (EU) 2015/2366 on payment services in the internal market”, as PSD2 (see PSD2) is officially called, is a law that is defined on the European level and that must be adopted into national law by the member states. As part of the adoption into national law, the member state must establish a National Competent Authority that will certify TPPs that comply with PSD2 regulation and that are therefore authorised to participate in PSD2. In many member states, this role is assigned to the financial market authority so that Banks will receive their banking license from the same authority as TPPs receive their PSD2 certification.
The “Regulation (EU) No 910/2014 on electronic identification and trust services for electronic transactions in the internal market” or eIDAS (eIDAS and eid.as) for short, is an important foundation for establishing trust for PSD2. eIDAS is another law that is defined on the European level and that must be adopted into national law by the member states. It provides regulation for organisational, procedural and technical implementation of different types of certificates and by definition each member state must verify in a certification process that issuers of eIDAS-compliant certificates meet the certification criteria associated with eIDAS.
In the context of PSD2 two types of certificates are required to be used by both banks and trusted third parties (see ETSI TS 119.499). The QWAC or Qualified Website Authentication Certificate is the first and it is used to establish mutual TLS authentication to secure all communication between participants of the PSD2 mesh. Since the eIDAS law is on a European level, the certificates are valid within the EU and communication between organisations from different member states is an integral part of PSD2.
The second certificate is named QSealC or Qualified Seal Certificate. It is used to sign transactions in the PSD2 context. QSealC are not to be confused with QSigC (Qualified Signature Certificates). While they serve a similar purpose, a QSealC is intended to be used by organisations and QSigC are used by natural persons. Thanks to QSealC, it is possible for Banks and TPPs to fully automate processing of transactions without human intervention.
To be issued a QSealC and/or QWAC by a certified issuer, an organisation must provide proof that they have been certified as an actor according to PSD2 regulation. Once the proof is given, not only will the issuer issue the certificate, the certificate will also contain a globally unique identifier for the organisation and the roles this organisation may hold the PSD2 network are encoded into an extension named qcStatement.
With PSD2 the situation of the customer remains mostly unchanged. The customer must have a contract with the Bank and one with the TPP. While this may sound rather cumbersome, one should keep in mind that from a legal perspective, buying a ticket for public transportation is considered a transportation contract or buying some groceries is a sales contract. In essence, the customer experience may remain the same as it is today with normal NFC payment methods. PSD2 primarily affects the relationship between Bank and TPP because it forces all participants to accept each other regardless in which EU member state they have obtained their PSD2 certification or their banking license. A certified TPP is no longer required to contract with providers of payment services they want to support in their business.
With regards to PSD2, the most important role of the customer is the management of consents. The customer must grant consent with the Bank before the Bank is allowed to accept any transactions that a TPP requests on behalf of this customer. To guarantee this, PSD2 law demands that the Bank must either enforce Strong Customer Authentication on consent grants or accept liability and cover all financial losses that a customer incurs from a fraudulent transaction. Strong Customer Authentication or SCA is defined in PSD2 law as multi factor authentication with at least two independent factors (knowledge, possession, behaviour/biometry).
PSD2 differentiates three types of functions that Banks must provide: account information, availability of funds and payment initiation. While this is essentially business functionality, it does have some security implications with regards to consent management. A customer may consent for a TPP to execute account information and availability of funds transactions. Once the initial consent has been granted using SCA, the Bank must store the consent and the TPP may continue to use this consent without further SCA. Expiration of consent is not covered in the law, but current implementations seem to require a renewal of consent typically every 3 to 6 months.
The third function: payment initiation requires for every single transaction an explicit SCA by PSD2 law. As mentioned before, the Bank may avoid enforcing SCA if the Bank accept liability. Of course, modern fraud detection measures in Banking systems will be able to assess if a transaction fits the normal payment transaction patterns of a customer and a risk-based approach can be implemented without conflict with the PSD2 law.
PSD2 and eIDAS are by definition adopted into national law of the EU member states. An organisation (Bank or TPP) that wants to obtain PSD2 conformant licenses, certifications and certificates must do so under the national law of the EU member state where the organisation is incorporated.
As a consequence of the nationalisation of the PSD2 legal base, all organisations that have no offices in any EU member states are excluded from the participation in PSD2. If and when Switzerland can or will adopt eIDAS and PSD2 regulations into Swiss law is unclear. This may be one of the reasons why Swiss Banks are busy discussing a number of alternatives to PSD2 law to provide similar functionality but outside of PSD2 law.
Michael Doujak
Product Manager Application Security
Ergon Informatik AG
