BCB Normative Instruction No. 574

BCB NORMATIVE INSTRUCTION No. 574, OF 20 DECEMBER 2024

Normative document revoked, as of 1/7/2025, by BCB Normative Instruction No. 615, of 6/5/2025.

Discloses version 6.0 of the Open Finance API Manual.

The Heads of the Department of Regulation of the Financial System (Denor) and of the Department of Information Technology (Deinf), in the exercise of the attributions conferred upon them by art. 23, item I, subitem "a", of the Internal Rules of the Central Bank of Brazil, annexed to BCB Resolution No. 340, of 21 September 2023, based on art. 3, item II, of BCB Resolution No. 32, of 29 October 2020,

R E S O L V E :

Art. 1 This Normative Instruction discloses version 6.0 of the Open Finance API Manual, which must be observed 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 of the Central Bank of Brazil's website on the internet and on the Open Finance Portal in Brazil, maintained by the Open Finance Governance Structure referred to in art. 44, § 1, of Joint Resolution No. 1, of 4 May 2020.

Art. 2 Normative Instruction No. 456, of 29 February 2024, published in the Official Gazette of the Union of 1 March 2024, is revoked.

Art. 3 This Normative Instruction enters into force on 1 July 2025.

RENATO KIYOTAKA UEMA HAROLDO JAYME MARTINS FROES CRUZ Head of Denor, substitute Head of Deinf

ANNEX TO BCB NORMATIVE INSTRUCTION No. 574, OF 20 DECEMBER 2024

Open Finance API Manual Version 6.0

Revision history

Date

Version

Description of changes

20/12/2024

6.0

Section 1: update of definitions.

Subsection 5.1.2: details on controlling the volume of requests with HTTP status code 529.

Terms of Use

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

The manual will be revised and updated periodically in order to preserve compatibility with the regulations, as well as to incorporate improvements arising 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 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

The 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

Hypertext Transfer Protocol – HTTP/1.1

https://tools.ietf.org/html/rfc2616

ISO 20022

https://www.iso20022.org/

OpenAPI Specification

https://github.com/OAI/OpenAPI-Specification/blob/3.0.0/versions/3.0.0.md

Representational State Transfer

https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

1. Introduction

Open Finance is intrinsically linked to APIs, interfaces through which it is possible to interconnect the different systems of institutions. When made available by participants, APIs must satisfy conditions such as standardization, robustness and security, so that the objective of sharing data and services is satisfactorily met.

In this sense, this manual aims to define the main aspects related to the specifications and implementations of the APIs that integrate Open Finance in the Country, observing the provisions of Joint Resolution No. 1, of 4 May 2020, and BCB Resolution No. 32, of 29 October 2020.

This manual addresses aspects such as: data exchange format, interface design, data transmission protocol, versioning, API model and endpoints. Thus, the manual establishes general guidelines without exhausting all aspects necessary for the implementation of APIs for Open Finance. The other definitions under the responsibility of participating institutions, through the Open Finance Governance Structure, will be available on the Open Finance Portal in Brazil, where guides, tutorials and other operational information about the APIs can be found.

Throughout this manual, the use of acronyms and specific terminology to designate some everyday expressions of technology professionals will be constant. Some examples of the most frequently used, with the corresponding definitions, are as follows:

• I - API (Application Programming Interface): a set of definitions on how a system can access data or functionalities provided by another system;

• II - REST (Representational State Transfer): architectural software style;

• III - RESTful API: API that adheres to the constraints of the REST architectural style;

• IV - OpenAPI: specification language for RESTful APIs;

• V - endpoint: element of an OpenAPI specification on which operations can be executed to access data or functionalities;

• VI - HTTP (Hypertext Transfer Protocol): protocol for hypermedia, distributed and collaborative systems;

• VII - operation: element of an OpenAPI specification that declares a valid way to access an endpoint, informing which HTTP method (GET, POST etc.) to use, names and types of parameters;

• VIII - API provider: institution that makes an API available to be consumed by other institutions. In the "Payment Initiation Services" APIs, it is the account-holding institution; in the case of "Registration and Transactional Data" APIs, it is the data-transmitting institution;

