INSTRUÇÃO NORMATIVA BCB Nº 359, DE 3 DE MARÇO DE 2023

Regulatory document revoked by Normative Instruction BCB No. 588, of 1/31/2025.

Publishes version 3.0 of the Manual of Services Provided by the Structure Responsible for Open Finance Governance.

The Heads of the Financial System Regulation Department (Denor), the Department of Supervision of Cooperatives and Non-Banking Institutions (Desuc), the Banking Supervision Department (Desup), and the Information Technology Department (Deinf), in the exercise of the powers conferred upon them by arts. 23, item I, letter "a", 62, item IV, and 116, item I, letter "b", of the Internal Regulations of the Central Bank of Brazil, annexed to Ordinance No. 84,287, of February 27, 2015, based on art. 3, item III, of BCB Resolution No. 32, of October 29, 2020,

R E S O L V E:

Art. 1º This Normative Instruction publishes version 3.0 of the Manual of Services Provided by the Structure Responsible for Open Finance Governance, of mandatory observance by participating institutions, as per the Annex.

Sole Paragraph. The manual referred to in the caput, in its most recent version, will be accessible on the Open Finance page on the Central Bank of Brazil's internet website and on the Open Finance Portal in Brazil, maintained by the Structure Responsible for Open Finance Governance referred to in art. 44, § 1, of Joint Resolution No. 1, of May 4, 2020.

Art. 2º Normative Instruction BCB No. 133, of July 22, 2021, is hereby revoked.

Art. 3º This Normative Instruction enters into force on April 1, 2023.

João André Calvino Marques Pereira Harold Paquete Espínola Filho Head of the Financial System Regulation Department Head of the Department of Financial System Regulation of Supervision of Cooperatives and Non-Banking Institutions

Belline Santana Haroldo Jayme Martins Froes Cruz Head of the Department Head of the Department of Banking Supervision of Information

ANNEX TO NORMATIVE INSTRUCTION BCB NO. 359, OF MARCH 3, 2023

Manual of Services Provided by the Structure Responsible for Open Finance Governance Version 3.0

Summary of Changes

Date	Version	Description of Changes
03/03/2023	3.0	Decoupling of the Participant Directory Monitoring Service, with the exclusion of item 2.6, and creation of section 8 on Monitoring of Open Finance Technology Services.
Greater detail regarding the opening of tickets in the Service Desk, with changes in item 3.2.2.2.
Creation of new types of incidents regarding incident response targets without unavailability, with changes in item 3.2.2.5.2.
Creation of section 7 on Validation of the Production Environment.
Adaptation of various sections to the current stage of Open Finance.
Improvements in the wording of the text, without alteration of merit.
Substitution of the expressions Open Banking by Open Finance, as per the alteration promoted by Joint Resolution No. 4, of March 24, 2022, in Joint Resolution No. 1, of 2020.

Terms of Use

This manual details the technical requirements for the implementation of the elements necessary for the operationalization of Open Finance, complementing the current regulation on the subject.

The manual will be reviewed and updated periodically in order to preserve compatibility with the regulation, as well as to incorporate improvements resulting from the evolution of Open Finance and technology.

More detailed information and examples of the application of this manual can be found in the guides and tutorials available on the Open Finance Portal in Brazil, in the Developer Area.

Suggestions, criticisms, or requests for clarification regarding the content of this document may be sent to the Central Bank of Brazil through the institutional channels of this autarchy.

References

These specifications are based on, reference, and complement, when applicable, the following documents:

Reference	Origin
Joint Resolution No. 1, of 2020	https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolu%C3%A7%C3%A3o%20Conjunta&numero=1
BCB Resolution No. 32, of 2020	https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolu%C3%A7%C3%A3o%20BCB&numero=32
Circular No. 4,032, of 2020	https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Circular&numero=4032

1. Introduction

The functioning of Open Finance presupposes the provision of some fundamental services. In the model adopted in the Country, defined by Joint Resolution No. 1, of May 4, 2020, of the Monetary National Council and the Central Bank of Brazil, and by BCB Resolution No. 32, of October 29, 2020, this responsibility fell to the Structure Responsible for the Governance of Open Finance, as per Circular No. 4,032, of June 23, 2020.

The Participant Directory is the first essential element for the infrastructure of Open Finance. It aggregates a series of critical functionalities, such as the management of participant credentials.

