Monitoramento do Open Finance: guia técnico de APIs e SLAs

O Open Finance Brasil já ultrapassou 200 milhões de consentimentos e conecta mais de 800 instituições por meio de APIs padronizadas. Toda essa operação funciona sob regras rígidas do Banco Central, que mede disponibilidade, latência e qualidade de dados de cada participante.

Desde a publicação do Manual de Monitoramento, cada instituição recebe notas de 0 a 10. Quem fica abaixo da nota mínima de conformidade entra em descumprimento e pode sofrer multas em caso de reincidência. Por isso, o monitoramento do open finance deixou de ser diferencial: virou requisito operacional e regulatório.

Neste guia, você vai entender como o Banco Central supervisiona o ecossistema e como estruturar a observação técnica das suas APIs. A lógica é parecida com a do monitoramento do sistema Pix: traduzir exigências regulatórias em métricas, alertas e dashboards acionáveis.

O que é o Open Finance e como funciona sua arquitetura de APIs

O Open Finance é o sistema financeiro aberto brasileiro, regulado pelo Banco Central. Ele permite que clientes compartilhem seus dados financeiros entre instituições, mediante consentimento. O modelo nasceu como Open Banking em 2021 e depois ampliou o escopo para investimentos, seguros, câmbio e previdência.

Na prática, todo o ecossistema funciona sobre APIs REST padronizadas. Cada participante expõe endpoints de dados cadastrais, transacionais e de iniciação de pagamento. Além disso, um diretório central registra as instituições autorizadas e seus certificados.

A segurança segue o padrão FAPI (Financial-grade API), com OAuth 2.0, mTLS e certificados ICP-Brasil. As especificações técnicas completas estão na área do desenvolvedor do ecossistema.

Fases e participantes do ecossistema

A implantação aconteceu em quatro fases desde 2021. A primeira abriu dados públicos das instituições, como canais de atendimento e produtos. A segunda liberou o compartilhamento de dados cadastrais e transacionais dos clientes. Já a terceira trouxe a iniciação de pagamentos, enquanto a quarta expandiu o escopo para o Open Finance completo.

Hoje, mais de 800 instituições autorizadas pelo Banco Central participam do ecossistema. Para os grandes bancos dos segmentos S1 e S2, a adesão é obrigatória. As demais instituições entram voluntariamente, em geral atraídas pela reciprocidade: quem consome dados também precisa fornecer.

Para o time de operações, isso significa um ponto importante: cada endpoint exposto é um serviço crítico de produção. Consequentemente, as disciplinas clássicas de monitoramento de APIs se aplicam aqui, porém com thresholds definidos por regulação, não apenas por metas internas.

Como o Banco Central monitora o ecossistema

O marco central é o Manual de Monitoramento do Open Finance, publicado pela Instrução Normativa BCB nº 441, de dezembro de 2023. O documento define as regras e os procedimentos usados para avaliar o desempenho dos participantes no compartilhamento de dados e serviços.

A partir de 2025, o modelo evoluiu para notas de 0 a 10, organizadas por categorias e por produto. A nota mínima de conformidade é 7: abaixo disso, a instituição está em descumprimento. Em abril de 2026, a média do ecossistema atingiu esse patamar pela primeira vez, segundo a Associação Open Finance.

O primeiro capítulo do modelo avalia a resiliência. Ele reúne indicadores de sobrecarga de servidor, desempenho (latência das APIs) e disponibilidade de curto prazo (30 dias) e de longo prazo (90 dias). Outros capítulos acompanham qualidade de dados, jornada do cliente e taxa de conversão.

Vale destacar que o Banco Central divulga estatísticas públicas de desempenho na sua página oficial. Ou seja, a reputação técnica da instituição fica exposta ao mercado.

Esse acompanhamento complementa a supervisão tradicional. As estatísticas alimentam rankings públicos e medidas que vão de planos de ação a sanções. Em síntese, a régua existe, é pública e aperta a cada ciclo. Assim, tratar essas exigências dentro da estratégia de monitoramento de TI da casa é o caminho natural para não ser surpreendido.

