O núcleo não é um problema de legado. É um problema de estratégia.

Os bancos têm vindo a descrever os seus sistemas bancários de base como um passivo durante a maior parte de duas décadas. A conversa não mudou muito. A infraestrutura legada é cara de manter, difícil de alterar e, cada vez mais, desalinhada com o que os modelos operacionais modernos exigem. Sabe-se, de forma geral, tudo isto.

O que é menos compreendido é que a base se tornou silenciosamente o limite de todos os outros investimentos estratégicos que um banco está a fazer, neste momento.

Pense no desafio de sequenciação que a maioria das instituições enfrenta em 2026. Os conselhos estão a aprovar programas de IA agentica. As equipas de tecnologia estão a construir no sentido de infraestruturas tokenizadas. A modernização dos pagamentos está em curso. As funções de risco e de conformidade estão a ser solicitadas para operar em tempo real, em vez de em ciclos por lotes. Cada um destes programas tem um caso de negócio real. Cada um deles, em algum momento, exige que a base faça algo para o qual não foi concebida.

Os fluxos de trabalho de IA agentica que executam de forma autónoma precisam de confirmação de liquidação em tempo real. Depósitos tokenizados requerem lógica de transações programável que os núcleos monolíticos de processamento por lotes não conseguem suportar de forma nativa. Os pagamentos em tempo real exigem reconciliação contínua, em vez de processamento no fim do dia. A monitorização da conformidade para fluxos de dinheiro programáveis 24/7 não pode depender de checkpoints que fecham à meia-noite.

O núcleo foi concebido para um mundo em que as transações eram agrupadas, a finalização era adiada e a janela da noite era uma funcionalidade. Esse mundo está a terminar mais depressa do que a maioria dos roadmaps de modernização assume.

As taxas de falha nos programas de modernização dos sistemas de base tornam a urgência mais difícil de agir, e não mais fácil. A maioria dos programas que tentam a substituição total dura muito, custa mais do que o previsto e entrega menos do que prometido. A investigação da IBM concluiu que 94% dos programas de modernização do core bancário falharam os prazos iniciais. As organizações que foram prejudicadas por essas experiências são, compreensivelmente, cautelosas perante a próxima tentativa. Mas a cautela na modernização do core não é a mesma coisa que segurança. É uma opção por absorver a restrição em vez de a remover, e essa escolha vai-se acumulando ao longo do tempo à medida que a distância entre o que o core consegue fazer e o que o negócio precisa se torna maior.

As instituições que estão a navegar isto com mais eficácia não estão a tentar uma substituição total. Estão a executar arquiteturas em sidecar, com núcleos modernos a operar em paralelo com sistemas legados, tratando produtos, segmentos de clientes ou tipos de transação específicos em que a restrição do legado é mais aguda. A IDC prevê que 40% dos bancos globais estão a seguir esta abordagem até 2026. A lógica é sólida: demonstrar o novo core num âmbito controlado, provar que a migração não quebra aquilo de que o negócio depende e expandir de forma incremental. É mais lento do que a substituição. Mas é também consideravelmente mais provável que seja bem-sucedido.

A reinterpretação mais importante, no entanto, não é sobre qual abordagem de modernização escolher. É sobre onde o core se posiciona na sequenciação estratégica da instituição.

A maioria dos bancos trata a modernização do core como um programa de tecnologia, gerido pela função de tecnologia, com um caso de negócio construído em torno da redução de custos ou da eficiência operacional. Esse enquadramento torna mais fácil reduzir a prioridade quando os ciclos orçamentais se apertam ou quando uma iniciativa mais visível compete pelos recursos. Também torna mais difícil ligar o core aos resultados estratégicos de que as conversas ao nível do conselho de administração verdadeiramente se tratam: a capacidade de implementar IA agentica à escala, a capacidade de participar em infraestruturas tokenizadas, a rapidez para responder à pressão competitiva de novos entrantes não bancários que construíram em cima de plataformas modernas desde o início.

O core não é um problema de tecnologia que fica a jusante da estratégia. É uma restrição de estratégia que fica a montante de quase todos os investimentos tecnológicos que a instituição está a fazer. Dar-lhe esse nome muda o tipo de conversa, quem a tutela e qual é o prazo aceitável para a resolução.

A questão que vale a pena colocar em cada ciclo de planeamento não é se o core atual consegue suportar os programas no roadmap. É se os programas no roadmap estão a ser concebidos tendo em conta aquilo que o core não consegue fazer, em vez daquilo que o negócio realmente precisa.

Esse é um tipo diferente de dívida técnica. Não aparece no balanço. Aparece na diferença entre aquilo que é anunciado e aquilo que é entregue.