Main content

Preparing for PSD2, the technology issues

Angelica Mari Profile picture for user angelica_muri January 14, 2018
Upcoming regulatory technical standards for strong customer authentication are sparking controversy among European banks and service providers. We consider the implications of the new provisions.

As the implementation date of the revised Payment Services Directive (PSD2) passed last Saturday, a number of significant technology changes are expected in the existing payment services regime of European banks and new market entrants.

In a nutshell. PSD2 requires that Europe’s banks must allow third-party access to data from any customer who authorises access to ther data. That includes rival lenders and retailers. Think for one moment how the likes of Amazon and Alibaba have become players in the payment space and it doesn't take too much imagination to understand the reverberations this will bring to the financial services sector. However, while PSD2 may look like a Trojan Horse, it comes with stringent conditions that have a significant technology impact.

One of the changes is the requirement for payment service providers (PSPs) to use strong customer authentication (SCA) and secure communication. This has become a hot potato passing between the European Banking Authority (EBA) and the European Commission (EC) and has been the subject of much debate in the financial services sector.

As part of the PSD2 directive, all PSPs are required to apply SCA when payers access their payment accounts online when they initiate an electronic payment transaction or carry out any action through a remote channel that may present a risk of payment fraud or other threats.

Banks will be responsible for leading the efforts and bearing the cost involved in the design and implementation of SCA requirements. But new market entrants, Payment Initiation Service Providers (PISPs) and Account Information Services Providers (AISPs) will also need to ensure that the requirements are properly applied.

SCA's technology impact

The main IT sticking point of SCA relates to the implementation of two-factor authentication (2FA), according to Mark Hartley, EMEA head of cards and payments at Infosys.

Banks will need to ensure 2FA with dynamic linking is in place for remote transactions, says Hartley. They will also need to authenticate two-way password protocols (TPPs) for every transaction barring repeat payments, then validate TPPs against an EBA-mandated central registry.

To drive minimal compliance to the SCA requirements, banks will need to implement 2FA for online account access and electronic single time transactions and first of recurring payments.

Hartley adds:

They will also need to re-design authentication and authorization flows and also build consent flows to allow TPPs to facilitate transactions with the customer’s consent, as well as maintaining consent lists of account and payment transactions against customer profiles.

While SCA is very much about ensuring the security of customer data, that doesn’t necessarily mean that the final user experience is optimal, according to Ronan Hughes, senior payments and technology transformation manager at Bank of Ireland. He says:

Organizations want to be able to [comply with SCA] so that it’s as much of a light touch as possible for the consumer, as payment initiator or as the end consumer of the service.

He adds:

Banks and PSPs are debating whether or not a fingerprint, for example, is sufficient as one of the two factors of authentication in combination with the unlock passcode on your phone, or the virtual token on your phone used to access your bank account.

Defining the best possible combination of factors to support SCA to ensure enough variations in companies’ offerings will be key, says Hughes. That’s because using the same two factors every time wouldn’t necessarily ensure ideal standards of security and wouldn’t lend itself to any new - or different - user experiences.

Additionally, SCA requirements bring more complexity for the existing IT portfolios of large incumbents, as new interfaces have to be built and hooked into legacy platforms, says Hughes:

This is a much bigger challenge because these interfaces have to be embedded with [the bank’s] own security framework, and this is something that ordinarily would not be part of the standardized security model of a large incumbent bank.

For fintechs, app-based payment providers or challenger banks starting from scratch and without the burden of legacy technology platform, complying with SCA requirements is much simpler despite the fact they will also have to amend and adapt their systems, the executive adds.

[For the new companies] to comply it’s a much easier ask, because all they have to do is build [new interfaces]. They don’t have to worry about changing a huge underlying platform in order to make sure that it’s compliant.

Getting ready

Sector firms will have a little more time before having to implement SCA. While PSD2 must be implemented by 13 January, the provisions relating to SCA will only apply from 18 months after the date of publication of the regulatory technical standards (RTS). This means that the deadline is anticipated to be October 2018 at the earliest.

The RTS has been published and despite possible amendments, the SCA requirements are mostly known to industry players. However, there will still be a lot of debate going on within the banking community about the IT impact of the new rules in the months to come, according to Hughes.

This is akin to when the Single Euro Payments Area (SEPA) went live a number of years ago: there was a grace period for people to get on board, a lot of people voiced potential concerns around the scheme but everybody had to have it in place anyway. I think this similar sort of situation happens when you’ve got such a large amount of change going on.

Hughes adds:

I would argue that PSD2 is probably much more fundamental in terms of the amount of change it introduces at a European level. It’s just less readily visible to everybody, but it is much more fundamental. So having this amount of debate right up to the effective implementation date would be quite normal.

For large incumbent organizations, there are three main options to get their IT ready for SCA, according to Hughes. They can decide to do it all themselves and come up with what they believe their SCA solution will be, then lobby intensively to ensure they won’t have to change anything. But, according to the executive, not many organizations are going for that route due to the high risk associated with it.

End users can also adopt a number of deployment strategies, according to Hughes. Going for this second option means that, regardless of what the final requirements will look like, they will have a solution ready to cover those needs. The third alternative is to go out and partner with a technology company that has options off the shelf.

There are many flavors and options in between depending on the size and scale of the institution and whether you want to operate as a PSP, a PISP, an AISP or all three.

The IT executive adds:

Or, potentially, if you’re one of those larger and more technologically diverse banks you may want to provide banking-as-a-service or banking-as-a-platform and license your systems to other financial institutions, so that they don’t have to provide their own solutions and can leverage yours on their behalf.

My take

The requirements around SCA, just like the wider PSD2 requirements, can be seen as a hassle as well as an opportunity, depending on where the organization sits the financial services food chain. If they are an existing payment services provider, there is definitely an element of difficulty given the change that must be introduced to existing, often legacy portfolios.

Realistically speaking, if companies are serious about operating in an open banking context, they will need to see this as an opportunity and become compliant from day one to compete in what will effectively be, for the first time ever, a level playing field for everybody.

Image credit - via Forum Systems

Read more on:
A grey colored placeholder image