How DTVMs and CTVMs can modernize platforms without interrupting operations

In financial institutions, modernizing technology does not just mean replacing old languages or migrating applications to the cloud. For DTVMs and CTVMs, the challenge is to transform platforms that support critical operations (such as registration, orders, positions, settlement, reconciliation, risk controls, and regulatory reporting) without compromising availability, data integrity, or the institution’s compliance.

The pressure for this evolution increases as the financial market becomes more digital. According to the Febraban Banking Technology Survey 2026, 83% of banking transactions are already conducted through digital channels. The survey also estimates that Brazilian banks’ investments in technology will reach R$ 50.4 billion by 2026, a growth of 58% over five years. Cybersecurity appears as a priority for 100% of participating institutions, while cloud and generative artificial intelligence are seen as key players in the budget by 84% of them.

Although the data reflects the banking sector, it indicates a transformation that reaches the entire financial ecosystem. DTVMs and CTVMs need to expand their integration capabilities, respond to new business requirements, and strengthen security, audit, and traceability controls. The problem is that many of these institutions still rely on platforms built over the years, with critical rules embedded in the code, complex integrations, and little margin for downtime.

In this scenario, a complete one-time replacement can pose a risk just as significant as staying on legacy systems. Therefore, incremental modernization emerges as a safer alternative: instead of halting operations to swap out the entire platform, the institution gradually evolves components, keeps old and new systems running in parallel, and validates each step before proceeding. This way, it’s possible to reduce technical and regulatory risks without turning modernization into a “all or nothing” gamble.

What characterizes a legacy system in DTVMs and CTVMs?

A system doesn’t become legacy simply because it’s old. It starts to represent a problem when it limits business evolution, increases operational risk, or relies on difficult-to-maintain technologies and knowledge.

In DTVMs and CTVMs, the main signs are:

• critical rules concentrated in monolithic applications;
• fragile integrations or those performed through file exchanges and manual processes;
• low coverage of automated tests;
• incomplete documentation;
• dependence on professionals who have undocumented knowledge;
• difficulty in tracking changes and reconstructing operations;
• updates that require long downtime windows;
• delays in meeting new regulatory rules or launching products.

It is possible, therefore, for an old platform to remain suitable as long as it is stable, secure, well-documented, and capable of evolving. The issue is not the age of the system, but the gap between what it delivers and what the institution needs to control, integrate, and scale.

Why do financial institutions delay the modernization of critical systems?

The main reason is perceived risk. Critical platforms accumulate business rules, operational exceptions, and integrations built over the years. This knowledge is not always documented, making it difficult to foresee the impact of a change.

There is also fear of interrupting processes such as trading, registration, custody, settlement, reconciliation, or reporting. When the system works, even with limitations, maintenance seems safer than a structural transformation.

However, delaying transfers the cost to the future. The institution continues to invest in emergency fixes, manual activities, and professionals specialized in increasingly unavailable technologies. At the same time, it loses speed in responding to the market and regulatory requirements.

The correct decision is not to choose between “swap everything” and “leave it alone.” It is to create a sequence of small, controlled, and measurable changes.

What regulatory risks does a legacy system create for DTVMs and CTVMs?

Using an old system does not in itself represent an irregularity. The risk arises when the platform compromises the institution’s ability to comply with and demonstrate its controls.

Key points of attention include:

• inconsistencies in positions, balances, and reconciliations;
• absence of complete audit trails;
• access controls incompatible with segregation of duties;
• difficulties in protecting data and fixing vulnerabilities;
• unavailability of essential processes;
• failures or delays in reporting;
• low capacity to reconstruct decisions, orders, and transactions;
• dependence on manual procedures without sufficient evidence.

The CVM Resolution 35, applicable to intermediaries, establishes responsibilities related to rules, procedures, internal controls, information security, and business continuity. Meanwhile, CMN Resolution 4,893 addresses cybersecurity policy and requirements for processing and data storage services.

In this context, modernizing is not just about improving performance. It’s about enhancing traceability, resilience, and the ability to produce evidence for audits, regulatory inspections, and internal controls.

What is incremental modernization and how to apply it to critical systems?

