Boas práticas para implementar APIs de Open Finance seguras

Última atualização: 25 de julho de 2026

Principais lições deste artigo

• APIs de Open Finance precisam de mTLS, OAuth 2.0 com PKCE e PAR, além de consentimentos granulares e logs imutáveis, para atender aos padrões do Banco Central e do Open Finance Brasil.

• A arquitetura recomendada usa um API Gateway com validação de certificados, rate limiting por cliente e por endpoint, WAF contra BOLA e monitoramento contínuo com SIEM.

• Consentimentos devem ser explícitos, limitados a 12 meses, revogáveis em tempo real e vinculados a escopos parametrizados no formato consent:{Consent Resource Id}.

• Erros como tokens de longa duração, ausência de PAR e reutilização de dados sem consentimento aumentam o risco regulatório e a chance de falhas na homologação.

• Para implementar APIs de Open Finance seguras e escaláveis, conte com a infraestrutura da Celcoin.

Conceitos essenciais de segurança no Open Finance

Dominar alguns conceitos técnicos acelera decisões de arquitetura e reduz retrabalho em auditorias e homologações.

• FAPI (Financial-grade API): perfil de segurança de alto nível baseado em OAuth 2.0 e OpenID Connect. O Open Finance Brasil Financial-grade API Security Profile v2.2.0, atualizado em 20/05/2026, define os padrões de segurança para o mercado brasileiro e se alinha ao Manual de Segurança do Banco Central.

• mTLS (Mutual TLS): autenticação mútua via certificados digitais que garante a identificação de cliente e servidor antes de qualquer troca de dados. O perfil FAPI-BR 2.0 (FAPI-Único) adota Private Key mais PAR como perfil único e mantém mTLS apenas em perfis legados durante o período de convivência.

• OAuth 2.0 com PKCE: fluxo de autorização que adiciona um verificador criptográfico (code_verifier e code_challenge) para impedir ataques de interceptação de código. Authorization Servers devem exigir PKCE nos fluxos de autorização.

• Consentimento granular: modelo em que o usuário autoriza escopos específicos de dados, como saldo, transações e cadastro, de forma independente, com prazo máximo de 12 meses e revogação em tempo real.

• Tokens de curta duração: emissão de access tokens com expiração curta, o que reduz a janela de exploração em caso de vazamento.

• Logs imutáveis: registros append-only de cada evento de acesso a dados, com hash encadeado para detecção de adulteração e integração com plataformas SIEM para monitoramento contínuo.

Com esses conceitos estabelecidos, fica mais simples estruturar uma arquitetura de produção que atenda às exigências técnicas e regulatórias.

Arquitetura recomendada para APIs seguras

A implementação segura de APIs de Open Finance segue uma sequência de camadas de proteção que se complementam.

1. API Gateway com validação mTLS: toda requisição entra pelo gateway, que valida o certificado BRCAC do cliente antes de qualquer processamento. Configure o gateway para rejeitar conexões sem certificado válido e para encaminhar o CN do certificado como header interno para os serviços downstream.

2. Validação OAuth 2.0 mais PKCE mais PAR: authorization servers devem exigir pushed authorization requests, autenticação de cliente via private_key_jwt e PKCE. O PAR garante o envio direto dos parâmetros de autorização ao servidor antes do redirecionamento do usuário, o que elimina a exposição de parâmetros sensíveis na URL.

3. Ciclo de vida do consentimento: implementar uma consent API dedicada com operações de criação, consulta, atualização e revogação. Refresh tokens vinculados a consentimentos deletados devem ser revogados imediatamente. A revogação precisa ser propagada em tempo real para todos os resource servers.

4. Rate limiting por cliente e por endpoint: aplicar limites distintos para endpoints de leitura, como saldo, e de escrita, como iniciação de pagamento. Usar algoritmos de sliding window ou token bucket permite tolerar bursts legítimos sem comprometer a disponibilidade.

5. WAF (Web Application Firewall): configurar regras específicas para bloquear BOLA, SSRF e injeção de parâmetros. BOLA é um dos principais riscos em ataques a APIs de serviços financeiros.

