Taking a chance on TPPs: a road banks cannot afford to follow
Despite all the new and varying financial players in today’s market, banks still hold a vital position in society. Firstly, they play a huge part in ensuring the stability and the integrity of the financial system. Secondly, even in the face of high-profile issues over the last few years, they are still the most trusted financial service providers in the eyes of consumers. Any imprudent behaviour from banks has been shown to have disastrous consequences for customers and the economy of not only their country, but an entire continent and even the rest of the world. With the foundations of their reputation built on security and the far-reaching ramifications of any potential failures, the stakes have never been higher for banks as they start to open their doors to TPPs under PSD2.
Mapping the risks and responsibilities
Over the years, court rulings and the regulators’ attitude towards banks have shown that their responsibilities have expanded. Some of this has been driven by legislation, some by customer expectations and some by inference. PSD2 has both solidified and reshaped this even further.
In a previous blog, I highlighted that there is no explicit obligation on banks to verify the authorisation status of TPPs. However, it is expected that if something goes wrong, customers will turn to the bank for resolution. In my blog I outlined a very likely future scenario; a TPP misuses data, where authorisation has actually been withdrawn – and then they disappeared. If the bank had not checked their status and granted access, they would be accountable. In my view, the assumption of responsibility is very clear in this example.
Courts often find it relevant to establish the level of duty of care by determining whether or not a negative impact on the customer could have been foreseen. It seems pretty evident that this criterion is fulfilled in the above example. Common law has established that a duty of care is owed where a person be harmed by the action (or inaction in certain cases) of a bank. However, even though a duty is owed, no liability attaches unless the harm suffered was of a foreseeable kind. Given the sensitivity of the data a TPP would gain access to, the risk of loss to the bank account holder if the TPP turns out to be unauthorised (by revocation or otherwise), is high. That loss is most definitely foreseeable, so if a bank had not acted despite this, they could be held responsible.
Pinning down ‘duty of care’
A bank’s duty of care is a complex issue. Different jurisdictions across Europe deal differently with the question and each legal system and court may even give different answers about where a bank’s duty of care begins and where it ends. This is not only based upon the law, but also upon the current climate and economy at that moment in time. For instance, after the financial crisis we saw a number of cases that were treated differently than before.
By no means do I intend to imply I can predict the outcome of any customer claim against a bank for misuse of his/her data by a TPP who has disappeared. I do, however, want to acknowledge the fact that there is a clear risk of banks being held responsible, in accordance with their duty of care.
Often the duty of care of a bank is developed by case law and subject to a constant shift. Some countries, like the Netherlands, have founded general banking conditions. The general banking conditions applicable to Dutch banks for instance start with: “The Bank shall exercise due care when providing services. In its provision of services, the Bank shall take the Customer’s interests into account to the best of its ability. None of the provisions of these General Banking Conditions or of the special conditions used by the Bank shall detract from this principle.” UK banks are subject to the general principles for business as laid down in the FCA’s Handbook, which includes a general requirement to carry out business with skill, care and diligence. A bank’s duty of care is considered a special duty of care and one that is very broad.
An assumption of a bank’s responsibility in the scenario I’ve highlighted may even follow from existing PSD2 provisions such as article 73 on unauthorised transactions, where the bank is responsible for immediately refunding the bank account holder. If a PISP was involved and the latter was to blame, it will still be up to the bank to get the sums paid to the bank account holder and then get reimbursed by the PISP. If the PISP has then vanished, the bank takes the financial hit.
Article 89 of PSD2 also places the responsibility on the banks for non-execution, defective or late execution of payments, again, even when a PISP was involved and responsible. The bank would then need to chase the PISP on its own accord.
Of course, many do believe that the solution is a straightforward one – for banks to ensure they check the available registers maintained by independent authorities and even better, the one introduced with PSD2: the EBA register. Unfortunately this is not a route that is as simple as it seems….
Reliance on public registers will not suffice
I spoke about the flaws of the EBA register in my previous blog; the first issue being that the register is not real-time, which leaves a huge margin for error.
The EBA has warned users wishing to download information that there may be be ‘a discrepancy between the information contained on the download and the information contained on the actual register’ - depending on the time of the update of the file information and the timing of the download.
Secondly, we can’t ignore the (in)famous disclaimer that the register actually has no legal significance. In fact, the EBA’s responsibility is limited to what they call ‘accurate reproduction’ of information from national authorities only: ““Disclaimer: The present Register has been set up by the EBA solely on the basis of information provided by national competent authorities of the EEA Member States. Therefore, unlike national registers under PSD2, this Register has no legal significance and confers no rights in law. If an unauthorised institution is inadvertently included in the Register, its legal status is in no way altered; similarly, if an institution has inadvertently been omitted from the Register, the validity of its authorisation will not be affected.”
Unfortunately, the NCA (National Competent Authorities) registers also have flaws. Information from NCAs is non-standard and inconsistent. Plus, the available information is generally not machine-readable, for instance, the Liechtenstein and Ireland register are a pdf document. Some authorities hold data in different registers depending upon the type of payment service provider (e.g. credit institution versus EMI versus payment institution) and different languages make it no easier to navigate.
The information provided in the registers is not complete, some do not include much information or any information about an institution’s passporting rights (again the Liechtenstein register is an example here).
Even worse, a quick glance at an authorisation status on some registers may not be sufficient to rely on. For example, UK fintech Ipagoo’s status was suspended in July 2019, but they still keep an authorised status in the headline of the FCA’s register, with a comment about the suspension added somewhere further down in the records. The suspension explicitly states they cannot carry out any activity for which they are regulated for, but as stated they are still authorized.
Finally, the EBA does not include banks that are performing TPP services. They have a separate register. This means reliance on the public registers would mean at least checking the EBA register for PIs and EMIs, the EBA register for credit institutions, checking in those registers which home member state the TPP has its license and then finally checking that NCA register (which could be only manually depending upon the register format). And all this while the TPP is knocking at the door for access.
eIDAS certificates are also not the whole answer
Banks will rely (and are legally required to rely as per PSD2) on eIDAS certificates for identification and authentication when establishing a communications channel. The eIDAS certificates include the authorisation number of the TPP, its PSD2 roles, (at the time the certificate was issued) and the name of the NCA where the TPP is registered.
Because the certificates only confirm regulatory status at time of issue, they do not reflect any information on revocation or an altered status which happens later on. Where a national regulator withdraws authorisation from a TPP, this will not be reflected in the TPPs eIDAS certificate. Since there is no EU-level statutory framework that mandates how the national regulator and the relevant Qualified Trust Service Provider (QTSP (the parties that issue the eIDAS certificates) should work together, there may be a time delay between the withdrawal of authorisation and the revocation of that TPP’s eIDAS certificate – or worse still, the certificate may not even be revoked at all, so the change in status is not easily visible.
The EBA has suggested to NCAs a voluntary mechanism for cooperating with QTSPs in relation to revocation of eIDAS certificates in case of an authorisation withdrawal, but not suspension. But this is only voluntary so cannot be counted on given the number of other required obligations that these parties are dealing with. While the majority are likely to adopt this mechanism, four regulators (Germany, France, Ireland and Czech Republic) have already indicated they will not, without their reasons being entirely clear.
What is the solution?
It is vital for banks to build in real-time and continuous status checking, to make sure that they have thorough and up-to-date visibility of a TPPs status. Whether the solution is in-house or outsourced, it is important that it takes into account the above concerns with the public EBA and NCA registers.
Banks need data in real-time as TPPs’ authorisation status may change, especially in the introduction of newly regulated market players. Over time, regulators will still need to weed out any organisations looking to abuse the new market opportunities. This isn’t always clear at the time of authorisation being granted, but can come to light during ongoing business and after complaints. Any action taken by the regulators must be immediately picked up by banks to make sure they don’t leave their customers – and themselves- open to the risk of unscrupulous or incompetent TPPs.
For those banks looking to cover off this risk quickly and comprehensively, there are a few providers who are addressing the practical issues arising out of PSD2, with private registers including real-time TPP identity and regulatory status checking (and some even provide insurance on the information they provide further reducing the risk liability for banks). As with any outsourced solution, it is of course important to make sure it meets your individual business needs and also has all the components needed to mitigate risk, uphold duty of care and protect consumer trust.
Share your thoughts in the comments!
Freeform: Enterprise Account Executive @ VergeSense | Data-driven decisions for modern workplaces.
5yGreat piece and indeed it is a very evident challenge you are outlining, Nadja. It would be of worth for you to have a look at one of our #marketplace partners – Konsentus. They are one of a few (if not the only one) who are on a mission to ensure banks that they’re only providing data to regulated and known entities.
Founder, consultant, technologist. Currently building isAI - a system to promote AI legal conformance. Consulting on AI investment strategies (hype avoidance, value identification...) and system architectures.
5yThis is a very good article. What we have here is a collision of regulated banking ways of doing things and start-up ways of doing things. My reading is that European regulators wanted to get more innovation into the banking and payment industries so set out on the PSD2/OB journey, but you can't have innovation without risk and the banking industry is, rightly, risk-averse. One of its roles (which it occasionally forgets!) is to look after others' money. We've ended up with an awkward compromise. The ASPSPs are obliged to do business with any TPP that is licensed. The TPP licensing is at a lower threshold than bank licensing and, as the article points out, the registries are non-realtime. Good luck with all that. My company reached the conclusion that the difficulties around PSD2 and Open Banking are going to take a few years to play out and that it's un-investable from an organic start-up position. By this I mean that you either have to have deep pockets, or stay out. We decided to stay out and focus on other things. I think the real pity in all this is that it doesn't look like playing out well for the consumer. The AISP side of Open Banking may work out; the payments side - the P in PSD2 - is looking less promising. Meanwhile, the regulatory industry trundles on.
Designing IT Solutions
5yFUD
Corporate Law | Internet Law | EU Law & Regulation
5yNadja, interesting. Tks. PISPs and AISPs when exclusively providing those services cannot hold client funds. However, if a TPP is authorised to provide a wider range of payment services, then yes these issues one has to consider. In payments, aligning, the tech stack, GTCs and operations is so important. Tks, Paul
Fintech Chairman/NED | Investor | Advisor | Awards Judge | Keynote Speaker | Influencer; CEO Polymath Consulting, CBI approved PCF2 and PCF3
5yGreat article on what FIs need to consider on TPP regulatory and identity checking.