Modernizar sem recomeçar o banco.
Como transformar uma demanda de produto em uma evolução delimitada — e evitar que a próxima entrega carregue mais uma cópia da mesma regra.
Orçamento tecnológico projetado para os bancos no Brasil em 2026. Valor em reais brasileiros (BRL).
Febraban · Pesquisa de Tecnologia Bancária 2026 ↗26 jun 2026 · transações: ano-base 2025; orçamento: projeção 2026O melhor ponto de partida é uma mudança que você consegue delimitar, medir e reverter.Leitura editorial da Catalisa
O que o mercado está pedindo
O orçamento projetado pela pesquisa Febraban 2026 mostra a dimensão do investimento em tecnologia. O dado não prova retorno, nem preferência por uma arquitetura específica. A pergunta editorial é outra: quanto desse esforço aumenta a capacidade de entregar o próximo produto?
A pressão aparece quando uma mudança comercial exige alterações em vários canais, integrações e rotinas de operação. Um novo prazo de crédito ou uma nova condição de acesso deixa de ser uma decisão localizada e passa a disputar uma janela de entrega de toda a organização.
Referência: Febraban · Pesquisa de Tecnologia Bancária 2026 ↗
Escolha uma fronteira de negócio
Um recorte útil pode ser a simulação de uma proposta, a verificação de identidade ou a formalização. Ele precisa ter entrada, saída, responsável e resultado observável. Escolher uma capacidade só porque é simples de extrair pode produzir uma API nova sem melhorar o trabalho de ninguém.
Considere uma instituição que apresenta condições diferentes no app, no portal do parceiro e na mesa. Concentrar o cálculo em uma capacidade com contrato explícito cria um lugar para discutir a regra. Os canais continuam distintos, mas consomem a mesma responsabilidade.
A convivência é parte da solução
A migração precisa definir onde está o dado oficial, quais operações podem ser repetidas e como comparar respostas. Durante a transição, executar cálculos em paralelo pode ajudar a encontrar diferenças antes de encaminhar tráfego real. Operações que movimentam dinheiro exigem outro cuidado: repetir uma chamada não pode repetir o efeito.
Uma fronteira modular não elimina acoplamento por si só. Versões, tratamento de falhas e compatibilidade precisam ser combinados com os consumidores. Quando uma capacidade ganha muitos usuários, uma mudança mal governada pode ampliar o impacto em vez de reduzi-lo.
Quando compartilhar — e quando preservar a diferença
Há reúso quando dois produtos precisam da mesma responsabilidade e aceitam um contrato comum. Há apenas semelhança superficial quando nomes iguais escondem regras, ciclos de vida ou exigências diferentes. Forçar ambos para uma única implementação tende a transformar parâmetros em exceções difíceis de entender.
A proposta é compartilhar o fundamento e manter explícito o contexto. Banking, crédito e recebíveis podem reutilizar identidade e documentos sem compartilhar a mesma política de aprovação. A arquitetura precisa permitir essa diferença.
A regra mudou. Quem precisa mudar junto?
App, portal e mesa mantêm sua própria interpretação. A mesma alteração precisa percorrer três implementações e três agendas de entrega.
Uma simulação, três experiências
Exemplo de desenho: app do cliente, portal do parceiro e mesa consomem cálculo e precificação. Cada canal organiza sua interface; política, parâmetros e versão permanecem identificáveis na base. A migração começa por uma modalidade, com comparação de resultados e plano de retorno.
Prazo de mudança
Tempo entre a regra aprovada e sua chegada aos canais.
Duplicação
Quantas implementações da mesma regra ainda precisam mudar juntas.
Qualidade operacional
Divergências de resultado, falhas e esforço de reconciliação.
Três perguntas
antes de construir.
- Qual regra hoje precisa ser alterada em mais de um lugar?
- Existe uma modalidade pequena o suficiente para validar a transição?
- Quem responde pelo contrato depois que o segundo produto passar a usá-lo?
Da leitura
à composição.
Na Catalisa, portfólio, cálculo, precificação e decisão são responsabilidades que podem compor jornadas de crédito. A seleção depende do contrato e do estágio de cada capacidade; o catálogo não dispensa validação de integração.
O que sustenta
esta leitura.
O framework britânico usa probabilidade e impacto para priorizar risco de legado. Ele serve aqui como referência de análise, não como exigência para bancos brasileiros nem como recomendação de uma arquitetura específica.
- Febraban · Pesquisa de Tecnologia Bancária 2026 ↗26 jun 2026 · transações: ano-base 2025; orçamento: projeção 2026
- GOV.UK · Avaliação de risco de sistemas legados ↗Atualizado em 17 ago 2026 · referência do setor público britânico
