Insight · Regulatory Technology

The modern supervisory system of record: what should actually be connected?

Regulatory information becomes significantly more useful when licences, filings, obligations, supervisory work, cases and decision history remain connected around the regulated entity.

Diagram: the regulated entity at the centre, connected to identity and relationships, authorization, obligations, filings, supervisory activity, findings and cases, documents and correspondence, decisions, and risk and intelligence.

Financial supervisors rarely experience their work as a collection of separate systems.

An application becomes a licence. A licence creates obligations. Obligations generate filings. Filings raise questions. Questions create supervisory work. Supervisory work can become a finding, a case, a remediation requirement or a formal decision. Years later, someone may need to understand not only what information was received, but what the authority knew at the time, what it did, and why.

Technology often tells a different story.

Licensing may live in one system, regulatory returns in another, documents somewhere else, casework in a workflow platform, correspondence in email, and management reporting in a data warehouse assembled after the fact. Each system may work adequately on its own while the supervisory picture remains fragmented.

That fragmentation matters because supervision depends on context.

A recent Financial Stability Institute study on supervisory information systems found that integration remains uneven across authorities, with almost half of surveyed authorities still operating fragmented systems. Among more integrated authorities, the study observes a move toward entity-centric platforms — organizing supervisory information around the institution being supervised rather than around individual applications or technologies.

That direction is important.

But an entity-centric supervisory environment is not simply a database with more tables, and it is not necessarily a single replacement platform. The more useful question is:

What information, work and decision history should remain connected around the regulated entity so that supervisors can understand context and act with confidence?

That is the question a modern supervisory system of record should answer.

What matters

A useful supervisory system of record should do three things:

  1. Keep regulatory information connected to the entity and relationships it describes.
  2. Keep information connected to the supervisory work and decisions it creates.
  3. Preserve enough history to explain what changed, who acted and why.

1. Start with the regulated entity, not the application

Many regulatory systems are built around transactions.

There is an application system for licensing. A filing system for returns. A case system for enforcement or supervision. A document repository. Perhaps a complaints system. Each captures an event or work type.

The supervisor, however, often needs to ask a different kind of question:

What do we know about this entity?

That question can require information from several systems at once.

A useful regulated-entity record may need to bring together:

  • legal identity and trading names;
  • licence and authorization history;
  • business activities and permissions;
  • key people, controllers and relationships;
  • regulatory obligations;
  • filings and returns;
  • supervisory reviews and interactions;
  • open findings, issues and remediation;
  • cases or investigations;
  • correspondence and documents;
  • risk indicators;
  • material decisions and their history.

This does not mean every piece of data must physically live in one application.

It means the operating environment needs a dependable way to resolve those records back to the entity they describe.

That distinction is important.

Entity-centric does not have to mean monolithic.

2. Licensing should remain connected after approval

Licensing systems are often treated as front-door systems: receive an application, complete review, issue a decision.

But the regulatory significance of that information does not end when the licence is approved.

The application may establish:

  • ownership;
  • directors and officers;
  • approved activities;
  • conditions;
  • business models;
  • jurisdictions;
  • financial information;
  • supporting documents;
  • representations made by the applicant.

Those facts can become relevant to later supervision.

If a key person changes, if a business line expands, if an obligation is missed or if a supervisor reviews the firm two years later, the authority benefits from being able to see the relationship between the original authorization, subsequent changes and the current regulated state.

A modern record therefore treats licensing as the beginning of the regulated relationship, not the end of an application workflow.

ApplicationAuthorizationRegulated entityOngoing obligationsSupervision

The record should survive the transition between each stage.

3. Obligations and filings need more than a submission history

Digital filing is a major improvement over email and paper, but a portal alone does not create supervisory context.

A filing becomes more useful when the authority can answer:

  • Why was this filing required?
  • Which regulated entity and licence does it relate to?
  • Was it submitted on time?
  • Did it pass validation?
  • Were there previous exceptions?
  • Did the submission create a supervisory task?
  • Was additional information requested?
  • Was the matter resolved?
  • Did the filing affect the entity’s risk view?

This is the difference between receiving regulatory information and operating with regulatory information.

The World Bank and Financial Stability Institute have both documented how supervisory technology is changing data collection, validation, integration and analysis. Better collection can improve timeliness, granularity and quality. But the operating value increases further when the information can be connected to the work that follows.