6. Logs imutáveis com hash encadeado: registrar cada evento com identidade do ator, timestamp, IP, payload de negócio e decisão de política. Armazenar um checksum SHA-256 de cada evento concatenado com o checksum do evento anterior garante rastreabilidade e detecção de adulteração.

7. Monitoramento contínuo com SIEM: integrar os logs ao SIEM e configurar alertas para anomalias como volume anormal de refresh tokens, padrões geográficos incomuns e picos de requisições fora do perfil histórico do cliente.

Implemente essa arquitetura com a infraestrutura completa da Celcoin para fintechs, bancos digitais, gestoras de fundos, varejistas e ERPs.

Como implementar consentimento granular no Open Finance

O controle de acesso baseado em consentimento granular depende de escopos bem definidos e de uma jornada clara para o usuário.

O perfil FAPI-BR exige o uso de escopos parametrizados no formato consent:{Consent Resource Id} para vincular cada acesso a um consentimento específico. Cada escopo deve corresponder a uma categoria de dados, como accounts, credit-cards-accounts ou investments, e o usuário precisa autorizar cada categoria de forma independente.

A implementação deve incluir:

• Interface de consentimento alinhada ao Guia UX do Banco Central, com linguagem clara sobre quais dados serão compartilhados, por quanto tempo e para qual finalidade declarada.

• Mecanismo de revogação em tempo real, em que a revogação de um consentimento invalida todos os tokens associados em todos os resource servers.

• Comunicação transparente com o cliente sobre o status de cada solicitação, com garantia de que o usuário pode retirar o consentimento a qualquer momento.

• Respeito ao prazo máximo de validade já mencionado, com renovação explícita pelo usuário ao término.

• Consentimento sob as regras do Banco Central deve ser explícito, granular por categoria de dados, limitado a 12 meses, revogável em tempo real e vinculado a uma finalidade declarada.

Quais os riscos de APIs sem mTLS

A ausência de autenticação mútua aumenta a superfície de ataque e facilita man-in-the-middle, impersonação de clientes e replay attacks. Sem mTLS, um atacante pode interceptar tokens OAuth válidos e reutilizá-los em conexões não autenticadas, o que contorna o fluxo de autorização.

Falhas de autenticação em APIs de Open Banking geralmente decorrem de implementações fracas de OAuth, uso de tokens de longa duração e ausência de autenticação multifator. As mitigações diretas incluem:

• Exigir certificados BRCAC válidos em todas as conexões de entrada no API Gateway.

• Validar a cadeia de certificados e o status de revogação via OCSP em cada requisição.

• Configurar os cipher suites obrigatórios. Endpoints de authorization server e resource server devem suportar TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 e TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, com TLS Session Resumption e TLS Renegotiation desabilitados.

• Implementar sender-constrained tokens para vincular cada token ao certificado do cliente que o solicitou.

Rate limiting e proteção de endpoints no Open Finance

O rate limiting protege sistemas de Core Banking, motores de pagamento e bancos de dados legados, não apenas as APIs expostas. Os limites precisam refletir a capacidade real dos sistemas, e não thresholds arbitrários.

Boas práticas para rate limiting em Open Finance:

• Aplicar limites por cliente, por endpoint e por credencial de aplicação, com políticas distintas para endpoints de leitura e de iniciação de pagamento. Essa granularidade permite proteger recursos críticos sem penalizar operações de baixo risco.

• Para implementar esses limites de forma confiável, usar o algoritmo token bucket como padrão, que tolera bursts enquanto mantém uma taxa média. Em sistemas distribuídos, implementar com Redis e scripts Lua atômicos para manter consistência entre instâncias.

• Quando os limites forem excedidos, retornar HTTP 429 com os headers Retry-After, X-RateLimit-Remaining e X-RateLimit-Limit, o que permite que clientes ajustem o ritmo automaticamente.

• Além do rate limiting no gateway, combinar a estratégia com circuit breakers downstream para evitar que um único cliente mal configurado esgote a capacidade compartilhada.

• Por fim, monitorar continuamente a taxa de violações. Se usuários legítimos forem bloqueados com frequência, os limites configurados estão muito restritivos e precisam de ajuste.

Logs imutáveis e monitoramento contínuo

