Skip to main content
Back Custom print Text Only Rich Text Print

  • Enabling Technologies

    • Guidelines for Financial Institutions Adopting Enabling Technologies

      • Open Finance Regulation

        C 7 /2023 Effective from 15/4/2024

        • Introduction

          The Central Bank of the UAE (CBUAE), together with the Securities and Commodities Authority (SCA), the Dubai Financial Services Authority (DFSA) of the Dubai International Financial Centre and the Financial Services Regulatory Authority (FSRA) of Abu Dhabi Global Market, collectively referred to as “Supervisory Authorities”, have issued the “Guidelines for Financial Institutions adopting Enabling Technologies” (“the Guidelines”).

          The Guidelines are issued pursuant to the powers vested in the respective law of the individual Supervisory Authorities, including:

          • •The Central Bank of the UAE under the Decretal Federal Law No. (14) of 2018 Regarding the Central Bank & Organization of Financial Institutions and Activities (“Central Bank Law”);
          • •The Securities and Commodities Authority under Federal Law No. (4) of 2000 concerning the Emirates Securities and Commodities Authority and Market;
          • •The Dubai Financial Services Authority pursuant to the Regulatory Law - DIFC Law No. (1) of 2004 concerning Dubai International Financial Centre; and
          • •The Financial Services Regulatory Authority pursuant to Law No. (4) of 2013 concerning Abu Dhabi Global Market.

          The increasing adoption of technology-enabled business models presents both opportunities and challenges to those carrying out Innovative Activities.

          The purpose of the Guidelines is to provide a set of principles when using Enabling Technologies in financial services and accompanying guidance. The key principles are broad enough to cater to the different business models, operating models and financial services offered by existing organisations operating in, and new entrants to, the financial services sector. The key principles are accompanied by more detailed guidance for Institutions to consider when using Enabling Technologies.

          The Supervisory Authorities may issue further guidance relating to the Guidelines.

          • Introduction and Scope

            This Open Finance Regulation (this Regulation) establishes a framework for the licensing, supervision and operation of an Open Finance Framework in the United Arab Emirates. The Open Finance Framework consists of a Trust Framework, an API Hub and Common Infrastructural Services, which provide Open Finance access for the cross-sectoral sharing of data and the initiation of Transactions, on behalf of Users.

            • Mandated Entities

              Participation in the Open Finance Framework is mandatory for all Licensees with respect to the Products and Services within its scope. Licensees (as Data Holders and Service Owners) are required under this Regulation to provide participants in the Open Finance Framework (as data recipients and service initiators) with access to customer data and the ability to Initiate Transactions on customer Accounts and Products.

              Data Sharing and Service Initiation of Transactions is in all cases subject to the express consent of Users, the application of appropriate authentication processes and the use of secure communication. This Regulation and the rights of access to data and Accounts established hereunder, do not apply with respect to activities that are not regulated by the Central Bank.

              Licensees mandated by this Regulation to provide Open Finance access include the following entities:

              a.Banks incorporated in the UAE.
              b.branches of foreign Banks/representative offices of foreign Banks.
              c.specialized Banks.
              d.restricted license Banks.
              e.Islamic Banks and Islamic windows.
              f.Finance Companies.
              g.payment service providers (category 1/2/3/4).
              h.retail payment systems providers.
              i.stored value facility providers.
              j.exchange houses.
              k.loan-based crowdfunding companies. 
              l.Insurance Brokers.
              m.Insurance Companies (national companies and foreign branches).
              n.any other entity deemed to be a relevant Licensee by the Central Bank.

              The Licensees which are mandated to provide Open Finance access, pursuant to this Regulation, will be onboarded in phases. The first phase will include all Banks, including branches of foreign banks, and Insurance Companies (national companies and foreign branches) only. Later phases of the onboarding will be announced by the Central Bank through official channels.

            • Open Finance Providers and their Licensing

              In order to facilitate the adoption of Open Finance and the participation of businesses as licensed Data Sharing Providers and/or Service Initiation Providers, this Regulation establishes a new category of regulatory license for providers of Open Finance Services. Open Finance Providers will be the holders of such a license, which enables them to undertake Data Sharing and/or Service Initiation.

              Providers of Open Finance Services can opt for either one or both of the options to undertake Data Sharing or Service Initiation under an Open Finance License.

              Without prejudice to other regulatory licenses that they hold, an Open Finance License will not permit license holders to perform any other category of licensed activity and, in particular, will not entitle license holders to provide any form of Advice or to arrange or mediate Transactions in licensed activities, or hold customer funds in any form. Open Finance Providers must separately obtain or hold the additional regulatory licenses required to undertake any other licensed activity or activities.

            • Persons Deemed Licensed

              Certain categories of Licensees, as specified in Article 3 of this Regulation, are treated as Persons Deemed Licensed. A Person Deemed Licensed must notify the Central Bank in writing of the intention to provide any Open Finance Service, setting out full details of its intended activities, and obtain the approval of the Central Bank prior to commencing such activities.

            • Articles Applicable to Licensees

              All Licensees, whether or not they are engaged in the provision of Open Finance Services, must comply with the requirements of this Regulation with regard to Data Sharing and Service Initiation by Users through Open Finance Providers and specifically the requirements in Articles 18 to 22 of this Regulation.

          • Objectives

            The objectives of the Guidelines are:

            • •To provide Institutions with best practices on risk management in respect to Enabling Technologies;
            • •To encourage the safety and soundness of Institutions so that relevant risks arising from innovative business models and services are adequately managed and mitigated;
            • •To limit the systemic risks that could arise from the use of innovative technology, thus fostering transparency and financial stability;
            • •To provide guidance on how to manage the risks when adopting Enabling Technologies to deliver more efficient, secure and robust solutions to Customers thereby improving organisational efficiency and financial inclusion; and
            • •To promote the growth and advancement of the UAE financial services sector and encourage adoption of Innovative Activities in the UAE whilst managing risks in a proportionate manner.

            • Objectives

              In exercising its powers and functions under this Regulation, the Central Bank has regard to the following objectives:

              a.Ensuring the safety and soundness of Open Finance Services;
              b.Adoption of effective and risk- based licensing requirements for Data Sharing and Service Initiation;
              c.Promoting the reliability and efficiency of Open Finance Services as well as public confidence;
              d.Encouraging innovation to promote competition and to benefit consumers through. enhanced transparency across all financial products and services; and
              e.Reinforcing the UAE's status as a leading financial technology hub in the region.
               Where this Regulation, or its accompanying Regulations, includes a requirement to provide information or to take certain measures, or to address certain items listed at a minimum, the Central Bank may impose requirements that are additional to those provided in the relevant article.

            • Structure of the Guidelines

              The Guidelines are divided into the following sections:

              • •Section 1: Provides definitions of the key terms used throughout the Guidelines;
              • •Section 2: Sets out the key principles relating to the adoption and use of different types of Enabling Technologies; and
              • •Section 3: Provides guidance on the application of the key principles covering the use of Application Programming Interface (API), Cloud Computing, Biometrics, Big Data Analytics and Artificial Intelligence (AI), and Distributed Ledger Technology (DLT).

              • Article (1) Definitions

                The following terms shall have the meaning assigned to them below for the purposes of this Regulation:

                1. Account: an account held by a User with a Licensee relating to one or more of the Products specified in Article 5 of this Regulation.
                2. Advice: advice on Products or Accounts and includes any method of communication that provides an opinion, evaluation, recommendation, and/or biased information / comparisons to a User or when acting as a User’s agent, provided that it could reasonably be regarded as having the intent to influence a User’s choice or decision to select, buy, sell, hold or subscribe to a particular Product or Account, related options or an interest in a particular Product or Account.
                3. AML Laws: Decree Federal Law No. (20) of 2018 on Anti-Money Laundering and Combating the Financing of Terrorism and Illegal Organizations and Cabinet Decision No. (10) of 2019 Concerning the Implementing Regulation of Decree Federal Law No. (20) of 2018 on Anti-Money Laundering and Combating the Financing of Terrorism and Illegal Organizations, as amended, and any instructions, guidelines and notices issued relating to their implementation.
                4. API Hub: the centralized Application Programming Interface Hub established by the Central Bank, through which parties will be able to access the Open Finance Framework.
                5. Applicant: any juridical person duly incorporated in the State which submits an Application.
                6. Application: a written request for obtaining an Open Finance License.
                7. Bank: any juridical person licensed in accordance with the provisions of the Central Bank Law to primarily carry on the activity of taking deposits and any other Licensed Financial Activities.
                8. Board: the board of directors of an Applicant or Open Finance Provider in accordance with applicable State law.
                9. Central Bank: the Central Bank of the United Arab Emirates.
                10. Central Bank Law: the Decretal Federal Law No. (14) of 2018 Regarding the Central Bank and Organization of Financial Institutions and Services, as amended.
                11. Chief Executive Officer: the most senior executive appointed by the Board.
                12. Common Infrastructural Services: the services specified in Schedule 1 of this Regulation.
                13. Confidential Data: data relating to a User, who is or can be identified, either from the confidential data, or from the confidential data in conjunction with other information that is in, or is likely to come into, the possession of a Person or entity that is granted access to the confidential data.
                14. Controller: a Person that alone or together with the Person’s associates has an interest in at least 20% of the shares in an Open Finance Provider or is in a position to control at least 20% of the votes in an Open Finance Provider.
                15. Data Holder: a Licensee holding User Data.
                16. Data Sharing: an on-line service to provide a User with consolidated User Data relating to one or more Accounts and/or Products held with a Data Holder.
                17. Data Sharing Provider: a juridical person who is licensed by the Central Bank to carry on Data Sharing activities.
                18. Finance Company: the juridical person who is licensed as a Finance Company under the Finance Companies Regulation.
                19. Finance Companies Regulation: Central Bank Circular No. 3/2023, as amended.
                20. Initiate: (1) an electronic instruction to a Service Owner to effect a transfer, credit, debit, placement, withdrawal, redemption, sale, order or cancellation; or (2) communicating a User’s agreement to open, effect, enter into or take any other action in relation to an Account or Product. Initiate does not include the execution of any Transaction.
                21. Insurance Broker: a juridical person licensed to practice insurance brokerage activity in the State, under the Insurance Law.
                22. Insurance Company: any juridical person licensed to engage in insurance business in the State, under the Insurance Law.

                23.  Insurance Intermediation: the activity of soliciting, negotiating or selling insurance contracts through any medium where:

                  (a)“solicit” means attempting to sell insurance or asking a Person to apply for a particular kind of insurance from a particular insurer for compensation;
                  (b)“negotiate” means the act of conferring directly with, or offering Advice directly to, a purchaser or prospective purchaser of a particular contract of insurance concerning any of the substantive benefits, terms or conditions of the contract, provided that the person engaged in that act either sells insurance or obtains insurance from insurers for purchasers;
                  (c)“sell” means to exchange a contract of insurance by any means for money or its equivalent on behalf of an Insurance Company.
                24. Insurance Law: the Federal Decree-Law No. (48) of 2023 Regulating Insurance Activities and its Executive Regulations, and any amendments thereof.
                25. Insurance Underwriting: evaluating the risk and establishing the price of insurance.
                26. Licensed Financial Activities: the financial activities subject to Central Bank licensing and supervision, which are specified in Article (65) of the Central Bank Law.
                27. Licensed Financial Institution: Banks and Other Financial Institutions licensed in accordance with the provisions of the Central Bank Law to carry on a Licensed Financial Activity, including those which carry on the whole or a part of their business in compliance with the provisions of Islamic Shari`ah, and are either incorporated inside the State or have branch offices inside the State.
                28. Licensees: Banks, Insurance Companies, Insurance Brokers and Other Financial Institutions.
                29. Master System of Record: the collection of all data, including Confidential Data, required to conduct all core activities of a Licensee, including the provision of services to clients, managing all risks, and complying with all legal and regulatory requirements.
                30. Open Finance Framework: the framework for Open Finance Services established and operated under this Regulation.
                31. Open Finance License: the license granted under this Regulation to provide Data Sharing and/or Service Initiation.
                32. Open Finance Provider: a juridical person who is licensed by the Central Bank to carry on Open Finance Services.
                33. Open Finance Service: Data Sharing and/or Service Initiation.
                34. Other Financial Institutions: any juridical person, other than Banks, licensed, in accordance with the provisions of the Central Bank Law, to carry on a financial activity or more, of the Licensed Financial Activities.
                35. Outsourcing: an agreement with another party either within or outside the UAE, including a party related to the Open Finance Provider, to perform on a continuing basis an activity which currently is, or could be, undertaken by the Open Finance Provider itself.
                36. Payee: a Person who is the intended recipient of funds, which have been the subject of a Transaction.
                37. Payer: a Person who holds a Payment Account and gives a payment order from that Payment Account, or, where there is no Payment Account, a Person who gives a payment order.
                38. Payment Account: an account with a Payment Service Provider held in the name of at least one user of a Retail Payment Service which is used for the execution of payment Transactions.
                39. Payment Service Provider: a juridical person that has been licensed in accordance with the Retail Payment Services and Card Schemes Regulation to provide one or more Retail Payment Services and has been included in the register of Licensed Financial Institutions as per Article (73) of the Central Bank Law.
                40. Person: a natural or juridical person, as the case may be.
                41. Personal Data: any information, which is related to an identified or identifiable natural person.
                42. Person Deemed Licensed: a Person specified in Article 3 of this Regulation as deemed licensed under this Regulation.
                43. Processing: in relation to Personal Data and for the purposes of Article 22 of this Regulation, any operation or set of operations which is performed on Personal Data or on sets of Personal Data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction.
                44. Product: a product specified in Article 5 of this Regulation.
                45. Regulations: any resolution, regulation, circular, rule, standard or notice issued by the Central Bank.
                46. Retail Payment Service: any business activity set out in Annex I of the Retail Payment Services and Card Schemes Regulation, as amended.
                47. Retail Payment Services and Card Schemes Regulation: Central Bank Circular No. 15/2021, as amended.
                48. Senior Management: the executive management of the Open Finance Provider responsible and accountable to the Board for the sound and prudent day-to-day management of the Open Finance Provider, generally including, but not limited to, the Chief Executive Officer, chief financial officer, chief risk officer, and heads of the compliance and internal audit functions.
                49. Sensitive Data: any Personal Data related to the health of a person, such as his/her physical, psychological, mental, genetic or sexual condition, including information related to healthcare services provided thereto that reveals his/her health status.
                50. Service Initiation: the service of initiating by electronic means a Transaction relating to an Account or Product.
                51. Service Initiation Provider: a juridical person who is licensed by the Central Bank to carry on Service Initiation activities.
                52. Service Owner: a Licensee that holds an Account or Product for a User.
                53. State: the United Arab Emirates (UAE).
                54. Stored Value Facilities Regulation: Central Bank Circular No. 6/2020, as amended.
                55. Technical Service Provider: a Person who provides technical support to third parties for the provision of Open Finance Services, including information technology services, communication network provision, the processing and storage of data, the obtaining and processing of Account and Product information and trust and privacy protection services.
                56. Transaction: an act Initiated by a User through the Service Initiation Provider to effect a transfer, credit, debit, placement, withdrawal, redemption, sale, order or cancellation in relation to an Account or a Product.
                57. Trust Framework: the trust framework established and operated pursuant to Article 2 and Schedule 1 of this Regulation.
                58.  Unauthorized Transaction: a transaction, the execution or initiation of which, the User has not given consent for.
                59. User: a Person who uses Data Sharing or Service Initiation.
                60. User Data: information relating to a User that is: (1) in relation to Accounts and Products as specified in Article 5 of this Regulation; and (2) data more particularly described in the relevant Regulations issued by the Central Bank for that purpose.

              • Scope of Application

                The Guidelines are applicable to all Institutions licensed and supervised by the Supervisory Authorities that are using, or intend to use, Enabling Technologies. Institutions are expected to consider the application of the Guidelines to their business activities in a manner that reflects the size and complexity of the Institution and the nature, scope, risk level, complexity and materiality of their Institution’s Innovative Activities. They are in addition to any binding regulations, standards, guidance, and other instructions issued by the relevant Supervisory Authorities, which shall take precedence over the Guidelines.

                • The Open Finance Framework

                  • Requirements to be Licensed

                    • Article (2) Licensing and Licensing Procedures

                      1. No juridical person may engage in providing an Open Finance Service within the State unless it obtains an Open Finance License from the Central Bank or is specified as a Person Deemed Licensed.
                      2. An Applicant for an Open Finance License must submit an Application (together with the required supporting documents and information) to the Central Bank in accordance with the procedure specified by the Central Bank’s Licensing Division and according to its licensing guidelines.
                      3. An Applicant must submit an Application which includes the options for which it would like to apply in respect of Data Sharing or Service Initiation. If the Licensee later seeks to change the options selected under their license, they must re-apply and obtain approval from the Central Bank.
                      4. An Applicant must at the time of submitting its Application satisfy all requirements as to legal form, minimum capital and fit and proper requirements and any other requirements set by the Central Bank.
                      5. The Central Bank will issue its decision of approval or dismissal of the Application within a period not exceeding sixty (60) working days from the date of the Applicant meeting all conditions and requirements for licensing. The lapse of this period without decision on the Application shall be considered an implicit rejection thereof.
                      6. The granting by the Central Bank of an Open Finance License permits the holder of that license to provide an Open Finance Service (Data Sharing and/or Service Initiation) but no other Licensed Financial Activities or services.
                      7. A Technical Service Provider does not require an Open Finance License provided that its services are limited to the provision of support services to Open Finance Providers and/or Persons Deemed Licensed and it does not directly engage in any activities regulated under this Regulation.
                      8. In the event of use of a Technical Service Provider by an Open Finance Provider or a Person Deemed Licensed, the responsibility, regulatory requirements, legal basis and liability as a result of operation within the Open Finance Framework cannot be transferred to the Technical Service Provider or any other third party.

                    • Article (3) Persons Deemed Licensed

                      1. The following are Persons Deemed Licensed:

                        1.1.Banks licensed in accordance with the Central Bank Law;
                        1.2.Finance Companies licensed in accordance with the Finance Companies Regulation;
                        1.3.Persons licensed by the Central Bank to provide Retail Payment Services under the Retail Payment Services and Card Schemes Regulation;
                        1.4.Insurance Brokers licensed in accordance with the Insurance Law;
                        1.5.Insurance Companies licensed in accordance with the Insurance Law; and
                        1.6.Stored value facility providers licensed in accordance with the Stored Value Facilities Regulation.
                      2. A Person Deemed Licensed must provide prior written notice to the Central Bank of its intention to provide an Open Finance Service. The notice must be in the form prescribed by the Central Bank from time to time and must provide a description of the Open Finance Service that the Person intends to provide, the resources that will be utilised in the provision of the Open Finance Service and the governance arrangements relating to them. The Central Bank’s approval must be obtained prior to the commencement of the provision of the Open Finance Service. The Central Bank will issue its decision of approval or rejection within a period not exceeding sixty (60) working days from the date of the notice. The lapse of this period without decision on the request shall be considered an implicit rejection thereof.
                      3. All articles of this Regulation apply to Persons Deemed Licensed, when their approval to provide the Open Finance Service is granted by the Central Bank.

                    • Article (4) Limitations

                      1. An Open Finance Provider must not:

                        1.1.receive, hold or transfer any funds for or on behalf of a User;
                        1.2. provide Advice to a User in relation to a particular Account or Product;
                        1.3.provide any personal and specific recommendation to a User in relation to a particular Account or Product;
                        1.4.receive any fee, commission, payment or other benefit from the provider of an Account or Product;
                        1.5.process any User Data that is Sensitive Data for the provision of any Open Finance Service, even with the explicit consent of the User;
                        1.6.negotiate, mediate, effect or enter into any agreement or Transaction on behalf of a User in relation to an Account or Product; or
                        1.7.engage in any form of Insurance Intermediation or Insurance Underwriting.
                      2. The limitations specified in Article 4(1) of this Regulation, do not prevent an Open Finance Provider from providing Users with information, including information based on analyses, relating to commercially available but nonspecific Accounts and/or Products. This can be communicated by displaying the information on-line or otherwise, but must not involve the provision of Advice.
                      3. The limitations specified in Article 4(1) of this Regulation do not apply to an Open Finance Provider who holds any required additional license to perform the relevant activities from the Central Bank.

                       

                • Section 1: Definitions

                  In the Guidelines, words and expressions have the meanings set out below.:
                   

                  TermDefinition
                  Application Programming Interface (API)A set of rules and specifications for software programs to communicate with each other that forms an interface between different programs to facilitate their interaction.

                  There are various types of APIs which include:

                  • •Private APIs: used within an organisation to provide interoperability between internal applications in order to help automation and provide flexibility.
                  • •Partner APIs: used to integrate software between a company and its partner, often for a very specific purpose such as providing a product or service.
                  • •Open APIs: Designed to be easily accessible by the wider population, regardless of whether a business relationship has been established or not. This term does not have the same meaning as “Open Banking”.
                  • •Composite APIs: Designed to batch API requests sequentially into a single API call combining different data and service APIs with the aim to improve efficiency.
                  API LifecycleRefers to the phases of:
                  • •Conception: the formulation and design of an API;
                  • •Production: the development and testing of an API;
                  • •Publishing: the steps taken to make an API available for use;
                  • •Consumption: the use of an API; and
                  • •Retirement: the withdrawal of an API from use.
                  API ProviderAn organisation that makes APIs available for use by organisations or persons, including by the organisation itself.
                  ApplicationRefers to the use of an Enabling Technology in any capacity by an Institution, including where the Institution outsources part or all of the use of that Enabling Technology.
                  Artificial Intelligence (AI)Refers to the theory and development of computer systems able to perform tasks that traditionally use human intelligence.
                  Big Data AnalyticsUsing advanced analytics techniques in relation to a large volume of Data, generated by any means and stored in a digital format.
                  BiometricsAutomated recognition of individuals based on their biological and behavioral characteristics. It covers a variety of technologies in which unique, identifiable attributes of people are used for identification and authentication. These include, but are not limited to, a person’s fingerprint, iris print, hand, face, voice, gait or signature, which can be used to validate the identity of individuals.

                  Biometric attributes are based on an individual’s personal biometric characteristics and typically include the use of one of the following:

                  • •Biophysical: Biometric attributes, such as fingerprints, iris print, voiceprints, and facial recognition;
                  • •Biomechanical: Biometric attributes that are the product of unique interactions of an individual’s muscles, skeletal system and nervous system, such as keystroke mechanics; or
                  • •Behavioral: Biometric attributes that consist of an individual’s various patterns of movement and usage, such as an individual’s email or text message patterns, mobile phone usage, geolocation patterns, file access log etc.

                  Biometrics can be used for the following activities, amongst others:

                  • •Facilitating Customer identification and verification at on-boarding and for ongoing Customer authentication;
                  • •Supporting ongoing due diligence and scrutiny of transactions throughout the course of the business relationship;
                  • •Providing better and focused Customer services, e.g. identifying regular Customers at the point of entrance and authenticating transactions; and
                  • •Aiding transaction monitoring for the purposes of detecting and reporting suspicious transactions, as well as, general risk management and anti-fraud efforts.
                  Cloud ComputingUse of a network (“cloud”) of hosting processors to increase the scale and flexibility of computing capacity. Such a network could be built by an Institution or made available by a service provider. This model enables on-demand network access to a shared pool of configurable computing resources (for example, networks, servers, storage facilities, applications and services).
                  CustomerCustomer includes:
                  • •In respect of the CBUAE: A person who is using, or who is or may be contemplating using, any of the services provided by an Institution.
                  • •In respect of the SCA: A natural or legal person.
                  • •In respect of the DFSA: A Retail Client, Professional Client or Market Counterparty.
                  • •In respect of the FSRA - A “Customer”.
                  Credential Service ProviderAn organisation that issues and/or registers authenticators and corresponding electronic credentials (binding the authenticators to the verified identity) to subscribers. Credential Service Provider’s maintain a subscriber’s identity credential and all associated enrolment Data throughout the credential’s lifecycle and provide information on the credential’s status to verifiers.
                  DataA collection of organised information, facts, concepts, instructions, observations or measurements, in the form of numbers, alphabets, symbols, images or any other form, that are collected, produced, or processed by Institutions.
                  Digital ChannelsThe internet, mobile phones, Automated Teller Machines (ATMs), Point of Sale (POS) terminals, Digital Personal Assistants (DPAs), mobile applications, or other similar means for Institutions to contact other organisations or persons.
                  Distributed Ledger Technology (DLT)Processes and related technologies that enable Nodes in a network (or arrangement) to securely propose, validate, agree and record state changes (or updates) to a synchronised ledger that is distributed across the network’s Nodes.

                  Blockchain is a type of DLT which stores and transmits Data in packages called “blocks” that are connected to each other in a digital ‘chain’.
                  Enabling TechnologyOne of the following types of technologies:
                  1. •APIs;
                  2. •Cloud Computing;
                  3. •Biometrics;
                  4. •Big Data Analytics;
                  5. •AI; and
                  6. •DLT.
                  FeeAny fees, charges, penalties and commissions incurred on a product and/or service.
                  GuidelinesRefers to these Guidelines.
                  Governing BodyGoverning Body means an Institution’s Board of Directors, partners, committee of management, or any other form of the governing body of a body corporate or partnership.
                  Identity LifecycleRefers to the phases of:
                  • •Enrolment: collecting and proofing identity data;
                  • •Issuance: issuing one or more credentials;
                  • •Use: checking identity at the point of transactions;
                  • •Management: maintaining identities and credentials; and
                  • •Retirement: removing the identity record.
                  Innovative ActivitiesTechnologically enabled provision of financial services which can take various forms and encompass the different sectors of the financial industry (e.g., crowdfunding, payment services).
                  InstitutionAn Institution includes:
                  • •In respect of the CBUAE: Any licensed and supervised Financial Institution. All references to Institutions include any Outsourcing Service Providers acting on behalf of the Institution.
                  • •In respect of the SCA: Any entity that has obtained a license or approval to engage in a financial activity and / or provide a specific financial service.
                  • •In respect of the DFSA: Any licensed and supervised “Authorised Person”. All references to Institutions include any Outsourcing Service Providers acting on behalf of the Authorised Person.
                  • •In respect of the FSRA: Any “Authorised Person” or “Recognised Body”.
                  IT AssetsAny form of information technology, including software, hardware and Data.
                  Machine LearningMachine Learning is a sub-category of AI that is a method of designing a sequence of actions for the design and generation or development of AI models to solve a problem through learning and experience and with limited or no human intervention.
                  Multi-Factor AuthenticationCombines use of two (2) or more of the following authentication factors to verify a user’s identity:
                  • •knowledge factor - “something an individual knows”;
                  • •possession factor - “something an individual has”; and/or
                  • •biometric factor - “something that is a biological and behavioral characteristic of an individual".
                  NodesNetwork participants in a DLT network.
                  OutsourcingAn agreement with another party either within or outside the UAE, including a party related to an Institution, to perform an activity, process or service on a continuing basis which currently is, or could be, undertaken by the Institution itself. The activity, process or service should be integral to the provision of a financial service or should be provided to the market by the Outsourcing Service Provider on behalf of and in the name of the Institution.
                  Outsourcing Service Provider (OSP)A third-party entity that is undertaking an outsourced activity, process or service or parts thereof, under an outsourcing arrangement. The Institution using an Outsourcing Service Provider always remains responsible and accountable for the actions of that OSP under an outsourcing arrangement and to ensure that its outsourcing arrangements comply with the principles set out in these Guidelines.
                  Permissioned DLTA distributed ledger which can be updated or validated only by authorised users within set governance rules i.e. special permissions are necessary to read, access or write information on them.
                  Permissionless DLTA distributed ledger which can be read or updated by anyone, such as an open-access blockchain used for some cryptocurrencies.
                  Personal DataPersonal Data is any information relating to an identified natural person or identifiable natural person. "Identifiable natural person" is defined as a natural person who can be identified, directly or indirectly, in particular by reference to an identification number or to one or more factors specific to their biological, physical, Biometric, physiological, mental, economic, cultural or social identity.
                  Senior ManagementSenior Management includes:
                  • •In respect of the CBUAE: The executive management of the Institution responsible and accountable to the Board/Governing Body for the sound and prudent day-to-day management of the Institution, generally including, but not limited to, the chief executive officer, chief financial officer, chief risk officer and heads of the compliance and internal audit functions.
                  • •In respect of the SCA: A director or group of executives who assume the tasks of planning the daily administrative and supervisory operations of the company's business to achieve its goals and is appointed by the company's Board/Governing Body.
                  • •In respect of the DFSA: Includes any senior management and Governing Body within an Authorised Person who take responsibility for that Authorised Person’s arrangements and operations.
                  • •In respect of the FSRA: - “Senior Management”.
                  StaffOne or more employee(s) of the Institution acting in any capacity for or on behalf of the Institution.
                  SubscriberA person whose identity has been verified and bound to authenticators (credentialed) by a Credential Service Provider.
                  Supervisory AuthoritiesRefers to the following UAE authorities:
                  • •The Central Bank of the UAE (CBUAE);
                  • •The Securities and Commodities Authority (SCA);
                  • •The Dubai Financial Services Authority (DFSA) of the Dubai International Financial Centre; and
                  • •The Financial Services Regulatory Authority (FSRA) of the Abu Dhabi Global Market.
                  Third PartyAny person, group of persons or organisation external to and not a related party to an Institution.

                   

                   

                   

                  • Accounts and Products in Scope of Open Finance

                    • Article (5) Accounts and Products

                      1. An Account or a Product is within the scope of this Regulation where it relates to any of the following offered or issued by a Licensee:

                        1.1deposits;
                        1.2payment accounts and services;
                        1.3savings accounts and term deposits;
                        1.4credit, debit and charge card accounts and products (including acquiring and processing card transactions);
                        1.5standing orders;
                        1.6direct debits;
                        1.7stored value facilities and prepaid payment accounts;
                        1.8post-paid payment accounts;
                        1.9foreign exchange accounts and products;
                        1.10credit, loans and any other personal finance accounts and products;
                        1.11mortgages and other loans secured on property or other assets;
                        1.12virtual accounts or products providing for the items specified in 1.1 – 1.11 above; and
                        1.13insurance products, including life and general insurance.
                      2. The Central Bank may, from time to time, amend or supplement the list in Article 5(1) of this Regulation.
                      3. The list in Article 5(1) of this Regulation shall not include accounts or products regulated by the Securities and Commodities Authority, unless approved by the Securities and Commodities Authority.

                  • Section 2: Key Principles for Adopting Enabling Technologies

                    • Initial and Ongoing Requirements

                      • Key Principles for All Enabling Technologies

                        1. 2.1Data Protection: Institutions are required to comply with all applicable legislation and regulations in relation to Data protection when handling the use, transmission, and storage of Data.
                        2. 2.2Control Functions: Institutions should have effective audit, compliance and risk management functions that are equipped with the relevant expertise for reviewing and assessing the adequacy of the internal control environment for implementing the Enabling Technologies.
                        3. 2.3Independent Review: Institutions should ensure that formal, independent reviews/audits of Enabling Technologies are carried out periodically, the regularity of which will depend on the nature, scope, complexity and materiality of the Institution’s technology framework. These reviews should be conducted by the internal audit function and/or third party/external auditors that can provide independent, timely assurance in respect of an Institution’s Enabling Technologies, including compliance with relevant internal policies. While Institutions may cosource or outsource the audit activities surrounding their innovative technology, they are expected to ensure that the OSP has a solid understanding of their operations, an appreciation of the existing and potential risks and knowledge of the controls required to remain in compliance with all applicable laws and regulations.
                        4. 2.4Skills, Knowledge and Expertise: Institutions should ensure that their adoption of Enabling Technologies is supported by resources with the necessary skills, knowledge, and expertise specific to their roles and functions. Staff responsible for the operations, management and oversight of innovative technologies should possess the required expertise to ensure ongoing effectiveness and that the technologies continue to meet intended outcomes. Institutions should ensure that they continue to develop specialist expertise relative to the technologies adopted.
                        5. 2.5Training: Given the rapid developments in respect of Enabling Technologies, Institutions should ensure that adequate training is provided to the relevant staff for handling Enabling Technologies.

                        • Article (6) Minimum Capital

                          1. For the purpose of being granted a license by the Central Bank to perform an Open Finance Service, an Open Finance Provider will be required to hold a minimum capital amount of one million Dirham (AED 1,000,000).
                          2. Additional capital requirements may be imposed by the Central Bank, at its sole discretion and notified to the Open Finance Provider, with the Central Bank taking into account factors such as the risk, size and/or complexity associated with the activities conducted by the Open Finance Provider.

                        • Application Programming Interfaces (APIs)

                          1. 2.6Governance: Institutions should establish an approved and documented governance framework for effective decision-making and the proper management and control of risks arising from the use of APIs.
                          2. 2.7Design: Institutions should ensure that APIs, whether designed in-house or by a Third Party, are designed such that the APIs can flexibly evolve and have robust controls to support cybersecurity, cyber resilience, and data protection.
                          3. 2.8Management and Monitoring: Institutions should establish an approved and documented API monitoring framework that addresses infrastructure, technology and security-related incidents and events in a timely and effective manner.
                          4. 2.9Outsourcing: Where an Institution outsources API development to an Outsourcing Service Provider, the Institution must follow the outsourcing requirements of the relevant Supervisory Authority. Institutions should ensure that the contract governing the arrangement between the Institution and Outsourcing Service Provider contains at a minimum information on the roles and obligations of all parties, liability, dispute management, access to relevant information by the relevant Supervisory Authority, and minimum control measures to be employed by the OSP that are acceptable to the Institution.
                          5. 2.10Business Continuity: Institutions should sufficiently cover APIs and the related security controls in their business continuity plans. Institutions should also assess the criticality of different types of APIs being used and ensure that the business continuity planning scenarios reflects them.

                          • Article (7) Aggregate Capital Funds

                            1. An Open Finance Provider must hold, at all times, aggregate capital funds that do not fall below the minimum capital requirements set in Article 6 of this Regulation.
                            2. The minimum capital held as aggregate capital funds must be the higher of the figure stated in Article 6 of this Regulation and the Central Bank’s estimate of the wind down costs for the Open Finance Provider.
                            3. The Central Bank may at its sole discretion impose aggregate capital funds requirements higher than the requirements referred to in Article 7(1) of this Regulation, if, taking into consideration the risk, scale and complexity of the Open Finance Provider’s business, it considers such higher requirements are necessary for ensuring that the Open Finance Provider has the ability to fulfil its obligations under this Regulation.

                          • Cloud Computing

                            1. 2.11Material Arrangements: Institutions should assess the materiality and the associated risks of their Cloud Computing arrangements and address any concerns and expectations that the relevant Supervisory Authority may have prior to implementing any material Cloud Computing arrangement.
                            2. 2.12Governance: Institutions should establish an approved and documented governance framework for effective decision-making and proper management and control of risks arising from the use of Cloud Computing and Outsourcing to Outsourcing Service Providers.
                            3. 2.13Auditability: Institutions should ensure that the Cloud Computing arrangement is auditable by maintaining appropriate evidence and records to enable the Institution’s internal control functions, external auditors, regulators, and other authorities to conduct their audits and reviews.
                            4. 2.14Outsourcing: Institutions should establish an approved and documented governance framework for Outsourcing their Cloud Computing arrangements to appropriately select and monitor vendors as well as mitigate risks arising from Cloud Computing Outsourcing arrangements.
                            5. 2.15Design: Institutions should implement adequate measures that are commensurate with the materiality of the arrangement to ensure that Cloud Computing arrangements are resilient, secure, recoverable, and meet the capacity and other needs of the Institution.
                            6. 2.16Management and Monitoring: Institutions should regularly monitor their Cloud Computing arrangements, to evaluate performance, detect technology and security related incidents, and promptly take any remedial action.
                            7. 2.17Data Protection: Institutions should ensure that the use, transmission and storage of Data in a Cloud Computing arrangement complies with applicable laws and regulations and is secured from unauthorised access, use or modification to the extent commensurate with the importance of the Data.
                            8. 2.18Business Continuity: Institutions should put in place a robust and regularly tested business continuity plan for each material Cloud Computing arrangement and ensure that the plan complies with the relevant Supervisory Authority’s requirements.
                            9. 2.19Exit and Resolution Planning: Institutions should define and maintain specific exit plans for their material outsourced Cloud Computing arrangements and account for these arrangements when developing recovery and resolution plans.

                            • Article (8) Capital Instruments

                              1.  An Open Finance Provider’s aggregate capital funds consist of:

                                1.1.paid-up capital;
                                1.2.reserves, excluding revaluation reserves; and
                                1.3.retained earnings.
                              2. An Open Finance Provider’s aggregate capital funds cannot be met by any capital held within their entity which is otherwise allocated as any other regulatory capital for Licensed Financial Activities.

                              3. The following items must be deducted from the aggregate capital funds:

                                3.1accumulated losses;
                                3.2goodwill; and
                                3.3any other items as determined by the Central Bank.

                            • Biometrics

                              1. 2.20Governance: Institutions should establish an approved and documented governance framework to control and manage the broad range of risks which may arise from the use of Biometrics.
                              2. 2.21Identity Proofing and Enrolment Management: Institutions should establish appropriate identity verification and proofing mechanisms as part of the Biometrics Application’s identity enrolment process.
                              3. 2.22Ongoing Authentication: Institutions should establish controls and processes to protect the customers and their credentials against vulnerabilities and unauthorised access, disclosure or use in the authentication process and throughout the Identity Lifecycle.
                              4. 2.23Management and Monitoring: Institutions should regularly monitor their Biometrics Applications throughout the Identity Lifecycle to evaluate performance, detect security-related events, ensure the adequacy of controls, and promptly take any remedial action.
                              5. 2.24Data Management: Institutions should ensure the security, confidentiality, authenticity, and integrity of Data throughout all phases of authentication and whether the Data is in use, storage, or transmission.

                              • Article (9) Professional Indemnity Insurance

                                1. An Open Finance Provider must hold professional indemnity insurance of an amount and scope suitable and proportionate to the risks arising from the Open Finance Service it provides, as determined by the Central Bank on a case-by-case basis. Subject to this, the minimum limits of indemnity per year are:

                                  1.1.for a single claim, five million Dirham (AED 5,000,000); and
                                  1.2.in aggregate the higher of five million Dirham (AED 5,000,000) or an amount equivalent to 50% of annual income from the Open Finance Provider’s Open Finance Services.
                                   The Central Bank may determine that an Open Finance Provider must hold minimum limits of indemnity in excess of these amounts.
                                2. The professional indemnity insurance must at a minimum cover liabilities of the Open Finance Provider and its employees in respect of, inter alia, Unauthorized Transactions, data loss and breaches, cyber security risks and delayed or incorrectly Initiated Transactions.

                                 

                              • Big Data Analytics and Artificial Intelligence (AI)

                                1. 2.25Governance: Institutions should establish an approved and documented governance framework for effective decision-making and proper management and control of risks arising from the use of Big Data Analytics and AI.
                                2. 2.26Accountability: The Governing Body and Senior Management of the Institution should remain accountable for the outcomes and decisions of their Big Data Analytics and AI Applications including those Applications that make decisions on behalf of the Institutions.
                                3. 2.27Design: Institutions should ensure that the models for their material Big Data Analytics and AI Applications are reliable, transparent, and explainable, commensurate with the materiality of those Applications.
                                4. 2.28Management and Monitoring: Institutions should establish an approved and documented framework to review the reliability, fairness, accuracy and relevance of the algorithms, models and Data used prior to deployment of a material Big Data Analytics and AI Application and on a periodic basis after deployment, to verify that the models are behaving as designed and intended.
                                5. 2.29Ethics: Institutions should ensure that their Big Data Analytics and AI Applications promote fair treatment, produce objective, consistent, ethical, and fair outcomes and are aligned with the Institutions’ ethical standards, values and codes of conduct.
                                6. 2.30Customer protection: Institutions should be transparent with Customers about their use of Big Data Analytics and AI through their conduct and through accurate, understandable, and accessible plain language disclosure.

                                • Article (10) Control of Controllers

                                  1. A Person must not become a Controller of an Open Finance Provider without obtaining prior authorisation from the Central Bank.

                                  2. The Central Bank may grant authorisation under Article 10(1) of this Regulation if it considers that:

                                    2.1having regard to the likely influence of the Controller, the Open Finance Provider will remain compliant with the requirements of this Regulation and any other relevant Regulations, including Regulations issued in accordance with this Regulation and any relevant law; and
                                    2.2the Controller meets the fit and proper and suitability requirements specified by the Central Bank.

                                  3. The approval under Article 10(2) of this Regulation may be granted subject to any conditions that the Central Bank may impose on the Person, including, but not limited to:

                                    3.1conditions restricting the Person’s disposal or further acquisition of shares and/or voting powers in the Open Finance Provider; and
                                    3.2conditions restricting the Person’s exercise of voting power in the Open Finance Provider.

                                • Distributed Ledger Technology (DLT)

                                  1. 2.31Governance: Institutions should establish an approved and documented governance framework for effective decision-making and proper management and control of the risks arising from the use of DLT.
                                  2. 2.32Auditability: Institutions should ensure that the DLT Application is auditable by maintaining appropriate evidence and records to enable the Institution’s internal control functions, external auditors, regulators, and other authorities to conduct their audits and reviews.
                                  3. 2.33Design: Institutions should design their DLT Applications to be efficient and effectively secure IT Assets and any Customer assets.
                                  4. 2.34Anonymity and Pseudonymity: Institutions developing Permissionless DLT Applications should ensure that users are not anonymous or pseudonymous.
                                  5. 2.35Management and Monitoring: Institutions should ensure that their DLT Application are reviewed and monitored on a periodic basis to evaluate performance, detect technology and security related incidents, ensure the adequacy of controls, and promptly take any remedial action.
                                  6. 2.36Business Continuity: Institutions should establish an effective business continuity plan to ensure and periodically test arrangements to maintain the continuity of the service/process performed by the DLT Application in the event of an incident that adversely affects the availability of the Application.

                                  • Article (11) Corporate Governance

                                    1. Open Finance Providers must have and maintain effective, robust and well-documented corporate governance arrangements, including a clear organisational structure with well-defined, transparent and consistent lines of responsibility.

                                    2.  The corporate governance arrangements referred to in Article 11(1) of this Regulation must be comprehensive and proportionate to the nature, scale and complexity of the Open Finance Provider’s business, and must contain, at a minimum:

                                      2.1a Board approved organisation structure which records in writing each division, department or unit, indicating the name of each responsible individual accompanied by a description of the respective function and responsibilities;
                                      2.2controls on conflicts of interest;
                                      2.3controls on integrity and transparency of the Open Finance Provider’s operations;
                                      2.4controls to ensure compliance with applicable laws and Regulations;
                                      2.5methods for maintaining confidentiality of information and complying with data privacy requirements; and
                                      2.6procedures for regular monitoring and auditing of all corporate governance arrangements.
                                    3. The Senior Management of an Open Finance Provider must fulfil fit and proper and suitability requirements specified by the Central Bank from time to time, including that each member of Senior Management:
                                    3.1is competent and possesses the necessary knowledge, skills, qualifications and experience;
                                    3.2has a record of acting honestly, ethically, with integrity and is of good repute;
                                    3.3has a good record of financial conduct;
                                    3.4is able to make his/her own decisions in a reasoned, objective and independent manner; and does not have any conflict of interest that could affect their conduct;
                                    3.5has sufficient time to devote to fully performing his/her duties/responsibilities under this Regulation;
                                    3.6contributes to the collective suitability of the Senior Management; and
                                    3.7meets any additional requirements specified in applicable Regulations.

                                     

                                  • Article (12) Risk Management, Compliance and Internal Audit

                                    1. Open Finance Providers must establish a framework with appropriate mitigation measures and control mechanisms to manage the operational, security and other risks to which they are or might become, exposed.

                                    2. The framework established under Article 12(1) of this Regulation must be proportionate to the nature, scale and complexity of the Open Finance Provider’s business, and must contain, at a minimum:

                                      2.1incident management procedures, including for the detection and classification of major operational and security incidents;
                                      2.2business continuity and disaster recovery plans, which include: (i) an adequate business continuity management programme to ensure continuation, timely recovery, or in extreme situations, orderly scale-down of critical operations in the event of major disruptions. The programme must comprise business impact analysis, recovery strategies, a business continuity plan and alternative sites for business and information technology recovery; and (ii) appropriate software development life cycle practices to ensure operational resilience and minimise application failures that may pose risks to users; and
                                      2.3sound administrative and accounting procedures.
                                    3. Open Finance Providers must establish a risk management function, an internal audit function and a compliance function and ensure that they are adequately resourced.
                                    4. Open Finance Providers must establish and maintain on an ongoing basis a wind down plan that is acceptable to the Central Bank.
                                    5. The risk management function must be independent, permanent, have a reporting line directly to the Board and effectively monitor, report on and mitigate the operational, market, credit, legal and other risks to which the Open Finance Provider is exposed.
                                    6.  The compliance function must be independent, permanent, have a reporting line directly to the Board and must monitor and report on observance of all applicable laws, regulations and standards and on adherence by staff and Senior Management to legal requirements, proper code of conduct and the requirements of this Regulation and other Regulations, where applicable.
                                    7. The internal audit function must be independent, permanent, report directly to the Board, employ best practice in internal audit, and be effective. It must provide independent assurance to Senior Management on the quality of the Open Finance Provider’s internal controls, risk management, compliance, systems, and controls.
                                    8.  Open Finance Providers must not Outsource any material activity, including to any related party without the prior receipt of notification of non-objection from the Central Bank. Open Finance Providers will retain full responsibility for the services provided by any Outsourced service provider. Although all requests for non-objection will be considered on their individual merits, the Central Bank will, in general, not permit the Outsourcing of core activities, and key management and control functions.
                                    9.  Regulatory requirements for specific functions including risk management, internal audit and compliance, may be established in separate Regulations.

                                  • Article (13) Record Keeping

                                    1. Open Finance Providers must maintain records relating to the provision of their Open Finance Services, which must at a minimum include records of the following matters:

                                      1.1.User consent to access User Data and/or Initiate Transactions as required under Article 22 of this Regulation;
                                      1.2.Evidence of all User Data provided to the Open Finance Provider by Licensees who are Data Holders on behalf of Users;
                                      1.3.All Transactions Initiated by the Open Finance Provider on the instruction of Users; and
                                      1.4.Evidence of all User Data related to a Transaction which was destroyed or otherwise disposed of.
                                    2. All records maintained pursuant to Article 13 of this Regulation must be kept securely, in a durable medium and must be capable of being made available to the Central Bank promptly upon request.
                                    3. Open Finance Providers must retain the records referred to in Article 13 of this Regulation for a period of at least five (5) years from the date of creation of such records, unless otherwise required by applicable laws or the Central Bank.

                                  • Article (14) Notification and Reporting Requirements

                                    1.  An Open Finance Provider must be open and cooperative with the Central Bank and notify the Central Bank of all matters that the Central Bank might reasonably require notice of, including to support the performance of the Central Bank’s supervisory functions.
                                    2. An Open Finance Provider must comply with all regulatory reporting requirements, including ongoing requirements specified by the Central Bank from time to time.
                                    3. Where any material change affects the accuracy and completeness of information provided in an Application, the Applicant or Open Finance Provider, as the case may be, must immediately notify the Central Bank of such change and provide all necessary information and documents.
                                    4. An Open Finance Provider must immediately notify the Central Bank of any violation or potential violation of a material requirement under this Regulation or other applicable legal or regulatory requirement.

                                    5. An Open Finance Provider must immediately notify the Central Bank if it becomes aware that any of the following events have occurred or are likely to occur:

                                      5.1if a Data Holder or Service Owner unjustifiably refuses access to an Account or Product and/or information relating to them;
                                      5.2any event that prevents access to or disrupts the operational or security status of the Open Finance Provider;
                                      5.3any legal action taken against the Open Finance Provider or any member of its Senior Management or director of the Board either in the State or outside the State;
                                      5.4the commencement against the Open Finance Provider or any member of its Senior Management or director of the Board of any insolvency, winding up, liquidation or equivalent proceedings, or the appointment of any receiver, administrator or provisional liquidator in any jurisdiction;
                                      5.5any disciplinary measure or sanction taken against the Open Finance Provider or any member of its Senior Management or director of the Board or any measure or sanction imposed on any of them by a body other than the Central Bank, whether in the State or outside the State;
                                      5.6any material change in regulatory requirements to which the Open Finance Provider is subject beyond those of the Central Bank, whether in the State or outside the State; or
                                      5.7any other event specified by the Central Bank.

                    • Section 3: Guidelines for Adopting Enabling Technologies

                      • Requirements Relating to the Sharing of Data and Initiation of Transactions

                        • Application Programming Interfaces (APIs)

                          • Article (15) Obligations of licensees

                            1. Licensees who are Data Holders and Service Owners must:

                              1.1.establish and maintain a dedicated interface to provide secure on-line access to Accounts and Products by Open Finance Providers through the API Hub and other relevant components of the Open Finance Framework;
                              1.2.within fourteen (14) days of receipt of approval from the Central Bank to perform Open Finance Services, register and maintain their registration as a participant under the Trust Framework; and
                              1.3.co-operate openly and in a timely manner, as specified in this Regulation and any accompanying Regulations, with an Open Finance Provider with regard to the sharing of User Data of the Users who are customers of the Licensee and/or the initiation of Transactions, subject to the User’s consent. A Licensee must not share any User Data in its possession where that User is not a customer of the Licensee, or where the Licensee receives the User Data from a Service Owner.
                            2. No Person shall engage in data scraping, or any other similar data extraction activity, whether or not in conjunction with automated data entry, in order to undertake any activities subject to this Regulation except as permitted under applicable laws. No Person shall engage in the interception of digital connections, including but not limited to the application programming interface, between the public interfaces and other systems of a Licensee’s online or mobile applications by way of reverse engineering or any other similar activity, except as permitted under applicable State laws.

                            • Governance

                              1. 3.1Institutions should establish a documented governance framework for effective decision-making and proper management and control of risks arising from the use of APIs. The governance framework should:
                                1. a.Define the roles and responsibilities of the Institution, API Provider and API developer (where different), including the division of duties;
                                2. b.Establish appropriate policies, procedures, standards and controls to govern the API Lifecycle within the Institution;
                                3. c.Employ tools and technologies that enable communication, change management and performance monitoring across the API Lifecycle;
                                4. d.Establish appropriate testing strategies prior to publication and on an ongoing basis for optimal performance of APIs, for example:
                                  1.  i.A load testing strategy which can be used to assess how the API performs against service-level agreements and to determine what response is normal for the API. Target API test case problems that would prevent longer load tests from running correctly should be developed;
                                  2.  ii.Stress testing of the APIs that can be undertaken by simulating a heavy load on the API or by conducting crash point testing to identify the maximum number of users the API can handle; and
                                  3. iii.A monitoring framework that can ensure critical interfaces and functions to be appropriately tested and verified for conformance to expected behavior;
                                5. e.Establish a framework to assess, monitor, report and mitigate risks associated with the APIs including developing mechanisms to ensure regular testing and implementation of coding controls, production monitoring and support post deployment, process control mapping and development of a risk control matrix; and
                                6. f.Be approved by the appropriate Governing Body.
                              2. 3.2When Outsourcing to an Outsourcing Service Provider, Institutions should ensure that access to information is adequately controlled, monitored, reviewed and audited by the Institution’s internal control functions, and regulators, including the appropriate Supervisory Authority;
                              3. 3.3Business continuity plans of an Institution should cover APIs and the security controls associated with APIs. Institutions should assess criticality of the different types of APIs used and ensure that the business continuity planning scenarios cover the various types of APIs being used. The business continuity strategy and arrangements should be updated when changes are made to the operating environment, and most importantly, be tested periodically.

                            • Architecture

                              1. 3.4Institutions should ensure that the systems and technology architecture for the APIs are designed such that the APIs can flexibly evolve. This could be done by making the architecture independent from the applications using the APIs (i.e. such that it is not over tailored to the most common use cases). The evolution of APIs should not hinder existing applications, which should be able to function without interruption.
                              2. 3.5Institutions should establish controls so that the architecture supporting the API and the API itself is secure and protected against misuse or security attacks.

                            • Design

                              1. 3.6When determining the design of an API, Institutions may consider the following elements to deliver innovation and flexibility:
                                1. a.Accessibility: Ensure all relevant parties can access the API;
                                2. b.Interoperability: Enable exchange of Data across Institutions without any dependencies on underlying technologies;
                                3. c.Reuse: Leverage existing standards and taxonomies to avoid duplication of effort;
                                4. d.Independence: Avoid dependency on any vendors or technologies and retain various options for delivery models and implementation technologies;
                                5. e.Extensibility: Establish flexibility to extend APIs to new stakeholders and business channels and offer new functionality in existing APIs;
                                6. f.Stability: Ensure consistency in functionality and accessibility when modifying the API through appropriate governance;
                                7. g.Privacy by design: All APIs should be designed in a way to only expose relevant Data elements to any party in order to fulfil the purpose of the API;
                                8. h.Transparency: Promote transparency and clarity on the API, including environments supported, changes implemented, and standards followed; and
                                9. i.Loosely coupled: Provide flexibility and minimise impact of changes to operations of other APIs or API applications.
                              2. 3.7Institutions should have proper engagement with API Providers before API Providers can expose any Personal Data through the APIs. This engagement should cover the onboarding of and due diligence processes on the API Provider.
                              3. 3.8Institutions should undertake the following steps when designing APIs:
                                1. a.Decide on in-house vs outsourced API development;
                                2. b.Prioritise and sequence APIs to publish;
                                3. c.Consider guiding principles such as openness, usability and interoperability;
                                4. d.Ensure that adequate security and Data protection mechanisms are in place to protect Personal Data; and
                                5. e.Identify and define requirements and technical guidelines.
                              4. 3.9During the development of APIs, Institutions and API Providers should ensure that they:
                                1. a.Adopt the appropriate API design model based on the type of the API and the protocol used;
                                2. b.Develop requirements and technical specification that define the output to be achieved by the APIs and how the APIs should perform their expected functionality from a technical perspective; and
                                3. c.Document these requirements and technical specifications so that the behavior of the API is well understood and can be measured against expected behavior.
                              5. 3.10Institutions should ensure that Personal Data being transmitted or stored is encrypted to enable privacy and integrity of Data. Institutions can consider utilizing secure public/private key based encryption methods and protocols, which should comply with internationally recognised and applicable security standards.
                              6. 3.11Institutions should ensure that access management and authentication processes are used so that only authorised and authenticated individuals and organisations have controlled access to the appropriate API resources.
                              7. 3.12Institutions should ensure that authentication mechanisms are implemented effectively and securely, preventing attackers from compromising authentication tokens, or exploiting implementation flaws to assume other user identities temporarily or permanently.
                              8. 3.13Institutions should develop an appropriate infrastructure to manage and securely store access credentials.
                              9. 3.14Institutions should use Multi-Factor Authentication when a Customer initially accesses an online service that uses APIs, to provide secure access to the account.
                              10. 3.15Institutions should consider using Multi-Factor Authentication when a customer uses an API to access, process or transmit Personal Data. Multi-Factor Authentication may also be considered for the initiation or processing of transactions.
                              11. 3.16Institutions should ensure that they create clear access control policies that separate administrators and regular users and that accurately reflect the hierarchies, groups, and roles within the organisation. Institutions should review their internal hierarchies, groups, and roles to ensure that there are no gaps in the roles that could lead to unauthorized access to the APIs.
                              12. 3.17Institutions should ensure that APIs are designed to impose restrictions on the size or number of resources that can be requested by the user to prevent Denial of Service (DoS) attacks.
                              13. 3.18An independent function or external expert with adequate skills and knowledge should conduct vulnerability assessments and penetration tests on the Institution’s and the API Provider’s systems and infrastructure to identify weaknesses or flaws in the security processes at least on an annual basis.

                            • Standardisation

                              1. 3.19Institutions should consider the adoption of standardised APIs that are issued either by Supervisory Authorities or the industry. Standardised APIs can, among other matters, include the following:
                                1. a.API design standards: Adopting a uniform API design model and language across the relevant financial services industry based on a broad range of design considerations;
                                2. b.Data standards: Adopting international Data standards that define the semantics and syntax of Data being transmitted using APIs, based on the type of Data being transacted and the use case, to promote interoperability; and
                                3. c.Information security standards: Adopting international information security standards to ensure information is securely transmitted through APIs.

                            • Management

                              1. 3.20Institutions should consider establishing an API monitoring framework that addresses infrastructure, technology and security related incidents and events in a timely and effective manner. The monitoring framework should:
                                1. a.Define what constitutes an incident/event, such as unusual activity or unauthorised changes;
                                2. b.Monitor the use of APIs to rapidly and accurately detect incidents and events;
                                3. c.Report incidents and events to decision makers in a timely manner commensurate with their severity; and
                                4. d.Remediate the impact of the incidents and events in an effective manner.
                              2. 3.21Larger Institutions with important API adoption should consider establishing a security operations centre dedicated to monitoring, assessing and defending IT systems and assets such as APIs, web sites, applications, Data servers, networks, hardware and software.
                              3. 3.22Institutions should maintain an audit trail that records the appropriate metrics and security-related behavior of each API and records any breaches of security that occur. The audit trail should capture the metrics and behavior before and after such breaches to support future detection of breaches of security.
                              4. 3.23Institutions should establish incident handling procedures to swiftly detect, review, report and rectify any incidents. Institutions should only provide the necessary details of any incident when reporting incidents to the public to avoid providing attack vectors for bad actors.

                          • Cloud Computing

                            • Article (16) Obligations relating to Data Sharing

                              1.  The Data Sharing obligations under Article 16 of this Regulation apply only in relation to User Data.
                              2. Subject to provision of the User’s consent in accordance with Article 22 of this Regulation, where a User uses Data Sharing provided by a Data Service Provider to consolidate information relating to the User Data of that User, the Data Holder must:
                              2.1communicate the information relating to the User Data in accordance with the request received;
                              2.2treat a request for information relating to the User Data in the same way as a request solely received directly from the User; and
                              2.3communicate securely with the Data Sharing Provider in accordance with this Regulation and other applicable Regulations and requirements of the Open Finance Framework.
                              1. A Data Sharing Provider must:
                              3.1only provide Data Sharing in accordance with the User's explicit consent and instructions;
                              3.2not Process any User Data that is Sensitive Data for the provision of Data Sharing, even with the explicit consent of the User;
                              3.3 ensure that the User's personalised security credentials, such as Personal Identification Numbers (PIN) and/or passwords, are:
                               3.3.1not accessible to other parties, with the exception of the issuer of the credentials; and
                               3.3.2transmitted through secure and efficient channels.
                              1. The Data Sharing Provider must identify itself to and communicate securely with the Data Holder and the User.
                              2. The Data Sharing Provider must not use, access or store any information for any purpose except for the provision of the Data Sharing services explicitly requested by the User, except where necessary to comply with any applicable law of the State.

                              • Materiality

                                1. 3.24A Cloud Computing arrangement is considered material when a disruption in service or breach of security or confidentiality of systems and/or Data may have the potential to materially impact:
                                  1. a.The Institution’s business operations;
                                  2. b.The Institution’s ability to manage risks;
                                  3. c.The Institution’s ability to comply with applicable laws and regulations; or
                                  4. d.The confidentiality or integrity of an Institution’s or Customer’s Personal Data (i.e. if the arrangement may lead to unauthorized access, disclosure, loss or theft of Personal Data).
                                2. 3.25Institutions should conduct an assessment to determine the materiality and the associated risks of a Cloud Computing arrangement. When conducting such an assessment, Institutions should consider:
                                  1. a.The criticality and inherent risk profile of the Cloud Computing arrangement i.e. activities that are critical to the business continuity/viability of the Institution and its obligations to Customers;
                                  2. b.The impact and likelihood of a service failure, security breach or other event on an Institution’s business operations or reputation;
                                  3. c.The impact and likelihood of a confidentiality breach, loss or theft of Customer Data or breach of Data integrity of the Institution and its Customers; and
                                  4. d.The cost and other resources to support a Cloud Computing arrangement.
                                3. 3.26Institutions should engage the relevant Supervisory Authority of any material Cloud Computing plans in order to address any concerns and expectations early in the design process before implementing any material Cloud Computing arrangement. This approach must comply with existing outsourcing requirements set by the relevant Supervisory Authority, including, where appropriate, the need to seek approval for material Cloud Computing plans.

                              • Governance

                                1. 3.27Institutions considering the use of Cloud Computing should define a clear strategy and architectural roadmap which covers the target IT environment, the transition from the current environment to the target and the operating model, including any organisational change or additional skillsets that maybe necessary.
                                2. 3.28Institutions should establish an approved and documented governance framework for effective decision-making and proper management and control of risks arising from the use of Cloud Computing and Outsourcing of Cloud Computing to Outsourcing Service Providers. The governance framework should:
                                  1. a.Define the roles and responsibilities for the operation and management of the Cloud Computing arrangement, security controls and risk management controls. Where an Outsourcing Service Provider is involved, the division of roles and responsibility between the Institution and the Outsourcing Service Provider should be clearly defined;
                                  2. b.Define the process to conduct a risk-based analysis to identify and classify the IT Assets involved in or deployed by the Cloud Computing arrangement based on criticality and confidentiality;
                                  3. c.Require the maintenance and updating of the log of IT Assets in the cloud environment including their ownership;
                                  4. d.Establish appropriate policies, procedures, and controls to govern the use of Cloud Computing covering risk management, due diligence on the Outsourcing Service Providers and access, confidentiality, integrity, and recoverability of IT Assets outsourced; and
                                  5. e.Set out the steps for management and review of the contract between the Institution and the Outsourcing Service Provider, where Cloud Computing services are outsourced.
                                3. 3.29Senior Management of the Institution should be responsible for the assessment, understanding and monitoring of the Institution’s reliance on Outsourcing Service Providers for material Cloud Computing services.
                                4. 3.30Institutions should maintain up-to-date and accurate documentation pertaining to the Cloud Computing arrangement for review, audit, supervision, and other purposes, including but not limited to:
                                  1. a.Rationale and an appropriate strategy for implementing the Cloud Computing arrangement;
                                  2. b.Materiality and risk assessment and conclusion;
                                  3. c.Outsourcing risk assessment, other initial security-related risk assessments and their conclusions (further guidance on assessments provided in subsection “Outsourcing”);
                                  4. d.Due diligence or suitability assessments conducted on the Outsourcing Service Provider and conclusions;
                                  5. e.Description of the Cloud Computing arrangement including but not limited to:
                                    1.  i.Name of Outsourcing Service Provider and any sub-contractors;
                                    2.  ii.Level of reliance on Outsourcing Service Providers;
                                    3. iii.Type of Cloud Computing service models (i.e. Software as a service - SaaS, Infrastructure as a service - IaaS etc.) and deployment models used (i.e. private, public etc.);
                                    4. iv.IT Assets in scope including their criticality and ownership;
                                    5.  v.Services/products selected;
                                    6. vi.Parties involved; and
                                    7. vii.Delivery locations.
                                  6. f.Contract and other legal documentation pertaining to the arrangement with the Outsourcing Service Provider (further guidance provided in subsection “Outsourcing”).

                              • Outsourcing

                                1. 3.31Prior to engaging an Outsourcing Service Provider to provide Cloud Computing services, Institutions should perform a comprehensive Outsourcing risk assessment covering:
                                  1. a.The role and materiality of the service to be outsourced in the Institution’s business operations;
                                  2. b.Due diligence on prospective Outsourcing Service Providers (further guidance on the due diligence process provided in Clause Institutions should verify the maturity, adequacy and appropriateness of the prospective Outsourcing Service Provider and services selected, taking into account the intended usage of the Cloud Computing service. Institutions should consider the following specific factors when conducting due diligence on Outsourcing Service Providers providing Cloud Computing services, including but not limited to:); and
                                  3. c.Assessing the benefits of the Outsourcing arrangement against the risks.
                                2. 3.32Institutions should verify the maturity, adequacy and appropriateness of the prospective Outsourcing Service Provider and services selected, taking into account the intended usage of the Cloud Computing service. Institutions should consider the following specific factors when conducting due diligence on Outsourcing Service Providers providing Cloud Computing services, including but not limited to:
                                  1. a.Materiality: The results of the materiality assessment. The depth of the due diligence undertaken and risk mitigating controls established should be commensurate with the materiality of the Cloud Computing arrangement and the level of reliance the Institution places on the provider to maintain effective security controls;
                                  2. b.Due diligence scope: The scope of the due diligence assessment should be appropriate and cover an adequate set of controls and individual assessments of all locations expected to be relevant in the arrangement. In particular, the Institution should consider the track record of the Outsourcing Service Provider in achieving acceptable outcomes in areas such as information security policies and awareness, due diligence and risk assessment of practices related to sub-contracting, system vulnerability assessments, penetration testing, and technology refresh management;
                                  3. c.Data centers: Evaluation of whether the data centers are located in countries that the Institution deems suitable and acceptable to store and process Data (further guidance outlined in the subsection “Design”);
                                  4. d.Controls: Institutions should ensure that Outsourcing Service Providers implement strong authentication, access controls, Data encryption and other security and technical controls (further guidance outlined in the subsections “Design” and “Management and monitoring”) to meet the Institutions’ requirements. Controls implemented by Outsourcing Service Providers should be at least as strong as those which the Institutions would have implemented had the operations been performed in-house;
                                  5. e.Security risk assessments: Prior to implementing Cloud Computing services and undertaking an Outsourcing arrangement, Institutions should conduct an initial security and risk assessment of the service to identify any information security, cybersecurity and other IT control weaknesses. The risk assessment will identify security threats including information security threats and operational weaknesses and develop safeguards to mitigate those threats and weaknesses. The factors considered during the risk assessment should include but not be limited to:
                                    1.  i.Nature of the service (including specific underlying arrangements);
                                    2.  ii.Provider and the location of the service;
                                    3. iii.Criticality and confidentiality of the IT Assets involved;
                                    4. iv.Transition process including handover from the Institution and/or other service providers to the potential Outsourcing Service Provider;
                                    5.  v.Target operating model; and
                                    6. vi.Adherence to recognised technical security standards.
                                    7. vii.Compliance with standards and external assurance: The Outsourcing Service Provider’s adherence to international standards as relevant to the provision of services (for e.g. ISO/EIC etc.). Institutions may take into consideration any external assurance that has already been provided by independent auditors when conducting their own due diligence.
                                3. 3.33When conducting risk assessments of Cloud Computing services, Institutions should consider key risks including but not limited to:
                                  1. a.Cybersecurity risk;
                                  2. b.Operational risks, specifically information security, Outsourcing and business continuity risk. In particular, Institutions in an outsourced Cloud Computing arrangement should consider the impact of the Outsourcing arrangement on the Institution’s risk profile i.e. the potential heightened operational, legal, compliance, reputational, concentration and other risks associated with the arrangement;
                                  3. c.Reputational risk; and
                                  4. d.Specific risks arising from the design and operating model of the Cloud Computing arrangement.
                                4. 3.34Institutions should ensure that the written contract governing the Cloud Computing arrangement between the Institution and Outsourcing Service Provider covers the following issues including, but not limited to:
                                  1. a.The roles, relationships, obligations and responsibilities of all contracting parties;
                                  2. b.Location of the data centres;
                                  3. c.Ownership and control over IT Assets, if the Outsourcing Service Provider is expected to be given some level of control over IT Assets;
                                  4. d.Liability in the event of losses or breaches in security or confidentiality;
                                  5. e.Measures to protect the Institution’s Data and confidential information and limits to disclosure of such information;
                                  6. f.Data recovery and access to Data used for daily operational purposes as well as for contingency, disaster recovery or backups;
                                  7. g.Advance notice to the Institutions regarding any changes to data centre locations;
                                  8. h.Access to information held by the Institution;
                                  9. i.The right to monitor, review and audit Cloud Computing arrangements by the Institution’s internal control functions, and regulators, or persons employed by them, including for the purposes of supervisory reviews by the respective Supervisory Authority;
                                  10. j.With respect to Outsourcing Service Providers use of sub-contracting arrangements:
                                    1.  i.Disclosure of all material and service-related sub-contracting arrangements;
                                    2.  ii.Advance notification of any new sub-contracting arrangements or changes to existing arrangements by the Outsourcing Service Provider;
                                    3. iii.Outsourcing Service Provider’s accountability to the Institution for the provision of service and effectiveness of agreed controls;
                                    4. iv.Outsourcing Service Provider’s contractual liability for the performance and risk management of any sub-contractor(s) it employs and, where this is the case, the full compliance of the sub-contractor(s) with the obligations existing between the Institution and Outsourcing Service Provider.
                                  11. k.Scenarios or events in which Institutions have the right to terminate the contractual agreement, such as where new or modifications to existing sub-contracting arrangements have an adverse effect on the Institution’s security or risk assessment of the Cloud Computing arrangement; and
                                  12. l.The exit plan and process to be followed in the event of termination of the Cloud Computing arrangement including, but not limited to:
                                    1.  i.A reasonable transition period;
                                    2.  ii.Procedures for returning Data to the Institution;
                                    3. iii.Permanent Data deletion by the Outsourcing Service Provider; and
                                    4. iv.Any arrangements to transfer the outsourced service to another Outsourcing Service Provider or reincorporate it into the Institution with sufficient handover and support from the previous Outsourcing Service Provider.
                                5. 3.35Institutions should understand their roles and those of the Outsourcing Service Provider providing Cloud Computing services. Roles and owners should be defined and agreed upon as part of the shared responsibility model which should specifically cover roles with respect to cybersecurity, information security and related controls.
                                6. 3.36Where a material Outsourcing arrangement involves the transfer of Data, Institutions should:
                                  1. a.Classify Data based on criticality and confidentiality;
                                  2. b.Identify potential risks relating to outsourced Data and their impact; and
                                  3. c.Agree on an appropriate level of confidentiality, integrity, and availability.

                              • Design

                                1. 3.37Institutions should ensure that the design and architectural aspects of the Cloud Computing services, or arrangement are optimised to cater to the needs of the Institution, adhere to the Institution’s internal policies and procedures and minimise risks.
                                2. 3.38Institutions and Outsourcing Service Providers should consider the following principles when developing the design and architecture of the Cloud Computing arrangement:
                                  1. a.Availability: To reduce the likelihood of IT Assets becoming unavailable in the event of failure of individual components and improve the ability for users to request and use IT Assets;
                                  2. b.Resilience: To improve resilience through implementation of security controls, implementation of regular testing and checks to detect security and service issues, and use of multiple data centres distributed across multiple locations, or where appropriate, use of multiple Outsourcing Service Providers to provide Cloud Computing services;
                                  3. c.Recoverability: To allow for swift and effective recovery and restoration of IT Assets to a specified level of service in the event of a compromise of integrity or availability;
                                  4. d.Capacity: To ensure the Cloud Computing arrangement’s capacity is commensurate with the Institution’s needs; and
                                  5. e.Encapsulation: To ensure re-usability of network and system components.
                                3. 3.39Institutions should carefully determine and choose the type of cloud(s) deployed based on an assessment of the business operations performed on the cloud(s) and the risks associated with each type of cloud.
                                4. 3.40Institutions should evaluate and assess the location of data centres while determining the design of the Cloud Computing arrangement to select data centres appropriate to the Institution’s needs. The assessment should address the location’s:
                                  1. a.Potential risks, including information security, legal and compliance risks;
                                  2. b.Wider political and security issues; and
                                  3. c.Legislation and legal framework including law enforcement and insolvency law provisions that would apply in the event of an Outsourcing Service Provider’s failure.
                                5. 3.41Institutions should implement appropriate and effective network access and security controls such as firewalls, Intrusion Prevention System, advanced threat protection and web proxy so that other on-premise environments are not exposed to unauthorized access from the cloud.
                                6. 3.42Institutions should define a standard set of tools and processes to manage containers, images and release management and ensure consideration of any risks posed by shared virtual environments or Data co-mingling.
                                7. 3.43Institutions should implement preventative and detective Data controls to keep Data secure and prevent Data loss. Institutions should ensure that the Data controls including those outlined in this section cover all Data, whether it is Data in storage, Data in transmission (i.e. Data that is actively moving from one location to another) or Data in use.
                                8. 3.44Institutions should ensure that Data processed or stored through the Cloud Computing arrangement are recoverable within a pre-defined timeframe and appropriate and secure backups of Data are maintained.
                                9. 3.45Where the Cloud Computing arrangement is using a multi-tenancy environment or Data comingling arrangement, Institutions should ensure its Data and information is segregated and the Outsourcing Service Provider is able to protect the confidentiality and integrity of the Data and information.
                                10. 3.46Institutions should introduce controls to prevent unauthorised access to Data and permit access to IT Assets only when appropriate.
                                11. 3.47Institutions should establish security controls to protect against attacks (e.g. network intrusion attempts, DoS attacks) including cloud specific attacks.
                                12. 3.48Institutions should introduce cryptographic key management to control access to, segregate and secure Customer’s Data.
                                13. 3.49Institutions should utilise encryption or tokenisation to protect confidentiality of Personal Data, such as authentication credentials and emails etc., being processed, or in transit including Data in Data back-ups.
                                14. 3.50Institutions should introduce user identity and access management and authentication (including Multi-Factor Authentication) to provide controlled access to information systems allowing Staff and Outsourcing Service Providers to perform their business activities, while protecting Data and systems from unauthorised access.
                                15. 3.51Institutions should ensure that user access and activities are logged and reviewed on an “as needed” basis.
                                16. 3.52Institutions should develop controls to ensure confidentiality and integrity of source codes and prevent alteration of source codes and system configurations (particularly when the Institution uses models such as DevOps).
                                17. 3.53Institutions should conduct vulnerability assessments and penetration tests specific to the Cloud Computing arrangement to identify weaknesses or flaws in the security processes.

                              • Management and Monitoring

                                1. 3.54Institutions should establish change management processes to ensure any changes in the Cloud Computing arrangement by the Institution or the Outsourcing Service Provider are appropriately governed and implemented.
                                2. 3.55Institutions should ensure that they define the conditions and scenarios in which automated testing and releases can take place for changes to their Cloud Computing arrangements, and that there is a full audit trail, record of the changes and evidence of pre-approval.
                                3. 3.56Institutions should develop a mechanism by which they are notified of material changes to the Cloud Computing arrangement in a timely manner.
                                4. 3.57Institutions should develop a configuration management process which includes regular monitoring to detect unauthorised changes to the cloud environment and ensure such changes can be appropriately remediated.
                                5. 3.58Institutions should ensure that the Cloud Computing arrangement has the capacity to run the Institution’s workloads. Institutions should regularly monitor utilisation and proactively plan for upgrades or enhancements based on anticipated spikes in workloads or resulting from strategic business initiatives.
                                6. 3.59Institutions should establish a monitoring framework to define, monitor, report and remediate key infrastructure, technology and security related incidents and events in the cloud environment in a timely and effective manner to minimise detriment. The framework should:
                                  1. a.Cover incidents and events that may impact the stability or availability of the Institution’s applications, networks and systems or the confidentiality or integrity of cloud environments;
                                  2. b.Be centralised to promote clarity of process and enable consolidation and analysis of threat intelligence, incident and event related Data;
                                  3. c.Manage incidents and events according to their frequency, criticality and assigned ownership;
                                  4. d.Identify, monitor and manage systemic issues;
                                  5. e.Monitor and identify vulnerabilities, incidents, and events on an on-going basis by:
                                    1.  i.Defining a standard set of health and performance metrics;
                                    2.  ii.Utilising analytics and Data from previous security incidents and events to enable retrospective detection;
                                  6. f.Categorise and record Data associated with incidents and events;
                                  7. g.Report and escalate incidents and events to relevant stakeholders for notification or action; and
                                  8. h.Ensure that incidents and events are properly reviewed and identified gaps are remediated to prevent a reoccurrence.
                                7. 3.60Institutions should be able to swiftly and safely:
                                  1. a.Detect vulnerabilities in the software used in the cloud environment; and
                                  2. b.Deploy security and operating system patches.
                                8. 3.61After implementation of the Cloud Computing arrangement, Institutions should re-assess the risks associated with the Cloud Computing arrangement when there is a material change to existing arrangements and on a regular basis through ongoing:
                                  1. a.Outsourcing risk assessments to assess adequacy of controls in managing the risks arising from the Outsourcing arrangement; and
                                  2. b.Security and risk assessments to assess the adequacy of the security and risk controls in managing the risks arising from Cloud Computing. These should include conducting vulnerability assessments and penetration tests specific to the Cloud Computing arrangement on at least an annual basis.
                                9. 3.62Institutions should establish risk mitigation controls to address any shortcomings of the Cloud Computing arrangement. The degree of risk should inform the stringency of controls and mitigation procedures implemented.

                              • Business Continuity

                                1. 3.63Institutions’ business continuity management functions and crisis management teams should develop and implement a business continuity plan for material Cloud Computing arrangements. If Cloud Computing arrangements are outsourced, the Outsourcing Service Provider should have a business continuity plan in place that is acceptable to the Institution.
                                2. 3.64Institutions should define key risk indicators, performance metrics and adverse conditions that can trigger the business continuity plan for the Cloud Computing arrangement during its on-going monitoring and oversight of any services provided by the Outsourcing Service Provider.
                                3. 3.65As part of an Institution’s own business continuity planning for Cloud Computing services, it should tailor the plan to:
                                  1. a.Account for any dependency on one Outsourcing Service Provider;
                                  2. b.Define the division of roles and responsibilities;
                                  3. c.Define recovery objectives;
                                  4. d.Identify alternative solutions/develop transition plans; and
                                  5. e.Test their business continuity plans for their Cloud Computing arrangement (jointly with the Outsourcing Service Provider if the Cloud Computing arrangement is outsourced) on at least an annual basis.

                              • Exit and Resolution Planning

                                1. 3.66Institutions should consider the possibility of a stressed exit wherein an event of disruption cannot be managed through business continuity measures.
                                2. 3.67Institutions should define and maintain specific exit plans for their outsourced Cloud Computing arrangements, taking into account, developments (such as new technology) that may change the feasibility of an exit in stressed and non-stressed scenarios.
                                3. 3.68Institutions should account for outsourced Cloud Computing arrangements when developing resolution plans or strategies to identify and address any impediments to its resolvability and to prepare for its possible resolution.
                                4. 3.69Institutions should establish procedures for Data recovery by the Institution and permanent Data deletion by the Outsourcing Service Provider in the event of a termination of services.

                            • Biometrics

                              • Article (17) Obligations relating to Service Initiation

                                 

                                1.The obligations under Article 17 of this Regulation relating to Service Initiation apply only in relation to relevant Accounts and Products.
                                2.Where a User gives explicit consent for a Transaction to be Initiated through a Service Initiation Provider, the Service Owner must:
                                  2.1communicate securely with the Service Initiation Provider in accordance with the Regulations and requirements of the Open Finance Framework;
                                  2.2immediately after receipt of the instruction to Initiate a Transaction for the User, provide or make available to the Service Initiation Provider all information required for the initiation of the Transaction, and subsequently display the status of the Transaction to the User, until its completion; and
                                  2.3treat the instruction to Initiate the Transaction in the same way as an instruction solely received directly from the User.
                                3.A Service Initiation Provider must:
                                  3.1only provide Service Initiation in accordance with the User's explicit consent and instructions;
                                  3.2ensure that the User's personalised security credentials, such as PIN and/or passwords, are:
                                    3.2.1not accessible to other parties, with the exception of the issuer of the credentials; and
                                    3.2.2transmitted through secure and efficient channels.
                                4.Each time it Initiates a Transaction, the Service Initiation Provider must identify itself to the Service Owner and communicate securely with the Service Owner.
                                5.In providing its services the Service Initiation Provider must not use, access or store any information for any purpose except for the provision of the services explicitly requested by the User, except where necessary to comply with any applicable law of the State.

                                 

                                • Governance

                                  1. 3.70Institutions should ensure compliance with the relevant legislation and regulations in relation to Data protection.
                                  2. 3.71When Outsourcing to an Outsourcing Service Provider, Institutions should ensure that access to information is adequately controlled, monitored, reviewed, and audited by the Institution’s internal control functions, and regulators, or persons employed by them, including supervisory reviews by the respective Supervisory Authority.

                                • Identity Proofing and Enrolment Management

                                  1. 3.72Institutions using Biometric Applications should ensure effective proofing of identities, including validation and verification of identities. Validation involves determining that the documentary evidence for the Biometric identity is genuine, reliable, and independent. Verification involves confirming the validated identity relates to the individual being proofed.
                                  2. 3.73Institutions should obtain and store evidence of any digital identity verification (e.g., via chip or wireless technologies) performed by integrated scanners, sensors and other devices.

                                • Ongoing Authentication and Identity Lifecycle Management

                                  1. 3.74Institutions should establish controls and processes to protect Customers and their credentials against vulnerabilities and unauthorized access, disclosure or use in the authentication process and throughout the Identity Lifecycle.
                                  2. 3.75Institutions deploying Multi-Factor Authentication at login that includes a Biometric factor should consider employing phishing-resistant authenticators where at least one factor relies on public key encryption to secure the Customer authentication process.
                                  3. 3.76Institutions should implement risk-based or adaptive authentication measures that present Customers with authentication options commensurate with the risk level of the transaction and sensitivity of the information.
                                  4. 3.77Institutions should implement Multi-Factor Authentication using a Biometric factor, where possible, to authorize high risk activities and protect the integrity of Customer account Data and transaction details. High-risk activities include changes to Personal Data (e.g. Customer office and home address, email and telephone contact details), registration of Third-Party payee details, high value funds transfers and revision of funds transfer limits.
                                  5. 3.78For Biometric authentication of transactions, Institutions should adopt security measures to ensure the confidentiality, authenticity and integrity of authentication codes, Personal Data and transaction specific information.

                                • Management and Monitoring

                                  1. 3.79Institutions should periodically monitor their Biometric Applications throughout the Identity Lifecycle to assess performance, detect security-related events, evaluate the adequacy of controls, and take any remedial action.
                                  2. 3.80Institutions should ensure that all communications with individuals involving Biometric Data across the Identity Lifecycle occur over a mutually authenticated and protected channel.
                                  3. 3.81Institutions should ensure the employment of physical tamper detection and resistance features appropriate for the environment in which the identity-proofing session occurs.
                                  4. 3.82Across the Identity Lifecycle, Institutions should introduce processes and controls to safeguard against Data tampering, cyberattacks, security breaches and other fraudulent activities which may lead to identity theft, compromise or misuse of Data and errors.
                                  5. 3.83Institutions should monitor and evaluate all the processes involved in the Identity Lifecycle including identity proofing, authentication etc. to ensure that they are secure and efficient.
                                  6. 3.84As a Credential Service Provider may be an independent Third Party or may issue credentials for its own use, Institutions should ensure that they perform the requisite due diligence checks and protocols on the Credential Service Provider on a regular basis.
                                  7. 3.85Institutions should monitor the performance of the Biometrics Application for inherent risks such as false acceptance rates and false rejection rates. Poorly executed algorithms may result in higher false acceptance rates and these inherent risks should be calibrated to be commensurate with the risks associated with the Biometric Application.

                                • Data Management

                                  1. 3.86Institutions should ensure the security, confidentiality, authenticity and integrity of Data across all phases of authentication, whether the Data is in use, storage or transmission.
                                  2. 3.87Institutions should maintain a clear trail and record of the Biometric Application’s Data obtained from the Credential Service Providers.
                                  3. 3.88Institutions should consider the principles of portability and interoperability when planning and implementing systems and databases for the Biometric Application.
                                  4. 3.89Where Biometric Applications are used for Biometric authentication, Institutions should ensure Biometric Data and authentication credentials, whether in use, storage or transmission, are encrypted.

                                • Outsourcing

                                  1. 3.90If Biometric activities are outsourced, Institutions should ensure that:
                                    1. a.They obtain the necessary Data concerning Biometric identification/verification from the Outsourcing Service Providers and take adequate steps to satisfy themselves that copies of identification Data and other relevant documentation will be made available from the Outsourcing Service Providers upon request and without delay; and
                                    2. b.The Outsourcing Service Provider complies with the Institution’s Customer due diligence and record-keeping requirements.

                              • Big Data Analytics and Artificial Intelligence (AI)

                                • Materiality

                                  1. 3.92Institutions should assess their Big Data Analytics and AI Applications to determine the materiality and associated risks of each Application.
                                  2. 3.93When conducting a materiality assessment of a Big Data Analytics and AI Application, Institutions should consider:
                                    1. a.The purpose of the Big Data Analytics and AI Application (i.e. use case) and its role in the Institution’s decision-making process;
                                    2. b.The criticality and inherent risk profile of the activities (i.e. are they activities that are critical to the business continuity/viability of the Institution and its obligations to Customers); and
                                    3. c.The likelihood that the activity may be disrupted and the impact of any such disruption.

                                • Governance

                                  1. 3.94Institutions should establish an approved and documented governance framework for effective decision-making and proper management and control of risks arising from the use of Big Data Analytics and AI. The governance framework should:
                                    1. a.Establish a mechanism to ensure that Institutions are required to assess whether the Application is suitable for Big Data Analytics and AI implementation and define specific parameters and criteria to enable the Institution in its decision-making;
                                    2. b.Establish appropriate policies, procedures and controls to govern the design, development, monitoring, review and use of Big Data Analytics and AI Applications within the Institution;
                                    3. c.Ensure proper validation of Big Data Analytics and AI Applications prior to their launch, and thereafter implement on-going training, calibration and review to ensure the reliability, fairness, accuracy and relevance of the algorithms, models and Data used and the results;
                                    4. d.Maintain a transparent, enterprise-wide record of Big Data Analytics and AI Applications and their underlying mechanics;
                                    5. e.Establish processes to assess, monitor, report and mitigate risks associated with the Big Data Analytics and AI Application;
                                    6. f.Ensure that material decisions regarding Big Data Analytics and AI Applications and their underlying models and Data are documented and sufficiently justified; and
                                    7. g.Cover every stage of the model lifecycle including design, development, deployment, review, update and discontinuation.
                                  2. 3.95The Governing Body and Senior Management of the Institution should be accountable for the outcomes and decisions arising from the use of Big Data Analytics and AI Applications, including those Applications that make decisions on behalf of the Institution. They should:
                                    1. a.Ensure that all Staff working on or using Big Data Analytics and AI Applications are assigned appropriate accountability for their involvement with Big Data Analytics and AI Applications and understand what they should to do meet this accountability; and
                                    2. b.Ensure that technical specialists with appropriate technology skillsets (e.g. Big Data analysts, Artificial Intelligence engineers and specialists) and Application specific skillsets (e.g. credit risk modelling specialists if the Application is a credit scoring model) form part of the team actively involved in developing and implementing Big Data Analytics and AI Applications.
                                  3. 3.96When Outsourcing to an Outsourcing Service Provider, Institutions should ensure that access to information is adequately controlled, monitored, reviewed, and audited by the Institution’s internal control functions, and regulators, or persons employed by them, including supervisory reviews by the respective Supervisory Authority.
                                  4. 3.97Big Data Analytics and AI Applications, including when the model is developed by an Outsourcing Service Provider, should be auditable and, accordingly, Institutions, where relevant and considering the type of application used, should maintain on-going and up-to-date information through:
                                    1. a.Establishing audit logs and maintaining traceability of decisions and outcomes of the Big Data Analytics and AI Application;
                                    2. b.Developing and maintaining design documentation (further guidance provided in Clause Institutions should maintain documentation outlining the design of the material Big Data Analytics and AI model including but not limited to, where applicable:);
                                    3. c.Maintaining records of the various versions of the model including its code (further guidance provided in Clause Institutions should establish a robust system for versioning and maintain record of each version of the material Big Data Analytics and AI model including but not limited to, where applicable:);
                                    4. d.Archiving original Datasets used to develop, re-train or calibrate models;
                                    5. e.Tracking outcomes and performance of the Big Data Analytics and AI Application; and
                                    6. f.Retaining above information for a minimum period of five (5) years, or as otherwise prescribed by applicable laws and regulations.

                                • Design

                                  1. 3.98Institutions should ensure that the models for their Big Data Analytics and AI Applications are reliable, transparent, and explainable, commensurate with the materiality of those Applications. Accordingly, Institutions, where appropriate, should consider:
                                    1. a.Reliability: Implementing measures to ensure material Big Data Analytics and AI Applications are reliable and accurate, behave predictably, and operate within the boundaries of applicable rules and regulations, including any laws on data protection or cyber security;
                                    2. b.Transparency: Institutions should be transparent in how they use Big Data Analytics and AI in their business processes, and (where reasonably appropriate) how the Big Data Analytics and AI Applications function; and
                                    3. c.Technical Clarity: Implementing measures to ensure the technical processes and decisions of a Big Data Analytics and AI model can be easily interpreted and explained to avoid the threat of “black-box” models. The level of technical clarity should be appropriate and commensurate with the purpose and materiality of the Big Data Analytics and AI Application (e.g. where the model results have significant implications on decision making).
                                  2. 3.99Institutions should adopt an effective Data governance framework to ensure that Data used by the material Big Data Analytics and AI model is accurate, complete, consistent, secure, and provided in a timely manner for the Big Data Analytics and AI Application to function as designed. The framework should document the extent to which the Data meets the Institution’s requirements for data quality, gaps in data quality that may exist and steps the Institution will take, where possible, to resolve these gaps over time.
                                  3. 3.100Institutions should make regular efforts to ensure data used to train the material Big Data Analytics and AI model is representative (i.e. how relevant the Data and inferences drawn from the Data are to the Big Data Analytics and AI Application) and produces predictable, reliable outcomes that meet objectives.
                                  4. 3.101Institutions should be able to promptly suspend material Big Data Analytics and AI Applications upon the Institution’s discretion such as in the event of a high cyber threat, information security breach or malfunctioning of the model.
                                  5. 3.102Institutions should, where relevant, conduct rigorous, independent validation and testing of material trained Big Data Analytics and AI models to ensure the accuracy, appropriateness, and reliability of the models prior to deployment. Institutions should ensure the model is reviewed to identify any unintuitive or false causal relationships. The validation may be carried out by an independent function within the Institution or by an external organisation.
                                  6. 3.103Institutions should maintain documentation outlining the design of the material Big Data Analytics and AI model including but not limited to, where applicable:
                                    1. a.The input Data source and Data description (types and use of Data);
                                    2. b.The Data quality checks and Data transformations conducted;
                                    3. c.Reasons and justifications for specific model design and development choices;
                                    4. d.Methodology or numerical analyses and calculations conducted;
                                    5. e.Results and expected outcomes;
                                    6. f.Quantitative evaluation and testing metrics used to determine soundness of the model and its results;
                                    7. g.Model usage and implementation;
                                    8. h.Form and frequency of model validation, monitoring and review; and
                                    9. i.Assumptions or limitations of the model with justifications.
                                  7. 3.104Institutions should introduce controls to ensure confidentiality and integrity of the codes used in the material Big Data Analytics and AI Application so that the code is only accessed and altered by authorized persons.
                                  8. 3.105Institutions should identify and monitor the unique risks arising from use of the material Big Data Analytics and AI Application and establish appropriate controls to mitigate those risks.

                                • Management and Monitoring

                                  1. 3.106Institutions should establish an approved and documented framework to review the reliability, fairness, accuracy and relevance of the algorithms, models and Data used prior to deployment of a material Big Data Analytics and AI Application and on a periodic basis after deployment, to verify that the models are behaving as designed and intended. The framework should cover, where relevant:
                                    1. a.The various types and frequencies of reviews including continuous monitoring, re-training, calibration and validation;
                                    1. b)Scenarios and criteria that would trigger a re-training, calibration, re-development or discontinuation of the model such as a significant change in input Data or external/economic changes;
                                    1. a.Review of material Big Data Analytics and AI model outcomes for fairness or unintentional bias (e.g. through monitoring and analysis of false positive and/or false negative rates); and
                                    2. b.Review of continuity or contingency measures such as human intervention or the use of conventional processes (i.e. that do not use Big Data Analytics and AI).
                                  2. 3.107When the use of a material Big Data Analytics and AI model results in a technical or model-related error or failure, Institutions should:
                                    1. a.Be able to swiftly detect the error;
                                    2. b.Establish a process to review the error and rectify it in a timely manner, which may include notifying another function; and
                                    3. c.Report the error to relevant stakeholders if material.
                                  3. 3.108Institutions should establish a robust system for versioning and maintain record of each version of the material Big Data Analytics and AI model including but not limited to, where applicable:
                                    1. a.New Data used;
                                    2. b.Revisions to the documentation;
                                    3. c.Revisions to the algorithm;
                                    4. d.Change in the way variables are picked and used in the model or, where possible, the names of variables; and
                                    5. e.The expected outcome of the newly calibrated, re-trained or re-developed model.

                                • Ethics

                                  1. 3.109Institutions should ensure that their Big Data Analytics and AI Applications promote fair treatment, produce objective, consistent, ethical, and fair outcomes, and also, are aligned with Institutions’ ethical standards, value and codes of conduct. Accordingly, they should:
                                    1. a.Comply with laws against discrimination and other applicable laws;
                                    2. b.Be produced using representative inputs and Data which have been tested for selection bias (further guidance provided in Clause 3.100);
                                    3. c.Consider whether a human-in-the-loop mechanism is needed to detect and mitigate biases;
                                    4. d.Retain the possibility of manual intervention to mitigate or reverse irresponsible and erroneous decisions;
                                    5. e.Retain the possibility of modification by the Institution; and
                                    6. f.Be explainable.
                                  2. 3.110Institutions should consider the fairness of a Big Data Analytics and AI model through understanding the biases and noise affecting Big Data Analytics and AI decisions. Institutions should define what it means for a Big Data Analytics and AI model to be fair.
                                  3. 3.111Institutions should consider and assess the impact that Big Data Analytics and AI models may have on individuals or groups of individuals to ensure that such individuals or groups are not systematically disadvantaged unless the decisions suggested by the models have a clearly documented justification. Institutions should take steps to minimize unintentional or undeclared bias.

                                • Customer Protection

                                  1. 3.112Institutions should be transparent with Customers about their use of Big Data Analytics and AI through their conduct and through accurate, understandable, and accessible plain language disclosure. Institutions should:
                                    1. a.Ensure that Customers are informed of products and/or services that utilise Big Data Analytics and AI and the associated risks and limitations of the technology, prior to providing the service or each time Customers interact with the service (e.g. in the case of a Customer-facing service);
                                    2. b.Explain how to use the Big Data Analytics and AI Application to Customers and ensure Customers always have easy access to the instructions; and
                                    3. c.Provide clear explanations of the types of Data, types of variables and decision-making process used by Big Data Analytics and AI Applications upon Customers’ requests. To avoid doubt, clear explanations do not require exposure of Institutions intellectual property, publishing of proprietary source code or details on firms’ internal processes.
                                  2. 3.113Institutions should obtain each Customer’s acceptance of the risks associated with the use of Big Data Analytics and AI prior to providing the service.
                                  3. 3.114Institutions should put in place a mechanism for Customers to raise inquiries about Big Data Analytics and AI Applications and request reviews of decisions made by Big Data Analytics and AI Applications.

                              • Distributed Ledger Technology (DLT)

                                • Governance

                                  1. 3.115Institutions should establish an approved and documented governance framework for effective decision-making and proper management and control of risks arising from the use of DLT. The governance framework should include the following, as may be relevant depending on the type of DLT:
                                    1. a.Cover the following elements integral to the functioning of a DLT Application:
                                    2. b.Ownership model of the DLT platform and the Nodes running on it;
                                    3. c.The model used to operate and manage the distributed ledger (e.g. a consortium, a single Institution);
                                    4. d.Rules to govern the ledger(s) including participant and validator rules and restrictions;
                                    5. e.Approval processes and procedures to grant access to create, read, update or deactivate Data stored on the distributed ledger(s);
                                    6. f.Managing public and private keys;
                                    7. g.Consensus protocol; and
                                    8. h.Off-chain procedures (if any) including parameters for the validity of an off-chain activity and any standards or requirements for off-chains systems are defined and complied with.
                                    9. i.Define the roles and responsibilities of the key groups involved with respect to the design, development, and operation of the distributed ledger(s). Key groups may include:
                                      1.  i.Core group who will design, govern and operate the distributed ledger(s);
                                      2.  ii.Qualified users of the distributed ledger(s), such as other Institutions and miners;
                                      3. iii.Participants involved in the distributed ledger(s), such as owners of cryptocurrency etc.; and
                                      4. iv.Third Parties including Outsourcing Service Providers such as custodians or software developers involved in delivering the service.
                                  2. 3.116Reviews of the DLT Application should be conducted with oversight from Senior Management, prior to launch and thereafter on an on-going basis to ensure its reliability and security.
                                  3. 3.117Institutions should establish clear and unambiguous governing rules for participants of the distributed ledger(s) for onboarding, on-going operations and dispute resolution.
                                  4. 3.118When Outsourcing to an Outsourcing Service Provider, Institutions should ensure that access to information is adequately controlled, monitored, reviewed, and audited by the Institution’s internal control functions, and regulators, or persons employed by them, including supervisory reviews by the respective Supervisory Authority.
                                  5. 3.119Institutions should ensure that their DLT Applications maintain appropriate evidence and records to enable the Institution’s internal control functions, external auditors, regulators, and other authorities to conduct their audits and reviews. Accordingly, Institutions should:
                                    1. a.Record and store the additional evidence and information to provide auditors with a complete representation of processes, internal controls, financial statements, etc., and for proper accounting treatment of the transaction;
                                    2. b.Ensure that a log of records of the DLT Application is fully available and accessible to the relevant parties to audit and review;
                                    3. c.In the event that the DLT is in the form of a blockchain, ensure that off-chain activities, rules and protocols associated with and any link to on-chain activities are recorded and stored; and
                                    4. d.Ensure that the DLT code and subsequent updates are recorded and stored.

                                • Design

                                  1. 3.120Institutions should design their DLT Applications to be efficient and effectively secure IT assets and any customer assets. Institutions should, where possible, ensure the design and architectural aspects of the DLT are optimised to cater to the specific use of the technology and the needs of the Institution.
                                  2. 3.121Institutions should consider the following principles when developing the design of a DLT Application that manages financial assets:
                                    1. a.Flexibility: To define the DLT Application narrowly, which is easier to optimise, or flexibly, which may incur higher costs (more difficult protocol, less predictability, larger target for attacks, etc.);
                                    2. b.Traceability: To ensure that the distributed log of records and any off-chain records are traceable and anonymity is avoided;
                                    3. c.Capacity: To ensure that the DLT Application’s computing and Data capacity is commensurate with the Institution’s needs and is scalable depending on the intended use;
                                    4. d.Security: To ensure that the activities and records on the distributed ledger(s) are secure;
                                    5. e.Confidentiality: To maintain confidentiality of Data and implement adequate controls over the set-up and number of Nodes; and
                                    6. f.Resilience: To ensure that the system is resistant to Data loss, loss of integrity, unavailability, or manipulation.
                                  3. 3.122Institutions should define rules relating to Data and technological architecture of the DLT Application during the design phase to ensure that internal control functions, external auditors and Supervisory Authorities can effectively access the application (when applicable) and monitor compliance.
                                  4. 3.123Institutions should appropriately determine the type of access, whether permissioned or permissionless, granted to participants based on an assessment of the operations performed, level of security and Data stored using DLT. For instance, Applications involving any of the following elements should use permissioned systems:
                                    1. a.Customer assets, funds or other forms of ownership, rights or interests such as contracts;
                                    2. b.Personal Data; or
                                    3. c.Requirements for a controlled set of participants or restricted access.
                                  5. 3.124Institutions should establish controls to ensure the integrity and security of the network and DLT Application. These controls may include, but are not limited to:
                                    1. a.Implementing processes to limit Node processing ability and limit the potential for a Node to process an excessive number of transactions;
                                    2. b.Designing the Application to allow blocking of IPs/Nodes that generate too many new transactions; and
                                    3. c.Developing permissioned DLT Applications with individual Nodes that comply with security standards and requirements to guard against attacks.
                                  6. 3.125Institutions should establish appropriate consensus protocols or platforms to accept and validate new records. The consensus methodology should be based on the Institution’s requirements with respect to performance, scalability, consistency, Data capacity, governance, security and failure redundancy.
                                  7. 3.126Institutions should avoid storing clear-text Personal Data on a blockchain and instead use sidechains or other private storage options.
                                  8. 3.127Institutions should introduce cryptographic key management to control access to confidential information and Personal Data. Institutions should institute controls with respect to key generation and management and ensure an appropriate and secure storage and transmission mechanism for private keys. The key management controls should cover offline root keys (split amongst multiple owners) and online root keys (stored on hardware security modules).
                                  9. 3.128With respect to the issuance of keys to Staff and other personnel:
                                    1. a.Institutions should issue individual keys to Staff and other persons working on behalf of the Institution for audit, supervision and review purposes;
                                    2. b.Institutions should embed internal checks and verifications on the transactions and activities executed through the distributed ledger such as Staff sign-off on requests or transactions; and
                                    3. c.Institutions should ensure they can internally identify the Staff signing-off messages or requests on the distributed ledger.
                                  10. 3.129Institutions should, if possible, ensure that the design of the DLT Application allows for change i.e. add new functionality or remove unwanted or incorrectly functioning features within the DLT Application.
                                  11. 3.130Institutions should, if possible, introduce mechanisms to manage forks (i.e. conflicts arising from incompatible versions of the DLT that are broadcast within a short time period) and ensure that the situation is resolved quickly and the integrity of the DLT is maintained.
                                  12. 3.131Institutions should, if possible, introduce user access management and authentication to provide controlled access to the DLT Application. Staff and Outsourcing Service Providers should be provided access to only those parts of the system they need to perform their responsible business or operational activities. Institutions may consider if, in certain cases, it might be feasible to accept transactions only from selected, authorised IP addresses.
                                  13. 3.132Institutions should develop controls to ensure confidentiality and integrity of code(s) and prevent alteration of code(s).

                                • Anonymity and Pseudonymity

                                  1. 3.133Institutions developing Permissionless DLT Applications should ensure that users are not anonymous or pseudonymous, as allowing anonymity and pseudonymity can facilitate criminal purposes like tax evasion, bribery, money laundering or terrorism financing.
                                  2. 3.134Further, Institutions should consider using mechanisms such as chain analytics to follow and monitor transactions on pseudonymous blockchains.

                                • Management and Monitoring

                                  1. 3.135Institutions should ensure that their DLT Applications are reviewed and monitored on a periodic basis to evaluate performance, detect technology and security related incidents, ensure the adequacy of controls, and promptly take any remedial action.
                                  2. 3.136Institutions should ensure that code is reviewed and validated on an ongoing basis at regular, predetermined intervals to identify any weaknesses. Institutions should ensure code is performing its expected functions and is secure.
                                  3. 3.137Institutions should conduct vulnerability assessments and penetration tests specific to the DLT Application to identify weaknesses or flaws in the security processes.
                                  4. 3.138Institutions should manage and monitor information integrity, privacy and confidentiality in the implementation of the DLT throughout its lifecycle (e.g. by conducting privacy threshold analysis, privacy impact assessment, and Data protection impact assessment). Institutions may adopt processes such as sharding and pruning during the design of the Application to further manage privacy and confidentiality mechanisms.
                                  5. 3.139Institutions should further ensure adequate control and monitoring of the DLT through an even stringent focus on encryption than traditional controls with a particular focus on key management. A related control to consider is encrypting the ledger(s) with more than one key and applying on-chain encryption.
                                  6. 3.140Institutions should review the distributed log of records and transactions within the ledger(s) to identify suspicious patterns and connections to monitor any anomalous behavior using analytics and testing.
                                  7. 3.141Institutions should adopt operations security controls including standard infrastructure controls such as virus checking schedules, zero-day exploit remediation, maintenance schedules, capacity, and backup management.
                                  8. 3.142Institutions should adopt security incident management controls that describe the processes around reporting, escalation, and response to any breaches. Institutions should monitor if one of the Nodes increases processing power and is executing a significantly higher number of transactions.
                                  9. 3.143Institutions should ensure that adequate human resources are put in place for implementing security controls to monitor access to the DLT Application and system. Institutions should ensure that these controls are updated when Staff leave or change roles.
                                  10. 3.144Institutions should maintain and monitor physical and environmental security through use of hardware security modules, physical security measures such as CCTVs, physical barriers, traditional key security, and access controls.

                                • Data Standardisation and Interoperability

                                  1. 3.145Institutions should not maintain Personal Data on the ledger(s) and such Data should be maintained off-chain.
                                  2. 3.146Data retention will need to be factored into the underlying design of the network for Nodes to purge ledger information after certain defined time periods. Where Data retention rules apply to individual Data sets, destruction of keys used to encrypt the on-chain Data should be implemented.
                                  3. 3.147Depending on the Application, Institutions should consider the principle of interoperability when planning the design of the distributed ledger(s). Institutions should establish processes to prune the distributed ledger(s) and remove records older than a specific time period or enable processes that allow Data stored on the ledger to be forgotten (i.e. destruction of keys used to encrypt Data).

                                • Business Continuity

                                  1. 3.148Institutions should ensure appropriate business continuity planning with respect to DLT, as it covers the potential loss of Data and processing capability due to loss of servers or connectivity, and risks such as cyber-crime.
                                  2. 3.149Institutions should plan, establish, and periodically test arrangements to maintain the continuity of the service/process performed by the DLT Application in the event of an incident that affects the availability of the Application
                                  3. 3.150Institutions should ensure that their business continuity plan encompasses all the complex technical areas of DLT, from key storage and key regeneration in the event of catastrophic Data loss to creating new keys when a cyber-crime incident compromises Data security.
                                  4. 3.151Institutions should consider DLT specific scenarios such as network malfunction or compromise of Data integrity in their business continuity plans.
                                  5. 3.152The Institution’s business continuity plan team should include specialists in DLT and should monitor cryptographic advances and vulnerabilities such that proactive responses can be developed to avoid system outages.
                                  6. 3.153In solutions involving public key infrastructure, Institutions should ensure that the business continuity plan covers the technical integrity of the key generation mechanisms (certificate authorities, hardware security modules etc.), the business processes involved in the secure transportation of the private keys and the authorisation layer around these mechanisms.

                                • Customer Protection

                                  1. 3.154Institutions should disclose the relevant governing rules to Customers participating in the distributed ledger(s).
                                  2. 3.155Institutions should disclose any Fees associated with the on-going operation and management of the distributed ledger(s) including providing notice that Fees may be charged by Third Parties, where applicable.
                                  3. 3.156Institutions should advise Customers on what they should do to protect their keys from misuse. In particular, Institutions should inform Customers of the consequences of sharing their private keys and other security information.

                      • Section 4: Interpretation

                        Any clarification or interpretation of the provisions of the Guidelines may be sought from the respective Supervisory Authority:

                        • Authentication and Secure Communication

                          • Article (18) Authentication

                            1. Licensees who are Data Holders and Service Owners must apply authentication procedures in accordance with Article 18(2) of this Regulation, where a User:

                              1.1.accesses Account or Product information through a Data Sharing Provider conducting Data Sharing activities; or
                              1.2.initiates a Transaction through a Service Initiation Provider conducting Service Initiation activities.
                            2. Licensees who are Data Holders and/or Service Owners must select and implement a reliable and effective authentication procedure to verify the identity and validate the authority of the User. At a minimum, the procedure must require two factor authentication, including elements of knowledge, possession or inherence. Additional procedures must be applied in higher risk circumstances. Licensees who are Data Holders and/or Service Owners must also comply with any additional requirements specified from time to time by the Central Bank.
                            3.  Providers of Data Sharing and/or Service Initiation may rely on authentication procedures performed by the Data Holder or Service Owner, as appropriate.

                          • Article (19) Secure Communication

                            1.  All participants in Open Finance must use common and secure open standards of communication for the purpose of identification, authentication, notification and information, as well as for the implementation of security measures, between Licensees who are Data Holders and/or Service Owners in addition to Data Sharing Providers, Service Initiation Providers, Users, Payers, Payees and other relevant parties.
                            2. All communications must be conducted in accordance with the Regulations, as prescribed from time to time by the Central Bank, pursuant to the Open Finance Framework.

                            3.  Licensees offering Accounts or Products that are accessible online must have in place at least one interface which meets each of the following requirements:

                              3.1Data Sharing Providers and Service Initiation Providers can identify themselves to the Licensees;
                              3.2Data Sharing Providers can communicate securely to request and receive information on one or more Products and/or Accounts; and
                              3.3Service Initiation Providers can communicate securely to provide Service Initiation and receive information on Service Initiation and the associated Transaction.
                            4. Licensees must establish the interface referred to in Article 19(3) of this Regulation by means of a dedicated interface or by allowing use by the Open Finance Providers, of the interface used for authentication and communication with the Licensee’s User.
                            5. Licensees must also ensure that any dedicated interface referred to in Article 19(3) of this Regulation uses ISO 20022 elements, components or approved message definitions, for financial messaging, as amended/updated from time to time.
                            6. Information held by the Data Holder or Service Owner must only be accessed for the purposes of providing Open Finance Services and any relevant ancillary activities in compliance with the requirements of this Regulation.

                          • Article (20) Obligation Toward Users

                            1. Open Finance Providers must operate prudently and ethically and with competence, in a manner that will not adversely affect the interests of a User or potential User.
                            2. Open Finance Providers must provide a User with written terms and conditions governing their contractual relationship with the User in advance of entering into a relationship with a User for the provision of Open Finance Services.
                            3.  The terms and conditions referred to in Article 20(2) of this Regulation must be written in clear, plain and understandable language, in a manner that is not misleading, and must, at a minimum, be available in Arabic and in English. To the extent that the Open Finance Provider is contractually entitled to make changes to its terms and conditions, the Open Finance Provider must provide at least sixty (60) calendar days’ notice to the User of such changes.
                            4. A User is entitled to terminate its relationship with an Open Finance Provider, at no charge (direct or indirect), if the User does not accept the change(s) to the Open Finance Provider’s terms and conditions notified to the User under Article 20(3) of this Regulation.

                            5. An Open Finance Provider’s terms and conditions with Users must at a minimum set out the following:

                              5.1schedule of fees and charges;
                              5.2contact details of the Open Finance Provider, including legal name and registered address, and the address of the agent, where applicable;
                              5.3the communication channel(s) between the Open Finance Provider and the User;
                              5.4the manner and timeline for notification by the User to the Open Finance Provider in case of unauthorised, delayed or incorrect Service Initiation;
                              5.5information on the Open Finance Provider’s and the User’s respective liability for Unauthorized Transactions;
                              5.6information on the Open Finance Provider’s complaints procedure;
                              5.7information on the manner in which disputes between the Open Finance Provider and the User are to be resolved; and
                              5.8the Open Finance Provider’s procedure for reporting of Unauthorized Transactions.

                        • Liability

                          • Article (21) Liability for Unauthorised Transactions, Defective Transactions and Data Breaches

                            1. An Open Finance Provider is liable to a User for loss or damage suffered by the User where there has been unauthorized access to or loss of the User Data of that User held by the Open Finance Provider.
                            2. In relation to Initiation Services, a Service Initiation Provider is liable to a User for loss or damage suffered by the User in relation to the non- execution or late or defective execution of a Transaction (arising from the late initiation and/or late processing of the initiation of Transactions), including where there has been a failure by the Service Initiation Provider to ensure that the Transaction was appropriately authorised, authenticated, accurately recorded or failure to use appropriate secure methods of communication.
                            3. In the case of a dispute between the Service Initiation Provider and the User as to the Service Initiation Provider’s liability under Article 21(2) of this Regulation, it is for the Service Initiation Provider to prove that the Transaction was correctly processed, with supporting evidence.
                            4. In relation to Initiation services, a Service Owner is liable to a User for loss or damage suffered by the User in relation to the non-execution or late or defective execution of a Transaction, unless such loss or damage occurred as a result of any act or omission of the Service Initiation Provider as provided for in Article 21(2) of this Regulation.
                            5. Any breach of security or other action that leads to the illegal, unauthorised, or accidental access, alteration, destruction, disclosure or loss of User Data that is a User’s Personal Data during storage, transmission or otherwise that is caused directly or indirectly, in whole or in part, by an Open Finance Provider may subject the Open Finance Provider to administrative and financial sanctions and penalties as deemed appropriate by the Central Bank, without prejudice to any other sanctions or penalties set out under applicable laws.

                        • Data Privacy and Users’ Consent

                          • Article (22) Data Privacy and Consent for the Use of Personal Data

                            1.  An Open Finance Provider must not Process any Personal Data for the provision of its services unless it has the explicit consent of the User to do so. Article 22 of this Regulation is subject to the prohibitions on Processing Sensitive Data set out in Article 4(1)(5) and in Article 16(3)(2) of this Regulation.

                            2. A User’s consent must:

                              2.1be specific to the purpose for which it is provided, informed, unambiguous, and freely given;
                              2.2be given using a clear, objective and affirmative statement or action to signify agreement to the Processing of Personal Data of that User;
                              2.3if the Processing is intended to cover multiple purposes, be obtained for each purpose in a manner that is clearly distinguishable;
                              2.4in case of a recurring Transaction, specify the period for which the consent is valid, up to a maximum period of twelve (12) months; and
                              2.5be able to be withdrawn by the User at any time and for any reason, upon notice to the Open Finance Provider.
                            3. An Open Finance Provider must inform the User of this right to withdraw consent and how to exercise that right at the time the consent is obtained. Withdrawing consent should not require undue effort on the part of the User and should be at least as simple, quick and easy as the process of giving consent. Withdrawal of consent does not affect the lawfulness of Processing carried out before the date of withdrawal and shall not prevent the Open Finance Provider from retaining Personal Data required for compliance with Article 13 of this Regulation or applicable laws.

                            4.  In the case of Service Initiation, a User’s consent must be obtained in relation to each Transaction to be Initiated by the Service Initiation Provider or, in the case of a recurring Transaction, a User’s consent must be obtained at the time that the User first establishes the recurring Transaction, and its parameters. A User’s consent in the case of Service Initiation must include details, as relevant, of:

                              4.1The relevant Account(s) or Product(s) to which the Transaction(s) relates;
                              4.2The nature of the relevant Transaction(s) to be Initiated (including whether it is a recurring Transaction);
                              4.3The value(s) of the relevant Transaction(s);
                              4.4The beneficiary(ies) of the relevant Transaction(s); and
                              4.5The value date(s) of the relevant Transaction(s).
                            5. A User’s consent will not be considered valid in circumstances where the Open Finance Provider has obtained that User’s consent to Process Personal Data which includes Personal Data that is not relevant or not limited to what is necessary for the relevant purpose for which it is provided.
                            6. If User Data contains Personal Data of natural persons other than the User, Open Finance Providers must anonymise such Personal Data of these other natural persons, or ensure that the consent of such natural persons to whom the Personal Data relates, is obtained prior to Processing such Personal Data in accordance with this Regulation (unless the Processing of that Personal Data is otherwise permissible under applicable laws concerning the protection of Personal Data).
                            7. Nothing in this Regulation derogates from the obligations of a Licensee under all other applicable laws and regulations relating to protection of Personal Data including other Regulations.
                            8. Open Finance Providers must comply with all other applicable laws and regulations relating to the protection of Personal Data.

                            9. Without prejudice to Articles 22(7) and (8) of this Regulation, Personal Data Processed by a Licensee or an Open Finance Provider relating to Open Finance Services must be:

                              9.1Processed lawfully, fairly and in a transparent manner;
                              9.2collected for specified, explicit and legitimate purposes and not Processed at any time, in a manner that is incompatible with those purposes;
                              9.3adequate, relevant and limited to what is necessary in relation to the purposes for which it is Processed;
                              9.4accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that Personal Data that is inaccurate, having regard to the purposes for which it is Processed, is erased or rectified without delay; and
                              9.5Processed in a manner that ensures appropriate security of the Personal Data, including protection against unauthorised or unlawful Processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures.
                            10. Open Finance Providers must destroy User Data that is Personal Data which allows for the identification of the User, after the purpose of its provision to the Open Finance Provider has been completed, subject to the record retention requirements in Article 13 of this Regulation and any mandatory data retention requirements under applicable laws, including AML Laws.

                            11. Open Finance Providers must store all data relating to Open Finance Services within the State and are not permitted to maintain copies of the data they obtain through Open Finance Services outside of the State, unless the Open Finance Provider has obtained:

                              11.1approval from the Central Bank and additional approvals from any other relevant competent authority, as necessary;
                              11.2prior written consent from the User. For the purpose of obtaining such consent from a User, the User must be informed of the following, prior to or at the time of being asked to give consent:
                               11.2.1where the User Data will be stored;
                               11.2.2why it will be stored outside the State; and
                               11.2.3that consent is sought only for the purpose which has been approved by the Central Bank; and
                              11.3written acknowledgement from the User that his/her User Data may be accessed under legal proceedings outside the State in such circumstances.
                            12. Subject to Central Bank approval, and in accordance with relevant laws and Regulations, licensed branches of foreign banks may store data relating to Open Finance Services outside of the State, provided a copy of the Master System of Record, updated on at least a daily basis, is stored in the State.

                             

                        • Anti-Money Laundering, Terrorist Financing and Security

                          • Article (23) Anti-Money Laundering and Combating the Financing of Terrorism and Illicit Organisations

                            1. Open Finance Providers must have comprehensive and effective internal Anti-Money Laundering and Combating the Financing of Terrorism policies, procedures and controls in place to ensure compliance with the AML Laws and Regulations, as amended from time to time.
                            2. Open Finance Providers must have robust fraud control policies and systems in place, which should address identification and access controls requirements, to comply with the requirements of this Regulation.

                          • Article (24) Technology Risk and Information Security

                            1. Open Finance Providers must establish an appropriate information technology (IT) governance framework. IT governance must cover various aspects, including a clear structure of IT functions and the establishment of IT control and risk management policies, and at a minimum, must include an effective IT function, a robust technology risk management function, and an independent technology audit function.
                            2. The Board, or a committee designated by the Board, shall be responsible for ensuring that a sound and robust risk management framework is established and maintained to manage technology risks in a manner that is proportionate to all risks that the Open Finance Provider is exposed to.
                            3. Open Finance Providers must adhere to the security and other standards set by the operator to ensure that the software used by the Open Finance Provider is not compromised at any stage in its development process.
                            4. Open Finance Providers must adopt and implement industry standards and best practices in relation to security risk management as directed by the Central Bank from time to time.
                            5. Open Finance Providers must identify, manage and adequately address all cybersecurity risks through the implementation of a technology risk management framework. Open Finance Providers must commit adequate skilled resources to ensure its capability to identify the risk and protect its critical infrastructure and services against any attack and contain the impact of cybersecurity incidents and restore its services.
                            6. Open Finance Providers must establish a cybersecurity incident response and management plan to swiftly isolate and neutralise a cybersecurity threat and to resume affected services as soon as possible. The plan must, inter alia, describe the procedures to respond to plausible cyber threat scenarios.

                        • Supervisory Examinations

                          • Article (25) Supervision

                            1. The Central Bank may conduct periodic examinations of the operation of Open Finance Providers to ensure their financial soundness and compliance with the requirements of this Regulation and all applicable laws and Regulations
                            2. Open Finance Providers must provide the Central Bank with full and unrestricted access to their premises, Senior Management and employees, accounts, records and documents, and must promptly supply such information and facilities as may be required by the Central Bank to conduct the monitoring and examination referred to in Article 25(1) of this Regulation.

                        • Supporting Regulatory Technical Standards

                          • Article (26) Supervision

                            1. The Central Bank may, from time to time, and, in cooperation with relevant government bodies and consultation with relevant stakeholders, develop and issue regulatory technical standards addressed to Open Finance Providers with the aim of establishing additional requirements and/or providing additional details, controls and guidance on areas relating to the provision of Open Finance Services within the scope of Open Finance activities, including, but not limited to:
                            1.1.digital access specification;
                            1.2.cyber security;
                            1.3.overall customer journey design;
                            1.4. management and journeys of centralised consent including consent; app-to-app
                            1.5.right to implement capped charging or to inhibit charging to third party providers; and
                            1.6.any other area as may be required.

                        • Enforcement and Sanctions

                          • Article (27) Enforcement and Sanctions

                            1. Violation of any provision of this Regulation or committing any of the violations provided for under the Central Bank Law or other applicable laws may subject the Open Finance Provider and/or Licensee to administrative and financial sanctions and penalties as deemed appropriate by the Central Bank.

                          • Article (28) Consumer Protection

                            1. Open Finance Providers will be subject to applicable consumer protection laws and their implementing regulations as well as any Regulations issued.

                          • Article (29) Interpretation

                            1. The Regulatory Development Department of the Central Bank shall be the reference for interpretation of the provisions of this Regulation.

                          • Article (30) Publication and Application

                            1. This Regulation shall be published in the Official Gazette in both Arabic and English and shall come into effect in phases as notified by the Central Bank.

                             

                             

                             

                             

                             

                             

                             

                             

                             

                             

                             

                             

                             

                             

                             

                            Khaled Mohamed Balama

                             Governor of the Central Bank of the United Arab Emirates

                        • Schedule 1 – Details of the Open Finance Framework

                          The Introduction to this Regulation specifies that the Open Finance Framework consists of the Trust Framework, the API Hub, the Common Infrastructural Services and such other matters as might be determined from time to time by the Central Bank.

                          The Trust Framework, the API Hub and the Common Infrastructural Services shall at a minimum include the following:

                          Trust Framework

                          The Trust Framework shall include:

                          1. The Participant Directory

                            1.1.to facilitate the validation of participants in the Open Finance Framework and the secure exchange of information.
                            1.2.to provide identity and access management services to enrolled market participants providing secure access to use Open Finance Services, contact and enrolment management, digital certificate validation and Application registration and validation services.
                          2. Digital Certificates: to facilitate secure communication between participants with respect to the provision of Open Finance Services. The operator of the Trust Framework will mint, revoke and validate digital certificates used to access Open Finance Services.
                          3. API Portal: to hold all documentation on standards, technical specification, requirements and business rules for all participants.
                          4. Sandbox: to facilitate participants’ ongoing testing and official conformance certifications.

                          API Hub

                          The API Hub shall include an API Manager. The API Manager will provide an API Aggregator to aggregate participant API’s and provide a single point of implementation. The API aggregator will provide a harmonised and standardised API for participants in the Open Finance Framework for all of the underlying APIs included in this Regulation with which it integrates.

                          A Participant Integration Layer used to receive and manage information related to Accounts, Transaction Initiation Services and all other data exposed to the Open Finance Framework.

                          Common Infrastructural Services

                          The Common Infrastructural Services shall include:

                          1. A Consent and Authorization Manager: a standalone App for Users or a set of APIs for participants that supports the creation, management, enforcement and revocation of consumer, organisational and jurisdictional privacy directives.
                          2. Service Assurance: a platform for managing all service level enquiries relating to onboarding and registration requests as well as technical enquiries relating to all key components covering data and Transaction flow enablement.
                          3. Reporting and Analytics: a platform used to analyse and report operational data and KPIs across participants including service performance, service availability and service adoption.
                          4. Administration Tools: a platform used to facilitate the management, tracking, adjudication and resolution of cases and disputes among participant (whether between participants or in relation to end Users).
                          5. Value added enablers as appropriate.