Controle de versão
Versão | Data | Resumo das alterações |
1 | 27 31 de maijan. de 20242025 | Versão inicial |
Introdução e Objetivos
Esta métrica visa monitorar e assegurar que as APIs das instituições participantes do Open Finance estejam aderentes aos padrões de desempenho e disponibilidade estabelecidos. A Estrutura Responsável pela Governança do Open Finance monitora essas questões para garantir a integridade, eficiência e eficácia do ecossistema do Open Finance.
Sobre a Métrica
A métrica se baseia em dois aspectos principais para determinar a conformidade das APIs das instituições participantes: a disponibilidade das APIs e o tempo de resposta das APIs.
Disponibilidade das APIs
Disponibilidade Diária: Monitoramento diário da disponibilidade das APIs, calculada como a fração do total de requisições válidas processadas com sucesso a cada intervalo de 1 minuto.
Disponibilidade Longa: Média móvel das disponibilidades dos últimos 90 dias corridos, considerando apenas os dias em que a disponibilidade diária pode ser calculada.
Tempo de Resposta das APIs
Desempenho: Medição do tempo de resposta de cada requisição, desde o recebimento da requisição pelo gateway até o envio do último byte da resposta. O valor do percentil 95 (P95) do tempo de resposta é utilizado para minimizar o impacto de valores extremos (outliers).
Critérios de Conformidade:
Disponibilidade das APIs
Disponibilidade diária mínima de 95%.
Disponibilidade longa (média móvel de 90 dias) mínima de 99.5%.
Tempo de Resposta das APIs
Percentil 95 do tempo de resposta:
1.500ms para endpoints de alta e média-alta frequências.
2.000ms para endpoints de média frequência.
4.000ms para endpoints de baixa frequência.
Informações Adicionais
As medições devem ser feitas para cada versão major dos endpoints em produção.
As requisições com todos os códigos de retorno possíveis devem ser consideradas, exceto aquelas associadas a limites de tráfego e operacionais.
As medições de tempo de resposta e disponibilidade devem ser realizadas de maneira independente pela instituição provedora da API, além da Plataforma de Coleta de Métricas (PCM).
A Estrutura Responsável pela Governança do Open Finance deve disponibilizar indicadores adicionais para monitoramento e aprimoramento do ecossistema.
APIs de Iniciação de Pagamentos (Pix)
De acordo com o arranjo do Pix, o período de apuração do índice de disponibilidade é mensal. Todos os participantes do Pix devem apurar seu próprio índice de disponibilidade, podendo o BCB solicitar, a qualquer tempo, informações adicionais dos participantes para validação do índice informado, bem como utilizar mecanismos de validação dessa informação por meio de informações disponíveis na infraestrutura operada pelo BCB.
A meta mensal de índice de disponibilidade de cada categoria de participante é a seguinte:
...
Categoria
...
Disponibilidade
...
A
...
99,5%
...
B
...
99,0%
...
C
...
98,5%
...
D
...
as requisições que excederem os limites de TPS e que devem ser respondidas com status code HTTP 529 (Site is overloaded). A Estrutura de Governança do Open Finance visa, com esta métrica, fornecer informação sobre a infraestrutura das instituições provendo APIs no Open Finance que deve ter a capacidade de, no mínimo, atender a 300 requisições simultâneas por segundo (TPS).
Sobre a Métrica
A métrica se baseia no volume de requisições excedentes que retornam o status code HTTP 529.
Metodologia Simplificada
Para fins de monitoramento deste item, o período de apuração será mensal, conforme orientado pelo Manual de Monitoramento do Open Finance Brasil. A avaliação envolverá:
Disponibilidade diária: Monitoramento da disponibilidade diária de todos os dias do mês de referência.
Disponibilidade longa: Cálculo da disponibilidade longa como média móvel dos últimos 90 dias.
Tempo de Resposta: Medição do tempo de resposta de cada requisição e cálculo do percentil 95 (P95) do tempo de resposta.
Interpretação dos Resultados
Os resultados da métrica serão interpretados para verificar se as instituições estão cumprindo os critérios de conformidade para desempenho e disponibilidade das APIs. A análise incluirá:
Disponibilidade das APIs
Disponibilidade Diária
A disponibilidade pontual (t) é calculada como a fração do total de requisições válidas processadas com sucesso a cada intervalo de 1 minuto. 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:
...
A disponibilidade diária é calculada baseada nas informações das disponibilidades pontuais.
Disponibilidade Longa
A disponibilidade longa é calculada diariamente como média móvel das disponibilidades dos últimos 90 dias corridos. Por exemplo, a disponibilidade longa do último dia de março é a média das disponibilidades diárias dos últimos 90 dias.
Tempo de Resposta das APIs
Cálculo do Desempenho
Para fins do cálculo do desempenho, deve-se considerar o valor do percentil 95 (P95) dos tempos de resposta diários.
Exemplo: Se um endpoint recebe 10.555 requisições em um dia (n = 10.555), o índice para o percentil 95 (i95) será 10.027 (i95 = [0.95 * n] = [10.027,25] = 10.027). Ordenando os tempos de resposta em ordem crescente (Rord), o valor do percentil 95 (P95) será o tempo de resposta na posição 10.027 no conjunto ordenado Rord
Service Level Agreement (SLA)
Endpoints de alta e média-alta frequências: P95 do tempo de resposta em no máximo 1.500ms.
Endpoints de média frequência: P95 do tempo de resposta em no máximo 2.000ms.
Endpoints de baixa frequência: P95 do tempo de resposta em no máximo 4.000ms.
Aferição do Desempenho
...
A metodologia adotada para o monitoramento do volume de requisições com status code HTTP 529 avalia se, diariamente, esse volume é inferior a 0,5% das requisições válidas.
Aspectos Técnicos
Excluir chamadas com status 'PAIRED_INCONSISTENT' e ‘DISCARTED’
Considerar as requisições válidas que retornam status code da faixa 2XX, 5XX, igual a 408 ou igual a 422
Interpretação dos Resultados
Para fins do processo de monitoramento, o período de apuração referente a este item é mensal e a análise de desconformidade é feita por conglomerado.
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%.
Exemplo Ilustrativo
Para ilustrar as condições de conformidade e desconformidade, considere os seguintes exemplos:
Conformidade
Em um mês de 30 dias, um endpoint de alta frequência deve apresentar um valor de P95 inferior a 1500ms em pelo menos 90% dos dias (27 dias). Nos demais dias, o valor de P95 pode ser até 20% superior ao SLA (1500ms * 1,2 = 1800ms).
Dia | P95 (ms) | Conformidade |
|---|---|---|
1 | 1400 | Sim |
2 | 1450 | Sim |
3 | 1600 | Sim |
… | … | … |
27 | 1500 | Sim |
28 | 1750 | Sim |
29 | 1780 | Sim |
30 | 1790 | Sim |
Neste exemplo, o endpoint está em conformidade para fins do processo de monitoramento naquele mês, pois em 27 dias o P95 foi inferior a 1500ms e, nos demais dias, o P95 não ultrapassou 1800ms.
Desconformidade
Em um mês de 31 dias, um endpoint de alta frequência deve apresentar um valor de P95 inferior a 1500ms em pelo menos 90% dos dias (28 dias). Nos demais dias, o valor de P95 pode ser até 20% superior ao SLA (1500ms * 1,2 = 1800ms). Se em qualquer um desses dias o P95 for superior a 1800ms, o endpoint estará em desconformidade.
Dia | P95 (ms) | Conformidade |
|---|---|---|
1 | 1400 | Sim |
2 | 1450 | Sim |
3 | 1600 | Sim |
… | … | … |
28 | 1500 | Sim |
29 | 1820 | Não |
30 | 1750 | Sim |
31 | 1790 | Sim |
Neste exemplo, o endpoint não está em conformidade para fins do processo de monitoramento naquele mês, pois em pelo menos um dos dias (dia 29), o P95 foi superior a 1.800ms.
Para maior clareza, veja a representação visual dos exemplos:
Mês | Dias do mês | Dias com P95 < 1500ms | Dias com P95 entre 1500ms e 1800ms | Dias com P95 > 1800ms | Conformidade |
|---|---|---|---|---|---|
Março | 30 | 27 | 3 | 0 | Sim |
Abril | 31 | 28 | 2 | 1 | Não |
Aspectos Técnicos
Sob a perspectiva da Plataforma de Coleta de Métricas (PCM), os dados são predominantemente observados do lado do servidor. Na terminologia da PCM, o servidor é a instituição que fornece os dados em resposta a uma solicitação, enquanto o cliente é a instituição que faz a solicitação de dados. A avaliação da métrica é feita com base nos reportes enviados tanto pelo servidor quanto pelos seus respectivos reportadores (clientes). Quando não há reporte do cliente, é considerado o reporte do próprio servidor.
O status UNPAIRED é utilizado para indicar que o cliente ainda não reportou para a PCM. Além disso, são considerados os status codes 408, 5XX (família 500), 2XX (família 200) e 422 para todos os endpoints obrigatórios da instituição participante em análise, desde que o status não seja PAIRED_INCONSISTENT (pareados e inconsistentes).
Registros com os status UNPAIRED e PAIRED_INCONSISTENT são considerados divergentes e devem passar pelo processo de resolução. Esses registros indicam que houve uma discrepância entre os reportes enviados pelo cliente e pelo servidor ou que o reporte do cliente ainda não foi recebido, respectivamente. A conciliação dessas divergências é essencial para manter a integridade e a precisão dos dados coletados pela PCMo seguinte exemplo:
O Banco ABC, com uma capacidade inicial de 300 TPS, recebeu um pico de 350 TPS em 05/12. As 50 requisições excedentes retornaram o status HTTP 529, totalizando 0,54% das requisições válidas naquele dia. Isso exige um aumento imediato da capacidade para 450 TPS.
Ainda no mês de dezembro, o Banco ABC teve 28 dias dentro do limite de 0,5%, 2 dias com valores entre 0,51% e 5%, e 1 dia crítico com 6,2%. Como violou o limite de 5% em um dia, foi classificado como não conforme, mesmo tendo 90% dos dias dentro do padrão.
Dados e Fontes
Para o cálculo da métrica, utiliza-se um conjunto diversificado de dados provenientes de diferentes fontes. A principal fonte informacional é a Plataforma de Coleta de Métricas (PCM), que consolida os dados a partir dos reportes enviados pelas instituições participantes. Além disso, as planilhas auto reportadas pelas instituições são integradas e consolidadas na Plataforma Analítica de Dados (PAD), um repositório centralizado que serve como base para a análise e avaliação da métrica. Essa combinação de dados provenientes da PCM e das planilhas auto reportadas permite uma avaliação precisa da métrica e um monitoramento efetivo do desempenho e disponibilidade das APIs no contexto do Open Finance.
...