Instruction Normative BCB No. 615 — Publishes Version 7.0 of the Open Finance API Manual

Resolution No. 222

INSTRUCTION NORMATIVE
BCB NO. 615, OF MAY 6, 2025

Publishes version 7.0 of the Open Finance API Manual.

The Heads of the Financial System Regulation Department (Denor) and the Information Technology Department (Deinf), using the powers 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 II, of BCB Resolution No. 32, of October 29, 2020,

R E S O L V E:

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

Art. 2. Instruction Normative No. 574, of December 20, 2024, published in the Official Gazette of the Union on December 30, 2024, is hereby revoked.

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

MARDILSON FERNANDES
QUEIROZ CAIO MOREIRA FERNANDES Head of Denor Head of Deinf

ANNEX TO INSTRUCTION NORMATIVE BCB NO. 615,
OF MAY 6, 2025

Open Finance API Manual Version
7.0

Review History

Date	Version	Description of changes
6/5/2025	7.0	Subsection 5.1.1: update of traffic limits.
Subsection 5.2: update of operational limits.

Terms of Use

This manual details the technical requirements for the implementation of the elements necessary for the operationalization of the 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 the 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 regarding 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, 2020	https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolu%C3%A7%C3%A3o%20Conjunta&numero=1
BCB Resolution No. 32, 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

The 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, the APIs must satisfy conditions such as standardization, robustness, and security, in order for the objective of sharing data and services to be met satisfactorily.

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

Aspects treated in this manual include: format for data exchange, interface design, protocol for data transmission, versioning, API model, and endpoints. Thus, the manual establishes general guidelines without exhausting all aspects necessary for the implementation of APIs for the Open Finance. The other definitions assigned to participating institutions, through the Governance Structure of the Open Finance, 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 is constant. Some examples of the most frequently used, with their 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 style of software;

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

IV - OpenAPI: language for specifying RESTful APIs;

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

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

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 "Payment Initiation Services" APIs, it is the institution holding accounts; in the case of "Cadastro and Transactional Data" APIs, it is the institution transmitting data;

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

X - gateway API: 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 several platforms that need to interact with each other without giving direct access to the APIs of each other. In addition, an gateway API 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 the Open Finance must be categorized into one of the following types:

I - Open Data;

II - Cadastro and Transactional Data;

III - Services; and

IV - Reports and Metrics.

3. Principles

The principles below guide the specifications and implementations of the 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, being able to 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 the participants of the Open Finance, their clients, the consumers of the APIs, and other participants in the ecosystem, 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 REST architectural style restrictions whenever possible.

3.7 ISO 20022

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

3.8 Declaration of Obligation

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.

Functionalities that are optional for the transmitter to implement must be explicit in its documentation, both to adequately inform the transmitting public, who may or may not implement the functionality, and to the consuming public, who may not find the functionality available from some transmitters.

4. Definitions and Recommendations

The definitions and recommendations below must be observed by the specifications and implementations of the 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 done with the standard ruleset of this version of Spectral. The result of the analysis must not contain errors or alerts.

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 implementation code of the APIs from their specifications. It is recommended that the generated code be analyzed in order to identify possible features of the OpenAPI language that were used in the specifications, but that are not adequately supported by Swagger Codegen and, possibly, by other softwares that work with OpenAPI specifications. If this occurs, it should be evaluated whether it is not possible to alter the specifications to no longer use these resources.

Example implementations of the APIs must be made available. The data returned by them does not need to be real data or voluminous, as the objective of making them available is to give the Central Bank of Brazil, the implementers, and the consumers of the APIs another resource to resolve any doubts regarding their specifications and implementations. It is recommended that the initial implementation code of the APIs mentioned above be complemented in order to constitute the example implementations.

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

All endpoints of the implemented APIs 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. A 404 error 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 characteristics, 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 preceding major, for example, v1.1.0 and v1.2.0;

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

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

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

The Central Bank of Brazil may define:

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

II - the typification of certain changes as "minor" or "patch" independent 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, 2020, must contain definitions and auxiliary recommendations not present in this manual, as well as other artifacts necessary for the specification, implementation, and consumption of the APIs of the Open Finance. All auxiliary definitions and recommendations and artifacts published on the portal must be in accordance with this and with the other manuals of the Open Finance.

4.4 Schedule

The Open Finance Portal must list the APIs in production, their current versions, dates 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, publication date, expected date of entry into production, and other relevant information.

4.5 Logs of changes

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

4.6 Auxiliary Definitions

The Governance Structure of the Open Finance 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 body of requests and responses;

V - naming conventions;

VI - common data types;

VII - pagination; and

VIII - stability of identifiers.

4.7 Change Management Process

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

4.8 Tutorials

