SupTech dashboards for bank supervisors: why most are built for the wrong reader

What SupTech means#

SupTech is the use of technology by supervisory authorities to carry out supervision itself. It is distinct from RegTech, which is technology used by regulated firms to meet their obligations — the two are often discussed together and they serve opposite sides of the same relationship.

In an early warning context it covers everything between a bank filing a return and a supervisor deciding to act: collection, validation, reconciliation, the analytical layer, and the dashboards and alerts through which the result is received.

The pipeline decides what is possible#

Attention usually goes to the interface, and the interface is the least consequential part. What a dashboard can show is bounded entirely by what the pipeline behind it has delivered, validated and reconciled.

Four properties of that pipeline set the ceiling, and none of them is visible on screen.

• **Frequency of collection**, which caps how recent any figure can be.
• **Validation at the point of entry**, which decides whether errors are caught before they propagate or discovered downstream by an analyst who happens to notice.
• **Reconciliation across returns**, without which the same quantity reported in two places disagrees and nobody knows which to believe.
• **Scheduling**, which determines how long after arrival a figure actually reaches the person who needs it.

An authority frustrated by its dashboard will often find, on inspection, that the dashboard is faithfully displaying a pipeline that delivers late and disagrees with itself.

Where it goes wrong#

Supervisory dashboards fail in a small number of recognisable ways, and the failures are about design rather than technology.

• **Built for the builder.** Comprehensive, configurable, organised by data structure — a tool for someone who already knows what they are looking for, given to someone who does not.
• **Too many views.** A supervisor with forty screens available uses three. The other thirty-seven are not neutral: they make the three harder to find.
• **No path from system to institution to exposure.** A supervisor who sees a concerning aggregate and cannot descend to the bank, and then to the exposure driving it, has been given a fact rather than a lead.
• **Alerts that fire routinely.** Once an alert is expected it stops being information. The system then performs worse than having no alerts, because dismissal has become a habit.
• **No record of dismissal.** Where alerts are closed without a reason being captured, nobody can tell whether the system is wrong or being ignored.

An alert that a supervisor expects to see is no longer an alert. It has become part of the background, and the background is not read.

What good looks like#

A dashboard supervisors actually use tends to share four characteristics, and they are unglamorous.

• **Few views, each answering a question a supervisor actually asks** — which institutions changed most this period, which are furthest from their peers, which are approaching a threshold.
• **Drill-down that ends somewhere useful**, at a portfolio, a counterparty or an exposure that a supervisor can raise in a meeting.
• **Graduated states rather than a single red light**, so that movement toward a boundary is visible before the boundary is crossed.
• **Dismissals captured with a reason**, which over months turns the alert log into evidence about the calibration rather than about the banks.

Automation, and where to stop#

Collection, validation, reconciliation and computation should run without a person. Nothing after that should. The point where automation must hand over is the point where the output stops being a measurement and starts being a judgement about an institution.

That line is worth drawing explicitly and writing down, because it tends to move quietly as a system matures and each individual step past it looks reasonable on its own.

What to do next#

Ask which views supervisors open unprompted on a Monday morning, and compare that list with the views the system offers. The gap between the two is the design brief.

Then read the alert log for a quarter and count how many alerts were closed without a recorded reason. That number says more about the system than any measure of its coverage.