Normative Instruction BCB No. 588 — Publishes Version 4.0 of the Manual of Services Provided by the Open Finance Governance Structure

INSTRUÇÃO NORMATIVA BCB
Nº 588, DE 31 DE JANEIRO DE 2025

Publishes version 4.0 of the Manual of Services Provided by the Open Finance Governance Structure.

The Heads of the Department of Regulation of the Financial System (Denor), the Department of Supervision of Cooperatives and Non-Bank Institutions (Desuc), the Banking Supervision Department (Desup) and the Information Technology Department (Deinf), in use of the attribution conferred upon them by art. 23, item I, letter "a", of the Internal Regulations of the Central Bank of Brazil, annexed to Resolution BCB No. 340, of September 21, 2023, based on art. 3rd, item III, of Resolution BCB No. 32, of October 29, 2020,

R E S O L V E M :

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

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

Art. 2nd Is revoked Normative Instruction BCB No. 359, of March 3, 2023, published in the Official Gazette of the Union on March 7, 2023.

Art.
3rd This Normative Instruction enters into force on the date of its publication.

RENATO
KIYOTAKA UEMA ADALBERTO FELINTO DA CRUZ JUNIOR Chief of Denor, substitute Chief of Desuc

BELLINE
SANTANA CAIO MOREIRA FERNANDES Chief of Desup Chief of Deinf

ANNEX TO NORMATIVE INSTRUCTION BCB NO. 588, OF JANUARY 31, 2025

Manual of Services
Provided by the Governance Structure of Open Finance Version 4.0

Summary of changes

Date	Version	Description of changes
.../1/2025	4.0	Section 2: update of the subsection regarding identity and access management.
Section 3: reorganization and greater detail given to the section relative to the Service Desk.
Section 5: update of the subsections referring to the developer area and the participant area.
Section 8: simplification of the text, considering the edition of the Open Finance Monitoring Manual.

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 Portal of Open Finance in Brazil, in the Developer Area.

Suggestions, criticisms or requests for clarification of doubts related to the content of this document can 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
Resolution BCB No. 32, of 2020	https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolu%C3%A7%C3%A3o%20BCB&numero=32

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 Council of Brazil and the Central Bank of Brazil, and by Resolution BCB No. 32, of October 29, 2020, this responsibility fell to the Governance Structure of Open Finance.

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 credentials of participants.

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

The support channels for the services provided by the Governance Structure of Open Finance and for forwarding demands to participating institutions are also important for the fulfillment of technical support needs in the operationalization of Open Finance. They constitute focal points for reception and forwarding of 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 said platform must observe confidentiality, integrity, availability of data and systems of information used, as well as legislation and current regulation.

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

The Governance Structure of Open Finance must, furthermore, make available a test environment (Sandbox) of application programming interfaces (APIs), with the objective of providing support structure to development and testing by participating institutions, and a validation service in production with a view to checking the compliance and the registration of APIs of participating institutions and guarantee that the productive environments of participating institutions are adherent to their respective certifications.

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

In this sense, these are just some of the services provided by the Governance Structure of Open Finance with the objective of enabling Open Finance 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 of 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 function by the Central Bank of Brazil registers and formalizes its participation in the environment of Open Finance, performing its integration to begin sharing data or services with other participating institutions, through APIs.

The Participant Directory must contain 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 - identity and application authorization management: identification and authorization of applications of participating institutions; and

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

2.1
Identity and Access Management

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

The Participant Directory must collect the necessary information so that institutions are registered as participants in Open Finance and allow representatives of these institutions to update the information necessary for their full participation, according to their respective participation modalities.

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

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

2.2
Application Identity and Authorization Management

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

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

2.3
Directory Information Management

The Participant Directory must have functionalities that enable listing participants, querying and changing their data, their representatives and their contacts, as well as the history of modifications performed. These changes must be capable of notification to participants.