Requisitos de disponibilidade e desempenho das APIs

O ecossistema define disponibilidade de forma empírica, baseada nas requisições reais que chegam aos endpoints. São consideradas requisições válidas aquelas com status code na faixa 2XX, na faixa 5XX, igual a 408 ou igual a 422.

Dentro desse conjunto, as requisições com 2XX ou 422 contam como sucesso. Já as respostas 5XX e 408 contam como erro. A disponibilidade de cada endpoint é o percentual de sucesso sobre o total de requisições válidas, calculado nas janelas de 30 e 90 dias.

Um exemplo ajuda a visualizar. Imagine um endpoint com 100 mil requisições válidas em 30 dias: 97 mil respostas 2XX, mil respostas 422 e 2 mil respostas 5XX. A disponibilidade fica em 98%, resultado de (97.000 + 1.000) / 100.000. Esse é o número que o ecossistema enxerga.

No desempenho, o indicador oficial é o percentil 95 do tempo de resposta das requisições com sucesso, medido por API e por provedor. A medição começa antes do envio da requisição e termina após o recebimento do último byte. As instituições que consomem APIs registram esses tempos e enviam os dados à PCM, a plataforma de coleta de métricas do ecossistema.

Para a operação, isso muda a forma de definir metas internas. Em vez de inventar números, o time parte dos limites regulatórios e define SLOs e SLIs mais apertados que eles. Dessa forma, o alerta interno dispara antes de o indicador oficial entrar em zona de risco.

Limites de tráfego e janelas de medição

Além dos SLAs, o ecossistema define limites de tráfego por endpoint, medidos em transações por minuto. Ao ultrapassar o limite, a instituição pode responder com 429 sem penalidade direta na disponibilidade. No entanto, respostas de sobrecarga frequentes entram no radar do capítulo de resiliência.

Outro detalhe importante: as janelas de 30 e 90 dias são móveis. Uma indisponibilidade longa hoje continua pesando na média por semanas. Portanto, recuperar a nota exige estabilidade prolongada, não apenas resolver o incidente do dia.

Métricas essenciais para o monitoramento do open finance

Com os requisitos mapeados, o próximo passo é transformá-los em métricas coletadas continuamente. A tabela abaixo resume as cinco mais importantes para instituições participantes, com a forma de medição e o impacto regulatório de cada uma.

Cabe ressaltar um detalhe operacional: a disponibilidade regulatória ignora respostas 4XX comuns, como 401 e 404. Portanto, replicar a fórmula oficial no seu monitoramento evita falsos positivos e divergências em relação ao número apurado pelo ecossistema.

Outro ponto é a granularidade. Médias diárias escondem janelas curtas de degradação. Em contrapartida, séries por minuto permitem correlacionar picos de latência com deploys, lentidão de banco ou saturação de infraestrutura.

Monitoramento sintético da jornada de consentimento

Medir requisições reais resolve metade do problema. A outra metade aparece quando não há tráfego: de madrugada, um endpoint pode ficar fora do ar sem que nenhuma requisição válida registre a falha. É exatamente esse vazio que o monitoramento sintético preenche.

A técnica consiste em executar transações simuladas em intervalos regulares, reproduzindo a jornada completa. O ciclo inclui autenticação no diretório, criação de consentimento, autorização e consumo do dado compartilhado. Assim, a operação descobre falhas de ponta a ponta antes do cliente e antes do regulador.

Esse cuidado importa ainda mais nos fluxos novos. O Pix Automático, por exemplo, virou o ponto fraco do ecossistema, com taxa de conversão em torno de 35% nas jornadas. Ou seja, problemas de jornada são reais e mensuráveis, não hipotéticos.

Nesse sentido, vale tratar a jornada de consentimento como um serviço de monitoração da experiência do usuário. Cada etapa do funil vira um checkpoint sintético, com tempo máximo e validação de resposta esperada.

