As a result of its Retail Banking Market Investigation, the Competition and Markets Authority ("CMA") has made a provisional order requiring the major retail banks to adopt open application programming interfaces ("APIs") and share current account transaction data with intermediaries. As the bright spot in a set of remedies otherwise considered cautious, the move has been well received by the challenger banks and fintechs who will be the key beneficiaries. The banks are likely to be reflecting on the future of customer engagement in retail banking, as well as some more immediate questions around governance and risk management in the complex new ecosystem that is about to emerge.

In the 2015 Budget HM Treasury announced its commitment to delivering an open standard for APIs and data sharing in UK retail banking. Its aim was to increase the opportunity for the challenger banks to disrupt the market and facilitate the development of an effective fintech intermediary sector. The Open Banking Working Group ("OBWG") proposals that followed in February 2016 were generally considered ambitious and a lack of teeth appeared to threaten momentum. However all that changed on 17th May when the CMA published its "Retail banking market investigation – provisional decision on remedies" and effectively required the banks to adopt the OBWG proposals to an aggressive timetable.

Many banks must be relieved by the CMA conclusions that ordering the break-up of larger banks would not solve the competition problems in the retail banking sector. Instead, the CMA has proposed a package of measures that aims to improve customer engagement and facilitate effective comparison of retail banking products. The requirement to adopt common API standards is heralded as the single measure with the greatest potential to transform competition in retail banking markets. Customers will be able to consent to share their data with intermediaries who, through the open API standard, will access information about banks' services, prices and service quality and develop services for customers to compare different banks' offerings. The measures also pave the way for the development of new business models offering innovative services to customers such as personal financial management tools and affordability check solutions.

Requirements of the Provisional Order on open API standards

The CMA provisional order requires the major retail banks to:

  • make reference and product information (e.g. charges, terms and conditions, customer eligibility criteria) for current account and SME lending products available through an open API by the end of Q1 2017;
  • make redacted personal current account data (mi-data sets as they exist today) available through an open API by the end of Q1 2017; and
  • make personal and current account transaction data with full read write functionality available through an open API within a timeframe to be agreed with the CMA but no later than January 2018, the transposition deadline for Payment Services Directive 2 ("PSD2").


Governance and Funding

The OBMW identified the need for the creation of an independent authority to set up and operate the ecosystem, a Standards Governing Body to set and develop the data, technical and security standards and an appeals board to hear challenges. In particular it identified that:

  • Access to and participation in standard-setting must be unrestricted
  • The procedure for adopting the standard must be transparent
  • There must not be any obligation to comply with the standard
  • The open banking standard must be accessible to all on RAND terms.

In addition, the OBMW noted that membership of each body should be determined according to objective and non-discriminatory criteria to avoid challenges of discrimination. The CMA's provisional order falls short of meeting the above criteria in a number of ways:

Creation of an "independent" authority

The CMA has provisionally ordered the establishment of an "Implementation Entity" to implement and maintain open banking standards. However, instead of being independently run, it proposes that the Implementation Entity would:

  • be composed of the major retail banks (who are obliged to join) while any challenger banks can elect to participate on the same terms. In addition, the fintech sector would be represented, as well as the FCA and HMT;
  • have an independent chair accountable to the CMA with powers to impose solutions where necessary; and
  • be funded by the participating banks in proportion to market share.

It is arguable that in its composition and its requirement that it be funded proportionately to market share by the banks, the CMA has removed the independent element of this organisation, envisaging instead that it be a form of trade body funded and governed in large part by the major banks. The banks are required to submit proposals to the CMA on the composition, governance and funding of the Implementation Entity, as well as their nominations for chair. It remains to be seen whether they will raise these issues as a concern.

There are also unanswered questions about the role of the proposed Implementation Entity. Based on the OBWG proposals it is likely to need to take on responsibility for vetting and accreditation of third parties, resolution of disputes among customers and participants and overseeing standards.

In the context of co-operation by the banks within the IE, thought will need to be given to ensuring that the banks do not disclose or share commercially sensitive information with one another. The OBWG identified this as a concern and suggested that a separate competition law policy be drawn up. Thought should be given to this aspect of the new body too.

The OBWG proposed the creation of an independent standards setting body. This is not mentioned in the CMA proposals. Instead the provisional Order requires the major banks to adopt and maintain common APIs. Should it be their role to do so outside the framework of an independent standard-setting organisation? An additional question arises about the basis on which any IP rights forming part of the standard are treated. The CMA suggests that all licences of the API would be royalty free, whereas the OBWG recognises that in some circumstances proprietary rights should be licensed on RAND terms. If they are licensed on RAND terms, what would be the basis of these terms and who would hold the banks to account if they fail to license on those terms?

The question of the extent to which the banks might be able to recoup any costs has not been expressly addressed. It is unlikely that they will be able to charge customers to release their data as this would likely create a barrier to customers releasing their data in the first place and undermine the whole process. Could the banks recoup some of their investment by charging intermediaries for use of the data? If so, then what is a reasonable fee to charge? All these questions are yet to be resolved and many more will no doubt arise as the process unfolds.

