{"navegacao":null,"view":"views/exibenormativo.aspx","conteudo":[{"Titulo":"Instrução Normativa BCB N° 615","Tipo":"Instrução Normativa BCB","Documentos":null,"DOU":"Publicada no DOU de 12/5/2025, Seção 1, p. 217-220.","Id":52585,"Data":"2025-05-06T15:46:00Z","DataTexto":"6/5/2025 12:46","Numero":615.0,"VersaoNormativo":1.0,"Assunto":"Divulga a versão 7.0 do Manual de APIs do Open Finance.\n","NormasVinculadas":"INSTRUÇÃO NORMATIVA BCB;@574;@2024;#RESOLUÇÃO CONJUNTA;@1;@2020;#RESOLUÇÃO BCB;@340;@2023;#RESOLUÇÃO BCB;@32;@2020;#","Referencias":"Resolução BCB nº 32/2020.;#Resolução BCB nº 340/2023, Anexo (Regimento Interno do BCB), art. 23, inciso I, “a”.;#Cita Resolução Conjunta BCB/CMN nº 1/2020.;#Revoga, a partir de 1º/7/2025, Instrução Normativa BCB nº 574/2024.;#","Atualizacoes":null,"Revogado":false,"Cancelado":false,"Texto":"
\n\n\n\n\nResolução Nº 222\n\n\n\n\n\n\n
\n\n

INSTRUÇÃO NORMATIVA\nBCB Nº 615, DE 6 DE MAIO DE 2025

\n\n

Divulga\na versão 7.0 do Manual de APIs do Open Finance.

\n\n

Os Chefes do\nDepartamento de Regulação do Sistema Financeiro (Denor) e do Departamento de\nTecnologia da Informação (Deinf), no uso das atribuições que lhes conferem o\nart. 23, inciso I, alínea "a", do Regimento Interno do Banco Central\ndo Brasil, anexo à Resolução BCB nº 340, de 21 de setembro de 2023, com base no\nart. 3º, inciso II, da Resolução BCB nº 32, de 29 de outubro de 2020,

\n\n

R E S O L V E M :

\n\n

Art. 1º  Esta Instrução\nNormativa divulga a versão 7.0 do Manual de APIs do Open Finance, de\nobservância obrigatória por parte das instituições participantes, conforme Anexo.

\n\n

Parágrafo único.  O manual de que trata o caput, em sua\nversão mais recente, estará acessível na página do Open Finance no sítio\neletrônico do Banco Central do Brasil na internet e no Portal do Open\nFinance no Brasil, mantido pela Estrutura de Governança do Open Finance\nde que trata o art. 44, § 1º, da Resolução Conjunta nº 1, de 4 de maio de 2020.

\n\n

Art. 2º  Fica revogada a Instrução Normativa nº 574, de 20 de dezembro\nde 2024, publicada no Diário Oficial da União de 30 de dezembro de 2024.

\n\n

Art. 3º  Esta Instrução Normativa entra em vigor em 1º de julho de\n2025.

\n\n

MARDILSON FERNANDES\nQUEIROZ                       CAIO MOREIRA FERNANDES
                        Chefe do Denor                                                         Chefe\ndo Deinf

\n\n
\n\n\n

 

\n\n

ANEXO À INSTRUÇÃO NORMATIVA BCB Nº 615,\nDE 6 DE MAIO DE 2025

\n\n

Manual de APIs do Open Finance Versão\n7.0

\n\n

Histórico de revisão

\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n
\n

Data

\n 		\n

Versão

\n 		\n

Descrição das\n alterações

\n
\n

6/5/2025

\n 		\n

7.0

\n 		\n

Subseção 5.1.1:\n atualização dos limites de tráfego.

\n
\n

Subseção 5.2: atualização\n dos limites operacionais.

\n
\n\n

 

\n\n

Termos de Uso

\n\n

Este manual\ndetalha os requisitos técnicos para a implementação dos elementos necessários à\noperacionalização do Open Finance, complementando a regulamentação\nvigente sobre o tema.

\n\n

O manual será revisto e atualizado\nperiodicamente a fim de preservar a compatibilidade com a regulamentação, bem\ncomo para incorporar os aprimoramentos decorrentes da evolução do Open\nFinance e da tecnologia.

\n\n

Informações mais detalhadas e exemplos\nda aplicação deste manual poderão ser encontrados nos guias e tutoriais\ndisponíveis no Portal do Open Finance no Brasil, na Área do\nDesenvolvedor.

\n\n

Sugestões, críticas ou pedidos de\nesclarecimento de dúvidas relativas ao conteúdo deste documento podem ser\nenviados ao Banco Central do Brasil por meio dos canais institucionais dessa\nautarquia.

\n\n

Referências

\n\n

As especificações baseiam-se,\nreferenciam e complementam, quando aplicável, os seguintes documentos:

\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n
\n

Referência

\n 		\n

Origem

\n
\n

Resolução\n Conjunta nº 1, de 2020

\n 		\n

https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolu%C3%A7%C3%A3o%20Conjunta&numero=1\n

\n
\n

Resolução\n BCB nº 32, de 2020

\n 		\n

https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolu%C3%A7%C3%A3o%20BCB&numero=32

\n
\n

Hypertext Transfer Protocol – HTTP/1.1

\n 		\n

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

\n
\n

ISO 20022

\n 		\n

https://www.iso20022.org/\n

\n
\n

OpenAPI Specification

\n 		\n

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

\n
\n

Representational State Transfer

\n 		\n

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

\n
\n\n

 

\n\n

1. Introdução

\n\n

O Open Finance está\nintrinsecamente ligado às APIs, interfaces por meio das quais é possível\ninterligar os diferentes sistemas das instituições. Ao serem disponibilizadas\npelos participantes, as APIs devem satisfazer condições tais como\npadronização, robustez e segurança, a fim de que o objetivo de compartilhamento\nde dados e serviços seja atendido a contento.

\n\n

Nesse sentido, este manual visa a definir\nos principais aspectos relativos às especificações e implementações das APIs\nque integram o Open Finance no País, observando as disposições da\nResolução Conjunta nº 1, de 4 de maio de 2020, e da Resolução BCB nº 32, de 29\nde outubro de 2020.

\n\n

São tratados neste manual aspectos\ncomo: formato para a troca de dados, desenho da interface, protocolo para\ntransmissão de dados, versionamento, modelo de APIs e endpoints. Desse\nmodo, o manual estabelece as diretrizes gerais sem esgotar todos os aspectos\nnecessários à implementação das APIs para o Open Finance. As demais\ndefinições a cargo das instituições participantes, por meio da Estrutura de Governança\ndo Open Finance, estarão disponíveis no Portal do Open Finance no\nBrasil, no qual poderão ser encontrados guias, tutoriais e outras informações\noperacionais sobre as APIs.

\n\n

Ao longo deste manual, será constante\no uso de siglas e terminologia específica para designar algumas expressões\ncotidianas dos profissionais da área de tecnologia. Alguns exemplos das mais\nfrequentemente utilizadas, com as correspondentes definições, são as seguintes:

\n\n

I - API (Application Programming Interface): um conjunto\nde definições sobre como um sistema pode acessar dados ou funcionalidades\nprovidos por um outro sistema;

\n\n

II - REST (Representational State Transfer):\nestilo arquitetural de software;

\n\n

III - API RESTful: API que adere às\nrestrições do estilo arquitetural\nREST;

\n\n

IV - OpenAPI: linguagem de\nespecificação de APIs RESTful;

\n\n

V - endpoint: elemento de uma especificação OpenAPI\nsobre o qual podem ser executadas operações para acessar dados ou\nfuncionalidades;

\n\n

VI - HTTP (Hypertext Transfer\nProtocol): protocolo para sistemas hipermídia,\ndistribuídos e colaborativos;

\n\n

VII - operação: elemento de uma\nespecificação OpenAPI que declara uma maneira válida de se acessar um endpoint,\ninformando qual método HTTP (GET, POST etc.) utilizar, nomes e tipos de\nparâmetros;

\n\n

VIII - provedor da API: instituição que\ndisponibiliza uma API para ser consumida por outras instituições. Nas APIs de "Serviços\nde Iniciação de Pagamentos", é a instituição detentora de contas; no caso\nde APIs de "Dados Cadastrais e Transacionais", é a instituição\ntransmissora de dados;

\n\n

IX - consumidor da API: instituição que\nconsome uma API provida por outras instituições. Nas APIs de "Serviços de\nIniciação de Pagamentos", é a instituição iniciadora de pagamentos; no\ncaso de APIs de "Dados Cadastrais e Transacionais", é a instituição\nreceptora de dados; e

\n\n

X - gateway de API: é um serviço, dispositivo ou proxy\nque atua como intermediário, aceitando, transformando, encaminhando e\ngerenciando o tráfego de APIs para serviços de back-end. Ele permite a\ncomunicação e a transferência de dados entre endpoints e pode ser útil\nquando há várias plataformas que precisam interagir umas com as outras sem\nconceder acesso direto às APIs umas das outras. Além disso, um gateway\nde API pode lidar com tarefas como autenticação, limitação de taxas,\narmazenamento em cache e transformação de solicitação/resposta, reduzindo a\ncarga sobre o aplicativo e melhorando a segurança geral e o desempenho do\nsistema.

\n\n

2. APIs do Open Finance

\n\n

As APIs a serem providas pelas\ninstituições no âmbito do Open Finance devem ser categorizadas em um dos\nseguintes tipos:

\n\n

I - Dados Abertos;

\n\n

II - Dados Cadastrais e Transacionais;

\n\n

III - Serviços; e

\n\n

IV - Relatórios e Métricas.

\n\n

3. Princípios

\n\n

Os princípios abaixo norteiam as\nespecificações e implementações das APIs do Open Finance.

\n\n

3.1 Experiência do usuário

\n\n

As especificações e implementações das\nAPIs devem oferecer uma boa experiência para os usuários, sejam eles\nimplementadores ou consumidores das APIs.

\n\n

3.2 Independência de tecnologia

\n\n

As especificações das APIs devem ser independentes\nde tecnologia, podendo ser implementadas e consumidas em diferentes linguagens,\ntais como Java, JavaScript e Python; ou plataformas, tais como Windows, Linux,\nAndroid e iOS.

\n\n

3.3 Segurança

\n\n

Procedimentos e controles (assinaturas\ndigitais, criptografia, protocolos de autenticação e autorização, entre outros)\ndevem ser adotados de forma a proteger os participantes do Open Finance,\nseus clientes, os consumidores das APIs e demais participantes do ecossistema,\nobservada a compatibilidade com a política de segurança cibernética da\ninstituição.

\n\n

3.4 Extensibilidade

\n\n

No futuro, as APIs poderão ser\nevoluídas para atender a novos casos de uso e, portanto, devem ser\nespecificadas e implementadas de forma a permitir e facilitar extensões como,\npor exemplo, novos endpoints, operações, parâmetros e propriedades.

\n\n

3.5 Padrões abertos

\n\n

Padrões abertos devem ser adotados\nsempre que possível.

\n\n

3.6 APIs RESTful

\n\n

As especificações das APIs devem\natender às restrições do estilo arquitetural REST sempre que possível.

\n\n

3.7 ISO 20022

\n\n

As respostas das APIs devem ter como\nbase os elementos e componentes de mensagem ISO 20022 (https://www.iso20022.org/).\nOs casos particulares em que a adoção do padrão ISO não seja possível ou\nrecomendada poderão sofrer adequações, desde que especificamente apontados para\navaliação pelo Banco Central do Brasil.

\n\n

3.8 Declaração de obrigatoriedade

\n\n

Todos os elementos que compõem as\nespecificações das APIs (endpoints, operações, parâmetros, propriedades\nde respostas etc.) devem ser explicitamente declarados como "Obrigatório",\n"Opcional" ou "Condicional", caso sejam obrigatórios apenas\nem certas condições.

\n\n

Funcionalidades\nque sejam de implementação opcional pelo transmissor devem ficar explícitas na\nsua documentação, tanto para informar adequadamente ao público transmissor, que\npoderá ou não implementar a funcionalidade, quanto ao público consumidor, que pode\nnão encontrar a funcionalidade disponível em alguns transmissores.

\n\n

4. Definições e recomendações

\n\n

As definições e recomendações abaixo\ndevem ser observadas pelas especificações e implementações das APIs do Open\nFinance.

\n\n

4.1 Especificações

\n\n

As APIs devem ser especificadas com a\nversão 3.0.0 ou superior da linguagem OpenAPI\n(https://github.com/OAI/OpenAPI-Specification/blob/3.0.0/versions/3.0.0.md).

\n\n

As especificações das APIs devem ser analisadas com a versão\n5.9.0 ou superior do software livre e de código aberto Spectral (https://github.com/stoplightio/spectral/tree/v5.9.0).\nA análise deve ser feita com o conjunto de regras (ruleset) padrão desta versão do Spectral. O\nresultado da análise não deve conter erros ou alertas.

\n\n

É recomendado que a versão 3.0.25 ou\nsuperior do software livre e de código aberto Swagger Codegen (https://github.com/swagger-api/swagger-codegen/tree/v3.0.25)\nseja utilizada para gerar o código de clientes e também o código inicial de\nimplementações das APIs a partir de suas especificações. Recomenda-se que o\ncódigo gerado seja analisado com o intuito de identificar possíveis recursos da\nlinguagem OpenAPI que foram utilizados nas especificações, mas que não são\nadequadamente suportados pelo Swagger Codegen e, possivelmente, por outros softwares\nque trabalham com especificações OpenAPI. Caso isso ocorra, deve-se avaliar se\nnão é possível alterar as especificações para não mais fazer uso desses\nrecursos.

\n\n

Devem ser disponibilizadas implementações\nde exemplo das APIs. Os dados retornados por elas não precisam ser dados reais\ne nem volumosos, pois o objetivo da disponibilização é dar ao Banco Central do\nBrasil, aos implementadores e aos consumidores das APIs mais um recurso para\ndirimir eventuais dúvidas acerca de suas especificações e implementações. É recomendado que o código inicial de implementações das\nAPIs mencionado anteriormente seja complementado de forma a constituir-se nas\nimplementações de exemplo.

\n\n

As informações disponibilizadas nos\ndicionários de dados devem ser consistentes com as especificações OpenAPI associadas.

\n\n

Todos os endpoints das APIs implementados\ndevem ser previamente registrados no diretório de participantes.

\n\n

Todos os endpoints registrados\nque retornem listas, caso os parâmetros sejam válidos, devem retornar a lista\nassociada, mesmo que seja lista vazia. Não é considerado um retorno válido o\nerro 404, neste cenário, quando não houver a informação associada.

\n\n

4.2 Versionamento

\n\n

As versões das especificações das APIs\nserão tipificadas como "major", "minor", "patch"\ne "release candidate" de acordo com os critérios a seguir:

\n\n

I - major: inclui novas\ncaracterísticas da implementação, mudanças e correções a serem incorporadas,\nque podem ser incompatíveis com versões anteriores, por exemplo, v1.0.0 e\nv2.0.0;

\n\n

II - minor: pequenas mudanças\nnos elementos já existentes, com manutenção da compatibilidade com as versões\naté a major imediatamente anterior, por exemplo, v1.1.0 e v1.2.0;

\n\n

III - patch: esclarecimentos às\nespecificações "minor", não incluem alterações funcionais, por\nexemplo, v1.1.1, v1.1.2; e

\n\n

IV - release candidate: versões\nde pré-lançamento de qualquer versão futura do tipo "patch", "minor"\nou "major", por exemplo, v1.0.0-rc e v1.0.0-rc2.

\n\n

A Estrutura de Governança do Open\nFinance, de que trata o art. 44, § 1º, da Resolução Conjunta nº 1, de 2020,\npode lançar novas versões das APIs.

\n\n

O Banco Central do Brasil pode definir:

\n\n

I - o cronograma de implantação das\nnovas versões das especificações das APIs e de certificação das instituições\nparticipantes; e

\n\n

II - a tipificação de determinadas\nalterações como "minor" ou "patch"\nindependentemente dos critérios definidos nos incisos de I a IV desta subseção.

\n\n

Alterações feitas na especificação de\numa API devem sempre ser documentadas com um novo versionamento desta especificação.

\n\n

Por fim, credenciais de acesso\nassociadas às APIs devem ser agnósticas às suas versões.

\n\n

4.3 Portal do Open Finance no Brasil

\n\n

O sítio\neletrônico de que trata o art. 15 da Resolução BCB nº 32, de 2020, deverá conter definições e\nrecomendações acessórias não presentes neste manual, bem como outros artefatos\nnecessários à especificação, implementação e consumo das APIs do Open\nFinance. Todas as definições e recomendações acessórias e artefatos\npublicados no portal deverão estar em concordância com este e com os demais\nmanuais do Open Finance.

\n\n

4.4 Cronograma

\n\n

O Portal do Open Finance deverá\nlistar as APIs em produção, suas versões atuais, datas em que entraram em\nprodução, link para suas especificações e lista de mudanças desde a\núltima publicação. Também deverá apresentar o cronograma de homologação das\nAPIs, indicando versão, data de divulgação, data prevista de entrada em\nprodução e outras informações relevantes.

\n\n

4.5 Logs de mudanças

\n\n

Todas as versões já publicadas das\nAPIs devem ser listadas no Portal do Open Finance, juntamente com os\nrespectivos logs de mudanças e períodos em que estiveram em produção.

\n\n

4.6 Definições acessórias

\n\n

A Estrutura de Governança do Open Finance\ndeverá estabelecer e publicar no Portal do Open Finance um guia de\nestilo de especificações de APIs contendo definições e recomendações para os\nseguintes elementos:

\n\n

I - estrutura de Uniform Resource\nIdentifiers (URIs);

\n\n

II - cabeçalhos HTTP;

\n\n

III - códigos de status HTTP;

\n\n

IV - convenções de corpo de\nrequisições e respostas;

\n\n

V - convenções de nomenclatura;

\n\n

VI - tipos de dados comuns;

\n\n

VII - paginação; e

\n\n

VIII - estabilidade de\nidentificadores.

\n\n

4.7 Processo de gerência de mudanças

\n\n

A\nEstrutura de Governança do\nOpen Finance deve estabelecer\ne publicar no Portal do Open Finance o processo que ela adotará para\ngerenciar mudanças nas especificações das APIs.

\n\n

4.8 Tutoriais

\n\n

Todas as informações necessárias para\no desenvolvimento, testes e entrada em produção de aplicações ou APIs no Open\nFinance devem estar disponíveis em tutoriais publicados na Área do\nDesenvolvedor no Portal do Open Finance. Cada tutorial deve conter todos\nos passos necessários para o completo desenvolvimento da atividade em questão,\ncomo desenvolvimento e uso de aplicações e APIs, autenticação e autorização,\nuso da Sandbox, aplicação de testes de conformidade e cadastramento no\ndiretório. Quando pertinente, devem ser fornecidos exemplos de código fonte ou\nde capturas de telas, tornando o processo o mais claro possível para todos os\nparticipantes e interessados.

\n\n

4.9 Extensibilidade

\n\n

As especificações das APIs do Open\nFinance podem não dar acesso a todos os dados e funcionalidades que um ou\nmais participantes desejam expor para os consumidores das APIs. Isso pode ser\nnecessário para melhor suportar casos de uso ou possibilitar inovações em\nprodutos e serviços financeiros. Para atender estas e outras necessidades, é\nfacultado aos participantes implementarem versões estendidas das APIs\ninteiramente compatíveis com as especificações padrões das APIs que são:

\n\n

I - novos endpoints;

\n\n

II - novas operações em endpoints\npré-existentes;

\n\n

III - novos parâmetros em operações\npré-existentes, desde que opcionais; e

\n\n

IV - novas propriedades em respostas\npré-existentes.

\n\n

A Estrutura de Governança do Open\nFinance deverá publicar no Portal do Open Finance as definições e\nrecomendações acessórias relacionadas às extensões das APIs.

\n\n

Todas as extensões implementadas pelos\nparticipantes deverão estar listadas, com sua documentação referenciada, em\nseção específica no Portal do Open Finance e disponíveis para consumo,\nobservadas as regras de ressarcimento de despesas previstas na regulamentação\nvigente.

\n\n

5. Requisitos não funcionais

\n\n

Esta seção apresenta os requisitos não\nfuncionais que as instituições participantes devem observar na implementação\ndas APIs do Open Finance.

\n\n

Para auxiliar na definição de alguns\nrequisitos não funcionais, é necessário que cada endpoint seja classificado\nno Portal do Open Finance de acordo com a sua frequência de atualização\ndos dados, conforme as opções abaixo:

\n\n

I - alta frequência;

\n\n

II - média-alta frequência;

\n\n

III - média frequência; e

\n\n

IV - baixa frequência

\n\n

Os Limites de tráfego por origem,\nlimites operacionais e tempo de resposta (desempenho) serão definidos baseados\nnessa classificação.

\n\n

Os endpoints\ndas APIs do tipo "Serviços", das APIs de "Segurança" (Token\n– consumo OAuth 2.0 (FAPI), Token – DCR/DCM) e das APIs de "Recursos"\ne de "Consentimento" devem ser considerados como de alta frequência.

\n\n

Destaca-se\nque, especialmente em requisitos não funcionais, o termo "endpoint"\ndeve considerar as operações específicas associadas a cada caminho. Por\nexemplo, as chamadas GET /consents/{consentId} e DELETE /consents/{consentId}\nrepresentam operações distintas e, portanto, devem ser monitoradas de forma\nindependente.

\n\n

5.1 Limites de tráfego

\n\n

5.1.1 Limites por origem

\n\n

Cada endpoint implementado no Open\nFinance pode ter uma restrição quanto ao tráfego a partir de determinada\norigem. Em APIs do tipo "Dados Abertos" a origem é o IP de onde\npartiu a requisição, em APIs autenticadas é a organizationId da\ninstituição que fez a requisição.

\n\n

No caso de uma instituição implementar\nlimites, eles devem respeitar os valores mínimos de Transações por Minuto (TPM),\nconforme definido abaixo:

\n\n

I - em endpoints classificados\ncomo de alta frequência, por endpoint e por origem, de acordo com o\nnúmero de consentimentos possuídos por uma determinada instituição receptora de\ndados com uma determinada instituição transmissora de dados:

\n\n

a) nas hipóteses em que a quantidade\nde consentimentos ativos possuídos por uma determinada instituição receptora de\ndados com uma determinada instituição transmissora de dados for inferior ou\nigual a seis milhões, conforme a tabela abaixo:

\n\n
\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n
\n

Quantidade de\n Consentimentos Ativos da instituição receptora de dados por instituição\n transmissora de dados (QCA)

\n 		\n

TPM

\n
\n

0 < QCA ≤\n 1.000.000

\n 		\n

2.500

\n
\n

1.000.000 < QCA\n ≤ 2.000.000

\n 		\n

5.000

\n
\n

2.000.000 < QCA\n ≤ 3.000.000

\n 		\n

8.000

\n
\n

3.000.000 < QCA\n ≤ 6.000.000

\n 		\n

10.000

\n
\n\n
\n\n

b)\nnas hipóteses em que a quantidade de consentimentos ativos possuídos por uma determinada\ninstituição receptora de dados com uma determinada instituição transmissora de\ndados for superior a seis\nmilhões, o limite de TPM deve ser calculado considerando faixas de dois em dois\nmilhões, sendo o TPM equivalente ao limite de TPM da faixa anterior acrescido\nde dois mil. Exemplo: na faixa de quantidade de consentimentos ativos acima de seis\nmilhões e menor ou igual a oito milhões, o limite de TPM deve ser igual a 12.000;

\n\n

II - em endpoints classificados\ncomo de média-alta frequência, por endpoint e por origem, 2.000 TPM;

\n\n

III - em endpoints\nclassificados como de média frequência, por endpoint e por origem, 1.500\nTPM; e

\n\n

IV - em endpoints classificados\ncomo de baixa frequência, por endpoint e por origem, 1.000 TPM.

\n\n

Aplicabilidade: Alguns endpoints\nnão podem ter limites de tráfego definidos por origem, como nas APIs do tipo "Serviços",\nnas APIs de "Segurança", e de "Recursos" e de "Consentimento".\nA informação se o limite por origem é "aplicável" ou "não aplicável"\ndeve estar explícito por endpoint no Portal do Open Finance.

\n\n

A quantidade de consentimentos detidos\npor cada instituição receptora de dados com cada instituição transmissora de\ndados deve ser atualizada no primeiro dia de cada mês para fins da\nclassificação nas faixas de TPM do inciso I desta subseção, que diz respeito à\ncapacidade de TPM a ser provida pelas instituições transmissoras de dados às\ninstituições receptoras de dados no caso de endpoints classificados como\nde alta frequência.

\n\n

As requisições que excederem os\nlimites implementados deverão ser respondidas com status code HTTP 429 (Too\nMany Requests). Caso a instituição transmissora de dados opte por não\naplicar as restrições de tráfego por endpoint por origem estabelecidas\nneste manual, ela não poderá utilizar o status code HTTP 429.

\n\n

Por fim, as requisições que\nultrapassarem os limites deverão ser desprezadas no cálculo do tempo de\nresposta das implementações das APIs.

\n\n

5.1.2 Limites globais

\n\n

A infraestrutura das instituições\nprovendo APIs no Open Finance deve ter a capacidade de, no mínimo, atender\na 300 requisições simultâneas por segundo (TPS).

\n\n

Caso uma instituição atinja o limite\nde 300 TPS, no contexto do Open Finance, ela deve ampliar sua capacidade\nde infraestrutura para possibilitar um acréscimo de 150 TPS ao limite anterior.\nTal aumento deve ocorrer novamente a cada vez que o limite vigente naquela instituição\nseja atingido. Eventual redução pode ser realizada somente se durante trinta\ndias a capacidade a ser reduzida não tiver sido utilizada.

\n\n

As requisições que excederem os\nlimites de TPS deverão ser respondidas com status code HTTP 529 (Site\nis overloaded) e o seu volume diário deve ser inferior a 0,5% das\nrequisições válidas, nos termos da subseção 5.4 deste Manual.

\n\n

Com vistas a cumprir o limite máximo\nde volume de requisições com status code HTTP 529, cada instituição deve\nimplementar monitoramento preventivo, cuja metodologia é definida pela\nEstrutura de Governança do Open Finance e deve estar disponível no\nPortal do Open Finance.

\n\n

A execução do processo de\nmonitoramento preventivo não isenta a instituição participante de aumentos\nemergenciais de infraestrutura para atender a 99,5% das requisições válidas.

\n\n

Endpoints criados dentro do conceito de\nextensibilidade, sejam dentro de novas APIs ou em APIs existentes, não devem ser\nconsiderados para controle do limite global de transações simultâneas.

\n\n

Considerando que o Manual de\nMonitoramento do Open Finance estabelece que o período de apuração do\nvolume de requisições com status code HTTP 529 é mensal, assim que o mês\nde referência se encerrar, a Estrutura de Governança do Open Finance\ndeve verificar se os volumes diários de requisições com status code HTTP\n529 de uma determinada instituição participante em relação às suas requisições\nválidas foram superiores ou iguais ao limite de 0,5%.

\n\n

Para fins do processo de\nmonitoramento, considera-se que uma determinada instituição participante está\nem conformidade caso tenha respeitado o limite de 0,5% em pelo menos 90% dos\ndias do mês de referência, arredondando-se para o número inteiro mais próximo,\ndesde que o volume diário de requisições com status code HTTP 529 dos\ndemais dias não tenha sido superior a 5%.

\n\n

Evidências do processo de\nacompanhamento de limites de TPS devem estar à disposição do Banco Central do\nBrasil por um período de doze meses.

\n\n

5.2 Limites operacionais

\n\n

É facultado às instituições participantes\nimplementar um limite de acesso mensal por endpoint e por cliente.

\n\n

Em endpoints que acessem\nrecursos ou produtos, os limites serão também considerados por recurso ou produto.\n

\n\n

A contabilização dos acessos deve ser\nfeita por:

\n\n

I\n- mês;

\n\n

II\n- endpoint;

\n\n

III\n- objeto mais granular referenciado na chamada (consentimento/recurso/produto);

\n\n

IV\n- cliente (CPF ou CNPJ); e

\n\n

V\n- instituição consumidora da informação.

\n\n

Por exemplo: uma instituição receptora\n"A" pode acessar um endpoint "B", acessando o\nrecurso "C", de um cliente "D" da instituição transmissora "E",\nno mínimo "N" vezes (ou chamadas) com sucesso por mês.

\n\n

Aplicabilidade dos limites\noperacionais: todos os endpoints das APIs do tipo Dados Cadastrais e Transacionais\n(conforme classificação por tipo),\nexcetuando-se os endpoints das APIs de Consentimento (Consents) e\nRecursos (Resources). As APIs dos tipos Dados Abertos, de Serviços (como\nde Iniciação de Pagamento) e de Segurança não podem ter restrições de limites\noperacionais.

\n\n

A implementação dos limites\noperacionais é opcional pelas instituições transmissoras, mas, uma vez que\nsejam implementados, devem garantir o consumo mínimo estabelecido no Portal do Open\nFinance. É facultada à instituição a possibilidade de ampliar estes limites,\nmas vedada a implementação de limites inferiores aos estabelecidos.

\n\n

O Portal do Open Finance deve listar\nos valores mínimos de limites operacionais a serem considerados, por endpoint,\nque devem ser iguais ou maiores que os abaixo, de acordo com a classificação de\nfrequência de utilização:

\n\n

I - 8 chamadas ao mês, para endpoint\nclassificado como de baixa frequência;

\n\n

II - 30 chamadas ao mês, para endpoint\nclassificados como de média frequência;

\n\n

III - 120 chamadas ao mês, para endpoint\nclassificados como de média-alta frequência;

\n\n

IV - 240 chamadas ao mês, para endpoint\nclassificado como de alta frequência; e

\n\n

V - 420 chamadas ao mês, para os\nseguintes endpoints da API de Contas: "Saldos da conta" e "Limites\nda conta".Só deverão\nser contabilizadas nos limites operacionais as requisições respondidas com status\ncode HTTP 2XX (com sucesso),\nsendo que as requisições adicionais a um endpoint para fins de paginação\nnão devem ser contabilizadas.

\n\n

As requisições que excederem os\nlimites operacionais deverão ser respondidas com status code HTTP 423.

\n\n

Todas as requisições autenticadas em endpoints\nsujeitos ao limite operacional devem possuir o atributo x-fapi-interaction-id\npreenchido no seu header pela instituição receptora de dados, que deve\nser copiado pela instituição transmissora de dados nos headers da\nresposta. Essa definição objetiva permitir um adequado rastreamento de\ndivergências que podem ocorrer entre instituições transmissoras e receptoras de\ndados associadas ao limite operacional.

\n\n

5.3 Desempenho

\n\n

Deverá ser medido o tempo de resposta\nde cada requisição, ou seja, o tempo transcorrido entre o recebimento de uma\nrequisição que não ultrapassa os limites de tráfego e o momento em que a\nrequisição é completamente respondida. Adicionalmente, esta medição deverá ser\nfeita de maneira que os tempos medidos sejam os mais próximos possíveis dos\ntempos de resposta experimentados por quem fez a requisição. A medição na\ninstituição provedora da API deve iniciar quando a requisição é recebida pelo gateway\ne deve terminar após o último byte da resposta desta requisição ser\nenviado.

\n\n

5.3.1 Cálculo do desempenho

\n\n

Para fins do cálculo do desempenho,\ndeve-se considerar o valor do percentil 95 e as requisições para medir o\ndesempenho, que pretende minimizar impacto do aparecimento de valores extremos\n(outliers). O valor do percentil 95 pode ser obtido da seguinte maneira:

\n\n

I - coleta dos dados: Seja R o\nconjunto de todos os tempos de resposta de um dia, onde ri é o tempo\nde resposta da i-ésima requisição. Ou seja, R={r1, r2, ...,\nrn};

\n\n

II - cálculo do índice do percentil\n95: o índice para o percentil 95, denotado por i95, é calculado pela\nfórmula i95 = 0.95 ∗ n, arredondado para o número inteiro\nmais próximo, e onde n representa número de requisições;

\n\n

III - ordenação dos dados: Ordene o\nconjunto R em ordem crescente para obter o conjunto ordenado Rord={r(1),\nr(2), ..., r(n)}, onde r(1) é o menor tempo de resposta e r(n) é o maior; e

\n\n

IV - obtenção do valor do percentil\n95: o valor do percentil 95, denotado por P95, é o valor no\níndice i95 no conjunto ordenado Rord. Ou\nseja, P95 = r(i95).

\n\n

Considerando um exemplo em que um endpoint\nrecebe 10.555 requisições em um dia (ou seja, n = 10.555). Nesse caso, o\níndice para o percentil 95 será 10.027 (i95 = [0.95 * n]\n= [10.027,25] = 10.027). Após ordenarmos as medições do tempo de resposta em\nordem crescente (formando o conjunto Rord), o valor do\npercentil 95 (P95) para esse dia será igual ao tempo de\nresposta na posição 10.027 no conjunto ordenado Rord.

\n\n

5.3.2 Service Level Agreement (SLA)\ndo desempenho

\n\n

Neste contexto, os endpoints\ndas APIs deverão manter, diariamente, o percentil 95 do tempo de resposta em no\nmáximo:

\n\n

I - 1.500ms, em endpoints classificados\ncomo de alta e média-alta frequências;

\n\n

II - 2.000ms, em endpoints\nclassificados como de média frequência; e

\n\n

III - 4.000ms, em endpoints\nclassificados como de baixa frequência.

\n\n

Por exemplo, em um dia que um endpoint\nde alta frequência receba 10.000 requisições, o tempo de resposta de pelo menos\n9.500 requisições deve ser inferior a 1.500ms.

\n\n

Informações adicionais:

\n\n

I - as medições de tempo de resposta\ndevem ser realizadas de maneira independente para cada versão "major"\ndos endpoints em produção;

\n\n

II - devem ser consideradas as\nrequisições com todos os códigos de retorno possíveis, com exceção dos\nassociados a limites de tráfego e limites operacionais;

\n\n

III - esta subseção não se aplica às\nAPIs de "Webhook";

\n\n

IV - as instituições provedoras devem gerar\ne acompanhar seus indicadores de desempenho, de maneira independente da\nPlataforma de Coleta de Métricas (PCM) provida pela Estrutura de Governança do Open\nFinance;

\n\n

V - as instituições consumidoras das\nAPIs devem registrar os tempos de resposta das APIs que consomem para envio à\nPCM. Nelas, a medição do tempo de resposta de cada requisição deve iniciar no\nmomento antes da requisição ser feita e deve terminar após o último byte\nser recebido, antes de qualquer processamento;

\n\n

VI - o valor do tempo de resposta a\nser considerado para uma requisição é o valor reportado pelo consumidor da API;

\n\n

VII - na falta de informações dos\nconsumidores, serão utilizadas as informações dos provedores para o cálculo do\nSLA de desempenho; e

\n\n

VIII - a Estrutura de Governança do Open\nFinance deverá disponibilizar indicadores adicionais para monitoramento e\naprimoramento do ecossistema, que não terão, nesse momento, um SLA mínimo, tais\ncomo:

\n\n

a) percentil 95 do tempo de resposta\nsomente de requisições com status code 2XX;

\n\n

b) percentil 95 do tempo de resposta -\nprovedor - deve considerar todas as requisições fornecidas pelo provedor das\nAPIs, mesmo quando houver diferença entre as informações entre provedor e\nconsumidor;

\n\n

c) percentil 95 do tempo de resposta -\nconsumidor - deve considerar todas as requisições fornecidas pelos consumidores\ndas APIs, mesmo quando houver diferença entre as informações entre provedor e\nconsumidor;

\n\n

d) índice de paridade - percentual do número\nde requisições no status "PAIRED" em relação ao total;\ne

\n\n

e) média do tempo de resposta até P95\n- média do tempo de resposta de todas as requisições com tempo de resposta\nmenores que o valor do P95.