• IX - API consumer: institution that consumes an API provided by other institutions. In the "Payment Initiation Services" APIs, it is the payment-initiating institution; in the case of "Registration and Transactional Data" APIs, it is the data-receiving institution; and

• X - API gateway: it is a service, device or proxy that acts as an intermediary, accepting, transforming, forwarding and managing API traffic to back-end services. It allows communication and data transfer between endpoints and can be useful when there are multiple platforms that need to interact with each other without granting direct access to each other's APIs. In addition, an API gateway can handle tasks such as authentication, rate limiting, caching and request/response transformation, reducing the load on the application and improving overall security and system performance.

2. Open Finance APIs

The APIs to be provided by institutions within the scope of Open Finance must be categorized into one of the following types:

• I - Open Data;

• II - Registration and Transactional Data;

• III - Services; and

• IV - Reports and Metrics.

3. Principles

The principles below guide the specifications and implementations of Open Finance APIs.

3.1 User experience

The specifications and implementations of the APIs must offer a good experience for users, whether they are implementers or consumers of the APIs.

3.2 Technology independence

The API specifications must be technology-independent and may be implemented and consumed in different languages, such as Java, JavaScript and Python; or platforms, such as Windows, Linux, Android and iOS.

3.3 Security

Procedures and controls (digital signatures, encryption, authentication and authorization protocols, among others) must be adopted in order to protect Open Finance participants, their clients, API consumers and other ecosystem participants, observing compatibility with the institution's cybersecurity policy.

3.4 Extensibility

In the future, the APIs may be evolved to meet new use cases and, therefore, must be specified and implemented in a way that allows and facilitates extensions such as, for example, new endpoints, operations, parameters and properties.

3.5 Open standards

Open standards must be adopted whenever possible.

3.6 RESTful APIs

The API specifications must meet the constraints of the REST architectural style whenever possible.

3.7 ISO 20022

