Segurança de dados em APIs de Open Finance: 7 controles

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

Principais lições deste artigo

• Garantir segurança em APIs de Open Finance exige autenticação forte via FAPI e mTLS, além de criptografia TLS 1.3 e gerenciamento estruturado de chaves.

• Implementar gestão explícita de consentimento e revogação síncrona em menos de 500 ms é obrigatório para manter conformidade com o Bacen e com a LGPD.

• Aplicar controles contra BOLA/IDOR, rate limiting por client_id e logging imutável reduz riscos de vazamento de dados e facilita auditorias regulatórias.

• Integrar DevSecOps com testes automatizados SAST e DAST ajuda a absorver novas versões das especificações FAPI sem comprometer a segurança.

• Com a plataforma da Celcoin é possível implementar todos esses controles em uma única solução. Conheça a infraestrutura completa de Open Finance.

Introdução

APIs de Open Finance no Brasil movimentam dados financeiros sensíveis de milhões de usuários. Essas integrações exigem controles de segurança específicos, alinhados às normas do Bacen, da LGPD e às vulnerabilidades do OWASP API Top 10. Este guia apresenta sete controles essenciais que ajudam instituições participantes e empresas que operam via BaaS a manter segurança, conformidade regulatória e operação estável em produção.

Os sete controles essenciais de segurança para APIs de Open Finance

1. Autenticação forte com FAPI e mTLS

2. Gestão explícita de consentimento e revogação

3. Criptografia em trânsito e em repouso com TLS 1.3 e gerenciamento de chaves

4. Mitigação de BOLA/IDOR e OWASP API Top 10

5. Rate limiting, detecção de anomalias e throttling

6. Logging contínuo, auditoria e geração automática de relatórios regulatórios (CCS, CADOC)

7. Integração DevSecOps e testes automatizados

Visão geral e pré-requisitos regulatórios

O Banco Central do Brasil (Bacen) estabelece que todas as instituições participantes do Open Finance devem aderir ao perfil Financial-grade API (FAPI) 1.0 Advanced, utilizando OAuth 2.0 com PKCE, mTLS para autenticação de cliente e assinatura de mensagens com JWS. Esses requisitos se aplicam a Instituições de Pagamento e a Instituições Financeiras conectadas ao SPB. A LGPD adiciona obrigações de proteção de dados pessoais, enquanto a SUSEP define requisitos equivalentes para o Open Insurance. Antes de iniciar a implementação, a instituição deve registrar certificados no Diretório de Participantes do Open Finance Brasil e configurar o ambiente de produção para replicar as validações do sandbox regulatório.

Passo 1 – Autenticação forte com FAPI e mTLS