Logs de auditoria imutáveis funcionam como evidência de controles de segurança e sustentam a conformidade regulatória. Cada evento deve registrar identidade do ator, ação executada, timestamp sincronizado, IP de origem, recurso alvo, resultado e ID único do evento.

Uma estratégia de retenção em camadas pode usar hot storage de 0 a 90 dias para acesso completo, warm storage de 90 dias a 2 anos em stores otimizados para leitura e cold storage acima de 2 anos em formatos como Parquet ou JSON Lines. Essa abordagem atende a requisitos típicos de retenção de 5 a 7 anos em reguladores financeiros.

Para monitoramento contínuo:

• Centralizar a ingestão de logs de sistemas, aplicações e serviços de nuvem em uma única plataforma SIEM.

• Empregar detecção de anomalias baseada em machine learning para identificar desvios como tentativas excessivas de refresh de token, padrões geográficos incomuns e volumes anormais de requisições.

• Aplicar controle de acesso baseado em função aos dados de log, restringindo o acesso apenas a perfis autorizados.

• Configurar alertas proativos quando requisições por segundo excederem thresholds definidos, antes de qualquer impacto na disponibilidade.

Mesmo com essas práticas, implementações reais ainda podem enfrentar falhas previsíveis. Antecipar esses erros reduz o risco de problemas na homologação e de exposição regulatória.

Erros comuns e riscos operacionais/regulatórios

Alguns padrões de erro se repetem em projetos de Open Finance no Brasil e afetam tanto a segurança quanto a operação diária.

• Escopos OAuth excessivos: solicitação de escopos como customers-details sem justificativa clara pode resultar em negação de homologação por participantes bancários. A prática recomendada é solicitar apenas os escopos estritamente necessários para a finalidade declarada.

• Tokens de longa duração: ignorar a exigência de tokens de curta duração, com máximo de 900 segundos conforme o perfil FAPI-BR, amplia a janela de exploração em caso de comprometimento.

• Ausência de PAR: não implementar pushed authorization requests expõe parâmetros de autorização na URL e viola requisito obrigatório do Open Finance Brasil.

• UX de consentimento inadequada: reclamações no Open Finance brasileiro mostram que alguns clientes se sentiram pressionados a compartilhar dados sem necessidade clara. Fluxos confusos aumentam abandono e risco regulatório.

• Reutilização de dados para marketing sem consentimento: uso de dados transacionais de clientes para ofertas de produtos sem consentimento explícito pode gerar multas em inspeções do Banco Central.

• Ausência de middleware de normalização: dependência de estruturas de resposta específicas de cada banco aumenta falhas quando participantes alteram campos nas respostas de API.

• Dados desatualizados: 21% das reclamações sobre o Open Finance que os bancos participantes recebem tratam de dados desatualizados, o que indica problemas em pipelines de sincronização e cache.

Cenários de uso por tipo de empresa

O tipo de empresa define prioridades de segurança, foco regulatório e estratégia de implementação.

• Fintechs em estágio inicial: o principal risco é a homologação. A prioridade deve ser implementar corretamente mTLS, PAR e PKCE antes de funcionalidades avançadas de produto. O uso de sandboxes certificados ajuda a validar o fluxo completo de consentimento antes do envio ao processo de homologação do Open Finance Brasil.

• Bancos digitais em escala: o desafio é manter conformidade contínua com atualizações regulatórias, como a Resolução BCB nº 526/2025, que expandiu modalidades de crédito cobertas pela portabilidade via Open Finance, sem interromper operações. Testes de conformidade automatizados e feature flags para rollout controlado de novas versões de API reduzem risco.

• ERPs que adicionam serviços financeiros: a integração com múltiplos participantes do Open Finance exige um middleware robusto de normalização de dados. Implementar lógica de fallback evita que decisões de negócio fiquem bloqueadas por indisponibilidade temporária de participantes específicos.

• Varejistas que modernizam ofertas financeiras: o foco deve estar na UX de consentimento e na proteção de dados dos clientes finais. Fluxos de autorização claros e transparentes aumentam a taxa de conversão e reduzem o risco regulatório sob a LGPD.

Infraestrutura da Celcoin para Open Finance seguro