\n\n

5.3.3 Aferição do desempenho para fins\ndo processo de monitoramento

\n\n

Considerando que o Manual de\nMonitoramento do Open Finance estabelece que o período de apuração do\ndesempenho é mensal, assim que o mês de referência se encerrar, a Estrutura de\nGovernança do Open Finance deve verificar se os endpoints das\nAPIs das instituições participantes atenderam aos SLAs do desempenho definidos\nna seção anterior deste manual.

\n\n

Para fins do processo de\nmonitoramento, considera-se que um endpoint está em conformidade caso\ntenha respeitado o SLA do desempenho em pelo menos 90% dos dias do mês de\nreferência, arredondando-se para o número inteiro mais próximo, desde que o valor\ndo P95 dos demais dias não tenha sido superior ao SLA do desempenho\naumentado em 20%.

\n\n

Por exemplo:

\n\n

I - em um mês de 30 dias, em que um endpoint\nde alta frequência tenha apresentado valor de P95 inferior a 1.500ms\nem 27 dias e, nos demais dias, tenha apresentado valor de P95 entre\n1.500ms e 1.800ms (1.500ms * 1,2 = 1.800ms), o endpoint está em\nconformidade para fins do processo de monitoramento naquele mês; e

\n\n

II - em um mês de 31 dias, em que um endpoint\nde alta frequência tenha apresentado valor de P95 inferior a 1.500ms\nem 28 dias e, nos demais dias, tenha apresentado, em pelo menos um dos dias,\nvalor de P95 superior a 1.800ms (1.500ms * 1,2 = 1.800ms), o endpoint\nnão está em conformidade para fins do processo de monitoramento naquele mês.

