Machine-to-Machine Supervision: The Next Capability Is Awareness

Two clocks now run inside the financial system, and they are drifting apart.

The first is the risk clock. Depositors become concerned, information spreads, liquidity disappears. The second is the supervisory clock. Data is reported, validated, analysed. Questions are sent, responses come back, decisions are taken.

This piece is not really about APIs. It is not about AI either. It is about the gap between those two clocks, and what a supervisory authority can build to close it.

To see why the gap matters, it helps to start in 2008.

2008: the lesson was resilience

The global financial crisis did not simply prove that one Basel framework had failed. The crisis was more complex than that. What it did was expose serious weaknesses in the pre-crisis framework across capital, leverage, liquidity and risk management, and it became the catalyst for one of the largest transformations in modern banking regulation.

That transformation was Basel III. Higher and better quality capital. A leverage ratio as a backstop. And, for the first time, global liquidity standards: the Liquidity Coverage Ratio in January 2013 and the Net Stable Funding Ratio in October 2014, with the package finalised in December 2017 [1].

These reforms were necessary and the banking system is more resilient because of them. But resilience and awareness are not the same thing. A bank can meet every requirement and hold strong ratios while its actual financial condition changes quickly under stress.

So after more than a decade spent strengthening balance sheets, there is a second question worth asking. What about the information architecture that supervision runs on?

The data problem the crisis also exposed

The crisis revealed something far less visible to the public than capital shortfalls. A data problem.

When a crisis is running, management is asking a short list of urgent questions. What is our exposure to this counterparty? What is our liquidity position? What happens if this market moves? What happens if these depositors leave?

Some institutions could not answer quickly enough. The Financial Stability Institute summarised the finding plainly: certain banks took entire days, or longer, to aggregate their exposures to single counterparties [2]. In crisis conditions, that figure may be needed several times a day.

That is why the Basel Committee issued BCBS 239 in 2013, and why it still matters to any conversation about machine-to-machine supervision. The same FSI summary notes that as of the Basel Committee’s 2020 monitoring report, no G-SIB had achieved full compliance with the Principles, because the necessary data architecture and IT infrastructure remain difficult to build [2].

The implication is uncomfortable but useful. Before the regulator can become real-time, the institution itself has to become data-ready. If a bank cannot construct an accurate picture of its own risk quickly, no API solves that. No AI model solves that. No dashboard solves that.

So the first principle of machine-to-machine supervision is not machines. It is trustworthy, standardised, timely data.

2023: the lesson was speed

In the fifteen years after the crisis, finance itself changed. Payments became instant. Banking moved onto phones. Information started travelling globally in seconds. Confidence can now shift in an afternoon, and deposits can move at a pace that was previously hard to imagine.

In March 2023, Silicon Valley Bank showed what that means in practice.

The underlying vulnerabilities did not appear overnight. Interest rate risk. Liquidity risk. A highly concentrated depositor base. A large share of uninsured deposits. Those developed over quarters.

The ending did not. The sequence, as set out in the Federal Reserve’s April 2023 review:

• 8 March 2023: SVB announced a balance sheet restructuring and an intention to raise capital [3].

• 9 March 2023: deposit outflows of more than $40 billion in a single day. California’s DFPI review puts the withdrawal requests at roughly $42 billion within about eight hours, close to 25% of SVB’s approximately $166 billion of total deposits [5].

• 10 March 2023: management expected over $100 billion more to leave that day. Actual and expected outflows together represented roughly 85% of the bank’s deposit base [4]. The bank was closed.

Roughly 48 hours from announcement to closure.

Bank runs are not new. Loss of confidence is not new. Liquidity risk is not new. What changed was speed, and with it the amount of time available to see the problem and act on it.

Supervisory latency

Back to the two clocks.

Nothing on the supervisory clock is wasteful. Collection, validation, analysis, the question to the institution, the response, the decision. Each step exists because somebody needed it. But each step also takes time, and the sum of those steps is what you might call supervisory latency: the distance between an event occurring inside an institution and a supervisor being in a position to act on it.

The question worth sitting with is simple. What happens when the first clock runs much faster than the second?

