The "Win" Side of the PSD2: Security Opportunities

The following is summary of a presentation held by Ariadne Plaitakis, Head of Regulatory at Mondato, at ENISA's Industry Event on 21 October 2016. You will find further Mondato articles on PSD2 here and here.

The flip-side of regulation and its corollary, compliance obligations, are the business opportunities that are seeded by these new rules. In regards to the revised EU Payment Services Directive (PSD2), the security industry could be a major beneficiary, if products are properly positioned and targeted. This presentation will look at strong customer authentication in particular, and identify certain business opportunities this requirement may trigger.

An Enlarged Ecosystem

To best conceptualize such opportunities, one needs first to understand the key changes that the PSD2 brings about to the payment ecosystem. The Payment Services Directive, otherwise known as PSD1, has provided the legal foundation of an EU-wide single market for payments by introducing specific risk-proportionate regulation of payment providers. The PSD2 widens the scope of entities that are regulated, to include Third Party Payment Providers (TPPs), even if they do not hold funds. These include:

(a) Payment initiation services (PIS), which allow consumers to make payments from their bank accounts directly to the merchant, typically by establishing an electronic payment link between the payer and the online merchant via the payer’s online banking module. (Examples include Sofort in Germany, IDeal in the Netherlands, and Trustly based Sweden, but currently available in 29 countries); and

(b) Account information services (AIS) - the display of online consolidated information on a consumer’s different payment accounts, that typically allows consumers to have a global view on their financial situation and to analyze their spending patterns, expenses, and financial needs in a user-friendly manner. (Examples include First Direct and Money Dashboard in the UK, and Boursorama in France).

In the past, these types of companies operated in a "grey" legal area. Now both of these types of TPPs have new compliance duties of consumer disclosure, transparency and security. But, in exchange, they have also obtained the right to limited access to data in the bank accounts of payers who provide their consent (allows known as "X2 Account"). In particular, PIS providers will be able to receive information from the payer's bank on the availability of funds (a yes/no answer) on the account before initiating the payment (with the explicit consent of the payer), and AIS providers will receive information explicitly consented by the payer, but only to the extent necessary for the service provided to the payer (though in reality, if the service is to provide an aggregate view of all of a payer's bank accounts, this is a significant amount of data).

It should also be noted that the PSD2 widens its geographical reach beyond pure European transactions, imposing a number of obligations, including information/ transparency, on “one-leg” transactions – payments to and from third countries, where one of the payment service providers is located in the EU - as well as transactions in non-EU currencies within the EU.

Payment Model Revolution

Traditionally, online payments were based on a “pull” model of credit card systems - a merchant would “call” for a payment via a card scheme. The PSD2 now allows a merchant to communicate via an open Application Programme Interface (API) either directly with the payer’s bank (if registered as a TPP) or via a third party payment initiator, effectively cutting out the merchant acquiring bank and the card schemes. Thus online payments are moving to a new “push” model (taking money from a customer account via a PIS and then transferring it to a merchant account).

A further innovation is one that can be piloted by banks. Rather than providing limited data access via bilateral APIs, they can decide to create "open APIs" that allow unhindered access to their data while concurrently devising new and innovative API-driven distribution strategies for their own loan, deposit and investments products to reach customers. Such a move would drive up volumes of transactions and possibly render banks more relevant in a post PSD2 world.

Liability Shift

Under the current Card Scheme rules concerning “card not present” transactions, merchants are mainly liable for unauthorised/ fraudulent transactions. The PSD2 introduces a liability shift. As long as there is no payer fraud, this liability shifts to the responsible Payment Service Provider (PSP) i.e. the PSP in the payment chain whose error results in the unauthorized transaction, due to a failure to either apply strong authentication at all, or to apply it effectively. It is the bank that reimburses the payer, but the responsible PSP then compensates other PSPs or intermediaries involved in a transaction (including the bank) for any losses incurred by those other businesses as a result of this failure. Further, it should be noted that the account servicing PSP (bank) must allow the PIS providers (PISPs) and the AIS providers (AISPs) - the TPPs - to rely on the authentication procedures provided by the bank to the user.

Augmented Security Requirements

The PSD2 introduces additional security requirements to PSD1, and considerably tougher rules on verifying the identities of users:

(a) PSPs are now obligated to provide the regulator an annual assessment of operational and security risks;

(b) In the case of a major operational or security incident, PSPs shall notify the home regulator, and if the incident could potentially impact the financial interests of the users, to notify the customers of the relevant security incident and all measures available to them to mitigate the consequences; and

(c) PSPs as well as AISPs (which are not technically PSPs) must guarantee “strong customer authentication” (SCA) where the payer (i) accesses his payment account online; (ii) initiates an electronic payment transaction; or (iii) carries out any action, through a remote channel, which may imply a risk of payment fraud or other abuses.

PSPs must also meet specific security requirements to "protect the confidentiality and integrity of payment service users' personalised security credentials" and where a payer initiates an electronic payment transaction, PSPs must adopt "strong customer authentication that shall include elements dynamically linking the transaction to a specific amount and a specific payee”.

RTS: The Devil is in the Details