Incremental modernization is the evolution of the platform by parts, without relying on a complete replacement to achieve results. The institution identifies a functional domain, reduces its coupling to the rest of the system, and gradually transfers its responsibilities to a more current architecture.

Execution can combine different strategies:

• encapsulating legacy functionalities through APIs;
• replacing modules with higher risk or maintenance costs;
• extracting specific services from a monolithic application;
• automating tests and operational processes;
• modernizing interfaces without immediately altering the core;
• migrating selected workloads to cloud environments;
• reorganizing data and integrations before replacing applications.

Priority should be defined by the balance between risk, value, and feasibility. An unstable component that causes operational bottlenecks and has a low level of integration may be a better candidate than the institution’s largest system.

“Modernizing a critical platform does not mean swapping out the entire system at once. It means creating a secure evolution, where each step reduces risks, delivers value to the business, and prepares the institution for the next move.” — Jorge Sellmer, CRO of Objective

How to run the legacy system and the new system in parallel?

The coexistence of the two environments requires a clear definition of which system is responsible for each data and process. Without this governance, parallel operation can generate duplicities and discrepancies.

A safe approach begins with the creation of an integration layer. APIs, events, or controlled replication mechanisms allow the new component to receive data from the legacy system without directly depending on its internal structure.

During the transition, the institution can execute the same processing in both systems and compare the results. This practice, known as shadow mode, allows for the validation of calculations, rules, and integrations before transferring the operation. The definitive change should only occur after objective acceptance criteria, such as processed volume, divergence rate, performance, and stability, are met.

It is also necessary to define:

• the official source of each piece of information;
• reconciliation routine between the environments;
• real-time monitoring;
• reversion plan;
• incident responsibilities;
• evidence of tests and approvals.

A nearby example of this strategy is in the case of system modernization for a benefits and incentives company. Objective adopted a modular architecture based on microservices, allowing layers to be adjusted and updated independently, with less impact on availability.

How long does gradual modernization take and what does it cost?

There is no single timeframe, as duration depends on the volume of rules, code quality, documentation, integrations, and the acceptable level of risk. As a starting reference:

• diagnosis and roadmap definition: four to eight weeks;
• pilot or modernization of the first domain: three to six months;
• evolution of a critical platform: 12 to 36 months, conducted in waves.

These timelines are indicative and should be confirmed after a technical and operational assessment.

Costs should not only be calculated based on the number of applications. The main components are the teams involved, the complexity of integrations, data preparation, test automation, infrastructure, and security and compliance requirements.

Instead of approving a large, closed program up front, the institution can finance modernization in stages. Each wave should have its own budget, deliverables, and indicators. This makes it easier to review priorities and reduces the risk of investing for years before seeing benefits.

Financial analysis must also consider the cost of not modernizing: incidents, downtime, rework, manual controls, vulnerabilities, and delays in adapting products or regulatory demands.

Where to start modernizing a platform that cannot stop?

The first step is to conduct a diagnosis that integrates technology, operations, risk, and business. The goal is not just to map applications but to understand which processes depend on them and what the impact of a failure would be.

This diagnosis should identify:

• truly critical processes and systems;
• dependencies and integrations;
• business rules without documentation;
• vulnerabilities and unsupported technologies;
• manual controls and reconciliation points;
• availability and recovery requirements;
• components with a better balance between value and complexity.

Based on this map, the institution can select a limited domain for the first wave. Ideally, it should choose a component significant enough to demonstrate results, but with a controlled scope and the possibility of reversal.

The case of the multinational insurer illustrates this principle. Before implementation, Objective analyzed the system and business needs, identifying 159 updates. The work involved critical modules, such as finance, accounting, commissions, reports, audit trails, and access, in addition to the gradual centralization of operations previously distributed among different platforms.

Modernizing without interrupting operations relies less on a big technological swap and more on the ability to organize the transition. With diagnosis, proper architecture, testing, reconciliation, and governance, DTVMs and CTVMs can reduce reliance on legacy systems while maintaining continuity and controls required by the financial market.

Does your DTVM or CTVM need to modernize a platform without jeopardizing operations? Contact the Objective specialists and find out how to structure a gradual, safe journey that aligns with business needs and regulatory requirements.

Frequently asked questions on the subject