Updated 12 January 2018 from original post 9 October 2015.
On the 8 October 2015 the European Parliament voted to pass the Payment Services Directive 2 (PSD2). In a rather timely fashion, we had just published a paper on this subject, and reproduced it here. Now it’s been two years since the first announcement so we have updated the information here with the latest. 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 Megan Caywood, 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 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 interoperability. 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 (they can process payments but cannot accept deposits, like a bank can). 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 Starling. (See Diagram 1)
Diagram 1 – Paying online pre PSD2 with debit/credit card
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 Starling. You agree and it takes you to your bank’s online 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 login details to Amazon, or vice versa, the retailer does not give your login details to your bank account, you simply give permission to Amazon to execute payments on your behalf via your (Starling) bank account. (See Diagram 2)
Diagram 2 – Paying online post PSD2 with credit/debit card
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.
Option 1
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), Starling. 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.
Option 2
Another way this scenario could play out is that we, Starling, could act as the PISP to connect Amazon with the bank account eg. Amazon to connect through our APIs and process fast and convenient payments.
Diagram 3 – Starling Bank Payments as a Service as the PISP post PSD2
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?
However, now there are aggregators popping up, or Banks (such as Starling) who are aggregating Bank APIs for payments. If a business like Amazon doesn’t want to become regulated as a PISP and do the work to integrate all of the banks’ APIs, they could integrate through one of these aggregators – a single source of truth, if you will – and pay them a fee to directly charge the bank account. These banks/aggregators could take a fee for doing so – e.g. Amazon would have to pay Starling a fee to instruct a payment on Lloyd’s API, if they used us as an aggregator.
In the Q3 2016, the Competition and Markets Authority (CMA) in the UK completed its Market Investigation into the retail banking sector, and found that older and larger banks weren’t having to compete hard enough for customers’ business, and as a result many people were paying more than they should and weren’t benefitting from new services. To address these problems, the CMA announced a mandate for the nine largest current account providers in the UK to implement Open Banking by early 2018.
Open Banking is a mandate in the UK that requires banks to build open Application Programming Interfaces (APIs) which will enable customers to securely share their bank data with third parties, ranging from transaction data to instructing payments via API. The purpose of these open APIs is to enable customers to securely access other products and services – other than those that their banks provide – should they choose to do so, and as a result have more options and transparency around those choices. It also enables new services to be built around this open data, notably aggregation services that allow bank products to be compared easily so consumers have more clarity regarding their options. By enabling customers to have significantly easier access to these third party products (and easier ways to view and compare products), there would be a natural increase in competition in the market and improve customer’s options.
This requirement from the CMA coincides with PSD2. A key goal of Open Banking is to be compliant with PSD2, which provides the legal framework within which the CMA requirements will have to operate.
However, initially, there were some distinct differences between the scope of PSD2 and Open Banking, particularly in the products included. As of November 2017, however, the Open Banking Implementation Entity (OBIE) announced amendments to the scope of Open Banking to broaden out the Open Banking solution to include PSD2 items “in order to deliver a fully compliant PSD2 solution” – which can be read in full here and here.
This is a massive change to the scope of Open Banking and a huge win for consumers.
Notably, this amendment broadens the Open Banking solution to include all payment account types covered by PSD2, which means that additional products are now included in the scope of Open Banking, such as credit cards, e-wallets, currency accounts, charge cards, prepaid accounts and payments enabled savings, deposit, loan and mortgage products, and comprehensively fulfills the functional requirements of PSD2. Additionally, Open Banking APIs will now also cover multi-currency products not covered under the original order, as well as corporate accounts.
The delivery of this has been organised across a series of six-month releases spanning 2018 to August 2019 and coinciding with the regulatory application of the regulatory technical standards (RTS).
This increased alignment with PSD2 materially improves the likelihood of adoption across the market and by consumers, who then have greater access to a broader range of products.
There’s a great opportunity – for the consumer and the provider – with aggregators, and we’re regularly seeing new additions to the market. It’s still early days though so we’re yet to see the ones that will stick. Aggregators are being used in a number of different ways at the moment:
The challenger bank market is also becoming an increasingly competitive space with new versions of banks appearing with different approaches. Many, like Starling, are incorporating a marketplace model, but also doing this in different ways. Some challengers choose to deeply integrate one third party per category of service (e.g. one insurance provider, one savings solution, etc), and on the on the other end of the spectrum there are price comparison sites that aggregate the entire market.
At Starling, we have a particular strategy to create a Marketplace Platform, in which third parties can easily integrate our public API and can also easily plug their APis into the Marketplace within the Starling app to offer their services to Starling users, ultimately creating a network effects platform. In this way, we can easily enable customers to have a range of options from providers across the market, and help them to easily and securely access those products. We’re able to do this given we’re a licensed bank, have open APIs, and have regulatory permissions to introduce our customers to third party financial products. Traditional banks are recognising the threat and are actively working to be competitive in this space though, as evidenced by partnerships such as the Bud and First Direct relationship. It’s a new world, and many are vying to be competitive in this space, so only time shall tell who becomes a contender in this arena.
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 Yolt in the UK and 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 or Yolt app, and see your Starling, 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 4 & 5)
Diagram 4 – Checking multiple payment account details pre PSD2
Diagram 5 – Checking multiple payment account details with PSD2
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. 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 encrypted tokens, not asking customers to compromise passwords.
This is where the Starling Marketplace comes into play. The advantage to the consumer here, in being able to see all of your financial world in a single view. This could be pensions, investments, insurance etc. Some of the Regulatory Technical Specs (RTS) are still being determined but they’ve largely been set with Open Banking and it does include “complete transactional warts” – e.g. all transaction data. As Starling has already carried out checks on the consumer and approved them for a current account, it potentially (with approval from the other financial services provider eg. PensionBee) enables pre-approval, speeding up the process and convenience for both parties.
PSD2 comes into effect 13 January 2018. As mentioned above, the Open Banking scope has been broadened to include all payment account types covered by PSD2 (including credit cards, e-wallets, and pre-paid cards, to name a few) and as a result an ‘Amended Order Timetable’ for Open Banking has been produced that has broken down the phases to compliance and extended the overall deadline to August 2019.
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
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 geolocation and other information.
We at Starling have built a bank truly fit for an XS2A world.
+ Access to Accounts(XS2A)
Access to Accounts (XS2A) basically entails that financial institutions but also non-financial market players may obtain access to the bank account of European costumers. These businesses would be positioned between the consumer and banks and are referred to as Third Party Payment Service Providers (see below).Existing brands/potential new examples: n/a
+ Account Information Service Provider (AISP)
Any online provider that wishes to aggregate online information on one or more payment accounts held with one or more other payment service providers who typically present the information in a single dashboard for a customer.Existing brands/potential new examples: Yodlee, Money Dashboard, Mint, First Direct price comparison sites e.g. Money Supermarket Banks e.g. Starling
+ Account Servicing Payment Service Provider (ASPSP)
All financial institutions that offer payment accounts (e.g. current accounts, credit cards) with online access (internet banking), and under this legislation will be obliged to open up an interface to allow authorised and registered third parties to initiate payments and access account information.Existing brands/potential new examples: Banks e.g. Santander, Building Societies e.g. Nationwide, Yorkshire BS
+ Card scheme
Card schemes are payment networks linked to payment cards, such as debit or credit cards, of which a bank or any other eligible financial institution can become a member.Existing brands/potential new examples: Mastercard, Visa, AMEX
+ European Banking Authority (EBA)
The European Banking Authority (EBA) is a regulatory agency of the European Union headquartered in London, United Kingdom. Its activities include conducting stress tests on European banks to increase transparency in the European financial system and identifying weakness in bank’s capital structures.Existing brands/potential new examples: n/a
+ Merchant acquirer
An acquiring bank (or acquirer) is a bank or financial institution that processes credit or debit card payments on behalf of a merchant (e.g. retailer). The term acquirer indicates that the bank accepts or acquires credit card payments from the card-issuing banks within a card scheme.Existing brands/potential new examples: WorldPay, First Data, Elavon
+ Open Application Programme Interface (API)
An API is a set of commands, functions, and protocols which programmers can use when building software for a specific operating system. The API allows programmers to use predefined functions to interact with the operating system, instead of writing them from scratch. An open API is an interface that has been designed to be easily accessible by the wider population of web and mobile developers. This means an open API may be used both by developers inside the organisation that published the API or by any developers outside that organisation who wish to register for access to the interface.Existing brands/potential new examples: n/a
+ Payment Initiation Service Provider (PISP)
Any organisation (traditionally retailers, but could be utilities or any other category of business that takes online payments) that initiates a payment, needing a software bridge between the website of the merchant and the online banking platform of the payer’s bank in order to initiate internet payments on the basis of a credit transfer.Existing brands/potential new examples: Amazon, John Lewis, British Gas
+ Payment Institute
A category of payment service provider that came into being as a result of the enactment of the original Payment Services Directive (PSD1). They can offer their customers the following services:+ Payment Services Directives 1 & 2 (PSD1 & PSD2)
Two pieces of legislation handed down from the European Parliament and the council of the European Union. These directives provide the legal foundation for the initial creation and subsequent widening of scope, of an EU wide, single market for payments.Existing brands/potential new examples: n/a
+ Regulatory Technical Standards (RTS)
A set of detailed compliance standards that will be set for all parties to meet covering things such as data security, who is accountable if something goes wrong, and what is the compensation process.Existing brands/potential new examples: n/a
+ Single Euro Payments Area (SEPA)
SEPA is a payment-integration initiative of the European Union with the objective to simplify bank transfers denominated in Euro. As of 2015, SEPA consists of the 28 member states of the European Union, the four member states of the European Free Trade Association ( Iceland, Liechtenstein, Norway and Switzerland), Monaco and San Marino. Andorra will become part of the area in 2016.Existing brands/potential new examples: n/a
+ Third Party Payment Service Providers
In this context, the third party payment service providers are the AISPs and PISPs that are the third parties alongside the banks and the customer in the payment process.Existing brands/potential new examples: as Above