Para atender ao perfil FAPI exigido pelo Bacen, o servidor de autorização deve validar o certificado de transporte do cliente, via mTLS, em cada requisição e vincular o token de acesso ao certificado com certificate-bound access tokens (RFC 8705. O fluxo de autorização deve usar pushed authorization requests (PAR) para reduzir o risco de manipulação de parâmetros no front-channel. A aplicação deve configurar tokens de acesso com vida útil curta e implementar rotação de refresh tokens para limitar o impacto de comprometimento. Qualquer desvio desses parâmetros pode comprometer a segurança e a conformidade regulatória.

Passo 2 – Gestão explícita de consentimento e revogação

O consentimento no Open Finance brasileiro é granular, o usuário autoriza escopos específicos, como dados cadastrais, transações e investimentos, com prazo determinado. Para gerenciar esse ciclo de vida, a API de consentimento deve expor endpoints para criação, consulta e revogação, garantindo que mudanças de estado se propaguem imediatamente para todos os recursos protegidos. A revogação deve ser síncrona, ao receber DELETE /consents/{consentId}, o servidor invalida o token vinculado em menos de 500 ms, porque qualquer atraso mantém dados acessíveis após o usuário retirar a permissão. Logs de ciclo de vida do consentimento são obrigatórios para auditorias do Bacen e para demonstrar conformidade com a LGPD, que exige rastreabilidade completa do tratamento de dados pessoais.

Passo 3 – Criptografia em trânsito e em repouso com TLS 1.3 e gerenciamento de chaves

O uso de TLS 1.3 fortalece a proteção de dados em trânsito entre participantes do Open Finance. A equipe deve desabilitar versões anteriores de TLS nos balanceadores de carga e nos gateways de API para evitar protocolos obsoletos. Em repouso, a aplicação deve cifrar dados sensíveis, como números de conta, CPF e histórico transacional, com algoritmos robustos e chaves gerenciadas de forma centralizada. O gerenciamento de chaves deve seguir rotação periódica e armazenamento em HSM ou serviço equivalente de KMS em nuvem. A renovação antecipada de certificados do Diretório de Participantes evita interrupções de serviço e incidentes de indisponibilidade.

Passo 4 – Mitigação de BOLA/IDOR e OWASP API Top 10

Broken Object Level Authorization, também conhecido como IDOR, é uma das vulnerabilidades mais críticas do OWASP API Top 10 em ambientes de Open Finance. Essa falha ocorre quando a API retorna dados de um recurso sem verificar se o token de acesso apresentado pertence ao titular daquele recurso. A mitigação exige validação explícita do sub do token contra o identificador do recurso solicitado em cada endpoint. Além do BOLA, os controles devem cobrir injeção em parâmetros de query, exposição excessiva de dados em respostas, retornando apenas os campos autorizados pelo escopo do consentimento, e ausência de limites de consumo. Testes de autorização devem rodar no pipeline de CI/CD com ferramentas de DAST específicas para APIs REST, cobrindo cenários de acesso indevido.

Passo 5 – Rate limiting, detecção de anomalias e throttling

O Bacen define limites de requisição por participante no Diretório de Open Finance, o que torna o controle de volume obrigatório. O gateway de API deve implementar rate limiting por client_id e por IP de origem, com respostas HTTP 429 e cabeçalho Retry-After para orientar o cliente. Para evitar que esse limite rígido bloqueie clientes legítimos que ultrapassam brevemente a cota, o throttling adaptativo reduz gradualmente a taxa permitida antes de bloquear completamente, preservando a disponibilidade. Além desses controles baseados em volume, a detecção de anomalias monitora padrões comportamentais, como picos de requisições fora do horário comercial, sequências de IDs incrementais que indicam enumeração de recursos e falhas repetidas de autenticação, identificando ataques mesmo quando o volume está dentro dos limites. Alertas de alta severidade devem acionar resposta automática em menos de 60 segundos.

Passo 6 – Logging contínuo, auditoria e geração automática de relatórios regulatórios (CCS, CADOC)

Cada transação de API no Open Finance deve gerar um registro imutável com timestamp em UTC, consentId, client_id, endpoint acessado, código de resposta HTTP e latência. Esses logs alimentam fluxos regulatórios obrigatórios, como CCS e CADOCs, enviados ao Bacen via RSFN, o que torna a automação desses relatórios uma forma de reduzir erros manuais e atrasos. A instituição deve reter logs de auditoria por um período compatível com os requisitos regulatórios e protegê-los contra alteração com assinatura criptográfica. Essa integridade garante que os registros possam servir como evidência em auditorias e em eventuais investigações de incidentes.

Passo 7 – Integração DevSecOps e testes automatizados

Segurança em APIs de Open Finance não é um estado estático, novas versões das especificações FAPI e atualizações do Diretório de Participantes exigem ciclos contínuos de validação. O pipeline DevSecOps deve incluir análise estática de código, SAST, com regras específicas para OAuth 2.0, testes de contrato contra o schema OpenAPI publicado pelo Bacen, testes de penetração automatizados, DAST, em ambiente de staging e validação de certificados mTLS antes de cada deploy em produção. Uma boa cobertura dos endpoints críticos em testes automatizados de segurança, com relatórios de cobertura disponíveis para auditorias internas e externas, reduz o risco de regressões. Implementar e manter esses sete controles de forma independente exige equipes especializadas em segurança, compliance e infraestrutura, além de processos contínuos de atualização regulatória, o que pode desviar recursos do core business da instituição.

Como a Celcoin entrega esses controles em uma única plataforma

A Celcoin opera com infraestrutura de Open Finance nativa em API, conectada diretamente ao SPB e ao Diretório de Participantes do Bacen. A plataforma entrega os sete controles descritos acima como módulos integrados, o que elimina a necessidade de múltiplos fornecedores para autenticação, criptografia, consentimento, logging e relatórios regulatórios. Fintechs, bancos digitais, ERPs e varejistas podem operar sob a licença da Celcoin, no modelo BaaS, ou integrar sua própria licença ao Core Banking, mantendo a mesma base de segurança e compliance em todas as etapas da jornada.

A tabela a seguir mostra como cada funcionalidade da plataforma se traduz em benefícios operacionais e financeiros para sua empresa.

Funcionalidade da Celcoin	Benefício para sua empresa
APIs modulares	Integrações mais rápidas, com redução de custos e prazos de desenvolvimento.
Experiência e suporte ao desenvolvedor	Documentação, SDKs e sandboxes reduzem ciclos de integração e custos de engenharia.
Capacidade de lançamento rápido	Módulos pré-construídos e entrega via SaaS aceleram lançamentos, melhorando o tempo para geração de receita e a competitividade.
Distribuição white-label e embutida, embedded	Suporte a produtos financeiros com marca própria, mantendo a experiência sob o seu branding.
Escalabilidade com confiabilidade	Ter uma solução com alta disponibilidade e escalável na nuvem mantém serviços funcionando mesmo com altos volumes, protegendo sua receita.
Cobertura de diversas possibilidades de pagamentos, incluindo crédito	Oferecer 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, o que melhora conversão e retenção.
Compliance e conformidade como princípio	KYC, AML e relatórios integrados reduzem risco regulatório e aceleram 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.
Força do ecossistema de parceiros da Celcoin	Parcerias e integrações com bancos, redes e fintechs ampliam cobertura, recursos e velocidade de entrada no mercado.

Veja como a Celcoin integra autenticação, criptografia, consentimento e logging em uma única plataforma.

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

Erros comuns e pontos de atenção

Os erros mais frequentes na implementação de segurança em APIs de Open Finance envolvem dependências entre times e lacunas de processo, não apenas falhas técnicas. Muitos desses erros surgem quando a responsabilidade por um controle se fragmenta entre equipes sem coordenação clara.

• Validação de consentimento apenas no gateway: o gateway de API valida o token, mas os microsserviços internos não verificam se o escopo do consentimento cobre o recurso solicitado. Isso cria uma superfície de ataque BOLA interna e costuma ocorrer quando times de infraestrutura e de produto não alinham responsabilidades de autorização.

• Certificados mTLS não monitorados: certificados do Diretório de Participantes vencem sem alerta automatizado, o que causa interrupção de serviço e notificação compulsória ao Bacen. Esse problema aparece quando o time de segurança emite certificados, mas o time de operações não implementa monitoramento de expiração.

• Logs sem integridade criptográfica: logs armazenados sem assinatura podem ser contestados em auditorias, o que reduz a confiança do regulador e dificulta a comprovação de que a instituição tratou dados pessoais de forma adequada.

• Rate limiting aplicado apenas por IP: atacantes que distribuem requisições por múltiplos IPs contornam o controle. O limite deve ser aplicado por client_id e por consentId para refletir o consumo real por cliente e por consentimento.

• Ausência de testes de revogação em staging: o fluxo de revogação de consentimento raramente é testado em carga, o que resulta em propagação lenta que viola o SLA de revogação descrito anteriormente.

• Times de produto e compliance desalinhados: mudanças de escopo de produto que alteram os dados acessados pela API não passam por revisão de compliance, criando exposição regulatória não mapeada e riscos de sanções.

Critérios de sucesso e validação

A instituição pode medir a conformidade com os controles de segurança do Open Finance com métricas objetivas e fáceis de acompanhar.

• Latência de autenticação: tempo de resposta do endpoint de token inferior a 300 ms no percentil 95.

• Taxa de erro de autorização: menos de 0,1% de requisições com erro 401 ou 403 em operação normal, excluindo testes de penetração.

• Cobertura de logs: 100% dos endpoints de dados cobertos por logging de auditoria, com retenção verificada mensalmente.

• Tempo de revogação de consentimento: propagação completa em menos de 500 ms, medida em testes de carga com 1.000 requisições simultâneas.

• Aderência regulatória: zero atrasos no envio de CCS e CADOCs ao Bacen nos últimos 12 meses, com relatório de auditoria disponível para inspeção.

• Cobertura de testes automatizados: alta cobertura dos endpoints críticos por testes DAST em cada ciclo de release.

Próximos passos

Após a implementação dos sete controles, a próxima etapa é evoluir a operação de forma estruturada. Essa evolução costuma seguir três frentes principais, que podem avançar em paralelo conforme a maturidade da instituição.

A primeira frente é a expansão da operação para novos escopos do Open Finance, como dados de investimentos, seguros via SUSEP e Open Insurance, sempre reaproveitando a base de segurança já construída. A segunda frente é a automação de governança com dashboards em tempo real que consolidam métricas de segurança, consentimento e relatórios regulatórios, o que facilita decisões de risco e priorização de melhorias. A terceira frente é o monitoramento contínuo da evolução das especificações FAPI e das resoluções do Bacen, que passam por atualizações periódicas, exigindo ajustes em endpoints, testes e relatórios.

Instituições que operam com infraestrutura modular conseguem absorver essas mudanças sem reconstruir a base tecnológica, o que reduz custo de manutenção e tempo de adequação a novas regras. Saiba como a infraestrutura modular da Celcoin absorve mudanças regulatórias sem reconstrução.

FAQ

Quais são os prazos regulatórios para adequação aos requisitos de segurança do Open Finance no Brasil?

O Banco Central define cronogramas de adesão por fase e por tipo de instituição participante. Instituições de Pagamento e Instituições Financeiras já autorizadas devem manter conformidade contínua com as especificações técnicas do Diretório de Participantes, incluindo FAPI 1.0 Advanced e mTLS. Novas participantes recebem prazos específicos no ato de autorização pelo Bacen. A renovação de certificados do Diretório ocorre anualmente e deve ser monitorada com antecedência mínima de 30 dias para evitar interrupção de serviço e obrigação de notificação regulatória.

Quais requisitos técnicos mínimos uma empresa precisa ter antes de integrar APIs de Open Finance?

A empresa deve possuir ou operar sob uma licença de Instituição de Pagamento ou Instituição Financeira autorizada pelo Bacen, ou utilizar a infraestrutura de uma instituição licenciada no modelo BaaS. Do ponto de vista técnico, a empresa precisa de ambiente com suporte a TLS 1.3, capacidade de gerenciar certificados mTLS emitidos pelo Diretório de Participantes, servidor de autorização compatível com OAuth 2.0 e PKCE e infraestrutura de logging com retenção de cinco anos. Empresas que não possuem licença própria podem operar sob a infraestrutura regulatória de um parceiro licenciado, como a Celcoin, que fornece a base tecnológica e regulatória necessária.

Quais são os custos operacionais recorrentes de manter a segurança de APIs de Open Finance em conformidade?

Os custos recorrentes incluem renovação anual de certificados do Diretório de Participantes, manutenção de HSM ou KMS em nuvem para gerenciamento de chaves, operação de ferramentas de SAST e DAST no pipeline DevSecOps e armazenamento de logs de auditoria por cinco anos. Empresas que utilizam infraestrutura modular de um parceiro especializado diluem esses custos, pois a manutenção de certificados, as atualizações de especificações FAPI e a geração automática de relatórios regulatórios, como CCS e CADOC, são gerenciadas de forma centralizada, sem necessidade de equipes dedicadas a cada componente.

Como funciona a manutenção contínua dos controles de segurança diante de atualizações regulatórias do Bacen?

O Bacen publica atualizações das especificações técnicas do Open Finance periodicamente, incluindo novas versões do perfil FAPI, mudanças nos escopos de consentimento e requisitos adicionais de logging. A manutenção contínua exige um processo estruturado de monitoramento dessas publicações, avaliação de impacto nos endpoints existentes, atualização dos testes automatizados e validação em ambiente de staging antes de cada deploy em produção. Plataformas que entregam infraestrutura de Open Finance como serviço gerenciam essas atualizações de forma centralizada, o que reduz o esforço interno das instituições participantes e ajuda a manter a conformidade sem interromper a operação.

Empresas não reguladas podem implementar APIs de Open Finance com segurança?

Empresas sem licença própria podem acessar o ecossistema de Open Finance operando sob a infraestrutura de uma instituição licenciada pelo Bacen no modelo BaaS. Nesse modelo, a instituição licenciada é responsável pela conformidade regulatória, incluindo controles de segurança FAPI, mTLS, logging e relatórios obrigatórios. A empresa não regulada integra as APIs do parceiro licenciado e entrega a experiência ao usuário final, enquanto a complexidade de compliance, KYC e reportes ao Bacen permanece sob responsabilidade do parceiro. Essa abordagem permite que fintechs, ERPs e varejistas acessem dados financeiros com consentimento e ofereçam produtos personalizados sem obter licença própria ou construir infraestrutura de segurança do zero.

Veja como operar Open Finance sob a licença da Celcoin no modelo BaaS.