\n\n

5.4 Disponibilidade

\n\n

5.4.1 Cálculo da disponibilidade

\n\n

A disponibilidade dos endpoints\ndas APIs do Open Finance será calculada empiricamente, baseada na\nmonitoração de requisições válidas. Serão consideradas "requisições válidas"\nas requisições que retornam status code da faixa 2XX, 5XX, igual a 408 ou\nigual a 422. As requisições válidas podem ser divididas em "requisições\nválidas com sucesso" - com status code na faixa 2XX ou igual a 422\n- e "requisições válidas com erro" - com status code na faixa\n5XX ou igual a 408.

\n\n

A disponibilidade pontual (t) será\ncalculada como a fração do total de requisições válidas que cada endpoint\nrecebe e as que ele processa com sucesso a cada intervalo de 1 minuto. Os\nintervalos de minuto deverão ser calculados do segundo zero (0s:000ms) até o\nsegundo 59 (59s:999ms).

\n\n

\"\" 

\n\n

Por exemplo, a disponibilidade pontual\nde um endpoint referente ao minuto 11:34, de um determinado dia, no qual\nhouve um total de requisições válidas com sucesso de 255 e um total de\nrequisições válidas com erro de 4, é calculada da seguinte forma:

\n\n

​\"\" 

\n\n