The API responses must be based on the ISO 20022 message elements and components (https://www.iso20022.org/). The particular cases in which adoption of the ISO standard is not possible or recommended may undergo adjustments, provided they are specifically pointed out for evaluation by the Central Bank of Brazil.

3.8 Declaration of mandatory status

All elements that make up the API specifications (endpoints, operations, parameters, response properties, etc.) must be explicitly declared as "Mandatory", "Optional" or "Conditional", if they are mandatory only under certain conditions.

Features that are optional for implementation by the transmitter must be explicit in their documentation, both to properly inform the transmitter audience, which may or may not implement the feature, and the consumer audience, which may not find the feature available in some transmitters.

4. Definitions and recommendations

The definitions and recommendations below must be observed by the specifications and implementations of Open Finance APIs.

4.1 Specifications

The APIs must be specified with version 3.0.0 or higher of the OpenAPI language (https://github.com/OAI/OpenAPI-Specification/blob/3.0.0/versions/3.0.0.md).

The API specifications must be analyzed with version 5.9.0 or higher of the free and open-source software Spectral (https://github.com/stoplightio/spectral/tree/v5.9.0). The analysis must be performed with the default ruleset of this version of Spectral. The result of the analysis must not contain errors or warnings.

It is recommended that version 3.0.25 or higher of the free and open-source software Swagger Codegen (https://github.com/swagger-api/swagger-codegen/tree/v3.0.25) be used to generate client code and also the initial code for API implementations from their specifications. It is recommended that the generated code be analyzed in order to identify possible OpenAPI language features that were used in the specifications but that are not adequately supported by Swagger Codegen and, possibly, by other software that works with OpenAPI specifications. If this occurs, one must assess whether it is not possible to change the specifications to no longer use these features.

Example implementations of the APIs must be made available. The data returned by them need not be real data nor voluminous, since the purpose of making them available is to give the Central Bank of Brazil, the implementers and the consumers of the APIs one more resource to resolve any doubts about their specifications and implementations. It is recommended that the initial code for API implementations mentioned above be complemented so as to constitute the example implementations.

The information made available in the data dictionaries must be consistent with the associated OpenAPI specifications.

All implemented API endpoints must be previously registered in the participants directory.

All registered endpoints that return lists, if the parameters are valid, must return the associated list, even if it is an empty list. Error 404 is not considered a valid return, in this scenario, when there is no associated information.

4.2 Versioning

The versions of the API specifications will be typified as "major", "minor", "patch" and "release candidate" according to the following criteria:

• I - major: includes new implementation features, changes and corrections to be incorporated, which may be incompatible with previous versions, for example, v1.0.0 and v2.0.0;

• II - minor: small changes to existing elements, maintaining compatibility with versions up to the immediately previous major, for example, v1.1.0 and v1.2.0;

• III - patch: clarifications to "minor" specifications, do not include functional changes, for example, v1.1.1, v1.1.2; and

• IV - release candidate: pre-release versions of any future version of type "patch", "minor" or "major", for example, v1.0.0-rc and v1.0.0-rc2.

The Open Finance Governance Structure, referred to in art. 44, § 1º, of Joint Resolution No. 1, of 2020, may release new versions of the APIs.

The Central Bank of Brazil may define:

• I - the implementation schedule for new versions of the API specifications and certification of participating institutions; and

• II - the typification of certain changes as "minor" or "patch" regardless of the criteria defined in items I to IV of this subsection.

Changes made to the specification of an API must always be documented with a new versioning of this specification.

Finally, access credentials associated with the APIs must be agnostic to their versions.

4.3 Open Finance Portal in Brazil

The website referred to in art. 15 of BCB Resolution No. 32, of 2020, must contain definitions and supplementary recommendations not present in this manual, as well as other artifacts necessary for the specification, implementation and consumption of Open Finance APIs. All definitions and supplementary recommendations and artifacts published on the portal must be in accordance with this and the other Open Finance manuals.

4.4 Schedule

The Open Finance Portal must list the APIs in production, their current versions, dates on which they entered production, link to their specifications and list of changes since the last publication. It must also present the API homologation schedule, indicating version, disclosure date, expected date of entry into production and other relevant information.

4.5 Change logs

All previously published versions of the APIs must be listed on the Open Finance Portal, together with their respective change logs and periods in which they were in production.

4.6 Supplementary definitions

The Open Finance Governance Structure must establish and publish on the Open Finance Portal a style guide for API specifications containing definitions and recommendations for the following elements:

• I - structure of Uniform Resource Identifiers (URIs);

• II - HTTP headers;

• III - HTTP status codes;

• IV - conventions for request and response bodies;

• V - naming conventions;

• VI - common data types;

• VII - pagination; and

• VIII - identifier stability.

4.7 Change management process

The Open Finance Governance Structure must establish and publish on the Open Finance Portal the process it will adopt to manage changes to the API specifications.

4.8 Tutorials

All information necessary for the development, testing and entry into production of applications or APIs in Open Finance must be available in tutorials published in the Developer Area on the Open Finance Portal. Each tutorial must contain all the steps necessary for the complete development of the activity in question, such as development and use of applications and APIs, authentication and authorization, use of the Sandbox, application of conformity tests and registration in the directory. When pertinent, examples of source code or screen captures must be provided, making the process as clear as possible for all participants and interested parties.

4.9 Extensibility

The Open Finance API specifications may not give access to all data and functionalities that one or more participants wish to expose to API consumers. This may be necessary to better support use cases or enable innovations in financial products and services. To meet these and other needs, participants are allowed to implement extended versions of the APIs fully compatible with the standard API specifications that are:

• I - new endpoints;

• II - new operations on pre-existing endpoints;

• III - new parameters in pre-existing operations, provided they are optional; and

• IV - new properties in pre-existing responses.

The Open Finance Governance Structure must publish on the Open Finance Portal the definitions and supplementary recommendations related to API extensions.

All extensions implemented by participants must be listed, with their documentation referenced, in a specific section on the Open Finance Portal and available for consumption, observing the rules for reimbursement of expenses provided for in current regulations.

5. Non-functional requirements

This section presents the non-functional requirements that participating institutions must observe in the implementation of Open Finance APIs.

To assist in the definition of some non-functional requirements, it is necessary that each endpoint be classified on the Open Finance Portal according to its data update frequency, according to the options below:

• I - high frequency;

• II - medium-high frequency;

• III - medium frequency; and

• IV - low frequency

The traffic limits by origin, operational limits and response time (performance) will be defined based on this classification.

The endpoints of APIs of type "Services", of "Security" APIs (Token – OAuth 2.0 consumption (FAPI), Token – DCR/DCM) and of "Resources" and "Consent" APIs must be considered as high frequency.

It is highlighted that, especially in non-functional requirements, the term "endpoint" must consider the specific operations associated with each path. For example, the calls GET /consents/{consentId} and DELETE /consents/{consentId} represent distinct operations and, therefore, must be monitored independently.

5.1 Traffic limits

5.1.1 Limits per origin

Each endpoint implemented in Open Finance may have a restriction regarding traffic from a given origin. In APIs of the "Open Data" type, the origin is the IP from which the request originated; in authenticated APIs, it is the organizationId of the institution that made the request.

If an institution implements limits, they must respect the minimum values of Transactions per Minute (TPM), as defined below:

• I - 2,000 TPM, per endpoint and per origin, on endpoints classified as high frequency;

• II - 1,500 TPM, per endpoint and per origin, on endpoints classified as medium-high frequency;

• III - 1,000 TPM, per endpoint and per origin, on endpoints classified as medium frequency; and

• IV - 500 TPM, per endpoint and per origin, on endpoints classified as low frequency.

Applicability: Some endpoints cannot have traffic limits defined by origin, such as in APIs of the "Services" type, in "Security" APIs, and in "Resources" and "Consent" APIs. The information on whether the limit per origin is "applicable" or "not applicable" must be explicit per endpoint on the Open Finance Portal.

Requests that exceed the implemented limits must be responded to with HTTP status code 429 (Too Many Requests).

Finally, requests that exceed the limits must be disregarded in the calculation of the response time of the API implementations.

5.1.2 Global limits

The infrastructure of institutions providing APIs in Open Finance must have the capacity to handle at least 300 simultaneous requests per second (TPS).

If an institution reaches the limit of 300 TPS, in the context of Open Finance, it must expand its infrastructure capacity to enable an increase of 150 TPS to the previous limit. Such an increase must occur again each time the limit in force at that institution is reached. Any reduction may be made only if, for thirty days, the capacity to be reduced has not been used.

Requests that exceed the TPS limits must be responded to with HTTP status code 529 (Site is overloaded) and their daily volume must be less than 0.5% of valid requests, in accordance with subsection 5.4 of this Manual.

In order to comply with the maximum limit of volume of requests with HTTP status code 529, each institution must implement preventive monitoring, whose methodology is defined by the Open Finance Governance Structure and must be available on the Open Finance Portal.

The execution of the preventive monitoring process does not exempt the participating institution from emergency infrastructure increases to handle 99.5% of valid requests.

Endpoints created within the concept of extensibility, whether within new APIs or in existing APIs, must not be considered for controlling the global limit of simultaneous transactions.

Considering that the Open Finance Monitoring Manual establishes that the assessment period for the volume of requests with HTTP status code 529 is monthly, once the reference month ends, the Open Finance Governance Structure must verify whether the daily volumes of requests with HTTP status code 529 of a given participating institution in relation to its valid requests were greater than or equal to the 0.5% limit.

For the purposes of the monitoring process, a given participating institution is considered compliant if it has respected the 0.5% limit on at least 90% of the days of the reference month, rounded to the nearest whole number, provided that the daily volume of requests with HTTP status code 529 on the other days has not exceeded 5%.

Evidence of the TPS limit monitoring process must be available to the Central Bank of Brazil for a period of twelve months.

5.2 Operational limits

Participating institutions are permitted to implement a monthly access limit per endpoint and per client.

On endpoints that access resources or products, the limits will also be considered per resource or product.

Access counting must be done by:

• I - month;

• II - endpoint;

• III - most granular object referenced in the call (consent/resource/product);

• IV - client (CPF or CNPJ); and

• V - institution consuming the information.

For example: a receiving institution "A" may access an endpoint "B", accessing resource "C", of a client "D" of the transmitting institution "E", at least "N" times (or calls) successfully per month.

Applicability of operational limits: all endpoints of APIs of the Registration and Transactional Data type (as classified by type), except for endpoints of the Consent (Consents) and Resources (Resources) APIs. APIs of the Open Data, Services (such as Payment Initiation) and Security types cannot have operational limit restrictions.

The implementation of operational limits is optional for transmitting institutions, but once they are implemented, they must guarantee the minimum consumption established on the Open Finance Portal. The institution is permitted the possibility of increasing these limits, but is prohibited from implementing limits lower than those established.

The Open Finance Portal must list the minimum values of operational limits to be considered, per endpoint, which must be equal to or greater than those below, according to the frequency of use classification:

• I - 4 calls per month, for an endpoint classified as low frequency;

• II - 30 calls per month, for an endpoint classified as medium frequency;

• III - 120 calls per month, for an endpoint classified as medium-high frequency;

• IV - 240 calls per month, for an endpoint classified as high frequency; and

• V - 420 calls per month, for the following endpoints of the Accounts API: "Account balances" and "Account limits".

Only requests answered with HTTP status code 2XX (successfully) should be counted within the operational limits, and additional requests to an endpoint for pagination purposes should not be counted.

Requests that exceed the operational limits should be answered with HTTP status code 423.

All authenticated requests to endpoints subject to the operational limit must have the x-fapi-interaction-id attribute filled in their header by the data receiving institution, which must be copied by the data transmitting institution in the response headers. This objective definition aims to allow adequate tracking of divergences that may occur between data transmitting and receiving institutions associated with the operational limit.

5.3 Performance

The response time of each request must be measured, that is, the time elapsed between the receipt of a request that does not exceed the traffic limits and the moment when the request is completely answered. Additionally, this measurement must be performed in such a way that the measured times are as close as possible to the response times experienced by the requester. The measurement at the API provider institution must start when the request is received by the gateway and must end after the last byte of the response to this request is sent.

5.3.1 Performance calculation

For the purposes of calculating performance, the value of the 95th percentile and the requests to measure performance must be considered, which aims to minimize the impact of the appearance of extreme values (outliers). The value of the 95th percentile can be obtained as follows:

• I - data collection: Let R be the set of all response times of a day, where ri is the response time of the i-th request. That is, R={r1, r2, ..., rn};

• II - calculation of the 95th percentile index: the index for the 95th percentile, denoted by i95, is calculated by the formula i95 = 0.95 ∗ n, rounded to the nearest integer, and where n represents the number of requests;

• III - sorting of the data: Sort the set R in ascending order to obtain the ordered set Rord={r(1), r(2), ..., r(n)}, where r(1) is the shortest response time and r(n) is the longest; and

• IV - obtaining the value of the 95th percentile: the value of the 95th percentile, denoted by P95, is the value at index i95 in the ordered set Rord. That is, P95 = r(i95).

Considering an example in which an endpoint receives 10,555 requests in a day (that is, n = 10,555). In this case, the index for the 95th percentile will be 10,027 (i95 = [0.95 * n] = [10,027.25] = 10,027). After sorting the response time measurements in ascending order (forming the set Rord), the value of the 95th percentile (P95) for that day will be equal to the response time at position 10,027 in the ordered set Rord.

5.3.2 Service Level Agreement (SLA) of performance

In this context, the API endpoints must maintain, daily, the 95th percentile of response time at a maximum of:

• I - 1,500ms, in endpoints classified as high and medium-high frequency;

• II - 2,000ms, in endpoints classified as medium frequency; and

• III - 4,000ms, in endpoints classified as low frequency.

For example, on a day when a high-frequency endpoint receives 10,000 requests, the response time of at least 9,500 requests must be less than 1,500ms.

Additional information:

• I - response time measurements must be performed independently for each "major" version of the endpoints in production;

• II - requests with all possible return codes must be considered, except those associated with traffic limits and operational limits;

• III - this subsection does not apply to "Webhook" APIs;

• IV - provider institutions must generate and monitor their performance indicators, independently of the Metrics Collection Platform (PCM) provided by the Open Finance Governance Structure;

• V - API consumer institutions must record the response times of the APIs they consume for submission to the PCM. In them, the measurement of the response time of each request must start at the moment before the request is made and must end after the last byte is received, before any processing;

• VI - the response time value to be considered for a request is the value reported by the API consumer;

• VII - in the absence of information from consumers, information from providers will be used to calculate the performance SLA; and

• VIII - the Open Finance Governance Structure must make available additional indicators for monitoring and improving the ecosystem, which will not, at this moment, have a minimum SLA, such as:

  • a) 95th percentile of response time only for requests with status code 2XX;

  • b) 95th percentile of response time - provider - must consider all requests provided by the API provider, even when there is a difference between the information between provider and consumer;

  • c) 95th percentile of response time - consumer - must consider all requests provided by the API consumers, even when there is a difference between the information between provider and consumer;

  • d) parity index - percentage of the number of requests in "PAIRED" status in relation to the total; and

  • e) average response time up to P95 - average response time of all requests with response times lower than the P95 value.

