Como DTVMs e CTVMs podem modernizar plataformas sem interromper a operação 

Em instituições financeiras, modernizar tecnologia não significa apenas substituir linguagens antigas ou migrar aplicações para a nuvem. Para DTVMs e CTVMs, o desafio é transformar plataformas que sustentam operações críticas (como cadastro, ordens, posições, liquidação, conciliação, controles de risco e reportes regulatórios) sem comprometer a disponibilidade, a integridade dos dados ou a conformidade da instituição.

A pressão por essa evolução aumenta à medida que o mercado financeiro se torna mais digital. Segundo a Pesquisa Febraban de Tecnologia Bancária 2026, 83% das transações bancárias já são realizadas em canais digitais. O levantamento também estima que os investimentos dos bancos brasileiros em tecnologia chegarão a R$ 50,4 bilhões em 2026, um crescimento de 58% em cinco anos. Cibersegurança aparece como prioridade para 100% das instituições participantes, enquanto cloud e inteligência artificial generativa são consideradas protagonistas no orçamento por 84% delas.

Embora os dados retratem o setor bancário, eles indicam uma transformação que alcança todo o ecossistema financeiro. DTVMs e CTVMs precisam ampliar sua capacidade de integração, responder a novas exigências de negócio e fortalecer controles de segurança, auditoria e rastreabilidade. O problema é que muitas dessas instituições ainda dependem de plataformas construídas ao longo de anos, com regras críticas incorporadas ao código, integrações complexas e pouca margem para indisponibilidade.

Nesse cenário, uma substituição integral, feita de uma única vez, pode representar um risco tão relevante quanto permanecer no legado. Por isso, a modernização incremental surge como uma alternativa mais segura: em vez de interromper a operação para trocar toda a plataforma, a instituição evolui componentes de forma gradual, mantém sistemas antigos e novos operando em paralelo e valida cada etapa antes de avançar. Assim, é possível reduzir riscos técnicos e regulatórios sem transformar a modernização em uma aposta de “tudo ou nada”.

O que caracteriza um sistema legado em DTVMs e CTVMs?

Um sistema não se torna legado apenas por ser antigo. Ele passa a representar um problema quando limita a evolução do negócio, aumenta o risco operacional ou depende de tecnologias e conhecimentos difíceis de manter.

Em DTVMs e CTVMs, os principais sinais são:

• regras críticas concentradas em aplicações monolíticas;
• integrações frágeis ou realizadas por troca de arquivos e processos manuais;
• baixa cobertura de testes automatizados;
• documentação incompleta;
• dependência de profissionais que detêm conhecimento não registrado;
• dificuldade para rastrear alterações e reconstruir operações;
• atualizações que exigem longas janelas de indisponibilidade;
• demora para atender novas regras regulatórias ou lançar produtos.

É possível, portanto, que uma plataforma antiga continue adequada, desde que seja estável, segura, documentada e capaz de evoluir. O problema não é a idade do sistema, mas a distância entre o que ele entrega e o que a instituição precisa controlar, integrar e escalar.

Por que instituições financeiras adiam a modernização de sistemas críticos? (h2)

A principal razão é o risco percebido. Plataformas críticas acumulam regras de negócio, exceções operacionais e integrações construídas ao longo de anos. Nem sempre esse conhecimento está documentado, o que dificulta prever o impacto de uma mudança.

Também existe o receio de interromper processos como negociação, registro, custódia, liquidação, conciliação ou reporte. Quando o sistema funciona, mesmo com limitações, a manutenção parece mais segura do que uma transformação estrutural.

O adiamento, entretanto, transfere o custo para o futuro. A instituição continua investindo em correções emergenciais, atividades manuais e profissionais especializados em tecnologias cada vez menos disponíveis. Ao mesmo tempo, perde velocidade para responder ao mercado e às exigências regulatórias.

A decisão correta não é escolher entre “trocar tudo” e “não mexer”. É criar uma sequência de mudanças pequenas, controladas e mensuráveis.

Quais riscos regulatórios um sistema legado cria para DTVMs e CTVMs? (h2)

O uso de um sistema antigo não representa, por si só, uma irregularidade. O risco aparece quando a plataforma compromete a capacidade da instituição de cumprir e demonstrar seus controles.

Entre os principais pontos de atenção estão:

• inconsistências em posições, saldos e conciliações;
• ausência de trilhas de auditoria completas;
• controles de acesso incompatíveis com a segregação de funções;
• dificuldade para proteger dados e corrigir vulnerabilidades;
• indisponibilidade de processos essenciais;
• falhas ou atrasos nos reportes;
• baixa capacidade de reconstruir decisões, ordens e movimentações;
• dependência de procedimentos manuais sem evidências suficientes.

A Resolução CVM 35, aplicável aos intermediários, estabelece responsabilidades relacionadas a regras, procedimentos, controles internos, segurança da informação e continuidade dos negócios. Já a Resolução CMN 4.893 trata da política de segurança cibernética e dos requisitos para serviços de processamento e armazenamento de dados.

Nesse contexto, modernizar não é somente melhorar desempenho. É ampliar rastreabilidade, resiliência e capacidade de produzir evidências para auditorias, fiscalizações e controles internos.

O que é modernização incremental e como aplicá-la a sistemas críticos?

Modernização incremental é a evolução da plataforma por partes, sem depender de uma substituição integral para gerar resultados. A instituição identifica um domínio funcional, reduz seu acoplamento ao restante do sistema e transfere gradualmente suas responsabilidades para uma arquitetura mais atual.