Dessa forma, obtém-se o indicador\npercentual para cada janela de tempo de 1 minuto. Cada período de 1 minuto será\nclassificado como "disponível" ou "indisponível". Se a "disponibilidade\npontual" da janela de tempo ficar abaixo de 95% isso indicará que ela será\nconsiderada como "indisponível", caso contrário será "disponível".

\n\n

Períodos que não tenham requisições\nválidas são considerados "indefinidos" e são desconsiderados para\ncálculo da disponibilidade.

\n\n

​\"\" 

\n\n

A disponibilidade diária será\ncalculada baseada nas informações das disponibilidades pontuais.

\n\n

​\"\" 

\n\n

Por exemplo, considerando um dia em\nque houve requisições válidas em 1.390 das 1.440 faixas de 1 minuto possíveis\n(1 dia = 24h * 60min = 1.440 faixas de horário) para um endpoint\nespecífico "x" de versão 1, e dos quais 30 períodos tiveram a\ndisponibilidade menor que o limite de disponibilidade definido (95%), a\nDisponibilidade Diária de "x" v1 será igual a:

\n\n

​​\"\" 

\n\n

A disponibilidade longa deverá ser\ncalculada diariamente como média móvel das disponibilidades dos últimos noventa\ndias corridos, considerando somente os dias em que a disponibilidade diária\npode ser calculada (teve pelo menos uma disponibilidade pontual diferente de "indefinido").\nOu seja, caso nos últimos noventa dias tenhamos dois dias calculados como\nindefinidos, a média deve ser calculada considerando somente as 88 disponibilidades\nválidas.

