INSTRUÇÃO NORMATIVA BCB Nº 615, DE 6 DE MAIO DE 2025 (parte 3 de 3)

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
Por exemplo, a disponibilidade pontual de um endpoint referente ao minuto
11:34, de um determinado dia, no qual houve um total de requisições válidas com sucesso
de 255 e um total de requisições válidas com erro de 4, é calculada da seguinte forma: 1_BCB_12_002
Dessa forma, obtém-se o indicador percentual para cada janela de tempo de 1
minuto. Cada período de 1 minuto será classificado como "disponível" ou "indisponível". Se
a "disponibilidade pontual" da janela de tempo ficar abaixo de 95% isso indicará que ela
será considerada como "indisponível", caso contrário será "disponível".
Períodos que não tenham requisições válidas são considerados "indefinidos" e
são desconsiderados para cálculo da disponibilidade. 1_BCB_12_003
A disponibilidade diária será calculada baseada nas informações das
disponibilidades pontuais. 1_BCB_12_004
Por exemplo, considerando um dia em que houve requisições válidas em 1.390
das 1.440 faixas de 1 minuto possíveis (1 dia = 24h * 60min = 1.440 faixas de horário) para
um endpoint específico "x" de versão 1, e dos quais 30 períodos tiveram a disponibilidade
menor que o limite de disponibilidade definido (95%), a Disponibilidade Diária de "x" v1
será igual a: 1_BCB_12_005
A disponibilidade longa deverá ser calculada diariamente como média móvel das
disponibilidades dos últimos noventa dias corridos, considerando somente os dias em que a
disponibilidade diária pode ser calculada (teve pelo menos uma disponibilidade pontual diferente
de "indefinido"). Ou seja, caso nos últimos noventa dias tenhamos dois dias calculados como
indefinidos, a média deve ser calculada considerando somente as 88 disponibilidades válidas.
A aferição mensal deve considerar a disponibilidade longa do último dia do mês
de referência.
5.4.2 SLA da disponibilidade
Cada um dos endpoints das APIs categorizadas como "Dados Abertos", "Dados Cadastrais
e Transacionais", "Relatórios e Métricas", por versão, e os endpoints das APIs de "Segurança"
"/register" e "/token", deverão satisfazer os requisitos mínimos de disponibilidade abaixo:
I - disponibilidade diária (calendário): 95%; e
II - disponibilidade longa (média móvel de 90 dias), medida diariamente: 99,5%.
As APIs classificadas como "Serviços de Iniciação de Pagamentos" seguem o
definido na regulamentação do Pix.
Informações adicionais:
I - as medições devem ser feitas todos os dias, em todas as faixas de 1 minuto
disponíveis, iniciando na primeira faixa (00:00:00-00:00:59) e terminando na última faixa
(23:59:00-23:59:59), considerando o horário de Brasília;
II - as medições de disponibilidade devem ser feitas para cada versão major dos
endpoints em produção. Por exemplo, em períodos de convivência o endpoint de
v1/resources poderia estar disponível no mesmo período em que o endpoint de
v2/resources estaria também disponível. É importante que suas disponibilidades sejam
calculadas de maneira independente;
III - as instituições provedoras devem gerar e acompanhar seus indicadores de
disponibilidade, de maneira independente da Plataforma de Coleta de Métricas (PCM)
provida pela Estrutura de Governança do Open Finance;
IV - o status code a ser considerado para uma requisição é o valor reportado
pelo consumidor da API;
V - na falta de informações dos consumidores, serão utilizadas as informações
dos provedores para o cálculo do SLA de disponibilidade;
VI - a indisponibilidade programada não exime o cálculo da disponibilidade no
período apurado;
VII - esta subseção não se aplica às APIs de "Webhook";
VIII - a disponibilidade de endpoints que não tenham requisições válidas no
período apurado será considerada "indefinida", não estando sujeita a um SLA; e
IX - 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) disponibilidade calculada do ponto de vista do provedor da API - deve
considerar as informações fornecidas pelo provedor das APIs; e
b) disponibilidade calculada do ponto de vista do consumidor da API - deve
considerar as informações fornecidas somente pelos consumidores das APIs, classificadas
no PCM como "PAIRED" ou "SINGLE".
5.5 Timeout
Padronização do timeout de tempo de resposta do provedor e do tempo de
resposta do consumidor em quinze segundos.
As requisições que excederem o limite de timeout do provedor deverão ser
respondidas com o status code HTTP 504 (Gateway Timeout).
6. Regras transitórias
As mudanças realizadas na seção 5.1.1 entram em vigor a partir de 1º de setembro de 2025.
Brasília, 6 de maio de 2025.