Regarding the data APIs accessible to the public relating to customer 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, through API or files, that allow identifying participants that implement a certain API or endpoint, as well as listing the APIs and endpoints implemented by a participant. Regarding the other APIs of that manual, an API must be provided that implements analogous queries, in this case restricted to participating institutions of Open Finance.

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

2.4 Compliance Testing and API Registration

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

The execution of compliance tests is performed in an environment made available by the Governance Structure of Open Finance, which also takes care of certifying the results.

An implementation of an API version of Open
Finance can only be registered in the productive environment of the Directory of Participants if it has been certified in compliance tests.

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

Results of compliance tests of APIs already performed must be made available in a public area of the Portal of Open Finance 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:

Response time of percentile 95 in, at most,
1,500ms.

3.
Service Desk

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

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

I

• general question resolution;

II

• support in issuing tickets;

III

• notification support; and

IV

• support for services provided by the Governance Structure of Open
  Finance.

3.1
General Question Resolution

Two areas must be provided for resolving 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 every time a major version of APIs is released, 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 profile of the requester.

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

3.2
Support in Opening Tickets

3.2.1 Ticket Opening

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

I - by the Governance Structure of Open
Finance;

II - by participating institutions;

III - by developers; and

IV - by citizens.

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

In the case of receipt of citizen demands that involve complaints against participating institutions, the requester must be oriented to seek out the involved institution first and, if unable to 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 through a specific API.

Upon opening a ticket, a protocol number must be generated, which must be informed to the requester. At this moment, the deadline for attending to the demand will start counting.

3.2.2
Types of Tickets

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

I - request: request for information, request for services or suggestion of improvements;

II - incident: communication of failures or degradation of quality in services; and

III - monitoring: notification or demand for adjustments resulting from the monitoring process.

The service channel of the Service Desk must be used as the preferred form of communication for tickets of request and mandatory for tickets of incident and of monitoring.

3.2.2.1
Request

3.2.2.1.1
Request for information or services

The Governance Structure of Open Finance can request information from participating institutions, with a view to subsidizing the fulfillment of its attributions within the scope of Open Finance.

Participating institutions, developers and citizens can request information from the Governance Structure of Open Finance.

Participating institutions and developers can request the provision of services by the Governance Structure of Open Finance.

3.2.2.1.2
Suggestion of improvements

Participating institutions and developers can suggest improvements to the Governance Structure of Open Finance.

3.2.2.2
Incidents

Participating institutions, the Governance Structure of Open Finance and developers can open incident tickets.

tickets opened by developers are limited to customer service APIs and products and services of participating institutions.

In the case of tickets opened by the Governance Structure of Open Finance that are inserted in the monitoring process, they must also follow the provisions of subsection 3.2.2.3.

After closing the ticket, the participating institution responsible for attending must analyze the need for additional adjustments in its implementation, with a view to correcting the root cause of the object of the ticket, or in its internal controls to mitigate new analogous occurrences. This procedure must be documented in a report, updated at the time of conclusion of said adjustments, and kept available to the Central Bank of Brazil.

3.2.2.2.1
Incidents without unavailability

With the exception of cases framed in the category "Degradation of service quality", tickets must be opened, initially, in the category "Non-conformity Error".

If the participating institution responsible for attending believes that the specific case is framed in a distinct category than the one that best defines the concrete case, it is possible to request reclassification of the ticket.

3.2.2.2.1.1
Degradation of service quality

This incident is characterized by a decrease in performance or response capacity of the participating institution's resources.

This type of ticket can be opened by participating institutions or by the Governance Structure of Open Finance against participating institutions or against the Governance Structure of Open Finance. When the ticket is opened by a participating institution, the degradation can be characterized considering only the calls between the two participating institutions involved, without needing to characterize a generalized degradation of the participating institution responsible for attending.

3.2.2.2.1.2
Non-conformity Error

This incident is characterized by errors in the customer journey or in APIs and associated artifacts.

This type of ticket can be opened by participating institutions, developers or by the Governance Structure of Open Finance against participating institutions or against the Governance Structure of Open Finance.

