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

TEXTO OFICIAL · ÍNTEGRA

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