Última atualização: 17 de julho de 2026
Principais lições deste artigo
-
Evitar construir uma infraestrutura bancária própria dentro do ERP reduz riscos regulatórios e permite concluir a integração em semanas, não em meses.
-
Adotar uma arquitetura de microsserviços com ledger separado, sharding por tenant e filas assíncronas garante escalabilidade sem impacto no sistema principal.
-
Delegar compliance, KYC, PLD/FT e relatórios regulatórios a um parceiro de Banking as a Service licenciado é obrigatório e simplifica a operação do ERP.
-
Implementar webhooks com deduplicação, chaves de idempotência e SLOs de latência previne falhas em alto volume e garante integridade contábil.
-
Usar o banking da Celcoin permite que ERPs ofereçam contas digitais, Pix e cartões de forma escalável e em conformidade com a Resolução Conjunta nº 16/2025. Conheça a solução.
Pré-requisitos e times envolvidos
Três condições precisam estar claras antes da implementação. O time de engenharia deve ter capacidade de consumir APIs REST com autenticação OAuth 2.0 e processar eventos via webhooks. O time de produto precisa definir quais serviços financeiros o ERP vai oferecer e em qual sequência. O time de compliance deve compreender que, sob a Resolução Conjunta nº 16/2025, o ERP atua como tomador de serviços, não pode usar termos como “banco” em suas comunicações e não pode cobrar tarifas próprias sobre os serviços do provedor licenciado.
Os papéis centrais são claros. A engenharia de backend cuida da integração de API gateway e filas. O arquiteto de dados define a separação do ledger e o sharding. O time de produto desenha as jornadas financeiras. O time de compliance valida KYC, PLD/FT e relatórios regulatórios. A delegação do compliance ao parceiro de Banking as a Service é estrutural, não opcional.
Passo a passo: arquitetura técnica para escalabilidade
1. Definição da arquitetura de microsserviços e API gateway
Uma estrutura de microsserviços com bounded contexts separa responsabilidades como autorização, liquidação, conciliação, risco e gestão de clientes, com cada serviço expondo APIs bem definidas para escalabilidade independente. No contexto de um ERP, essa abordagem isola o módulo financeiro embarcado em um serviço dedicado, sem acoplamento direto aos módulos de estoque, fiscal ou contábil.
O API gateway atua como controlador central de tráfego. Esse componente aplica autenticação, rate limiting e roteamento antes que as requisições alcancem os serviços internos. Essa camada distribui requisições e reduz gargalos em sistemas de pagamento de alto volume.
2. Como separar o ledger financeiro do ERP
O ledger financeiro precisa ser um journal de dupla entrada, append-only, em que cada lançamento referencia seu evento de origem. Entradas históricas não são editadas, e correções são registradas como novos journals de estorno com razão e autorização explícitos. Esse ledger deve ficar em um banco de dados separado do ERP principal, com acesso controlado exclusivamente pelo microsserviço financeiro.
3. Implementação de filas assíncronas e webhooks para picos de volume
Webhooks são preferíveis ao polling para conciliação. A latência do polling no Open Finance se torna um gargalo operacional acima de 5.000 transações mensais, o que força o uso de webhooks robustos ou APIs privadas para evitar crescimento não linear no esforço de conciliação manual. Handlers de webhook devem implementar deduplicação por ID de evento para evitar lançamentos contábeis duplicados quando o banco retransmite o mesmo evento.
4. Estratégia de sharding e read/write separation no banco de dados
Para ERPs com múltiplos CNPJs clientes, o sharding por cliente, ou tenant, costuma ser a estratégia mais eficiente. Cada tenant possui seu próprio shard de dados financeiros, o que isola falhas e permite escalar partições individualmente conforme o volume cresce. A separação de réplicas de leitura e escrita reduz a contenção em consultas de saldo e extrato, sem prejudicar o throughput de novas transações.
5. Garantia de idempotência e observabilidade
Service-level objectives e budgets de latência para fluxos críticos, como autorização, captura e liquidação, combinados com rastreamento end-to-end, permitem detectar problemas de performance antes que os clientes sejam afetados. Logs imutáveis de eventos funcionam como fonte de verdade para auditorias e relatórios regulatórios.
6. Delegação de compliance, KYC, relatórios regulatórios e liquidação para o parceiro BaaS
A Resolução Conjunta nº 16/2025 centraliza a responsabilidade de compliance, incluindo PLD, financiamento ao terrorismo e KYC, na instituição provedora de Banking as a Service, enquanto o ERP tomador atua dentro das políticas e limites definidos em contrato.
Na prática, o ERP não precisa construir fluxos de KYC, gerar CADOCs, CCS, DIMP ou conectar-se diretamente à RSFN. Toda essa camada fica sob gestão do parceiro licenciado. Desde agosto de 2025, fintechs e instituições de pagamento devem apresentar a e-Financeira nas mesmas condições aplicáveis às instituições financeiras integrantes do SFN e SPB, o que reforça que essas obrigações recaem sobre o provedor de Banking as a Service, não sobre o ERP integrador.
7. Checklist final de validação
-
API gateway configurado com rate limiting e autenticação OAuth 2.0.
-
Ledger financeiro em banco de dados separado do ERP principal, com double-entry e append-only.
-
Filas assíncronas implementadas para absorver picos de volume sem perda de mensagens.
-
Webhooks com deduplicação por ID de evento substituindo polling para conciliação.
-
Sharding por tenant configurado com separação de réplicas de leitura e escrita.
-
Chaves de idempotência geradas antes de cada requisição ao parceiro de Banking as a Service.
-
SLOs definidos e rastreamento end-to-end ativo nos fluxos críticos.
-
Contrato com parceiro de Banking as a Service licenciado cobrindo KYC, PLD/FT, relatórios regulatórios e liquidação.
-
Conformidade com a Resolução Conjunta nº 16/2025 documentada, com prazo até 31 de dezembro de 2026.
Celcoin: infraestrutura BaaS para ERPs
A Celcoin opera com um portfólio completo de licenças e tecnologia proprietária. O banking da Celcoin oferece APIs modulares para que ERPs possam prover serviços bancários completos, de contas digitais e cartões até liquidação, compliance e relatórios regulatórios, sem construir uma infraestrutura bancária própria. A plataforma medeia mais de R$ 30 bilhões em transações mensalmente e atende mais de 6 mil clientes, incluindo ERPs como o PipeImob.
A tabela abaixo resume como cada funcionalidade do banking da Celcoin se converte em benefícios práticos para ERPs que desejam escalar serviços financeiros embarcados com segurança e previsibilidade:
|
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 que reduzem ciclos de integração e esforço 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. |
|
Distribuição white-label e embutida (embedded) |
Suporte a produtos financeiros com marca própria do ERP. |
|
Escalabilidade com confiabilidade |
Solução com alta disponibilidade e escalável na nuvem mantém serviços estáveis mesmo em altos volumes, protegendo a receita. |
|
Cobertura de diversas possibilidades de pagamentos, incluindo 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, com impacto direto em conversão e retenção. |
|
Compliance e conformidade como princípio |
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. |
|
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. |
Erros comuns e pontos de atenção
Operações digitais de alto volume sem sistemas financeiros adequados frequentemente enfrentam gargalos como conciliação bancária atrasada, erros de precificação, falhas no controle fiscal, processos manuais inconsistentes e atrasos no fechamento de contas.
Os erros mais recorrentes em integrações de contas digitais em ERPs violam diretamente os princípios arquiteturais descritos acima e comprometem tanto a escalabilidade quanto a conformidade regulatória:
-
Acoplamento do ledger ao banco de dados principal do ERP: qualquer instabilidade no módulo financeiro impacta diretamente módulos de estoque, fiscal e contábil, criando risco sistêmico.
-
Uso de polling em vez de webhooks para conciliação: esse modelo gera crescimento não linear no esforço manual e latência incompatível com operações acima de 5.000 transações mensais.
-
Handlers de webhook sem deduplicação: retransmissões do banco criam lançamentos duplicados no ledger, exigindo estornos manuais e comprometendo a integridade contábil.
-
Ausência de chaves de idempotência: timeouts de rede resultam em cobranças duplicadas ou pagamentos processados duas vezes.
-
Operar com contas-bolsão: a Resolução Conjunta nº 16/2025 proíbe contas-bolsão e exige que os fluxos financeiros se movam diretamente do cliente final para o provedor de Banking as a Service licenciado, sem parada intermediária na conta do ERP.
-
Subestimar a complexidade regulatória: projetos de integração própria frequentemente falham quando as equipes subestimam os requisitos de certificados ICP-Brasil e a complexidade dos fluxos de consentimento e revogação, o que resulta em meses de esforço descartado.
Critérios de sucesso e indicadores
Uma integração escalável de contas digitais em ERP deve ser avaliada por indicadores objetivos. No plano de performance, o tempo de resposta das APIs para Pix e consultas de saldo precisa permanecer abaixo de 200 ms em condições normais, com SLOs documentados para picos. A taxa de falha em transações deve ficar abaixo de 0,1%, e o tempo de recuperação após incidentes precisa respeitar o SLA contratado com o parceiro de Banking as a Service.
No plano de compliance, zero divergências em relatórios regulatórios automatizados, como CADOCs, CCS e DIMP, e ausência de notificações do Banco Central são os principais sinais de sucesso. A taxa de aprovação em KYC e a cobertura de mapeamento de beneficiários finais, ou UBO, completam o quadro regulatório.
No plano de negócio, a redução do esforço manual de conciliação, o aumento da retenção de clientes do ERP que utilizam serviços financeiros embarcados e a geração de uma nova linha de receita sobre a base existente são os indicadores de valor mais relevantes para o Head de Produto.
Próximos passos
Após a estabilização da arquitetura inicial, três frentes de evolução ganham prioridade. A primeira é a expansão para Open Finance Fase 3, que adiciona endpoints de iniciação de pagamento, incluindo Pix, TED e boletos selecionados via TPP, permitindo que o ERP leia extratos e inicie pagamentos usando infraestrutura pública, sem contrato bilateral com cada banco. A segunda é o monitoramento contínuo de conformidade com a Resolução Conjunta nº 16/2025, cujo prazo de adaptação já foi detalhado no checklist acima. A terceira é a avaliação de migração para uma licença própria: ERPs que atingem volume e maturidade operacional podem migrar do modelo de Banking as a Service para Core Banking mantendo a mesma base tecnológica, sem reconstruir a infraestrutura.
Perguntas frequentes
Quanto tempo leva para integrar contas digitais em um ERP usando Banking as a Service?
O prazo depende da complexidade da arquitetura existente e da disponibilidade do time de engenharia para executar a integração. ERPs com arquitetura modular e APIs bem documentadas costumam colocar os primeiros serviços financeiros em produção em uma a três semanas. Sistemas com arquiteturas monolíticas ou legadas podem levar até três meses. A Celcoin oferece documentação, SDKs e ambientes de sandbox que reduzem os ciclos de integração, além de uma equipe dedicada de suporte técnico para acelerar o processo.
O ERP precisa obter licença do Banco Central para oferecer contas digitais aos seus clientes?
O ERP não precisa de licença própria do Banco Central quando contrata um provedor autorizado de Banking as a Service. Sob a Resolução Conjunta nº 16/2025, a responsabilidade regulatória perante o Banco Central recai integralmente sobre o provedor licenciado, que responde por KYC, PLD/FT, sigilo bancário e relatórios regulatórios. O ERP opera com um contrato de serviços comerciais com o provedor e deve seguir as políticas e limites definidos nesse contrato. A Celcoin, como Instituição de Pagamento autorizada e participante direta no Pix, absorve essa camada regulatória para seus clientes.
Como funciona a migração de uma solução existente para a infraestrutura da Celcoin?
A migração é viável e a Celcoin possui equipe dedicada para apoiar o processo. O ponto de partida é o mapeamento da arquitetura atual, incluindo quais serviços financeiros estão ativos, como o ledger está estruturado e quais integrações bancárias existem. A partir desse diagnóstico, a equipe da Celcoin define um plano de migração faseado que reduz o impacto sobre os clientes finais do ERP. O fator determinante para o prazo é a complexidade da estrutura existente. ERPs com integrações simples migram em dias, enquanto operações com múltiplos serviços financeiros ativos e grande base de contas podem levar até três meses. Durante todo o processo, o suporte técnico da Celcoin permanece disponível com acesso direto aos decisores.
Quais relatórios regulatórios são gerados automaticamente pelo parceiro de Banking as a Service e quais o ERP precisa produzir internamente?
Quando o ERP opera sob a licença da Celcoin no modelo de Banking as a Service, todos os relatórios regulatórios exigidos pelo Banco Central, pela Receita Federal e pela SUSEP ficam sob responsabilidade da Celcoin. Essa lista inclui CADOCs, CCS, DIMP, DES-IF, SCR e PR, entre outros. O ERP não precisa desenvolver nenhuma conexão direta com a RSFN ou o SPB. Internamente, o ERP deve manter registros de suas próprias obrigações fiscais e contábeis como empresa, em seu CNPJ, separados das obrigações financeiras dos clientes finais que utilizam as contas digitais. A separação clara entre o ledger financeiro dos clientes e a contabilidade interna do ERP, descrita no passo 2 da arquitetura, é o mecanismo técnico que viabiliza essa distinção.