\n\n

A aferição mensal deve considerar a\ndisponibilidade longa do último dia do mês de referência.

\n\n

5.4.2 SLA da disponibilidade

\n\n

Cada um dos endpoints das APIs categorizadas\ncomo "Dados Abertos", "Dados Cadastrais e Transacionais", "Relatórios\ne Métricas", por versão, e os endpoints das APIs de "Segurança"\n"/register" e "/token", deverão satisfazer os\nrequisitos mínimos de disponibilidade abaixo:

\n\n

I - disponibilidade diária\n(calendário): 95%; e

\n\n

II - disponibilidade longa (média\nmóvel de 90 dias), medida diariamente: 99,5%.

\n\n

As APIs classificadas como "Serviços\nde Iniciação de Pagamentos" seguem o definido na regulamentação do Pix.

\n\n

Informações adicionais:

\n\n

I - as medições devem ser feitas todos\nos dias, em todas as faixas de 1 minuto disponíveis, iniciando na primeira\nfaixa (00:00:00-00:00:59) e terminando na última faixa (23:59:00-23:59:59),\nconsiderando o horário de Brasília;

\n\n

II - as medições de disponibilidade\ndevem ser feitas para cada versão major dos endpoints em produção. Por\nexemplo, em períodos de convivência o endpoint de v1/resources\npoderia estar disponível no mesmo período em que o endpoint de v2/resources\nestaria também disponível. É importante que suas disponibilidades sejam\ncalculadas de maneira independente;

