The new Payment Services Directive (PSD2) is having massive impact on the European payment service landscape. Christophe Cauche, technical account manager at identity company Nexus Group, explains how PSD2 affects payment service providers – and how Nexus can help secure all application communications and enable strong customer authentication.
PSD2 is an EU Directive that regulates payment services and payment service providers throughout the European Union (EU) and European Economic Area (EEA). The main goals of the directive, as stated by the European Commission, are to contribute to a more integrated and efficient European payments market, make payments more secure, and protect consumers.
PSD2 affects all payment service providers
The new directive affects all payment service providers active in the European Economic Area, such as:
- Traditional banks.
- Account information service providers (AISPs), which are regulated third-party players (TPPs).
- Payment initiation service providers (PISPs), which also are regulated third-party players.
Each EU country has its own institution – such as Autorité de Contrôle Prudentiel et de Résolution (ACPR) in France – that authorizes regulated third-party players.
I’ll now explain the most important PSD2 concepts and go through how the directive affects the different payment service providers. If you already know all of this, please skip ahead to the sub-headline “How Nexus can help with PSD2 compliance.”
New players aggregate bank accounts
First, let’s have a look at account information service providers. Typical examples of these are applications such as Bankin’ or Linxo, which offer consumers aggregation or consolidation of their bank accounts, presented in dashboard format. AISP tools are often developed by agile startup companies, which are typically more reactive and visionary than traditional banks, and much quicker to release useful and convenient mobile device apps. That said, traditional banks also develop new services to compete with the startups’ new apps: the banks prefer to keep their direct contact with the customers – and they definitely prefer to keep their customers’ business.
Prior to PSD2, bank aggregation tools often connected to the customers’ bank accounts with a technology called screen scraping: the customer gave the application their credentials so that the app could log in to their bank account and download the information. Another approach used by bank aggregation tools was to download Open Financial Exchange (OFX) files.
PSD2 obliges banks to provide APIs
With PSD2, European banks are obliged to share customer data through APIs that allow AISP applications to access the data in a secure and standardized way – but only if they have received mandate from the customers to do so, of course.
This illustration shows the (simplified) interactions:
An authorization framework that’s commonly used for API security – regardless of industry – is OAuth2 (the second version of the OAuth protocol). Using OAuth2, a customer can authorize an account information service provider app such as Bankin’ to connect to all of their bank accounts, without giving their bank account credentials to Bankin’: the customer just authorizes Bankin’ to consume services provided by the banks.
The OAuth2 protocol is not explicitly mentioned by PSD2 or its regulatory technical standards (RTS) since the directive is technology neutral, but the protocol is adopted by important players such as:
- The Open Banking Implementation Entity, which was created by the UK’s Competition and Markets Authority to create software standards and industry guidelines that drive competition and innovation in UK retail banking.
- The Berlin Group, which is a pan-European payments interoperability standards and harmonization initiative with the primary objective of defining open and common scheme- and processor-independent standards in the inter-banking domain.
Online shopping – prior to PSD2
Prior to PSD2, when a customer bought something online with a credit card the (simplified) interactions were these (and they still are in many cases):
- The customer’s card data is presented to the merchant, which is a webshop such as Amazon or Fnac.
- The transaction request is sent to an online payment service provider (PSP) to process the transaction. A PSP (also called payment gateway) is a PCI-DSS compliant company such as Atos in France or Verifone in the US. The PSP uses the card number to contact the acquirer, which is a merchant bank.
- The acquirer (the merchant’s bank) uses the card network or card scheme indicated at payment – such as Visa, Mastercard, or Maestro – to contact the purchaser’s bank.
- The request is relayed to the purchaser’s card issuing bank or a company such as American Express, which approves or rejects the purchase.
Online shopping – with PSD2
With PSD2, payment initiation service providers – such as Sofort in Germany or Swish in Sweden – can initiate payments on behalf of consumers. This means that the customer can authorize a fintech app, their favorite social network, a bank, or their mobile phone operator to pay directly from their bank account.
When a customer buys something online with the help of a payment initiation service provider, the (simplified) interactions are these:
This setup allows merchants to offer more payment options – not just Visa, MasterCard, PayPal, and the other traditional payment services. And the payment initiation service providers can offer the customers additional services, such as choosing which of several bank accounts to charge.
PSD2 obliges banks to provide APIs to payment initiation service providers, and OAuth2 is widely used for API security in this case too.
PSD2 demands common and secure communication
PSD2’s regulatory technical standards define requirements for common and secure communication (CSC), and these demand the use of eIDAS-defined qualified certificates for:
- Website authentication.
- Electronic seals used for communication between financial services players.
The technical specification ETSI TS 119 495 defines a standard for implementing these requirements.
PSD2 demands strong customer authentication
PSD2 also demands operational risks management, incident notification mechanisms, and strong customer authentication (SCA).
The demand for strong customer authentication means that the payment service providers must support strong authentication of the payment service user for operations such as transactions and remote access. The principles and security measures for the application of strong customer authentication are defined in the PSD2’s regulatory technical standards. In summary, the demands are:
- An account must be blocked after five failed authentication attempts.
- If the user has been inactive for five minutes, they should automatically be logged out.
- For a remote transaction, a unique authentication code has to dynamically link the transaction and the person making the payment. The code should only be used once, it should not be derived from a previous code, and it should be impossible to forge.
Since the National Institute of Standards and Technology (NIST) has declared the SMS authentication method deprecated, it should not be used anymore.
PSD2’s regulatory technical standards also define exemptions from the above demands if the risk level is low, such as if the transaction has a value of less than 30 Euros or if the fraud rate is exceedingly low.
How Nexus can help with PSD2 compliance
Nexus can help financial services players with:
- Common and secure communication.
- Strong customer authentication and dynamic linking.
When it comes to enabling common and secure communication, Nexus offers a reliable public key infrastructure (PKI) platform that can help payment service providers comply with the PSD2 demands. The Nexus PKI platform secures all application communications by issuing electronic identities to all components, such as mobile applications, servers, and gateways.
When it comes to enabling strong customer authentication and dynamic linking, Nexus offers a strong authentication and signature solution that’s compatible with the PSD2’s regulatory technical standards. The solution consists of an app that users download to their smartphones and an authentication server. The smartphone app is used for online, out-of-band, and push-based authentication as well as PKI-based signatures that conform with the what you see is what you sign (WYSIWYS) model.
The app can be used with all authentication servers, regardless of vendor, so if you already have an authentication server you are happy with, you can keep using it after deploying a connection with the Nexus app. This connection can be made either through the cloud or via an on-premises software.
This is a screen shot of the Nexus app – it looks pretty sleek, right?
Nexus also offers a software development kit (SDK) that allows customers to integrate two-factor authentication (2FA) and PKI-based signing into their own apps.
The Nexus authentication platform also implements the OAuth2 protocol.
If you want to know more about how we can help you comply with PSD2, please don’t hesitate to reach out to me or one of my colleagues.
Read more about the case how Nexus secures online banking for YES BANK