The Open Banking Standard

8/20/2019 The Open Banking Standard

1/148

The Open BankingStandard

Unlocking the potential of open bankingto improve competition, efficiency and

stimulate innovation


2/148

CONTENTS

1. Eecutive Summary............................................................................................................!

". #ntroduction.........................................................................................................................$

!. %oundations......................................................................................................................11

&. Opportunities and 'hallenges..........................................................................................1&

(. Scope of )ata...................................................................................................................1*

+. 'ustomer Benefits............................................................................................................"

*. The Open Banking %rame-ork........................................................................................."&

*a. Standards......................................................................................................................."(

*b. )eveloper esources.....................................................................................................!*

*c. Security...........................................................................................................................&1

*d. /overnance....................................................................................................................((

$. egulatory and 0egal 'onsiderations...............................................................................+&

. #mplementation 2lan.........................................................................................................*+

3ppendices...........................................................................................................................$1

/lossary.............................................................................................................................1&!

3ckno-ledgements............................................................................................................ 1&*


3/148

1. Executive Summary

Context

#n the "1( Budget 45 Treasury announced its commitment to delivering an open standard for 3pplication 2rogramming #nterfaces in U6 banking, to help customers have more control over their data and to make it easier for financial technology companies 7%inTechs8 or other businesses to makeuse of bank data on behalf of customers in a variety of helpful and innovative -ays. The /overnmenteplained that this could help to drive more competition in banking to improve outcomes for customers, and further support the U69s -orld:leading %inTech industry.

#n summer of last year, at the re;uest of the Economic Secretary to the Treasury, 4arriett Bald-in52, the Open Banking


4/148

include a broad implementation plan, covering three distinct phases over the course of the net threeyears.

The implementation plan -ill, by necessity, need to be fleible over the coming years ? both becauselessons -ill be learned as implementation gets under-ay and because the technology and standardson -hich it -ill rely -ill continue to evolve at a rapid rate in -ays that are impossible to anticipate

today. Eecution of the plan, along -ith maintenance of the emerging standard itself, -ill re;uirecareful ste-ardship. 'lear and consistent communications -ill be re;uired to continuously builda-areness, understanding and adoption not =ust -ith service developers, but also -ith the individualsand businesses that -ill benefit.

This latter point is fundamental. Our aim in constructing this frame-ork in the -ay that -e have -asto ensure that such an open standard provides the highest ;uality of service for individuals andbusinesses, that increases competitiveness, improves efficiency and stimulates innovation. Thisstandard -ill only be as good as the trust that all of the participants re;uired to make it successfulhave in it> that -ill ultimately rely on the trust of individuals and businesses.

Fundamental importance of data literacyOur -ork in constructing this frame-ork, as -ell as more advanced -ork in other sectors, hasrepeatedly highlighted the fundamental role of data literacy in supporting the creation of any opendata standards. -e feel it importantto do the same here.

Those core definitions arise from the t-o important, distinct, but mutually beneficial outcomes that thisframe-ork seeks to create@

A an open 32# for data that is shared, including, but not limited to, customer data> and

A an open data 32# for market information and relevant open data.

3n open A! is a means of accessing data based on an open standard@ it is a public interface.

)ata eists on a spectrum of accessibility. The data spectrum ranges from closed to shared to open.The data accessed via an open 32# may be closed, shared or open data.


5/148

Figure 1.1 T"e data #pectrum

See [email protected]:spectrum

#n fact, it could include data considered to be Dproprietary. #n that circumstance, the holder of rights toany such Dproprietary data could choose to share 7but could not be compelled to do so unless thedata -as deemed not to be proprietary8 that data via the open 32#, along -ith stipulations ? or licensing terms ? related to its use by those -ith -hom it chooses to share it.

Open data is data that anyone can access, use and share. 3n open data 32#, therefore, is a public

interface that provides access to open data. 3n eample of open data in this contet could befinancial product information.

3ny individual9s personal bank details or a company9s transaction data are considered clo#ed or #"ared data. They -ill be made available via an open 32# as a result of the implementation of this-ork, but access to them -ould be sub=ect to consent of the individual or business to -hom the databelongs and specific governance related to that. Such data $ill not %e licen#ed or made pu%lic a#open data as a result of this -ork.

3 n open #tandard is developed and maintained collaboratively and transparently, and can beaccessed and used by anyone.

&ey recommendation#

There are, of course, significant technical considerations involved in defining and implementing anOpen Banking Standard. But the bulk of the -ork is not technical> there are critical issues to takefor-ard around governance' #ecurity' lia%ility' #tandard#' communication#' regulation and legal.The chapters of this report outline the -orking group9s recommendations in each of these areas.There are a number -orth highlighting here because of their relative importance.

• 3n independent authority should be created, in collaboration -ith industry, to overseedevelopment and deployment of the Open Banking Standard.

• The Open Banking 32# should be built as an open, federated and net-orked solution, as

opposed to a centralisedChub:like approach. This echoes the design of the


6/148

• 'ustomer transaction data 7data that is presented to customers in their financial statements,including underlying transaction history, and data that relates to a customer9s account through-hich payments can be initiated8 should be made available, -ith consent, via the OpenBanking 32# as both customer:related data and aggregated data.

• 2rotocols -ill be developed and shared -ith all participants in the Open Banking Standard to

ensure that redactions in data that is shared via the open 32#s are truly eceptional, based onspecific risk considerations. %urther -ork -ill be needed to eplore the etent of redactionand -hat alternatives may be available.

• 3s a principle, eisting standards, datasets and structures should be reused -here possibleand appropriate.

• The Open Banking Standard should be managed -ithin a transparent and open governanceframe-ork that -ill support accessibility, usability and innovation.

• 3n #ndependent 3uthority should be established, -hose scope -ould include consideration of ho- complaints are handled, ho- data is secured once shared, as -ell as the security,reliability and scalability of the 32#s provided.

• The #ndependent 3uthority -ould vet third parties, accredit solutions and publish its outcomethrough a -hitelist of approved third parties.

• 'ustomers 7individuals and businesses8 of services built through the Open Banking Standard-ill need to understand their responsibility for ensuring their data is protected.


7/148

)elivery of a Dminimum viable product 75G28 including@ 18 the establishment of re;uired governanceentities 7and their initial scope and processes8 and "8 the launch of a tightly scoped Open Banking 32#, enabling select, read:access, open data use cases. This release -ill focus on lo-er:risk, easilyimplementable components of the Open Banking %rame-ork.

elease " ? to be completed by end of H1 "1*

Etension through implementation of select, read:access capability for customer transaction data. Bythis release9s conclusion, third parties -ill be able to access the midata personal customer data setsvia the Open Banking 32# on a read:only basis.

elease ! ? to be completed by end of H1 "1$

Significant build:out of governance entities and further development of the Open Banking 32# ? tocover the ma=ority of use cases supported by open data and anonymised and aggregated data.Similar functionality outlined in elease " to also be provided for midata business customer data sets.

elease & ? to be completed by end of H1 "1

3ll recommendations -ill be implemented by this stage. #n particular, -ithin this release, data and

services generally perceived as higher risk -ill be implemented and -ill re;uire governance andtechnical recommendations to have been fully implemented and tested. #t -ill deliver full read and-rite functionality under the Open Banking Standard as per its target scope.

The implementation section of the report provides more detail on each of these releases.

!n clo#ing

The recommendations set out in this report are purposely ambitious.


8/148