The Structure Responsible for Governance must monitor the technology service levels of participants and shared infrastructure defined in regulation.

The support channels for the services provided by the Structure Responsible for the Governance of Open Finance and for forwarding demands to participating institutions are also important for meeting the technical support needs for the operationalization of Open Finance. They constitute focal points for receiving and forwarding demands to participants, with the monitoring of demands until their resolution.

Another important element for the functioning of Open Finance is the dispute resolution platform. Such platform integrates the mechanism for dispute resolution referred to in art. 44, item IV, of Joint Resolution No. 1, of 2020. The access of participating institutions to the resources of the aforementioned platform must observe confidentiality, integrity, availability of data and information systems used, as well as current legislation and regulation.

With the purpose of promoting communication not only among participants of Open Finance, but with the general public, the Structure Responsible for the Governance of Open Finance must make available the Open Finance Portal in Brazil. On this portal, citizens can clarify their doubts regarding services and technology; developers can obtain technical-operational information; and participating institutions can obtain information about the environment.

The Structure Responsible for the Governance of Open Finance must also make available a test environment (Sandbox) for application programming interfaces (APIs), with the objective of providing support structure for development and testing by participating institutions, and a production validation service to check the compliance and registration of APIs of participating institutions and ensure that the production environments of participating institutions are compliant with their respective certifications.

It is worth noting that several of the aforementioned services, such as the Participant Directory, API test environments and technology service monitoring, and production validation tools, constitute elements of the participant monitoring role attributed to the Structure Responsible for the Governance of Open Finance, as per art. 44, item VIII, of Joint Resolution No. 1, of 2020. It is worth mentioning that, however, such role is not limited to the services described in this manual.

In this sense, these are just some of the services provided by the Structure Responsible for the Governance of Open Finance with the objective of making Open Finance viable in the Country. Naturally, there will be an evolution of the needs inherent to this initiative. Thus, the purpose of this manual is to establish part of the minimum requirements of essential services without the pretension of being exhaustive, leaving a margin for decision and action by institutions at points not covered by the document, but necessary for the success of the implementation of Open Finance.

2. Participant Directory

The Participant Directory is the environment in which an institution authorized to operate by the Central Bank of Brazil registers and formalizes its participation in the Open Finance environment,* performing its integration to begin data sharing, payment transaction initiation and/or forwarding of credit operation proposals to other participating institutions, via APIs.

The Participant Directory must implement the following functionalities:

I - identity and access management: the issuance and management of identity records for organizations and natural persons who interact with the Directory;

II - application identity and authorization management: identification and authorization of participating institutions' applications; and

III - Directory information management: the ability to update and find information maintained in the Directory, via APIs, files and/or a web user interface.

2.1 Identity and Access Management

The "Identity and Access Management" functionality covers all business processes executed from the first contact of the institution's representative with the Open Finance homepage until the end of its registration as a participant in the Participant Directory.

The Participant Directory must allow representatives of institutions to register them as participants in Open Finance, collecting the necessary information for their full participation, according to their respective participation modalities.

The Participant Directory must also have functionality for the revocation of participant certificates, as per current regulation.

The registration process must be detailed on the Open Finance Portal in Brazil maintained by the Structure Responsible for the Governance of Open Finance.

2.2 Application Identity and Authorization Management

The "Application Identity and Authorization Management" functionality covers the business processes involved in the identification and authorization of application participation in Open Finance, allowing secure consumption of information.

This process must be detailed on the Open Finance Portal in Brazil maintained by the Structure Responsible for the Governance of Open Finance.

2.3 Directory Information Management

The Participant Directory must have functionalities that enable the listing of participants, the consultation and alteration of their data, their representatives, and their contacts, as well as the history of modifications made. These alterations must be subject to notification to participants.

Regarding the data APIs accessible to the public regarding service channels and products and services available for contracting at the participating institution, currently defined by the Data Scope Manual, the Participant Directory must provide queries, via API or files, that allow identifying participants who implement a specific API or endpoint, as well as listing the APIs and endpoints implemented by a participant. Regarding the other APIs from that manual, an API must be provided that implements analogous queries, in this case restricted to Open Finance participating institutions.

The processes involved in these functionalities must be detailed on the Open Finance Portal in Brazil.

2.4 Conformity Tests and API Registration

