Modernizing regulatory technology without replacing everything at once

Most regulatory modernization programmes are framed as replacement programmes: a list of systems to retire and a list of systems to buy.

That framing can create unnecessary cost, implementation risk, long timelines and organizational resistance — and it is often the wrong starting point.

Many regulators do not need to replace every application they operate. Licensing systems, filing portals, case-management tools, document repositories, workflow platforms and reporting warehouses can each work adequately on their own while the wider environment remains fragmented. The problem is frequently not that a given component is obsolete. It is that these components do not operate as one coherent system.

Regulatory modernization does not require replacing everything at once. A stronger approach is to identify the operating capabilities that matter most, connect existing systems around a coherent data and workflow architecture, modernize high-friction components in stages, and replace technology only where the existing environment genuinely prevents the target operating model.

That is not an argument against modernization. It is an argument for modernizing deliberately rather than indiscriminately.

1. Start with the operating capability, not the application inventory

“What systems should we replace?” is frequently the wrong first question, because it starts from the technology estate rather than from the operation the regulator wants to run.

A recent Bank for International Settlements Financial Stability Institute (FSI) paper on suptech’s evolution observes that financial authorities have pursued technology adoption through varied paths — dedicated roadmaps, institution-wide digital transformation initiatives and innovation labs among them — but that practical applications concentrate where the operating need is clearest, such as misconduct detection, reporting and data administration. The starting point, in other words, tends to be an operating problem, not an inventory of ageing applications.

2. Separate systems that must change from systems that merely need to connect

A useful modernization plan sorts the existing estate into three groups, and treats each differently.

These categories are not permanent. A system in “modernize around” today may move to “replace” once its constraints become clearer, or once a genuinely better alternative exists. The categorization is a planning tool, not a one-time verdict.

3. Build the connective architecture first

Once the estate is sorted, the highest-leverage early investment is usually not a new application. It is the shared layer that lets existing and future systems work together: identity and access, an integration and API layer, master and reference data, stable entity identifiers, workflow orchestration, document and content integration, reliable data movement between systems, shared reporting and analytics, and a consistent audit trail.

The goal is not to build a large technical platform programme for its own sake. It is to reduce the number of isolated, point-to-point integrations that accumulate — often invisibly — every time two systems need to exchange information. This is closely related to the case for an entity-centric supervisory system of record: the connective layer is what makes it possible for information, work and decision history to stay resolved back to the entity they describe, without requiring every source system to be replaced first.

A World Bank technical note on suptech solutions for market conduct supervision documents this pattern directly. In one central bank’s case, a middleware layer was introduced specifically to give supervised institutions’ existing databases — regardless of vendor — a common, readable path into a central data warehouse, “adapt[ing] data from different types of databases into a common readable format.” The warehouse was deliberately designed to “break down internal data siloes,” integrating with the national payments system, credit reference data and statistics functions that already existed. Nothing supervised institutions ran day-to-day had to be replaced for the authority to gain a connected view.

4. Modernize the highest-friction journeys first

With a connective layer in place, modernization can proceed journey by journey rather than system by system. Candidates typically include licensing and authorization journeys, regulatory filing intake, case handoffs between teams, document requests, supervisory reviews, approval workflows, data reconciliation and management reporting.

A good first phase tends to share four traits: it matters operationally, the friction is visible to staff and regulated entities alike, it crosses at least one system boundary, and it leaves behind reusable architecture — an API, a workflow pattern, a reporting pipeline — that the next phase can build on. A phase chosen only because it is easy, with none of these traits, rarely compounds into a programme; it is a project that ends when it ends.

The same FSI paper on suptech’s evolution notes that current implementations concentrate in a narrow set of high-value use cases rather than spreading thin across the estate — consistent with sequencing modernization by where the operating friction, and the reusable value, is greatest.

5. Design migration as a transition architecture, not a one-time cutover

During any multi-phase modernization, old and new systems will operate side by side for a period — sometimes a long one. That coexistence needs to be designed, not merely tolerated.

Deliberate coexistence requires explicit decisions about which system is the system of record for a given fact, how data stays synchronized between old and new, who owns each dataset, where audit history lives, where documents are stored, how duplicate entry is avoided, what the fallback path is if a new component fails, and what conditions have to be met before a legacy component is finally retired.

Unmanaged coexistence becomes permanent complexity. Managed coexistence becomes a migration strategy.

The World Bank note referenced above frames this as an enablement problem as much as a technical one: implementing a suptech solution “requires making investments in three key enablers: people, process, and IT infrastructure.” In its central data warehouse case study, staff accustomed to existing data-management routines initially met the change with skepticism and needed retraining to work as business analysts rather than manual data handlers — a reminder that a transition architecture has an operational dimension alongside its technical one.

6. Use replacement where it creates real strategic value

None of this is an argument that replacement is never the right decision. There are cases where it clearly is: technology that is no longer supported, a security or resilience concern that cannot be mitigated in place, a system that cannot practically be integrated at all, data structures too inconsistent to trust, licensing terms that constrain the organization, or an architecture that blocks services the regulator needs to offer.

Do not preserve legacy technology merely because replacing it is difficult. Replace deliberately, where replacement materially improves the target operating model — and connect, modernize around, or retire in place everywhere else.

7. A practical modernization sequence

The approach above can be summarized as a repeatable sequence rather than a single large programme.

Each step feeds the next. A regulator that connects before it modernizes, and modernizes before it replaces, spends its scarcest resource — organizational attention — on the changes that compound rather than the changes that merely relocate the same fragmentation into new systems.

Practical implications

A regulator assessing its own modernization plan can use a short set of internal questions:

1. Which existing systems genuinely prevent the operating model we want, and which are simply isolated?
2. Where are staff manually bridging systems today, and what would a shared integration layer remove?
3. What should become shared infrastructure — identity, data, workflow — rather than being rebuilt inside every project?
4. Which modernization phase creates reusable capability for the phase after it?
5. What explicit criteria will determine when a legacy system is finally retired, rather than indefinitely kept “for now”?

These questions do not resolve on their own. But they tend to produce a materially different programme than the one that starts from a list of systems to replace — often a faster, less disruptive and less expensive one, built around the operation the regulator actually needs to run day to day, such as the connected view described in the modern supervisory system of record, the workflow automation that carries work between systems, or the reporting and decision intelligence that depends on both.

Sources & further reading

1. The suptech generations — Financial Stability Institute, FSI Insights 19 (2019)
2. From data reporting to data-sharing: how far can suptech and other innovations challenge the status quo of regulatory reporting? — Financial Stability Institute, FSI Insights 29 (2020)
3. The Next Wave of Suptech Innovation: Suptech Solutions for Market Conduct Supervision — World Bank (2021)

External references are cited for context. No endorsement of Amayztech by the BIS, the Financial Stability Institute or the World Bank is implied.