To find out more about the upcoming revised Payment Services Directive (‘PSD2’) and its implications particularly in relation to the payments landscape and cyber security, we speak with Cognosec’s Business Analysts, George Messum.
Q. Could you first of all provide some background as to why PSD2 was deemed necessary in the first place, how it came about, and the goals of the legislation?
A. The original Payment Services Directive (known as ‘Directive 2007/64/EC’ or ‘PSD’)
was adopted in 2007 and its aim was to increase uniformity in payments throughout the EU and EEA, and increase competition while protecting consumers.
Over the years, there have been tremendous technological advancements in payments and there was the feeling that the scope of the original PSD was not sufficient to encompass all of the relevant changes and entities. As just one example, PSD makes no explicit mention of acquirers, and this led to confusion as to whether or not these entities come within its scope, and therefore whether the obligations of PSD apply to them. PSD2 (‘Directive 2015/2366’ or ‘PSD2’) explicitly mentions acquirers, as well as other new providers.
Q. Could you explain what PSD2 itself is, its aims and scope?
A. PSD2 had its ‘entry into force’ at the EU level, on 12th January 2016. As it is a directive and not a regulation, EU member states (including the UK) were required to transpose it into national law by 13th January 2018. The UK has transposed PSD2 into its national legislation via the Payment Services Regulations 2017 (PSRs 2017).
The aim of PSD2 is broadly similar to the original PSD, namely to integrate payments services throughout the EU and respond to the rapid advancements that are occurring across the payments industry, with the hope that the facilitation of competition will result in better service for customers by providing more choice and thereby driving down cost, as well as providing greater security through the introduction of what are known as Regulatory Technical Standards (RTS).
In the European Commission’s (EC) own words, the aim of PSD2 is to provide ‘more and better choice in the EU retail payment market. At the same time, it will introduce higher security standards for online payments.’
Q. Who are the ‘new providers’ to which you refer above?
One of the ways PSD2 will encourage increased competition is by licensing as Payment Institutions, a new class of payment service provider:
- Payment Initiation Service Providers (PISPs); and
- Account Information Service Providers (AISPs), collectively referred to as Third-Party Providers (TPPs).
A. PISP is defined in a draft paper published by HM Treasury as ‘a service to initiate a payment order at the request of the payment service user with respect to a payment account held at another payment service provider’.
The advantage of PISPs is that they allow users to make payments without the use of credit or debit cards, with lower transaction fees for merchants and immediate confirmation that funds are on their way. It is important to note that the PISP does not at any time handle actual funds.
A key disadvantage is that, unlike conventional credit and debit card payments, there is no automatic chargeback right: if a user initiates a payment and the merchant subsequently fails to deliver a good/service, the user would have to write to his/her bank and attempt to reverse the transaction that way. The burden of proof in cases of alleged fraud would lie with the user, creating uncertainty of outcome.
An AISP provides a user with consolidated view of his/her payment accounts with various providers, in order to give an overview of availability of funds, track spending habits etc.
A potential disadvantage with both PISPs and AISPs is the fact that both of these TPPs make use of a bank’s online environment and could therefore be subject to downtime not directly connected to the TPP itself.
Do we have an idea of what the uptake will be of these entities in the aftermath of PSD2?
By way of an example, iDEAL in the Netherlands is a PISP, and is responsible for the majority of online payment transactions in the Netherlands: PISPs constitute 55% of online payments in that country: there is also Sofort in Germany and Trustly in the Scandinavian region, both large service providers.
It remains to be seen whether this growth will be translated throughout Europe and particularly the UK, but these entities certainly look set to become a significant component of the payments landscape throughout Europe.
What is the significance from a cyber security perspective of these entities becoming licenced as providers under PSD2?
This is essentially down to the fact that PSD2 requires banks to allow these TPPs access to its users’ accounts. This has obvious security implications for all concerned parties.
TPPs will need access in order to allow them to perform their respective functions: for a PISP to initiate a payment, or for an AISP to provide a consolidated statement of funds, they will require information on the user’s funds.
The way that this will happen is that the TPPs will be able to utilise the banks’ infrastructures to initiate payments or provide account information services: this is known as ‘Access to Account (XS2A)’.
How this will happen in a practical sense, will be covered by the aforementioned RTS.
Can you explain what the RTS are and their proposed implementation?
The RTS govern the technical implementation aspects of PSD2: this is the area that is highly relevant to Cognosec’s services, particularly in relation to what we can offer in the areas of assurance and advisory services.
The aim of the RTS is to provide a set of technical requirements with which payment service providers (PSPs) must comply in order to operate under PSD2. The draft was produced by the European Banking Authority (EBA) and will be adopted by the European Commission, whence it will become law.
To become official, the RTS must be published in the Official Journal of the European Union (expected to be January/February 2018): the RTS will then go into effect 18 months after adoption, so around September 2019: in other words, well over a year after the transposition of PSD2 into national law.
Under the RTS, banks will be required offer an interface (via an API) for TPPs, that allows communication exchanges to take place: and these interfaces should use ISO 20022 elements.
The way TPPs worked before was by screen scraping. Screen scraping in this context is where the TPP accesses a customer’s data via the customer interface and using the customer’s security information (i.e. password). Screen scraping allows the TPP to access customer data without direct authorisation of the bank.
There has been a divergence of opinion between the European Banking Authority (EBA) and the European Commission (EC) as to whether to allow screen scraping by TPPs as a fall-back provision in case the bank’s API-based interface was unavailable: The TPPs are in favour, whereas the banks are against, for obvious reasons.
The EC has tried to compromise by stating that no fall-back screen-scraping provision will be necessary provided that the banks’ API-based communication interface is adequate: the question of adequacy will be decided by a new industry body, comprising both TPPs and banks.
The API standards are yet to be finalised. It is in an uncertain regulatory and technical climate such as this, particularly in light of the timelines for implementation and the potential consequences of a data breach of either a bank or TPP, that Cognosec is able to assist, by providing the technical and advisory resources to ensure that all parties are protected. Any technical and security framework that is built will need to be rigorously tested, and the area of penetration testing within a financial services context is one in which Cognosec possesses significant expertise.
We have a team of highly experienced technical personnel who possess experience in the banking industry, as well as the requisite accreditations and knowledge of ISO standards to ensure that both banks and TPPs will be prepared and protected to the greatest possible extent.
Are there any specific issues around account access where Cognosec could help?
The primary one is the issue of Strong Customer Authentication (SCA). SCA will form the basis for access to a customer’s payment account and for paying online. Under this, a user will have to prove his/her identity by providing at least 2 of the following 3 elements:
- Something they know (e.g. A password);
- Something they are (e.g. Biometric scan);
- Something they own (e.g. Mobile phone).
Although countries such as the Netherlands and Sweden already apply SCA for remote payment transactions, others only do so on a voluntary basis. As part of creating a uniform single market for payments, SCA will be required throughout the EEA as part of PSD2, but this will require the implementation of technical facets as well as ensuring that the inputted information does not fall into the wrong hands. Cognosec are highly experienced in applying industry best practices when it comes to matters such as multi-factor authentication and we recognise that this will be essential when financial institutions are considering the requirements for compliance under this element of PSD2.
It will be up to the banks to not only implement the measures but to audit these measures to ensure robustness: Cognosec are able to provide auditing services in such instances and have a breach response team ready in case of any data breach.
On which parties does the burden for technical compliance lie and what are the security implications of this?
Technically, the burden lies on all parties (i.e. banks and TPPs).
By far the biggest question-mark raised by PSD2 from a cyber security perspective, is the security issue of banks allowing a third-party access to a user’s account. Banks have unsurprisingly expressed misgivings at the idea of allowing third parties, many of which will be new entities, access to their users’ accounts.
In addition to the costs required to accommodate the legislation from a technical perspective, there are also the potential problems around granting a third party, that is unknown to the bank and has not gone through its AML/KYC procedures, accessing its users’ accounts, and the potential liability if a PISP or an AISP is hacked.
The EC response has been that TPPs will be licensed PSPs and as such will be required to conform to stringent security requirements in order to maintain their status and these should alleviate concerns around security. TPPs will be required to meet capital requirements and carry professional indemnity insurance. In addition, they will be subject to the AML obligations of a regulated entity.
There is also the commercial issue that has made banks uneasy, namely that by allowing PISPs and AISPs access to their users’ accounts, it is providing sensitive information to what are essentially competitors.
There is also the issue of increased compliance costs and the question of who will bear these. As an example, under PSD2, all PSPs must apply SCA each time a user initiates a payment transaction.
Whereas PISPs and AISPs are required to ensure that SCA is applied, they can rely on the authentication procedures provided by the user’s bank. In other words, the banks will be tasked with formulation and implementation, as well as ensuring effectiveness.
How can Cognosec help?
Cognosec has extensive experience of working with both banks and other payments institutions and as such our knowledge and experience in the payments sector is unrivalled. We possess the requisite expertise and track record, having carried out penetration testing for many financial institutions, and it is this assurance aspect of our services that can be utilised by both the newly licensed PISPs and AISPs as well as consultancy services for the larger institutions on whom the majority of the technical obligations under PSD2 fall.
We will be able to minimise the risks of data breach by ensuring that all systems are compliant and effective, and furthermore, we will be able to provide consultancy and assurance services to financial institutions who require assistance in complying with multiple legislative changes coming in 2018 and beyond, due to our dedicated end-to-end GDPR compliance service, and our extensive knowledge of PCI and related security-based legislation.