A Celcoin oferece infraestrutura modular de Open Finance para empresas reguladas e não reguladas, com APIs documentadas compatíveis com padrões REST e com o perfil FAPI-BR. A solução inclui widget de jornada de consentimento alinhado ao Guia UX do Banco Central, relatórios regulatórios automatizados, integração direta com a Rede do Sistema Financeiro Nacional, além de suporte a KYC, AML e compliance contínuo. Fintechs, bancos digitais, ERPs e varejistas podem operar sob as licenças da Celcoin no modelo Banking as a Service ou integrar suas próprias licenças ao Core Banking da Celcoin, mantendo a mesma base tecnológica em todas as etapas de crescimento.

A Celcoin não oferece empréstimo para consumidores. A Celcoin fornece a infraestrutura tecnológica para que empresas ofertem produtos de crédito aos seus clientes.

A infraestrutura da Celcoin reúne funcionalidades que reduzem tempo de implementação e risco regulatório:

• APIs modulares: permitem integrações mais rápidas e reduzem custos e prazos de desenvolvimento.

• Experiência e suporte ao desenvolvedor: documentação, SDKs e sandboxes encurtam ciclos de integração e diminuem esforço de engenharia.

• Capacidade de lançamento rápido: módulos pré-construídos e entrega via SaaS aceleram lançamentos e antecipam geração de receita.

• Distribuição white-label e embutida: possibilita ofertar produtos financeiros com marca própria.

• Escalabilidade com confiabilidade: solução em nuvem com alta disponibilidade mantém serviços estáveis mesmo em picos de volume.

• Cobertura de pagamentos e crédito: oferta de pagamentos e emissão de crédito aumenta conversão, ARPU e fidelização.

• Acesso a dados e personalização: dados e análises via Open Finance permitem ofertas personalizadas e melhoram conversão e retenção.

• Compliance e conformidade: KYC, AML e relatórios integrados reduzem risco regulatório e encurtam ciclos de vendas.

• Prevenção de fraude e controles de risco: monitoramento baseado em IA e autenticação robusta reduzem estornos, perdas e exposição regulatória.

• Ecossistema de parceiros: parcerias com bancos, redes e fintechs ampliam cobertura, recursos e velocidade de entrada no mercado.

Explore como a Celcoin acelera sua entrada no Open Finance com APIs prontas, Core Banking integrado e conformidade embarcada.

Perguntas frequentes

O que é necessário para homologar APIs de Open Finance no Banco Central?

A homologação exige conformidade com o perfil FAPI-BR, no padrão FAPI-1-Advanced com extensões brasileiras, implementação de mTLS com certificados BRCAC, OAuth 2.0 com PKCE e PAR, escopos parametrizados por consentimento, access tokens com validade entre 300 e 900 segundos e registro no Diretório de Participantes do Open Finance Brasil. Instituições transmissoras de dados devem configurar restrições de recursos no Diretório no momento da publicação em produção, usando a flag de homologação no authorization server para novas marcas ou o metadado correspondente para novos produtos. O processo inclui testes em ambiente controlado com usuários habilitados antes da abertura ao público geral.

Como a LGPD se aplica às APIs de Open Finance?

A LGPD exige que cada categoria de dado compartilhada via Open Finance tenha uma base legal explícita. No contexto do Open Finance, essa base é o consentimento do titular. As políticas de privacidade e os termos de uso devem declarar quais dados são processados, para qual finalidade e por quanto tempo. O uso de dados transacionais para finalidades não declaradas no momento do consentimento, como ofertas de marketing, configura violação da LGPD e das normas do Banco Central. O titular tem direito à revogação imediata do consentimento, e a instituição deve garantir que essa revogação se propague para todos os sistemas que processam os dados em questão.

Com que frequência pentests devem ser realizados em APIs de Open Finance?

Não existe uma frequência mínima definida pelo regulador, mas a prática de mercado recomenda testes de penetração pelo menos uma vez por ano ou sempre que houver alterações relevantes na arquitetura ou na exposição de endpoints. Os testes devem cobrir fluxos de consentimento, autenticação mútua, validação de tokens e proteção contra ataques como BOLA, SSRF e injeção de parâmetros.