The Structure Responsible for the Governance of Open Finance is responsible for the conformity validation process of participants' APIs. The minimum scope of tests must cover functional and non-functional aspects; the former aim to evaluate if implementations are compliant with API specifications; the latter aim to evaluate if the non-functional requirements of APIs, in particular security, are being met by their implementations.

The execution of conformity tests is performed in an environment made available by the Structure Responsible for the Governance of Open Finance, which is also responsible for certifying the results.

An implementation of an Open Finance API version can only be registered in the production environment of the Participant Directory if it has been certified in conformity tests.

The Structure Responsible for the Governance of Open Finance must establish a recertification policy to be followed by participating institutions.

The results of conformity tests of APIs already performed must be made available in a public area of the Open Finance Portal in Brazil.

2.5 Service Level Agreements (SLAs) of the Participant Directory

The Participant Directory must observe the following minimum service level:

Availability:

I - 24 hours a day, 7 days a week;

II - 95% every 24 hours; and

III - 99.5% every 3 months.

API Performance:

95th percentile response time of, at most, 1500ms.

3. Service Desk

The Service Desk is the Open Finance environment in which tickets for technical support related to the Participant Directory, its APIs, and the data and services shared between participants are requested and maintained in a centralized manner.

In this environment, four basic functionalities must be made available:

I - resolution of general questions;

II - support in the issuance of tickets;

III - support for notifications; and

IV - support for services provided by the Structure Responsible for the Governance of Open Finance.

3.1 Resolution of General Questions

Two areas must be provided for the resolution of technical questions related to Open Finance, namely: frequently asked questions on technical subjects (FAQ) and a service channel, which may be implemented with automated service, without human intervention.

3.1.1 Frequently Asked Questions

In this area, answers to the most frequent questions related to technical support, the Participant Directory, APIs, data and services shared between participating institutions, and processes of this sharing must be found, so that some doubts can be resolved quickly and independently.

The content of this section must be reassessed at least with each major version launch of APIs, in order to meet its objective of clarifying frequent questions from the public.

3.1.2 Service Channel

A service channel must be made available for technical support, which may be implemented with automated service, without human intervention. In this channel, answers to less complex questions may be obtained.

Answers must be classified according to the degree of sensitivity, and must be provided with observance of the requester's profile.

If it is not possible to meet the requester's needs through the automated channel, the possibility of opening a ticket must be offered.

3.2 Support in Opening Tickets

3.2.1 Types of Tickets

The Service Desk must support at least two types of tickets:

I - requests: requests for information or suggestions for improvements; and

II - incidents: communication of failures or degradation of quality in any service.

3.2.2 Ticket Management

3.2.2.1 Principles for Ticket Management

A system must be implemented that allows the definition of ticket response states, as well as transitions between states, in order to allow the adoption of actions appropriate to their treatment, such as: triage, queuing, assignment, response, evaluation, and return. This system must be detailed on the Open Finance Portal in Brazil maintained by the Structure Responsible for the Governance of Open Finance.

3.2.2.2 Opening of Tickets

The Service Desk must allow the opening of tickets, via service channel, by:

I - participating institutions;

II - developers; and

III - citizens.

To respond to questions and requests from citizens, the Service Desk must provide an environment with a friendly and intuitive interface adapted to the general public, so that interested people can address their demands to the Structure Responsible for the Governance of Open Finance without the need for specific technical knowledge.

In the case of receiving demands from citizens involving complaints against participating institutions, the requester must be guided to first seek the involved institution, and if they cannot resolve the problem, register the complaint with the Central Bank of Brazil.

Additionally, in the case of a participating institution, it must be possible to open tickets via a specific API.

When opening a ticket, a protocol number must be generated, which must be informed to the requester. At this moment, the deadline for responding to the demand will begin to run, as per the service level agreement specified in item 3.2.2.5.

3.2.2.3 Classification of Maximum Resolution Deadline for Tickets

The maximum resolution deadline for tickets must be associated with the ticket before being directed to participating institutions. These deadlines are defined in item 3.2.2.5.

3.2.2.4 Ticket Audit Trail

Any update that generates a change in the response state or content of the ticket must be duly recorded and stored for future access and for verification or audit purposes, observing the storage deadlines provided in current regulation.

3.2.2.5 SLAs for Responding to Tickets

3.2.2.5.1 Response Targets for Requests

The targets for responding to tickets by type of request are:

