Fulfilling the aims of regulations intended to improve competition in banking could benefit incumbent financial service providers as well as the businesses and consumers the regulation is aimed at – but only if those incumbents embrace the spirit of the legislation and engage with the wider universe of participants.
In addressing the requirements of the European Union's second Payment Services Directive (PSD2) or the UK's Open Banking Working Group, incumbents will also be able to address many of the issues that face them as they seek to find a new role in the emerging digital economy where they will have to partner with new players and collaborate with existing competitors in a flexible and dynamic way that their systems and processes are not currently capable of handling.
Deadlines are tight, and guidelines are vague
Efforts to develop standards for banks to provide third-party access to customer account information are at risk of fragmentation under pressure from tight deadlines, a lack of clarity about the technical requirements, and competing domestic proposals. Unless these are addressed, there will be unnecessary duplication, costs, and a dilution of the effects of opening the banking system.
PSD2 specifies that trusted third parties (TTPs) must have access to accounts, known as XS2A, in order to provide new services such as account aggregation and payment initiation.
The financial services industry has assumed that the mechanism for this will be through the development of an open-standard application programming interface (API), although that is not specified by the legislation. The industry is concerned that the absence of clarity from regulators will lead to the development of an overabundance of APIs, hindering the integration process for TTPs, banks, and account holders.
Already there are parallel developments, particularly in the UK, where the government has set the industry the task of creating a UK Open Banking API for introduction in 1Q17. Nine major UK banks are expected to announce details in the autumn of this year – at about the same time as the first Regulatory Technical Standards (RTS) involved in PSD2 proposals will be published, ahead of ratification in 2Q17.
There are, however, a number of obstacles and potential pitfalls, not least in the timescales involved and the lack of specifications for the PSD2 in particular. As one Danish banker put it at a recent conference, "We find ourselves in the unusual position of begging the European Central Bank to tell us what to do."
Working with a wider range of stakeholders is necessary
What is needed is a wider universe of participants, not just banks, to come together to develop a rule book on the wider issues of interpretation of the regulatory background, technical standards, common solutions, and governance.
There are also differences in the scope of the UK's proposed Open Banking API and the PSD2. As the names suggest, one is about banking and the other is about payments. The UK envisions a range of new services being offered, such as automatic collection of income details that could be used for tax gathering for small businesses, while PSD2 really addresses only the issues of payment initiation on the one hand and more widespread use of transaction-related data, such as for automated reconciliation, on the other.
Despite the wider ambitions of the proponents of the UK Open Banking standard, third parties initially will be allowed access only to a restricted data set – just the value, date, and direction (credit or debit) of the transaction – which existing third parties say is actually worse than the current situation where they access customers' online accounts and screen-scrape additional data such as the payee details.
Such a halfway house will satisfy neither the security requirements of the banks – screen-scraping involves account holders handing their login details to a third party in violation of the rules – nor the frictionless, feature-rich end-user experience that will be required to compete in the digital world of fintech competitors.
Some European countries already have a form of API, such as the German Electronic Banking Internet Communication Standard, which is used for corporate banking. How these fit with PSD2 – and wider initiatives such as immediate payments and blockchains – will not become clear until the draft RTS appears, at the earliest.
Even without the short timescales and such existing issues to deal with, it is inevitable that several APIs will emerge to address domestic issues in each European country. That is not necessarily a bad thing, as it will allow for differences in the way various countries deliver financial services.
In any case, the notion of having a single API is a red herring; the real need is for all stakeholders to get together and create a framework for building APIs that ensures a good outcome for end users.
The creation of such a framework is the focus of much behind-the-scenes efforts by industry bodies such as Payments UK, banks, vendors, regulators, and domestic payment schemes, but it will also have to involve fintech developers, business representatives, card schemes, and merchants if it is to work in any meaningful sense. And it will have to bear in mind that the end users in this case are consumers, who will have to be convinced that they really want to let third parties have access to their bank accounts.
Even given all of these obstacles, some banks are realizing that this will also be a good outcome for them too: As the digital economy forces a shift from vertical channels to horizontal networks of partners, competitors, and customers, functional APIs working in an agreed-upon framework will be key components.
Potentially, PSD2 open banking and the rise of fintech innovation will mean that banks cede more and more of their customer-facing activities to specialists – which could be fintechs or other institutions carving out new specialist niches for themselves. This will require a change in mindset and business models for banks to successfully make the transition.
Straight Talk is a weekly briefing from the desk of the chief research officer. To receive this newsletter by email, please contact us.