#PSD2: An Account Information Service Is Not Really A Payment Service

There are good reasons why an "account information service" (AIS) became a regulated "payment service" under the not-so-new Payment Services Directive (PSD2). Chief among them was retail banks' decades-long refusal to allow retailers and other unregulated service providers access to the data in their antiquated systems at all, let alone seamlessly via 21st century "application programming interfaces" (APIs) that are now commonplace. Resolving those concerns sparked formal registration and other complex regulatory and technical requirements on service providers wishing to enable the sharing of payment data (AISPs), including a lot of unfortunately necessary detail in the Directive about customer authentication and information security. Yet years after PSD2 was set in stone confusion still reigns over exactly what an AIS actually is or is not, both as defined in local payments regulation implementing PSD2 and how such services work commercially - especially because an AIS rarely stands alone...

The FCA is doing its best to clarify the regulatory scope of an AIS, including confusion about who might be the AISP, when a firm would require formal registration as an agent and how to benefit from the exclusion for 'technical service providers' (see Q25A of its Perimeter Guidance on payment services). But those issues are merely the tip of the iceberg.

The major problem is that an AIS is primarily a data service (and one which involves personal data at that). This means an AIS attracts the need for several sets of regulatory consents and specific information to be included in customer contracts, as well as the typical series of contractual licences to receive and use the data itself. 

The challenge to getting all this right is that it's rare for payments regulatory specialists to know very much about data licences, or for lawyers who specialise in data licensing to know anything about PSD2. It still feels strange to me to have spent a career on both sides of that divide - veering from financial information service licensing at Reuters, to e-commerce specialist at DLA, to payments specialist at Earthport, to P2P lending at Zopa (which involved licensing of user-generated content and market data) and back to payments at Amazon and WorldPay. And even though I've also continued to advise private clients on all types of services since 2005, there's still very much a sense of 'switching hats' when working through the various issues. 

So what are they?

Regulatory requirements for an AIS

From a regulatory standpoint the multiple sets of rights needed to supply an AIS include:  

• explicit consent from the customer for the supply of the AIS itself (under payments regulation) - note that that 'customer' does not include a third party with whom the customer wants to share the data; and
• under data protection regulation, explicit consent (or some other legitimate basis) for the collection, processing, sharing etc of the data itself, to the extent required to deliver it to a third party - as well as for the processing etc of that data by the third party (which may be tackled via the third party's own privacy policy and data consents).

In addition, payment services regulation specifies certain information that must be included in either an ongoing or single use service contract with the customer.

Meeting these requirements is complicated by the fact that the customer is also likely to be using the AISP's platform to be receiving and sharing data from other types of personal account that are not regulated. So the payment-specific regulatory requirements have to be met within a context where unregulated data services are also being provided.

Commercial requirements

From a commercial standpoint, there are numerous copyright licensing issues to consider regardless of whether the data being shared comes from a payment account or some type of unregulated account. Indeed, the data being contributed and shared could come from the customer herself (user-generated information or 'UGC'). In effect, even the information coming from the user's accounts with third parties is effectively user-generated, particularly in terms of whether the service provider takes responsibility for its accuracy and so on.

These licensing issues must also be considered in terms of what licences are required 'upstream' from the customer, the service provider and any sources of data, as well as downstream licenses - and usage restrictions - from the standpoint of the service provider, the customer and third parties receiving the data. These licences are likely to be reflected in an array of different contracts, including customer terms and commercial agreements. Appropriate disclaimers, exclusions and limits on liability must also be considered.

This is where the sanity of specifically regulating payment account information services becomes questionable, as some of the typical commercial requirements may conflict with the liability and information requirements relating to an AIS, in which case it would need to be 'carved-out'.

Conclusion

These are not the only issues related to the supply of account information services or other data services, but they do illustrate the complex challenges arising from the fact that AISPs had to be subjected to regulation for banks to cooperate with them, and yet an AIS involves the supply of data in a way that other regulated payment activity does not, often in combination with other data services.