A execução pode combinar diferentes estratégias:

• encapsular funcionalidades legadas por meio de APIs;
• substituir módulos com maior risco ou custo de manutenção;
• extrair serviços específicos de uma aplicação monolítica;
• automatizar testes e processos operacionais;
• modernizar interfaces sem alterar imediatamente o núcleo;
• migrar cargas selecionadas para ambientes de nuvem;
• reorganizar dados e integrações antes de substituir aplicações.

A prioridade deve ser definida pelo equilíbrio entre risco, valor e viabilidade. Um componente instável, responsável por gargalos operacionais e com baixo nível de integração pode ser um candidato melhor do que o maior sistema da instituição.

“Modernizar uma plataforma crítica não significa trocar todo o sistema de uma vez. Significa criar uma evolução segura, em que cada etapa reduz riscos, entrega valor ao negócio e prepara a instituição para o próximo movimento.” — Jorge Sellmer, CRO da Objective

Como fazer o sistema legado e o sistema novo operarem em paralelo?

A convivência entre os dois ambientes exige uma definição clara sobre qual sistema é responsável por cada dado e processo. Sem essa governança, a operação paralela pode gerar duplicidades e divergências.

Uma abordagem segura começa com a criação de uma camada de integração. APIs, eventos ou mecanismos controlados de replicação permitem que o novo componente receba dados do legado sem depender diretamente de sua estrutura interna.

Durante a transição, a instituição pode executar o mesmo processamento nos dois sistemas e comparar os resultados. Essa prática, conhecida como shadow mode, permite validar cálculos, regras e integrações antes de transferir a operação. A mudança definitiva deve ocorrer somente após critérios objetivos de aceitação, como volume processado, taxa de divergência, desempenho e estabilidade.

Também é necessário definir:

• fonte oficial de cada informação;
• rotina de conciliação entre os ambientes;
• monitoramento em tempo real;
• plano de reversão;
• responsáveis por incidentes;
• evidências de testes e aprovações.

Um exemplo próximo dessa estratégia está no case de modernização de sistemas para uma empresa de benefícios e incentivos. A Objective adotou uma arquitetura modular baseada em microsserviços, permitindo que as camadas fossem ajustadas e atualizadas de forma independente, com menor impacto sobre a disponibilidade.

Quanto tempo leva e quanto custa uma modernização gradual?

Não existe um prazo único, porque a duração depende do volume de regras, da qualidade do código, da documentação, das integrações e do nível de risco aceitável. Como referência inicial:

• diagnóstico e definição do roadmap: de quatro a oito semanas;
• piloto ou modernização do primeiro domínio: de três a seis meses;
• evolução de uma plataforma crítica: de 12 a 36 meses, realizada em ondas.

Esses prazos são indicativos e devem ser confirmados após uma avaliação técnica e operacional.

O custo também não deve ser calculado apenas pelo número de aplicações. Os principais componentes são as equipes envolvidas, a complexidade das integrações, a preparação dos dados, a automação de testes, a infraestrutura e os requisitos de segurança e conformidade.

Em vez de aprovar antecipadamente um programa extenso e fechado, a instituição pode financiar a modernização por etapas. Cada onda deve ter orçamento, entregáveis e indicadores próprios. Isso facilita a revisão das prioridades e reduz o risco de investir por anos antes de obter benefícios.

A análise financeira também precisa considerar o custo de não modernizar: incidentes, indisponibilidade, retrabalho, controles manuais, vulnerabilidades e demora para adaptar produtos ou exigências regulatórias.

Por onde começar a modernizar uma plataforma que não pode parar?

O primeiro passo é realizar um diagnóstico que una tecnologia, operação, risco e negócio. O objetivo não é apenas mapear aplicações, mas compreender quais processos dependem delas e qual seria o impacto de uma falha.

Esse diagnóstico deve identificar:

• processos e sistemas realmente críticos;
• dependências e integrações;
• regras de negócio sem documentação;
• vulnerabilidades e tecnologias sem suporte;
• controles manuais e pontos de reconciliação;
• requisitos de disponibilidade e recuperação;
• componentes com melhor relação entre valor e complexidade.

A partir desse mapa, a instituição pode selecionar um domínio limitado para a primeira onda. O ideal é escolher um componente relevante o suficiente para demonstrar resultado, mas com escopo controlável e possibilidade de reversão.

O case da seguradora multinacional ilustra esse princípio. Antes da implementação, a Objective analisou o sistema e as necessidades do negócio, identificando 159 atualizações. O trabalho envolveu módulos críticos, como financeiro, contábil, comissões, relatórios, trilhas de auditoria e acessos, além da centralização gradual de operações antes distribuídas entre diferentes plataformas.

Modernizar sem interromper a operação depende menos de uma grande troca tecnológica e mais da capacidade de organizar a transição. Com diagnóstico, arquitetura adequada, testes, conciliação e governança, DTVMs e CTVMs podem reduzir a dependência do legado enquanto preservam a continuidade e os controles exigidos pelo mercado financeiro.

Sua DTVM ou CTVM precisa modernizar uma plataforma sem colocar a operação em risco? Entre em contato com os especialistas da Objective e descubra como estruturar uma jornada gradual, segura e alinhada às necessidades do negócio e às exigências regulatórias.

Perguntas frequentes sobre o tema