All information necessary for development, testing, and entry into production of applications or APIs in the Open Finance must be available in tutorials published in the Developer Area on the Open Finance Portal. Each tutorial must contain all 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 compliance tests, and registration in the directory. When appropriate, source code examples or screenshots must be provided, making the process as clear as possible for all participants and interested parties.

4.9 Extensibility

The specifications of the Open Finance APIs may not provide 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, it is optional for participants to implement extended versions of the APIs entirely compatible with the standard specifications of the APIs that are:

I - new endpoints;

II - new operations on endpoints pre-existing;

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

IV - new properties in responses pre-existing.

The Governance Structure of the Open
Finance must publish on the Open Finance Portal the auxiliary definitions and recommendations related to the extensions of the APIs.

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

5. Non-functional Requirements

This section presents the non-functional requirements that participating institutions must observe in the implementation of the 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 frequency of data update, 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 the APIs of the "Services" type, of the "Security" APIs (Token – OAuth 2.0 consumption (FAPI), Token – DCR/DCM) and of the "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 by Origin

Each endpoint implemented in the Open
Finance may have a restriction regarding traffic from a specific 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.

In the case of an institution implementing limits, they must respect the minimum values of Transactions Per Minute (TPM), as defined below:

I - in endpoints classified as high frequency, per endpoint and per origin, according to the number of consents held by a specific data-receiving institution with a specific data-transmitting institution:

a) in the cases where the quantity of active consents held by a specific data-receiving institution with a specific data-transmitting institution is less than or equal to six million, according to the table below:

Quantity of Active Consents of the data-receiving institution per data-transmitting institution (QCA)	TPM
0 < QCA ≤ 1,000,000	2,500
1,000,000 < QCA ≤ 2,000,000	5,000
2,000,000 < QCA ≤ 3,000,000	8,000
3,000,000 < QCA ≤ 6,000,000	10,000

b) in the cases where the quantity of active consents held by a specific data-receiving institution with a specific data-transmitting institution is greater than six million, the TPM limit must be calculated considering ranges of two million each, with the TPM equivalent to the TPM limit of the previous range plus two thousand. Example: in the range of active consent quantity above six million and less than or equal to eight million, the TPM limit must be equal to 12,000;

II - in endpoints classified as medium-high frequency, per endpoint and per origin, 2,000 TPM;

III - in endpoints classified as medium frequency, per endpoint and per origin, 1,500 TPM; and

IV - in endpoints classified as low frequency, per endpoint and per origin, 1,000 TPM.

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

The quantity of consents held by each data-receiving institution with each data-transmitting institution must be updated on the first day of each month for the purpose of the classification into the TPM ranges of item I of this subsection, which concerns the TPM capacity to be provided by data-transmitting institutions to data-receiving institutions in the case of endpoints classified as high frequency.

Requests that exceed the implemented limits must be responded to with HTTP status code 429 (Too Many Requests). If the data-transmitting institution chooses not to apply the traffic restrictions by endpoint by origin established in this manual, it cannot use the HTTP status code 429.

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

5.1.2 Global Limits

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

If an institution reaches the limit of 300 TPS, in the context of the Open Finance, it must expand its infrastructure capacity to allow an increase of 150 TPS to the previous limit. Such an increase must occur again each time the current limit at that institution is reached. Any reduction can only be performed if during 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 the valid requests, as per subsection 5.4 of this Manual.

In order to comply with the maximum limit of request volume with HTTP status code 529, each institution must implement preventive monitoring, whose methodology is defined by the Governance Structure of the Open Finance 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 existing APIs, must not be considered for control of the global limit of simultaneous transactions.

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

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

Evidence of the 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.

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

The counting of accesses 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", from a client "D" of the transmitting institution "E", at least "N" times (or calls) successfully per month.

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

The implementation of operational limits is optional by transmitting institutions, but, once implemented, they must guarantee the minimum consumption established in the Open Finance Portal. The institution is permitted to expand these limits, but implementing limits lower than those established is prohibited.

The Open Finance Portal must list the minimum operational limit values to be considered, per endpoint, which must be equal to or greater than the following, according to the classification of usage frequency:

I - 8 calls per month, for endpoint classified as low frequency;

II - 30 calls per month, for endpoints classified as medium frequency;

III - 120 calls per month, for endpoints classified as medium-high frequency;

IV - 240 calls per month, for 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 responded with HTTP 2XX status code (success) should be counted in operational limits, and additional requests to an endpoint for pagination purposes should not be counted.

Requests that exceed operational limits must be responded with HTTP 423 status code.

All authenticated requests in endpoints subject to operational limits must have the attribute x-fapi-interaction-id filled in its header by the data receiving institution, which must be copied by the data transmitting institution in the response headers. This definition aims to allow adequate tracking of discrepancies 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 traffic limits and the moment when the request is completely responded. Additionally, this measurement must be done 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 of this request is sent.

5.3.1 Performance Calculation