Type of Request	Maximum Deadline	Additional Clarifications
Information Requests	5 business days	The deadline refers to the provision of the requested information, or the indication of the appropriate channel to obtain the information.
Improvement Suggestions	10 business days	The deadline refers to the provision of the result of a preliminary analysis of the proposal, also informing the estimated implementation deadline, if applicable.

3.2.2.5.2 Response Targets for Incidents Without Unavailability

The targets for responding to tickets related to incidents that do not cause service unavailability are:

Type of Incident	Maximum Deadline	Additional Clarifications
Service Quality Degradation	2 business days	The deadline refers to the implementation of a correction or workaround (analysis and solution) to repair failures that degrade a service without causing its interruption.
Certification Non-Conformity Errors	5 business days	The deadline refers to the implementation of a correction or workaround (analysis and solution) to repair failures that, without causing service interruption, produce results divergent from those obtained during the certification process.
Implementation Non-Conformity Errors	10 business days	The deadline refers to the implementation of a correction or workaround (analysis and solution) to repair failures that, without causing service interruption, produce results divergent from the specification.
Only cases where the implementation is divergent from the specification and no technical inconsistency in the specification is demonstrated may be classified under this error.
Other Errors	Analysis: 5 business days Correction/workaround: 45 calendar days	The analysis deadline refers to the preliminary evaluation of the presented case, also informing the estimated deadline for correction, according to the effort expected for the correction and the impact on the citizen.
The correction or workaround deadline (analysis and solution) refers to the implementation of a correction or workaround to repair other errors without causing service interruption.
Incidents of this type must be evaluated by the Structure Responsible for the Governance of Open Finance, with consideration given to the possibility of coverage of the problem by certification tests.

Regarding the incidents "Implementation Non-Conformity Errors" and "Other Errors", the Central Bank of Brazil may establish differentiated deadlines for their correction due to analysis regarding the required effort and the impact on the citizen.

3.2.2.5.3 Response Targets for Incidents With Unavailability

The targets for responding to tickets related to incidents that cause service unavailability must be established by the Structure Responsible for the Governance of Open Finance, ensuring compliance with their respective availability SLAs. Once the service is reestablished, the ticket related to the incident must be closed within 1 business day.

3.2.2.6 Ticket Deadline Counting

Deadlines refer to the total response time, from the generation of the protocol until the closing of the ticket, encompassing the time spent in the Service Desk and in the demanded participants. If there is a need to complement essential information regarding tickets, the deadline counting is suspended until the relevant information is provided.

3.2.2.7 Notification of Ticket Updates

Any update to the ticket (content and/or response state) must be notified to the requester. Demanded participants may also receive notifications.

3.3 Support for Notifications

The Service Desk must have functionality for notifying and disseminating information relevant to participating institutions and other interested parties.

The process involves reporting, inserting into a news board, and sending information to participating institutions.

3.3.1 Types of Notifications

The following information must be reported:

I - problems in API implementations;

II - timely updates on API unavailability;

III - timely updates on service quality degradation;

IV - notifications on scheduled unavailabilities; and

V - notifications on service reestablishment.

The following technical changes must also be reported:

I - updates in API implementations;

II - updates to security policies and/or participants;

III - updates to the Participant Directory; and

IV - updates to API definitions.

The detail of the information and notification methods must be provided on the Open Finance Portal in Brazil.

3.4
Support for services provided by the Structure Responsible for the Governance of Open Finance

The Service Desk must provide support for the following topics related to the services provided by the Structure Responsible for the Governance of Open Finance:

I - registration of participants in the Participants Directory;

II - access to the Participants Directory;

III - updates to the Participants Directory; and

IV - inquiries, reporting of problems, and complaints regarding the services provided by the Structure Responsible for the Governance of Open Finance.

3.5
Service Desk SLAs

The Service Desk must observe the following minimum service level:

Availability:

I - 24 hours a day, 7 days a week;

II - 95% every 24 hours; and

III - 99.5% every 3 months.

API Performance:

95th percentile response time of no more than 1500ms.

Dispute Resolution Platform

The dispute resolution platform is an environment that integrates the mechanism for dispute resolution referred to in Article 44, item IV, of Joint Resolution No. 1, of 2020. Complementarily to the provisions in this manual, the dispute resolution platform must be developed in accordance with the technical standards and other operational issues defined in documents prepared by the Structure Responsible for the Governance of Open Finance.