A filing should not become a dead record after submission.

Where appropriate, it should become part of the entity’s ongoing supervisory history.

4. Supervisory work needs state, ownership and evidence

A supervisory record is not only a collection of facts.

It is also a record of work.

For consequential regulatory activity, the authority may need to know:

  • what required attention;
  • who owned the work;
  • what stage it reached;
  • what evidence was considered;
  • which questions were raised;
  • what responses were received;
  • what decision was made;
  • what follow-up was required;
  • whether the matter was closed or remains open.

This is where workflow becomes part of the supervisory architecture.

A document repository can show that a file exists.

A data warehouse can show that a metric changed.

Neither, by itself, necessarily shows the operational state of the supervisory response.

That state matters because oversight is not only about what the authority knows. It is also about what the authority is doing with what it knows.

5. Cases, findings and decisions should not become isolated endpoints

When supervisory work becomes more formal, many organizations move it into a dedicated case or investigation system.

That can be appropriate. The problem appears when the case becomes disconnected from the wider entity history.

A finding may have originated from:

  • a late or unusual filing;
  • an inspection;
  • a complaint;
  • a licence condition;
  • correspondence;
  • a change in ownership;
  • a risk indicator;
  • another supervisory review.

If the resulting case is stored separately with no meaningful relationship back to those originating signals, the authority loses part of the story.

The system of record should therefore preserve lineage:

SignalReviewFindingActionDecisionFollow-up

Not every regulator will use those exact stages. The principle is that material supervisory actions should be traceable to the context that produced them.

That traceability becomes particularly valuable when staff change, cases span long periods, or leadership needs to understand why an action was taken.

6. Documents matter, but context matters more

Regulation remains document-heavy.

Applications, audited statements, policies, returns, correspondence, inspection material, legal documents and evidence all matter.

A modern document platform can improve storage, search, retention and access. But documents become significantly more useful when the system knows what they relate to.

For example:

  • this document was submitted for this obligation;
  • by this entity;
  • for this reporting period;
  • reviewed as part of this supervisory activity;
  • resulting in this request;
  • and ultimately associated with this decision.

That relationship can be more useful than the folder in which the document happens to sit.

The architectural goal is therefore not to eliminate document-management systems. It is to make document context available to the regulatory work around them.

7. A data warehouse is important — but it is not the supervisory record

Regulatory modernization programmes often place major emphasis on data warehousing, analytics and dashboards. They should.

Supervisors need cross-entity analysis, trend detection, risk indicators, management reporting and the ability to work with historical and market-wide data.

But an analytical environment and an operational supervisory record solve different problems.

Analytical environment

  • What is happening across the market?
  • Which entities are changing?
  • Where are the exceptions?
  • What patterns deserve attention?
  • What should leadership see?

Operational supervisory record

  • What do we know about this entity?
  • What requires action?
  • Who is handling it?
  • What happened previously?
  • What evidence supports the current position?
  • What decision was made?

These environments should connect.

A risk signal identified analytically should be able to inform supervisory work. Supervisory outcomes should, where appropriate, flow back into the broader data model.

But combining the two conceptually can create poor architecture.

A warehouse should not be forced to become a workflow system.

A workflow system should not be expected to become the authority’s analytical platform.

The stronger model is connected operational and analytical layers.

8. Connection is not the same as consolidation

A common modernization mistake is assuming that the only path to a connected supervisory view is to replace every existing system.

Sometimes consolidation is the right decision.

Sometimes it is not.

A regulator may already have systems that perform important functions well: document management, identity, finance, specialist analytics, case management, reporting, or sector-specific tools.

The architecture should therefore distinguish between three modernization moves:

Connect

Keep a capable existing system and make its information available in the wider regulatory context through integrations, identifiers and shared data definitions.

Modernize

Replace or rebuild a weak function while preserving the surrounding environment.

Unify

Bring multiple regulatory functions into a common platform when the operating and architectural case genuinely supports it.

The right programme may use all three.

The objective is not to maximize the number of systems replaced. It is to reduce the number of places where context is lost.

9. AI becomes more useful after the context is connected

AI is increasingly relevant to supervisory work.

Potential uses include:

  • document classification;
  • information extraction;
  • summarization;
  • comparison;
  • knowledge retrieval;
  • anomaly assistance;
  • triage;
  • pattern detection;
  • drafting support.

But AI is not a substitute for the underlying record.

