Failed transactions are supervisory data

Counting failures is the beginning

A total failure rate can tell leadership that a problem exists. It rarely tells operations where to act. The same count may be caused by one misconfigured participant, a concentrated account pattern, a new rejection reason, or a scheme-wide dependency.

Guevara's public model separates institution, account, rejection type, and trend analytics. That dimensional view turns a pile of exception rows into candidate causes and accountable boundaries.

Operating principleThe useful question is not how many failed, but where risk is concentrating.

Precompute the operating picture

Dedicated analytics runs and persisted summaries can make large operational sources usable without forcing every dashboard request across raw switch tables. A run identity also says when the view was computed and which period it represents.

Classification matters. Technical errors, participant rejection, fraud rules, malformed messages, and insufficient funds should not share one undifferentiated bucket. Each category implies a different owner and remediation path.

• Trend by time window to distinguish spikes from persistent conditions.
• Rank institutions and accounts by both count and rate.
• Preserve the rejection vocabulary used by the source.
• Keep drill-through to the governed underlying records.

Analytics becomes governance

When the same evidence feeds operator, regulator, and participant conversations, the analytics layer becomes a governance instrument. It can support a remediation request, explain a service incident, or show whether a prior intervention worked.

The aim is not to punish participants with a league table. It is to make systemic and concentrated risk visible early enough for the right institution to act.