Retired Draft
Retired Document
Status Initial Public Draft (IPD)
Series/Number NIST Internal Report (IR) 8389
Title Cybersecurity Considerations for Open Banking Technology and
Emerging Standards
Publication Date January 2022
Additional Information See https://csrc.nist.gov for information on NIST cybersecurity
publications and programs.
Warning Notice
The attached draft document has been RETIRED. NIST has discontinued additional
development of this document, which is provided here in its entirety for historical purposes.
Retired Date May 11, 2023
Original Release Date January 3, 2022
Draft NISTIR 8389 1
2
Cybersecurity Considerations for
3
Open Banking Technology and
4
Emerging Standards
5
6
Jeffrey Voas 7
Phil Laplante 8
Steve Lu 9
Rafail Ostrovsky 10
Mohamad Kassab 11
Nir Kshetri 12
13
14
15
16
This publication is available free of charge from: 17
https://doi.org/10.6028/NIST.IR.8389-draft 18
19
20
Draft NISTIR 8389 21
22
Cybersecurity Considerations for
23
Open Banking Technology and
24
Emerging Standards
25
26
Jeffrey Voas Rafail Ostrovsky 27
Computer Security Division UCLA 28
Information Technology Laboratory Los Angeles, CA 29
30
Phil Laplante Nir Kshetri 31
Mohamad Kassab University of North Carolina 32
Penn State University at Greensboro 33
State College, PA Greensboro, NC 34
35
Steve Lu 36
Stealth Software 37
Los Angeles, CA 38
39
This publication is available free of charge from: 40
https://doi.org/10.6028/NIST.IR.8389-draft 41
42
January 2022 43
44
45
46
U.S. Department of Commerce 47
Gina M. Raimondo, Secretary 48
49
National Institute of Standards and Technology 50
James K. Olthoff, Performing the Non-Exclusive Functions and Duties of the Under Secretary of Commerce 51
for Standards and Technology & Director, National Institute of Standards and Technology 52
National Institute of Standards and Technology Interagency or Internal Report 8389 53
45 pages (January 2022) 54
This publication is available free of charge from: 55
https://doi.org/10.6028/NIST.IR.8389-draft 56
Certain commercial entities, equipment, or materials may be identified in this document in order to describe an 57
experimental procedure or concept adequately. Such identification is not intended to imply recommendation or 58
endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best 59
available for the purpose. 60
There may be references in this publication to other publications currently under development by NIST in accordance 61
with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, 62
may be used by federal agencies even before the completion of such companion publications. Thus, until each 63
publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For 64
planning and transition purposes, federal agencies may wish to closely follow the development of these new 65
publications by NIST. 66
Organizations are encouraged to review all draft publications during public comment periods and provide feedback to 67
NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at 68
https://csrc.nist.gov/publications. 69
Public comment period: January 3, 2022
- March 3, 2022 70
Submit comments on this publication to: nistir-8389-comm[email protected] 71
National Institute of Standards and Technology 72
Attn: Computer Security Division, Information Technology Laboratory 73
100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930 74
All comments are subject to release under the Freedom of Information Act (FOIA). 75
76
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
ii
Reports on Computer Systems Technology 77
The Information Technology Laboratory (ITL) at the National Institute of Standards and 78
Technology (NIST) promotes the U.S. economy and public welfare by providing technical 79
leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test 80
methods, reference data, proof of concept implementations, and technical analyses to advance the 81
development and productive use of information technology. ITL’s responsibilities include the 82
development of management, administrative, technical, and physical standards and guidelines for 83
the cost-effective security and privacy of other than national security-related information in federal 84
information systems. 85
Abstract 86
“Open banking” refers to a new financial ecosystem that is governed by specific security 87
profiles, application interfaces, and guidelines with the objective of improving customer choices 88
and experiences. Open banking ecosystems aim to provide more choices to individuals and small 89
and mid-size businesses concerning the movement of their money, as well as information 90
between financial institutions. Open baking also aims to make it easier for new financial service 91
providers to enter the financial business sector. This report contains a definition and description 92
of open banking, its activities, enablers, and cybersecurity and privacy challenges. Open banking 93
use cases are also presented. 94
Keywords 95
open banking; computer security; privacy; cybersecurity; APIs. 96
97
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
iii
Acknowledgments 98
The authors thank Rick Kuhn, Tom Costello, and Zubin Gautam for their input to this document. 99
100
Audience 101
This publication is accessible for anyone who wishes to understand open banking and the 102
associated cybersecurity and data privacy issues. It is particularly applicable to developers of 103
open banking standards as well as implementers of open banking applications. 104
105
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
iv
Call for Patent Claims 106
This public review includes a call for information on essential patent claims (claims whose use 107
would be required for compliance with the guidance or requirements in this Information 108
Technology Laboratory (ITL) draft publication). Such guidance and/or requirements may be 109
directly stated in this ITL Publication or by reference to another publication. This call also 110
includes disclosure, where known, of the existence of pending U.S. or foreign patent applications 111
relating to this ITL draft publication and of any relevant unexpired U.S. or foreign patents. 112
113
ITL may require from the patent holder, or a party authorized to make assurances on its behalf, 114
in written or electronic form, either: 115
116
a) assurance in the form of a general disclaimer to the effect that such party does not hold 117
and does not currently intend holding any essential patent claim(s); or 118
119
b) assurance that a license to such essential patent claim(s) will be made available to 120
applicants desiring to utilize the license for the purpose of complying with the guidance 121
or requirements in this ITL draft publication either: 122
123
i. under reasonable terms and conditions that are demonstrably free of any unfair 124
discrimination; or 125
ii. without compensation and under reasonable terms and conditions that are 126
demonstrably free of any unfair discrimination. 127
128
Such assurance shall indicate that the patent holder (or third party authorized to make assurances 129
on its behalf) will include in any documents transferring ownership of patents subject to the 130
assurance, provisions sufficient to ensure that the commitments in the assurance are binding on 131
the transferee, and that the transferee will similarly include appropriate provisions in the event of 132
future transfers with the goal of binding each successor-in-interest. 133
134
The assurance shall also indicate that it is intended to be binding on successors-in-interest 135
regardless of whether such provisions are included in the relevant transfer documents. 136
137
Such statements should be addressed to: nistir[email protected] 138
139
140
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
v
Table of Contents 141
1 Introduction ............................................................................................................ 1 142
1.1 Fundamental Banking Functions Provided by Financial Institutions ............... 1 143
1.2 Multiple Financial Institutions .......................................................................... 2 144
1.3 Open Banking Defined .................................................................................... 2 145
2 Use Cases ................................................................... Error! Bookmark not defined. 146
3 Differences from Conventional e-Banking and Peer-To-Peer Financial 147
Platforms ........................................................................................................................ 8 148
4 Survey of Open Banking Approaches Around the World ................................. 10 149
4.1 European Union and United Kingdom ........................................................... 10 150
4.1.1 Development of open-banking standards and API specifications ....... 10 151
4.1.2 From Open Banking to “Open Finance” .............................................. 12 152
4.1.3 The Impact of Privacy and Cybersecurity Considerations .................. 13 153
4.2 Australia ........................................................................................................ 15 154
4.3 India .............................................................................................................. 16 155
4.4 United States ................................................................................................ 18 156
4.5 Other Countries ............................................................................................ 20 157
5 Positive Outcomes and Risks ............................................................................. 23 158
6 Software and Security Practices in Banking-Related Areas ............................ 24 159
7 API Security: Widely Deployed Approaches and Challenges .......................... 25 160
7.1 Intrabank APIs .............................................................................................. 25 161
7.2 Interbank APIs .............................................................................................. 25 162
7.3 API Security .................................................................................................. 26 163
8 Privacy Relations to NIST and Other Standard Frameworks ........................... 27 164
9 Conclusion ................................................................. Error! Bookmark not defined. 165
References ................................................................................................................... 29 166
167
List of Appendices 168
Appendix A— Acronyms ............................................................................................ 36 169
Appendix B— Glossary .............................................................................................. 38 170
171
172
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
1
1 Introduction 173
Open banking (OB) describes a new financial ecosystem that is governed by a set of security 174
profiles, application interfaces, and guidelines for customer experiences and operations. OB 175
ecosystems are intended to provide new choices and more information to consumers, which 176
should allow for easier interaction with and movement of money between financial institutions 177
and any other entity that participates in the financial ecosystem. OB also aims to make it easier 178
for new actors to gain access to the financial sector (e.g., smaller banks and credit unions), has 179
the potential to reduce customers fees on transactions, and is already in use in various countries. 180
1.1 Fundamental Banking Functions Provided by Financial Institutions 181
Financial institutions engage in lending, receiving deposits, and other authorized financial 182
activities. There are nine types of financial institutions [1]: central banks, retail banks, 183
commercial banks, credit unions, savings and loan institutions, investment banks and companies, 184
brokerage firms, insurance companies, and mortgage companies. Central banks (e.g., the U.S. 185
Federal Reserve Bank) only interact directly with other financial institutions. The rest of these 186
financial institutions interact with individuals, companies, and each other in different ways. For 187
example, banks may act as financial intermediaries by accepting customer deposits or by 188
borrowing in the money markets. Banks then use those deposits and borrowed funds to make 189
loans or to purchase securities. Banking entities also make loans to businesses, individuals, 190
governments, and other entities. This document uses the term “banking entity” to refer to any 191
financial institution that conducts business with individuals, such as a retail bank, credit union, or 192
mortgage company. Figure 1 illustrates some monetary flows between banking entities, their 193
customers, and other entities in the financial system. 194
195
Figure 1 - Some typical interactions between banking entities, their customers, and other entities [2] 196
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
2
banks include individuals, merchants, service providers, governments, utilities, non-profit 199
organizations, other banking entities, and others (e.g., consumers, investors, and businesses). 200
Financial sector institutions also serve as financial intermediaries by facilitating payments to and 201
from their customers to the businesses and other entities with which they interact via check 202
payments and debit and credit transfers. Some banking entities provide other services to their 203
customers, such financial planning and notary services. 204
1.2 Multiple Financial Institutions 205
A customer can interact with more than one financial institution. For example, a person may use 206
a local bank for everyday transactions, a credit union to hold the home mortgage, a car financing 207
firm to finance a car, and one or more other banks for credit cards. However, moving funds 208
between these financial institutions is not always easy or transparent. For example, making a 209
payment to an auto loan through a credit transfer from the local bank requires several customer 210
actions, and making a mortgage payment from an advance on a credit card requires certain 211
authorizations. 212
Customers may be forced to accept most (or all) of a package of services offered by a financial 213
institution. Customers usually cannot “mix and match” services offered by different banking 214
entities easily. For example, it would be unusual to have a checking account with one bank, a 215
money market account with another, a savings account with another, and debit card with yet 216
another bank. Moving funds between these different accounts would likely require several steps 217
and authorizations, including fees. 218
1.3 Open Banking Defined 219
Open banking describes a new kind of financial ecosystem that gives third-party financial service 220
providers open access to consumer banking, transactions, and other financial data from banks 221
and non-bank financial institutions through the use of application programming interfaces 222
(APIs). It is governed by a set of security profiles, application interfaces, and guidelines for 223
customer experiences and operations. Ecosystem-enabled banking means that there are not 224
predefined direct relationships or “supply chains” of financial products and services. Rather, the 225
flow of debits and credits between these products and services are executed at the discretion of 226
the customer (see Figure 2). 227
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
3
228
The term “open banking” can be used as a noun that defines any conforming financial ecosystem 230
(e.g., “the XYZ bank conducts open banking”). “Open banking” can also be used as an adjective 231
(e.g., “open banking guidelines” or “open banking API”). OB can be thought of as “finance as a 232
service” (FaaS), a form of software as a service (SaaS). In Figure 2, the open banking cloud is a 233
collection of banking entities that are configured as a cloud and deliver micro and macro 234
financial services via SaaS using conforming APIs. Financial microservices include deposits, 235
withdrawals, payments, debits, credits, and more; macro services include loan origination and 236
payoff, mortgage origination, and the like. Within the open banking cloud in Figure 2, there are 237
clouds that represent one or more financial institutions that participate in the OB ecosystem (see 238
Figure 3). 239
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
4
240
OB is consistent with the goal of moving towards a “cashless economy” by using digital 242
payments. However, it requires banks to remove proprietary barriers and share information with 243
third parties. This opening and sharing of data forces banking entities to make proprietary data 244
available to any entity with the owner’s permission to access it. 245
In OB, banking entities interact with each other via APIs at the customer’s direction and can 246
offer better services on an a la carte basis. With a larger available set of services, customers can 247
personalize their finances with more suitable, balanced, and cost-effective products. For 248
example, a customer could choose one banking entity’s savings account service, another banking 249
entity’s checking account service, another’s credit card, another’s auto loan, and another’s 250
mortgage product, and funds could be moved seamlessly through all of these services. 251
Dashboard tools could help customers perform various transactions, aggregate information for 252
analysis and optimization, set activity alarms, and so on. 253
Aggregated accounts enable new insights and enhanced speed, convenience, and simplicity of 254
transactions. Aggregated accounts could belong to the balance sheets that clients select, or each 255
bank might only count its own accounts on its balance sheet. OB also makes it easier for smaller 256
financial product vendors to enter into the financial services industry. 257
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
5
2 Use Cases 258
Section 2 provides use cases to illustrate expected open banking experiences [3]. 259
Use Case 1, Recurring Payments: Members of a household juggle multiple recurring payments 260
for their mortgage, four credit cards, car insurance (insurance agency X), home insurance 261
(insurance agency Y), life insurance (insurance agency Z), healthcare (exchange Q), property 262
and income taxes, utilities, and much more. The household income (from three sources) appears 263
as direct deposits into two banks. One member of the household is responsible for managing the 264
finances. This member is finding it difficult to keep track of all of the sources of funds and has 265
occasionally incurred costly penalties for missed and late payments and overdrafts. OB would 266
allow the sources of income from different sources and all of the recurring expenses to be 267
displayed on one or more dashboards that provide statuses, alerts for payment, and seamless 268
access to funds from any source, including consolidated account overdraft protection. 269
Aggregating this information also allows for the optimization of payment scheduling (to reduce 270
interest charges) and the movement of money between revenue-generating accounts. Artificial 271
intelligence can provide additional insights to optimize cashflow, minimize lateness, and lead to 272
a higher credit rating for members of the household. 273
Use Case 2, Multiple Accounts: An individual has checking accounts at two different banks and 274
a credit card financed through a third bank. The individual wishes to make large purchases that 275
exceed the funds in any checking account or credit card limit. However, the OB allows the 276
individual to seamlessly combine these sources into an available balance that is sufficient to 277
make a large purchase, as well as covering shortfalls on any account as needed via direct 278
transfers between accounts. Once the consumer makes a purchase, the checking accounts and 279
credit card are debited accordingly. 280
Use Case 3, Linking Payments: A certain large banking entity no longer offers personal lines of 281
credit but supports OB. An individual customer wishes to continue everyday business with the 282
large bank but obtains a personal line of credit through a different banking entity that supports 283
OB. Through OB, more seamless payment of bills from a day-to-day operational perspective is 284
possible. For example, direct credit transfer can be used to pay the principal and interest on the 285
line, link to the savings and checking accounts for overdraft protection on the line of credit, and 286
transfer between accounts. These OB experiences all occur as if all accounts were held by one 287
large bank. 288
Use Case 4, Auto Purchase: An individual wishes to purchase a new car from a dealer. The 289
individual selects the particular model and options and negotiates with the dealer on the purchase 290
price. Using OB, the auto dealer conducts a rapid credit check on the buyer, sends financial 291
information to various loan agencies, and receives multiple loan offers and terms from various 292
finance sources. The buyer selects the preferred loan, and the purchase down payment is directly 293
paid to the dealer from a selected banking entity serving the customer. The payment plan is set 294
up with a loan agency, and overdraft protection is set up by linking regular load payment sources 295
(e.g., checking account) to other secondary financial sources (e.g., savings, investment accounts). 296
The complete set of financial transactions takes only a few minutes. 297
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
6
Use Case 5, Small Business Loan Origination: A small and medium enterprise (SME) owner 298
wishes to obtain a loan to purchase new equipment for their expanding business. The owner has 299
been unable to get a loan from traditional banks, including their regular bank. Part of the 300
difficulty in obtaining the loan has been the effort required to collect all of the financial 301
information needed for the loan application while simultaneously trying to run the business. 302
Using an OB application, however, the business owner can more easily gather the information 303
needed for the loan applications, shop more loan sources, and select from several options in 304
order to get the most favorable loan terms. 305
Use Case 6, New Banking Entities: Consider the collection of SME and large banking entities 306
participating in the activities of Use Cases 1-5. Many of these entities would not be able to 307
connect with nor have the opportunity to offer products and conduct business with the customers 308
in these Use Cases without the OB ecosystem. 309
Use Case 7, Wealth Management: Digital wealth management platforms are on the rise and 310
can benefit from the OB system to gain a clearer context of a client before recommending an 311
appropriate investment based on the client’s payment ability and risk tolerance. Companies that 312
can implement this use case in the U.K. include Plum (https://withplum.com/), Chip 313
(https://getchip.uk/), and Lenlord (https://www.lendlord.io/). 314
Use Case 8, Buy Now Pay Later (BNPL): A small retailer wants to implement a BNPL 315
campaign that allows users to receive their purchased items before payments are finished. A 316
typical step in traditional BNPL programs is determining a customer’s credit risk before 317
extending credit. This step is usually outsourced by small retailers. Using an OB framework, a 318
specialized company can smooth the interaction between retailer and customer and reduce the 319
burden on the retailer. OB-developed applications can aggregate more information about the 320
customer’s spending habits and use proprietary algorithms to help make a better-informed 321
decision about the creditworthiness of a user. Companies that can implement this use case 322
include Zilch (https://www.payzilch.com), Klarna (https://www.klarna.com), and Afterpay 323
(https://www.afterpay.com/en-US). 324
Use Case 9, Improving Employee Experience: A company wants to offer its employees 325
discount packages at retailers in their community. Typically, such a program would require proof 326
of employment to qualify for a discount, at which time an adjustment to the retailer’s point-of-327
sale system needs to be made. OB can streamline this process by connecting the employee’s 328
existing credit or debit card to their discount profile and unlocking eligible deals in their 329
community. Moreover, AI capabilities can further augment the OB-developed system. By 330
analyzing the employee’s banking transactional data, the discounts can be targeted to the 331
interests of each employee instead of a blanket discount voucher. Because there is no need to 332
modify the vendor’s system, it is also easier for a small retailer to participate in an employee 333
discount program. Companies that can implement this use case include Perkbox 334
(https://www.perkbox.com/uk). 335
Use Case 10, Debt Collection: A customer is behind on certain loan payments. Using open 336
banking, a debt collector can look into the accounts of the person and try to generate a payment 337
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
7
plan that the debtor can meet to pay off the remaining amount. Companies that can implement 338
this use case include Experian (https://www.experian.com/) and Flexys (http://flexys.com/). 339
Use Case 11, Carbon Tracking: An individual is interested in learning about the impact that 340
their spending has on the environment. An OB system connected to a carbon-tracking platform 341
can provide the user with carbon footprint insights based on their banking transactions, allowing 342
them to become more conscious about their environmental impact. The system can also offer 343
recommendations to engage in changing spending behaviors in a win-win ecosystem. Companies 344
that can implement this use case include Enfuce (https://enfuce.com/) and equensWorldline 345
(https://equensworldline.com). 346
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
8
3 Differences from Conventional e-Banking and Peer-To-Peer Financial 347
Platforms 348
Key differences between open banking and conventional e-banking and peer-to-peer (P2P)
349
financial platforms are pre
sented in Table 1. 350
Table 1 - Comparing OB, conventional e-banking, and P2P financial platforms [2] 351
Open Banking
Conventional e-
Banking
P2P Financial
Platforms
Privacy and security
aspects
Privacy and security
issues are of concern
among large
proportions of lenders
and consumers [4].
Many are
implementing strong
security and privacy
measures, including
biometric login
options involving
fingerprint, voiceprint,
and facial recognition
[8].
Cybercriminals have
been reported to use
compromised
identities from
massive data breaches
to get loans [10].
Adoption and use
Only a few
jurisdictions have
developed OB
regulations, and the
current regulatory
environment has been
a concern in most
economies [4].
In addition to well-
established e-banking
services offered by
existing banks, some
economies such as
Hong Kong SAR,
South Korea,
Malaysia, Singapore,
Taiwan, and the
Philippines have
issued bespoke digital
banking licenses to
operate online-only
banks [5].
The regulatory
environment is
complex and varies
significantly across
countries.
Potential effects on
mainstream banking
systems
There is the
opportunity to work
with FinTechs to
launch innovative
products and adopt
ways to enhance
customer experience
and loyalty. With
streamlined processes
and new products,
new customers can be
gained, and existing
There are lower
overhead costs than
brick-and-mortar
operations.
P2P loans typically
offer investors a
higher rate of return
(albeit riskier)
compared to bank
deposits. Such a
competition forces
banks to fund their
activities using more
costly non-deposit
funding sources [6].
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
9
Open Banking
Conventional e-
Banking
P2P Financial
Platforms
customers can be
retained. However,
banks may lose some
income from fees.
Potential benefits to
consumers
There is access to
additional products
that customers’
current banks cannot
offer, as well as
diversified access to
products [7].
E-banking offers
convenience (e.g.,
24/7 account access)
and control over
finances with the
ability to self-serve
[8].
High-risk borrowers
not served by
traditional banks
could get access to
loans. Consumers,
however, often pay
higher interest rates
than for loans from
the traditional banking
sector [9] or private
lenders.
Ordinary electronic banking (e-banking) is already well-established. None of the micro or macro 352
services provided by banks require a physical structure or proximity, and all can be conducted 353
online. Many banking entities serve their customers entirely through online services without the 354
need for physical branch offices. These e-banks provide capabilities for electronic deposits, the 355
withdrawal of funds, remote scanning of physical checks for deposit, electronic transfers, auto 356
deposits, auto debits, account analysis, transaction alerts, reminders, and more. Many 357
conventional banks also offer an electronic interface and other third-party e-banking solutions 358
that provide a “wrapper façade” for a mobile banking layer between the user and their bank. 359
However, these e-banking activities all occur within the closed system of banking entities 360
subscribed to by a customer and are predefined and not transparent. Further, proprietary 361
information kept by each banking entity curtails the optimization and customization of services 362
and the consolidation of information. 363
P2P financial platforms (e.g., Venmo, PayPal, Google Pay) offer digital wallets with money held 364
by the platform host and allow for transfer to and from linked debit cards, credit cards, or bank 365
accounts depending on the service. Yet beyond the electronic wallet feature, P2P financial 366
platforms offer few of the other services offered by traditional banks and, therefore, fall far short 367
of the capabilities of OB. Thus, e-banking services and P2P financial networks can benefit by 368
entering the OB ecosystem. 369
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
10
4 Survey of Open Banking Standards and Approaches Around the World 370
National approaches to open banking across the globe are frequently characterized broadly as 371
either regulatory or market-driven [11][12]. However, the adoption of open banking in many 372
countries might better be characterized as a hybrid approach with legal and regulatory mandates 373
driving certain aspects of open banking and market forces driving others. This section gives a 374
high-level survey of some national and regional approaches to open banking with a particular 375
focus on the role that privacy and cybersecurity considerations have played in the development 376
and implementation of these approaches. 377
4.1 European Union and United Kingdom 378
The E.U. and the U.K. have taken closely related and solidly regulatory approaches to open 379
banking, resulting in their reputations as open banking’s primary pioneers [11][13][14]. The 380
regulatory origins of open banking in the E.U. and the U.K. can be traced to the EU's Revised 381
Payment Services Directive (PSD2), which was adopted by the European Parliament, passed by 382
the Council of the European Union in 2015, and came into force under EU-member national laws 383
and regulations in early 2018 [15]. 384
With the goal of promoting competition and innovation in the payments market, PSD2 requires 385
Account Servicing Payment Service Providers (ASPSPs) – essentially, banks and other financial 386
institutions (FIs) at which customers hold payment accounts – to open their payment services to 387
regulated third-party payment service providers (TPPs) with customers’ consent. These TPPs, 388
which include FinTechs and other new players in the payments market that could also be FIs 389
themselves, include payment initiation service providers (PISPs) and account information service 390
providers (AISPs). PISPs provide services to initiate payments at the request of a customer using 391
the customer’s payment account held at an FI, whereas AISPs offer online services that provide 392
consolidated information on a customer’s payment accounts held at one or more FIs [15] (Article 393
4(15)–(19)). 394
More precisely, Articles 66 and 67 of PSD2 require E.U. Member States to establish and 395
maintain the rights of customers to make use of services from PISPs and AISPs, respectively, 396
and require FIs to enable those TPP services through the use of secure communications. In short, 397
PSD2 made participation in open banking compulsory for FIs in the EU, which included the U.K. 398
during the pre-Brexit time period of PSD2’s enactment and coming into force, at least with 399
respect to regulated TPPs. The U.K.’s implementation of PSD2 as the Payment Services 400
Regulations 2017 (PSRs 2017) remains in effect, although certain post-Brexit amendments to the 401
regulations are expected [16][17]. 402
4.1.1 Development of Open Banking Standards and API Specifications 403
The U.K. has seen a somewhat more rapid implementation of OB APIs than the EU. In 2017, 404
based on an investigation report published in August 2016, the U.K. Competition and Markets 405
Authority (CMA) ordered the nine largest U.K. banks at the time – HSBC, Barclays, Santander, 406
Bank of Ireland, RBS, Allied Irish Bank, Danske Bank, Nationwide, and Lloyds, collectively 407
known as the “CMA9” – to implement common open banking standards that would allow 408
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
11
customers to share their banking data with licensed TPPs through the use of standardized APIs 409
[18]. Perhaps the most notable distinguishing feature of this order is that it created a regulatorily 410
mandated set of open banking standards, including API and security-profile specifications. 411
Specifically, the CMA order directed the CMA9 to establish the Open Banking Implementation 412
Entity (OBIE, also known under the trading name Open Banking Limited) – a private, non-profit 413
entity with a steering group comprising representatives of the CMA9 banks, FinTechs, payment 414
service providers, challenger banks, consumers, small businesses, other stakeholders, and 415
observers from U.K. government regulators [19]. The OBIE was tasked with agreeing upon, 416
implementing, and maintaining freely available, open, read-only, and read/write data access 417
standards, which were to include an open API standard, data format standards, security 418
standards, governance arrangements, and customer redress mechanisms for the read/write 419
standard [18]. 420
The resulting Open Banking Standard was launched in January 2018, and the expanded Version 421
3 was published in September 2018. Designed as a “PSD2-compliant solution ([20]),” Version 3 422
of the U.K. Open Banking Standard includes four core components: (1) API specifications 423
(including read/write API specifications, open data API specification, open banking directory 424
specifications, dynamic client registration specifications, and management information (MI) 425
reporting specifications), (2) security profiles based on the Open ID Foundation’s Financial-426
grade API (FAPI) and Client Initiated Backchannel Authentication (CIBA) profiles, (3) customer 427
experience guidelines, and (4) operational guidelines to support ASPSPs in requesting an 428
exemption from PSD2 requirements to provide a so-called “contingency mechanism” in addition 429
to Open Banking Standard-compliant APIs, as discussed further below. Although the CMA 430
mandate requires only the CMA9 banks to comply with the Open Banking Standard, it has likely 431
resulted in a U.K. open banking environment harmonized around clear, regulation-driven 432
specifications. Indeed, the OBIE’s monthly highlights report 91 regulated ASPSPs (presumably 433
including the CMA9) and 234 regulated TPPs, with 114 regulated entities that “have at least one 434
proposition live with customers” in the U.K. open banking ecosystem [21]. 435
In contrast to the U.K.’s approach of establishing and developing concrete open banking 436
standards through regulatory mandate, the E.U. has essentially left the task of standardization to 437
the market [13][14]. Although PSD2 establishes a legal and regulatory framework requiring FIs 438
and other ASPSPs to establish interoperable communications with registered TPPs, it does not 439
provide for technical open-banking API specifications akin to the U.K.’s Open Banking 440
Standard. Article 98 of PSD2 (“Regulatory technical standards on authentication and 441
communication”) directed the European Banking Authority (EBA) to draft regulatory technical 442
standards (RTS) specifying, in part, “the requirements for common and secure open standards of 443
communication for the purpose of identification, authentication, notification, and information, as 444
well as for the implementation of security measures” between ASPSPs, TPPs, payers, and 445
payees. However, the resulting final draft RTS describes requirements for such “common and 446
secure communication” at a high level and does not mention, mandate, or provide technical 447
specifications for APIs as a prescribed or suggested communication interface. The EBA’s 448
feedback on responses from public consultation accompanying the final draft RTS note that 449
“[t]he RTS do not mandate APIs although the EBA appreciates that the industry may agree that 450
they are suitable” [22]. 451
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
12
Industry consensus in the E.U. appears to have settled broadly on the use of open-banking APIs 452
[23] despite the silence of PSD2 and the accompanying RTS on APIs. However, the lack of 453
regulatory clarity and specific mandated technical standards has arguably impeded the 454
development of detailed API specifications and harmonization around such specifications across 455
the EU. Some of the more notable E.U. open banking API standards include the Berlin Group’s 456
NextGenPSD2 standard, STET’s PSD2 API, Swiss Corporate API, and PolishAPI [24]. 457
Although approximately 78 % of E.U. banks relied on the NextGenPSD2 standard as early as 458
late 2018, the EU’s environment has still been comparatively more fragmented than that of the 459
U.K. in the early years of open banking [25][26][24]. Nonetheless, the regulatory foundation 460
provided by PSD2 has resulted in the EU’s standing as a pioneer and ongoing leader in open 461
banking. MasterCard’s Open Banking Readiness Index 2021 has recently ranked Sweden, 462
Denmark, and Norway ahead of the U.K. for open banking readiness (owing primarily to those 463
countries’ established schemes for digital ID authentication and know-your-customer (KYC) 464
services) [24][13]. Moreover, the Euro Retail Payments Board (ERPB) working group is set to 465
begin work on a SEPA (single euro payments area) API Access Scheme to further the integration 466
of the European open banking market and address business requirements, governance 467
arrangements, and a standardized API interface [23]. 468
4.1.2 From Open Banking to “Open Finance” 469
PSD2 currently provides a legal framework that regulates only the sharing of payment data by 470
ASPSPs with TPPs. For example, the sharing of data related to loans, mortgages, investments, or 471
insurance is not within the purview of the PSD2 regulations. Although the U.K. Open Banking 472
Standard provides a regulated data-sharing framework somewhat broader than that of PSD2 – in 473
particular by establishing procedures to allow data access to a broader range of trusted third-474
party entities than the licensed payment service providers covered by PSD2 – the regulatory 475
framework for open banking across the European Economic Area and the U.K. remains largely 476
focused on payment services. As open banking has become established in Europe, there has been 477
a push toward a broader conception of “open finance,” which would create a similar framework 478
for the sharing of financial data beyond payment account data. 479
With the CMA order’s implementation phase set to conclude in 2021, the banking and financial 480
services trade association, U.K. Finance, has proposed that the OBIE be transitioned to a new 481
industry-run services company, noting that this future entity should work to extend open banking 482
into open finance given that “[c]ustomers do not see the relevance of the PSD2 boundary 483
[between payment and other financial services] to their financial lives” [27][28]. Similarly, the 484
U.K.’s Financial Conduct Authority (FCA) – a financial regulatory body independent of the U.K. 485
government – has recently published feedback to its 2019 Call for Input on open finance, noting 486
a “degree of consensus” among responding stakeholders that, similar to open banking, a broader 487
open finance ecosystem would require basic elements such as a legislative and regulatory 488
framework, common standards, and an implementation entity [29]. Calls for a transition to open 489
finance have also occurred in the E.U. For example, in October 2020, the Berlin Group 490
announced that it would begin work on an “openFinance API Framework” [30]. 491
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
13
4.1.3 The Impact of Privacy and Cybersecurity Considerations 492
Although the E.U.’s introduction of PSD2 and the CMA’s open banking efforts in the U.K. were 493
initially motivated by a desire to increase competition and innovation in the banking and 494
payment sectors, the E.U. and U.K. frameworks have expanded their focus to considerations of 495
customer experience, customer data rights and control, privacy, and security. A 2018 survey by 496
PricewaterhouseCoopers found that “the risks of data management, fraud[,] and loss of privacy” 497
were major payment customer concerns, with 48 % of retail customers and 54 % of SMBs 498
surveyed expressing such concerns with respect to data sharing in open banking [14]. 499
As one aspect of addressing payment security, PSD2 and its accompanying RTS require payment 500
service providers to apply “strong customer authentication” (SCA) – essentially amounting to 501
multi-factor authentication – in scenarios where a payer “accesses its payment account online,” 502
“initiates an electronic payment transaction,” or “carries out any action through a remote channel 503
which may imply a risk of payment fraud or other abuses” [15] (Article 97(1)). The 3D Secure 504
2.0 (3DS2) protocol has emerged as the primary method for authenticating payments in 505
compliance with PSD’s SCA requirements for card-not-present transactions, though unified 506
adoption of the protocol and national enforcement of the SCA requirement have experienced 507
delays relative to the initial implementation timeline [31]. Additionally, payments consultancy 508
CMSPI reported testing in September 2020 showing that 35 % of 3DS2 transactions were 509
declined, abandoned due to customer frustration, or failed due to technical errors. At the time, 510
CMSPI estimated that such transaction failures, if not reduced, could result in losses to European 511
merchants exceeding €100 billion based on 2019 sales volumes [32]. 512
Much of the technological discussion of privacy and security in OB – not only with respect to the 513
E.U. and U.K. ecosystems but globally – has focused on the superior security of open APIs 514
relative to the practice of screen scraping, in which customers provide their payment-account 515
access credentials (such as username and password) directly to third-party providers who use 516
those credentials to access and gather customers’ data from an FI (or other ASPSP). Screen 517
scraping raises security and privacy concerns for both customers – not least because the practice 518
frequently grants a third-party access to considerably more of a customer’s data than is needed 519
for the particular service that the customer is requesting – and FIs, who can face in the event of 520
data breaches or data misuse resulting from third-party screen scraping, even where scraping is 521
applied without the FI’s knowledge [11][14]. 522
Notably, the RTS on Strong Customer Authentication and Common Secure Communication 523
under PSD2 limits but does not impose an outright ban on screen scraping by TPPs. Although 524
the RTS does effectively prohibit screen scraping as it was most frequently practiced prior to 525
PSD2, some form of permissible screen scraping survives in the form of contingency 526
mechanisms (alluded to in the description of the U.K. Open Banking Standard), also referred to 527
as “fallback mechanisms.” Specifically, as a compromise between the security risks of screen 528
scraping and the potential competitive disadvantage to TPPs if an ASPSP’s “dedicated interface” 529
(i.e., API) fails or is unavailable, Article 33 of the RTS requires ASPSPs to grant TPPs access to 530
their usual customer-facing authentication and communications interfaces as part of a 531
contingency mechanism in the event of such failure or unavailability, essentially allowing TPPs 532
to practice screen scraping as a contingency mechanism. However, the RTS requires TPPs 533
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
14
utilizing such contingency measures to identify themselves to the relevant ASPSP prior to 534
scraping, which theoretically mitigates some of the security risk for the ASPSP [33]. Moreover, 535
the PSD2 RTS provides conditions under which an ASPSP could qualify for an exemption from 536
the requirement to provide a fallback mechanism (see previous discussion of the U.K. Open 537
Banking Standard) [34][35][36]. 538
Even assuming the use of PSD2-compliant open APIs, significant privacy and cybersecurity 539
concerns and attendant liability concerns necessarily remain in an open banking ecosystem 540
premised on the sharing of individual consumers’ data. In this direction, the E.U.’s General Data 541
Protection Regulation (GDPR) ([37]) plays a crucial role alongside and beyond PSD2 in the legal 542
and regulatory framework of the European open banking ecosystem
1
. 543
GDPR Article 25, “Data protection by design and by default,” and Article 32, “Security of 544
processing,” are of particular interest with respect to the technological aspects of privacy 545
considerations for open banking. Article 25 may be viewed as creating a legal mandate for “data 546
controllers” (i.e., entities that determine the purpose and means of processing individuals’ 547
personal data) to adopt both technical and organizational measures that implement the principles 548
of “privacy by design” [39]. In the context of the PSD2 open banking framework, GDPR “data 549
controllers” include both ASPSPs (such as FIs) and TPPs. In addition to imposing privacy by 550
design, Article 25 requires organizations to only process personal data that are necessary for the 551
specific purpose to be accomplished by the processing. This requirement makes explicit the 552
application of GDPR’s “data minimization” and “purpose limitation” principles to limiting the 553
storage of customers’ data by ASPSPs and TPPs (as well as data controllers more generally) 554
[39]. Article 32 also requires organizations to implement technical and organizational measures 555
“to ensure a level of security appropriate to the risk” presented by data processing, in particular 556
from destruction, loss, alteration, unauthorized access, or disclosure of personal data that are 557
transmitted, stored, or otherwise processed [37] (Article 32). 558
Notably, both Article 25 and Article 32 require organizations to “tak[e] into account the state of 559
the art” in determining appropriate technical and organizational measures. The European Data 560
Protection Board’s Guidelines on the adoption and implementation of Article 25 further clarify 561
that the reference to the “state of the art” obligates organizations to remain current with 562
technological developments in privacy and security, noting that data controllers must “have 563
knowledge of and stay up to date on technological advances; how technology can present data 564
protection risks or opportunities to the processing operation; and how to implement and update 565
the measures and safeguards that secure effective implementation of the principles and rights of 566
data subjects taking into account the evolving technological landscape” [40]. 567
1
GDPR is retained in U.K. law as the “UK GDPR,” although in light of Brexit, the U.K. has independent authority to keep the
regulatory framework under review. As of this writing, the post-Brexit amendments to U.K. GDPR, as reflected in the relevant
“Keeling Schedule,” do not include any changes to the text of Article 25 of the U.K. GDPR, which is identical to the text of
Article 25 of the E.U. GDPR [38].
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
15
The GDPR data minimization and purpose limitation principles reflected in Articles 25 and 32 568
and the attendant liability risks for payment service providers could create an incentive for the 569
adoption of emerging technologies that obviate the data sharing upon which open banking is 570
currently premised. For example, certain verifications and aggregate computations commonly 571
performed by transferring customer data from ASPSPs to TPPs through the use of open APIs 572
could instead be performed using cryptographic techniques that do not require a TPP to access, 573
store, or process customer data in unencrypted form at all (e.g., secure multi-party computation 574
[SMPC], zero-knowledge proofs [ZK], private set intersections [PSI], homomorphic encryption 575
[HE], or hardware-based solutions that rely on trusted execution environments). By reducing the 576
amount of data shared in the open banking ecosystem in the first instance, the adoption of such 577
technologies could ease regulatory compliance burdens and reduce liability risks for ASPSPs and 578
TPPs. Moreover, this reduction in data sharing could provide an additional layer of protection for 579
consumer data, reducing the need to rely on potentially inefficient post hoc regulatory 580
enforcement remedies for consumer harm in the event of data misuse or improper exposure [41]. 581
Particularly in light of the Article 25 and Article 32 requirements for organizations to consider 582
the state of the art when determining and maintaining appropriate technological measures and 583
safeguards, such cryptographic technologies could find their way into standards as their adoption 584
increases both within the banking and financial services sectors and without. 585
4.2 Australia 586
In 2017, Australia introduced the Consumer Data Right (CDR) – an opt-in framework that grants 587
consumers the right to direct the sharing of their data held at regulated data holder institutions 588
(such as banks) with “accredited data recipients,” or third-party service providers, through APIs 589
[42]. The CDR is implemented by the Competition and Consumer (Consumer Data Right) Rules 590
2020 (CCCDR Rules), which are regulations under the legislative provisions of the Competition 591
and Consumer Act 2010 that govern “product data requests” related to data holder institutions’ 592
products, a consumer’s request for their own data, and requests for consumer data made on the 593
consumer’s behalf by an accredited third-party service provider [43]. Notably, similar to the 594
U.K.’s adoption of the Open Banking Standard discussed above, the CDR is accompanied by the 595
Consumer Data Standards – mandated by the CCCDR Rules and created by the Data Standards 596
Body within the Australian Treasury – which include technical and consumer experience 597
standards and detailed API specifications [44]. 598
The CDR became available for sharing consumer data in July 2020 when the four major 599
Australian banks (i.e., Australia and New Zealand Banking Group Limited, Commonwealth 600
Bank of Australia, National Australia Bank Limited, and Westpac Banking Corporation) were 601
required to begin sharing consumer data for their primary brands in compliance with the CCCDR 602
Rules and the Consumer Data Standards. An additional requirement to begin sharing consumer 603
data for their non-primary brands was scheduled for July 2021. Other deposit-taking institutions 604
have been required to begin sharing consumer data as of July 2021 for certain “Phase 1 products” 605
– including basic savings, checking, debit card, and credit card accounts – with a current 606
requirement to expand sharing to all products listed in the CCCDR Rules by February 2022 [43] 607
[45]. The listed banking sector products for which data sharing is governed by the CCCDR Rules 608
go beyond the basic payment services covered by PSD2 in the E.U. and the U.K. and include 609
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
16
certain “open finance” data, such as data for home and personal loan, mortgage, investment loan, 610
line of credit, and retirement savings account products [43]. 611
Participation in the CDR framework by FinTechs and other third-party service providers as 612
accredited data recipients appears to be progressing relatively slowly. As of this writing, the 613
Australian Government’s online list of CDR providers includes only six entities as “active” data 614
recipients – of which two are Intuit companies (Intuit Australia Pty Limited and Intuit Inc.) and 615
two are themselves banks (Commonwealth Bank of Australia and Regional Australia Bank Ltd.) 616
– with an additional seven currently accredited data recipients [46]. Given that the CDR does not 617
prohibit screen scraping, this relatively slow adoption could be at least partially explained by 618
third-party service providers’ reluctance to submit themselves to the considerably more rigorous 619
requirements of the CDR framework [47][48]. 620
Despite its comparatively later rollout, Australia’s CDR framework is viewed as a particularly 621
forward-looking approach to open banking. This view is due to the primary distinguishing 622
feature that sets the CDR apart from other countries’ approaches: although it is rightly seen as 623
providing the legal and regulatory foundation for open banking in Australia, the CDR is not 624
limited to the banking and financial services industry at all. Rather, the CDR provides a 625
framework for sharing consumer data across a multitude of economic sectors. The accompanying 626
standards reflect this broad vision with a particular emphasis on establishing consistent 627
representations of consumers across industries and a design approach focused on consumers 628
consenting to data sharing [48]. Banking is merely the first sector to which the CDR has been 629
applied. Next, it will be introduced to the energy sector, and subsequent application to the 630
telecommunications sector has been proposed [49]. 631
4.3 India 632
India’s open banking ecosystem has been facilitated by the government-driven development of 633
the “India Stack,” a collection of APIs that combine to form a digital infrastructure comprising 634
four technology layers [50]. 635
(1) The “presenceless layer,” controlled by the Unique Identification Authority of India 636
(UIDAI), relies on the Aadhaar authentication system introduced by the Indian 637
government in 2010, which is based on a 12-digit unique identity number. The Aadhaar 638
Auth API enables digital identity verification and authentication using a consumer’s 12-639
digit identity number to access stored biometric or demographic authentication data for 640
comparison [51]. 641
(2) The “paperless layer,” controlled by India’s Ministry of Electronics and Information 642
Technology,” facilitates the electronic storage and retrieval of documents linked to a 643
consumer’s digital identity and incorporates Aadhaar eKYC, an electronic know-your-644
customer service based on the aforementioned Aadhaar authentication system [52]; 645
eSign, an API-based digital document signature service facilitated by third-party service 646
providers licensed under India’s Information Technology Act ([53]); and DigiLocker, a 647
digital locker service that can be linked with a consumer’s Aadhaar identity number or 648
mobile number [54]. 649
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
17
(3) The “cashless layer” is controlled by the National Payments Corporation of India 650
(NPCI), a non-profit organization overseen by the Reserve Bank of India (RBI). A 651
primary component of the cashless layer is an electronic payments network with 652
interoperability between banks and third-party service providers afforded by the Unified 653
Payments Interface (UPI), an open API standard with a standardized payments markup 654
language [55]. 655
(4) Finally, the “consent layer,” controlled by the RBI, manages data sharing subject to a 656
consumer’s consent. A key component of the consent layer is the Data Empowerment and 657
Protection Architecture (DEPA), a public-private effort to provide a technical and legal 658
framework for consumers to control and consent to sharing their data. Introduced as a 659
draft policy by the Indian Government public policy think tank NITI Aayog, the DEPA 660
launched in the financial sector in 2020, overseen by the Ministry of Finance, RBI, and 661
various government regulators. Similar to Australia’s CDR, the DEPA framework for 662
data sharing and consent is intended to apply beyond financial services to other sectors, 663
including health services and telecommunications [56]. 664
The 2020 introduction of DEPA reflects a recent focus on privacy in Indian open banking and 665
the digital data ecosystem of the India Stack more generally. This heightened focus was perhaps 666
motivated by early complications for the India Stack posed by privacy issues centered on the 667
Aadhaar authentication system underlying the India Stack [55]. In particular, a series of court 668
petitions challenging the mandatory use of the Aadhaar identification number as a violation of 669
individual privacy rights led to a 2018 Indian Supreme Court decision that, while upholding 670
mandatory use of Aadhaar for certain government purposes, curtailed the mandatory use of 671
Aadhaar authentication by private entities on constitutional grounds. This decision created 672
significant uncertainty around the legality of Aadhaar-based eKYC by banks, with some initially 673
believing that the Supreme Court ruling had effectively banned any use of Aadhar by private 674
companies for eKYC [57][58]. Eventually, however, the RBI allowed private banks to access the 675
Aadhaar service for KYC purposes but with an additional requirement of customer consent to 676
such use [59]. In response to calls for India to establish a clear legal and regulatory framework 677
for privacy protection, the Personal Data Protection Bill was introduced in the Indian Parliament 678
by the Ministry of Electronics and Information Technology in December 2019 [60]. 679
Within this privacy- and consent-focused environment, the DEPA framework of the India 680
Stack’s “consent layer” can be distinguished from other open banking standards by the central 681
role played by third-party intermediaries known as “consent managers” (CMs). In the basic 682
DEPA model, communications by all parties related to sharing a consumer’s data held at a data 683
controller (such as a bank) with a third-party service provider (such as a FinTech) pass through 684
the CM as an intermediary. The consumer communicates their consent to the CM, and a data 685
request from the third-party service provider is sent to the CM, who in turn relays the request to 686
the data controller, and – subject to the consumer’s consent – the consumer’s data responsive to 687
the request is sent from the data controller to the CM to the third-party service provider using an 688
end-to-end encrypted data flow [56]. The August 2020 version of NITI Aayog’s draft policy for 689
DEPA characterizes this reliance on CMs as a point of superiority to the U.K. Open Banking 690
Standard, at least in the Indian open banking ecosystem, noting that the U.K.’s lack of 691
“unbundling of the institution collecting data and the institution collecting consent … may not 692
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
18
work to address India’s scale and diversity.” The draft policy asserts that “[t]o reach [its] full 693
population, [India] will need multiple institutions specialized in consent management innovating 694
to provide multiple modes of obtaining informed consent (for example various form factors – 695
audio, visual or video, or assisted with an agent).” However, it does not appear to provide a 696
substantial explanation for why dedicated CM intermediaries, as separate parties in consent and 697
data flows, are necessary or provide a superior model in the Indian ecosystem or in open banking 698
more generally [61]. 699
4.4 United States 700
Thus far, the approach to open banking in the United States has been almost entirely market 701
driven. Although the U.S. has been a leading technological pioneer in many of the novel services 702
that open banking provides – with account-aggregation FinTechs such as Yodlee, Finicity, and 703
CashEdge (all of which have since been acquired by other entities) founded as early as 1999 – it 704
has lagged behind other countries in developing a full-fledged open banking ecosystem. 705
In contrast to the heavily regulation-driven approaches of nations like the U.K., E.U. member 706
states, and Australia and the hybrid approaches that incorporate public-private partnerships like 707
that of India, the most significant efforts toward API-based open banking in the U.S. have come 708
from the financial services industry itself, with participation from both FIs and FinTechs 709
[11][62]. The Clearing House (TCH) – the U.S.’s oldest banking association owned by 24 of the 710
largest U.S. commercial banks – has created a “model data access agreement” to streamline the 711
negotiation of contractual data access and data sharing agreements between FIs and FinTechs 712
[63]. 713
From the technology side, the leading standards initiative is the Financial Data Exchange (FDX) 714
consortium – a non-profit independent subsidiary of the Financial Services Information Sharing 715
and Analysis Center (FS-ISAC) that seeks to “unify” the financial industry around a common, 716
interoperable, and royalty-free standard for the secure access of user permissioned financial 717
data,” known as the FDX API [64]. In 2019, the Open Financial Exchange (OFX) consortium, 718
the other leading industry API standardization effort at the time, joined FDX as an independent 719
working group [65]. Although the FDX API is based on JSON data serialization [66] and the 720
still-available OFX API employs XML serialization [67], FDX has stated that existing versions 721
of the OFX standard will continue to be supported and that “users of OFX will have assistance to 722
migrate to the FDX API standard” [64]. FDX’s membership includes numerous FIs, FinTechs, 723
card networks, and technology companies. Although the FDX API specification is not openly 724
available, non-members can access the specification by registering with FDX and accepting an 725
FDX Intellectual Property Agreement [66]. In addition to FDX, the National Automated Clearing 726
House Association (NACHA) has established the Afinis Interoperability Standards group to 727
advance API and other financial-service standards. Although smaller than FDX, Afinis’s 728
membership overlaps with that of FDX and includes all 12 regional banks of the U.S. Federal 729
Reserve [68]. 730
Preliminary efforts by the Department of the Treasury and the Consumer Financial Protection 731
Bureau (CFPB) have provided some measure of guidance and direction for the financial services 732
industry’s efforts to develop a U.S. open banking ecosystem. In July 2018, the Treasury issued a 733
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
19
report – “A Financial System That Creates Economic Opportunities: Nonbank Financials, 734
FinTech, and Innovation” – that specifically noted the significant security risks and liability 735
burdens of screen scraping and the potential for APIs to provide a more secure method of 736
accessing consumer financial data. Although the Treasury identified “a need to remove legal and 737
regulatory uncertainties currently holding back financial services companies and data 738
aggregators from establishing data sharing agreements that effectively move firms away from 739
screen-scraping,” it recommended that the best approach to such a transition for the U.S. market 740
would involve “a solution developed by the private sector, with appropriate involvement of 741
federal and state financial regulators” [69]. Despite the Treasury report’s lack of detailed 742
guidance, it is the only government articulation of “consumer protection principals” currently 743
cited by FDX as part of its online FAQ in response to the question of “[w]hat federal or state 744
regulations impact the FDX API standard” [64]. 745
Beyond the Treasury’s 2018 report, the CFPB has made some efforts to address open banking 746
and related developments as part of its regulatory mandate to implement Section 1033 of the 747
Dodd–Frank Wall Street Reform and Consumer Protection Act, which requires FIs to make 748
consumers’ transaction and account information available “in an electronic form usable by 749
consumers” and is arguably the provision of U.S. legislation most salient to facilitating open 750
banking [65]. In October 2017, the CFPB issued the “Consumer Protection Principles: 751
Consumer-authorized financial data sharing and aggregation” report, which articulated a set of 752
non-binding principles that were explicitly not intended to interpret or provide guidance on 753
existing laws and regulations. These principles addressed aspects of financial data sharing 754
including transparency; consumer access, control, and informed consent; security; dispute 755
resolution for unauthorized access; and accountability mechanisms for risks, harms, and costs 756
[70]. Although the CFPB Principles were not binding, the TCH Model Data Access Agreement 757
was designed to align with the Principles [63]. In October 2020, the CFPB issued an Advance 758
Notice of Proposed Rulemaking (ANPR) for Section 1033. The questions asked in the ANPR 759
and the public comments addressed issues relevant to open banking, including calls in the public 760
comments for CFPB implementation of strong privacy and security protections and for data-761
sharing standardization through open APIs. However, in view of the narrow scope of Section 762
1033, the CFPB’s ability to establish an open banking ecosystem through regulatory authority 763
remains unclear [65]. 764
The current lack of specific guidance or standards for the U.S. has led to a degree of uncertainty 765
in U.S. efforts to develop open banking, particularly around issues of privacy and security. For 766
example, FIs have significant liability concerns about sharing high-risk data, such as account 767
numbers or other personally identifiable information, as well as competitive concerns over 768
sharing proprietary information about FI products and services, whereas account aggregators 769
typically argue in favor of consumers’ ability to decide whether or not such data are shared [12]. 770
Moreover, in the absence of comprehensive adoption or mandated use of common API standards 771
for the exchange of financial data, screen scraping remains prevalent in the U.S. digital financial 772
services market [12][65]. This continued practice creates a heightened security risk for the 773
payment ecosystem, particularly in an environment where – according to research conducted by 774
TCH in 2019 – 80 % of consumers were unaware that they were not actually logging into their 775
FI’s website but rather providing login credentials to a TPP for the purpose of scraping [12]. 776
Although there is a general appreciation within the U.S. financial services industry of the 777
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
20
benefits – even the necessity – of adopting an open banking model, the lack of clear consensus 778
regarding how to implement such a model (whether mandated by laws and regulations or reached 779
independently by the industry itself) has arguably been a significant obstacle to the realization of 780
a U.S. open banking ecosystem. 781
4.5 Other Countries 782
Various countries have begun significant work towards OB. A brief summary of OB initiatives 783
around the world is given in Table 2. 784
Table 2 - Summary of OB initiatives around the world 785
Region
OB Initiatives
Africa
• NA
Asia
• 2014, Singapore, Smart Nation Singapore
• 2016, India, Unified Payments Interface
• 2016, South Korea, KFTC Developer Platform
• 2016, Thailand, BOT Regulatory Sandbox
• 2017, Japan, Banking Act
• 2019, Hong Kong SAR, Open API Framework
• 2020, India, Data Empowerment and Protection Architecture
• 2020, Bahrain, Open Banking Framework
Australia
• 2017, Australia, Consumer Data Right
• 2018, Australia, Data Sharing Compliance
• 2018, New Zealand, Payments NZ
• 2020, Australia, New Payments Platform
Europe
• 2018, U.K., Open Banking Implementation Entity
• 2018, E.U., Payment Services Directive
• 2020, Turkey, Payment Law
• 2020, Russia, Recommendatory Standards for Open Banking
North
America
• 2018, Mexico, Fintech Law
• 2018, Canada, Consumer Directed Finance
• 2019, U.S., CFPB principles UST report
South
America
• 2019, Brazil, Open Banking Framework
• 2020, Chile, Financial Portability Act
A brief discussion of some of these initiatives is provided below. OB efforts in the U.S. are 786
discussed in Section 4.5. 787
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
21
Mexico 788
Led by “The Fintech Law” in 2018, the implementation of OB in Mexico serves as inspiration 789
for other countries in Latin America. The law applies to almost all types of financial entities and 790
both transactional and product data, but it does not cover payment operations. 791
Brazil 792
The Central Bank of Brazil has been following a phased approach in implementing the “open 793
banking model” since it was published in 2019. It will be mandatory for large financial and 794
banking institutions with significant international activity and optional for others. The 795
implementation of the first phase occurred in early 2021 when the fundamental requirements for 796
the implementation of the law were disclosed. Phase 2, in which consumers will have an option 797
to share their data with the institutions they wish, is set to be implemented in July 2021. 798
Japan 799
Despite being among the first countries in Asia to establish its own OB framework in 2015, the 800
measures to adopt it have been versatile and focus mostly on partnerships between banks without 801
building API portals. For example, in 2017, three megabanks – Mizuho, Sumitomo Mitsui, and 802
MUFG – agreed on establishing a universal QR payment system. Another milestone was 803
recorded in 2018 when a QR code payment system called “Yoka Pay” was established as a 804
collaborative effort between Resona Banks, Fukuoka, and Yokohama. 805
Singapore 806
The Monetary Authority of Singapore has introduced API Exchange (APIX), which provides a 807
guidance and collaboration platform to encourage banks and TPPs to integrate and test solutions 808
with each other via a cloud-based architecture. 809
Hong Kong SAR 810
In 2017, Hong Kong introduced the Open API Framework as part of a wider plan to move into 811
the era of “smart banking,” and it was officially published in 2018. By mid-2020, more than half 812
of the incumbent banks had either open APIs or other OB innovations. 813
Russia 814
While still in the early stages, the Central Bank of Russia approved the first recommendatory 815
standards for OB in 2020, which included API standards for account information, payment 816
initiation, and information security standards. Since then, the Russian FinTech Association has 817
been carrying out pilot projects to experiment with the standards in real settings with local banks 818
and fintech. 819
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
22
Other notable initiatives 820
New OB initiatives are continuously developing. Recent OB regulations include the “financial 821
Portability Act” in Chile (2020), the “Payment Law” in Turkey (2020), and the Bahrain Open 822
Banking Framework (2020). 823
Other countries are letting industry lead the way. For example, Canada started government-led 824
consultations in 2019 to examine how to build regulatory oversight for the future, but the 825
majority of the initiatives that have been taken are industry-led. A similar story can be found in 826
Nigeria where a group of bankers and fintech experts came together in 2017 for the OB-Nigeria 827
initiative to drive the adoption of common API standards for the country. The OB-Nigeria API is 828
currently under development. 829
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
23
5 Positive Outcomes and Risks 830
Since some countries have deployed their own form of OB, the approaches can be compared and 831
the overall impacts summarized. This section focuses on the latter and provides some possible 832
advantages and risks to implementing, adopting, fostering, and even mandating OB. 833
Preventing fraud. Having an open platform should stimulate the means of securing financial 834
systems, such as by enabling better methods for detecting and preventing fraud. At a much larger 835
scale, OB could serve as a foundation upon which measures of risk and stability can be built, 836
thereby preventing or predicting potential weaknesses before they occur. 837
Risk of data leakage. Mandating, or at least fostering, adoption of OB could lead to unintended 838
consequences. While one of the main goals of OB is to offer proper security guidelines, designs, 839
policies, and APIs, these are ultimately implemented by the financial organizations. 840
Organizations that are not prepared for such integration but try to hurriedly implement OB could 841
create improperly secured endpoints that result in data leakage. 842
Improved consumer experience. By enabling OB, banking customers could have the capability 843
to choose financial services across multiple financial institutions. This would attract customers to 844
banks for specific account benefits rather than forcing them to subscribe to a large package deal. 845
Furthermore, frontend software written by third parties can now flourish due to the existence of a 846
common set of APIs and data standards. 847
Augmenting existing works. Within the U.S., there are several banking and finance APIs already 848
in existence that serve different purposes and operate at different levels of the financial sector. 849
An open framework, such as OB, would serve to augment and make existing frameworks more 850
interoperable with each other and with future frameworks. 851
Improved sharing for marketing and insights. An open standard to both the interfaces and the 852
standards for banking should enable much easier data sharing, shaping, and transformation. 853
When combined with appropriate privacy and security policies, such sharing could be used by 854
data aggregation without the overhead of building custom adapters for data import for each of 855
their sources. This could reduce the buy-in needed to perform better marketing analytics and help 856
galvanize academic, industry, or regulatory researchers with a better understanding of financial 857
infrastructure. 858
Homogeneous systems, market competition, and walled garden versus open platforms. 859
Security by obscurity is rarely acceptable, and much has been said about formal approaches to 860
utilizing heterogenous systems to achieve better security. Similarly, there has long been debate 861
about having a walled garden approach versus an open approach to technology. While market 862
competition of services ensures that customers can get more than just a bundle deal, it also opens 863
the possibility of inferior third-party options appearing as alternatives. Given that a fraction of 864
today’s third-party services use less accurate, less standardized, and less secure methods (such as 865
screen scraping to gather data), having an open standard should be a net positive. 866
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
24
6 Software and Security Practices in Banking-Related Areas 867
The use of information technology within banking or financial services is not new. Electronic 868
payment processing, payroll, transfers, and other services have long existed but are usually 869
offered as features or benefits of a larger package deal. The controls and software mechanisms 870
for these features are implemented in a closed manner by the institution offering the product. 871
Most larger institutions running these services have their own security practices, and while these 872
are generally compliant with expected modern standards, they differ greatly (e.g., online 873
password policies between different banks). OB can improve the security of the current e-874
banking ecosystem by offering a set of common standards, both in software and in operational 875
guidelines, so that large and small institutions could be held to the same level of data security. 876
Another popular and convenient form of banking includes P2P banking. There are many 877
traditional forms of payment and transfer of money (e.g., cash, credit card, check, ACH, wire) 878
that have been augmented to the point of being almost seamless for digitally sending and 879
receiving money. These services are either adopted by, backed by, or are compatible with 880
traditional banking services and offer customers convenient means of transferring, paying, or 881
receiving money. An OB ecosystem would not supplant these services but rather allow them to 882
rely on a common set of standards and APIs for handling the data so that they can focus on the 883
true value-added features of their platforms. 884
While cryptocurrencies do not fall under the model of traditional banking, they nonetheless have 885
many overlapping software and security challenges with open banking, P2P banking, and digital 886
wallets. Many digital wallet services offer a combination of traditional banking as well as 887
cryptocurrency features. While there are very few standards specific to this topic, they still fall 888
under the purview of better cybersecurity practices. 889
Data aggregation services provide important information to consumers and institutional analysts. 890
On the consumer side, this can span a large range of “quality of life” services, including finding 891
the best savings or loan rate, the best features in a credit card, credit monitoring, or even 892
financial planning. On the institutional side, aggregated data can be used in a multitude of ways, 893
including fraud detection, customer service, forecasting and market analytics, and even 894
advertising. Due to the large amount of data, having a common schema of data would be 895
immensely beneficial to all parties involved, and an OB ecosystem would contribute to having 896
such a schema. At the same time, privacy and cybersecurity are of great importance when 897
dealing with large data. Abundant personally identifiable information and consumer habits can 898
be valuable both in the hands of analysts and cybercriminals. 899
Finally, many brokerages, stock trading platforms, and automated financial planning “robo-900
advisors” in the U.S. already provide API access. Again, while these are not standardized, they 901
still need to adhere to quality cybersecurity standards. However, they are also not subject to the 902
same types of regulation as traditional banks and may therefore offer easier API access. 903
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
25
7 API Security: Widely Deployed Approaches and Challenges 904
APIs are the key element for OB success. This section first considers the classes of APIs 905
presented in the U.K. OBIE standard: read/write, open data, directory, dynamic registration, and 906
management reporting. Within each of these classes, some of the parallels between what has 907
been deployed with the context of open banking, what has been deployed outside of the context 908
of OB, and what cybersecurity challenges exist in these are considered. 909
7.1 Intrabank APIs 910
APIs are loosely separated into intrabank (namely within a single bank or financial institution) 911
and interbank APIs. Intrabank APIs are read/write and open data. Read-only APIs provide a 912
means to retrieve certain pieces of account information without the ability to modify it. Such 913
APIs would be beneficial for allowing account access to a third party that only wants to gather 914
that data to improve the experience of the customer (e.g., financial planning purposes). It 915
provides a strong one-way flow property that prevents misuse or the malicious use of access to 916
manipulate funds. Such APIs have been deployed in the U.S. and abroad for such settings. In 917
contrast, read/write APIs are somewhat riskier as they allow for the modification of account data 918
or even initiate transactions. However, carefully designed standards could readily assuage such 919
concerns, and success stories include both international OB ecosystems as well as U.S. brokerage 920
accounts that support API trading. 921
Open data standards are also important when considering API access. Having common schemas 922
across the industry means that data can be more easily aggregated with fewer errors. Consider 923
the example of the Australian open finance approach where data can be transmitted beyond 924
banking and into utilities, services, and other aspects of life that involve transactions. Having 925
such common data standards would help accelerate the development of both internal and third-926
party applications and promote a wider adoption of such services. 927
7.2 Interbank APIs 928
Managing accounts and identities across the ecosystem also requires an additional directory API. 929
This requirement is akin to a public-key infrastructure where identities, certificates, keys, and 930
such are maintained. This directory is the main entry point of APIs in order to ensure that they 931
are authenticated, identified, and provided with appropriate identification information to perform 932
further actions. 933
Critical to the management of the directory is the ability to enroll, modify, and remove entities. 934
Although several countries have developed open banking APIs to perform such tasks, there is the 935
complementary challenge of the physical linking between identities and people or organizations. 936
Even in the U.S., online-only banks that do not have a brick-and-mortar presence have solutions 937
to the problem of personal identification, but no common open standard (either in terms of 938
software or operations) has been set. Management and reporting APIs are also important and 939
included in the OBIE topics of focus. Having common data types, forms, and reporting contents 940
are important for the ongoing success of deployed systems. 941
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
26
7.3 API Security 942
The U.K. OBIE uses the Open ID Foundation’s Financial-grade API, which in turn uses OAuth 943
2.0 as a critical component. OAuth 2.0 is a protocol for user authorization and access delegation 944
for REST endpoints. It has been widely deployed for use in web services around the world. It is 945
by nature an open standard and serves as a solid module within an OB framework. 946
Another popular protocol is the single sign-on service of the Security Assertion Markup 947
Language (SAML). SAML has not been used as much in banking services as it offers a “one-948
click” logon when a user has already been identified and authenticated. The convenience is also a 949
potential weakness, especially when it comes to something as sensitive as banking data. It is 950
nonetheless popular and secure for serving its purpose of convenient logins. 951
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
27
8 Privacy Relations to NIST and Other Standard Frameworks 952
Because banking deals with customer data, privacy is also a concern. OB initiatives should be 953
proactive in adopting privacy frameworks, such as the NIST Privacy Framework [71], which 954
should be considered during both the design of the OB framework as well as the adoption and 955
integration of the framework into existing systems. In particular, the five primary functions of 956
the NIST Privacy Framework should be observed: Identify, Govern, Control, Communicate, and 957
Protect. 958
Other privacy frameworks have been adopted as well. For example, the Open ID Financial API 959
encourages stakeholders to adhere to the ISO/IEC 29100 privacy framework [72]. The FAPI 960
explicitly calls out 11 categories of interest: consent and choice; purpose legitimacy and 961
specification; collection limitation; data (access) limitation; use, retention, and data disclosure 962
limitation; accuracy and quality; openness, transparency, and notice; individual participation and 963
access; accountability; information security; and privacy compliance. 964
Just as important is the OB ecosystem’s ability to ensure that the data remains protected. Given 965
the connected nature of OB, it would make sense to incorporate cybersecurity principles into the 966
standard. Frameworks such as the NIST Cybersecurity Framework [73] provide tenets to adhere 967
to. 968
Beyond traditional cybersecurity, the ability to simultaneously protect, compute, and authenticate 969
across multiple domains has attracted the attention of new forms of cryptography. A NIST 970
project aimed at studying multi-party and threshold cryptography is currently being offered as an 971
approach toward distributing trust to ensure no single point of failure [74]. These new techniques 972
can offer solutions to previously unsolved problems of computing on sensitive data and data 973
provenance. 974
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
28
9 Conclusion 975
OB is quickly coming online with well-developed guidelines and regulations, and many 976
countries have already implemented feasible solutions to the security and privacy problems of 977
OB. 978
While the U.S. has not yet developed its own OB ecosystem, many of the necessary components 979
already exist in e-banking and P2P services. Still, more implementation work is needed, and the 980
experiences of other countries that are further ahead in the adoption of OB can be monitored for 981
best practices and lessons learned regarding cybersecurity and privacy. This report has described 982
those experiences. 983
Finally, this report is not intended to be a promotion of OB within the U.S but rather a factual 984
description of the technology and how various countries have implemented it. The proposal of a 985
specific API that would be compatible across heterogeneous systems was purposely avoided. 986
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
29
References 987
[1] Monetary and Financial Statistics Manual and Compilation Guide and Financial 988
Soundness Indicators’ Compilation Guide, International Monetary Fund, 2017. [Online]. 989
Available at https://www.imf.org/en/Data#manuals. 990
[2] Phil Laplante and Nir Kshreti, “Open Banking Definition and Description.” Computer, 991
Vol. 10, October, 2021, pp. 22-28. 992
[3] Phil Laplante and Mohamad Kassab, “Open Banking: What it is, Where it’s at, and 993
Where it’s going,” Computer, January, 2022. 994
[4] K. Rose, “41% of lenders taking ‘wait and see’ approach to Open Banking” March 31, 995
2021. Available at https://bestadvice.co.uk/41-of-lenders-taking-wait-and-see-approach-996
to-open-banking/. 997
[5] M. Kerse & I. Jenik. “Some Countries Have Digital Bank Licenses, Others Have Digital 998
Banks.” Available at https://www.cgap.org/blog/some-countries-have-digital-bank-999
licenses-others-have-digital-banks. 1000
[6] H. Farag et al., “Peer Pressure: How do Peer-to-Peer Lenders affect Banks' Cost of 1001
Deposits and Liability Structure?”, 14 Jun 2019. Available at 1002
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3398843. 1003
[7] Stan Cole. “How can banks respond to the open banking revolution?” March 30, 2021. 1004
Available at https://www.worldfinance.com/contributors/how-can-banks-respond-to-the-1005
open-banking-revolution. 1006
[8] M. Strohm, “5 Benefits Of Digital Banking In 2021” Feb 24, 2021. Available at 1007
https://www.forbes.com/advisor/banking/benefits-of-digital-banking/. 1008
[9] C. de Roure et al. “How does P2P lending fit into the consumer credit market?”, 1009
Deutsche Bundesbank, No 30/2016. Available at 1010
https://www.bundesbank.de/resource/blob/704046/b53dc281b4666672e6d526a35e50fd51011
0/mL/2016-08-12-dkp-30-data.pdf. 1012
[10] A. Najarian “Cybersecurity best practices for the booming online and P2P lending space” 1013
June 15, 2016. Available at https://www.itproportal.com/2016/06/15/cybersecurity-best-1014
practices-for-the-booming-online-and-p2p-lending-space/. 1015
[11] Stephen Ley et al., Deloitte. “Open Banking around the world: Towards a cross-industry 1016
data sharing ecosystem,” 2018. Available at 1017
https://www2.deloitte.com/global/en/pages/financial-services/articles/open-banking-1018
around-the-world.html. 1019
[12] Susan M. Pandy, Federal Reserve Bank of Boston. “Modernizing U.S. Financial Services 1020
with Open Banking and APIs,” February 8, 2021. Available at 1021
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
30
https://www.bostonfed.org/-/media/Documents/PaymentStrategies/Modernizing-US-1022
Financial-Services-with-Open-Banking-and-APIs.pdf. 1023
[13] Alice Prahmann, Franziska Zangl, Oliver Dlugosch, and Stephanie Milcke, ndigit. “Open 1024
Banking APIs Worldwide,” 2019. Available at https://www.openbankingexpo.com/wp-1025
content/uploads/2019/09/ndgit-Open-Banking-APIs-worldwide-Whitepaper.pdf. 1026
[14] PricewaterhouseCoopers. “The future of banking is open: How to seize the Open 1027
Banking opportunity,” 2018. Available at https://www.pwc.co.uk/financial-1028
services/assets/open-banking-report-web-interactive.pdf. 1029
[15] Directive (EU) 2015/2366 of the European Parliament and of the Council of 25 1030
November 2015 on payment services in the internal market, amending Directives 1031
2002/65/EC, 2009/110/EC and 2013/36/EU and Regulation (EU) No 1093/2010, and 1032
repealing Directive 2007/64/EC, 2015 O.J. (L 336), p. 35–127. Available at https://eur-1033
lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32015L2366. 1034
[16] Sidley Austin LLP. “Brexit and Payment Services: UK Proposes Amendments to Key 1035
Regulations,” Sept. 18, 2018. Available at 1036
https://www.sidley.com/en/insights/newsupdates/2018/09/brexit-and-payment-services-1037
uk-proposes-amendments-to-key-regulations. 1038
[17] Kai Zhang, K&L Gates LLP. “Brexit: Payment Regulations on a Temporary Standstill,” 1039
National Law Review, Volume X, Number 364, Dec. 29, 2020. Available at 1040
https://www.natlawreview.com/article/brexit-payment-regulations-temporary-standstill. 1041
[18] Competition and Markets Authority. The Retail Banking Market Investigation Order 1042
2017. Feb. 2, 2017. Available at 1043
https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_1044
data/file/600842/retail-banking-market-investigation-order-2017.pdf. 1045
[19] Competition and Markets Authority. Explanatory Note: The Retail Banking Market 1046
Investigation Order 2017. Feb. 28, 2017. Available at 1047
https://assets.publishing.service.gov.uk/media/5ee0ec7d86650c42122f536e/retail-1048
banking-explanatory-note.pdf. 1049
[20] Open Banking Limited. “OBIE publishes Open Banking Standards version 3.0,” Sept. 7, 1050
2018. Available at https://www.openbanking.org.uk/news/open-banking-publishes-open-1051
banking-standards-version-3-0/. 1052
[21] Open Banking Limited. “The OBIE Highlights – July 2021,” Aug. 19, 2021. Available at 1053
https://www.openbanking.org.uk/news/the-obie-highlights-july-2021/. 1054
[22] European Banking Authority. Final Report: Draft Regulatory Technical Standards on 1055
Strong Customer Authentication and common and secure communication under Article 1056
98 of Directive 2015/2366 (PSD2) (EBA/RTS/2017/02). Feb. 23, 2017. Available at 1057
https://www.eba.europa.eu/sites/default/documents/files/documents/10180/1761863/314b1058
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
31
d4d5-ccad-47f8-bb11-1059
84933e863944/Final%20draft%20RTS%20on%20SCA%20and%20CSC%20under%20P1060
SD2%20%28EBA-RTS-2017-02%29.pdf. 1061
[23] Euro Retail Payments Board Secretariat. Mandate of the Working Group on a SEPA API 1062
Access Scheme (November 2020 – June 2021). Nov. 16, 2020. Available at 1063
https://www.ecb.europa.eu/paym/groups/erpb/shared/pdf/14th-ERPB-1064
meeting/Mandate_of_the_working_group_on_a_SEPA_API_access_scheme.pdf?a8d9ac1065
20cc6887d6934493dafc286d15. 1066
[24] Alex Rolfe, Horst Forster and James Wood. “Open Banking Readiness Index: The Future 1067
of Open Banking in Europe,” Payments Cards & Mobile, June 17, 2021. 1068
[25] Eyal Sivan. “Open Banking regulation & data rights with Gavin Littlejohn,” Axway 1069
Blog, July 14, 2020. Available at https://blog.axway.com/digital-strategy/open-banking-1070
regulation-data-rights. 1071
[26] Hakan Eroglu. “Berlin Group und der Weg zur PSD3” (in German), MoneyToday.ch, 1072
Dec. 5, 2018. Available at https://www.moneytoday.ch/news/berlin-group-und-der-weg-1073
zur-psd3/. 1074
[27] UK Finance. “Open Banking Futures: Blueprint and Transition Plan,” March 2021. 1075
Available at https://www.ukfinance.org.uk/system/files/Open-Banking-Phase-II-report-1076
FINAL.pdf. 1077
[28] “UK Finance sets out future model for Open Banking,” Finextra, Mar. 2, 2021. Available 1078
at https://www.finextra.com/newsarticle/37583/uk-finance-sets-out-future-model-for-1079
open-banking. 1080
[29] Financial Conduct Authority. “FCA publishes feedback to Call for Input on open 1081
finance,” Mar. 26, 2021. Available at https://www.finextra.com/newsarticle/37583/uk-1082
finance-sets-out-future-model-for-open-banking. 1083
[30] The Berlin Group. “PRESS RELEASE – Berlin Group starts new openFinance API 1084
Framework,” Oct. 26, 2020. Available at https://www.berlin-group.org/single-post/press-1085
release-berlin-group-starts-new-openfinance-api-framework. 1086
[31] James Roche. “Global and regional impacts of SCA and 3-D Secure 2.0 (EDS2),” The 1087
Paypers, Oct. 6, 2020. Available at https://thepaypers.com/thought-leader-insights/global-1088
and-regional-impacts-of-sca-and-3-d-secure-20-3ds2--1244971. 1089
[32] “SCA for PSD2 could cost merchants more than EUR 100 bln in 2021,” The Paypers, 1090
Sept. 24, 2020. Available at https://thepaypers.com/digital-identity-security-online-1091
fraud/sca-for-psd2-could-cost-merchants-more-than-eur-100-bln-in-2021--1244803. 1092
[33] Stephen Ley and Valeria Gallo, Deloitte. “PSD2 standard on secure communication: a 1093
balancing act,” 2017. Available at https://www2.deloitte.com/ie/en/pages/financial-1094
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
32
services/articles/psd2-standard-on-secure-communication.html. 1095
[34] European Banking Authority. Final Report: Guidelines on the conditions to benefit from 1096
an expemption from the contingency mechanism under Article 33(6) of Regulation (EU) 1097
2018/389 (RTS of SCA & CSC) (EBA/GL/2018/07). Dec. 4, 2018. Available at 1098
https://www.eba.europa.eu/sites/default/documents/files/documents/10180/2250578/4e3b1099
9449-ecf9-4756-8006-1100
cbbe74db6d03/Final%20Report%20on%20Guidelines%20on%20the%20exemption%20t1101
o%20the%20fall%20back.pdf. 1102
[35] John Salmon and Jonathan Chertkow, Hogan Lovells. “PSD2: ban on traditional screen 1103
scraping confirmed in final strong customer authentication RTS,” Nov. 29, 2017. 1104
Available at https://www.engage.hoganlovells.com/knowledgeservices/news/psd2-ban-1105
on-traditional-screen-scraping-confirmed-in-final-strong-customer-authentication-rts. 1106
[36] Patrice Fritsch, EY PFS Solutions. “How to navigate the fallback mechanism exemption 1107
in PSD2?” Mar. 22, 2019. Available at https://www.ey.com/en_lu/payments/psd2--1108
navigating-the-fallback-mechanism-exemption. 1109
[37] Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 1110
2016 on the protection of natural persons with regard to the processing of personal data 1111
and on the free movement of such data, and repealing Directive 95/46/EC (General Data 1112
Protection Regulation), 2016 O.J. (L 119), p. 1–88. Available at https://eur-1113
lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679. 1114
[38] Department for Digital Culture, Media and Sport. General Data Protection Regulation 1115
Keeling Schedule. Dec. 18, 2020. Available at 1116
https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_1117
data/file/969514/20201102_-_GDPR_-1118
__MASTER__Keeling_Schedule__with_changes_highlighted__V4.pdf. 1119
[39] European Data Protection Supervisor. Opinion 5/2018: Preliminary Opinion on privacy 1120
by design. May 31, 2018. Available at 1121
https://edps.europa.eu/sites/default/files/publication/18-05-1122
31_preliminary_opinion_on_privacy_by_design_en_0.pdf. 1123
[40] European Data Protection Board. Guidelines 4/2019 on Article 25 Data Protection by 1124
Design and by Default, Version 2.0. Oct. 20, 2020. Available at 1125
https://edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_201904_dataprotecti1126
on_by_design_and_by_default_v2.0_en.pdf. 1127
[41] Kenneth A. Bamberger, Ran Canetti, Shafi Goldwasser, Rebecca Wexler, and Evan 1128
Joseph Zimmerman. “Verification Dilemmas, Law, and the Promise of Zero-Knowledge 1129
Proofs,” Berkeley Technology Law Journal, Vol. 37, No. 1 (forthcoming 2022). Preprint, 1130
May 6, 2021. Available at https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3781082. 1131
[42] Commonwealth of Australia. “What is CDR?” 2021. Available at 1132
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
33
https://www.cdr.gov.au/what-is-cdr. 1133
[43] Competition and Consumer (Consumer Data Right) Rules 2020. Compilation No. 3. 1134
Dec. 23, 2020. Available at https://www.legislation.gov.au/Details/F2021C00076. 1135
[44] Data Standards Body. Consumer Data Standards. 2021. Available at 1136
https://consumerdatastandardsaustralia.github.io/standards/#introduction. 1137
[45] Australian Competition and Consumer Commission. Compliance Guidance for Data 1138
Holders: Banking sector. April 2021. Available at 1139
https://www.accc.gov.au/system/files/CDR%20-1140
%20Compliance%20guidance%20for%20data%20holders%20in%20the%20banking%201141
sector%20-%20April%202021.pdf. 1142
[46] Commonwealth of Australia. “Current Providers,” 2021. Available at 1143
https://www.cdr.gov.au/find-a-provider. 1144
[47] Australian Competition and Consumer Commission. “Guidance on screen-scraping,” 1145
Mar. 23, 2021. Available at https://cdr-support.zendesk.com/hc/en-1146
us/articles/900005316646-Guidance-on-screen-scraping. 1147
[48] Eyal Sivan. “Exploring data rights – an interview with James Bligh,” Axway Blog, Jan. 1148
19, 2021. Available at https://blog.axway.com/digital-strategy/james-bligh. 1149
[49] Australian Competition and Consumer Commission. “Consumer data right (CDR),” 1150
2021. Available at https://www.accc.gov.au/focus-areas/consumer-data-right-cdr-0. 1151
[50] “About – IndiaStack.” Available at https://www.indiastack.org/about/. 1152
[51] “About Aadhaar AUTH API – IndiaStack.” Available at 1153
https://www.indiastack.org/aadhaar/. 1154
[52] “About eKYC API – IndiaStack.” Available at https://www.indiastack.org/ekyc/. 1155
[53] “About eSign API – IndiaStack.” Available at https://www.indiastack.org/esign/. 1156
[54] Digital India Corporation. “FAQs.” Available at 1157
https://www.digilocker.gov.in/about/faq. 1158
[55] Yan Carrière-Swallow, Vikram Haksar, and Manasa Patnam. “India’s Approach to Open 1159
Banking: Some Implications for Financial Inclusion,” IMF Working Paper WP/21/52, 1160
Feb. 26, 2021. Available at 1161
https://www.imf.org/en/Publications/WP/Issues/2021/02/26/Indias-Approach-to-Open-1162
Banking-Some-Implications-for-Financial-Inclusion-50049. 1163
[56] Vikas Kathuria. “Data Empowerment and Protection Architecture: Concept and 1164
Assessment,” Observer Research Foundation Issue Brief, Issue No. 487, Aug. 12, 2021. 1165
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
34
Available at https://www.orfonline.org/research/data-empowerment-and-protection-1166
architecture-concept-and-assessment/. 1167
[57 Vrinda Bhandar and Rahul Narayan. “In Striking Down Section 57, SC Has Curtailed the 1168
Function Creep and Financial Future of Aadhaar,” The Wire, Sept. 28, 2018. Available at 1169
https://thewire.in/law/in-striking-down-section-57-sc-has-curtailed-the-function-creep-1170
and-financial-future-of-aadhaar. 1171
[58] Anand Ramachandran. “The future of Aadhaar and eKYC-based solutions,” The 1172
Economic Times, Mar. 4, 2019. Available at 1173
https://economictimes.indiatimes.com/small-biz/sme-sector/the-future-of-aadhar-and-1174
ekyc-based-solutions/articleshow/68251916.cms. 1175
[59] Srinivas Kodali. “How Private Sector Slowly Regained Access to Aadhaar Post SC 1176
Judgment,” The Wire, June 14, 2019. Available at https://thewire.in/law/aadhaar-rbi-1177
supreme-court-uidai. 1178
[60] Rajeshwar Rao. “Open banking in India,” speech, Apr. 19, 2021. Available at 1179
https://www.bis.org/review/r210419a.htm. 1180
[61] NITI Aayog. “Data Empowerment and Protection Architecture: Draft for Discussion,” 1181
Aug. 2020. Available at http://www.niti.gov.in/sites/default/files/2020-09/DEPA-1182
Book.pdf. 1183
[62] Eyal Sivan. “The US market-driven approach to Open Banking with Don Cardinal,” 1184
Axway Blog, July 21, 2020. Available at https://blog.axway.com/amplify-products/api-1185
management/mr-open-banking-with-don-cardinal. 1186
[63] The Clearing House. “The Clearing House Releases Model Agreement to Help Facilitate 1187
Safe Sharing of Financial Data,” Nov. 12, 2019. Available at 1188
https://www.theclearinghouse.org/payment-1189
systems/articles/2019/11/model_agreement_press_release_11-12-19 (accessed Aug. 12, 1190
2021). 1191
[64] Financial Data Exchange. “Frequently Asked Questions about FDX US.” Available at 1192
https://financialdataexchange.org/FDX/About/FAQ-1193
US/FDX/About/FDX_US_FAQ.aspx. 1194
[65] Stan Adams and John B. Morris, Jr., Center for Democracy & Technology. “Open 1195
Banking: Building Trust,” May 26, 2021. Available at https://cdt.org/wp-1196
content/uploads/2021/05/CDT-2021-05-25-Open-Banking-Building-Trust-FINAL.pdf. 1197
[66] Financial Data Exchange. “Financial Data Exchange Launches FDX API 4.2,” Nov. 10, 1198
2020. Available at https://financialdataexchange.org/FDX/News/Press-1199
Releases/FDX_Launches_FDX_API_4.2.aspx. 1200
[67] Financial Data Exchange. OFX Banking Specification, Version 2.3. October 2020. 1201
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
35
Available at https://www.ofx.net/downloads.html. 1202
[68] Nacha, “Afinis Interoperability Standards.” Available at https://www.nacha.org/afinis-1203
interoperability-standards. 1204
[69] U.S. Department of the Treasury. A Financial System That Creates Economic 1205
Opportunities: Nonbank Financials, FinTech, and Innovation, July 2018. Available at 1206
https://home.treasury.gov/sites/default/files/2018-08/A-Financial-System-that-Creates-1207
Economic-Opportunities---Nonbank-Financials-FinTech-and-Innovation.pdf. 1208
[70] Consumer Financial Protection Bureau. “Consumer Protection Principles: Consumer-1209
Authorized Financial Data Sharing and Aggregation,” Oct. 18, 2017. Available at 1210
https://files.consumerfinance.gov/f/documents/cfpb_consumer-protection-1211
principles_data-aggregation.pdf. 1212
[71] NIST. “Privacy Framework: A Tool For Improving Privacy Through Enterprise Risk 1213
Management, Version 1.0,” January 2020. 1214
https://doi.org/10.6028/NIST.CSWP.01162020. 1215
[72] "ISO/IEC 29100:2011: Information technology — Security techniques — Privacy 1216
framework," 2011. 1217
[73] NIST. "Framework for Improving Critical Infrastructure Cybersecurity," April 2018. 1218
https://doi.org/10.6028/NIST.CSWP.04162018 1219
[74] NIST. "Multi-Party Threshold Cryptography," 2021. Available at 1220
https://csrc.nist.gov/projects/threshold-cryptography . 1221
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
36
Appendix A—Acronyms 1222
Selected acronyms and abbreviations used in this paper are defined below. 1223
ANPR Advance Notice of Proposed Rulemaking 1224
AISP Account Information Service Provider 1225
API Application Programming Interface 1226
ASPPS Account Servicing Payment Service Providers 1227
BNPL Buy Now Pay Later 1228
CFPB Consumer Financial Protection Bureau 1229
CIBA Client Initiated Backchannel Authentication 1230
CM Consent Manager 1231
CMA Competition and Markets Authority (U.K.) 1232
DEPA Data Empowerment and Protection Architecture 1233
e-banking Electronic Banking 1234
EBA European Banking Authority (EBA) 1235
FaaS Finance As A Service 1236
FAPI Financial-Grade API 1237
FCA Financial Conduct Authority (U.K.) 1238
FDX Financial Data Exchange 1239
FS-ISAC Financial Services Information Sharing and Analysis Center 1240
FI Financial Institution 1241
KYC Know Your Customer 1242
MI Management Information 1243
NACHA National Automated Clearing House Association 1244
NPCI National Payments Corporation of India 1245
OB Open Banking 1246
OBIE Open Banking Implementation Entity (U.K.) 1247
OFX Open Financial Exchange 1248
PISP Payment Initiation Service Provider 1249
PSD2 Revised Payment Services Directive 1250
P2P Peer-to-Peer 1251
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
37
RBI Reserve Bank of India 1252
RTS Regulatory Technical Standard 1253
SaaS Software As A Service 1254
SAML Security Assertion Markup Language 1255
SCA Strong Customer Authentication 1256
SOA Software-Oriented Architecture 1257
SEPA Single Euro Payments Area 1258
TCH Clearing House (TCH) 1259
TPP Third-Party Payment Services Provider 1260
UIDAI Unique Identification Authority of India 1261
UPI Unified Payments Interface 1262
NISTIR 8389 (DRAFT) CYBERSECURITY CONSIDERATIONS FOR OPEN BANKING
T
ECHNOLOGY AND EMERGING STANDARDS
38
Appendix B—Glossary 1263
Aadhaar authentication In the India banking system, the process by which a unique 1264
identifier (the Aadhaar number) along with the demographic 1265
information or biometric information of the number holder is 1266
submitted to the Central Identities Data Repository for its 1267
verification. 1268
1269
account servicing payment Banks and other financial institutions 1270
service providers 1271
banking entity Any financial institution that conducts business with individuals, 1272
such as a retail bank, credit union, or mortgage company. 1273
central bank A bank that only interacts directly with other financial institutions 1274
(e.g., the U.S. Federal Reserve Bank). 1275
consent manager A third-party online intermediary for financial transactions. 1276
customer Any entity engaging in banking activities, including individuals, 1277
trusts, estates, businesses (small, mid-size, and large), other public 1278
and private entities and investors, and other banking entities. 1279
democratization of data Making proprietary banking information available to any entity 1280
with the owner’s permission to access it. 1281
financial ecosystem A collection of banking entities and customers conducting 1282
financial transactions according to specific rules and governed by a 1283
particular set of laws. 1284
FinTech Any financial services company that primarily focuses on internet-1285
based technology to accelerate or enhance conventional services. 1286
open banking A special kind of financial ecosystem governed by a set of security 1287
profiles, application interfaces, and guidelines for customer 1288
experiences and operations. 1289
1290
