DOU 12/05/2025 - Diário Oficial da União - Brasil

                            Documento assinado digitalmente conforme MP nº 2.200-2 de 24/08/2001,
que institui a Infraestrutura de Chaves Públicas Brasileira - ICP-Brasil.
Este documento pode ser verificado no endereço eletrônico
http://www.in.gov.br/autenticidade.html, pelo código 05152025051200219
219
Nº 87, segunda-feira, 12 de maio de 2025
ISSN 1677-7042
Seção 1
5.1 Limites de tráfego
5.1.1 Limites por origem
Cada endpoint implementado no Open Finance pode ter uma restrição quanto
ao tráfego a partir de determinada origem. Em APIs do tipo "Dados Abertos" a origem é
o IP de onde partiu a requisição, em APIs autenticadas é a organizationId da instituição
que fez a requisição.
No caso de uma instituição implementar limites, eles devem respeitar os
valores mínimos de Transações por Minuto (TPM), conforme definido abaixo:
I - em endpoints classificados como de alta frequência, por endpoint e por
origem, de acordo com o número de consentimentos possuídos por uma determinada
instituição receptora de dados com uma determinada instituição transmissora de dados:
a) nas hipóteses em que a quantidade de consentimentos ativos possuídos por
uma determinada instituição receptora de dados com uma determinada instituição
transmissora de dados for inferior ou igual a seis milhões, conforme a tabela abaixo:
. .Quantidade de Consentimentos Ativos da instituição receptora
de dados por instituição transmissora de dados (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) nas hipóteses em que a quantidade de consentimentos ativos possuídos por
uma determinada instituição receptora de dados com uma determinada instituição
transmissora de dados for superior a seis milhões, o limite de TPM deve ser calculado
considerando faixas de dois em dois milhões, sendo o TPM equivalente ao limite de TPM
da faixa anterior
acrescido de dois mil.
Exemplo: na faixa de
quantidade de
consentimentos ativos acima de seis milhões e menor ou igual a oito milhões, o limite de
TPM deve ser igual a 12.000;
II - em endpoints classificados como de média-alta frequência, por endpoint e
por origem, 2.000 TPM;
III - em endpoints classificados como de média frequência, por endpoint e por
origem, 1.500 TPM; e
IV - em endpoints classificados como de baixa frequência, por endpoint e por
origem, 1.000 TPM.
Aplicabilidade: Alguns endpoints não podem ter limites de tráfego definidos
por origem, como nas APIs do tipo "Serviços", nas APIs de "Segurança", e de "Recursos"
e de "Consentimento". A informação se o limite por origem é "aplicável" ou "não
aplicável" deve estar explícito por endpoint no Portal do Open Finance.
A quantidade de consentimentos detidos por cada instituição receptora de
dados com cada instituição transmissora de dados deve ser atualizada no primeiro dia de
cada mês para fins da classificação nas faixas de TPM do inciso I desta subseção, que diz
respeito à capacidade de TPM a ser provida pelas instituições transmissoras de dados às
instituições receptoras de dados no caso de endpoints classificados como de alta
frequência.
As
requisições que
excederem
os
limites implementados
deverão
ser
respondidas com status code HTTP 429 (Too Many Requests). Caso a instituição
transmissora de dados opte por não aplicar as restrições de tráfego por endpoint por
origem estabelecidas neste manual, ela não poderá utilizar o status code HTTP 429.
Por fim, as requisições que ultrapassarem os limites deverão ser desprezadas
no cálculo do tempo de resposta das implementações das APIs.
5.1.2 Limites globais
A infraestrutura das instituições provendo APIs no Open Finance deve ter a
capacidade de, no mínimo, atender a 300 requisições simultâneas por segundo (TPS).
Caso uma instituição atinja o limite de 300 TPS, no contexto do Open Finance,
ela deve ampliar sua capacidade de infraestrutura para possibilitar um acréscimo de 150
TPS ao limite anterior. Tal aumento deve ocorrer novamente a cada vez que o limite
vigente naquela instituição seja atingido. Eventual redução pode ser realizada somente se
durante trinta dias a capacidade a ser reduzida não tiver sido utilizada.
As requisições que excederem os limites de TPS deverão ser respondidas com
status code HTTP 529 (Site is overloaded) e o seu volume diário deve ser inferior a 0,5%
das requisições válidas, nos termos da subseção 5.4 deste Manual.
Com vistas a cumprir o limite máximo de volume de requisições com status
code HTTP 529, cada instituição deve implementar monitoramento preventivo, cuja
metodologia é definida pela Estrutura de Governança do Open Finance e deve estar
disponível no Portal do Open Finance.
A execução do processo de monitoramento preventivo não isenta a instituição
participante de aumentos emergenciais de infraestrutura para atender a 99,5% das
requisições válidas.
Endpoints criados dentro do conceito de extensibilidade, sejam dentro de
novas APIs ou em APIs existentes, não devem ser considerados para controle do limite
global de transações simultâneas.
Considerando que o Manual de Monitoramento do Open Finance estabelece
que o período de apuração do volume de requisições com status code HTTP 529 é mensal,
assim que o mês de referência se encerrar, a Estrutura de Governança do Open Finance
deve verificar se os volumes diários de requisições com status code HTTP 529 de uma
determinada instituição participante em relação às suas requisições válidas foram
superiores ou iguais ao limite de 0,5%.
Para fins do processo de monitoramento, considera-se que uma determinada
instituição participante está em conformidade caso tenha respeitado o limite de 0,5% em
pelo menos 90% dos dias do mês de referência, arredondando-se para o número inteiro
mais próximo, desde que o volume diário de requisições com status code HTTP 529 dos
demais dias não tenha sido superior a 5%.
Evidências do processo de acompanhamento de limites de TPS devem estar à
disposição do Banco Central do Brasil por um período de doze meses.
5.2 Limites operacionais
É facultado às instituições participantes implementar um limite de acesso
mensal por endpoint e por cliente.
Em endpoints que acessem recursos ou produtos, os limites serão também
considerados por recurso ou produto.
A contabilização dos acessos deve ser feita por:
I - mês;
II - endpoint;
III
- 
objeto
mais
granular
referenciado 
na
chamada
(consentimento/recurso/produto);
IV - cliente (CPF ou CNPJ); e
V - instituição consumidora da informação.
Por exemplo: uma instituição receptora "A" pode acessar um endpoint "B",
acessando o recurso "C", de um cliente "D" da instituição transmissora "E", no mínimo "N"
vezes (ou chamadas) com sucesso por mês.
Aplicabilidade dos limites operacionais: todos os endpoints das APIs do tipo
Dados Cadastrais e Transacionais (conforme classificação por tipo), excetuando-se os
endpoints das APIs de Consentimento (Consents) e Recursos (Resources). As APIs dos tipos
Dados Abertos, de Serviços (como de Iniciação de Pagamento) e de Segurança não podem
ter restrições de limites operacionais.
A implementação dos limites operacionais é opcional pelas instituições
transmissoras, mas, uma vez que sejam implementados, devem garantir o consumo
mínimo estabelecido no Portal do Open Finance. É facultada à instituição a possibilidade
de ampliar estes limites, mas vedada a implementação de limites inferiores aos
estabelecidos.
O Portal do Open Finance deve listar os valores mínimos de limites
operacionais a serem considerados, por endpoint, que devem ser iguais ou maiores que os
abaixo, de acordo com a classificação de frequência de utilização:
I
-
8 chamadas
ao
mês,
para
endpoint
classificado como
de
baixa
frequência;
II - 30 chamadas ao mês, para endpoint classificados como de média
frequência;
III - 120 chamadas ao mês, para endpoint classificados como de média-alta
frequência;
IV - 240 chamadas ao mês, para endpoint classificado como de alta frequência;
e
V - 420 chamadas ao mês, para os seguintes endpoints da API de Contas:
"Saldos da conta" e "Limites da conta".Só deverão ser contabilizadas nos limites
operacionais as requisições respondidas com status code HTTP 2XX (com sucesso), sendo
que as requisições adicionais a um endpoint para fins de paginação não devem ser
contabilizadas.
As requisições que excederem os limites operacionais deverão ser respondidas
com status code HTTP 423.
Todas as requisições autenticadas em endpoints sujeitos ao limite operacional
devem possuir o atributo x-fapi-interaction-id preenchido no seu header pela instituição
receptora de dados, que deve ser copiado pela instituição transmissora de dados nos
headers da resposta. Essa definição objetiva permitir um adequado rastreamento de
divergências que podem ocorrer entre instituições transmissoras e receptoras de dados
associadas ao limite operacional.
5.3 Desempenho
Deverá ser medido o tempo de resposta de cada requisição, ou seja, o tempo
transcorrido entre o recebimento de uma requisição que não ultrapassa os limites de
tráfego e o momento em que a requisição é completamente respondida. Adicionalmente,
esta medição deverá ser feita de maneira que os tempos medidos sejam os mais próximos
possíveis dos tempos de resposta experimentados por quem fez a requisição. A medição
na instituição provedora da API deve iniciar quando a requisição é recebida pelo gateway
e deve terminar após o último byte da resposta desta requisição ser enviado.
5.3.1 Cálculo do desempenho
Para fins do cálculo do desempenho, deve-se considerar o valor do percentil 95
e as requisições para medir o desempenho, que pretende minimizar impacto do
aparecimento de valores extremos (outliers). O valor do percentil 95 pode ser obtido da
seguinte maneira:
I - coleta dos dados: Seja R o conjunto de todos os tempos de resposta de um
dia, onde ri é o tempo de resposta da i-ésima requisição. Ou seja, R={r1, r2, ..., rn};
II - cálculo do índice do percentil 95: o índice para o percentil 95, denotado
por i95, é calculado pela fórmula i95 = 0.95 * n, arredondado para o número inteiro mais
próximo, e onde n representa número de requisições;
III - ordenação dos dados: Ordene o conjunto R em ordem crescente para obter o
conjunto ordenado Rord={r(1), r(2), ..., r(n)}, onde r(1) é o menor tempo de resposta e r(n) é o
maior; e
IV - obtenção do valor do percentil 95: o valor do percentil 95, denotado por
P95, é o valor no índice i95 no conjunto ordenado Rord. Ou seja, P95 = r(i95).
Considerando um exemplo em que um endpoint recebe 10.555 requisições em
um dia (ou seja, n = 10.555). Nesse caso, o índice para o percentil 95 será 10.027 (i95 =
[0.95 * n] = [10.027,25] = 10.027). Após ordenarmos as medições do tempo de resposta
em ordem crescente (formando o conjunto Rord), o valor do percentil 95 (P95) para esse
dia será igual ao tempo de resposta na posição 10.027 no conjunto ordenado Rord.
5.3.2 Service Level Agreement (SLA) do desempenho
Neste contexto, os endpoints das APIs deverão manter, diariamente, o
percentil 95 do tempo de resposta em no máximo:
I
- 1.500ms,
em endpoints
classificados
como de
alta e
média-alta
frequências;
II - 2.000ms, em endpoints classificados como de média frequência; e
III - 4.000ms, em endpoints classificados como de baixa frequência.
Por exemplo, em um dia que um endpoint de alta frequência receba 10.000
requisições, o tempo de resposta de pelo menos 9.500 requisições deve ser inferior a
1.500ms.
Informações adicionais:
I - as medições de tempo de resposta devem ser realizadas de maneira
independente para cada versão "major" dos endpoints em produção;
II - devem ser consideradas as requisições com todos os códigos de retorno
possíveis, com exceção dos associados a limites de tráfego e limites operacionais;
III - esta subseção não se aplica às APIs de "Webhook";
IV - as instituições provedoras devem gerar e acompanhar seus indicadores de
desempenho, de maneira independente da Plataforma de Coleta de Métricas (PCM)
provida pela Estrutura de Governança do Open Finance;
V - as instituições consumidoras das APIs devem registrar os tempos de
resposta das APIs que consomem para envio à PCM. Nelas, a medição do tempo de
resposta de cada requisição deve iniciar no momento antes da requisição ser feita e deve
terminar após o último byte ser recebido, antes de qualquer processamento;
VI - o valor do tempo de resposta a ser considerado para uma requisição é o
valor reportado pelo consumidor da API;
VII - na falta de informações dos consumidores, serão utilizadas as informações
dos provedores para o cálculo do SLA de desempenho; e
VIII - a Estrutura de Governança do Open Finance deverá disponibilizar
indicadores adicionais para monitoramento e aprimoramento do ecossistema, que não
terão, nesse momento, um SLA mínimo, tais como:
a) percentil 95 do tempo de resposta somente de requisições com status code
2XX;
b) percentil 95 do tempo de resposta - provedor - deve considerar todas as
requisições fornecidas pelo provedor das APIs, mesmo quando houver diferença entre as
informações entre provedor e consumidor;
c) percentil 95 do tempo de resposta - consumidor - deve considerar todas as
requisições fornecidas pelos consumidores das APIs, mesmo quando houver diferença
entre as informações entre provedor e consumidor;
d) índice de paridade - percentual do número de requisições no status
"PAIRED" em relação ao total; e
e) média do tempo de resposta até P95 - média do tempo de resposta de todas
as requisições com tempo de resposta menores que o valor do P95.
5.3.3 Aferição do desempenho para fins do processo de monitoramento
Considerando que o Manual de Monitoramento do Open Finance estabelece
que o período de apuração do desempenho é mensal, assim que o mês de referência se
encerrar, a Estrutura de Governança do Open Finance deve verificar se os endpoints das
APIs das instituições participantes atenderam aos SLAs do desempenho definidos na seção
anterior deste manual.
Para fins do processo de monitoramento, considera-se que um endpoint está
em conformidade caso tenha respeitado o SLA do desempenho em pelo menos 90% dos
dias do mês de referência, arredondando-se para o número inteiro mais próximo, desde
que o valor do P95 dos demais dias não tenha sido superior ao SLA do desempenho
aumentado em 20%.
Por exemplo:
I - em um mês de 30 dias, em que um endpoint de alta frequência tenha
apresentado valor de P95 inferior a 1.500ms em 27 dias e, nos demais dias, tenha
apresentado valor de P95 entre 1.500ms e 1.800ms (1.500ms * 1,2 = 1.800ms), o endpoint
está em conformidade para fins do processo de monitoramento naquele mês; e
II - em um mês de 31 dias, em que um endpoint de alta frequência tenha
apresentado valor de P95 inferior a 1.500ms em 28 dias e, nos demais dias, tenha
apresentado, em pelo menos um dos dias, valor de P95 superior a 1.800ms (1.500ms * 1,2
=
1.800ms), o
endpoint
não
está em
conformidade
para
fins do
processo
de
monitoramento naquele mês.
5.4 Disponibilidade
5.4.1 Cálculo da disponibilidade
A disponibilidade dos endpoints das APIs do Open Finance será calculada
empiricamente, baseada na monitoração de requisições válidas. Serão consideradas
"requisições válidas" as requisições que retornam status code da faixa 2XX, 5XX, igual a
408 ou igual a 422. As requisições válidas podem ser divididas em "requisições válidas com
sucesso" - com status code na faixa 2XX ou igual a 422 - e "requisições válidas com erro"
- com status code na faixa 5XX ou igual a 408.
A disponibilidade pontual (t) será calculada como a fração do total de
requisições válidas que cada endpoint recebe e as que ele processa com sucesso a cada
intervalo de 1 minuto. Os intervalos de minuto deverão ser calculados do segundo zero
(0s:000ms) até o segundo 59 (59s:999ms).
1_BCB_12_001