One of the major talking points surrounding PSD2 was the introduction of two entirely new categories of payment service: payment initiation services and Account Information Services (AIS). These were introduced largely to regulate services that were already being provided, particularly in continental Europe, without any regulatory oversight. However, the introduction of not only these new types of regulated service providers, commonly referred to as third party providers (TPPs), but also the regulatory structures through which banks and other account providers are obliged to provide consent-driven account access to such TPPs, opens up enormous potential for new innovation. This is particularly the case for account information services, where there is a myriad of possibilities for the usage of transaction data to create services that benefit consumers and small and medium-sized enterprises (SMEs) and assist in the growth of the economy overall.

Huge progress has been made in open banking in the UK, especially through the Open Banking programme driven by the Competition and Markets Authority (CMA) and the Open Banking Implementation Entity (OBIE). However, in relation to AIS there are a few points of difficulty caused by the structure of its definition and subsequent interpretation by regulators, which threaten to slow innovation significantly without any tangible benefit to customers.

Extraction vs. display

The first point of difficulty revolves around the difference between (a) the access point to the payment accounts needed to extract data, and (b) the way in which that data is then used and distributed. The definition of the regulated activity of AIS is essentially purposive: the activity is providing an online service which provides customers with ‘consolidated’ information “on” one or more payment accounts held with another payment service provider. In other words, the regulated activity is the display of the “consolidated information”. When the definition was originally put together, it was looking mostly backwards at existing account aggregation services, where screen scraping (the use of a customer’s login details to access accounts on their behalf) was being used to extract the data, and that data was then being used by the same entity to display aggregated information across multiple accounts.

The need to regulate such an intrusion into a customer’s financial information makes complete sense, but the definition of the regulated activity ignores the fact that there are  not one but two separate elements within any such service. In order to get to a point where you can display consolidated information in an online service, one first must extract the data from the payment accounts.

The difficulty arises because the extraction of data does not necessarily involve the provision of an online service displaying consolidated information, and the display does not necessarily involve extraction. It is perfectly possible for the two functions to be split, whereby one entity extracts data (but does not provide an online portal displaying it) and another entity then takes that data from the first company and does provide the online service to customers.

The splitting of these two functions is beneficial to the industry: it allows those who are skilled at building systems which connect to banking application programming interfaces (APIs) to focus on the efficient extraction of the data from the payment accounts, whilst those with the different skill set of data manipulation and display can focus on doing that. The fact that the definition of AIS lumps both functions together, and technically only regulates one of them, creates something of a Catch 22 situation for the “extractor” companies that want to provide the extraction element of this process but not the display: in order to extract the data they need to be registered as an Account Information Service Provider (AISP) in order to gain the access credentials that the banks demand, even if they have no desire to display it themselves; but in order to attain the AISP registration they have to meet the requirements of the AIS definition – which are all about display.

On the flip side, companies that are displaying data but have no desire to access the payment accounts directly are also given the keys to the accounts in the form of the AISP registration, which entitles them to demand account access from a bank even if they have no intention of doing this themselves. By way of analogy, this is a little like saying that anyone who wants to ride in the back of a car taking in the passing landscape, has to have a full driving licence and will be given their own set of car keys, even though you only need one driver sitting in the front. This can result in a conceptual contortion, with extractor companies having to create a display element in order to get their registration and car keys; while companies that are displaying data that has already been extracted by a regulated AISP need to have a driving licence to do so, even though they are bound by contract to use the data only as required by the customer.

The market has created some useful workarounds to these issues, whereby extractors classify themselves as technical service providers and issue access tokens (the keys) to the banks in the name of the registered AISPs who are just providing display. But this is surely an unsatisfactory situation, whereby the entity which is actually entering the bank’s data vaults does not have to be regulated, but the company which simply takes that data and displays it to the customer does. If the purpose of introducing this new regulated service was to ensure that access to customers’ financial information was handled more safely, this is arguably an odd way to approach it. The current definition also creates situations where a company can become registered as an AISP for providing one service which extracts and displays account information, but can then use those same access keys to extract data and use it in other services which, because they don’t involve display of the data, are not technically regulated within the scope of AIS at all.

I think there are two possible routes through which a third Payment Services Directive (PSD3) could address these issues. The first route is to regulate access to accounts on the one hand, and display of financial information on the other, as two separate activities. The second is to regulate only the access to accounts, on the basis that it would be up to the extractor company to control, by contract, the use of the data by any further recipient. This would ensure that usage of that information was carried out only in accordance with the wishes of the customer. There are arguments for and against each approach, which hang mostly on the viability of determining a workable regulatory perimeter based on the type of data being displayed.

“Consolidated information” and the regulatory perimeter

This leads to the second difficulty posed by the AIS definition, which is that it all revolves around the concept of “consolidated information on one or more payment accounts”, but there is no useful guidance on what “consolidated information” actually means. In many instances this makes it almost impossible for those looking to provide data-related services to know whether their services will fall within or outside the regulatory perimeter.

Again, whilst the definition was probably created with a particular set of existing account aggregation services in mind, where it is obvious that the information displayed is still sensitive, it does not deal at all well with the almost infinite gradations of derivation that data can undergo.

Take an example: if Company A is taking transaction data and displaying that raw data, clearly that falls within the definition of “consolidated information on one or more payment accounts”. If Company A then passes that transaction data to Company B, and Company B mixes it with location data to produce a new set of data showing the location where the customer spends most money, the position is less clear, and therefore Company B may be uncertain as to whether or not it needs to be regulated. If Company B then gives that data to Company C, and Company C mixes that data with merchant data so that it can display loyalty offers a customer is entitled to, it is even less clear. From a realistic point of view, it seems odd that the treatment of that last set of data could potentially be subject to a regulatory licence, even though the information being displayed is so very far removed from the original transaction data, and probably reveals little to nothing about the financial position of the customer.

There is a useful parallel here in market data licensing, where data sets, which are licensed out for often significant amounts of money and are heavily guarded by contract are often permitted to be used to derive new data. The standard position is that if the original data set has been derived to a point where the original data cannot reasonably be reverse engineered from it, it is out of scope of the control of the licensor. Therefore the display elements of AIS should be regulated in a similar way, such that the display of consolidated information should not be regulated under PSD3 if it is not reasonably possible to (i) derive the original transaction data from it or (ii) to discern the customer’s financial status or wellbeing from it. This is not to say that the use of derived data should not be controlled at all, as other bodies of law such as General Data Protection Regulation (GDPR), contract, intellectual property and confidentiality can be used to regulate that usage – but rather that the purview of a financial regulator should be limited to that which demonstrably pertains to a customer’s finances.

Conclusion

The creation of AIS and the related structures mandating banks’ provision of access to accounts has already brought real benefits to many companies and their customers. It is in no way surprising that innovators have – as is always the case – created services which legislators could not have been expected to legislate for. In the case of AIS in particular, in order to foster certainty around a sensible regulatory perimeter for those looking to innovate, and to achieve the safety levels which will facilitate the adoption of new services, it is necessary to revisit the definition of the regulated activity so that its constituent parts are each addressed in a way which is proportionate to the risks they pose.

 

This article is part of a collection from the EPA’s whitepaper ‘The Future of Payments Regulation: Voices of the EPA’. The whitepaper has been written by myself and fellow members of the EPA’s Project Regulator as we hope to start an important discussion on the future landscape of payments legislation. To download the full document hot off the press click here.

 

• Share this blog

• Twitter
• Facebook
• Linkedin