Construir ou comprar: o custo real de um sistema de core banking

Mais cedo ou mais tarde, todos os fundadores de fintech põem preço à mesma decisão: construir o sistema de core banking internamente, ou licenciar um e configurá-lo. A comparação ingénua — uma licença de um lado, alguns salários de programadores do outro — está quase sempre errada, porque as duas colunas não contêm as mesmas coisas.

A comparação honesta é o custo total de propriedade ao longo da vida do produto: a construção, a manutenção permanente, o trabalho recorrente de segurança e compliance, e a receita que não gera enquanto constrói. Nós fazemos software de core banking, por isso temos obviamente uma posição — mas o cálculo abaixo é o que quereríamos ver se fôssemos nós os compradores.

O que significa realmente "um sistema de core banking"

A maioria das estimativas de construir-ou-comprar descarrila antes de se escrever o primeiro número, porque o âmbito fica aquém da realidade. A app bancária que os seus clientes veem é a fração visível do sistema. Um core pronto para produção são quatro produtos num só:

• O núcleo transacional: um ledger de dupla entrada que se mantém equilibrado sob carga concorrente, onde cada saldo é derivado do ledger e reconciliado diariamente contra cada provedor.
• O produto para o cliente: a própria app bancária, o onboarding com níveis de KYC e KYB, contas multimoeda, transferências, cartões — e, cada vez mais, carteiras cripto com custódia de chaves a sério por trás.
• O segundo produto que ninguém orçamenta: um back office de operações para filas de compliance, monitorização de transações, configuração de comissões, relatórios e perfis granulares para a equipa.
• A camada invisível: uma trilha de auditoria append-only, fluxos de duplo fator para lá do login, rate limiting, fingerprinting de dispositivos e uma gestão de chaves que mantém os segredos fora do código e da base de dados.

A via de construir: o que o orçamento contém de verdade

Uma construção interna realista precisa de engenheiros backend seniores com experiência em sistemas financeiros, engenheiros frontend, DevOps e segurança, QA, e uma coordenação de produto que entenda de compliance. As equipas que atingem qualidade de produção raramente têm menos de seis a dez pessoas seniores — e o perfil escasso, engenheiros que já operaram ledgers e custódia em produção, é exatamente o mais difícil de contratar e de reter.

Nos prazos, o padrão é consistente: um a dois anos até alcançar o que uma plataforma madura oferece no primeiro dia. O tempo não se gasta em ecrãs; gasta-se na correção do ledger sob concorrência, em integrações de provedores que trazem as suas próprias particularidades de sandbox e passos de certificação, no endurecimento da segurança e na longa cauda de casos-limite que só aparecem com clientes e dinheiro reais.

E a despesa não termina no lançamento. Os provedores mudam as APIs, as redes blockchain atualizam-se, a regulação move-se, as dependências degradam-se. Um core interno não é um projeto que acaba; é uma equipa permanente que se compromete a financiar enquanto o produto existir.

Os custos que nunca aparecem na folha de cálculo

• Custo de oportunidade: cada mês gasto a construir o ledger é um mês em que o produto não está no mercado. Os concorrentes que licenciaram o seu core estão a captar clientes e a iterar preços enquanto você ainda está a integrar provedores.
• Risco de contratação: o plano assume que a equipa que começa a construção a termina. Perder um dos dois engenheiros que entendem o ledger a meio do projeto é um evento de calendário que se mede em meses.
• A cauda da correção: um ledger 99% correto não está quase pronto — é um gerador de tickets de suporte, quebras de reconciliação e incidentes regulatórios. O último 1% custa mais do que os primeiros 99%.
• A segurança como operação: testes de penetração, rotação de chaves, resposta a incidentes, monitorização e alertas — custos recorrentes que existem mesmo que nada corra mal.
• A manutenção do compliance: expiração de documentos KYC, regras de criptoativos em evolução, novas obrigações de reporte. O trabalho repete-se todos os anos e não pode ser adiado.
• O back office: as construções internas tratam sistematicamente as ferramentas da equipa como algo secundário, e a equipa de operações herda uma consola SQL. Qualquer regulador ou auditor que veja isso obrigá-lo-á a reconstruí-lo como deve ser.
• A localização: lançar em muitos idiomas com suporte right-to-left real é barato quando desenhado desde o primeiro dia e caro de acrescentar depois de o produto estar construído.