5.3.3 Performance assessment for the purposes of the monitoring process

Considering that the Open Finance Monitoring Manual establishes that the performance assessment period is monthly, as soon as the reference month ends, the Open Finance Governance Structure must verify whether the API endpoints of the participating institutions met the performance SLAs defined in the previous section of this manual.

For the purposes of the monitoring process, an endpoint is considered compliant if it has met the performance SLA on at least 90% of the days of the reference month, rounded to the nearest whole number, provided that the P95 value of the remaining days has not exceeded the performance SLA increased by 20%.

For example:

• I - in a 30-day month, in which a high-frequency endpoint presented a P95 value below 1,500ms on 27 days and, on the remaining days, presented a P95 value between 1,500ms and 1,800ms (1,500ms * 1.2 = 1,800ms), the endpoint is compliant for the purposes of the monitoring process in that month; and

• II - in a 31-day month, in which a high-frequency endpoint presented a P95 value below 1,500ms on 28 days and, on the remaining days, presented, on at least one of the days, a P95 value above 1,800ms (1,500ms * 1.2 = 1,800ms), the endpoint is not compliant for the purposes of the monitoring process in that month.

5.4 Availability

5.4.1 Availability calculation

The availability of the Open Finance API endpoints will be calculated empirically, based on the monitoring of valid requests. "Valid requests" shall be considered as requests that return a status code in the 2XX range, 5XX range, equal to 408 or equal to 422. Valid requests can be divided into "successful valid requests" - with a status code in the 2XX range or equal to 422 - and "valid requests with error" - with a status code in the 5XX range or equal to 408.

