Os bancos passaram a última década perseguindo a transformação digital. Aplicativos móveis, migração para a nuvem, onboarding digital e uma onda de pilotos de IA dominaram a agenda, e o investimento foi real. No entanto, muitas instituições ainda lidam com os mesmos problemas com que começaram: lançamentos de produtos lentos, jornadas de cliente fragmentadas, custos operacionais crescentes e pressão de concorrentes digitais mais ágeis.

O que está por trás de tudo isso é a arquitetura: a distância cada vez maior entre o que um banco quer fazer comercialmente e o que sua tecnologia e dados subjacentes realmente conseguem suportar.

Chamemos isso de lacuna de arquitetura. Ela raramente aparece em um documento de estratégia ou em um roadmap de transformação. Aparece na execução: um produto que deveria levar seis semanas leva seis meses, uma solicitação de rotina precisa de revisão manual, um piloto de IA não consegue avançar além do único caso de uso para o qual foi criado. No setor bancário essa lacuna está aumentando.

Grande parte disso se deve ao crescimento. Muitos bancos se expandiram por meio de aquisições e diversificação regional, e comercialmente essa estratégia funciona. Mas cada aquisição traz consigo seu próprio sistema core bancário, seu próprio modelo de dados, sua própria lógica de tomada de decisão. Depois de algumas rodadas disso, uma instituição deixa de operar uma única plataforma e passa a operar uma federação frouxa de sistemas parcialmente conectados, cada um com suas próprias regras e sua própria versão do cliente.

Nada disso reflete uma estratégia ruim: é simplesmente o que acontece com a arquitetura em escala, e a lacuna se amplia a cada negociação.

Isso não se limita a bancos que crescem por aquisição. Grupos tão consolidados e bem administrados quanto Absa e Standard Bank absorveram custos reais ligados à modernização de sistemas legados, incluindo perdas tecnológicas associadas à substituição de plataformas e à reprioritização estratégica.

Esses não são itens contábeis isolados: são um sinal de que a arquitetura bancária se tornou um alvo móvel, no qual os sistemas legados se depreciam mais rápido do que os ciclos de investimento criados para sustentá-los.

Os bancos digitais nativos estão do outro lado dessa equação. Revolut, Salt Bank, Discovery Bank, Bank Zero e TymeBank, para citar alguns, foram construídos com infraestrutura nativa em nuvem, design API-first e dados em tempo real desde o primeiro dia.

Mas, à medida que escalam, assumem mais complexidade regulatória e ampliam seu portfólio de produtos, encontrarão sua própria versão da mesma limitação. A lacuna de arquitetura não é um problema de sistemas legados: é um problema de escala, e todo banco acaba esbarrando nela.

Historicamente, os bancos podiam tratar a estratégia de negócios e a execução tecnológica como conversas separadas. Isso já não é mais realista. A capacidade de um banco de competir hoje depende da rapidez com que consegue lançar novos produtos, da eficiência com que consegue orquestrar decisões em tempo real, da eficácia com que consegue levar a IA do piloto à produção, da rapidez com que consegue se adaptar a novas regulamentações e da consistência da experiência entre os canais.

Tudo isso depende da arquitetura, não da capacidade digital no sentido tradicional.

A maioria dos bancos está investindo pesadamente em IA nas áreas de fraude, risco de crédito, cobrança e engajamento do cliente. Mas a IA não opera de forma independente dos sistemas ao seu redor. Ela depende de dados limpos, conectados e em tempo real, de uma visão única do cliente, de uma tomada de decisão incorporada ao negócio em vez de adicionada posteriormente, e de uma orquestração que funcione em toda a empresa.

A pergunta para os líderes bancários não é se devem modernizar ou investir em IA. A maioria já está fazendo isso, e os investimentos vão continuar. A verdadeira pergunta é se a arquitetura subjacente consegue sustentar a instituição que estão tentando se tornar.

Os bancos que fecharem essa lacuna não serão necessariamente os maiores nem os mais rápidos. Serão aqueles que tratarem a arquitetura, e as decisões que passam por ela, como um ativo estratégico, e não apenas como um item de TI.

Escrito por