Regulator dashboards need supervisory signals

What the public implementation shows

The regulator dashboard query surface includes monitoring cards, hourly transaction volume, velocity alerts, alert heatmaps, and participant availability.

Supervisory views aggregate controlled transaction and monitoring records under regulator-specific authorization. This is the implementation fact behind the note; the architectural reading begins from that visible boundary rather than from an assumed production story.

Operating principleOversight needs indicators of concentration and abnormal behavior, not a duplicate operator screen.

The decision behind the mechanism

The dashboard emphasizes patterns and system conditions that support oversight rather than exposing raw operational administration.

Total daily value can remain normal while one participant, account, corridor, or hour shows a concentrated anomaly. The mechanism matters because it gives that failure a named boundary, durable evidence, and a controlled response instead of leaving the outcome to timing or operator guesswork.

• Separate indicator from confirmed incident.
• Show the time window and data freshness.
• Apply regulator-specific access boundaries.
• Provide governed drill-through to supporting records.

How the control should be operated

Each signal should define calculation window, source freshness, threshold, drill-through, and whether it is an alert, indicator, or confirmed event.

Regulatory conversations can start from current structured evidence without confusing a signal with a finding. The reusable lesson is not to copy a class or endpoint in isolation, but to preserve the relationship between identity, state, authority, evidence, and operational ownership.