This is not an argument for collecting everything, constantly, because the technology allows it. Different risks move at different speeds. Capital adequacy does not change hour to hour. Liquidity can. Market risk can. Concentration can shift faster than a quarterly return will show.

So the useful question is not whether all reporting can become real-time. It is whether supervisory systems can keep pace with the specific risks that move fastest. That is a narrower objective, and a far more achievable one.

Can an always-on system be supervised through periodic snapshots?

Today most regulatory information still travels a long supply chain. Source systems inside the institution. Internal extraction. A reporting template. Manual review. A file. An upload. Receipt. Validation. Follow-up on errors. Resubmission. Aggregation. Only then does somebody ask the supervisory question.

Every hand-off in that chain can introduce three things: time, complexity and inconsistency.

And when a new supervisory question appears that the original template was never designed to answer, the usual answer is another collection exercise. The data is fitted to specific use cases, which makes it hard to reuse when the analytical question changes.

A report is a snapshot. It tells you something genuinely valuable about a defined point or period, and formal reporting is not going anywhere. Financial statements will not disappear. Regulatory submissions will not disappear.

But consider what it is like to understand a film through screenshots taken every three minutes. Every image can be perfectly accurate. The problem is everything that happened in between.

So perhaps the question is not whether reporting survives. It is whether the supervisor needs the report, or the information behind the report, and whether there is a way to ask for the second when a situation calls for it.

Stop collecting answers. Build the data.

Simplified, the current pattern looks like this. Take data, produce Report A. Take data, produce Report B. Then Report C. Each report carries its own definitions, its own transformation, its own mapping, its own validation, and sometimes a slightly different interpretation of the same underlying concept.

There is another architecture. Start with a standardised granular data foundation. Define the underlying concepts precisely. Then produce A, B and C from it, along with the question nobody knew they would need to ask yesterday.

That last part is what changes the economics. Template reporting is optimised for known questions. A granular foundation makes it possible to answer new ones.

This is the direction the BIS Innovation Hub explored in Project Ellipse with the Monetary Authority of Singapore. Replacing template-based, aggregated reporting with granular data gives supervisors the opportunity to continually repurpose common data points across different analytical use cases, which in turn requires authorities and institutions to share a common understanding of what those data points mean [6].

The caveats matter as much as the idea. Granular does not mean raw. Granular does not mean uncontrolled. It does not mean the authority receives every database table from every institution. It means common definitions, data models, taxonomies, identifiers, quality controls, lineage and governance.

Where that foundation exists, one thing changes fundamentally. The regulatory report stops being the data. It becomes one possible output of the data.

What machine-to-machine supervision actually looks like

[Visual: machine-to-machine architecture diagram]

Validation sits with the institution. Only approved data reaches the controlled staging area, and the authority meets it through one secure machine interface.

Start with the institution. It already has source systems, and those systems do not speak the language of supervision. So the first requirement is a data dictionary: common meaning, agreed between both sides. Then mapping and transformation into the agreed supervisory structure. Then validation, with invalid records going back for correction. Responsibility for data quality stays with the institution, before anything crosses the boundary.

Then the staging area, and two interaction patterns.

Pull. Approved and validated information sits in a controlled staging area. When the supervisor has an authorised need, that information is retrieved through the machine interface. Picture an emerging liquidity concern where the normal periodic return is too coarse. Instead of designing a new template, emailing it to every institution, waiting for responses and aggregating them, the authority requests standardised information directly from the supervisory layer.

The word doing the work there is controlled. This is not unrestricted access to a bank’s production database, which would raise entirely different legal, security and governance questions. It is a defined staging environment, with defined datasets, defined permissions, defined requests and full auditability.

Push. Some information should not wait to be asked for. A periodic return can become available automatically when the reporting period closes. If an institution’s anomaly or fraud rules fire, a supervisory message or dataset can be pushed without a request.

In the middle sits one secure machine interface. The name does not matter, and here it is SAPI. What matters is the change in the interaction. Today a human creates a file, another human uploads it, a system receives it, another human checks it. In this model, more of that happens system to system.

On the authority’s side, raw information is retained, curated information is prepared, and analytical datasets support supervision. Which means a hybrid model: sometimes Push, sometimes Pull, with the method chosen by the supervisory question. And unnecessary delay removed between the source data and the person who needs to understand it.

