Open banking and the AISP agent – views on the FCA’s proposed guidance
The FCA released a Consultation Paper (“CP”) in September 2018 (CP 18/25, available here) outlining its proposed Approach to the final Regulatory Technical Standards and… Read more
The FCA released a Consultation Paper (“CP”) in September 2018 (CP 18/25, available here) outlining its proposed Approach to the final Regulatory Technical Standards and EBA Guidelines under the revised Payment Services Directive (“PSD2”). In the CP, the FCA set out its proposed approach to a wide variety of matters under PSD2, including:
- Assessment of requests for exemptions to the contingency mechanism;
- Fraud reporting requirements;
- Corporate payment exemptions;
- Application of strong customer authentication requirements and associated exemptions;
- Approach to the regulation and registration of agents of account information service providers;
- E-commerce platforms; and
- Closed loop gift cards.
The below addresses one of these topics, the FCA’s views on agency and account information service requirements.
Agency requirements for AISPs – the background
The CP sets out the FCA’s proposed approach to agents of account information service providers, or “AISPs” – these being one of the two types of “open banking” entities created by PSD2, which are permitted to pull transaction data out of a customer’s account (with the customer’s consent) in order to produce some form of “consolidated information” using it, and display that consolidated information in an online service. This concept was originally designed to regulate already existing services that allowed a user to pull data out of numerous bank accounts in order to display a consolidated view of their financial position as a whole, but the potential uses of the data are far broader.
As with other payment service providers, AISPs may appoint agents to carry out, on the principal’s behalf, account information services. The principal is responsible for registering the agent with the FCA and retains responsibility for regulatory compliance by the agent. The Payment Services Regulations 2017 (implementing PSD2 in the UK) require payment service users to be informed of the agency arrangement; that is, the payment service user must be made aware that they receive payment services through an agent and must also know who the principal is. However, the plethora of different ways that data can be used, and the lack of legislation or guidance on what “agency” means in a data context, has made it difficult for many businesses to know where they stand.
The FCA has proposed guidance to clarify how agency arrangements work in the case of AISPs. Essentially, the FCA has set out two guidelines:
- if an AISP (Firm A) passes payment account data to another firm (Firm B), and Firm B uses that data to provide account information services (“AIS”) to its customers, Firm B must be authorised or registered with permission to provide AIS; and
- if Firm B is acting as Firm A’s agent it may present Firm A’s AIS service to users through its own platform, e.g., its website or application, … It must be clear to the customer who they are dealing with and that Firm B is acting as agent of Firm A, the principal. … Further, the agreement for the provision of AIS will be between the customer and Firm A, the principal.
The effect of the first guideline would be to increase the number of agents who would need to become registered in their own right for AIS – which may well come as a surprise to many who are planning to team up with an AISP that intends to provide data to them for use in their own service. As regards the second guideline, Firm B would have to be registered as an agent of Firm A but would not have to be registered as an AISP in its own right; however, Firm B would need to have its customers contract with its principal, which represents a departure from current market practice in payment services in which agents are free to contract with payment service users on behalf of their principals.
There are a number of broader issues with the approach outlined in the proposed guidance.
Regulated data vs any other data
The first is that in order to know whether you need to be an agent of an AISP, or even registered as an AISP in your own right, you need to know whether or not your activities fall within the meaning of “account information services”. However, the meaning of “consolidated information” – arguably the core concept in the definition of AIS – is so unclear that in many circumstances it may be impossible for some entities in a chain of data usage to know whether or not they sit within the regulatory boundary.
For example, using the FCA’s scenario above, Firm A, as a registered AISP has access to the Open Banking APIs and can pull transaction data out of a payment service user’s payment account with one of the major banks. Firm A then passes that data (all with the customer’s consent) on to Firm B, who takes that data and combines it with location data to show where the transactions took place. This would almost certainly fit within the AIS definition of providing “consolidated information on one or more payment accounts”. Firm B then passes the data to a separate service, Firm C, which takes the enhanced transaction + location data, and uses that to produce analytics on how much the customer has spent in which country so that it can recommend foreign exchange services. Is this analytics data still “consolidated information on one or more payment accounts”, or not? Does Firm C have to be regulated as an AISP, or to register as an agent of Firm A, or Firm B, or do nothing at all? The crux of the issue is that data – unlike funds – has gradations of derivation, and can exist in two places at the same time: without further definition of “consolidated information”, it is very difficult if not impossible to know what level of manipulation of the original transaction data has to have happened before that data has left or should have left the regulated sphere. In other words, when does regulated transaction data become just the customer’s “data”?
Who has access to the account
Another issue revolves around the fact that the definition is defined by the purpose for which the data is used, rather than by who has access to the underlying accounts to retrieve the data – which is surely the chief risk point in the process.
Take another example. A small business takes all of its physical receipts, and manually uploads them into a spreadsheet. An online service (let’s call it “XL-ent”) launches which allows the business to upload all its spreadsheets into a portal which then puts all the data together and provides a consolidated view back to the small business via a website. On a strict reading of the PSD2 definition of an AISP, and the refined definition in the Payment Service Regulations 2017, XL-ent would have to be regulated. This is because it fulfils all the criteria of providing consolidated information via an online service, and that consolidated information is “on one or more payment accounts” of another payment service provider (i.e. the small business’s bank). But from a big picture perspective it is bizarre that this should have to be regulated, given that XL-ent has never had direct access to the small business’s bank accounts, and is only using information that has been given to it directly by the small business itself. Take this one step further: if the customer were to ask XL-ent to provide that same data for Firm C to provide analytics, then would Firm C have to register as an AISP just for this one activity? Or as an agent of XL-ent?
These examples may seem contrived, but they are not. As soon as the open banking structures were announced, fintechs and other innovators started coming up with structures to take advantage of the myriad of different ways that data can be transmitted and transmogrified. There is already a wide array of structures in place and anticipated, where data is accessed from the bank account – the original risk point that the regulation was trying to address – and then used by other services, or chains of services, to the benefit of customers. Surely the real risk point here is the access point to the data itself – the initial data pull out of the bank. As long as it is clear that the regulated AISP that initially pulls the data out is ultimately responsible for the proper usage of the data then the main risk is protected – and this can be controlled by contract with those using the data further down the chain, by obliging those further down the chain only to use the data as explicitly agreed with the customer. As with other data chains, such as exchange market data, the perimeter of that control should in any case stop where the “consolidated information” has been derived far enough that the underlying data can no longer reasonably be reverse engineered from it.
This is not an easy position for the FCA to resolve. As much as they have refined the PSD2 definition, to the benefit of the industry, the original PSD2 definition to which they are necessarily anchored is purposive (what are you doing with the data) rather than risk-based (do you have access to the source data, and are you using it as the customer requested). It is of course correct to ensure that services that are directly taking the data and acting in the same way as an AISP would, are doing so in line with regulation. However, it would be highly beneficial to the burgeoning and innovative open banking data industry to have guidance on the extent of derivation needed before “consolidated information” is no longer regulated. Even better, it would seem to make more sense for full regulation to be required only for those with direct access to the underlying accounts (the “keys to the kingdom”), and for that regulated entity to be responsible for making sure – via a string of contracts if necessary – that anyone further down the data chain who is using consolidated information that can be linked back to the underlying transaction data, is doing so only on the express wishes of the customer. Without parameters of this type being put in place, which the FCA is well placed to do via its perimeter guidance and further examples of what does and doesn’t count as AIS and/or agency, there is a real danger that the pace and scope of innovation could be significantly slowed without any real benefit to customers.
Share this blog
- Adtech & martech
- Artificial intelligence
- Cloud computing
- Complex & sensitive investigations
- Cryptocurrencies & blockchain
- Data analytics & big data
- Data breaches
- Data rights
- Digital commerce
- Digital content risk
- Digital health
- Digital media
- Digital infrastructure & telecoms
- Emerging businesses
- Financial services
- KLick DPO
- Open banking
- Software & services