The point-in-time availability (t) shall be calculated as the fraction of the total valid requests that each endpoint receives and those it processes successfully at each 1-minute interval. The minute intervals shall be calculated from second zero (0s:000ms) to second 59 (59s:999ms).

For example, the point-in-time availability of an endpoint for the minute 11:34, on a given day, in which there was a total of 255 successful valid requests and a total of 4 valid requests with error, is calculated as follows:

Thus, the percentage indicator is obtained for each 1-minute time window. Each 1-minute period shall be classified as "available" or "unavailable". If the "point-in-time availability" of the time window falls below 95%, this will indicate that it shall be considered "unavailable"; otherwise it shall be "available".

Periods that have no valid requests are considered "undefined" and are disregarded for the availability calculation.

The daily availability shall be calculated based on the information from the point-in-time availabilities.

For example, considering a day in which there were valid requests in 1,390 of the 1,440 possible 1-minute intervals (1 day = 24h * 60min = 1,440 time intervals) for a specific endpoint "x" of version 1, and of which 30 periods had availability below the defined availability threshold (95%), the Daily Availability of "x" v1 will be equal to:

The long-term availability shall be calculated daily as a moving average of the availabilities of the last ninety consecutive days, considering only the days on which the daily availability can be calculated (had at least one point-in-time availability different from "undefined"). That is, if in the last ninety days we have two days calculated as undefined, the average must be calculated considering only the 88 valid availabilities.