In fact, fragmented context can make AI harder to govern.

If an AI-assisted process cannot reliably determine which entity, licence, reporting period, case or obligation a document belongs to, the authority may gain speed while losing confidence.

A connected supervisory record gives AI better boundaries.

It can provide:

  • known context;
  • controlled source material;
  • explicit relationships;
  • access rules;
  • work state;
  • historical decisions.

That makes it easier to define what AI is allowed to assist with and where human review remains necessary.

The Financial Stability Institute has repeatedly emphasized that suptech outputs should support, rather than replace, supervisory judgement.

The same principle should shape AI architecture.

Use AI to increase supervisory capacity. Keep consequential judgement accountable to people.

10. What should actually be connected?

A practical target model can be expressed around one central object:

Identity & relationships

Legal identity, names, ownership, controllers, key people, group relationships.

Authorization

Applications, licences, permissions, conditions, renewals, variations and history.

Obligations

What the entity is required to submit or do, when it is due and under what authority.

Filings & submissions

Returns, forms, supporting documents, validation results, reporting periods and exceptions.

Supervisory activity

Reviews, inspections, tasks, requests, assessments and interactions.

Findings & cases

Issues, breaches, investigations, remediation, actions and status.

Documents & correspondence

Evidence and communication linked to the regulatory context in which they matter.

Decisions

Approvals, refusals, conditions, escalations, closures and the history behind them.

Risk & intelligence

Indicators, analytical outputs, trends and other signals that influence supervisory attention.

That is the supervisory record.

Not one screen.

Not necessarily one product.

A connected body of regulatory context that helps the authority understand the entity, the work and the decisions around it.

11. A practical modernization sequence

Authorities do not need to solve the entire architecture in one release.

A practical sequence is:

1. Define the supervisory questions

Identify what officers and leadership need to be able to understand about an entity.

Do this before choosing the final technology pattern.

2. Establish the entity model

Agree how entities, licences, people, obligations and relationships are identified across systems.

3. Map the regulatory lifecycle

Follow the actual path from authorization through ongoing obligations, supervision, cases and decisions.

Pay particular attention to handoffs where context currently disappears.

4. Connect work to information

Ensure filings, documents, analytics and other signals can create or inform controlled supervisory activity.

5. Add intelligence deliberately

Once the underlying context is dependable, improve analytics, prioritization and AI-assisted work around it.

This sequence does not eliminate technical complexity.

It makes the complexity serve a clearer operating objective.

12. Measure the result by supervision, not by integration

A programme can connect ten systems and still leave supervisors struggling to understand what matters.

Technical integration is therefore an incomplete measure of success.

Better questions include:

  • Can an officer understand the current regulatory state of an entity without reconstructing it manually?
  • Can the authority trace a material issue from signal to action?
  • Can leadership see workload, risk and unresolved matters with confidence?
  • Can new staff understand historical decisions?
  • Can analytical insight create controlled follow-up?
  • Can the authority change a regulatory process without rebuilding the whole environment?
  • Can AI or automation be introduced without weakening accountability?

The recent FSI work on supervisory information-system integration makes a similar broader point: integration should ultimately be judged by whether it improves the effectiveness of supervision, not simply by whether the technology was deployed successfully.

That is a useful standard.

The strongest supervisory architecture is not the one with the fewest applications.

It is the one that gives the authority the clearest, most dependable context for acting on its mandate.

If you are planning a regulatory technology programme, start with the relationships

Before deciding whether to replace, integrate or consolidate systems, define the relationships that need to survive across the regulatory lifecycle: entity, licence, obligation, filing, supervisory activity, case and decision.

The architecture becomes easier to evaluate once the operating context is explicit.

  1. What should an officer be able to understand about a regulated entity without reconstructing the picture manually?
  2. Where does information currently lose its connection to the action or decision it created?
  3. Which existing systems are valuable enough to connect, and which functions genuinely need to be modernized?

Sources & further reading

  1. High expectation but low integration? Experiences in modernising and integrating information systems for supervision — Financial Stability Institute, FSI Insights 77 (2026)
  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. Suptech tools for prudential supervision and their use during the pandemic — Financial Stability Institute, FSI Insights 37 (2021)
  4. 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.

Working through a similar question?

Bring us the operating problem.

We help organizations work through the process, data and technology choices behind complex modernization programmes.

Get in touch