4.1 SLAs of the Dispute Resolution Platform

The Dispute Resolution Platform must observe the following minimum service level:

Availability:

I - 24 hours a day, 7 days a week;

II - 95% every 24 hours; and

III - 99.5% every 3 months.

Open Finance Portal in Brazil

5.1
Guidelines for the Open Finance Portal in Brazil

5.1.1 Accessibility and diversity

All areas to be made available on the Open Finance Portal in Brazil must ensure accessibility and comply with the Web Content Accessibility Guidelines (WCAG), and all informational content must take into account the regional diversity of the country (rural/urban, capital/inland), as well as the diversity of the Brazilian population regarding race, gender, age group, and disability.

5.1.2 Language and timeliness

The language used in the different areas of the Portal must be appropriate for the audience profiles that visit them. The content must be made available in a clear, accessible, transparent, and timely updated manner, adequately reflecting the Open Finance scenario at that time and providing the necessary information to understand and use it. Especially in the citizen area, there must be an emphasis on visual application, with videos, images, charts, and infographics that facilitate people's understanding.

5.1.3 Security, confidentiality, and data protection

The Portal must provide a secure browsing environment, free of malware or means for installing vulnerabilities that could allow obtaining illicit advantage. It must be ensured that data processing, including any data requests to visiting persons, is in compliance with current legislation, particularly with the provisions of Law No. 13,709, of August 14, 2018 (General Data Protection Law).

5.2 Developer Area

The Developer Area must be an open environment that evolves over time, in line with the development of Open Finance.

The following content must be made available mandatorily:

I - API specifications for service channels and for institutions' products and services;

II - API specifications for client registration and transactional data;

III - API specifications for payment transaction initiation;

IV - API specifications for forwarding credit operation proposals;

V - API specifications for the Participants Directory and the Service Desk;

VI - API specifications for reports and metrics;

VII - registration specifications;

VIII - security profile;

IX - Sandbox environment specifications, including related tutorials;

X - conformity test specifications and documentation of recertification policies and validation of the production environment;

XI - known specification issues;

XII - operational guidelines;

XIII - customer experience guidelines;

XIV - technical guidelines for the Participants Directory;

XV - calendar;

XVI - participant implementation guides;

XVII - issues;

XVIII - frequently asked questions (FAQ);

XIX - specification history; and

XX - change history.

If any item is still pending specification, the information "to be published" must be provided.

API specifications must observe the Open Finance implementation schedule established in current regulation.

5.3 Citizen Area

The Citizen Area must be an open environment, focused on the citizen's experience, using language appropriate to the theme and easy to understand, which evolves over time, in consonance with the development of Open Finance.

The following content must be made available mandatorily:

I - what is Open Finance?: explanation of the Open Finance environment, including its origin, benefits, and applications, as well as its mode of operation;

II - Structure Responsible for the Governance of Open Finance: explanation of the Governance Structure, with clarification on the formation process, its different instances (strategic, technical, and administrative levels), composition, roles, and responsibilities, as well as on the function of the Central Bank of Brazil in these aspects;

III - customer journey: visual material (infographic or, preferably, video) that clarifies for people all the steps for data sharing, including the stages of consent, authentication, and confirmation; for payment initiation and for forwarding credit operation proposals. The content must explain the terms used during the journey and the required input fields, as well as address the journey related to natural persons and legal entities;

IV - security: Open Finance security infrastructure, including the responsibilities of participating institutions, security alerts, precautions to be taken to prevent fraud, and guidance in case the person is a victim of fraud;

V - citizen frequently asked questions (FAQ): answers to recurring citizen doubts, especially regarding the object of Open Finance, participating institutions, the customer journey, user rights, transaction security, and channels for submitting requests;

VI - guidance for forwarding requests: in addition to being in the FAQ, guidance must be made available in a visible area of the portal, clarifying to the citizen whom to turn to in cases of doubts about Open Finance or complaints about participating institutions. This guidance must cover, among other things, cases where the request relates to the entities involved in sharing;

VII - Open Finance participating institutions search mechanism, which meets the following conditions:

a) the search mechanism must, mandatorily, allow searching by, at minimum, institution name, institution type, brand, and participation modality in Open Finance; and

b) the list of participants must be extracted from the Participants Directory maintained by the Structure Responsible for the Governance of Open Finance and be permanently kept updated;

VIII - news: information of interest to the citizen;