The monthly assessment must consider the long-term availability of the last day of the reference month.

5.4.2 Availability SLA

Each of the endpoints of the APIs categorized as "Open Data", "Registration and Transactional Data", "Reports and Metrics", per version, and the endpoints of the "Security" APIs "/register" and "/token", must satisfy the minimum availability requirements below:

• I - daily availability (calendar): 95%; and

• II - long-term availability (90-day moving average), measured daily: 99.5%.

The APIs classified as "Payment Initiation Services" follow what is defined in the Pix regulation.

Additional information:

• I - measurements must be taken every day, in all available 1-minute intervals, starting at the first interval (00:00:00-00:00:59) and ending at the last interval (23:59:00-23:59:59), considering Brasília time;

• II - availability measurements must be taken for each major version of the endpoints in production. For example, during coexistence periods, the v1/resources endpoint could be available in the same period in which the v2/resources endpoint would also be available. It is important that their availabilities are calculated independently;

• III - the providing institutions must generate and monitor their availability indicators, independently of the Metrics Collection Platform (PCM) provided by the Open Finance Governance Structure;

• IV - the status code to be considered for a request is the value reported by the API consumer;

• V - in the absence of information from consumers, the information from providers will be used for the calculation of the availability SLA;

• VI - scheduled unavailability does not exempt the calculation of availability in the assessed period;

