The decision that defines your product's ceiling
There is an infrastructure decision that every fintech or financial company must make — sooner or later — and which is notoriously difficult to reverse: the choice of core banking.
Core banking is not just a system. It is the foundation upon which all financial products are built. Every account created, every transaction processed, every product rule defined goes through the core. And when this foundation has limitations — when it does not support the volume you need, does not have the API your product requires, or charges for every customization as if it were a separate project — the ceiling of what you can build becomes painfully visible.
The cost of switching core banking is high. Not just financially — but in time, operational risk, rework of integrations, and customer impact during migration. Therefore, making a good choice at the beginning — or clearly understanding what you are accepting when choosing a platform with known limitations — is one of the most important strategic decisions of any financial operation.
This article was written for those in this process: choosing their first core banking, evaluating a switch, or simply trying to understand what is at stake before signing any contract.
📌 Context: This article is part of the cluster on Banking as a Service. If you are still evaluating whether to build your own infrastructure or use a BaaS model, we recommend starting with the guide Banking as a Service: what it is, how it works, and when it is worth it.
O que é Core Banking
Core banking é o sistema central de processamento de operações bancárias — o software que gerencia contas, processa transações, controla saldos, aplica regras de produtos financeiros e mantém o registro histórico de tudo que acontece na operação.
Se o banco ou a fintech fosse um organismo, o core banking seria o sistema nervoso central: não é o que o cliente vê, mas é o que processa cada sinal e garante que tudo funcione de forma coordenada.
O que o core banking processa
As funções centrais de um core banking incluem:
Gestão de contas: abertura, encerramento, manutenção de saldo, histórico de movimentações, limites e restrições por conta.
Processamento de transações: débitos, créditos, transferências, estornos — cada operação financeira é registrada, validada e confirmada pelo core.
Gestão de produtos financeiros: as regras de cada produto (conta corrente, conta poupança, crédito, cartão, investimento) são configuradas e executadas pelo core. Taxa de juros, carência, limite de crédito, regime de capitalização — tudo isso vive no core.
Compliance e controles regulatórios: o core mantém os registros necessários para relatórios ao Banco Central, controles de AML (anti-lavagem de dinheiro) e auditoria.
Conciliação e fechamento: ao final de cada dia operacional, o core reconcilia as posições, fecha o balanço e prepara os dados para os sistemas downstream.
O que o core banking não é
Vale esclarecer o que geralmente fica fora do escopo do core — e que precisa ser contratado ou construído separadamente:
Interface com o usuário final: o aplicativo, o internet banking, o portal — esses são sistemas separados que consultam e atualizam o core via API.
Canal de atendimento: CRM, chatbot, central de atendimento — sistemas de relacionamento com o cliente são integrados ao core, não parte dele.
Antifraude: sistemas de detecção e prevenção de fraude geralmente são camadas separadas, integradas ao core via API.
Infraestrutura de rede: Pix, TED, boleto — as integrações com os sistemas do Banco Central e das câmaras de liquidação são módulos específicos, muitas vezes fornecidos por parceiros especializados.
As três arquiteturas de Core Banking
The core banking market has evolved in technological generations that still coexist — and understanding this evolution is essential to clearly evaluate any provider.
Legacy systems (mainframe and monolithic)
Legacy banking systems were built in the 1970s through the 1990s, when the primary requirement was to process large volumes of transactions with absolute reliability. They fulfilled this role with mastery — and that is why they still run a large part of the global banking system, including major Brazilian banks.
The limitations are well known: monolithic architecture that makes changes difficult, scarce programming technologies in the market (COBOL, for example), batch processes that were not designed for real-time, and rising maintenance costs as the code ages.
For fintechs and new entrants, legacy systems are not a realistic option. For traditional banks, migration is a project of years — with significant operational risk at every stage.
Cloud-native core banking
The second generation of core banking was built natively for the cloud — with microservices architecture, REST APIs, real-time processing, and elastic scalability. Platforms like Mambu, Thought Machine, and Dock (in Brazil) represent this profile.
The advantages are clear: flexibility, scalability, well-documented APIs, and continuous updates without prolonged maintenance windows. Limitations appear at extreme scale — some cloud-native systems are still proving their capacity to process the volumes of a large retail bank — and in highly specific customizations that may require additional development alongside the provider.
For fintechs and digital banks, cloud-native core banking is now the market standard.
Modular and API-first architecture
The most recent evolution is core banking as a composable platform — a set of independent modules (accounts, transactions, products, compliance) that can be combined as needed, consumed via API, and replaced individually without affecting the rest.
This model offers the ultimate in flexibility but requires greater engineering maturity to integrate and operate. It is the ideal architecture for fintechs with a robust technical team that want granular control over every component of the financial stack.
🔗 Technical deep dive: To understand how core banking fits into the complete banking infrastructure — alongside APIs, compliance, security, and observability — read the article Banking infrastructure: what your fintech needs to consider before choosing a partner.
Core Banking próprio vs. plataforma BaaS: quando construir e quando contratar
Before evaluating which core banking to choose, it is worth answering a prior question: do you need your own core banking u2014 or does it make more sense to use a BaaS platform that already includes the core as part of the infrastructure?
The answer depends on three main variables:
Required level of customization: Standardized financial products (payment accounts, prepaid cards, Pix) are well served by the built-in core in BaaS platforms. Products with very specific business rules u2014 credit with proprietary scoring, customized investment products, complex settlement rules u2014 may require their own core with steeper flexibility.
Volume and margin: A BaaS platform's core banking comes with a cost built into the transaction fee or monthly subscription. At low and medium volumes, this cost is efficient. At very high volumes, a TCO analysis might point to building your own core as the more economical choice.
Platform ambition: If the strategy is to become a BaaS provider u2014 offering infrastructure to others u2014 having your own controlled core is almost always necessary.
ud83dudd17 For those making this decision: The article BaaS vs. Embedded Finance vs. White Label: which model to choose for your fintech provides a comparative matrix that includes the core banking dimension.
Os 8 critérios para avaliar um Core Banking
Independentemente de qual fornecedor está sendo avaliado, esses oito critérios cobrem as dimensões que mais impactam a operação no médio e longo prazo:
1. Escalabilidade comprovada O fornecedor tem clientes operando no volume que você projeta para daqui a 3 anos? Escalabilidade declarada em apresentação comercial não é o mesmo que escalabilidade comprovada em produção. Peça referências de clientes com perfil similar ao seu.
2. Qualidade e cobertura das APIs As APIs cobrem todos os produtos que você precisa lançar? A documentação é completa e atualizada? Existe um ambiente de sandbox funcional para testes antes da contratação? Uma API mal documentada ou instável multiplica o custo de integração.
3. Flexibilidade de configuração de produtos Você consegue configurar novos produtos financeiros — com regras específicas de taxa, limite, carência e condição — sem precisar abrir um chamado de desenvolvimento para o fornecedor? A autonomia de configuração de produto é um dos diferenciadores mais práticos entre plataformas.
4. Compliance e relatórios regulatórios O core gera automaticamente os relatórios exigidos pelo Banco Central (SCR, BACEN 3040, FINREP, entre outros)? Atualizações regulatórias são incorporadas pelo fornecedor sem custo adicional? Compliance como serviço é um dos maiores valores de um core banking bem posicionado.
5. Modelo de precificação e previsibilidade de custo O modelo de cobrança é por transação, por conta ativa, por módulo ou por mensalidade fixa? Qual é o custo projetado nos cenários de 10x e 100x do volume atual? Surpresas de custo em escala são uma das causas mais comuns de migração forçada de core banking.
6. Tempo de implementação e suporte ao onboarding Qual é o prazo típico para um cliente com o seu perfil ir ao ar? O fornecedor tem equipe de implementação dedicada ou o processo é self-service? Um onboarding mal estruturado atrasa o lançamento e consome horas de engenharia que poderiam estar no produto.
7. Roadmap e velocidade de evolução O fornecedor tem um roadmap público ou compartilhado com clientes? Quantas releases foram feitas nos últimos 12 meses? Com que velocidade features solicitadas por clientes são incorporadas? Um core bancário que para de evoluir rapidamente se torna um gargalo de produto.
8. Portabilidade e saída Como é o processo de migração de dados caso você precise trocar de fornecedor? Os dados são exportáveis em formato aberto? Existe lock-in técnico estrutural? Avaliar a saída antes de entrar é uma das práticas mais negligenciadas — e mais importantes — na escolha de qualquer infraestrutura crítica.
Os erros mais comuns na escolha do Core Banking
Esses erros aparecem repetidamente em projetos de avaliação e implementação de core banking. Conhecê-los não garante que você vai evitá-los — mas aumenta significativamente a chance.
Escolher pelo preço do contrato inicial. O custo de um core banking não é o fee mensal no primeiro ano — é o TCO em 5 anos, incluindo custos de customização, integrações, suporte, atualizações regulatórias e eventual migração. Plataformas com mensalidade mais baixa frequentemente compensam com cobranças por cada módulo adicional, cada relatório regulatório e cada customização de produto.
Não testar em sandbox antes de contratar. Apresentações comerciais mostram o que o sistema faz em condições ideais. O sandbox mostra o que o sistema faz quando o seu time tenta fazer o que você realmente precisa. São experiências frequentemente muito diferentes.
Subestimar o esforço de migração. Migrar de um core banking para outro em produção, sem impactar clientes, é um dos projetos técnicos mais complexos de uma operação financeira. Fintechs que escolhem o primeiro core "para começar" sem planejar a migração futura frequentemente descobrem que o custo de trocar é alto o suficiente para manter uma plataforma inadequada por mais tempo do que deveriam.
Ignorar o time técnico do fornecedor. O produto técnico de uma plataforma de core banking é tão bom quanto o time que o mantém. Antes de contratar, vale entender quem são os engenheiros responsáveis pela plataforma, qual é a rotatividade do time e qual é a capacidade de suporte em incidentes críticos fora do horário comercial.
Não avaliar o ecossistema de parceiros. Um bom core banking tem um ecossistema de parceiros certificados — integradores, consultorias, fornecedores de módulos complementares. Esse ecossistema reduz o custo de implementação, acelera o acesso a funcionalidades adicionais e aumenta a resiliência da operação.
Checklist de avaliação — 10 perguntas para fazer a qualquer fornecedor
Antes de avançar em qualquer processo de contratação de core banking, valide estes dez pontos:
Quais são os três maiores clientes com perfil similar ao nosso que operam na sua plataforma hoje?
Qual é o volume máximo de transações por segundo que a plataforma processa em produção — não em benchmark de laboratório?
Como é feita a configuração de um novo produto financeiro? Quem pode fazer isso — o nosso time ou apenas o fornecedor?
Quais relatórios regulatórios são gerados automaticamente, e quais exigem customização adicional?
Qual é o SLA de disponibilidade contratado, e como são tratados os incidentes que afetam esse SLA?
Como funciona o processo de atualização regulatória — quem é responsável, qual é o prazo típico e há custo adicional?
Qual é o modelo de precificação projetado para 10x do nosso volume atual?
Como é o processo de exportação de dados caso precisemos migrar para outra plataforma?
Qual é o roadmap dos próximos 12 meses, e como clientes influenciam as prioridades de desenvolvimento?
Qual é o processo de suporte em incidentes críticos fora do horário comercial?
Conclusão: Core Banking como decisão estratégica, não técnica
The choice of core banking is often treated as a technical infrastructure decision — delegated to the CTO with little participation from the product and business side. This is a mistake with long-term consequences.
The core banking defines the ceiling of what is possible to build. A platform with limited APIs will restrict the product roadmap. A system without configuration flexibility will create vendor dependency for every change in business rules. An opaque pricing model will create cost surprises when volume starts to grow.
The right decision is the one that balances launch speed with product flexibility, initial cost with long-term TCO, and technical autonomy with implementation risk. And it needs to involve product, engineering, compliance, and finance from the beginning — not just at the moment of signing the contract.
🚀 Next step: With the core banking mapped out, the next level of evaluation is understanding how it fits into the complete banking infrastructure — including APIs, security, compliance, and observability. Read the article Banking infrastructure: what your fintech needs to consider before choosing a partner.
