Principais lições deste artigo
- O ledger é o critério eliminatório em um Core Banking moderno. Sem ledger como fonte de verdade, os demais critérios perdem relevância.
- Migração e coexistência com o legado exigem plano de exportação de dados, operação em paralelo e rollback testado antes da assinatura do contrato.
- Ser API-first significa demonstrar ao vivo criação de cliente, lançamento e reversão via API, sem intervenção manual no painel.
- Pix, Open Finance e reportes regulatórios formam um conjunto de requisitos de arquitetura que precisa de conexão direta à RSFN e ao SPB, com suporte nativo a idempotência e ciclo de vida de consentimento.
- O banking da Celcoin oferece infraestrutura que acompanha a jornada de licenciamento no Brasil, desde BaaS até Core Banking próprio, com continuidade tecnológica e APIs modulares.
Saiba como a Celcoin atende aos critérios de um Core Banking moderno
O que é o Core Banking?
Core Banking é a infraestrutura bancária central que processa contas, transações, produtos e relatórios regulatórios de uma instituição financeira. Esse modelo difere do Banking as a Service (BaaS) em um ponto essencial. No BaaS, a empresa opera sob a licença de um terceiro. No Core Banking, a empresa já possui licença própria, como a de Instituição de Pagamento (IP) ou Instituição Financeira (IF), e integra essa licença à infraestrutura tecnológica do fornecedor.
A jornada típica no Brasil começa no BaaS e evolui para o Core Banking conforme a empresa obtém sua própria autorização junto ao Banco Central do Brasil. Essa evolução torna a escolha do fornecedor de Core Banking um passo estratégico.
Quais critérios usar para escolher um Core Banking moderno?
Se a jornada começa no BaaS e evolui para o Core Banking, a escolha do fornecedor precisa acompanhar essa transição. A lista abaixo reúne sete critérios, ordenados por prioridade. A ordem importa: um fornecedor que falha no critério 1 não deve ser avaliado pelo critério 2.
- Ledger como fonte de verdade, com capacidade de reconstruir o saldo de qualquer cliente em qualquer instante do passado.
- Migração e coexistência com o legado, com plano de exportação de dados, operação em paralelo e rollback.
- API-first de verdade, com demonstração ao vivo de criação de cliente, lançamento e reversão via API.
- Pix e Open Finance como requisitos de arquitetura, com conexão direta à RSFN e ao SPB e suporte nativo a idempotência, conciliação e ciclo de vida de consentimento.
- Capacidade de POC e teste de desastre, com sandbox disponível antes da assinatura do contrato e possibilidade de executar cenários de timeout, retry e rollback.
- Lock-in e custo de saída, com clareza sobre propriedade dos dados, formato de exportação e prazo contratual de saída.
- Aderência à jornada de licenciamento no Brasil, com suporte tanto à operação sob licença de terceiro quanto à integração de licença própria, sem troca de base tecnológica.
Ledger como fonte de verdade: por que esse critério elimina fornecedores
A pergunta “consigo reconstruir o saldo de qualquer cliente em qualquer instante do passado?” elimina fornecedores que tratam o ledger como cache de saldos em vez de sistema de registro.
Um ledger correto impõe quatro invariantes na camada de armazenamento. A primeira é a soma zero em cada lançamento: todo débito tem um crédito correspondente. A segunda é tratar postings como fonte de verdade, com saldos derivados e nunca armazenados separadamente. A terceira é o modelo append-only, com postings de reversão para correções. A quarta é a escrita idempotente com deduplicação explícita, como detalhado em estudos de arquitetura de Core Banking. Quando essas invariantes estão ausentes, uma divisão de tarifa em código de aplicação pode executar como múltiplas escritas que falham parcialmente, o que gera divergências de conciliação difíceis de rastrear.
O processo de avaliação deve exigir evidência na documentação de API do fornecedor. Perguntas concretas a fazer:
- A API expõe consulta de saldo pontual por timestamp?
- Reversões e estornos são postings compensatórios no mesmo ledger ou ajustes em tabela separada?
- A trilha de auditoria é imutável e encadeada por hash?
- O relatório regulatório é extraído do mesmo ledger que alimenta o extrato do cliente?
Se o fornecedor não demonstrar esses pontos na documentação de API antes da assinatura do contrato, o critério de ledger não foi atendido.
Como migrar do Core legado para um Core moderno
Migração e coexistência com o legado formam o critério de maior risco e o menos discutido em processos de seleção. Projetos de integração de Core Banking costumam falhar por problemas de dados subestimados, prontidão da plataforma superestimada e cronogramas comprimidos por pressão de negócio.
O que exigir do fornecedor antes de assinar:
- Exportação de dados: formato aberto e documentado, como JSON ou CSV estruturado, sem dependência de ferramenta proprietária para leitura.
- Mapeamento de campos: regras explícitas para campos nulos, em branco ou com valores padrão no legado.
- Operação em paralelo: capacidade de rodar os dois sistemas simultaneamente, com reconciliação contínua de saldos antes do cutover.
- Rollback: plano documentado e testado para reverter a migração, com execução prevista e não improvisada após falha.
- SLA de migração: janelas definidas, responsáveis nomeados e critérios de entrada e saída para cada onda.
Os prazos variam conforme a complexidade da estrutura existente e a disponibilidade para migrar. A abordagem de menor risco segue o padrão strangler fig. Essa abordagem migra um domínio por vez, como contas, pagamentos ou crédito, enquanto o sistema legado permanece operacional para os domínios ainda não migrados, com rollback possível por domínio individual.
API-first de verdade vs. ter APIs
Ser API-first significa tratar APIs como o principal meio de operação do sistema. Em uma plataforma API-first, conectar uma nova rede de pagamentos ou lançar um produto de finanças embutidas exige configuração e integração via API, sem engenharia customizada.
O processo de avaliação deve incluir uma demonstração ao vivo, sem intervenção manual no painel, cobrindo:
- Criação de cliente via API, com retorno de ID único e trilha de auditoria.
- Lançamento de transação, com observação de latência, estrutura do evento emitido e idempotência.
- Reversão, com geração de posting compensatório no ledger em vez de simples ajuste de saldo.
- Consulta de saldo, com suporte a timestamp histórico.
- Webhooks, com retry automático, deduplicação e log de entrega.
Documentação completa, SDKs e sandboxes acessíveis antes da assinatura do contrato reduzem ciclos de integração e custos de engenharia. A ausência de sandbox antes do contrato funciona como um sinal de alerta.
Core Banking e Pix/Open Finance: o que exigir do fornecedor
Pix e Open Finance funcionam como requisitos de arquitetura. O Banco Central registrou quase 80 bilhões de transações via Pix em 2025, com movimentação superior a R$ 35 trilhões. Uma plataforma que trata Pix como módulo opcional não acompanha a realidade do mercado brasileiro.
O que exigir do fornecedor em relação ao Pix:
- Conexão direta à Rede do Sistema Financeiro Nacional (RSFN) e ao Sistema de Pagamentos Brasileiro (SPB).
- Suporte nativo a idempotência em todas as operações Pix.
- Implementação do Mecanismo Especial de Devolução (MED) conforme a versão 7.4 do Manual de Requisitos Mínimos para a Experiência do Usuário do Pix, com entrada em vigor em março de 2027.
- Suporte ao Pix Automático, com observância das regras publicadas pelo Banco Central em setembro de 2026.
O que exigir em relação ao Open Finance:
- Aderência à Resolução Conjunta CMN/BCB nº 1/2020 e à Resolução BCB nº 315/2023, com gestão completa do ciclo de vida de consentimento.
- Disponibilidade de APIs de 95% diária e 99,5% em média móvel de 90 dias, em linha com o Manual de Monitoramento do Open Finance (IN BCB nº 706/2026).
- Suporte à Jornada Otimizada introduzida pela IN BCB nº 724/2026, que permite consentimento simultâneo para iniciação de pagamentos e compartilhamento de dados.
- Geração automatizada de reportes regulatórios, como CCS, CADOCs, COSIF, DIMP, SCR e demais obrigações acessórias.
Como fazer POC de Core Banking: roteiro e teste de desastre
Um POC de Core Banking gera mais valor quando começa com uma hipótese única e verificável. A SDK.finance recomenda escrever a hipótese em uma frase: “acreditamos que X funcionará sob as condições Y, e vamos medi-lo usando Z.”
Roteiro mínimo para um POC de Core Banking:
- Definir escopo estreito: uma moeda, um tipo de transação, um provedor.
- Estabelecer critérios mensuráveis de sucesso e parada antes do início, como ausência de transação duplicada após retry, todo lançamento balanceado e toda divergência de conciliação detectada.
- Executar o caminho feliz: criação de cliente, lançamento, consulta de saldo e reversão.
- Executar cenários de falha: timeout do provedor, callback atrasado, callback duplicado e webhook fora de ordem.
- Testar idempotência: repetir a mesma requisição com a mesma chave e verificar se o sistema retorna o resultado original sem criar um segundo lançamento.
- Testar rollback: verificar se saldos retornam ao valor esperado após reversão e se contas de trânsito temporárias retornam a zero.
- Registrar o resultado com honestidade: comparar medições com os critérios definidos e decidir se continua, muda a abordagem ou encerra.
Checklist de teste de desastre:
- Simular latência e jitter na conexão com o fornecedor, usando ferramentas como Toxiproxy, que permitem esse tipo de teste de forma programática sem alterar o código da aplicação.
- Derrubar o serviço no meio de uma transação e verificar o comportamento de retry com exponential backoff.
- Introduzir duplicação deliberada de webhook e confirmar que o sistema não posta a transação duas vezes.
- Verificar se estados intermediários, como Initiated, Processing e Pending, são expostos via API e se cada estado tem uma ação operacional definida.
- Confirmar que o circuit breaker isola a falha sem propagar degradação para outros serviços.
Se o POC incluir crédito, o roteiro acima precisa cobrir também o ciclo completo de concessão, desembolso e cobrança, com verificação de que cada etapa gera postings balanceados no ledger. A Celcoin oferece infraestrutura de crédito como parte de sua solução full stack, o que permite que empresas ofertem produtos de crédito aos seus clientes.
Veja como fazer um POC de Core Banking com a Celcoin
Como evitar lock-in no Core Banking
Lock-in em Core Banking costuma aparecer em formatos proprietários de exportação, módulos sem equivalente no mercado, prazos de saída longos e ausência de documentação para migração.
Perguntas contratuais que revelam dependência proprietária:
- Quem é o proprietário legal dos dados, a empresa ou o fornecedor?
- Em qual formato os dados podem ser exportados e se o formato é aberto e legível sem ferramenta proprietária.
- Qual é o prazo contratual mínimo de saída e se existe multa por rescisão antecipada.
- Quais módulos não têm equivalente em outras plataformas do mercado.
- Se o fornecedor mantém plano documentado de migração de saída, com estratégia de exit clara.
Uma ação concreta para a próxima negociação é incluir no contrato cláusulas explícitas de portabilidade de dados, formato de exportação, prazo máximo de entrega dos dados após rescisão e direito de auditoria. Backbase recomenda que bancos exijam SLAs claros e cláusulas de saída nos contratos de fornecedores, com prioridade para arquiteturas abertas que interoperem com fintechs de terceiros.
Core Banking composable vs. monolítico
Uma arquitetura monolítica concentra ledger, motor de pagamentos, lógica de produtos e relatórios de compliance em uma única unidade de implantação e em um único domínio de falha. A falha de um componente pode se propagar por todo o sistema financeiro.
Uma arquitetura composable trata cada capacidade bancária como um serviço discreto que pode ser implantado, atualizado e escalado de forma independente. Esse modelo permite que o sistema cresça de dez mil para dez milhões de transações por dia sem mudanças arquiteturais.
O que observar ao avaliar a arquitetura de um fornecedor:
- Se módulos individuais podem ser implantados e atualizados de forma independente.
- Se a plataforma usa microsserviços com comunicação orientada a eventos ou apenas expõe APIs sobre um monólito.
- Se mudanças de configuração de produto, como taxas, regras de juros e limites, ocorrem sem desenvolvimento customizado.
- Se atualizações da plataforma exigem janela de manutenção ou se são entregues com zero downtime.
O banking da Celcoin opera com arquitetura baseada em microsserviços, com APIs modulares e atualização constante. Esse modelo permite que cada cliente contrate apenas as partes da infraestrutura que fizerem sentido para seu modelo de negócio.
A jornada de licenciamento no Brasil: como escolher um Core que acompanhe sua empresa
A escolha do Core Banking precisa considerar a jornada de licença da empresa. No Brasil, a Resolução BCB 494/2025 tornou a autorização prévia obrigatória para toda Instituição de Pagamento que preste serviço de pagamento, e a Resolução Conjunta CMN/BCB 14/2025 adotou o modelo Activity-Based Capital, com capital mínimo calculado em função do modelo de negócio. Trocar de base tecnológica no meio desse processo aumenta o risco operacional e regulatório.
O banking da Celcoin combina portfólio de licenças e tecnologia proprietária para cobrir essa jornada de forma contínua:
- BaaS para empresas não reguladas: fintechs, bancos digitais, ERPs e varejistas operam sob a licença da Celcoin, com contas digitais, Pix, cartões, boletos e TED/DOC, sem necessidade de construir estrutura regulatória do zero.
- Core Banking para IPs e IFs já licenciadas: integração de licença própria à infraestrutura da Celcoin, com onboarding e KYC, gestão de contas com ledger, relatórios regulatórios automatizados, como CCS, CADOCs, COSIF, DIMP, SCR e BacenJud, cabine de tesouraria e infraestrutura de Open Finance.
- Continuidade tecnológica: a empresa começa no BaaS e evolui para o Core Banking mantendo a mesma base tecnológica, com segurança e suporte consistentes.
Com a aquisição da VERT Capital, anunciada em agosto de 2026, o ecossistema da Celcoin passou a incluir securitização, administração fiduciária e gestão de fundos estruturados. Esse movimento amplia o caminho para empresas que desejam evoluir para crédito e, em seguida, para captação de recursos no mercado de capitais, mantendo a mesma infraestrutura.
Além da expansão por aquisição, a Celcoin investe em ferramentas de desenvolvimento. Em 24 de agosto de 2026, durante o Febraban Tech, a empresa lançou o cel_agents, primeira plataforma sob o conceito AI First da Celcoin. O cel_agents usa inteligência artificial para simplificar o desenvolvimento e a integração de produtos financeiros, com ambiente gratuito de testes disponível em até cinco minutos e redução do período entre a decisão de desenvolver um novo serviço e a obtenção de uma versão funcional, que passa de meses para poucas horas.
Por meio do Model Context Protocol (MCP com compliance), a IA acessa o contexto técnico dos produtos da Celcoin e apoia o desenvolvedor durante o processo de integração, sem necessidade de percorrer diferentes documentos. O uso do cel_agents Studio é opcional. Empresas que já têm interfaces e padrões próprios de desenvolvimento podem utilizar apenas os recursos de integração assistida por IA e manter sua arquitetura e seus processos.
Essa combinação de licenças, tecnologia e ferramentas atende desde startups em estágio inicial até empresas consolidadas, com operações financeiras complexas e grande base de clientes finais. A Celcoin media mais de R$ 40 bilhões em transações mensalmente e atende mais de 6 mil clientes. A tabela abaixo resume como essas capacidades se traduzem em benefícios concretos para a empresa contratante.
| Funcionalidade da Celcoin | Benefício para sua empresa |
|---|---|
| APIs modulares | integrações mais rápidas, reduzindo custos e prazos de desenvolvimento. |
| Experiência e suporte ao desenvolvedor | documentação, SDKs e sandboxes que 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 competitividade. |
| Distribuição white-label e embutida (embedded) | suporte a produtos financeiros com marca própria. |
| Escalabilidade com confiabilidade | 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 | 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 em 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. |
Conheça o portfólio completo de licenças e tecnologia da Celcoin
Erros comuns ao escolher um Core Banking
Alguns erros se repetem em processos de seleção de Core Banking e geram consequências operacionais e regulatórias diretas.
- Decidir por features antes de validar ledger e migração: a lista de funcionalidades não revela se o ledger é a fonte de verdade nem se a migração tem plano de rollback.
- Aceitar demonstrações comerciais sem teste ao vivo de API: um demo em ambiente controlado pelo fornecedor não substitui uma demonstração ao vivo com cenários de falha.
- Ignorar o custo de saída no contrato: formatos proprietários de exportação e ausência de cláusulas de portabilidade criam dependência que só aparece na rescisão.
- Subestimar a complexidade regulatória brasileira: as obrigações de arquitetura discutidas acima, como Pix, Open Finance e reportes regulatórios, não podem ser tratadas como módulos opcionais.
- Não planejar a coexistência com o legado: o trabalho de maior risco em uma migração de Core Banking costuma estar no tratamento de dados históricos, contas de casos extremos e dependências a jusante, e não na nova plataforma em si.
Critérios de sucesso e validação
Uma escolha bem executada de Core Banking pode ser avaliada por indicadores objetivos ao longo dos primeiros meses de operação.
- Estabilidade operacional: ausência de incidentes causados por falhas de ledger ou conciliação.
- Tempo de implementação: aderência ao cronograma de migração definido antes do início.
- Aderência regulatória: envio tempestivo de todos os reportes obrigatórios sem intervenção manual.
- Qualidade da integração: ausência de retrabalho causado por documentação de API incompleta ou comportamento não documentado em produção.
- Segurança: ausência de incidentes de acesso não autorizado e conformidade com a política de segurança cibernética exigida pelas Resoluções CMN/BCB 538/2025.
- Escalabilidade: capacidade de absorver crescimento de volume sem mudanças arquiteturais.
- Redução de retrabalho: diminuição de tickets de suporte relacionados a divergências de saldo, falhas de conciliação e erros de relatório regulatório.
Perguntas frequentes (FAQ)
O que é Core Banking e como se diferencia do BaaS?
Core Banking é a infraestrutura bancária central que processa contas, transações, produtos e relatórios regulatórios de uma instituição que já possui licença própria, como a de IP ou IF. O Banking as a Service (BaaS) permite que empresas sem licença própria operem serviços financeiros utilizando a licença de um terceiro. A principal diferença prática é que, no Core Banking, a empresa integra sua própria autorização regulatória à infraestrutura tecnológica do fornecedor, enquanto no BaaS ela opera inteiramente sob o guarda-chuva regulatório do parceiro. A Celcoin oferece os dois modelos, com BaaS para empresas que ainda não têm licença própria e Core Banking para instituições que já possuem autorização regulatória.