\n\n

III - as instituições provedoras devem\ngerar e acompanhar seus indicadores de disponibilidade, de maneira independente\nda Plataforma de Coleta de Métricas (PCM) provida pela Estrutura de Governança\ndo Open Finance;

\n\n

IV - o status code a ser\nconsiderado para uma requisição é o valor reportado pelo consumidor da API;

\n\n

V - na falta de informações dos\nconsumidores, serão utilizadas as informações dos provedores para o cálculo do\nSLA de disponibilidade;

\n\n

VI - a indisponibilidade programada\nnão exime o cálculo da disponibilidade no período apurado;

\n\n

VII - esta subseção não se aplica às\nAPIs de "Webhook";

\n\n

VIII - a disponibilidade de endpoints\nque não tenham requisições válidas no período apurado será considerada "indefinida",\nnão estando sujeita a um SLA; e

\n\n

IX - a Estrutura de Governança do Open\nFinance deverá disponibilizar indicadores adicionais para monitoramento e\naprimoramento do ecossistema que não terão, nesse momento, um SLA mínimo, tais\ncomo:

\n\n

a) disponibilidade calculada do ponto\nde vista do provedor da API - deve considerar as informações fornecidas pelo\nprovedor das APIs; e

\n\n

b) disponibilidade calculada do ponto\nde vista do consumidor da API - deve considerar as informações fornecidas somente\npelos consumidores das APIs, classificadas no PCM como "PAIRED"\nou "SINGLE".

