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 uma responsabilidade durante grande parte de duas décadas. A conversa não mudou muito. A infraestruturas legada é cara de manter, difícil de alterar e cada vez mais desalinhada com o que os modelos operacionais modernos exigem. No geral, isto é amplamente entendido.

O que é menos compreendido é que o sistema de base se tornou silenciosamente o teto de cada outro investimento estratégico que um banco está a fazer agora.

Considere o 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 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 genuíno. Cada um deles, em algum momento, também exige que o sistema de base faça algo para o qual não foi concebido.

Os fluxos de trabalho de IA agentica que executam de forma autónoma precisam de confirmação de liquidação em tempo real. Os depósitos tokenizados exigem lógica de transação 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 de conformidade para fluxos de dinheiro programáveis 24/7 não pode depender de checkpoints que fecham à meia-noite.

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

A taxa de falhas nos programas de modernização do sistema de base torna a urgência mais difícil de agir do que mais fácil. A maioria dos programas que tentam uma substituição total é morosa, custa mais do que o previsto e entrega menos do que prometia. A investigação da IBM concluiu que 94% dos programas de modernização do sistema de base falharam os seus prazos iniciais. As organizações que foram atingidas por essas experiências são, compreensivelmente, cautelosas quanto à próxima tentativa. Mas a cautela na modernização do sistema de base não é a mesma coisa que segurança. É uma escolha para absorver a restrição em vez de a remover, e essa escolha agrava-se com o tempo à medida que a distância entre aquilo que o sistema de base consegue fazer e aquilo de que o negócio precisa aumenta.

As instituições que navegam isto com maior eficácia não estão a tentar uma substituição total. Estão a executar arquiteturas de sidecar, com núcleos modernos a operar em paralelo com sistemas legados, tratando produtos específicos, segmentos de clientes ou tipos de transação em que a restrição do legado é mais aguda. A IDC estima que 40% dos bancos globais estão a seguir esta abordagem até 2026. A lógica é sólida: validar o novo núcleo num âmbito contido, demonstrar 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. E também é consideravelmente mais provável que tenha sucesso.

A redefinição mais importante, no entanto, não é sobre qual abordagem de modernização escolher. É sobre onde o sistema de base se posiciona na sequência estratégica da instituição.

A maioria dos bancos trata a modernização do sistema de base 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. Essa forma de enquadrar torna mais fácil despriorizar quando os ciclos orçamentais apertam ou quando uma iniciativa mais visível compete por recursos. Também torna mais difícil ligar o sistema de base aos resultados estratégicos de que as conversas ao nível do conselho são, de facto, sobre: a capacidade de implementar IA agentica em 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 stacks modernos desde o início.

O sistema de base não é um problema tecnológico 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. Chamar-lhe assim altera o que é discutido, quem o assume, e o que é um prazo aceitável para a resolução.

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

Trata-se de outro tipo de dívida técnica. Não aparece no balanço. Aparece na diferença entre o que é anunciado e o que é entregue.