New European payment regs leave banks holding the bag

Enjoy complimentary access to top ideas and insights — selected by our editors.

The European banking world is facing unprecedented challenges from upstarts who have been trying to wheedle their way into the loan, financing, payment and credit business.

And now those upstarts have the legal sanction of the European Union. Set to take effect in October, the European Union Payment Services Directive 2, or PSD2, is poised to rock bankers' world. With the new directives, a slew of new players will be able to get into the payments business.

Such third-party providers, or TPPs, will have the right to examine bank databases for information on balances, credit, obligations, etc., and make transfer payments between customer accounts and payment targets. The idea, according to the European Banking Association, is to “open up the payment market, allowing companies other than banks (e.g. money remitters, retailers and phone companies) to provide payment services.” More competition means lower cost and more choice. In one fell swoop, the EU has overturned a business model that developed on the Continent and has survived for hundreds of years, making a select few very wealthy. Now the union will be helping to spread those profits around.

Jock Fistick/Bloomberg

But what's not being spread around, or mandated, is the security onus. Banks are expected to admit all vetted comers, but how they will connect to them is up to the individual parties. If something goes awry in that connection and user data or money are compromised, it is the bank that could be left holding the bag. And while banks will do their best to ensure that the TPPs that connect with them are secure, the bottom line is that they have no control over what goes on beyond their cybergates. If the TPP has made poor security choices that empower hackers to compromise the connection process, the bank may face substantial fines.

It's actually odd that PSD2 does not mandate bank-TPP connections, considering that when it comes to payment protocols, where end users connect to TPPs to make payments or fetch information (which the TPP gets from the bank), the regulations are quite detailed.

In the world of PSD2, customer-TPP authentication must be done using the European Banking Association-defined strong customer authentication standards, which provides for two-factor authentication, with at least two of three factors including something a customer knows (password, PIN); something they have (trusted device, hardware token); and something they are (biometric test). In addition, payment service providers will be required to ensure that a customer's personalized security credentials (passwords etc.) are protected.

Thus, customers are well protected, and third-party providers are well motivated to ensure that customer transactions are safe. But the TPP is not the end of the line; in order to complete a transaction, a TPP must connect to a customer's bank account. It's here that PSD2 is lacking; banks are expected to decide on their own which authentication schemes work best for them. That authentication is as important as user authentication on the customer side, as the bank will be giving third-party providers access to their application programming interfaces. If the TPP request is compromised somehow, the bank, which has to be able to trust the TPP, could face penalties under PSD2 rules.

With many organizations relying on the standard user login/password authentication scheme to approve requests, the danger of such compromises is not negligible; certainly, the big hacks of recent years (Sony, Target, numerous banks, etc.) indicate that hackers have the means and resources to beat what were likely considered very effective security systems by those organizations even when they used two-factor authentication.

This is relevant. One possibility to secure bank-TPP transactions could be the use of SSL certificates issued by qualified trusted service providers based on rules PSD2 provides for certificate use in authenticating a TPP with a bank. If those certificates work for authenticating one end of the transaction, why not use them for the other end? But SSL certificates aren't necessarily the safest way to go; not long ago, hackers were able to use forged certificates to take over the online operations of a Brazilian bank, and there are more examples of this.

The only way out of this tangle is the institution of a single authentication chain that will protect all parties of a transaction. The ideal solution will be passwordless, a trend that experts at firms like Gartner see as rapidly growing. Instead of a password, the automation mechanism would utilize randomized code that bounces between the different parties to a transaction, different every time (making it very difficult for a hacker to reach). The initial code travels throughout the transaction, ensuring top security for all parties. It also makes things more convenient, as it eliminates the need for multiple independent authentications in a transaction series, as well as eliminating the need to remember a password. For banks, this works as an effective strong customer authentication for the third-party providers they are required to connect with, providing the “chain of trust” needed to execute the kinds of transactions foreseen by PSD2, ensuring that transactions between customers and third-party providers remain secure, while connections between third-party providers and banks are hack-free.

Freedom and free markets come at a price, but the question for many third-party providers, banks and customers is how high that price will be. The trick is going to be finding the balance between security and convenience, for all parties involved. This is going to entail some experimentation, and, as with any other new entity, there will be bumps along the road. TPPs, PISPs, AISPs, PSPs, ASPSPs and the rest of the gang will have to buckle down and work together to ensure they come up with a system that ensures that those bumps are light ones.