Instituições
Serviços comuns
≥ 95% operacional
90–95% degradado
< 90% falha crítica
Verificando status
Monitoramos, em tempo real, as chamadas feitas às APIs das instituições participantes do ecossistema Open Finance Brasil nas duas fases de uso regulamentadas:
/payments) e automáticos (/automatic-payments); vínculo de dispositivo (/enrollments) habilita autorização sem redirecionamento (JSR) — aplicável às duas famílias.
disponibilidade = respostas bem-sucedidas ÷ total de chamadas
Cada instituição é classificada de acordo com sua disponibilidade na janela:
A disponibilidade acima é a da instituição inteira, e ela dilui falha de API isolada: um endpoint com 60% de erro pode desaparecer numa média de 98% se o resto do tráfego estiver saudável. Por isso o card também olha cada API separadamente: uma API entre 95% e 50% deixa a instituição Degradando (laranja), e uma API abaixo de 50% deixa Degradado (vermelho) — em ambos os casos o percentual exibido continua sendo o da instituição, que pode seguir acima de 95%. No total do ecossistema, uma única API entre 95% e 50% não conta (degradação localizada); duas ou mais contam, e uma API abaixo de 50% conta sempre. Abra o card para ver qual API está fora.
Instituições com poucas chamadas para o tamanho da janela (~5 req/h: 10 em 1h, 60 em 12h) aparecem como Pouco tráfego e ficam recolhidas por padrão. Em volumes pequenos, poucas falhas em poucas chamadas podem ser ruído. A disponibilidade real ainda é exibida (apenas como informativo); ela não influencia a contagem de instituições degradadas.
Qualquer chamada com status HTTP 2xx, 3xx ou 4xx conta como bem-sucedida — 4xx representa erro do cliente (request inválido, sem permissão, consent revogado), não falha do banco. Conta como falha qualquer 5xx ou ausência de resposta (timeout, conexão recusada).
Exceções: mesmo o servidor respondendo, contamos como falha:
404 em /customers
o consumidor autenticado com consentimento válido espera o cadastro ou um 4xx semântico (401/403 se consent revogado, 422 se request inválido). 404 aqui indica que o provedor não cumpriu o contrato BCB.
202 em /resources
GET /resources/v3/resources é o endpoint canônico de polling — 200 = dados do consent prontos, 202 = ainda sincronizando. Pro consumer que tenta consumir dados via consent, 202 é indistinguível de indisponibilidade.
Mostramos a mediana (p50) do tempo que o provedor leva para responder cada chamada na janela — metade das respostas é mais rápida que esse valor, metade é mais lenta. Usamos a mediana, e não a média, porque ela não é distorcida por chamadas isoladas muito lentas. Entram todas as respostas recebidas (2xx a 5xx); chamadas sem resposta (timeout, conexão recusada) não têm tempo de resposta e ficam de fora. O número é exibido para cada instituição e para cada endpoint.
A disponibilidade é calculada sobre uma janela rolante de , atualizada continuamente.
Algumas instituições operam várias marcas (ex.: Itaú / Iti / Itaucard) sob o mesmo CNPJ regulado. As métricas são agregadas por instituição — todas as marcas são incluídas no cálculo.