Regulação de API Banking: O Guia Definitivo dos Padrões Técnicos e Segurança

Bateu a marca de 3,5 bilhões. Esse é o número exato de chamadas de API que o ecossistema do Open Finance brasileiro processa semanalmente agora no final de 2025. Não estamos falando de consultas inofensivas de CEP ou previsão do tempo. São extratos bancários detalhados, limites de cartão de crédito, histórico de fraudes e iniciação de pagamentos via Pix transitando entre servidores do Nubank, Itaú, Mercado Pago e centenas de outras instituições.

Se esse encanamento invisível vazar, o sistema financeiro entra em colapso.

O Banco Central (BACEN) tem plena consciência desse risco sistêmico. O regulador transformou o Brasil no maior laboratório de segurança de APIs financeiras do planeta. Esqueça o OAuth 2.0 básico que você usa para fazer login no Spotify ou no Google. A regulação brasileira exige um nível de criptografia e certificação que força arquitetos de software a repensarem toda a topologia de rede das suas empresas.

Nós acompanhamos a evolução das normativas técnicas desde a públicação da Resolução Conjunta nº 1, lá em maio de 2020. O que vimos nesses cinco anos foi uma escalada brutal de exigências tecnológicas. Hoje, colocar uma API bancária no ar significa passar por uma sabatina técnica impiedosa e contínua. Vamos destrinchar os padrões obrigatórios, os protocolos de segurança e o que isso significa para o caixa e a engenharia da sua operação financeira.

O Padrão FAPI: A blindagem inegociável do BACEN

O Financial-grade API (FAPI) é o coração absoluto da segurança do Open Finance. O BACEN não inventou esse padrão do zero; ele adotou as específicações desenhadas pela OpenID Foundation (OIDF). Especificamente, o Brasil exige o perfil FAPI 1.0 Advanced, com o mercado já testando as águas para a migração rumo ao FAPI 2.0.

Por que não usar o OAuth 2.0 tradicional? Porque o OAuth padrão permite brechas estruturais inaceitáveis para dados financeiros. Ele é vulnerável a ataques de interceptação de tokens, especialmente em aplicativos mobile, e permite ataques de replay (quando um hacker captura uma requisição legítima e a reenvia repetidas vezes).

O FAPI 1.0 Advanced resolve isso amarrando o token de acesso diretamente ao certificado digital do cliente. Se um invasor roubar o token de acesso de uma fintech, ele não consegue usá-lo, pois não possui a chave privada correspondente que gerou a conexão. Nós observamos que essa exigência derrubou muita empresa de tecnologia que tentou entrar no Open Finance achando que bastava subir um gateway na AWS.

Para operar legalmente, a instituição precisa passar pelos testes do motor de conformidade da OpenID Foundation. Você roda um script massivo contra a sua API e, se passar em todos os milhares de cenários de teste, recebe um selo público. Sem esse selo, o BACEN bloqueia seu acesso ao ecossistema.

Autenticação Mútua (mTLS) e a Criptografia de Mensagens

A segurança de transporte de dados no Open Finance brasileiro é draconiana. O padrão de mercado para a web é o TLS (Transport Layer Security), onde apenas o servidor prova quem é através do cadeado verde no navegador. O BACEN exige o mTLS (Mutual TLS).

No mTLS, a via é de mão dupla. O cliente (uma fintech iniciadora de pagamento) e o servidor (o banco detentor da conta) precisam apresentar certificados digitais válidos simultaneamente antes de trocar um único byte de informação. Pense no mTLS como o cofre de um banco suíço: o gerente e o cliente precisam girar suas chaves ao mesmo tempo para a porta abrir.

Esses certificados não são comprados em provedores comuns. Eles são emitidos exclusivamente por Autoridades Certificadoras (ACs) credenciadas na ICP-Brasil, contendo atributos específicos do Open Finance (como o número de autorização do BACEN da instituição).

O peso do JWS e JWE nos payloads

Além de proteger o tubo por onde a informação passa (o mTLS), o BACEN exige a proteção da própria informação. Entram em cena o JWS (JSON Web Signature) e o JWE (JSON Web Encryption).

Qualquer requisição que envolva criação de consentimento ou iniciação de pagamento exige que o payload (o corpo da mensagem) seja assinado digitalmente com JWS. A fintech pega os dados da transação, aplica uma função de hash com sua chave privada e anexa a assinatura no cabeçalho HTTP. Quando o banco recebe a requisição, ele verifica a assinatura com a chave pública da fintech. Se um único centavo for alterado no meio do caminho, a assinatura quebra e a transação é sumariamente negada.

O JWE vai além: ele criptografa o conteúdo. Apenas o destinatário final consegue ler os dados. Essa dupla camada garante integridade (JWS) e confidencialidade (JWE) absolutas.

DCR: O cartório automatizado do sistema

Como uma fintech recém-autorizada pelo BACEN consegue se conectar aos sistemas de um gigante como o Bradesco ou a Caixa Econômica Federal? Eles não trocam e-mails com credenciais. O processo usa o Dynamic Client Registration (DCR).

