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
POST Open banking and APIs, again (Brexit edition)
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
- A data model (so that everyone knows what “account”, “amount”, “account holder” etc means);
- An API standard.
- A governance model.
- A security standard.
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:
- Grandma sees a page that she thinks comes from from Age Concern asking for access to her bank account;
- Grandma clicks OK and accidentally grants access to Eastern European fraudsters or, worse still, investment bankers;
- Grandma’s account is looted.
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.
You can’t spend a penny without being snooped on | David Mitchell | Opinion | The Guardian
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.
And here we go again!
xxx
“The financing of the terrorist attacks which took place in France in January and November 2015 have been analysed in detail by the Center for the Analysis of Terrorism, a leading European Think Tank on the analysis of terrorism. The report – The Financing of the Paris Attacks (in French) – concludes:
The January attacks against Charlie Hebdo cost € 26,000 and were funded essentially thanks to consumer credit fraud, including two car loans. For both attacks, the perpetrators used a mix of payment instruments including money transfer services and anonymous pre-paid cards. The report states ‘Anonymous reloadable pre-paid cards enable anonymous transactions up to €2,500, including over the internet. Anonymity is guaranteed at all levels, from the purchase of the card, to its reloading, making it the ideal payment instrument for the perpetrators of the 2015 attacks.’ “
xxx
POST Corrupting the blockchain
xxx
“Since then, I’ve thought to myself that anyplace where there is the possibility of fraud and corruption – money laundering, investing in sharia-compliant products, moving funds offshore, giving to charities, paying taxes, managing government funds and more – could be assisted by DLT. It could provide a fully transparent, tamperproof view of who paid what to whom. “
via Solving state corruption with technology – Chris Skinner’s blog
But how? Suppose all of the bank accounts in the UK are on a shared ledger and anyone can look at that ledger to see all of the transactions. Oh dear. Something of a privacy problem – it’s none of my business if Chris has spent his money on… well… you get the point. So clearly a transparent ledger is not practical.
So we’d better encrypt it then. Now you can see that I paid Chris but not how much or what for. But that sounds like no-one’s business but ours, doesn’t it? In which case, he should be using anonymous digital cash like Z-cash or eMoney or Mondex. That’s better. Now no-one can see that Chris and are paying each other. Now I can get on and bribe him to award me a contract. Oh wait, I thought we were against that? My head hurts.
POST Cards vs non-cards or cards and non-cards?
I saw an interesting comment about the recent Google I/O conference, referring to the opening up of the European payments marketplace under PSD2. It came in a discussion about Google wallet:
For now, the service is linked to a user’s credit card, but not for long (at least for European users), Daniel Döderlein, CEO for payments systems provider Auka, told Bank Innovation. “Once Google’s able to go to direct to account they will cut out the cards companies and to some extent, the bank,”
From Would You Like to Set Google As Your Default Financial Institution? | Bank Innovation
This resonated with a story that I heard last year and mentioned to a few of our clients in seminars and workshops. A friend of mine was on a study tour of the US during which he visited a number of different technology companies as well as a number of different technology users in a group of related industries. He told me that the whole time he was in the US, the only people who had asked him about PSD2 came from Facebook and Google. Not from banks, not from retailers, not from payment processors and not from card issuers. Yet, as I think comes over in our recent webinar on threats and opportunities, PSD2 is a fundamental driver for all of their strategies for the foreseeable future.
When my friend came back from California with his tale of PSD2 indifference, I remember thinking at the time that it might be an indication that not all of the participants in the payment marketplace had fully evolved their open banking strategies. Hence I explained to him that as PSD2 was going to completely change the way in which consumer data is managed by banks, it was natural that banks had no strategy for dealing with it whereas people who sell consumer data for a living (e.g., Facebook and Google) would undoubtedly have already created and explored a number of different scenarios and set a strategy to exploit the changes.
Is that rather dramatic Google I/O comment justified though? Is it right that once the banks are required to open up their APIs and are forced to allow third parties to obtain account information, instruct payments and obtain confirmation of available funds, will those third parties cut out the “card companies”? In other words, is open access bad news for, to choose the obvious examples, Visa and MasterCard? Well, that depends. I remember answering this question a couple of years ago at a conference by saying that if the people that Consult Hyperion were working for at Visa and MasterCard were stupid, then it was a threat. But since the people that we were working for at Visa and MasterCard were not at all stupid, and could read the newspapers just as well as we could, I thought that on balance the new infrastructure would present an opportunity. At the time, of course, I couldn’t have foreseen that MasterCard would step up to the plate and pay $1 billion for VocaLink so quickly, thus ratifying my conclusion!
“Somehow this takeover didn’t make the news headlines, but mark my words it was one of the most significant events in the evolution of the UK payments industry since Reg Varney got a tenner out of that first ATM in Enfield half a century ago. It’s a significant milestone on the road to #cardmaggedon, and it’s not only me who thinks this.”
via MasterCard and VocaLink is a big deal | Consult Hyperion
The reasoning behind our general advice to clients at that time was that the network itself, the technological component of a scheme (the interfaces and switches and connections) is easily replicated, but the non-technological components (the “3Rs” of rules, rights and relationships) are much harder to create and manage. This where Visa and MasterCard have half a century on the competition. I saw this view echoed in a recent magazine article.
It is felt that as the distinction between cards and other forms of payments (e.g. credit transfers) breaks down, the management experience of card schemes positions them well to extend into these other payment methods rather than being replaced by them.
What is comes down to is that sending money from account to account over instant payment rails is ultimately cheaper, quicker and simpler than messing around with 16-digit PANs, authorisation networks and settlement files. As many industry observers have pointed out, in the long run the “push” payments will win. However, sending the money around is only a very small part of a real-world, mass-market, effective payment infrastructure. The rules, rights and relationships may well be simpler than in the world of the 16-digit PAN but they still have to be there. Someone still has to set the messaging standards, define the format of the associated data, draw up merchant agreements and so on. At the excellent Merchant Payment Ecosystems conference in Berlin earlier this year, I chaired a terrific panel session that touched on this issue.
//embedr.flickr.com/assets/client-code.js
The key concept that came out of this discussion, that the traditional merchant acquirer will transmute into a Merchant Service Provider (MSP), fits within this narrative. I can see that merchants want value-added services, a great many of which depend on collecting and analysing large quantities of data, rather than just “cost plus” payment processing.
So, will Visa and MasterCard be bypassed by open banking? If they do nothing, then yes. Facebook, Google, Amazon, Alipay and others will simply go direct to consumer payment accounts via APIs and payments will begin to drift away from the 8583 rails put in place over many years.
British Airways introduces new automated biometric technology – International Airport Review
xxx
“A digital facial scan of the customer is recorded when they travel through security, and when they arrive at the gate, their face is matched with this representation when they present their boarding pass – allowing them to board the aircraft.”
British Airways introduces new automated biometric technology – International Airport Review
xxx
POST Faster fraud
Some good news arrives from our friend at Financial Fraud Action (FFA), the body tasked with reducing financial fraud in the UK.
Remote banking fraud losses totalled £137.1 million, a 19 per cent decrease from £168.6 million in 2015.
From Financial fraud data for 2016 published : Financial Fraud Action UK
Great news. Except…
“But the report failed to include any reference to one form of crime that is on the rise and blighting victims’ lives: bank transfer fraud.”
Oh dear. Having made it easier to transfer money between bank accounts, criminals have t
“After it was realised this was a scam, your bank contacted the Italian post office where the funds had gone but the money could not be retrieved.”
xxx
xxx
“It was only on closer inspection that they saw underneath the displayed name that the email address was not his own.”
I must sound awfully harsh but I do not see what the bank has done wrong here. They were instructed to transfer money and that instruction was properly authenticated. It is not there fault that they were asked to transfer money to a fraudsters account.
The real problem here is using e-mail to instruct bank transfers. That’s negligence, since we all know that e-mail has no security. I would suggest that for accountancy firms and all others, all messages containing financial information be sent by Signal or for that matter WhatsApp (which has our Home Secretary’s enthusiastic endorsement as a platform for secure communications).
There was (yet another) discussion about these frauds on the BBC’s MoneyBox recently and I made a passing comment about how easy it would be to find out who the fraudsters are an arrest them. My point was that instant payments go to a bank account and since we have famously strict and well-observed Know-Your-Customer (KYC) laws maintained at great expense by the British bank industry, so it should be easy to send the police the details of who to arrest.
“TSB said… In this instance the scammer used valid ID”
Well if it was a valid ID then bob’s your uncle. Should be easy to round up the perps. But not so…
“In some cases the original account is opened by a student or temporary British resident who is later – perhaps when they are leaving the country – persuaded to ‘sell’ the account to a fraudster for cash.”
Interesting. And it’s not, a first glance, obvious what to do about this other than to make it a criminal offence to let someone else log in to your bank account.
Cash free for a month: an experiment in new ways to pay
xxx
“But did paying for everything with a card mean he spent more? ‘It’s certainly less tangible, you don’t see the money flowing in and out but I don’t think I’ve spent more or less than I would otherwise have,’ he says, adding that it can be even easier to keep a track on mobile payments with your phone, as you get the detail immediately on how much you’ve just spent – and on what. ‘It certainly makes expenditure on small transactions much more visible,’ he says. So, if you’re spending an excessive amount on regular coffees for example, you’ll learn soon enough once you start using the app.”
xxx
How do you define RegTech?
xxx
RegTech has been supplying some of the best use cases in banking. From the early customer engagement stages like KYC and Identity to compliance management, risk and reporting, the potential to reduce costs and create new customer engagement opportunities is tremendous for RegTech. Banks are also actively looking for solutions to better interfaces with regulators.
xxx
Snippings 