3.2.2.2.1.3
Other Errors

This incident is characterized by errors related to eventual ambiguities or cases not foreseen in specifications or technical documentation.

This type of ticket applies only by reclassification, requiring adequate justification.

3.2.2.2.2
Incidents with Unavailability

These incidents refer to any error that causes unavailability in the Open Finance environment, including the environment of APIs and associated artifacts, of participating institutions.

This type of ticket can be opened by participating institutions or by the Governance Structure of Open Finance against participating institutions or against the Governance Structure of Open Finance.

3.2.2.3
Monitoring

The Governance Structure of Open Finance can notify participating institutions, demand adjustments to regularize non-conformity situations and demand actions related to different aspects of the monitoring process.

3.2.2.3.1
Indications of Non-Conformity - Notification

The Governance Structure of Open Finance can open this ticket to notify a participating institution regarding an indication of non-conformity regarding one of the monitored items, as per the Open Finance Monitoring Manual. Upon opening the ticket, evidence of the indication of non-conformity or the location where such evidence is available for consultation must be presented.

The participating institution must evaluate the situation and, if it believes there is no non-conformity, present a justified argument to the Governance Structure of Open Finance.

3.2.2.3.2
Indications of Non-Conformity - Demand for Action

The Governance Structure of Open Finance can open this ticket to demand that a participating institution perform adjustments to regularize non-conformity situations regarding one of the monitored items, as per the Open Finance Monitoring Manual.

The participating institution must evaluate the situation and, if it believes there is no non-conformity, present a justified argument to the Governance Structure of Open Finance.

If adjustments are made within the target of attending the ticket, this indication of non-conformity will not be considered for purposes of applying the measures referred to in the Open Finance Monitoring Manual, except in specific situations established in normative act.

3.2.2.3.3
Consolidation of Non-Conformities

The Governance Structure of Open Finance can open this ticket to consolidate non-conformities occurred in the reference month.

3.2.2.3.4
Presentation of Report of Non-Conformity Situations

According to the Open Finance Monitoring Manual, within the scope of the measure application flow, the Governance Structure of Open Finance must demand a participating institution that presented non-conformities to deliver a report of non-conformity situations.

3.2.2.3.5
Presentation of Adaptation Plan

According to the Open Finance Monitoring Manual, within the scope of the measure application flow, the Governance Structure of Open Finance must demand a participating institution to present an adaptation plan so that non-conformity situations are solved, as well as mitigating elements for the prevention of new occurrences.

3.2.2.3.6
Presentation of Specific Evaluation on Conversion Rate

According to the Open Finance Monitoring Manual, within the scope of the measure application flow, the Governance Structure of Open Finance must demand that the participating institution present a specific evaluation with diagnosis regarding its conversion rate and, if necessary, a more complete diagnosis on the conversion rate of the non-conforming participating institution issued by an independent specialized company.

3.2.3 Ticket Management

3.2.3.1 Principles for Ticket Management

---

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

3.2.3.2 Classification of maximum resolution time for tickets

The maximum resolution time for a ticket must be associated with it before being directed to participating institutions. These timeframes are defined in item 3.2.3.4.

3.2.3.3 Ticket audit trail

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

3.2.3.4 Maximum timeframe targets for ticket handling

3.2.3.4.1 Requests

The maximum timeframe targets for handling tickets by request category are:

I - requests for information or services: up to five business days;

The timeframe refers to the provision of the requested information, the rendering of services, or the indication of the appropriate channel for obtaining the information.

II - suggestions for improvements: up to ten business days;

The timeframe refers to the provision of the result of a preliminary analysis of the proposal, also informing the estimated implementation timeframe, if applicable.

3.2.3.4.2 Incidents

3.2.3.4.2.1 Incidents without service unavailability

The maximum timeframe targets for handling tickets by category of incidents that do not cause service unavailability are:

I - degradation of service quality: up to two business days;