This is not supervisors replaced by machines. It is a trusted data channel between the institution and the authority.

From reporting calendar to risk radar

The architecture matters less than the change in the question being asked.

Template reporting tends to ask: what was the bank’s position? Risk-based, data-driven supervision increasingly asks a different set of questions. What is changing? What is accelerating? What is behaving differently from its own historical pattern? Where is concentration building? Where has deposit behaviour shifted? Where do several weak signals suddenly start moving together?

That is what always-on supervision should mean. Not every supervisory data point streamed continuously. Continuous supervisory awareness: the capability to see relevant change closer to the moment it occurs.

Technology is the easy part

That heading is an exaggeration, deliberately. Building secure, scalable supervisory infrastructure is not easy. But it is the visible part of the iceberg, and the visible part is what gets demonstrated in vendor meetings.

Underneath sit data standards, data quality, governance, legal authority, cybersecurity, accountability, architecture and institutional readiness. That is where the actual transformation happens, and the failure modes are specific:

• If two institutions define the same instrument differently, an API moves inconsistent data faster.

• If the underlying data is wrong, AI produces a faster wrong answer.

• If there is no legal basis for access, Pull supervision does not exist.

• If nobody is accountable for a machine-generated supervisory indicator, automation becomes a risk rather than a control.

• If an institution cannot trace a number back to its source, granularity produces volume rather than insight.

So granular data comes before AI. Data standards come before dashboards. Governance comes before automation. The quality of supervision cannot exceed the quality of the information architecture underneath it.

Which suggests a different opening question for any SupTech programme. Not “which technology should we buy?” but “what supervisory capability are we trying to create, and what data foundation makes it trustworthy?”

What gets built before the next crisis

2008 taught resilience. Stronger capital, better liquidity, stronger risk management. The industry changed, and it was right to.

2023 taught speed. A vulnerability that builds over months can become a liquidity crisis in hours, because information, confidence and money now move at the same pace.

The next capability is awareness. Not instead of resilience. On top of it. From aggregated data to granular data. From files to machine-to-machine exchange. From periodic reporting to continuous supervisory awareness.

To be clear about what this is not. It is not a prediction that quarterly reporting disappears, because it will not. It is not a prediction that supervisors become algorithms, because they should not. Technology identifies, organises and prioritises signals. Humans exercise supervisory judgment, challenge management, make decisions and remain accountable. Machine-to-machine supervision is about giving those humans a better information environment to decide in.

There is no single model here. Every jurisdiction has different systems, different legal frameworks and different levels of data maturity. But the direction is becoming clear: more granular data, more standardisation, more system-to-system interaction, and more awareness when risk starts to change.

At FINA, working on supervisory data platforms with central banks and regulators, the pattern we see is consistent. The hard part is rarely collecting more data. It is making sure the data is consistent, validated, traceable and usable for a supervisory decision. The future of SupTech will not be defined by one API or one AI model, but by how well the whole chain connects, from the source system inside the institution through to human judgment at the authority.

AI without trusted data is not intelligence. Dashboards without governance are not supervision. And faster reporting without better information is just faster reporting.

The question is what gets built now. The next crisis will not wait for the reporting deadline.

References

1. Basel Committee on Banking Supervision, “Basel III: international regulatory framework for banks,” BIS. Available here.

2. Financial Stability Institute, “Risk data aggregation and risk reporting: Executive Summary,” BIS. Available here.

3. Board of Governors of the Federal Reserve System, “Review of the Federal Reserve’s Supervision and Regulation of Silicon Valley Bank: Key Takeaways,” April 2023. Available here.

4. Board of Governors of the Federal Reserve System, “Review of the Federal Reserve’s Supervision and Regulation of Silicon Valley Bank: Executive Summary,” April 2023. Available here.

5. California Department of Financial Protection and Innovation, “Review of DFPI’s Oversight and Regulation of Silicon Valley Bank,” May 2023. Available here.

6. BIS Innovation Hub and Monetary Authority of Singapore, “Project Ellipse: An integrated regulatory data and analytics platform,” March 2022. Available here.