• VII this subsection does not apply to "Webhook" APIs;

• VIII - the availability of endpoints that have no valid requests in the assessed period will be considered "undefined", not being subject to an SLA; and

• IX - the Open Finance Governance Structure must provide additional indicators for monitoring and improving the ecosystem that will not, at this moment, have a minimum SLA, such as:

  • a) availability calculated from the point of view of the API provider - must consider the information provided by the API provider; and

  • b) availability calculated from the point of view of the API consumer - must consider the information provided only by the API consumers, classified in the PCM as "PAIRED" or "SINGLE".

5.5 Timeout

Standardization of the provider response time timeout and the consumer response time at fifteen seconds.

Requests that exceed the provider's timeout limit must be answered with the HTTP status code 504 (Gateway Timeout).

Brasília, 20 December 2024.

NOTE 886/2024-BCB/DENOR, OF 19 DECEMBER 2024.

It provides the basis for a proposal to issue a normative instruction that establishes version 6.0 of the Open Finance API Manual.

Mr. Heads of Denor and Deinf,

This Note provides the basis for a proposal to issue a normative instruction by the Financial System Regulation Department (Denor) and the Information Technology Department (Deinf), in the exercise of the attribution conferred on them by art. 23, item I, subitem "a", of the Internal Rules of the Central Bank of Brazil, annexed to BCB Resolution No. 340, of 21 September 2023, based on art. 51, item IX, of Joint Resolution No. 1, of 4 May 2020.

2. In this regard, the proposal concerns the issuance of a normative instruction that establishes version 6.0 of the Open Finance API Manual, revoking BCB Normative Instruction No. 456, of 29 February 2024, which discloses version 5.0 of the Open Finance API Manual.

3. It is worth emphasizing that, by force of art. 5 of Law No. 13.874, of 20 September 2019, proposals for the issuance and amendment of normative acts of general interest to economic agents or to users of the services provided, issued by a body or entity of the federal public administration, including autarchies and public foundations, must be preceded by a 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.

4. However, it is worth noting that the proposed changes and adjustments do not cause significant impacts for the set of institutions participating in Open Finance, as they are merely a detailing in relation to the form of controlling the volume of requests with HTTP status code 529. In this sense, in accordance with art. 4, item III, of Decree No. 10.411, of 30 June 2020, the normative act proposed herein is exempt from preparing an RIA because it is considered to be of low impact. It is important to highlight that, in accordance with art. 9-A, § 2, of the aforementioned decree, the discussions regarding these changes took place within the scope of the Open Finance Governance Structure, an environment in which all institutions participating in Open Finance are represented, ensuring social participation.

For the consideration of Your Honor.

JANAÍNA PIMENTA ATTIE MATHEUS RAUBER CORADIN Head of Subunit Senior Advisor

VERUSKA ROCHA DE ARAGÃO Deputy Head of Deinf

Agreed.

RENATO KIYOTAKA UEMA HAROLDO JAYME MARTINS FROES CRUZ Head of Denor, substitute Head of Deinf