The PSD2 delegated many of the functional and technical details to the European Banking Authority (EBA), which issued draft regulatory technical standards (RTS) on strong customer authentication and secure communication this past August. Following the submission by over 200 responses to these draft RTS, a final version is expected to be submitted by the EBA to the Commission by spring 2017. Once the Commission has adopted the RTS (there being no set time line, but 3 - 4 months are to be expected), the PSD2 provides that another 18 months shall pass until the RTS applies to companies. So we can expect the very earliest application date to be end of 2018, and until the RTS are applicable, the EBA’s guidelines on internet payments (published 1 August 2015) apply.

These draft RTS currently specify:

(a) the requirements of the strong customer authentication procedure;

(b) the exemptions to strong customer authentication ex. only accessing information with no sensitive date, or low value transactions (contactless up to 50 euros per transaction and remote payments up to 10 euros per transaction);

(c) the requirements that technical security measures have to comply with, in order to protect the confidentiality and the integrity of the users' personalised security credentials. ex. masking of data, not storing data and cryptographic material in plain text, etc.; and

(d) common and secure requirements for communication for the purpose of authentication, notification and information, as well as for implementation of security measures between account servicing PSPs, PISPs, AISPs, payers and payees. ex. secure bilateral identification, traceable transactions, and use ISO 20022.

RTS: Focus on Strong Customer Authentication

The main clarifications provided by the RTS in regards to Strong Customer Authentication (SCA) include that (i) the SCA relies on authentication codes that are created using two factor authentication, where authentication factors are independent to avoid to mutual compromise; (ii) the SCA requires, in addition, that each authentication code should be valid for only one authentication transaction (and an authentication transaction is any time a user must authenticate himself using SCA); and (iii) the SCA also requires that the authentication process does not expose any information that might compromise authentication data.

The RTS also clarifies that mobile phones can be used for SCA, but imposes some clear restrictions, by stating that authentication procedure must (a) mitigate the risk of a multipurpose device being compromised through the creation of a separated trusted execution environment inside the device; and (b) ensure software or device is not altered.

These clarifications mean that at least one element used to generate the authentication code must be dynamic in order to ensure that there is only one valid authentication code for each authentication transaction and that these codes are different every time. There are, in addition, a list of preferred security features in the RTS, including algorithm specifications, expiration time, and information entropy.

Silver Lining for the Security Industry?

Given all these game-changing provisions, including the push towards strong customer authentication, the business opportunities for the security industry are significant. However, to be best positioned to reap rewards from the PSD2, providers of security solutions should focus on three types of target customers/ business arrangements.

Establishment players will be clearly in the market to update their security solutions. It goes without saying that current payment providers (i.e. banks, but also other Payment Institutions, as designated in PSD1) must review existing security mechanisms and supporting processes against the security standards set out in the PSD2 and the RTS, and ensure full adherence to the requirements for two factor authentication, especially given the liability shift.
Current PSPs will, in addition, need to review how they currently deal with “one-leg” transactions, and determine how they will extend security requirements.

Given the X2 Account provisions, banks, in particular, are likely to embrace flexible systems (and IT architecture) so as to ensure they don’t have to create a separate API from scratch every time a TPP knocks on the door, or if they decide to build open APIs. Banks may also wish to develop their own apps, in case they want to offer a wallet or an aggregator site as the point of entry, and this will open even further opportunities.

The PSD2 will also introduce a whole new crop of potential clients for security solutions – the TPPs - thereby enlarging the market pie. Although they can rely on banks for authentication in regards to payment, TPPs will need to invest in their own security solutions for other parts of the transaction (esp. in regards to data transmission of the payer’s security credentials during enrollment, as well as storage of that data). In all cases, they will need to ensure secure communication with the banks (i.e. identifying themselves, proving consent on part of payer, obtaining confirmation of availability of funds). The use of all common types of devices (such as computers, tablets and mobile phones) for carrying out different payment services will need to be considered, and thus will add complexity and opportunity.

Security providers should also consider collaborating with PSPs and ancillary stake holders on value added applications. The most obvious synergies are with Mobile Network Operators (MNOs), where they can jointly create strong authentication solutions that leverage the mobile phone both as a channel to securely exchange passwords/ authentication codes as well as ensure access to account information, even within the tight guidelines set out in the RTS. Further, the specific relationship between a user and his/ her mobile device could also be a good starting point for a complementary authentication method i.e. the use of an API by MNOs, in the context of a security solution, to identify customers in real time based on the MNO's specific knowledge of the user, his/ her behavior and his/ her device.

Another type of collaboration targets banks, to help them position themselves as guardians of digital identity. For example, in late 2015 it was announced that Dutch banks were collaborating – through the Dutch Payments Association – on a digital identification service to let online customers use their log-in details to access other commercial and government sites. This could be a good strategy for banks looking to reinforce their relevance in the post-PSD2 landscape as well as for security companies wishing to reap the benefits of the additional security requirements.

Last but not least, collaborations with providers of wearable technology, especially those integrating biometric solutions, could be particularly fruitful in order to leverage secure and compliant payment solutions that also improve customers’ experience and diminish cart abandonment, two main challenges that the introduction of strong customer authentication will raise.

Concluding Thoughts...

The payment revolution to be ushered in by PSD2, as well as the resulting increase in competition, will need to be accompanied by strong security solutions. This is clearly a key opportunity for the European security industry, whether in regards to their current clients, potential new clients or future business partners in the more innovative spheres.

Click here to subscribe and receive a weekly Mondato Insight direct to your inbox.