For the purposes of performance calculation, the 95th percentile value and requests to measure performance must be considered, which aims to minimize the impact of the appearance of extreme values (outliers). The 95th percentile value 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 - data sorting: Sort the set R in ascending order to obtain the sorted set Rord={r(1), r(2), ..., r(n)}, where r(1) is the smallest response time and r(n) is the largest; and

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

Considering an example in which an endpoint receives 10,555 requests in a day (i.e., 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 95th percentile value (P95) for that day will be equal to the response time at position 10,027 in the sorted set Rord.

5.3.2 Performance Service Level Agreement (SLA)

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

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

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

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

For example, on a day that 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 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 - institutions consuming the APIs 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 consumer information, provider information will be used for the performance SLA calculation; and

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

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

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

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

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

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

5.3.3 Performance Verification for Monitoring Purposes

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

For the purposes of the monitoring process, it is considered that an endpoint is in compliance if it has respected the performance SLA in at least 90% of the days of the reference month, rounded to the nearest integer, 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 lower than 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 in compliance 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 lower than 1,500ms on 28 days and, on the remaining days, presented, on at least one of the days, a P95 value higher than 1,800ms (1,500ms * 1.2 = 1,800ms), the endpoint is not in compliance for the purposes of the monitoring process in that month.

5.4 Availability

5.4.1 Availability Calculation

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

Instantaneous availability (t) will 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 must be calculated from second zero (0s:000ms) to second 59 (59s:999ms).

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

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

Periods that do not have valid requests are considered "undefined" and are disregarded for availability calculation.

Daily availability will be calculated based on the information of instantaneous availabilities.

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

Long-term availability must be calculated daily as a moving average of the availabilities of the last ninety consecutive days, considering only the days in which daily availability can be calculated (had at least one instantaneous availability different from "undefined"). That is, if in the last ninety days there were two days calculated as undefined, the average must be calculated considering only the 88 valid availabilities.

Monthly verification must consider the long-term availability of the last day of the reference month.

5.4.2 Availability SLA

Each of the API endpoints categorized as "Open Data", "Data and Transactional Data", "Reports and Metrics", by 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%.

APIs classified as "Payment Initiation Services" follow the provisions of the Pix regulation.

Additional information:

I - measurements must be made every day, in all available 1-minute ranges, starting from the first range (00:00:00-00:00:59) and ending in the last range (23:59:00-23:59:59), considering Brasília time;

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

III - provider 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 consumer information, provider information will be used for the availability SLA calculation;

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

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

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

IX - the Open Finance Governance Structure must make available additional indicators for monitoring and improving the ecosystem that will not, at this time, 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 providers; and

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

5.5 Timeout

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

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

6. Transitional Rules

The changes made in section 5.1.1 enter into force from September 1, 2025.

Brasília, May 6, 2025.

NOTE 281/2025-BCB/DENOR, OF MAY 5, 2025

Justifies proposal for the issuance of a normative instruction establishing version 7.0 of the Open Finance API Manual.

Gentlemen Heads of Denor and Deinf,

This Note justifies the proposal for the issuance of a normative instruction by the Financial System Regulation Department (Denor) and the Information Technology Department (Deinf), in the exercise of the authority granted to 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. 51, item IX, of Joint Resolution No. 1, of May 4, 2020.

2. In this regard, the proposal concerns the issuance of a normative instruction establishing version 7.0 of the Open Finance API Manual, revoking BCB Instruction Normative No. 574, of December 20, 2025, which publishes version 6.0 of the Open Finance API Manual.

3. Finally, it is worth noting that, by virtue of art. 5 of Law No. 13,874, of September 20, 2019, proposals for the issuance and alteration of normative acts of general interest to economic agents or users of provided services, issued by a federal public administration body or entity, including autarchies and public foundations, must be preceded by the realization of 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. For its part, Decree No. 10,411, of June 30, 2020, which regulates the aforementioned law, in its art. 4, establishes criteria for exemption from carrying out the RIA. In this context, it is worth highlighting that, since the last alteration of traffic limits by origin and operational limits, occurring in mid-2022, the number of client consents in Open Finance has tripled and the use cases have been expanded and deepened. As a consequence, there is currently backlogged demand due to these limits, affecting the capacity of institutions to adequately offer products based on Open Finance or even causing risks of decision-making based on outdated data by both institutions and their clients.

5. In this sense, according to art. 4, item V, letters "b" and "c", of the aforementioned Decree No. 10,411, of June 30, 2020, the normative act now proposed is exempt from the preparation of an RIA as it aims to preserve the integrity of financial markets and payment systems.

For your consideration.

JANAÍNA PIMENTA ATTIE VERUSKA ROCHA DE ARAGÃO Consultant of Denor Deputy Head of Deinf

                    In agreement.

MARDILSON FERNANDES QUEIROZ CAIO MOREIRA FERNANDES Head of Denor Head of Deinf