A library of snippets
xxx
categorizing all unreported cash as “black money” risks putting into one policy basket the multiple (and legally valid) contexts that lead people to keep money hidden and store value in cash form. In particular, a large section of women, including many belonging to the middle class, have had good reasons to hide their small savings in rice bins and cosmetic jars, away from husbands and other family members.
xxx
xxx
Amazon, Apple, Google, Intuit, and Paypal just asked Congress for a unified federal alternative to state money transmission licensing. In a letter to congress, their industry group, Financial Innovation Now, explained how state-by-state money transmission licesing is a major impediment to innovation in financial serivces here in the US
xxx
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.
xxx
Over in the Livery Hall, a lively discussion about open banking was introduced and expertly steered by Dave Birch, head of innovation, Consult Hyperion.
Well, to be honest to success of the Open Banking session was more to do with the fact that the expert panel were actual experts and that they were prepared to share their genuine opinions than it was to my steering.
//embedr.flickr.com/assets/client-code.js
The panel, it seemed to me, were very clear about the priority of organisational strategies for the open banking world.
xxx
Banks operating in the EU will be able to verify the identity of customers and carry out due diligence checks on a wholly digitised and cross-border basis under plans outlined by the European Commission.
From Digital ID and fintech at the heart of new EU consumer financial services action plan
When the Commission say “digital identity”, they are talking about electronic identity schemes as set out their rules on e-ID and trust services (e-IDAS). To the best of my knowledge there is, at the time of writing, only one scheme “notified” to eIDAS and that is in Germany, so we are a long way from a universal eIDAS infrastructure, which is why I tend to think that a sector specific financial services identity (“financial passport”) might be a more practical way forward if we are going to tackle the escalating costs of regulation.
The good people at BBVA Research recently published a paper on central bank digital currencies (Central Bank Digital Currencies, Gouveia et al, March 2017) in which, amongst other conclusions, the authors say that “we also consider it likely that a scenario in which CBDC is anonymous, universal and non-yield bearing will be implemented”. But why is this “likely”? Why would any central bank bother setting up the form of distributed ledger that the authors envisage in order to implement something of such obvious utility to criminals, terrorists, money-launderers, tax-evaders and corrupt politicians? I don’t get it.
xxx
“‘If all I want to do is take your phone and use your Apple Pay to buy stuff”
That Fingerprint Sensor on Your Phone Is Not as Safe as You Think – The New York Times
xxx
How fun was Innovate Finance Global Summit 2017 at the Guildhall this month! Great agenda, great speakers, great location and sunshine!
//embedr.flickr.com/assets/client-code.js
xxx
We all know that “Open Banking”, by which I mean a regulatory environment that enables third-parties to have access to banks’ accounts (with the informed consent of the account holders, of course) is on the way. Regulators around the world are looking at what is going on in Europe (where the regulators are forcing banks to open up to third party service providers) and what is going on in the U.K. (where the government has decided that open data in banking and open access to bank accounts is the best way to bring competition and innovation into the sector) and beginning to formulate similar strategies. Whether it will involve the security standards of the European Union or the access structures of the U.K. is beside the point: whichever jurisdictions you are in, open banking is on the way and you should begin formulating your open banking strategies now.
Why? Well, what sort of things might you learn about somebody if you have access to their bank account? All sorts of things, actually. For one thing, you would learn that they exist, assuming that stringent and expensive know your customer (KYC) regulations have been effective. If you are match.com then merely knowing that I am a real person and actually exist might be the most important thing you need to know about me. For another thing, you would learn how much they earn. If you are Nationwide thinking about granting the customer’s mortgage applications, then this could save an awful lot of form filling and delays and mistakes. For another thing, you might learn how much they pay for gas and electricity and car insurance and a great many other utilities paid for by direct debit. If you are a comparison website, a consumer organisation or a rival utility, then this information is incredibly valuable to you and my even result in a better deal for the consumer.
This is all going to happen. When it comes to open banking, the U.K. is a global case study. Within a few months, open banking will be a reality and there will be mass-market players with millions of customers participating in a radically new financial services industry. No more bilateral agreements to obtain the rights to screen scrape to aggregate consumer data and no more have to have customers log in to execute transactions.Allowing third parties to have access to bank accounts is what we now call “open banking”. We are talking about direct access here: not “screen scraping” by getting hold of usernames and passwords to masquerade as the account owner but through Application Programming Interfaces (APIs) that give access to bank systems. Just as when I log into a website and it asks for permission to access my Facebook account now, I will log into Facebook in the future and it will ask me for permission to access my bank account.
To understand how this is going to come about in the U.K. you need to understand the the U.K.’s unique open banking landscape, which I have to say is advanced by comparison to other jurisdictions. Way back in 2014, the Treasury published rather a good report on open data in banking. Then, in February 2015, they began a consultation process about the next steps and the chosen next step was to create an Open Banking Working Group (OBWG) to bring together relevant stakeholders through the Open Data Institute (ODI). These stakeholders, including industry bodies such as Payments UK and the British Banking Association (BBA) as well as representatives from a variety of financial services organisations, were expected to look at how to implement open banking in practice and come up with recommendations for the industry.
The OBWG report was published in 2016. It was really a holding document, setting us on a path to allowing access to the open data held by banks while leaving proprietary data alone. (I imagine the discussions about what data the banks consider “proprietary” and what data the banks consider “open” must have been rather convoluted.) The document set out a four part framework, comprising
That last part, security, is critical. If people are going to start fiddling with each others’ bank accounts then we’d better be pretty sure that the identification, authentication and authorisation of the fiddlers is up to scratch. There are significant risks around this. I can paraphrase them easily as:
How does Grandma or, for that matter, anyone else know that who they are granting access to and what they are granting access for actually corresponds to what is on their computer screen? Well, as the report pointed out they cannot. Hence requests for access can only come from organisations that have been registered previously with some sort of database or directory (we’ll come back to this point later on).
(I might also point out that where the document talks about Grandma giving “informed consent” I automatically shiver. Having been involved in a couple of previous projects for the European Commission to try to explore what “informed consent” actually means and how the general public might be supported in giving it, I can tell you that it is a minefield. I can imagine the Uninformed Consent lawsuits might make Payment Protection Insurance mis-selling look like a walk in the park, hence the comment from y good friend Izabella Kaminska at the Financial Times that “API is the new PPI”!)
A sound way forward on security is what the OBWG reported called contextual limitations. The permissions granted to third-parties (you can think of them as “tokens” given to the third parties) should be circumscribed. They should be for a fixed time, for a fixed purpose, for a fixed provider. So if I give Saga permission to look at my bank account, that permission should be for (say) 7 days maximum, read-only and only for transaction data. Then if someone steals it, and they are not from Saga, they won’t be able to use it. And if they are from Saga, it’s only good for a few days.
Now on to the APIs.
Last year, the Competition and Markets Authority (CMA) published their “remedy” for more competition in the British banking sector. This included a requirement for the nine largest current account providers to make available to authorised third parties (i.e., TPPs):
Standardised product and reference data (by 31 March 2017);
With customer consent, secure access to specific current accounts in order to read the transaction data and initiate payments (by January 2018).
From Open Banking and the CMA remedies for retail banking | Payments UK
What’s more, as the remedy requires the access to transaction data and payments to be implemented using an open API framework, the U.K. had the banks fund “The Open Banking Implementation Entity” to develop the necessary APIs. These are called the “read-only” APIs as described in the OBWG framework and the “read-write” APIs that the CMA wanted in addition so that third-parties can instruct transactions.
Meanwhile… on 17th July, the U.K. Parliament ratified Statutory Instrument no.752 (2017) to transcribe the European Commission’s Second Payment Services Directive (PSD2) into U.K. law. In a rational world, there would be no need to develop Open Banking APIs for the U.K. because we would just use the APIs developed for use across Europe to implement PSD2 in a cost-effective and safe way. PSD2, however, does not contain any standards or standardisation process and there are no national competent authorities linked to PSD2 (note; competent doesn’t mean what you think it means in this context). However, there are other bodies who are working on standardisation to support implementation and the EBA is probably the place to start to try to understand what is going on since they were tasked with creating the Regulatory Technical Standards (RTS) on strong customer authentication (SCA) and secure communication (which isn’t really technical and isn’t a standard).
Regulatory Technical Standards on strong customer authentication and secure communication under PSD2
The SCA-RTS is not an API specification. Actually isn’t a specification of any kind. Oh, and it’s important not to confuse the EBA with the EBA, by the way. This is the European Banking Authority (EBA) based in London. The EBA based in Brussels is a different organisation.
“The Euro Banking Association (EBA) is a practitioners’ body for banks and other service providers supporting a pan-European vision for payments.”
So let’s call that EBA-Brussels to distinguish it from EBA-London from now on (although the Commission is looking to move EBA-London to EBA-somewhere-else following Brexit). Last year, EBA-Brussels published a report on PSD2 and it’s impact that made some interesting observations about the practicalities of PSD2 implementation for Account Servicing Payment Service Providers (AS-PSPs), noting the need for at least a minimum standard for APIs in order to avoid a fragmented approach and that also that such a standard could enable value-added Open APIs with additional information and functionality available for TPPs. This makes sense. But who will actually do this?
The European Retail Payments Board (ERPB) has three expert subgroups working in the field. There is the ERPB-WG on APIs (i.e., the TPP to AS-PSP interfaces), the ERPB-WG on the identification of TPPs (since as noted earlier some form of directory will be needed) and another ERPB-WG on general issues. As I understand things, the identification is being built on eIDAS but I think I’m right in saying that there is only one “notified” eIDAS scheme at the moment so there may need to be some alternatives. I suppose the participants could put the directory on a blockchain but at the moment they are thinking about some form of centralised repository. Blockchain or database, none of this exists and I don’t know that anyone knows how it will all work.
“The Berlin Group, a-European payments interoperability coalition of banks and payment processors, is pushing a single standard for API access to bank accounts to comply with new regulations on freeing up customer data under PSD2.”
Meanwhile, the Berlin Group API standardisation initiative set up by the major players in the payments industry has been putting together a framework for access to accounts to deliver the functions for confirmation of availability of funds, payment initiation service (PIS) and account information service (AIS) as set out under PSD2 (what is generally referred to as XS2A). The group is liaising with OBWG as well as CAPS, W3C and so on and its “NextGenPSD2” task force will be publishing its API standard (well, set of standards: the AS-PSPs will choose which of them to support) sometime soon so that payments industry participants can begin building new systems and services. There are, naturally, a few issues to be resolved around service definitions, data models, event handling, security levels, participant identification, authentication, messaging, architecture and so on but I’m sure these are minor details. Who knows what will emerge, but some people envisage REST APIs with ISO 20022 messaging (standardised by the Berlin Group).
Though there are differences in scope between the two regimes, consideration is being given to how open application program interfaces (APIs) being developed under the open banking initiative could be used to support access to payment accounts and data by PISPs and AISPs under PSD2.
From Expectations on PSD2 interactions between banks and fintechs clarified by UK Treasury
Right now, then, in the U.K. we have the “read APIs” that are broadly equivalent to the APIs that will emerge from PSD2 to support the AI-PSPs implementing the AIS and the “read-write APIs” that are broadly equivalent to the APIs that will emerge from PSD2 to support the PI-PSPs implementing PIS. The read-only APIs were put out for public trial a while back and the first read-write API has just been released. It would be great if the European banks would just use the same APIs.
We are also building our own UK TPP directory separate from the TPP directory under development in Europe although these will presumably have to interoperate as some point (I did think that the TPP directory might actually be a valid use case for a shared ledger of some kind but in the UK the Implementation Entity is building database). So, to summarise: in a few months the U.K. will have all of these APIs in place for millions of customers. You can go to github and download the APIs to play with them already if you want to. This combination of regulatory framework, practical implementation and new competition is why it makes senses for bankers, regulators and technology providers in many different countries to take the time out to look at the European environment (which is separating banking and payments regulation) and the U.K. environment in particular.
I’ll finish by noting another recent U.K. development. The Bank of England has decided to allow non-banks to have settlement accounts and therefore obtain access to the payment infrastructure, meaning that PSPs that qualify for these new accounts will not have to use API access via a bank to instruct transfers because they will be able to do it themselves.
The widely-trailed move is expected to open up a competitive space which has long been the preserve of the UK’s biggest incumbents, providing non-bank PSPs with direct access to the UK’s sterling payment systems that settle in central bank money, including Faster Payments, Bacs, Chaps, Link, Visa, and, once live, the new digital cheque imaging system.
From Bank of England comes good on promise to provide non-banks with dir…
This adds another dimension, and more vigour, to the U.K. financial services sector and I am hardly alone in thinking that it will lead to an incredible variety of products and services that will change the banking sector for good.
xxx
“The electronic endorsement of a bank, an organisation accountable to no one but its owners, is required.”
via You can’t spend a penny without being snooped on | David Mitchell | Opinion | The Guardian
As it happens, this isn’t true since, as I myself blogged some time ago, you can pay using Avios points.
Snippings