II - non-conformance error: up to ten business days; and

III - other errors: up to thirty business days.

The timeframes referred to in this subsection include the analysis and implementation of definitive or workaround corrections to repair the failures they refer to.

All tickets related to incidents must be continuously analyzed by the Open Finance Governance Structure, in order to evaluate any adjustment in specifications and documentation, as well as improvement in coverage or validation of certification tests.

The Central Bank of Brazil may establish differentiated timeframes for any specific cases, due to analysis regarding the effort required and the impact on the citizen.

3.2.3.4.2.2 Incidents with service unavailability

The targets for handling tickets related to incidents that cause service unavailability are up to 2.5 hours (two and a half hours) for service restoration. Once the service is restored, the ticket related to the incident must be closed within one business day.

3.2.3.4.3 Monitoring

The maximum timeframe targets for handling tickets related to monitoring are:

I - indications of non-conformance - notification: there is no maximum timeframe target;

II - indications of non-conformance - action demand: according to subsection 3.2.3.4.2;

III - consolidation of non-conformities: up to five business days for analysis and possible contestation;

IV - presentation of a report on non-conformance situations: up to five business days after the end of the analysis of item III;

V - presentation of an adequacy plan: up to ten business days;

VI - presentation of a specific evaluation on conversion rate: up to ten business days; and

VII - presentation of a specific evaluation on conversion rate by an independent specialized company: up to ninety calendar days.

3.2.3.5 Calculation of ticket timeframes

The timeframes refer to the total handling time, from the generation of the protocol until the closure of the ticket, encompassing the time spent in the Service Desk and in the demanded participants. If there is a need to complement information regarding tickets, the calculation of the timeframe is suspended until the aforementioned information is provided.

When requesting complementary information, the institution responsible for handling must ensure that the information is necessary and unknown for the specific scenario under analysis. If the information is derivable from other information provided in the ticket, it is not classifiable as unknown.

3.2.3.6 Ticket updates

The participating institution responsible for handling must timely update the expected implementation date, even if later than the established handling target, in all tickets that require implementation.

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

3.2.3.7 Ticket closure

The participating institution responsible for handling must record the root cause of the ticket object and describe the adjustments made.

It is prohibited to close a ticket referencing a future event, meaning that said closure must occur after the publication of any adjustment in the implementation.

According to the principles for ticket management, it is necessary that there be an evaluation by the Open Finance Governance Structure, to ensure that the demand that caused it has been resolved.

For tickets associated with the monitoring process, this evaluation can be carried out before its closure. For other tickets, such evaluation must be carried out after its closure, and if the Open Finance Governance Structure deems it necessary to deepen the analysis, another ticket must be opened requesting additional provisions, clarifications, or evidence.

If it is detected that the demand of the original ticket had not been adequately resolved at the time of its closure, such ticket must be reopened with recalculation of its maximum timeframe target for handling, regardless of the elapsed time.

For example, if a ticket was closed two business days after its target and it is detected that the demand had not been adequately resolved, after recalculation, the new target for such ticket must be two business days prior to the reopening date.

3.2.3.8 Reopening of tickets

The ticket can be reopened by the requester if the demand has not been adequately resolved, according to timeframes defined by the Open Finance Governance Structure.

The reopening of the ticket can be demanded at any time by the Central Bank of Brazil.

The recalculation of the maximum timeframe target for handling must be carried out according to what is defined in item 3.2.3.7.

3.3 Support for notifications

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

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

3.3.1 Types of notifications

Participating institutions and the Open Finance Governance Structure must report the following information:

I - timely updates on API unavailability;

II - timely updates on degradation of service quality;

III - notifications on scheduled unavailabilities; and

IV - notifications on service restoration.

The Open Finance Governance Structure may use the functionality referred to in this subsection for conducting surveys and for communication with participating institutions.

The Open Finance Governance Structure must detail the information, forms, and timeframe for notifications, and this detailing must be provided in the Open Finance Portal in Brazil.

