Explaining PSD2 without TLAs is tough!

Updated 12 January 2018 from original post 9 October 2015.

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.

What was PSD1?

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.

What is PSD2?

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)

How PSD2 might work when shopping on Amazon?

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)

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.

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.

However, just before we get into that we wanted to answer a question that is asked a lot - “What exactly is the difference between PSD2 and Open Banking?”

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.

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.

The rise of aggregators and challenger banks

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:

• To combine bank accounts (personal current accounts or business current accounts) from various providers
• To facilitate payment as an intermediary for an e-commerce shop and the source bank account
• To combine a selection of financial services products eg. pensions, insurance, investments
• To compare banks on key features, such as Overdraft Fees and Service Quality ratings.

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.

What is the Account Information Service Provider?

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.

AISP examples

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)

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.

Did you hear about the Amended Order Timetable?

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.

So in summary, what are the pros and cons for all the players in PSD2?

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

Our advantage

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.