Yesterday the European Parliament voted to pass the Payment Services 2 Directive. In a rather timely fashion, we had just published a paper on this subject, so we have reproduced it here. If you would like a copy of the original, please email [email protected] I would like to thank all of the Starling team, as it was genuinely a group effort on tackling this content, but particular thanks to Mark Hipperson, Julian Sawyer, Sarah Williams-Gardener and Terry McParlane.
For those who experienced the roller coaster that was Europe’s implementation of the Payment Services Directive (PSD1) – here comes Payment Services Directive 2 (PSD2). And before the initiatives outlined in PSD1 have been fully dealt with.
We won’t lower ourselves to jokes about bad movie sequels, so moving on. The driving force behind both directives is the harmonisation of the payments landscape to level the playing field between countries and between payments providers, with the end goal of increasing competitiveness and thereby giving the consumer better value.
Let’s pause there. Financial services is sometimes, understandably, accused of being a dark art, with complex terms and an impenetrable language all of its own. At Starling we always strive to explain what it means for a customer when technology or regulation evolves – the good, the bad and sometimes the ugly. So bear with us through this paper.
This subject, of all that we have covered recently, probably needs the most explanation. Even those in the industry are still trying to wrap their heads around all of the implications. In this paper, we want to focus on two, out of the many, changes in the new directive and what they mean for all impacted – the banks and other financial institutions, merchants i.e retailers and other payments beneficiaries, and most importantly, customers. We have tried to define terms as we go, but have also included a glossary below, with some examples of what companies might fall into which bucket to help bring it to life.
The common themes of both directives are about opening up the market to new types of organisation and defining common standards that encourage inter-operability. For example, PSD1 introduced the concept of a Payment Institution, which is a firm in the payment industry that is regulated but not to the higher banking standard. Examples most will have heard of are large payments bodies like PayPal or WorldPay, but it also allowed hundreds of smaller players to compete.
It also introduced the Single Euro Payment Area (SEPA), which is the set of standards for low value Euro Payments in the Euro zone. The idea was that if there was one standard for payment transactions and more players in the mix then those poor consumers in Spain where payments are expensive would benefit from increased competition from The Netherlands which would drive prices down. It has been a long road and SEPA has still not been fully deployed, with many deferred end dates along the way.
However, here we are talking about PSD2, which probably has much more relevance for consumers. The directive has a wide scope, but we would like to focus on how PSD2 capitalises on the accessibility of APIs, and explain why there is so much nervousness and excitement in the market. PSD2 is a great example of TLA (Three Letter Acronym) speak at its very best. So here goes:
Today, maybe you’re shopping on Amazon, you decide what to buy, and complete your purchase using your debit card. The merchant (Amazon) will have an acquirer e.g First Data or WorldPay, who will then contact the customer’s card scheme e.g. MasterCard or Visa, who will then pull the payment, debiting the customer’s bank account, e.g Lloyds Bank. (See Diagram 1)
Now fast forward to when PSD2 has been implemented. You are shopping again on Amazon, but instead of entering your debit or credit card details, you are asked whether you want to give the retailer access to your bank account, again at Lloyds. You agree and it takes you to the Lloyds internet banking site where you give your permission. This is similar to the way you allow applications to access your Facebook or Twitter account today. You do not give your bank logon details to Amazon, or vice versa the retailer your logon details to your bank account, you simply give permission to Amazon to execute payments on your behalf via your Lloyds bank account. (See Diagram 2)
The next time you go shopping on Amazon, you won’t need to give permission again – the permission should stay active until such time as you revoke it, for whatever reason.
So now, the technical bit. In this scenario, the directive allows for one firm to manage the payment initiation, known as the Payment Initiation Service Provider (PISP), in this instance Amazon, and another to manage the account, which is known as the catchy Account Servicing Payment Service Provider (ASPSP), Lloyds. This Access to Accounts (XS2A), (see what they did there, X-ess-to-A!), is probably the biggest technological innovation in retail banking since the internet. The merchant or retailer and the bank will communicate to each other using an open Application Programme Interface (API) for which the European Banking Authority (EBA) have been given the responsibility for defining the Regulatory Technical Standards (RTS). That basically means the standards that all APIs will need to comply with – i.e what data is transferred, what are the security protocols, what happens when things go wrong etc.
So what? As far as customers are concerned, how is there any difference between storing your debit card details with merchants you use regularly, and giving permission for your bank and said merchant to swap data to facilitate quicker payments? Basically there’s none in experience if you’re already a reasonably sophisticated online shopper.
For the businesses involved though – big change. Despite the IT complexity and cost to implement the changes, you will also notice that all the middle men are gone. The acquirers and the card schemes are disintermediated, and subsequently lose a significant revenue stream. Now there could be a customer benefit in that – if the merchant passes on the cost benefit. But will they, or will they take the margin? And what happens if banks decide they want another revenue stream to supplement others they are losing, and start charging merchants, like an interchange cost? Lots of elements still to be worked through before implementation of this can even begin.
Now we move onto the second big part of the directive – the AISP, which is the Account Information Service Provider. Whilst the PISP initiates payments across the ASPSP, the AISP consolidates information across multiple ASPSPs. OMG? Seriously?
Put simply, an AISP gives a name to something that does already exist, take for example Mint.com in the US, can consolidate a customer’s bank account details from several different banks.
So imagine in the UK in a few years, you logon to a Money Supermarket app and see your Barclays, Lloyds and Santander accounts, all into one place. Yet again access to this would be granted using XS2A standards set by the EBA and you would not have to give your logon passwords to Money Supermarket. (See Diagrams 3 & 4)
Why Money Supermarket as the example? Well amongst lots of other players, the product comparison sites will almost certainly sniff a real commercial opportunity here to enter this space from a cross-product, cross-bank, cross-sell point of view – the more customer data they have, the better they will be positioned to take over the role of the bank in aggressively cross-selling.
These account aggregator, or hub services, have existed in the U.S. for many years. They were not successful in coming to the UK because currently the data transfer can’t be facilitated via an encrypted token, so previously customers would have had to give away their passwords to the hub service, and in doing so would break their terms and conditions with their banks and muddy the water in case of fraudulent use of their account. As far as we are aware, First Direct is the only brand that has proceeded and given customers the choice to do this anyway, one assumes whilst flagging the associated risks. With PSD2, all banks, building societies and other financial entities (like pre-paid cards, credit card providers, mortgage brokers) would be obliged to support this – this time using passwords, not asking customers to compromise passwords.
There is an obvious consumer advantage here, in being able to see all of your financial world in a single view, although it is yet to be determined whether the standards will be set at a high level – e.g. balance, or complete transactional warts and all.
Pros and Cons for Consumers
+ Ability to consolidate all accounts in one place with continued protection under their product terms and conditions
+ The choice of the most convenient internet or app interface to check their bank account details
+ Direct integration of their bank account with merchant acquiring sites is convenient and practical
– Lack of clarity of responsibility between PISPs (merchants) and the ASPSPs (banks) in the event of loss
Pros and Cons for Merchants
+ Reduced costs compared to card interchange
+ Immediate settlement into merchants account
+ Even greater direct relationship with the customer
Pros and Cons for Banks
+ Ability to position themselves as an AISP
– Significant costs to change systems
– Loss of screen time in front of consumer
The question we would ask – is there really enough customer upside, when the existing banks will spend years and billions of pounds implementing these standards, when they could be focusing on other things? For me, the only group to win out of this, are the merchants, and the raft of new players who could enter the fray as an AISP to attempt to take over the cross-sell position of power currently occupied by the big banks.
Starling’s advantage as a new entrant is that we are already building a bank with the capability to deliver all of these requirements within this directive, with the highest level of security and confidence. We realised a while ago that many people now “login using Facebook” or “allow Reed.co.uk access to my LinkedIn profile to apply for a job” and are taking advantage of these, amongst other API potentials. What we want to ensure is that customers always understand what permissions they are granting, how the data will be used, and the level of security around it. How many of you would be comfortable allowing that new-kid-on-the-block-retailer to access your bank account?
The important part of Starling being a fully-fledged bank, is the higher regulatory standards we will be held to. As it turns out, we will actually be a PISP, an AISP and, of course, a ASPSP. We will allow our customers to execute payments across other banks accounts, consolidate their banks accounts and also actually give them a bank account! Being a bank allows us to do all three, and do it well, to the highest level of security.
Most importantly we will add a level of value to customers, giving them power over their data, to help them manage their money better – be that by helping them “jam jar” their spending and their saving, or tagging their transactions with geo-location and other information.
We at Starling are building a bank truly fit for an XS2A world. And for those of you who want to know more, you can find the 191 page PSD2 Directive here – happy reading!
Sign up now and you'll be invited to be one of Starling's first customers later this year. You'll also be able to join our Starling community, where we'd love you to play a part in our product development and testing.