Financial services in 2016 are being transformed through digital disruption. Lowered or demolished barriers to entry have resulted in an influx of disruptors and enablers across a FinTech ecosystem already energised by the accelerated expansion in digital connectivity. Rapid growth in customer adoption of new technology, the emergence of digital-first and mobile-only customers and expectations of a frictionless customer journey have meant banks must re-imagine their core systems and re-think the role of technology across the enterprise.
In doing so, banks are aiming to deliver a digital service built around the needs of their customer base. User experience architecture is focussed on progressing towards a cohesive, ubiquitous and seamless banking service, cognisant of the service provision benchmarked by Google, Apple, Facebook and Amazon.
To deliver the competitive digital proposition underpinning these objectives, banks have latterly (and in part through forthcoming necessity) begun to unpack transformative digital strategies, exploring opportunities to enhance customer experience through deploying flexible, scalable and agile technologies to optimise the wealth of customer data on their technology platforms. Central to this is the creation and execution of a compelling Application Programming Interface (‘API’) strategy which must operate within the context of a series of broad and challenging legal issues.
This article will discuss what the roll out of progressive API strategies and associated legislative or regulatory initiatives may mean for providers of financial services (large and small), touching on the experience and current thinking of my own employer, RBS.
API deployment
Software applications have become critical to optimising customer experience. Central to this are APIs, which provide a point of connectivity across platforms, allowing applications to communicate with each other and exchange data directly, without the need for human intervention. For banks, APIs are an attractive means to provide (permitted) access to their applications, creating a seamless and established way for third parties and FinTech providers to interact with their platform. At the same time, APIs pose a commercial challenge to established players in the market, providing a mechanism for third parties to gain legitimate access to banks’ customer relationships and data in a way that has never been possible before.
Regulatory Developments
While there are a number of different reasons – competitive, reputational, regulatory and legal – why banks are focussing upon API strategies, a key driver has been a governmental push to promote more effective competition and a better service for customers. As an example of this, in September 2015 in the UK, the Open Banking Working Group (OBWG) was set up at the request of HM Treasury, to explore how data could be used to help people transact, save, borrow, lend and invest their money. Its aim is to develop a framework for adopting an open API standard across banking and explore how open banking will impact consumers, regulators and industry.
The OBWG has recently released its framework for an Open Banking Standard, to act as a guide for how bank data should be created, shared and used deploying APIs, to progress towards a mandatory ‘open’ banking API to be launched towards the end of the year. The rationale for this is clear: increased competition and the unbundling of bank services by banks and FinTech developers should accelerate the provision of more and better services, competition and connectivity to customers. Establishing a standard open API for banking will mean that banks, with the account holder’s permission, can easily and securely pass personal account data to another entity, opening up the banking market to further innovation.
As a separate but overlapping initiative, the EU’s new payment services directive, PSD2, will require banks to offer third-party developers access to their systems via open APIs. Under its terms, banks are required to foster an open and equal market by allowing approved and licensed third party providers (which will include FinTech developers) access to customer accounts where the customer has granted permission. Banks cannot impose additional fees onto these providers, refuse them access (without a valid reason) or put them at the end of a priority queue. The technology standards underpinning PSD2 have yet to be agreed, but given the 2018 deadline for national implementation is fast approaching, there is a strong possibility that the OBWG initiative will influence the PSD2 APIs, with the consequent benefit for the UK financial services industry.
Incumbent banks and FinTech developers
For third-party developers operating in the FinTech space, the opportunity to leverage the connectivity presented through open APIs creates a platform to offer far greater richness and functionality in their applications; there will no longer be any need to have intimate knowledge of the software being accessed, nor access to the underlying code.
For banks, viewing open API initiatives solely through the lens of customer disintermediation or being ‘unbundled’ by third-party developers would be short-sighted. Enabling third parties to create applications on top of their platforms to better serve the needs of their customer base creates obvious opportunities around innovation in the user experience: many of these developers will bring a richness and functionality absent from the bank’s core services currently offered, or operate in niche areas which may be under-served at present. FinTech start ups, often addressing banking challenges from perspectives very different from centuries-old retail and commercial banks could generate ideas and innovation to extend reach beyond the boundaries of current thinking. For established players, third-party innovation allied with their own in-house expertise provides the best opportunity to build the kind of digital product suite that customers increasingly expect. Accelerated development, new channels of distribution, quicker customer on-boarding, optimised front-end user interfaces, more seamless integration across financial services platforms and the creation of mutual value should all be possible. The bank itself could in turn become a platform for third-party innovation, with compound benefits the more APIs are introduced.
RBS and APIs
Moving towards a strategy of open APIs has separately facilitated a more collaborative approach across current (and future) providers of services in the financial services marketplace. RBS is seeking to position itself as the go-to organisation for FinTech brands. It has sought to optimise its interaction with the FinTech community by hosting a series of eight hackathons over an 18-month period in the UK, India and the Republic of Ireland. In doing so, the bank has sought to learn from (and adapt to) third-party developers and tailor its engagement and operating model accordingly. As the bank moves toward the API economy, there is a wealth of creative, broad-based, diverse and multi-national FinTech talent available to create the newest breed of applications.
RBS has created a sandbox for external developers to use and feedback on. The sandbox contains what is anticipated to be the RBS API, with anonymised but realistic data to facilitate the creation by third-party developers of financial services applications to complement RBS’ own banking platform and services. Over time, a live API environment will be created, to allow graduation from the sandbox to full deployment in a production environment.
Legal and regulatory considerations
Facilitating these new developments through the use of APIs and externalising data to applications does not, however, come without risk. While banks will agree common rules for describing data and specifications for transferring it (and most organisations will create limits around what the API will access and who is able to connect to them), the legal and regulatory consequences of developing an open API strategy need to be worked through.
As a bank diversifies to incorporate products and services provided by FinTech start-ups and SMEs, the bank needs to perform appropriate risk assessments (around capability, security, AML and so on) on the in-scope third-party developers, with governance, contract management and assurance procedures flexed to accommodate these new partnerships. Banks will need to consider risk appetite and where liabilities are operationally likely to fall, having regard to the likely depth of pocket of most start-ups. As an example, if an API is provided by a third party and ceases to function, how much (if any) liability can the bank pass on? The most recent OBWG report indicates that the regulatory regime will need to give customers certainty that they will not be left out of pocket if they choose to use third-party providers and something goes wrong. Ultimately, this means banks will be exposed to greater risk.
Similarly, where services are provided to a bank through its open API, the bank must consider the application of the regulatory outsourcing requirements (such as SYSC8) and supply chain robustness. Many FinTech start-ups are not geared up for this level of scrutiny nor have they adequately considered realistic performance standards around which to provide contractual undertakings.
Related considerations arise for banks once the PSD2 regime has been implemented. Banks are generally being positioned by regulators to act as an Account Servicing Payment Services Provider (AS PSP), with FinTechs the obvious and planned Payment Initiation Service Providers (PISPs) and Account Information Service Providers (AISPs). Banks will have to consider how to manage the engagement with the PISPs and AISPs around the API. As PISPs and AISPs cannot be obliged to enter into contracts with banks acting as AS PSPs, issues are likely to arise around the risk of misuse of account data or fraud.
In relation to privacy, banks would need to have a clear understanding of the framework which governs the transfer and use of both behavioural data and identity data and understand the new profiling rules set out in the General Data Protection Regulation. Freely given and fully informed customer consents under the Data Protection Act and implementation of appropriate security standards would have to be in place.
Banks should review any existing commercial arrangements with third parties around access to the bank’s customer data, products and services to avoid breaching their terms, particularly where the existing arrangements drive revenue generated from database or copyright licensing.
In relation to security and access controls, the picture may be a little different: APIs may offer a step forward from the current model of authentication often used in third-party applications. In the already crowded ‘Personal Financial Management’ space, applications seek to provide users with a single view of multiple accounts held across providers, often to facilitate money management, budgeting or financial planning. Where a customer wishes to authorise an application to access their bank account information, at present access often is achieved by using screen-scraping technology to access the data. This of itself creates risks for the customer: the third-party application now has full access to the customer’s account, an unencrypted (or decryptable) version of his or her login details, and in providing login details to the third-party application, the customer may well be in breach of their account terms and conditions. In contrast, APIs benefit from an open security protocol standard (known as ‘OAuth’) which allows customers to authorise one application to interact with another on their behalf. It is anticipated that, subject to regulatory dialogue, a similar approach to access controls for financial services applications deploying APIs could be adopted.
Conclusion
While there are clearly contractual, operational, regulatory and legal issues to be worked through for both FinTech developers and banks, in the coming months the discussion around the possibilities presented by APIs is likely to intensify, not least as the OBWG continues to deliver against its remit and the task of implementing PSD2 into national legislation gathers pace. The deployment of open APIs could allow customers to get more out of their financial relationships while creating pathways for growth for banks and opportunities to help development cycles. The legacy core banking platforms often found in established UK banks do not readily promote change being executed quickly, yet if these banks developed their service interfaces in a manner which was capable of being expressed internally (and externally) through the same standard API, production cycles would quicken through standardised, agile processes, removing current concerns around dependencies with other programs and facilitating rapid development in response to changing consumer and technology needs.
Banks retain strong brands, enormous customer bases and a legacy of customer trust over many years; that customers will be core beneficiaries of the emerging API trends should cause the technology to be embraced rather than feared.
Kenny Robertson is Head of Services Legal, the Royal Bank of Scotland