IX - events: informative list of Open Finance events, such as forums, conferences, discussion panels, and networking events; and

X - glossary: main terms used in the Open Finance context, with a view to facilitating consumer understanding.

Additionally, specific content for legal entities must be provided, with clarifications on how Open Finance can contribute to companies, especially smaller ones, including possible use cases, as well as explanatory videos and infographics.

5.4 Participant Area

A Participant Area must be made available with information geared toward topics of interest to institutions that participate or intend to participate in Open Finance. Similar to the Citizen Area, this must also be an open environment that evolves over time. Restricted access areas for Open Finance participants may be made available.

For this area, the topics to be covered mandatorily are listed below:

I - participation in Open Finance: general clarifications on the scope of participation and which institutions are mandatory and voluntary;

II - partnerships: explanation of the forms of participation of institutions not supervised by the Central Bank of Brazil and the responsibilities involved;

III - implementation: description of the Open Finance phases, detailing the future implementation schedule established in regulation;

IV - registration in Open Finance: general clarifications and tutorial for registration in the Participants Directory, including access method;

V - Service Desk: general information, operation, expected SLAs, types of requests received, guidance for registration, and access method;

VI - dispute resolution mechanisms: guidance on the dispute resolution process involving participating institutions;

VII - funding of the Structure Responsible for the Governance of Open Finance: explanations on the calculation basis, responsibilities of the parties involved, and how to make payment;

VIII - Open Finance regulation: information on current normative acts, as well as associated documents, with possible direct link to the Central Bank of Brazil page on the subject;

IX - data scope: explanation of the data scope to be shared in each of the Open Finance implementation phases and access to the data dictionary; and

X - frequently asked questions from participating institutions: clarifications on the main doubts about participation in Open Finance.

5.5 SLAs of the Open Finance Portal

The Open Finance Portal must observe the following minimum service level:

Availability:

I - 24 hours a day, 7 days a week;

II - 90% every 24 hours; and

III - 99.5% every 3 months.

6. Sandbox

The Structure Responsible for the Governance of Open Finance must make available a structure, hereinafter referred to as Sandbox, which allows participants, at minimum:

I - to submit, even during the development phase, their implementations of the Open Finance APIs to automated functional and non-functional tests; and

II - to access example implementations of the Open Finance APIs, including at least one that simulates a Reference Participating Institution, with complete implementation of each API.

The Open Finance Portal must publish tutorials presenting in a complete, detailed, step-by-step manner, and when applicable, through code snippets and/or screenshots, how participants must interact with the Sandbox to, among other things, execute the automated tests and access the example implementations mentioned above. Any other functionality offered by the Sandbox must be accompanied by its respective usage tutorial.

6.1 SLAs of the Sandbox

The Sandbox must observe the following minimum service level:

Availability:

I - 95%, from 8:00 a.m. to 8:00 p.m. on business days, in the Federal District time zone, as defined in Article 2, item "b", of Decree No. 2,784, of June 18, 1913, with subsequent amendments; and

II - 80% during other hours.

Validation of the Production Environment

The Structure Responsible for the Governance of Open Finance must provide a validation mechanism to ensure that the production environments of participating institutions are compliant with their respective certifications.

The policy of this validation mechanism must be established by the Structure Responsible for the Governance of Open Finance and followed by participating institutions.

Monitoring of Open Finance Technology Services

The Structure Responsible for the Governance of Open Finance must provide the means to store and make available statistical data on the fulfillment of the technology service levels of participants and the shared infrastructure defined in regulation, as well as to make available their performance and availability indicators.

Open Finance participating institutions must make available quality data with sufficient detail, so that the Structure Responsible for the Governance of Open Finance can implement the functionalities set forth in this section.

Regarding individualized and nominal data of participating institutions, the following must be included, at minimum: information regarding the number of calls per API and per endpoint, including its history; the success percentage of calls, as well as their errors, by status code; the number of active consents total and per unique clients, natural and legal persons, including views by transmitter or holder (as applicable) and by receiver or initiator (as applicable), including its history; and conversion rates of consent with detail of each stage of its generation, including views by transmitter or holder and by receiver or initiator.

The data must be reported with a minimum frequency that allows verifying compliance with service level agreements:

I - of Participants' APIs; and

II - of the shared infrastructure elements.

The data reported by participating institutions are declaratory and the responsibility of each institution individually.