\n\n

5.5 Timeout

\n\n

Padronização do timeout de\ntempo de resposta do provedor e do tempo de resposta do consumidor em quinze\nsegundos.

\n\n

As requisições que excederem o limite\nde timeout do provedor deverão ser respondidas com o status code HTTP\n504 (Gateway Timeout).

\n\n

6. Regras transitórias

\n\n

As mudanças realizadas na seção 5.1.1\nentram em vigor a partir de 1º de setembro de 2025.

\n\n

Brasília, 6 de maio de 2025.

\n\n
\n\n\n

 

\n\n

NOTA 281/2025-BCB/DENOR, DE 5 DE MAIO DE\n2025

\n\n

Fundamenta\nproposta de edição de instrução normativa que estabelece a versão 7.0 do Manual\nde APIs do Open Finance.

\n\n

Senhores Chefes do Denor\ne do Deinf,

\n\n

A presente Nota\nfundamenta proposta de edição de instrução normativa pelo Departamento de\nRegulação do Sistema Financeiro (Denor) e pelo Departamento de Tecnologia da\nInformação (Deinf), no uso da atribuição que lhes confere o art. 23, inciso I,\nalínea "a", do Regimento Interno do Banco Central do Brasil, anexo à\nResolução BCB nº 340, de 21 de setembro de 2023, com base no art. 51, inciso IX,\nda Resolução Conjunta nº 1, de 4 de maio de 2020.