3.4 Support for services provided by the Open Finance Governance Structure

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

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 services provided by the Open Finance Governance Structure.

3.5 SLAs of the Service Desk

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, at most, 1500ms.

4. Dispute Resolution Platform

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

4.1 SLAs of the Dispute Resolution Platform

The Dispute Resolution Platform shall 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.

5. 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 in the Open Finance Portal in Brazil must guarantee accessibility and meet the Web Content Accessibility Guidelines (WCAG) standard, and all informational content must take into account the regional diversity of the country (rural/urban, capital/inland), as well as diversity in the Brazilian population regarding race, gender, age group, and disability.

5.1.2 Language and timeliness

The language used in different areas of the Portal must be adequate to 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 moment and providing the necessary information to understand and use it. Especially in the citizen area, there must be 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, which evolves over time, in line with the development of Open Finance.

The following content must be made available mandatorily:

I - API specifications;

II - registration specifications;

III - security profile;

IV - Sandbox environment specifications, including related tutorials;

V - conformity test and production environment validation specifications;

VI - policy documentation;

VII - known specification problems;

VIII - operational guidelines;

IX - customer experience guidelines;

X - Participants Directory technical guidelines;

XI - calendar;

XII - participant implementation guides;

XIII - frequently asked questions (FAQ);

XIV - specification history; and

XV - 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 and in the documentation of the Open Finance Governance Structure.

The Open Finance Governance Structure must notify participating institutions about changes in the content of the items referred to in items I to XII of this subsection.

5.3 Citizen Area

The Citizen Area must be an open environment, focused on the citizen's experience, using language adequate 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 - Open Finance Governance Structure: 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: material in visual format (infographic or, preferably, video) that clarifies people on all steps for data sharing, including consent, authentication, and confirmation stages; for payment initiation and for forwarding credit operation proposals. The content must explain the terms used during the journey and the fields requiring completion, as well as address the journey relative 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 any fraud;

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

VI - guidance for submitting demands: in addition to being in the FAQ, they must be made available, in a visible area of the portal, guidance that clarifies the citizen on whom to turn to in cases of doubt about Open Finance or complaint about participating institutions. These guidelines must cover, among others, cases where the demand refers to entities involved in sharing;

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

a) the search mechanism must, mandatorily, provide search by, at least, 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 Open Finance Governance Structure 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 context of Open Finance, with a view to facilitating consumer understanding.

Additionally, specific content for legal entities must be planned, with explanations 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 aimed at 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, which 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 scope of participation and which are the mandatory and voluntary institutions;

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

III - implementation: future implementation schedule established by the Central Bank of Brazil;

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

V - Service Desk: general information, functioning, planned SLAs, types of demands received, registration guidelines, and access method;

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

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

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

IX - data scope: explanation on the data scope to be shared by participating institutions;

X - service scope: explanation on the service scope to be shared by participating institutions; and

XI - frequently asked questions of 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 Open Finance Governance Structure must make available a structure, hereinafter referred to as Sandbox, which allows participants, at minimum:

I - submit, still in development time, their implementations of Open Finance APIs to automated functional and non-functional tests; and

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

The Open Finance Portal must contain 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 automated tests and access the example implementations mentioned above.

6.1 SLAs of the Sandbox

The Sandbox must observe the following minimum service level:

Availability:

I - 95%, from 8 am to 8 pm on business days, in the Federal District time zone, as defined in art. 2º, letter "b", of Decree No. 2,784, of June 18, 1913, with subsequent amendments; and

II - 80% in other hours.

7. Production Environment Validation

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

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

8. Open Finance Monitoring

The Open Finance Governance Structure must carry out ecosystem monitoring according to the Open Finance Monitoring Manual.

This process includes making information available so that participating institutions can manage non-conformance situations and disseminate statistical data and indicators on the performance of participating institutions in Open Finance.

9. Transitional Rules

