A year ago today, on 13th January 2018, I was greeted with an interesting message when logging into my account. It helpfully informed me that PSD2 had just come into force in Ireland and the rest of the EU.
It rattled me when I read it as it came across to me as nothing more than a dressed-up disclaimer for the bank placing liability on their customers, and one which I had to accept in order to continue to access my bank account.
Before we go down the PSD2 rabbit hole, let’s clear up a few abbreviations used throughout this piece:
- PSD2 – Payment Services Directive 2 – (there was an older one)
- RTS – Regulatory technical standards on strong customer authentication and common and secure communication (SCA and CSC) – yes abbreviations are needed within this definition of an abbreviation!
- ASPSP – Account Servicing Payment Service Providers (usually a bank)
- PISP – Payment Initiation Service Providers (third-party payment facilitator)
- AISP – Account Information Service Providers (third-party payment information provider)
- TPP – Third-Party Provider (a broad term to describe AISP’s & PISP’s)
- PSU – Payment Service User (that’s you and me)
What exactly is PSD2? As a quick primer, it’s the successor to the first Payment Services Directive (PSD1) that came into force in 2009. PSD1 facilitated the provision of uniform payment services across the EU but left a few gaps that PSD2 aims to close, among them - providing consumers with better security to take advantage of using third-party providers (TPP’s) and their services that may integrate directly with an individual’s bank account.
The two main types of third-party providers that PSD2 covers are:
Payment Initiation Service Providers (PISP’s) – PISP’s provide services that involve initiating payments through your bank account. This has the potential to speed up and increase the volume of online commerce when, for example, there is no longer the need to go through a credit card company to facilitate a payment.
Account Information Service Providers (AISP’s) – AISP’s provide informational services using the data within your bank account, or from multiple accounts in potentially multiple banks. For example – budgetary planning and accounting software reconciliation. They will conveniently be able to aggregate all your financial information across your various financial providers in one place, giving you a nice shiny UI to peruse it from.
What does it mean for the average consumer?
With traditional banks opening their doors up to the brave new world of modern fintech, it will foster innovation and competition in the financial sector and bring many benefits to the consumer - from easier online payments (without the need for a credit or debit card) to money management services that better help consumers keep on top of their finances.
This will be enabled through application programming interfaces (API’s) which provide a programmatic way for software to interact with systems (e.g. a budget planning provider pulling over your spending data and providing useful money management insights and reports).
This is useful because these kinds of services are not generally available directly with most banks and when they are, they are not often done well. How many online banking user experiences can you say you’ve been genuinely impressed by?
Banks are big ships and moving them in a new direction takes time. Allowing third-parties that they don’t have a direct relationship with access to their customer data is likely not a prospect that banks have been rushing to embrace but PSD2 has brought it to their doorstep and they are now mandated to let them in.
Hiding in plain sight
The big secret hidden in plain sight for banks and PSD2 is that most of them are not ready for it. The message I was presented with by my bank confirms it. The January 2018 introduction of PSD2 mandated that they open their customer data up to third-parties that the customer consents to, but the security standards that can provide adequate protection for consumers using these services do not come into force until 14th September 2019. The bank’s customers, who may not be fully aware of, nor understand the implications of following the current advice of using services in this way are at risk.
This is why I believe the cart has been put firmly before the horse with PSD2 and security standards.
Let’s take a closer look at these conditions for Permanent TSB Bank in Ireland
You must ensure that any TPP you instruct is a regulated TPP.... Use by a TPP of your Security Feature(s) is deemed to be use by you / and or the Joint Account Holder(s) and you permit us to share your information with that TPP...
It would appear that I as the customer of the bank need to make sure that the third-party that is offering to integrate with my account has the appropriate registration and authorisation to operate, because everything they do will be seen as carried out by me. And of course, the average banking customer has the time and wherewithal to undertake that kind of due diligence.
Surely there’s a better way? – yes…ish.
There is a certification standard specified for PSD2 to ensure that TPP’s are who they say they are – eIDAS certificates are to be used in the verification of authorised TPP’s. There are several problems with it:
- eIDAS certificates prove who a TPP is, but not if they are still approved to be a PISP/AISP at the time of the interaction with the bank;
- National Competent Authorities (in the case of Ireland – the Central Bank) hold lists of approved and registered TPP’s but mostly not in a machine-readable form. (This list is only accessible from the Irish Central Bank as a downloadable PDF.)
This means that a bank is not able to verify real-time if a third-party is still authorised to provide the services that they are to the bank’s customers. They may at one stage have been authorised, but subsequently had their status revoked and the bank would be none-the-wiser.
If you authorise a TPP to access your Account(s) you acknowledge that the TPP will be able to view all information in relation to all of your online accessible Account(s), including your Joint Account(s) and any term lending or mortgage Account you may have.
A third-party provider may only need to view your current account to provide you with their service, but if you allow access, as things stand, you are giving away the keys to the kingdom. They can see and do everything you can do. Access is not limited to one account - any account attached to your bank profile is accessible. There is currently no way of scoping the access.
This is a clear contravention (among others) of the data protection principle of data minimisation that is enshrined into the GDPR under Article 5.1.c of the regulation. It would seem like the GPDR was well-timed with its introduction in May of last year to prevent practices like this and yet banks are mandated to open access to their interfaces before having appropriate security and privacy controls in place in time to meet its requirements.
If you no longer wish to use a TPP service, you should contact the TPP directly to inform them of your decision. You should note that they may still have access to your online accessible Accounts (including your online accessible Joint Accounts(S)) unless you change your Open24 details.
Deciding that you no longer want to use a third-party does not mean they can’t still access your account data. The only way to stop them is to change your login details.
THIS IS A BIG PROBLEM
What if you’re using more than one third-party provider and you decide to stop using just one of them? You now must change your banking login details and inform those third-parties whose service you want to continue to use of your new details.
Under the GDPR, the consent that you give to process your data (if that is the basis it’s being processed under), should be as easy to withdraw as it was to give in the first place. Having to change your login details to ensure that a third-party no longer has access to your account certainly does not meet that standard.
Aside from the fact that this is a significant inconvenience – how many times have you been told by your bank never to share your login details with anyone else? It’s a catch-22 they may say – PSD2 mandates that they open their interfaces to third-party providers and so these compromises have to be made. The security of customers’ accounts should never be put at risk in this way. If the security standards of PSD2 had been met in time for January 2018, this would be a non-issue.
Screen scraping – The internet’s oldest profession
The types of third-party-provided services I’ve mentioned have been offered to consumers in various markets for some time. Often, they have been provided in the same way as banks are facilitating third-parties under PSD2 now. For example - the budgeting service Mint.com and Sigfig.com require you to give your bank account credentials (i.e. your username and password) to be able to access your bank or investment account. So too do Coinbase.com if buying bitcoin using a US bank account is your thing. Yodlee is a prime example of what PSD2 should be putting manners on – in many instances, where a bank does not have an API available, businesses are giving this third-party total access to their bank accounts by sharing their credentials so that they can easily reconcile their bank transactions within their accounting software.
How do they do this? – not with API’s (mainly because most banks that I’ve mentioned haven’t made API’s available) but with good old-fashioned screen scraping. Screen scraping, also known in the fintech world by the more clinical name of Direct Access, is a process as old as the internet itself whereby instead of using API’s that can offer better security and access to data only as needed, websites are crawled by software programmes (often called web spiders or bots) and programmed to recognise patterns in how the information is presented in order to extract that data.
Google uses a similar methodology to become aware of what content is on a website. It follows all the available links and indexes the content in an organised fashion. But that is for publicly-accessible information. The difference between that and using screen scraping to interact with your bank account is that you would need to provide your username and password to a third-party for them to log in and allow them to screen scrape, read your financial data and otherwise take actions as if they were you.
Why is this a problem?
This is far from ideal because if a third-party system is logging into your account using your credentials then it can do everything that you yourself could do. There is no limit on what it can initiate or read from your account. You may want to get budgeting insights on your Current Account – but if you also have a Joint Account attached to your profile, there’s nothing to stop the third-party from reading that data and performing actions on it as well. Access is not scoped to what is needed.
There are significant privacy concerns here and the General Data Protection Regulation (GDPR) that came into force in May 2018 is well-timed to bring home the point that so much of how this is done at the moment potentially leaves parties liable for the gaping security holes that are being allowed to exist as well as the data overreach that is allowed in accessing data in the first place.
Banks routinely tell customers that they shouldn’t share their credentials with anyone else, yet here they are, telling you that it’s okay to give your password to a third-party to access your account. Efforts at educating consumers for security best practices are being compromised with this contradictory advise.
Third-party providers are supposed to be registered and approved with the Central Bank of Ireland to offer these kinds of services but what is to stop a bad-actor, that wants to gain access to the bank accounts of customers from simply offering the service? The answer is not a whole lot. Yes, they will likely be caught out eventually, but by then significant harm could already have been done.
It is a breach waiting to happen, potentially on a massive scale if a significant third-party provider is compromised.
Surely there’s a more secure way?
Yes, there is – and it is part of the PSD2 specification. It’s called the “Regulatory technical standards (RTS) on strong customer authentication and common and secure communication (SCA and CSC)”.
This specifies that banks should provide secure API’s to authenticate third-party providers. The recommendation by the Open Banking Standard, which is developed by Open Banking Ltd., a spinoff from the UK's Competition and Markets Authority (CMA), is to use the OAuth 2.0 protocol with OpenID Connect to achieve this.
Authentication and Authorisation
Authentication and Authorisation are different beasts. And they are both difficult to do well.
Authentication is the process of verifying that someone is who they say they are, whereas authorisation relates to what that person or entity can do.
By allowing an individual to securely authenticate and at the same time limit what access to their account is allowed on their behalf by a third-party, banks would provide their customers with the tools needed to only allow those third-parties access to only what data is necessary to provide their service and only for as long as is necessary.
Many businesses are choosing to use dedicated identity providers who specialise in providing identity services such as Okta, Auth0 and Criipto to name a few. They are choosing to work with these best-in-class subject matter experts to ensure that they are constantly meeting security best-practice and continuing to evolve the deep-defence protections on what is a critical gateway to their systems.
With banks still scrambling to bring their legacy systems up to date for modern banking, providing secure authentication and authorisation, which many are likely to build and maintain in-house, are just one of the many challenges they face.
Interestingly, there’s been pushback from those in fintech as well, as evidenced by the publication of the Manifesto for the impact of PSD2 on the future of European Fintech.
In it, the case is made for maintaining the status quo and that strong authentication with PSD2 & Direct Access (screen scraping) can be achieved as is. This has the whiff of a clean coal argument to me.
They propose a more secure form of screen scraping where the third-party identifies itself to the bank. This doesn’t resolve some core issues:
- Customers credentials are being entrusted to third-parties. Because those credentials need to be presented back to the bank every time they need to interact with the customers’ account it means that they need to be stored in a manner that they can be decrypted;
- There could be hundreds or thousands of third-party providers offering services under PSD2. Security is only as strong as the weakest link. If one provider doesn’t manage the credentials entrusted to them adequately, the game is up for the customer – that individual is now at the mercy of however many third-parties they use and their varying ability to protect those credentials;
- Access to accounts is total. While third-party providers say that they will only access what is consented to by the customer, the fact is that they have total access to everything and the customer has zero control over that once they give their credentials to a third-party.
The manifesto lauds that “there hasn’t been, until this day, one single documented incident of data fraud or compromise of personal credentials.”. The fact is that PSD2 will result in an explosion of third-party providers offering services. It is only a matter of time before a significant breach happens of bank customers data because one of these providers fails to protect credentials. Updating the methods that are used to access this data to take advantage of the latest proven authentication and access technologies is surely a better way.
There is no doubt that there is a cost to those on both sides of the fence of moving to a more secure and purpose-built solution for data access. Long-term, it is in the interests of all involved, third-party providers, financial institutions and consumers on the ground.
The manifesto also makes mention of the GDPR and the fact that screen scraping allows third-parties to facilitate data subject rights such as portability. This is an interesting spin on making their case for continued access to bank data via screen scraping. They may think that it also satisfies Article 32 of the GDPR – I don’t.
It also raises some interesting questions for Article 28 of the GDPR around the controller/processor relationship – who has the contract with the third-party and who determines the purposes and means of processing? The third-party provider could be seen as determining the means of processing and as such , recent judgements such as the Wirtschaftsakademie Schleswig‐Holstein case may have an impact on their obligations. The right to data portability is not all that fintech third-parties should be cornered about with realising in General Data Protection Regulation.
The compromise that was reached with the European Banking Authority (EBA) involves allowing that direct access (i.e. screen scraping) is still available as a fallback option. Banks that choose to develop dedicated API's will still need to provide screen scraping as a fallback solution unless they have gained an exemption. This can be granted by the bank’s National Competent Authority (NCA). To gain an exemption, they will have to have developed and released for testing, performant and available dedicated API's six months before a market launch where the screen scraping option would no longer be available.
Where a bank has not gained an exemption and has screen scraping available as a fallback option, a third-party will be allowed to fail over to screen scraping where the dedicated API’s are unavailable five consecutive times for more than 30 seconds or have performance issues.
It is important to understand, that for the fallback to be an option, the third-party will still need a customer’s bank credentials. This does not solve the original problem.
What do Irish banks have to say?
Wearing my data protection hat and reading the message that PTSB presented to me, it left me wholly uneasy that this was the current state of play. I wanted to confirm that my understanding was correct, that with PSD2 in place and secure authentication and authorisation not being provided through API’s, that customers data is at risk.
The questions I was looking for answers to were:
- What authentication mechanisms do the bank have in place to facilitate PSD2?
- Do I have to share my bank credentials with a third-party provider to avail of a third-party service?
- Can I authorise a third-party provider to only access what they need to provide me with their service?
Permanent TSB (PTSB)
My journey to getting an answer with PTSB took a tweet, three weeks and a lot of prodding. Eventually I received a call from the head of fraud at the bank.
While it took some time to get an answer, the one I did get was delivered by someone who knew what they were talking about and he confirmed that the risks are there. I was told that they are “watching this like a hawk” and working towards getting secure authentication in place.
Other banks were not so forthcoming. Often it was difficult to get to speak to somebody who could talk with authority on the subject and would just refer me to their published information that was often lacking.
Bank of Ireland (BOI)
Although I eventually got to the bottom of things with BOI, they were the least forthcoming, throwing up what may as well have been smoke and mirrors in an attempt to avoid giving a straight answer.
Initially, I was told that the bank would tell me in their own good time what their plans are for PSD2 (or the secure authentication stage of it) would be:
Our policies in relation to the second stage of PSD2, which is related to third-party providers will be issued in due course in advance of the second stage of PSD2 roll out.
After a bit back and forth I received a definite answer from Bank of Ireland and it confirms the concerns that I had:
If you want to avail of a TPP service in line with PSD2 prior to the RTS deadline for secure delivery of these services – 14th Sept 2019 – then you may do so by sharing your credentials with authorised 3rd parties – as reflected in your updated Ts & Cs. Please note that Central Bank of Ireland maintain a register of these authorised providers – please consult this part of their website to find out this important information: http://registers.centralbank.ie/. Any TPP using your credentials is not required to identify itself to us, and any access will appear to have been made by you. It’s also important to understand that the TPP will have access to all your banking information, rather than just the subset of data required to be provided under PSD2. Once the secure delivery of these services – via a dedicated interface – is delivered by Sept 2019 then this current practise – known as screen scraping – will no longer be permitted. Please let us know if you require any further information.
My problem (and this is at the nub of the issue) is that while the second stage of PSD2 involving secure authentication doesn’t come into force till Q3 2019 – PSD2 is in force now.
- Banks need to provide for third-party not-so secure access now;
- Consumers are at risk because of this now;
- Banks need to be more transparent about the risks now;
- And banks should really get ahead of the requirements timeline now;
Allied Irish Bank (AIB)
My PSD2 digging with AIB started in Feb 2018 with a webchat where I was told that they are working on API’s and if I wanted further information, I could reach out to their API team. The API team told me that they are currently working on API’s for access to account information and payment initiation services under the PSD2 directive. Moreover, they expect to publish these API’s in 2018.
I was also directed to their Security Centre page where they give advice on using third-party providers under PSD2.
- AIB advise you not to give your personal access code to anyone (good practice), except for a third-party under PSD2 (because prior to releasing API’s there is no other way for them to meet their obligations to allow access by these third-parties to your accounts) – They have made you aware of the risk, it’s now yours to take.
- Third-parties will have the same access that you have to your accounts. – For all intents and purposes to the bank, the third-party is you.
- The onus is on the customer to ensure that a third-party is registered or authorised by the Central Bank. – Wouldn’t it be nice if any third-party requesting access to a bank account had a way to prove that they are currently registered or authorised, at the time they connect, lifting the burden from the end-user?
- Ensuring a site is legitimate can involve confirming that it has an SSL certificate (that nice padlock in the browser address bar). SSL certs are either low cost or free. While of course they should be used, the bank should not be advising that a user could consider a site legitimate just because they use an SSL cert. This is patently bad advice and will give some customers a false sense of security.
- If you decide that you want to remove the access that a third-party has to your accounts, you will need to change your access codes with the bank. Still using other third-parties that you want to continue using – don’t forget to hand them over your new codes!
- Finally, just a friendly reminder – you may be liable for any loss you suffer as a result of using these providers.
I didn’t have to search hard to find AIB customers wondering now that PSD2 is a reality since January 2018, what does this mean in practice for realising the benefits of it today.
Then in November 2018, AIB announced that they launched their PSD2 API’s. As of writing, they are the only Irish bank that I am aware of to have launched their API’s in time to meet the RTS standard for PSD2.
What role does the Central Bank of Ireland play?
The banks are telling us that we should check with the Central Bank that a third-party provider that you wish to use is either registered or authorised with them. How does one do that? Well, it’s not entirely clear – so I decided to ask them. I was pointed towards a download page where, among a plethora of other information, listed under ‘Registers of Payment Services Firms’, you will find a register of the approved PISP and AISP providers that we are being told a customer should fish out and inspect in doing their due diligence when considering using a new third-party provider.
As of writing here are the numbers on registered entities in each category:
- Payment Initiation Service Providers: 12
- Account Information Service Providers: ZERO
When I first started researching this, there were 11 registered PISP’s. As of Dec 2018, Google (under Google Payment Ireland Limited) has been added, which gives you an idea of the new players positioning themselves for the market opportunity that PSD2 offers.
Processing Beyond Purpose – PSD2 & Data Protection
I’ve already mentioned that the lack of data minimisation currently in place – i.e. when TPP’s access accounts via screen scraping they have total access to every action the customer can perform themselves, is not limited only to their need.
Another area of concern is that the fraud prevention analysis that banks will have to perform in order to keep their instances of fraud within an acceptable range will likely result in a massive increase in data analytics processing on consumer transactions. The temptation to use this information for other purposes will be there. Data Protection Impact Assessments will be a key component of realising the data protection by design requirements of Article 25 of the GDPR when undertaking new processing such as this.
Behavioural biometrics has also been suggested as a method of enhancing secure authentication with PSD2. There have been valid concerns raised about using biometric profiling for this purpose. Biometrics is considered special category personal data and so would need an additional lawful basis under Article 9 of the GDPR for processing. The risk that this type of data could be used beyond purpose or result in a high risk to the individual should it be breached is significant.
PSD2 & The RTS Gap Period
We are currently living in the PSD2 wild west before the RTS comes into force in September this year. The practice of third-parties accessing financial data without what can be considered adequate levels of security has been going on for a long time, with banks and fintech companies wishing to offer their customers value-added services. It's been an open secret, one that banks have not been shouting from the rooftops that they allow.
What PSD2 and its introduction in January of 2018 has done is to force banks to state openly that they are open for business to third-parties, but screen scraping is currently the only risky, insecure and irresponsible way that it is facilitated by most banks as of this moment.
Banks are mandated to provide access to their new API’s in advance of the application date of the RTS in September 2019 so that providers can test integration with them. Banks who have not yet rolled out their API’s need to do so soon as the migration from these halcyon days for fintech of wild west screen scraping to a world of secure authentication via API’s is not going to happen overnight.
In the meantime, the cart is very much before the horse and consumers are at risk while we are in this grey area between PSD2 introduction and the adequate security standards needed to facilitate it.