A via de comprar: o que paga e o que continua a ser seu

Na via de comprar, a coluna da tecnologia é explícita: uma licença ou aluguer da plataforma — os fornecedores sérios põem preço a módulos, blockchains e idiomas separadamente, para que a fatura acompanhe o que realmente ativa — mais a infraestrutura onde a instância corre. O que comprar não elimina: as suas licenças regulatórias ou acordos com parceiros, os seus contratos comerciais com provedores, a sua equipa de operações, a sua distribuição. Esses custos pertencem ao operador em qualquer das vias — comprar elimina a montanha de engenharia, não o negócio.

Os custos honestos de comprar têm forma de dependência: o roadmap não é totalmente seu, e a plataforma vale o que valer o seu pior módulo. As mitigações são verificáveis antes de assinar: uma instância dedicada com a sua própria base de dados e os seus próprios segredos cifrados, para que sair do fornecedor seja uma migração e não uma negociação de reféns; integrações de provedores mantidas atrás de uma camada de abstração, para que os acordos sejam seus e os provedores possam ser substituídos; licenciamento modular, para pagar apenas o que liga; e evidência de que a plataforma já processou clientes e dinheiro reais.

Quando construir internamente é a decisão certa

Construir-ou-comprar não é uma pergunta retórica com resposta predeterminada. Construir é o caminho certo quando pelo menos uma destas condições se verifica:

• A infraestrutura é o produto: você vende o ledger, a custódia ou a própria capacidade de banking-as-a-service, pelo que ser dono dela é o negócio.
• A sua diferenciação vive em requisitos que nenhum fornecedor cobre — não funcionalidades que faltam a um fornecedor este trimestre, mas capacidades estruturalmente fora do que as plataformas fazem.
• Já tem uma equipa sénior com experiência de core banking em produção, e o fôlego financeiro para a financiar durante anos sem receita.
• Um regulador ou uma casa-mãe impõe o controlo interno total do stack como condição inegociável.

Um quadro de cinco perguntas

• Diferenciação: algum cliente o escolherá alguma vez porque o seu ledger é feito em casa? Se a sua vantagem está no produto, na distribuição ou no preço, o core é canalização — essencial, mas não algo que lhe caiba reinventar.
• Prazos: consegue o negócio absorver um a dois anos sem receita enquanto o core é construído, num mercado que não espera?
• Equipa: tem, ou consegue realisticamente contratar e reter, engenheiros que já operaram sistemas que movem dinheiro em produção?
• Custo a três anos: compare o custo de construção mais uma equipa de manutenção permanente contra licença mais módulos ativados ao longo de três anos — nunca custo de lançamento contra custo de lançamento.
• Saída: como é sair em cada via? Internamente, o risco é as pessoas-chave irem embora com o conhecimento. Com um fornecedor, exija instância dedicada, a sua própria base de dados e as suas próprias chaves, e a saída é uma migração.

Onde a Coreza se situa nesta decisão

A Coreza é a coluna de comprar, construída para sobreviver à checklist acima: cada cliente opera uma instância dedicada na AWS com a sua própria base de dados e os seus próprios segredos cifrados, cada módulo — blockchains, idiomas e tokens incluídos — é licenciado individualmente para que o preço acompanhe o que ativa, e as integrações de provedores vivem atrás de uma camada de abstração para que os acordos comerciais continuem a ser seus.

Uma versão deste core está em produção numa fintech europeia regulada desde 2024, e uma instância nova é implementada em semanas: marca, módulos, idiomas e blockchains são configuração, não engenharia. Se está a fazer as contas de construir-ou-comprar, é essa a comparação que o convidamos a fazer — custo a três anos contra custo a três anos, com a coluna escondida preenchida.