These statistical data must also be made available in a public area of the Open Finance Portal in Brazil in the form of an easily viewable dashboard, which allows the general public to grasp this performance quickly and clearly.

The dashboard must allow viewing data in, at minimum, two different levels:

I - consolidated view: with the averages of the most important indicators, highlighting the best and worst performances of the month in terms of availability; and

II - customized/comparative view: with the possibility of sorting by value (ascending and descending), search, and selection of multiple parameters by the user, such as participating institution name, endpoint, period, among others.

In both views, the dashboard must include a graphical/visual resource, such as the use of icons or symbols, that allows assessing the indicator's performance relative to the minimum regulatory requirement. The views must allow the general public to nominally identify the performance of each of the participating institutions.

Given the broad scope of Open Finance participants, any charts that list all participating institutions must provide a search tool to assist the user in locating a specific institution on the chart, if desired.

The results must be downloadable in different formats.

The metrics, units of measurement, and definitions used must be clear to the user, as well as any limitations, exclusions, or changes regarding the calculation basis.

The monitoring of Open Finance technology services may collect and store other relevant metrics aiming to ensure the proper functioning of the ecosystem. The collection and storage of customer data, even if anonymized or pseudonymized, are prohibited.

Brasília, March 3, 2023.

NOTE
270/2023-BCB/DENOR, OF March 1, 2023

Justifies proposal for the issuance of a normative instruction that establishes version 3.0 of the Manual of Services Provided by the Structure Responsible for the Governance of Open Finance.

Dear Heads of
Denor, Desuc, Desup, and Deinf,

This Note justifies the proposal for the issuance of a normative instruction by the Department of Financial System Regulation (Denor), the Department of Supervision of Cooperatives and Non-Bank Institutions (Desuc), the Banking Supervision Department (Desup), and the Information Technology Department (Deinf), using the attribution conferred upon them by Article 23, item I, letter "a", of the Internal Regulations of the Central Bank of Brazil, annexed to Ordinance No. 84,287, of February 27, 2015, and observing item IX of Article 51 of Joint Resolution No. 1, of May 4, 2020.

2.                Regarding this, the proposal  
   

treats the issuance of a normative instruction that establishes version 3.0 of the Manual of Services Provided by the Structure Responsible for the Governance of Open Finance, revoking Instruction Normative BCB No. 133, of July 22, 2021, which publishes version 2.1 of the Manual of Services Provided by the Structure Responsible for the Governance of Open Finance.

3.                The changes  
   

refer to the substitution of the expression Open Banking by Open Finance, according to changes made by Joint Resolution No. 4, of March 24, 2022; to the creation of new types of incidents regarding the targets for incident response without unavailability; to the adaptation of sections to the current stage of Open Finance; to the greater detail regarding the opening of tickets in the Service Desk; to the creation of sections on verification of the production environment and on monitoring of Open Finance technology services, considering updates made to the attributions of the Participants Directory by BCB Resolution No. 294, of February 23, 2023, which altered BCB Resolution No. 32, of October 29, 2020.

4.                Finally, in compliance  
   

with the provision of Article 5 of Law No. 13,874, of September 20, 2019, Decree No. 10,411, of June 30, 2020, determines that proposals for normative acts of general interest of economic agents formulated by bodies and entities of the direct, autarchic, and foundation federal public administration, as well as by collegial bodies through the body or entity responsible for providing them administrative support, must be preceded by a Regulatory Impact Analysis (RIA).

5.                However, it is worth  
   

highlighting that the proposed changes and clarifications do not significantly impact Open Finance, as they refer to tools created by the governance structure, a simple change of attribution of the participants directory to the governance structure itself, and flexibility of some service level agreement requirements. In this sense, according to Article 4, items III and VII, of the aforementioned Decree, the normative act now proposed is exempt from the preparation of an RIA as it is considered low impact or as it reduces regulatory requirements.

For your consideration.

Mardilson Fernandes Queiroz Rodrigo Monteiro Consultant of Denor Deputy Head of Desuc

Ricardo Seviere Zeni Aristides Andrade Cavalcante Neto Deputy Head of Desup Deputy Head of Deinf

Agreed.

João André Calvino Marques Pereira Harold Paquete Espínola Filho Head of Denor Head of Desuc

Belline Santana Haroldo Jayme Martins Froes Cruz Head of Desup Head of Deinf