O DCR permite que o software da fintech se apresente automaticamente à API do banco. A fintech baixa um Software Statement Assertion (SSA) — um passaporte digital criptografado — diretamente do Diretório Central do Open Finance. A API da fintech envia esse SSA para a API do banco via DCR. O banco valida a assinatura do Diretório Central, registra a fintech em milissegundos e devolve as credenciais de acesso (Client ID).

Esse modelo de arquitetura Zero Trust (Confiança Zero) descentraliza a operação. Se o BACEN caçar a licença de uma fintech às 14h, o Diretório Central revoga o certificado às 14h01, e às 14h02 todas as APIs dos bancos do país rejeitam automaticamente qualquer nova conexão daquela empresa.

Gestão de Consentimento e o Motor de Regras

O consentimento no Open Finance não é um botão de 'Li e Aceito'. É uma máquina de estados complexa exigida pela regulação. O ciclo de vida de um consentimento passa por fases estritas: AWAITING_AUTHORISATION (Aguardando Autorização), AUTHORISED (Autorizado), REJECTED (Rejeitado) e REVOKED (Revogado).

As APIs precisam gerenciar essas transições com precisão de relógio suíço. O BACEN determinou que os consentimentos de compartilhamento de dados podem durar até 12 meses, mas o cliente pode revogá-los a qualquer segundo, seja pelo app da fintech, seja pelo app do banco detentor.

A API do banco precisa propagar essa revogação instantaneamente. Se um cliente revoga o acesso aos seus dados no app do Itaú, e cinco minutos depois a API do GuiaBolso (ou qualquer outro agregador) tenta buscar o saldo, a API do Itaú deve retornar um erro HTTP 403 (Forbidden) imediatamente. Falhas nesse motor de regras geram multas pesadas por violação da LGPD e das normativas do Conselho Monetário Nacional (CMN).

SLAs de Performance: A guilhotina regulatória

Segurança não serve para nada se o sistema estiver fora do ar. O Manual de Níveis de Serviço do Open Finance, regulamentado pela Resolução BCB nº 279/2022 e atualizações subsequentes, define a guilhotina de performance para as APIs.

A exigência de uptime (tempo no ar) é de 99,9%. Isso significa que a API de um banco só pode ficar fora do ar por cerca de 43 minutos por mês. Passou disso, o radar do BACEN aciona.

Os tempos de resposta (latência) também são tabelados. Uma API de iniciação de pagamento precisa responder em no máximo 1000 milissegundos. Consultas de dados cadastrais não podem demorar mais de 1500 milissegundos no percentil 95 (ou seja, 95% das requisições devem ser mais rápidas que isso).

O regulador monitora esses SLAs de forma implacável através de chamadas sintéticas disparadas pelo Diretório Central. Instituições que não sustentam a carga recebem ofícios, multas e, em casos extremos, sofrem suspensão preventiva do ecossistema.

Iniciação de Pagamentos e o Desafio do CIBA

A grande febre de 2025 é a Jornada Sem Redirecionamento (JSR) para iniciação de pagamentos Pix. Antes, o usuário precisava sair do app do e-commerce, abrir o app do banco, digitar a senha e voltar. A conversão despencava.

Para resolver isso sem comprometer a segurança, o BACEN exigiu a implementação do protocolo CIBA (Client Initiated Backchannel Authentication).

Com o CIBA, a comúnicação acontece nos bastidores (backchannel). A API da loja inicia o pagamento direto com o banco. O banco envia uma notificação push para o celular do cliente. O cliente aprova com biometria no app do banco, e a API do banco avisa a API da loja de forma assíncrona que o pagamento foi liberado. A complexidade de orquestrar webhooks, gerenciar timeouts e manter a sessão segura com FAPI no meio de tudo isso é o maior desafio de engenharia atual para adquirentes como Stone e PagSeguro.

Implicações Práticas: O Custo da Conformidade

Na prática, desenvolver e manter toda essa infraestrutura de API banking dentro de casa custa milhões de reais por ano. Uma equipe interna precisa lidar com rotação contínua de certificados mTLS, atualizações trimestrais de segurança da OIDF, monitoramento de SLAs 24/7 e gestão de incidentes.

O resultado? A consolidação explosiva do modelo de Open Finance as a Service (OFaaS). Empresas focadas em infraestrutura, como Sensedia, Celcoin, Dock, Belvo e Iniciador, assumiram o trabalho sujo. Elas constroem a ponte certificada pelo BACEN e entregam para as fintechs menores uma API RESTful simples e amigável.

Se você opera uma instituição de pagamento, o dilema 'comprar vs. construir' já não existe. A menos que você seja um Nubank ou Mercado Pago com milhares de engenheiros, tentar construir uma infraestrutura FAPI do zero hoje é queimar capital de risco sem necessidade.

A regulação de APIs bancárias no Brasil provou um ponto crucial: a padronização forçada gera inovação segura. O BACEN subiu a barra técnica para um nível onde aventureiros não sobrevivem. O Open Finance brasileiro funciona, é rápido e é seguro exatamente porque suas fundações de software foram forjadas sob a regulação mais dura do mercado global. Para as empresas de tecnologia, o recado é claro: domine a infraestrutura ou seja engolido por quem já a dominou.