Considering that the implementation of evidence availability regarding some of the monitored items, according to version 2.0 of the Open Finance Monitoring Manual, contained in the annex to Normative Instruction BCB No. 575, of December 20, 2024, will only occur starting from July 1, 2025, the obligation to present evidence of the indication of non-conformance or the location where such evidence is available for consultation, referred to in subsection 3.2.2.3.1 Indications of non-conformance - notification, relative to monitored items whose implementation of evidence availability occurs only starting from July 1, 2025, also comes into force from that date.

Due to the need for improvements in the teams of the Open Finance Governance Structure responsible for monitoring, the changes related to the evaluation to be carried out by the Open Finance Governance Structure during the ticket closure process, referred to in subsection 3.2.3.7, come into force starting from July 1, 2025.

Brasília, January 31, 2025.

NOTE 54/2025-BCB/DENOR, OF JANUARY 30, 2025

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

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

This Note justifies the proposal for issuance of a normative instruction by the Financial System Regulation Department (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 art. 23, item I, letter "a", of the Internal Regulations of the Central Bank of Brazil, annexed to BCB Resolution No. 340, of September 21, 2023, based on art. 3º, item III, of BCB Resolution No. 32, of October 29, 2020.

2. Regarding this, the proposal concerns the issuance of a normative instruction that establishes version 4.0 of the Manual of Services Provided by the Open Finance Governance Structure, revoking BCB Normative Instruction No. 359, of March 3, 2023, which publishes version 3.0 of the Manual of Services Provided by the Open Finance Governance Structure.

3. The changes refer to the reorganization and greater detailing given to the section relative to the Service Desk, bringing more flexibility regarding targets for incident handling, new rules for closing tickets, and revision of sections on the Open Finance Portal in Brazil and on monitoring, considering that, due to the relevance of the topic for the advancement of Open Finance, the Open Finance Monitoring Manual was created.

4. It is worth noting that, by virtue of art. 5º of Law No. 13,874, of September 20, 2019, proposals for issuance and alteration of normative acts of general interest to economic agents or users of services provided, issued by an organ or entity of the federal public administration, including autarchies and public foundations, must be preceded by the realization of regulatory impact analysis (RIA), which will contain information and data on the possible effects of the normative act to verify the reasonableness of its economic impact.

5. For its part, Decree No. 10,411, of June 30, 2020, which regulates this Law, in its Article 4, item II, establishes that the AIR may be waived in cases of normative acts that reduce requirements, obligations, restrictions, requests, or specifications with the objective of reducing regulatory costs, applicable to the exclusion of measures capable of being applied by the Open Finance Governance Structure and other regulatory flexibilities carried out.

6. Regarding the new rules for closing tickets, it is highlighted that this Central Bank has already been discussing this matter in discussions held in the Open Finance Governance Structure, and that, currently, for some tickets, there is already monitoring similar to what will be required with the changes present in this new version of the Manual of Services provided by the Open Finance Governance Structure, so that such adjustments can be considered low impact and, thus, are exempt from AIR, according to Article 4, item III, of said Decree No. 10,411, of 2020. It is worth noting that, according to Article 9-A, § 2, the discussions regarding these changes took place within the Open Finance Governance Structure, an environment in which all institutions participating in Open Finance are represented, guaranteeing social participation.

7. Therefore, considering the above paragraphs, the normative instruction now proposed is exempt from AIR.

                    For your consideration.
   
                    Mardilson Fernandes  
                    Queiroz                        Ivens Arua Neves de Miranda Consultant of Denor                                          Deputy Chief of Desuc
   
                    Ricardo  
                    Sivieri Zeni                                             Veruska Rocha Aragão Deputy Chief of Desup                                    Deputy Chief of Deinf
   
                    In agreement.
   
                    Renato  
                    Kiyotaka Uema                                         Adalberto Felinto da Cruz Junior Chief of Denor, substitute                                  Chief of Desuc
   
                    Belline  
                    Santana                                                      Caio Moreira Fernandes Chief of Desup                                                     Chief of Deinf