\n\n

2.                    A\nrespeito, a proposta trata de edição de instrução normativa que estabelece a\nversão 7.0 do Manual de APIs do Open Finance, revogando a Instrução\nNormativa BCB nº 574, de 20 de dezembro de 2025, que divulga a versão 6.0 do\nManual de APIs do Open Finance.

\n\n

3.                    Por\nfim, cumpre ressaltar que, por força do art. 5º da Lei nº 13.874, de 20 de\nsetembro de 2019, as propostas de edição e de alteração de atos normativos de\ninteresse geral de agentes econômicos ou de usuários dos serviços prestados,\neditadas por órgão ou entidade da administração pública federal, incluídas as\nautarquias e as fundações públicas, serão precedidas da realização de análise\nde impacto regulatório (AIR), que conterá informações e dados sobre os\npossíveis efeitos do ato normativo para verificar a razoabilidade do seu\nimpacto econômico.

\n\n

4.                    Por\nsua vez, o Decreto nº 10.411, de 30 de junho de 2020, que regulamenta a\nreferida lei, em seu art. 4º, estabelece critérios de dispensa para realização\nda AIR. Nesse contexto,\nvale destacar que, desde a última alteração de limites de tráfego por origem e\nde limites operacionais, ocorrida em meados de 2022, o número de consentimentos\nde clientes no Open Finance foi triplicado e os casos de uso foram\nampliados e aprofundados. Em consequência, há, atualmente, demanda represada em\nrazão dos referidos limites, afetando a capacidade de instituições de\noferecerem adequadamente produtos com base no Open Finance ou até mesmo\ncausando riscos de tomada de decisões com base em dados desatualizados tanto\npelas instituições quanto por seus clientes.

\n\n

5.                    Nesse\nsentido, de acordo com​ o art. 4º, inciso V, alíneas "b" e\n"c", do referido Decreto nº 10.411, de 30 de junho de 2020, o ato\nnormativo ora proposto fica dispensado de elaboração de AIR por visar a\npreservação da higidez dos mercados financeiros e dos sistemas de pagamentos.

\n\n

À consideração de V.Sa.

\n\n

JANAÍNA PIMENTA ATTIE                                              VERUSKA\nROCHA DE ARAGÃO
                        Consultora do Denor                                                      Chefe Adjunta do Deinf

\n\n


                        De acordo.

\n\n

MARDILSON FERNANDES QUEIROZ                             CAIO\nMOREIRA FERNANDES
                        Chefe do Denor                                                                Chefe\ndo Deinf

\n\n
\n\n\n\n\n
","Voto":null}]}