One of the many implementation challenges will be designing a framework for adoption of the open banking standard which is compatible with both PSD2 and the EU General Data Protection Regulation ("GDPR") while there is still ambiguity around their requirements. PSD2 is due to be transposed into UK law by January 2018 and GDPR by May 2018.

PSD2 requires the entity maintaining the customer's payment account to allow so-called payment initiation service providers ("PISPs") access to their customers' accounts to facilitate transactions ordered at the customers' request. It also promotes account information services such as account aggregation service providers and other intermediaries and requires the account provider s to open up access to customer accounts where the account information service provider has obtained "explicit consent" from the customer. Many of the infrastructure, security, and data sharing components that will need to be in place to enable the open API standards will also be required for PSD2. Co-ordinating the approach with PSD2 implementation will therefore ensure consistency and efficiency and this approach is reflected throughout both the OBWG proposals and those of the CMA.

Data Protection and Security

Even among those groups who most welcome the open API standards data security concerns are high on the agenda. Allowing customers to grant third parties access to their data expands the security perimeter beyond the control of the banks and could significantly increase exposure to fraud and identity theft risk. Many of the high profile data breaches of recent years have involved APIs and there is no doubt that the APIs will be the target of cyber-attacks. Customer confidence will be key to adoption and the CMA acknowledges that customers will need strong assurances on security.

The ICO1 has highlighted the need to ensure adequate safeguards are in place before opening up access to financial transaction data. In particular, the ICO has highlighted concerns relating to:

  • Data Profiling: Although data profiling is not one of the envisaged applications of the open API the arrangements will make granular transaction data readily available that could be used for data profiling purposes with negative impact for the individual's privacy. It is currently unclear if use for data profiling might be restricted by the Implementation Entity, as opposed to being left to existing data protection laws. Data profiling will be subject to more specific regulation under GDPR.
  • Data Subject Consent: Sharing via an API involves a challenge for ensuring any consent of an individual is "explicit", as will be required under GDPR, because the individual will not see the data before it is shared. Further challenges arise if the consent is more than simply a "one time" permission and permits ongoing access. There are many questions to be answered around how permissions will work and the form in which processing notices will be presented to data subjects.
  • Silent Party Information: The OBWG considered but did not resolve how deal with data protection compliance where a consenting account holder's transaction data includes personal data of third parties such as payments to friends or family. As it will be impractical to obtain individual consents from silent parties some other legal basis for sharing this data would need to be found before opening up access to un-redacted data-sets. Particular challenges arise where the data involves sensitive data (e.g. data suggesting a medical condition).

Although there is time before un-redacted transactional data must be made available in January 2018 there are many questions yet to be addressed. Finding a balance between effective adoption of the open API standard and giving adequate control of scope of use to the data subject in the context of a changing regulatory regime is likely to be a challenge.

The OBWG proposals describe a governance model under which no direct contractual arrangements exist between the participants (the banks and the third party intermediaries). Instead, the participants would sign up to obligations and standards monitored by an "independent authority" with powers to sanction non-compliance, including removal of an intermediary from the ecosystem and payment of compensation to customers. Leaving aside whether this function would be performed by the Implementation Entity described by the CMA the proposed arrangements pose some interesting risk allocation questions:

  • Reliance on shared data: Banks are not likely to be keen to take on liability for the ultimate use of or reliance by multiple intermediaries on the data shared via the API. In the absence of direct contractual arrangements with intermediaries other means of managing this risk will need to be found.
  • Unauthorised use of personal data: Customers will be looking for redress where third party intermediaries act outside the individual customer permissions granted, including where the data is passed onto third parties. It is currently unclear if this will be limited to remedies under existing data protection laws or whether the API standard governing authority would intervene.
  • Security breach: Account providers are currently obliged to refund customers for unauthorised transactions, however an open API standard involves risk that is less within the control of the account provider. Under PSD2 the customer has rights to address a refund claim to the account provider and be provided with a refund even where the unauthorised transaction occurs as a result of a third party fault. In those circumstances the third party is then required to immediately compensate the bank. The OBWG has considered whether the refund arrangements should be extended to services not subject to the PSD2 requirement, acknowledging that regulatory intervention would be needed to do so.
  • Liability of Intermediaries and Insurance: The proposed arrangements involve risks for the intermediaries as well as the banks and it would be appropriate for the vetting process to look at the ability of the intermediary to take on those risks. It has been suggested by the OBWG that a pooled insurance arrangement may be the appropriate approach to ensure that barriers to entry do not affect the growth of the intermediary sector.


The CMA has until 12 August to publish its final report. Its final decisions will take into account responses to the provisional decision on remedies, however it is unlikely that the overall form of the remedies package will change substantially in the next few months. Whilst the immediate focus of the banks is likely to be on the proposed governance and funding arrangements for the open API, they will no doubt also be considering the impending disruption to traditional retail banking. Those banks who wish to remain successful players in the retail banking market will be looking for partnership opportunities in the emerging ecosystem. The deadline for responses to the provisional decision on remedies is 7 June 2016.