Open to privacy

There’s so much that needs to be thought through about “open banking” before it turns into a thing across Europe. For one thing, we are a long way away from being able to go online and download a standard European bank account API (there is no such thing, by the way) and then activate it by obtaining an API from the European Bank API Management Centre (there is no such thing, by the way) by using a European Financial Services Identity (there is no such thing, by the way). As the Euro Banking Association say in their very good March 2017 working paper on “Open Banking: Advancing Customer-Centricity”, open banking "will require crucial developments in digital identity and APIs.

Let’s assume that these crucial developments happen. Then what exactly will we be able to do in the new open banking environment? There are gazillions of rules and directives and regulations that govern financial services and all of them will have to be interpreted and re-interpreted for API access. Some of the crucial constraints do not come from PSD2 itself but from other directions, such as the General Data Protection Regulation (GDPR). This may have some serious implications for Account Information Service Providers (AISPs) because it will restrict what data they can have and what they can do with it. Our good friends at Innopay pointed this out in a blog post earlier in the year.

We expect that the obligations that GDPR impose on AS-PSPs will significantly limit the possibilities for AISPs and other third parties to use account information in a way that would add real value for their customers. Although this may be a fair price to pay for privacy protection, it is unfortunate that it may hamper the development of innovative solutions for financial and other services.

From GDPR can significantly limit the value potential of Account Information Services

There may, however, be a way to get round this. Suppose that the information returned by an AISP query to the AS-PSP delivers persistent pseudonyms (in the form of meaningless but unique numbers, or MBUNs) rather than PII on counterparties? I understand that in the UK open banking sandbox the idea is to return a persistent MBUN and SIC code (so that the AISP can see, for example, see that you paid a fast-food retailer or a mobile network provider).

If you are wondering, SICs are Standard Industrial Classification codes. These are codes set by the government and used to collect and analyse data for statistical purposes. I’ll leave it to you assess their fitness for purpose, but will as an aside note that they may be in need for revision in order to be of maximum value to fintech entrepreneurs.  A National Endowment For Science, Technology and Arts (NESTA) report found it a trifle odd that there is no SIC for video games or graphene but there is one for whale oil production.

So, imagine that when an AISP queries my bank account they see my purchase of a season ticket for Woking Football Club (come on you Cards) they get back MBUN 12345 and the SIC code “Sports” or whatever. When they query again next year, Woking Football Club again shows up as MBUN 12345. But that is specific to me: it’s derived from the merchant ID for Woking Football Club, a bank ID for me and an AISP ID from the requestor. Every time that AISP queries my account they will see a Woking Football Club purchases as 12345 / Sports. But every time they query my friend Farid’s account, they will see his purchases from Woking Football Club show up as 67890 / Sports. And if hackers obtain these records, they will not be be able to reverse-engineer the MBUN. Only my bank can calculate that MBUN.

This seems to me to be a reasonable compromise.