(. !ntroduction

(.1 Background

#n September "1& the Open )ata #nstitute and %ingleton 3ssociates published a report titled DataSharing and Open Data for Banks 7hereafter referred to as the %ingleton eport8 at the re;uest of 45Treasury and the 'abinet Office.

The %ingleton eport concluded that Dgreater access to data has the potential to help improvecompetition in U6 banking and recommended that banks create standardised applicationprogramming interfaces 732#s8 that -ould be accessible by third parties 7e.g. %inTechs, developersand other corporates8. To facilitate this, the publication recommended that open industry standards be

established for data:sharing in banking, thereby enabling the creation of standardised 32#s.

Subse;uent to publication of the %ingleton eport, 45 Treasury undertook a consultation, sourcingvie-s from across the financial services industry, consumer and business groups and the %inTechcommunity.

The outcome of the consultation -as published in 5arch "1(, -ith many of the respondentssupporting the development of open industry standards for data:sharing in banking in the belief it-ould increase competition and innovation in banking. The consultation also highlighted potentialrisks around data privacy, consumer education and interoperability, and thus the role the governmentcould play in supporting and standardising the development of an Open Banking %rame-ork.

(.( O%)ective# of t"i# *eport

Building upon recommendations presented in the %ingleton eport and responses from industry, 45Treasury announced its intention to deliver an Open Banking %rame-ork to facilitate data:sharing inU6 banking.

This document provides the frame-ork for adopting these as an open industry standard, hereafter referred to as the Open Banking Standard. There are a number of elements to the Open BankingStandard, -hich are highlighted belo- for ease.


9/148


10/148

/overnance )iagram


11/148

+. Foundation#

+.1 C"apter Outline

This chapter outlines key concepts and terminology referenced throughout this report. These eplain-hat data:sharing entails in the contet of banking and financial services, and describe the key

mechanisms that are used to share data. They also provide definitions and conceptual overvie-s of the Open Banking Standard

+.( &ey Concept# and Terminology

+.(.1 ,ata-#"aring

)ata:sharing is the process through -hich access to data is provided from one party to another. Themechanics of data:sharing, including authentication, authorisation and consent, are addressed in

more detail in 'hapters *a@ Standards and *c@ Security.

#n the contet of this report, data:sharing is considered from t-o perspectives@


12/148

1.

". /reater publication of standardised open data 7e.g. bank product data released on moneysupermarketCprice comparison -ebsites8.

+.(.( Application rogramming !nterface

3n 32# is a method for t-o soft-are systems to echange data. 3 -ell:designed 32# allo-s systemsto be loosely coupled such that -ithout any great kno-ledge of the underlying system or datastructure and minimal investment in studying documentation, a soft-are developer can ;uickly beginto access information.

+.(.+ T"e Open Banking Standard

Standards in the contet of this report describe a set of specifications and rules addressing data,technical and security aspects to data:sharing in an 32# environment. The Open Banking Standard-ill be an open standard. #t -ill be developed and maintained collaboratively and transparently, andcan be accessed and used by anyone.

Three standards -ill be considered, -hich in combination -ill form the Open Banking Standard@

1. )ata Standards@ rules by -hich data are described and recorded, potentially including, amongother characteristics, agreements on representation, format, definition and structure. Thescope of data to -hich these standards -ill apply are detailed in 'hapter (@ Scope of )ata.

". 32# Standards@ specifications that inform the design, development and maintenance of an

32#. This can include guidelines pertaining to architectural design, resource formats,documentation and versioning.

!. Security Standards@ security aspects of the 32# specification 3 common standard on theunderlying data and the mechanism for accessing it -ill reduce many of the frictionsassociated -ith data:sharing and support materially higher customer and third party adoptionversus a non:standardised environment based on multiple bilateral relationships.

3 /overnance 5odel is also described in 'hapter *d.

+.(. T"e Open Banking Standard

To enable adoption of an Open Banking Standard, recommendations in this report address keyconsiderations in designing, developing and operationaliFing the Open Banking Standard

ecommendations -ill therefore take into account re;uirements from each participant including@

1. 'ustomers@ individuals and businesses -ho share their data> publishers of open data and

". )ata attribute providers@ banks, financial services companies and other organisations through-hom data is stored and shared>

!. Third parties@ developers, %inTech, and other organisations -ho use data provided to designand offer ne- products.

The frame-ork therefore includes@


13/148

1. )ata, 32# and Security Standards through -hich usability of data and 32#s -ill be achievedand customers9 data -ill be protected from malicious actors and access rights can besecurely delegated>

". 3 governance model, -hich -ill develop trust, provide issue resolution mechanisms andoversee the standards>

!. )eveloper resources, -hich -ill enable third parties to discover, educate and eperiment.

'hapters *a:*d outline in detail the aforementioned components and provide guidance on their design and subse;uent implementation.


14/148

. Opportunitie# and C"allenge#

.1 C"apter Outline

#n this chapter -e revie- the underlying factors that make an Open Banking Standard possible, andhighlight the kinds of benefits this can bring to individuals and businesses as -ell as some of thepotential challenges that need to be designed around.

.( Opportunitie#

.(.1 ,riving innovation t"roug" data-#"aring

The mass adoption of the internet has demonstrated the po-erful effect -idespread access to datacan have.

'ollectively, internet companies have collected and organised a vast array of data. This has resultedin the development of a broad spectrum of innovative services ranging from reference sources ?including the -orld9s largest encyclopaedia ? to the practically useful such as online maps -ithintegrated travel directions, to the niche such as Dho- to videos on every imaginable sub=ect.

3t first, data -as either public, or actively shared by individuals through personal homepages. 3s theinternet became commercialised, businesses began sharing corporate data 7e.g. airplane ticketprices, hotel room availability etc.8 directly to the public andCor via intermediaries. %urthermore,attitudes of individuals to-ards data:sharing has also evolved> consumers no- use social net-orks tointerface -ith third:party services and regularly share information to compare prices and receive morepersonalised services. To date, customers9 ability to use their bank data has been limited andrestricted to inconvenient -orkarounds.

.(.( /,* and S,( a# driving to$ard# an Open Banking Standard

3s the collection and use of personal data has increased, individuals, and governments, are seekingmore clarity on the basis on -hich the data is used and their interest safeguarded. The EU is

progressing the /eneral )ata 2rotection egulation 7/)28 initiative in order to fulfil this need. Somebasic principles of the forthcoming regulation are to enshrine the individual9s rights to@

• data portability ? the individual may share their data freely -ith -homever they choose>

• consent ? the individual must provide eplicit consent to sharing their data>

• specific usage ? the individual9s data may only be used for the pre:agreed purposes.

/)2 provides an important frame-ork under -hich customers9 banking data -ill be assessed andultimately shared.

The European 'ommission also issued a proposal for a revised 2ayment Services )irective 72S)"8

in Iuly "1!. 'entral to its recommendations are re;uirements for 2ayment 3ccount 2roviders toallo- third parties ? -ith appropriate consent ? to share account information and to initiate payments.


15/148

5ember states are re;uired to transpose 2S)" into national la- and apply the ma=ority of theprovisions from t-o years after publication in the Official Iournal 7-hich -as published in )ecember "1(8. Therefore, transposition at a national level -ill occur by Ianuary "1$.

#n order to comply -ith /)2 and 2S)", many of the components that -ill enable the Open BankingStandard -ill have to be built. These components -ill include technical design and infrastructure as

-ell as an approach to sensitive customer issues such as consent, delegation of access rights,authorisation and authentication, vetting, accreditation and governance.

.(.+ 0everaging a mature tec"nology in A!#

32# technology is the accepted norm for data:sharing and embedding functionality in an onlineenvironment. The use of 32#s is -idespread and today there are more than 1&, public 32#s

available.1 The most popular 32#s include familiar names such as %acebook and /oogle 5aps, -hich

are -idely used across the

• 3ccess to the host system is uncontrolled and unregulated>

• The techni;ue can fail -hen -eb pages are redesigned or ne- security measures areadopted>

• 'onsumers are uncertain about the procedure and have little recourse to their bank in casesomething goes -rong.

.(. ,igiti#ing & %anking and #trengt"ening & FinTec"

'ustomer demand for a digital banking eperience is increasing eponentially. ecent BB3 researchfound that "".m internet banking apps have been do-nloaded, an increase of (+J in "1(, andBritons -ere logging onto internet banking .+m times a day in "1(. 5ean-hile, branch andtelephone banking transactions are falling +:*J per annum.

#n addition, U6 consumers are active users of %inTech propositions, i.e. financial products providedby focused, online technology providers such as peer:to:peer lenders, payments providers and

personal financial management tools. %orthcoming research by EK suggests that as many as 1 in +digitally active consumers are %inTech customers" and as many again are epressing a -ish to

become customers.

Taken together, these trends sho- that -hile high street banks are un;uestionably digitising, a ne-group of firms is eager to compete for customers and may be capable of creating a differentiatedvalue proposition. 2romoting the sharing of data bet-een banks and %inTechs is an effective meansof helping both industries gro-, -hile supporting competition bet-een and amongst them.

1

See htp://www.programmableweb.com/news/elco-apis-ofer-huge-revenue-i-carriers-can-handle-disrupon/review/20!/0"/2

" #$ %in&ech 'nde(


16/148

.+ C"allenge#

.+.1 Converting cu#tomer intere#t

Earlier this year, #psos 5O# -as commissioned to conduct research on consumer and smallbusiness attitudes to data:sharing. Through a combination of focus groups and online intervie-s,respondents -ere introduced to a series of practical use cases based on echange of financialinformation bet-een a bank 7data attribute provider8 and a third party.


17/148

2. Scope of ,ata

2.1 C"apter Outline

This chapter outlines the types of data to be covered by the Open Banking Standard and providesdetails of their underlying characteristics and associated access rights envisaged 7i.e. -hat thirdparties -ill be able to use specific data types for8.

#n defining this scope, and as a driving principle, this report has sought alignment to products andchannels defined by 2S)" 7see 3ppendi 1 for further details8. This alignment delivers t-o key clear advantages should recommendations from this report be acted upon> 718 it simplifies compliance

re;uirements on participating institutions, and 7"8 it simplifies communications to customers. #t shouldbe noted, ho-ever, that as of the time this report -as -ritten, relevant regulations 7such as 2S)" andthe EU9s /)28 had not been finalised. 3s such, subse;uent -ork follo-ing this report may further refine or epand the scope as appropriate.

2.( ,ata in Scope

2.(.1 Open data

)ata that anyone can access, use or share. Eamples include product information and 3T5 locations.

2.(.( Cu#tomer tran#action data

)ata that is presented to customers in their financial statements 7including underlying transactionhistory8 and data that relates to a customer9s account through -hich payments can be initiated.Eamples include balance information, transaction history and payment information 7i.e. information tofacilitate a payment8.

2.(.+ Cu#tomer reference data

)ata about an individual or business that is not directly related to the use of an account, e.g. data thatis collected from or generated for a customer as part of an eligibility check, or -hile being broughtonboard. Eamples include data relating to 6no- Kour 'ustomer 76K'8 processes, anti:money:laundering checks or credit scores.

2.(. Aggregated data

Sets of averaged or aggregated data across transactions, balances, other customer data or open datasources. Eamples include average number of cash -ithdra-als per month across a postcode area,

successful lending applications by businesses -ithin a S#' code, etc. 'hapter *c.1" covers the needto ensure that any personal data that is released as open data -ould need to be annonymised andunable to be de:annonymised.


18/148

2.(.2 Sen#itive commercial data

Sensitive commercial information from data attribute providers@ Sensitive information includingdocuments, strategy, price:setting, policies , algorithms and data provided under licence ? is not inscope for the Open Banking Standard. 3t a data sub=ect level, this may include data aboutprofitability that reveals proprietary or competitive insight about a bank9s performance, e.g. theaverage credit score across a customer population, or average margin.

2.+ ermi##ion# and Acce## *ig"t#

2ermissions are rules that grant a third:party access to data -ithin the confines of prescribedfunctions. The follo-ing access rights have been taken into consideration for evaluation against datatypes.

• ead access ? permission that is granted to a third party enabling them to read but not modifya file, set of files, or set of data.

•


19/148

!nteraction "i#tory "(:month history from

date of re;uest

NC3 ? not

customer:level data

NC3 ? not customer:

level data

Account #tatu# Open accounts NC3 ? not

customer:level data

NC3 ? not customer:

level data

4arket #ector# e;uests from entitiesonly

NC3 : open data NC3 : open data

,ata tran#itmec"ani#m#

ead:only 32#

eadC-rite 32#

ead:only 32# ead:only 32#

Standardi#ation 5erchant metadata 2roduct definitions 2ath to purchase

definitions 7e.g. to

allo- product

applications to be

compared across

providers


20/148

5. Cu#tomer Benefit#

Standardised bank 32#s have the potential to dramatically improve competition and innovation in U6banking to the benefit of individuals and businesses. 3s financial services are brought into the 32#economy, it is epected that eisting providers and ne- entrants -ould compete to dramaticallyimprove eisting products by making them more intuitive, personalised, convenient and integrated. #naddition, customers -ould be epected to benefit from a suite of ne- propositions that are enabledthrough open 32#s.


21/148

by allo-ing consumers to share their transaction data -ith price comparison -ebsites. 4o-ever,midata usage has been relatively lo- as it is hard to use ? it re;uires the consumer to do-nload a'SG file, in Ecel, from their bank and then upload it into the price comparison -ebsite.

3n Open Banking 32# could eliminate the friction involved in the do-nloadCupload model andmaterially improve the consumer eperience. 3 consumer -ould simply give a price comparison

service permission to access their bank account data and the rest -ould happen Dbehind the scenesand in real time. This service could even be engaged as an ongoing service -ith regular automaticrevie-s, or respond to ne- offers launched into the market. The principle could also be etended toother personal financial products, in particular credit cards and mortgages.

The '53 also recommended making price comparison initiatives available to S5Es, -hich accountfor (.(m active business current accounts in the U6.

*e7uired data3

#ndividual transactional 7current account usage8 data for individuals and businesses.

'ertain data sets available as open data@ current account tariffs as a minimum, but could beetended to customer service, branch location, opening hours, digital functionality.

%urther opportunity in credit cards, mortgage and other lending and savings products.

5.1.( ropo#ition (3 per#onal financial management

2ersonal financial management tools 72%5s8 help consumers to budget better and understand their overall financial position, by helping them categorise and manage their spending using visualisationtools and predictive cash flo- tools. They often pull information from other financial services products,such as credit cards and savings accounts, to provide an aggregated vie- to the consumer. 2%5scan also help consumers potentially save money in non:banking products by looking at spending

patterns in products such as energy, telecoms, groceries or insurance and suggesting alternatives.

2%5s are popular in the US, -ith !"J of consumers using them to manage their finance, of -hich

approimately three:;uarters use third:party solutions such as 5int or yodlee.com.(

2%5 uptake in the U6 has been lo- primarily because consumers cannot give 2%5s access to their transaction and balance data. To date, the typical -orkaround has been for the 2%5s to screen:scrape the data from the banks9 online -eb pages. This forces consumers to share their login details-ith the 2%5s, -hich makes some consumers uncomfortable and in some cases invalidates banks9o-n terms and conditions. Under an Open Banking 32#, customers -ould be able to grant access totheir data securely and efficiently -ithout sharing their pass-ord -ith any party other than their bank.

Should U6 consumer uptake of 2%5s reach US levels of c.!"J, it -ould suggest 1:1(m potentialusers. 3 recent U6 survey suggested that !J of consumers felt positive about sharing data via an

open 32# for the purposes of aggregating financial information.+

*e7uired data3

#ndividual current account data 7balance and transactional8 for individuals.

3dding in additional products ? credit card, savings, lending.

5.1.+ ropo#ition +3 acce## to credit

! 4ovanas3 20

5 'psos 6'3 open 17' 8arclas 20!


22/148

4istoric transactional data is an important determinant of credit ;uality and real:time transactionaldata is a valuable indicator in the ongoing serviceability of loans. 'urrently this information is onlyavailable to the current account provider, -hich means third:party providers may not be able to offer the best terms to users -hen they shop around. #t is noted that c.J of S5Es procure loans from

their primary banking relationships -hile c.(J of consumers* are likely to purchase ne- banking

products from their current bank. they -ould choose -hich bank accountCs to link andprovide their permission for the data to be shared. There are c.(, businesses in the U6 -ith

bet-een ( and ( employees for -hom this could be a compelling proposition.

*e7uired data3

* htps://www.pwc.com/g(/en/ban+ing-capial-mar+es/publicaons/asses/pd/pwc-new-digial-pping-poin.pd $ htps://asses.digial.cabine-o9ce.gov.u+/media/!)c)c500b50aa00000"/0;;


23/148

#ndividual transactional 7current account usage8 data for businesses.

5.1.5 ropo#ition 53 fraud detection

%raud costs the U6 consumer c.(*m per annum.1 'urrently customers rely on their account

providers to notify them of fraudulent activity on their accounts. Some customers may believe thatthird:parties specialising in security and the detection of fraudulent transactions may offer better ;uality monitoring and notification services. This may be particularly compelling if the third partyaggregates data across multiple accounts or products and can spot patterns that a single productprovider -ould other-ise not see.

*e7uired data3

A #ndividual transactional 7current account usage8 data for individuals and businesses.

The si propositions described above -ere chosen from a long list to highlight the kind of innovativeand valuable propositions that Open Banking 32#s could enable. T-o propositions are notable bytheir absence@ 6K' and payment initiation. 6K' is a regulatory re;uirement all financial providersmust no- undertake -hen onboarding ne- clients. #n theory, an Open Banking 32# could be used toport across a customer9s 6K' profile to a third party> ho-ever, this becomes a form of identity that isconsidered to be out of scope for this report 7albeit it could be considered in con=unction -ith thegovernment9s -ork on identity, particularly /OG.U6 Gerify8. 2ayment initiation is the ability of thirdparties to initiate payments on behalf of customers of financial institutions. #t offers good utility tousers and dispenses -ith the need to input credit and debit card details multiple times in an onlineenvironment. 2ayment initiation has not been included above, as it is a clear and stated ob=ective of 2S)".

1 htp://www.=nancialraudacon.org.u+/%raud-he-%acs-20!.asp


24/148

8. T"e Open Banking Frame$ork

8.1 Overvie$

To enable the effective sharing of data bet-een parties, this report -ill outline a frame-ork for developing and operationalising an Open Banking Standard across U6 banking.

8.( T"e *ole Standard# lay in ,ata-S"aring

Standards in the contet of this report describe a set of specifications and rules addressing the data,

technical and security aspects to data:sharing in an 32# environment. Three types of standards -ill be

considered ? in combination these form the Open Banking Standard referenced in this report.

1. )ata Standards@ rules by -hich data are described and recorded, potentially including,among other characteristics, agreements on representation, format, definition andstructure. The scope of data to -hich these standards -ill apply are detailed in 'hapter (@Scope of )ata.

". 32# Standards@ specifications that inform the design, development and maintenance of an 32#. This can include guidelines pertaining to architectural design, resource formats,documentation and versioning.

!. Security Standards@ security aspects of the 32# specification.

By adopting common standards across the banking industry, many eisting frictions associated -ithdata:sharing can be reduced.

)ata standards -ill make it easier to create, share and release data by establishing a clear and

common understanding of -hat the data means, ho- it is represented and -hat state and ;uality it

-ill be released or received in. 32# standards, in addition, -ill help establish greater uniformity across

developer eperiences -hen accessing data through different providers. Security standards help to

protect customers from malicious actors 7'hapter *c8.

Usability markedly increases in a standardised environment, driven by greater consistency, integrity,accuracy and overarching ubi;uity and interoperability of both the underlying data and the 32#

platforms through -hich access is granted. This is epected to result in far greater sustainedparticipation among developers and therefore among third parties and data attribute providers.


25/148

8a. Standard#

8a. 1 Outline

Standards are a key enabler to market:driven innovation. They provide uniform infrastructure tocompete and innovate upon, and -hen distributed on an open basis help reduce market inertia andunlock net-ork effect benefits from ubi;uity. By improving access to 32#s and data, a more diverseecosystem of third parties -ill be cultivated -hose participation -ill lead to greater product innovationand choice for customers.

This chapter outlines the underlying types of standards that should comprise the Open BankingStandard. #t provides an overvie- of their specifications and guiding principles for design,

development and delivery. Security Standards are addressed in 'hapter *c.

8a. ( &ey *ecommendation#

8a (.1 Specification# for t"e Open Banking Standard

A The Open Banking Standard -ill include both 32# and data standards, thereby addressing both theunderlying data and the mechanisms through -hich data is accessed. #t -ill also include security

standards, -hich are addressed in 'hapter *c.

A The 32# Standard should comprise the follo-ing specifications andCor meet the follo-ing criteria@

o Use of EST as an architectural style and 4TT2 as the transport>

o Use of ISON as the resource format>

o 3chievement of 0evel " from the ichardson 5aturity 5odel>11

o 3doption of a vendor and technology independent definition.

A The 32# Standard should comply -ith the follo-ing versioning re;uirements@

o Support for ma=or and minor releases>

o Back-ards compatibility for all minor ? and as far as possible ? ma=or releases>

o 2rescription of minimum support time periods for ma=or releases>

o Embedded fleibilityCresponse speed for security or functional errors.

A The 32# Standard should be designed -ith the follo-ing features@

11 htp://rescoo+boo+.com/iscellaneous/richardsonmaurimodel


26/148

o 3 controlled core ? hosting shared resources should be established and this should

represent the slo-est:changing part of the standard>

o 0ocal etensions Dat the edges should be permitted, allo-ing for 32# provider

innovations -ith subse;uent potential incorporation back into the core>

o Specific characteristics allo-ing 32# providers 7data attribute providers8 to addressscalability challenges.

A The )ata Standard should be defined to enable consistency and standardisation.

8a (.( &ey principle# for development and di#tri%ution

The Open Banking Standard should endeavour to reuse and align -ith eisting openstandards, data sets, structures and semantics -herever possible.

The Open Banking Standard should be provided on an open basis, available for access

and use by anyone.

8a (.+ 0icen#ing recommendation#

The Open Banking Standard should be made available under a ''1" licence 7effectivelypublic domain8 to promote its use, reuse and distribution. %ailing this, '':BK 1!

7attribution8 -ould be recommended.

Open data in scope should be published under a '' licence 7i.e. the same licence usedby the /lobal 0E#1& system8, thereby avoiding barriers to reuse and Dlicence chains.

System soft-are should be made available under a 5#T 0icence, allo-ing the soft-are tobe as permissive as possible and thus avoiding difficulties -hen integrating -ithproprietary soft-are.

8a. + urpo#e' rinciple# and olicie#

8a. +.1 rinciple#

To deliver enhanced innovation and competition, the Open Banking Standard -ill be designed inaccordance to the follo-ing principles.

• Openness ? ensuring accessibility for all interested parties, across a -ide range of participants, thereby incentivising adoption, distribution and participation.

• Usability ? facilitating ease of implementation and a smooth user eperience for participants.

• #nteroperability ? promoting and progressing to-ards an environment -here data can beechanged bet-een parties in a frictionless manner across organisational and technologicalboundaries.

1" htps://creavecommons.org/abou/cc01! htps://creavecommons.org/licenses/b/.01& htps://www.glei.org/en/lei-ocus/wha-is-an-lei


27/148

• euse ? adopting and leveraging eisting standards, taonomies and data lists -herever possible and practicable to avoid duplicative efforts and maimise interoperability.

• #ndependence ? promoting competition among and avoiding dependencies on vendor solutions and technologies> preserving optionality in delivery models and implementationtechnologies.

• Etensibility ? establishing fleibility and encouraging adoptees to build upon the standardand innovate locally, -hile providing governance mechanisms to subse;uently bringetensions Dback to the core.

• Stability ? ensuring the provision of a stable environment for all participants -here change iscommunicated, actioned and governed in a transparent and consistent manner.

• Transparency ? providing visibility and clarity on issues pertaining to the standard and theenvironment it operates in 7for instance its design, specifications, governance8.

8a. +.( olicie# and con#ideration#*a. !.".1 Openness and participation


28/148

*a. !.".! )evelopment of open standards and consideration of non:open standards

Suitable open standards are not al-ays available. Therefore, the Open Banking %rame-ork mustensure engagement, as a key stakeholder, in the development of relevant open standards and take apragmatic approach to the selection of appropriate standards that help to reduce cost, promoteinnovation and meet the needs and ob=ectives of the Open Banking Standard.

%urther -ork -ill be re;uired to assess ho- standards that are not fully open can be made compatible-ithin the contet of the Open Banking Standard.

The follo-ing should be considered should compatibility of non:open standards be evaluated@

• Selection process ? if and ho- utilisation of a non:standard can ;ualify and be =ustified for adoption.

• #mplementation compatibility ? at a minimum, standards should be licensed on a 3N) or royalty:free and non:discriminatory basis, and terms and conditions must be compatible -iththe standard in both proprietary and open source soft-are. %urther considerations may bere;uired.

8a. A! Standard#

8a. .1 Approac"' re7uirement# and outcome#

3s per the principles and policies, in defining the 32# Standard, the follo-ing approach should betaken.

• Eisting open standards should be used -herever possible.

• Eisting taonomy and data lists 7e.g. currency descriptions8 should be used -herever possible and in instances -here the standard itself cannot be used.

• )eveloper eperience should play a significant role in informing design and a great developer eperience should be seen as a key outcome.

• 3 -orking assumption has been made that the Open Banking 32# -ill initially be pull rather than push and that streaming protocols -ill not be considered in early phases.

#n addition, the Open Banking 32# -ill specifically re;uire@

• a tight 32# schema 7U#s, re;uest and response8 on open repositories 7e.g. /it4ub8>

• minimum publishable 6ey 2erformance #ndicators 762#s8 due to potential business criticality

and to manage epectations regarding performance>

• clear change control and versioning procedures to lessen the impact on 32# providers andconsumers>

• once developed, the Open Banking 32# should align to the principles and specifically ehibit@

o openness -ith no commercial barriers to entry>

o technology and vendor independence>

o minimal commercial or technology barriers to adoption, i.e. free from vendor costs, or

licensing that prevents reuse, use of comple technologies, #2, etc>

o freedom to innovate etensions to the standard 7-ithin a governance frame-ork8.


29/148

#t should be noted that there are a number of emerging financial 32# sets in the market, but there isno eisting standard that meets all re;uirements for an Open Banking 32#.

8a. .( Arc"itecture #tyle

3 number of architectural styles are used for it describes the architectural style of the


30/148

8a. . A! definition

To create the Open Banking 32# in the EST style, it is important to have a clear and unambiguousdefinition of the interface, i.e. U#s, re;uests, responses, 4TT2 methods and status codes.

There are several competing approaches for describing EST 32#s, including 350 7ESTful 32#5odelling 0anguage8, 430 and S this -ill be addressed in future -ork.

8a .2 9er#ioning

'hange control, i.e. semantic versioning,1+

needs to be managed effectively other-ise adoption of the

Open Banking 32# could be negatively affected. Gersioning should be eplicit and a changed 32#

should not be released -ithout a ne- version.

The versioning process should@

• use release numbers for ma=or and minor releases>

• provideCaspire to back-ards compatibility for all 32# changes>

• provide back-ards compatibility for all minor releases on a mandatory basis>

• support additive changes for minor releases>

• guarantee support for developers for ma=or 32# versions, for a specified period>

• escalate security implementations -hen vulnerabilities come to light>

• apply to the data structures sent in the 32# re;uests and responses and, -herever possible,follo-


31/148

The core to the standard -ill specify resources that are common to all business areas, includingshared resources such as identity, core account information, core product information etc. 'hanges inthe core are epected to have an impact on every 32# and should therefore be managed carefully andoccur relatively infre;uently 7e.g. once per half:year8> the core should represent the slo-est:changingpart of the standard. Subse;uent -ork -ill define the core in more detail.

*a. (.1." %orking the standard

)omains included in the 32# are epected to be product:focused 7e.g. cash account services,mortgage:related services, savings:related services8. 32# providers are unlikely to implement everypart of the 32# specification. #t is likely that there -ill be domain:specific parts of the 32# that providersfocus on. Therefore to enhance innovation and competition, developers should be able to Dfork thestandard locally.

*a. (.1.! Etending at the edges

Etensions can be made to the core or to a product set. They can also be used to start a completelyne- product set of 32#s. 3ll etensions can be done -ithout asking permission, to encourageinnovation at the rate of the faster innovator.

Etensions to the standard should follo-, -here possible, the 32# Standard to ensure consistency

across all 32#s. These etensions may be subse;uently incorporated into the core or a product

domain, follo-ing approval -ithin the governance model.

Figure 8a.1 Open A! exten#ion#

8a. 5 C"ange and !nnovation :t"e /it;u% Approac"


32/148

'hange should be managed in a manner that encourages innovation and ;uick changes to thestandard, -hile maintaining control of the core to minimise the impact of change. #t9s important for allchanges to be managed in an open manner, to be sub=ect to critical revie- and to be documented-ith a full audit trail, including eplanations.

3 number of models eist to facilitate management of a layered 32#. /it4ub represents a good,

transparent implementation of a technical solution> it provides revision control and is -ell suited toediting a file in a distributed fashion.

The specification for the 32# Standard needs to have an open licence 7potentially a maimumpermissive licence, e.g. 5#T8 so users can fork and eperiment. #n /it4ub there is still one canonicalstandard> the forks are duplicates 7i.e. they are not Dreal until they are merged in8, so 32# providerscan -ork on their o-n fork 7see *a. (.1."8.

8a. 8 Control' Acce## and Security

8a. 8.1 !dentity and identifier #tandard#

The introduction of the Open Banking Standard may re;uire a ne- approach to identifiers ?particularly covering usage of standards and developer resources 7see 'hapter *b for more ondeveloper resources8. These identifiers could enable the identification of parties, resources, devices,applications and products.

3s a set of ongoing principles, identifiers should be@

• uni;ue, so that they can unambiguously identify a given Dob=ect> and

• non:proprietary, so that they can be freely used -ithin the system -ithout adding #2

restrictions to data.

3 good eample of the trend to-ards uni;ue, non:proprietary identifiers is the 0E#, -hich identifieslegal entities involved in financial transactions. Overseen by the -orld9s financial regulators andcentral banks, the 0E#, and its associated reference data, is published under a '' licence allo-ingfor free and unrestricted use.

5ore -ork -ill be re;uired to determine if identifiers are needed, the instances in -hich they areneeded and ho- a standard approach can be defined.

8a. 8.( ermi##ion# and entitlement#

To preserve security and entitlement fleibility, these recommendations should be follo-ed@

• Sensitive information should not be included in U#s as they are not considered secure7problems include attack vectors that leverage -eb server logging, caching, bro-ser history,user agents, referrer header, etc.8.

• Sensitive information should be replaced by a token, or -ith an indirect ob=ect reference 7e.g.Daccount1 instead of an actual account number8.

• /ranted entitlements should be kept separate from resource descriptions, to enable fleibleand sophisticated entitlements to be supported in the future.

5ore details on the security elements of the Open Banking Standard are available in 'hapter *c@

Security.


33/148

8a. 8.+ Scala%ility and performance

3doption of the Open Banking Standard could lead to increased load on legacy systems for 32#providers. #n order to address this scalability challenge, implementers may leverage cachinginfrastructure to reduce the load on the core banking system.

3 caching strategy -ill address read:based scalability challenges 7i.e. the serving of data8, -hichshould represent the ma=ority of 32# interactions. %or 32# interactions that are -rite:based 7e.g.instruction of payment8 these should, -here possible, be modelled asynchronously.


34/148

Figure 8a.( Open Banking ,ata Standard

8a. =.( *eference data model

The reference data model -ill describe data that is shared under the Open Banking Standard in amanner that is technology:neutral, consistent, reusable and -ell defined. #t -ill form a library of structured and individual business components, data components and data structures 7data types or patterns8 described in a uniform notation. The model -ill be used by all those that adhere to the Open

Banking Standard 7a similar approach has been implemented by the


35/148

form part of the core Open Banking 32# and therefore needs to be consistently implemented acrossall organisations.

Open data should also adhere to the principles of open access and treatment of #2 7such as codes,soft-are, reference data, etc.8. The licence rights to use open data need to be clear and potentiallyincluded as a field -ithin the ISON.

8a. 1? /overnance

8a. 1?.1 ,eci#ion-making

#n terms of deciding -hat -ill be adopted into the 32# and )ata Standards, it is recognised that thereare a variety of options 7models such as 3pache,

There may eist the possibility to reuse governance structures of eisting standards bodies for theOpen Banking Standard, but this -ould need to be eplored further.

8a. 11 !ntellectual roperty and atent#

8a. 11.1 Copyrig"t and ! :relating to t"e Open Banking Standard<

To the etent possible, the copyright for all Open Banking Standards shall belong to the legal entityresponsible for the Open Banking Standard 7see 'hapter *d@ /overnance8.

The treatment of #2 7such as codes, soft-are, reference data, etc.8 should be according to theprinciples of open access and the nature of the Open Banking Standard as a public good. Theob=ective of this shall be to ensure a regime that assures the availability in the public domain, -ithoutlimit on use or redistribution 7for the Open Banking Standard8. 3ny #2 rights should be held by, or licensed to the Open Banking Standard. 'opyright should be used to the etent possible to promotethe free flo- or combination of information from disparate sources.

The Open Banking Standard should be designed to ensure that it is not locked in -ith a particular service provider for any key system functions or processes, and that the principles of competition areensured on both global and local levels -here appropriate. The governance of the standard shouldprovide safeguards to ensure that competition principles and antitrust considerations are upheld.

The steady:state funding of the Open Banking Standard should be self:sustainable and reliable. Thefunding system should be based on an efficient, non:profit, cost:recovery model. The costs of implementing and sustaining the Open Banking Standard and developer resources 7proposed in'hapter *b8 should be sufficiently modest not to act as a barrier to entry .


36/148

8a. 11.( Approac" on patent#

eference to patented items -ithin the Open Banking Standard should be avoided. #f, in eceptionalsituations, technical reasons =ustify such a step, there is no ob=ection in principle to preparingstandards that include the use of items covered by patent rights 7as defined in the glossary8 even if the terms of the standard are such that there are no alternative means of compliance.

#f technical reasons =ustify the preparation of a document in terms that include the use of itemscovered by patent rights, the originator of the proposal shall dra- the attention of the Open BankingStandard9s #ndependent 3uthority to these patent rights. #f the proposal is accepted, the originator shall ask any holder of such identified patent rights for a statement that the holder -ould be -illing tonegotiate licences in all of the countries -here they have obtained patent protection under their rights-ith applicants throughout the -orld on 3N) terms and conditions. 3 record of the right:holderQsstatement shall be recorded by the Open Banking Standard9s #ndependent 3uthority. #f the right:holder does not provide such a statement the proposal concerned shall not be included.

8a. 11.+ 0icence#

#t is critical that licensing of the Open Banking system presents fe- legal and technical barriers toadoption, therefore using permissive licences to encourage reuse.

The follo-ing recommendations are made@

• Open Banking Standard 7copyright8@ this should be made available under a '' licence7effectively public domain8 that permits it to be freely used, reused and distributed, or failingthat '':BK 7attribution8.

• Open data falling under the Open Banking Standard@ any licence here -ould be a barrier toreuse and potentially end up -ith long Dlicence chains. Therefore open data should be madeavailable under a '' licence 7the same licence used by the /lobal 0E# system for its data8.

• System soft-are, e.g. core libraries or sandbo 7see 'hapter *b@ )eveloper esources8.5any banks -ill have difficulty in using soft-are that is difficult to integrate -ith proprietarysoft-are> therefore -e recommend licensing under a 5#T licence.

8a. 1( %i7uity @ Ac"ieving Net$ork Benefit# in a

Collective Action Setting

8a. 1(.1 *egulatory incentive @ alignment $it" S,(

3s discussed else-here in this report, the revised 2ayment Services )irective 72S)"8 re;uires someof the same outcomes as could be delivered via an Open Banking Standard in U6 banking. 3s aresult, there is a driver for some aspects of the implementation of an Open Banking Standard.

There is clearly an opportunity to leverage the regulatory drivers of 2S)" to ensure that at least thecore elements of standardisation proposed in this report are adopted.

Of course, in terms of competition, the need for ubi;uity should not result in standardisation activitiesthat inadvertently lead to eclusion or discrimination against third parties or ne- technologies. 3s this-ork progresses, it -ill be important to take a collaborative approach -hich engages -ith thetransposition of 2S)" so that respective policy processes are aligned.


37/148

8a. 1+ 0and#cape

3 number of eisting pro=ects might be looked to in terms of reusing or utilising elements for use in theOpen Banking Standard. These are detailed in 3ppendi $.

8%. ,eveloper *e#ource#

8%. 1 C"apter Outline

This chapter identifies the developer 7third party8 resources needed to deliver a compelling developer eperience, thereby facilitating developer adoption. #t outlines key re;uirements at each stage of adeveloper9s =ourney and also provides recommendations to help preserve the developer eperience inlight of provider 32# constraints 7e.g. limitations on use, costing etc.8.

8%. ( &ey *ecommendation#

8%. (.1 ,eveloper re#ource# re7uirement#

*b. ".1.1 'reation of a developer hub

3 central developer hub containing reference documents for the 32# and a reference implementationof the core 32#s should be established. #t should contain an implementation register, listing 32#providers that have implemented the Open Banking Standard, specifying their products and versions.

The developer hub is seen as critical in aiding developers in discovery 7i.e. understanding the dataand services 32#s epose8 and engagement 7i.e. identifying suitable 32# providers8.

*b. ".1." )evelopment of a central sandbo

3 central sandbo for the reference core Open Banking 32# 7and product sets8 in the developer hubshould be provided. #t should be implemented at all security levels, contain a set of eecutable tests

that 32# consumers can use to validate compliance and be provided free of cost to developers.

The central sandbo is seen as a key enabler of developer Dplay, allo-ing eperimentation -ith the 32# in a simulated environment. #ts centralisation also accelerates developer adoption in anecosystem -here not all 32# providers -ill develop local sandboes.

8%. (.( 4et"od# to pre#erve t"e developer experience

62#s, e.g. the number of calls per second allo-ed before throttling, maimum response time, etc.,should be published by 32# providers to provide transparency on serviceCperformance constraints.


38/148

8%. + urpo#e

On the assumption that an Open Banking -orld is in operation, -ith many provider 32#s operatingunder the Open Banking Standard, this chapter -ill outline the developer 7third party8 resources thatis re;uired to facilitate discovery, play and engagement from a diverse developer community. #t -illalso outline further areas for consideration relating to developer adoption.

8%. ,eveloper Experience' !ncentivi#ing Adoption

8%. .1 4otivation#

%or the Open Banking Standard to be successful, an engaged developer community must becultivated. 6ey to this is creating a compelling 32# developer eperience 732P8> barriers toparticipation should be as lo- as possible.

)evelopers -ill fall into distinct profiles that -ill re;uire tailored 32Ps. Eamples include@

• 4obbyist developers ? individuals -ho are building their o-n app to run or to gain eperience>

• %inTech developers ? highly technical developers -orking in companies of 1:1 -ho -antto eperiment very ;uickly>

• )igital agencies or S# partners ? technically adept developers -ho are building solutions for other companies>

• 'orporate clients or large companies ? from both financial services and ad=acent industries-ho -ant to develop their o-n solutions.

8%. .( ,eveloper )ourney

#n order to create high:;uality 32P, consideration should be given to the developer =ourney>understanding re;uirements across discovery, play and engagement.

*b. &.".1 )iscovery

)evelopers need to kno- -hat data and services 32#s epose. They need to develop anunderstanding of the data offered and ho- up to date it is, -hile forming a vie- of -hat the data andfunctionality provided via the 32# can be used for. #n the instance material on use cases and -orkedeamples are available, the developer -ill use these to inform of their participation and potentialproposition development.

*b. &."." 2lay

)evelopers -ill -ant to eperiment -ith the 32#s ? usually early in the lifecycle of a pro=ect. Thedeveloper may already have a business case, or may be in the process of determining potentialvalue. 2lay can be undertaken in different -ays, from using reference documentation 7i.e. by typing inparameters and looking at sample responses8, or eperimenting in simulated environments.

*b. &.".! Engagement

Before a developer can use an 32# in production -ith real data, they need to find an 32# provider that

has implemented the 32#s.


39/148

8%. 2 ,eveloper *e#ource#

8%. 2.1 Central developer "u%

3 central developer hub containing key reference documents and implementation registers should becreated to support developers in gaining a practical understanding of the data and services offered

from both the Open Banking Standard and specific 32# providers. This addresses key developer re;uirements in discovery and engagement 7see *b. &."8.

Specifically, the developer hub -ill@

• contain reference documents for the 32# and a reference implementation of the core 32#s>

• provide specifications as a set of eecutable tests>

• contain an implementation register, listing 32# providers that have implemented the OpenBanking Standard, -hile also specifying -hich products and versions of the Open Banking 32# they have adopted>

• link to 32# providers that have implemented the Open Banking Standard 7and potentially their etensions8 and provide information on their implementations>

• hold all historic versions of the core Open Banking 32#, but implement the most recentlyapproved.

The developer hub should be advertised on developer ne-s and information platforms 7e.g.2rogrammable

• contain a set of eecutable tests that 32# developers can use to validate compliance>


40/148

• be provided free of cost to developers so barriers to entry are avoided.

%or clarity, it should be noted that use of the sandbo does not imply accreditation> 7see 'hapter *d@/overnance8.

8%. 2.+ Example#

1. Stripe3 an eample of documentation pitched at developers is that available from Stripe. #tssite allo-s developers to try the 32#s out immediately and gives code eamples in severalprogramming languages.

". T"e Open Bank ro)ect3 recently launched an 32# eplorer that has received positivefeedback. They let a developer access a dummy bank account making test calls -ith securityto ;uickly discover value.

8%. 5 Ot"er Con#ideration#

8%. 5.1 Con#traint#

)evelopers -ill -ant to understand -hat constraints are imposed by 32#s. These could include@

• limitations on use>

• costing, i.e. imposition of a charging model>

• 7lack of8 data freshness>

• limitations on support provided.

'onstraints -ill vary depending on the 32# provider, so it is recommended that each provider givesclear information about all constraints.

This information should be provided in the form of 6ey 2erformance #ndicators 762#s8, e.g. thenumber of calls per second allo-ed before throttling, maimum response time, etc. These 62#sshould provide clarity on the above constraints. #n addition, as a principle 32# response time shouldbe at least as fast as the e;uivalent -ebsite 7if this eists8 so 32# access is not deterred.

5inimum service level agreements 7S03s8 -ill not be imposed as this could present a barrier to entry.)ifferent providers are likely to operate under different S03s.


41/148

8c. Security

8c. 1 Outline

This chapter covers three broad areas.

1. Security aspects of the 32# specification, including authentication, authorisation, accesslevels and permission and encryption.

". Security standards for data attribute providers and third:parties.

!. Security aspects of open data.

8c. ( &ey *ecommendation#

8c. (.1 #er con#ent

#n the contet of data:sharing -ith a third:party a principle of informed consent should be adopted.The user should clearly understand the authorisation they are being asked to provide, including@

• -ho they are providing authorisation to>

• -hat they are providing authorisation for 7i.e. -hat the authorisation -ill permit the third partyto do8>

• ho- long the authorisation -ill last for.

8c. (.( Aut"entication

The process through -hich a customer authenticates itself to its data attribute provider 7in order tofurther authorise a third party access8 -ill be a tripartite process and should be designed to minimise

digital friction. Specifically@

• data attribute providers and third parties should retain control over authentication method.

• O3uth ". in con=unction -ith Open#) 'onnect are recommended as authentication protocolsof choice ? future -ork -ill be needed to specify the precise model.

8c. (.+ Fraud detection and monitoring

• The 32# should provide support for out:of:band 7OOB"18 authentication.

"1 6u-o-band B668C: 6u-o-band is acvi ouside a de=ned elecommunicaons re,uenc band3 or3 meaphoricall3ouside some oher +ind o acvi.


42/148

• )ata 3ttribute 2roviders should be re;uired to notify the user asynchronouslyCOOB -hensignificant actions have occurred 7e.g. a change to a payee8.

• The 32# response should inform the third party that an OOB process is under-ay so that,-here appropriate, they can inform the customer.

• The practicality of including fraud:relevant information 7e.g. #2 addresses8 in the 32# returnmessage from the third party should be assessed in future -ork.

8c. (. Aut"ori#ation

Once a customer has authenticated -ith their data attribute provider tokens should be used to ensurethe third party is acting -ithin the bounds of the permissions granted. The third:party service shouldprovide evidence that it is entitled to use the authorisation token 7e.g. by -ay of providing a client #)and client secret8 to the data attribute provider Each data attribute provider -ill be responsible for issuing its o-n tokens and ensuring third parties are in possession of legitimate tokens.

• 2ermissions@ access granted to third:party providers should be defined in terms of specificpermissions to data andCor functionality. To reflect the potential risks from malicious misuse of permissions and protect consumers9 interests, the follo-ing are recommended@

o /ranting users and, in certain instances the data attribute provider revocation rights>

o e;uiring data attribute providers to establish a mechanism through -hich users can

revie- and cancel their permissions>

o 3ssigning risk levels to permissions>

o 3llo-ing for prohibitions on granting permissions>

o 2lacing contetual limits on permissions -here appropriate 7e.g. payment limits8>

o Sub=ecting permissions to timeCduration limits.

• oles@ a set of permissions and roles should be defined -ith a standardised nomenclature infuture -ork.

• Encryption@ 32# connections and data in transit should be encrypted using T0S v1." as aminimum.

• 'ertification@ should be used to coordinate the management and issuing of digital certificates-ith a -hitelist of approved companies.

• Security standards@ it is suggested to use the 'he;ue 2rinters 3ccreditation Scheme 7'23S8as a model, i.e. a security accreditation model based on #SO"*1 -ith a specific minimumthreat profile, against -hich independent auditors can assess the security of data attributeproviders and third parties 7it may be appropriate to grant a -aiver to certain data attributeproviders, e.g. banks8.

#t is recommended that the task of defining a threat profile relevant to the open banking environmentbe carried out by a body that includes relevant professional individuals and -ider representativestakeholders -ith eperience of the financial sector and the threats the third parties and data attributeproviders are likely to face. 3 control frame-ork should be implemented to address the risk profile toset a reasonable industry standard security control. This should be done in such a -ay that allo-sfleibility for future threats and technical fleibility to allo- innovation in implementation of the controls.


43/148

8c. *i#k#

The gro-ing threat from cyber:criminals means that the adoption of the Open Banking 32# brings -ithit significant security challenges. Banks have traditionally protected their clientsQ accounts andinformation -ithin a clearly defined and tightly controlled environment. 3llo-ing customers to grantthird parties access to their data -ill epand the security perimeter beyond the data attribute

providersQ control, and introduce ne- risks. esponsibility for protecting clientsQ data -ill be shared bythird parties.

The design of the Open Banking Standard must take account of this ne- security paradigm andaddress the risks it brings.

8c. .1 Open Banking A! a# a ne$ attack vector

3s a ne- technology and method of gaining access to customer data, it is likely that cyber:criminals-ill specifically focus on the open 32# as a ne- attack vector. The ability to amend or make payments-ill be a specific driver. 3ttacks are likely to include both eploiting any technical -eaknesses that

may eist in implementations of the open 32#, supporting applications and services, or through socialengineering of customers -ho -ill be unfamiliar -ith the 32# process. )etails obtained may beleveraged to effect an account takeover or commit fraud through other channels. The rollout of theOpen Banking 32# may also provide opportunities for bad actors to eploit customers9 naivetR or lackof familiarity -ith the processes surrounding the 32# to conduct phishing or social engineering attacks7e.g. criminals could attempt to create fake apps or services, or prompt customers to provide authorityto a third party but not actually read the re;uests properly, =ust simply approve -hatever has beenre;uested in order to let the app or service -ork8.

8c. .( Aggregation of data at t"ird partie#

Third parties that collate and store data on behalf of customers are likely to become a primary targetfor criminals. 3 popular Dmain player in this area could potentially hold a significant amount of customer data, across multiple data attribute providers. 'ompromising this single entity could beeasier and more lucrative than attacking multiple data attribute providers.

8c. .+ !ntermediary t"ird partie#

#n the event that third parties are permitted to act as intermediaries for other third parties, there is therisk that data may be passed on to third parties that do not have appropriate security measures inplace. Special consideration should be given to this scenario and clear policies should be put in placeto govern and restrict ho- data obtained by the primary third party is passed to secondary third

parties, and define -hat vetting re;uirements and security standards secondary third parties -ill besub=ect to.

8c. . Compromi#e of cu#tomer device#

'ustomer devices8 such as personal computers, laptops, tablets and smartphones are commonlytargeted by cyber:criminals, and have been sho-n to be highly susceptible to compromise. 3s aresult, any data or credentials 7e.g. access tokens8 that are stored on customer devices are at risk of compromise.

%urthermore, -hen a customer device is used to access an 32#8, the risk eists that a bad actor that

compromises the customer device may be able to access the 32# by controlling the device remotely,effectively impersonating the user.


44/148

The opportunity to mitigate the risk of such attacks is limited. Therefore, the Open Banking 32# shouldinclude measures designed to minimise their impact if and -hen they do occur.

8c. .2 Emerging t"reat#

Not all risks and threats can be anticipated. The security risk landscape -ill evolve and develop over time as eisting security technologies become obsolete and bad actors develop ne- techni;ues. Ne-threats may emerge that re;uire rapid, decisive and coordinated action by third parties and dataattribute providers.

The Open Banking Standard must be capable of recognising, reacting and adapting to emerging risksand threats. e;uirements that third parties and data attribute providers share information on securityincidents -ill facilitate recognition 7see section *c. 11.&@ #nformation sharing and incident handling8.

2olicies and procedures should be established to support the implementation of changes to the OpenBanking Standard at short notice.

8c. 2. Con#umer rotection

8c. 2.1 Cu#tomer confidence

'ustomer confidence is built on a number of tangible and intangible elements and security clearlyplays an important role 'ustomer confidence in the 32# ecosystem is likely to be bolstered if it isclear that that third parties and data attribute providers are sub=ect to appropriate security standards

and that appropriate protections are in place from a fraud perspective.""

Ultimately, for customers, confidence may also link to the ;uestion of liability for losses that resultfrom security breaches. This has security implications in that the security measures and standardsemployed should align -ith and support the liability model. %urther consideration should be given tothis topic at the net stage of the Open Banking Standard development.

8c. 2.( #a%ility v#. #ecurity

#t is important to ensure that security measures are put in place to mitigate risks associated -ith theOpen Banking 32#. 4o-ever, these should not be so restrictive andCor onerous that they

unreasonably reduce the utility, usability and benefits derived from products and services reliant on 32#s. The challenge is to balance customer protection -ith the potential benefits.

3 possible benchmark to use for determining -hether usability is unreasonably restricted is tocompare the functionality offered by the open 32# -ith that offered by data attribute providers9 eisting-ebsites and apps. %or eample, if, -ithin the scope of the Open Banking 32#, a data attributeprovider9s o-n -ebsite and mobile app -ere to offer significantly more functionality than is availablethrough the 32#, that -ould suggest that the 32# may be unduly restricted. )ata attribute providers,and any other institutions, are free to provide additional services on top of the core Open Banking 32#> the point here is that restrictive practices 7e.g. unnecessarily comple controls8 for commonlydefined services -ill be unacceptable.

22

ecen research published b 'psos 6' and 8arclas shows ha or cusomers using 17'-based producs securi isimporan and Dconsumer proecon needs o orm a +e par o an developmens in his areaE. See htp://www.ipsos-

mori.com/researchpublicaons/publicaons/;5"/6pen-17'-#(ploring-he-views-o-consumers-and-small-businesses.asp(


45/148

Balancing usability and security inevitably re;uires a certain amount of risk acceptance. #t is importantthat consumers are made a-are of and understand the risks they may be incurring by making use of a third party9s service or app.

8c. 2.+ !nformed con#ent*c. (.!.1 'larity

3 core principle of this report is informed consent. This is discussed further in chapter , ho-ever, theprinciple of informed consent implies that the customer must be able to clearly understand theauthorisation they are being ask to provide, including@

• -ho they are providing authorisation to>

• -hat they are providing authorisation for 7i.e. -hat the authorisation -ill permit thethird partyto do8>

• ho- long the authorisation -ill last for.

#f the third party intends to share the customer9s information -ith another party, this must also bemade clear and the customer must be given the opportunity to opt out of having their data shared.

'ustomers must have the ability to revie- this information before, during and after authorisation hasbeen granted and to revoke any authorisation they have previously granted.

They must also have confidence that their data -ill not be retained by a third party unnecessarilyafter authorisation to access it has epired or been revoked. #t is the responsibility of each third partyand data attribute provider to ensure they are complying -ith relevant )ata 2rotection 3ct 7)238.

*c. (.!." 'ommon terminology

The Open Banking Standard must define common terminology for describing the fine:grainedpermissions defined by the 32#, as -ell as any roles that may be granted. )efinitions must be simple,concise and easily understood by customers. 3ll parties should adhere to the standard terminology,-ith any variance highlighted and eplained clearly.


46/148

Eplicit 32# functionality to support out of band challenges should be put in place to allo- dataattribute providers to re;uire an additional level of authentication before an action is authorised 7e.g. ane- payment8. Third parties should also be able to re;uestCtrigger re:authentication by the dataattribute provider 7e.g. in the event that the third party detects suspicious activity that may not beapparent to the data attribute provider8.

The 32# should support the use of one:time transaction authorisation codes that are supplied out of band to be submitted via the 32#, as -ell as transactions that must be authorised entirely outside the 32#. The latter implies that the 32# must also support the concept of D;ueued or Dpendingtransactions that must be authorised by the customer before the data attribute provider -illacceptCaction them.

• 2'# )SS>

• '23S>

• tScheme.

#t is suggested to adopt a security standards approach based on the #SOC#E' "* series of standards, -ith a tiered approach, i.e. the standard the third party is re;uired to meet and the degree

of scrutiny to -hich it is sub=ect should be commensurate -ith the access the third party seeks toobtain. %or lo-er levels of access 7e.g. accessing open data8, self:certification may be =udgedsufficient -hile high levels may re;uire that the third party9s compliance -ith the relevant standards beindependently audited. This is the approach adopted by e.g. 2'# )SS.

The servers and infrastructure operated by third parties and data attribute providers must beprotected against cyber:attack. Security standards should mandate security controls that arecommensurate -ith the nature of the data and functionality that is provided. 3t this stage, this reportis not broaching details pertaining to appropriate security controls, but it is epected they -ill includethe use of penetration testing, fire-alls, intrusion detection systems, hard-are security modules, OSpatching policies, etc. #t is recommended that a specific -orkstream is established to define thesecurity standards in this area and then to revie- them at appropriate intervals to ensure that they arekept up to date -ith emerging threats and technologies.

Eisting financial institutions 7i.e. future data attribute providers8 have built up considerableeperience in this area> their input is epected to prove valuable.


47/148

The need and etent to include security testing of applications and servers on a timely basis is a topicthat should be covered in further detail in future stages of -ork.

There are a number of other -orking groups and standards bodies undertaking -ork that has bearingon, or parallels -ith the Open Banking 32#, -hose -ork could be leveraged as appropriate. 2eer revie- is also an important step in the design of security standards. #t is recommended that

appropriate organisations and individuals be identified and invited to revie- and comment uponproposals and drafts produced in the process of creating the Open Banking 32#.

#t is also recommended that -ork to-ards the Open Banking 32# be conducted as openly as ispracticable and that the public is given the opportunity to revie- and comment on it informally 7e.g.through mailing lists or social media8.

8c. =. Security and Aut"entication A#pect# of t"e A!

Specification

8c. =.1 Aut"entication

*c. $.1.1 User eperience, process and technical data flo-

• The customer authenticating themselves to a third party>

• The third party authenticating themselves to an data attribute provider 7in order to access acustomer9s data8>

• The third party authenticating themselves to a customer.

)ata attribute providers and third parties should o-n and control the method by -hich they

authenticate their customers."! The methods by -hich a third party authenticates itself to a data

attribute provider, and a user may identify a third party, should form part of the Open Banking 32#specification.

The process by -hich a customer authenticates themselves to a data attribute provider in order toauthorise the granting of permissions to a third party -ill be a tripartite process, -hich should bedesigned in a -ay that minimises digital friction, to avoid discouraging or confusing customers. #t -illpotentially involve a hand:off of customer interaction from the third party to the data attribute provider for the authentication to be carried out, follo-ed by a redirect of the customer back to the third partyfrom the data attribute provider after the authentication and authorisation interaction process hasbeen completed.

This approach has the benefit of allo-ing the data attribute provider to continue to o-n and controlthe method for authenticating its customers 7thereby minimising the risk that a third party could obtainpermissions -ithout eplicit approval by the customer8 and avoids mandating the use of specificauthentication methods. Separately, customers -ill also need to authenticate themselves to thirdparties in order to gain access to the services or functionality being provided. The method used by

2)

1s previousl noed3 he #81 has alread issued guidelines regarding auhencaon or inerne pamens Bhe Securio inerne 7amen FuidelinesC and urher elaboraon on hese rules in he cone( o hird-par services is e(peced o

suppor he implemenaon o 7SA2.


48/148

both data attribute providers and third parties to authenticate customers should be appropriate toade;uately protect the data and functionality in ;uestion.

Figure 8c.1 Aut"entication and aut"ori#ation3 cu#tomer experience example :account

aggregation<

Figure 8c.( Aut"entication and aut"ori#ation3 "ig"-level proce## flo$


49/148

Figure 8c.+ Aut"entication and aut"ori#ation3 tec"nical data flo$

*c. $.1." Selection of O3uth ". -ith future consideration of Open#) 'onnect

The %ingleton eport recommended the use of the O3uth ". protocol, -hich supports the tripartiteapproach outlined in *c. $.1.1. This report endorses this recommendation, although further consideration must be given to the specific implementation.

The O3uth ". protocol supports a variety of different interpretations and styles of interaction, -ithdifferent security implications. The Open Banking 32# should prescribe ho- authentication andauthorisation aspects of the standard are implemented, so the appropriate levels of consistency,interoperability and security are achieved. #t is recommended that the Open#) 'onnect authenticationprotocol 7-hich provides an identity layer on top of the O3uth ". protocol8 be considered as part of this process. 3ppendi + sets out some considerations pertaining O3uth 1. and ". and Open#)

'onnect.

4aving been granted permission to access a customer9s account information and act on thecustomer9s behalf, there must be a method -hereby the third party can authenticate themselves tothe data attribute provider during subse;uent interactions. O3uth ". solves this through the use of atoken that is provided by the 3S2 to the third party at the point at -hich permission to access anaccount is granted. The third party then presents the token to the each time it -ishes to access theaccount.

*c. $.1.! %urther considerations

The Open Banking 32# should define a method by -hich users can identify any third party they areinteracting -ith, particularly at the point at -hich they are granting authorisation, for eample, using


50/148

certificates. There must also be a method by -hich the data attribute provider may verify that a thirdparty is authorised to receive the permissions it is re;uesting.

8c. > Aut"ori#ation8c. >.1 T"e aut"ori#ation proce##

The O3uth model as it -ould apply to the Open Banking 32# is as follo-s@

#n the course of an interaction -ith the third party, the customer communicates intent to grant the thirdparty access to account information held by a data attribute provider@

1. The third party re;uests access to the customer9s account information from the data attributeprovider>

". The data attribute provider authenticates the customer>

!. The data attribute provider revie-s -hether the third party is authorised to receive the accessit is re;uesting>

&. The data attribute provider displays to the customer the access being re;uested by the thirdparty>

(. The customer revie-s the access being re;uested by the third party and authorises the dataattribute provider to grant the re;uested access to the account information and act on thecustomer9s behalf>

+. The data attribute provider grants the third party the re;uested access.

Steps ( and + must not involve the third party> doing so -ould provide opportunities for a bad actor toconceal the etent of the access being re;uested from the customer.

8c. >.( *e#pon#i%ilitie# of t"e data attri%ute provider

The data attribute provider must allo- the customer to revie-@

• pertinent information about the third party 7e.g. the company name, location, -hat level of authorisation it has received8>

• permissions being re;uested by the third party> and

• duration and validity for -hich the permissions -ill be granted.

3fter the fact, data attribute providers must provide an independent mechanism 7i.e. -ithout any thirdparty provided soft-are or service8 for customers to revie- the permissions they have gr

Documents

The Open Banking Standard