Defina a frequência conforme a criticidade de cada fluxo. Checagens a cada minuto funcionam bem para autenticação e consentimento, enquanto endpoints de dados aceitam intervalos de cinco minutos. Use credenciais de teste dedicadas para não poluir os indicadores oficiais com tráfego artificial.

Desafios que derrubam a nota das instituições

Na prática, alguns padrões de falha se repetem entre os participantes com nota baixa. Conhecê-los ajuda a priorizar o que monitorar primeiro.

Certificados e renovação de tokens

O mTLS exige certificados válidos dos dois lados da conexão. Um certificado expirado derruba todos os consumidores de uma vez, sem gerar nenhum alerta de infraestrutura tradicional. Por isso, monitore a validade dos certificados com antecedência mínima de 30 dias e acompanhe a taxa de falhas de handshake TLS.

Dependências de terceiros

Boa parte das instituições opera a camada de APIs com fornecedores de tecnologia. Nesse cenário, o SLA do fornecedor precisa aparecer no seu monitoramento, com medições próprias e independentes. Afinal, a nota pública é da instituição, não do parceiro.

Versionamento das APIs

As especificações evoluem com frequência e versões antigas saem de operação. Chamadas para versões aposentadas geram erros que contaminam os indicadores. Vale acompanhar o cronograma de depreciação na documentação oficial e validar os endpoints após cada migração.

Dashboards e alertas para o NOC

As métricas só geram valor quando chegam a quem opera. O primeiro passo é montar um dashboard único por API, combinando disponibilidade 30/90 dias, latência p95, taxa de erro e volume de requisições. Em seguida, acrescente uma visão executiva com a projeção da nota de resiliência da instituição.

Considere ainda um painel por produto, espelhando a estrutura de notas do regulador. Quando a visão interna usa as mesmas categorias da avaliação oficial, a conversa entre operação, compliance e diretoria flui sem tradução. Cada área enxerga o mesmo risco, no mesmo formato, com a mesma régua.

Os alertas devem seguir a lógica de margem de segurança. Por exemplo: se o limite regulatório de disponibilidade é 95% em 30 dias, alerte ao atingir 97%. Dessa forma, sobra tempo de reação antes do descumprimento.

Também é essencial conectar o alerta da API à causa raiz na infraestrutura. A correlação de eventos liga o pico de latência p95 ao banco de dados saturado, ao pod reiniciando ou ao certificado prestes a expirar.

Calibre também a severidade com critério. Disparar acionamento para cada oscilação de latência gera fadiga de alertas e treina o time a ignorar avisos. Reserve a notificação imediata para risco regulatório e degradação percebida pelo cliente.

Por fim, documente runbooks por tipo de alerta: o que verificar, quem acionar e qual o prazo de resposta. Equipes de NOC com procedimentos claros reduzem o MTTR e ainda mantêm evidências de diligência para auditorias e questionamentos do regulador.

Conclusão

O monitoramento do open finance une duas disciplinas que costumavam andar separadas: observabilidade técnica e conformidade regulatória. O Banco Central definiu métricas objetivas, janelas de medição e notas públicas. Cabe à instituição transformar essas regras em telemetria, alertas e resposta rápida.

O caminho prático passa por quatro frentes. Primeiro, replicar a fórmula oficial de disponibilidade e latência p95 nas suas ferramentas. Depois, cobrir os vazios de tráfego com monitoramento sintético da jornada de consentimento. Em seguida, correlacionar APIs com infraestrutura para acelerar o diagnóstico. Por fim, alertar com margem de segurança antes da zona de descumprimento.

Instituições que estruturam essa operação reduzem risco de multa, protegem a nota pública e ainda melhoram a experiência do cliente. Se a sua equipe precisa de apoio para montar essa esteira, fale com um especialista da OpServices e conheça nossa abordagem para ambientes financeiros críticos.