Companies have learned to count exceptions. The more difficult question is whether the same exception keeps coming back. In complex operations, recurrence can reveal that a temporary workaround has quietly become part of the real process.
Every large organisation has exceptions. A payment misses straight-through processing, a customer case needs manual review, a supplier invoice fails a matching rule, or a production order requires a one-off override. Counting these events is useful, but volume alone can be misleading. A business that handles thousands of low-risk exceptions once may be healthier than a business that handles a smaller number of the same unresolved exceptions every week.
That distinction is making recurrence a more interesting process metric. Recurrence asks whether an exception is genuinely unusual or whether it is becoming a parallel operating model. When the same deviation repeatedly appears at the same step, with the same root cause and the same manual repair, the organisation may no longer be dealing with exceptions at all. It may be running an unofficial process that has never been properly designed.
The point is especially relevant in financial services, where operational resilience rules increasingly require firms to learn from incidents rather than merely close them. The EU Digital Operational Resilience Act requires financial entities to record ICT-related incidents, identify and address root causes, and analyse the frequency, types, magnitude and evolution of incidents and their patterns. The regulatory language is about ICT risk, but the underlying logic is broader: repetition changes the meaning of an event.
Why volume can be the wrong first question
An exception count mixes together different phenomena. Some exceptions are deliberately designed controls. A high-value payment may require manual approval. A suspicious transaction should leave the normal path. A complex customer may need specialist handling. In these cases, volume can rise because the control is working as intended or because the business itself has changed.
Recurrence adds a second dimension. If the same payment type repeatedly fails because a reference-data field is incomplete, the organisation has evidence of a structural defect. If a customer onboarding case repeatedly needs the same policy override, the underlying product rule may no longer fit the customer population. If a supplier invoice is manually corrected every month, the apparent exception is actually recurring work.
Academic research supports the link between exceptions and operational performance. A study of process-execution logs from five organisations, published in the Business Process Management Journal, found that exceptional paths were associated with longer throughput times, with unexpected exceptions producing a stronger increase than expected exceptions. The study does not establish a universal recurrence threshold, but it reinforces the case for looking beyond average process completion.
The repeated exception is a form of organisational memory
A recurring exception tells the organisation something about what the formal process has failed to learn. The first occurrence may be genuinely novel. By the tenth occurrence, staff often know the workaround, the likely approver and the manual data correction required. That knowledge lives in people, inboxes and local spreadsheets even if the official process remains unchanged.
This gap between the formal process and the lived process is a central concern of process-mining research. Recent work on business process deviance analysis treats deviations as patterns that can be identified from event data and linked to process outcomes. The purpose is not to eliminate every deviation: some are constructive adaptations. The harder task is identifying which repeated deviations signal a design problem, a policy mismatch or a hidden dependency.
That is why recurrence can be more actionable than volume. Volume asks how much manual work exists. Recurrence asks whether the organisation has learned anything from doing the same manual work repeatedly.
DORA has made pattern recognition a governance issue
For financial institutions in the EU, this idea is no longer only an operations-management concept. DORA requires post-incident review after major ICT-related incidents and continuous incorporation of lessons from testing and real incidents into the risk-management framework. It also requires financial entities to analyse incident frequency and patterns over time. In other words, remediation is expected to change the system, not merely restore service.
The first full year of DORA reporting provides scale. The European Supervisory Authorities' first annual report on major ICT incidents recorded 3,383 major incidents in 2025 across the EU financial sector, around one-third with cross-border impact. System failures and external events were the principal drivers. The EBA's June 2026 Risk Assessment Report separately noted more than 18,000 DORA-related reports received through March 2026, with system failures the dominant category for credit institutions.
These totals do not tell a firm whether its own problems are repeating. But they show why regulators and management bodies increasingly need to understand patterns, not just incident counts. A large financial group can close every ticket within policy and still remain operationally fragile if the same underlying defect repeatedly creates new tickets.
From incident management to process quality
The recurrence idea is useful outside technology. In payments, repeated repair can signal weak reference data or poor customer input design. In treasury, recurring forecast overrides can reveal a missing data feed. In customer service, repeated escalations can show that frontline decision rights are too narrow. In procurement, recurring three-way-match failures can reveal a contract or master-data problem.
A practical recurrence metric therefore needs grouping. The organisation must decide when two exceptions are meaningfully the same: same root cause, same process stage, same data defect, same control trigger, or same workaround. Without that discipline, recurrence becomes another noisy count. With it, the measure can separate chronic exceptions from genuinely unusual ones.
Process mining provides a technical foundation. A 360-degree overview of process mining describes how event logs can be used to identify frequencies of undesired activities and loops, waiting times, rework and recurring quality problems. That means the data often already exist; the challenge is to connect them to ownership and remediation.
Why recurrence can reveal hidden cost
Repeated exceptions create cost in layers. There is the direct labour used to investigate and repair each case. There is queue time while the case waits for a specialist. There is the opportunity cost of the specialist's attention. There may also be customer cost through delay, duplicated requests for information or inconsistent outcomes.
The financial impact can remain invisible because each event is small. A five-minute manual fix does not look material. A five-minute fix repeated 100,000 times becomes a capacity problem. Even then, the business may tolerate it if the work is distributed across teams and no single budget owner sees the full cost. Recurrence analysis creates a way to aggregate that hidden burden around root cause rather than around department.
The FCA's resilience work points to the same discipline
The FCA's March 2026 operational-resilience observations emphasise that firms should continue evolving mapping, testing and remediation after the end of the transition period. Operational resilience is not a one-time compliance exercise. Firms are expected to understand vulnerabilities and improve their ability to remain within impact tolerances.
For management teams, recurring exceptions can be an early-warning layer below the formal incident threshold. A process may still meet its service-level target because staff are compensating manually. Recurrence reveals where resilience depends on people repeatedly rescuing the designed process. That is often valuable information before the workaround fails under higher volume or staff absence.
Recurrence needs ageing, ownership and a closure test
Recurrence becomes much more useful when it is paired with age. An exception that recurs for three days while a fix is being deployed is different from one that recurs for three years. A mature dashboard can therefore track not only how often the same issue returns but how long the root cause has remained open, whether a permanent remediation date exists and whether recurrence falls after the fix is implemented.
Ownership matters for the same reason. Repeated exceptions often survive because each individual team sees only its part of the problem. Operations repairs the case, technology owns the system, risk owns the policy and finance owns the cost. No single function owns recurrence. A cross-functional root-cause owner can therefore be more important than another queue-level service target.
The final test is closure quality. A problem should not be considered solved merely because the ticket is closed. If the same exception family returns at the same rate, the organisation has evidence that the remediation did not change the process. This turns recurrence into a feedback measure for change programmes themselves: did the fix actually reduce the behaviour it was designed to eliminate?
The counterargument: recurrence is not automatically bad
Some recurring exceptions are economically rational. A bank may intentionally route every unusually large transaction to enhanced review. A manufacturer may manually inspect a specialist product because automation would cost more than the labour saved. A regulated business may keep a human approval step because independence matters more than speed.
The objective should therefore not be zero recurrence. It should be explicit recurrence. If a repeated exception is necessary, it should have a designed path, clear ownership, known capacity requirements and a reason it remains outside the main process. The problematic case is the recurring exception that nobody has formally chosen but everyone has learned to live with.
Evidence versus inference
The evidence is clear that exceptions can be associated with longer throughput times; that modern process-mining methods can identify repeated deviations and loops; and that DORA explicitly requires financial entities to analyse incident frequency, patterns and root causes. Regulators are also placing sustained emphasis on remediation and learning from operational events.
The inference is that recurrence can be a better process-quality signal than raw exception volume in many settings. There is no universal recurrence ratio, and different processes will require different thresholds. The most useful approach is to combine frequency with root cause, impact, manual effort and whether the process has learned from previous occurrences.
Implications for companies, banks and investors
For operating leaders, recurrence should influence improvement priorities. A high-volume exception that is well controlled may deserve less attention than a lower-volume defect that repeatedly creates customer harm or senior escalation. For banks and fintechs, recurrence analysis can connect operational resilience, fraud operations, payment repair and service quality to the same root-cause discipline.
For technology providers, the opportunity lies in linking process logs, case-management data and control outcomes so repeated patterns can be seen across systems rather than inside individual teams. For investors, persistent manual exceptions can be a clue to operating leverage: a company may appear scalable while quietly adding people to compensate for unresolved process defects.
Conclusion: the exception that comes back is no longer exceptional
Companies have become better at counting what leaves the normal path. The next step is to distinguish unusual events from recurring design failures. An exception that appears once may be noise. An exception that appears repeatedly with the same cause is information about the process itself.
That makes recurrence a useful bridge between operational efficiency and resilience. It does not eliminate the need for volume, severity or customer-impact metrics. It adds a learning test: after the organisation has seen a problem before, has the process changed? If the answer is repeatedly no, the hidden cost is not the exception. It is the failure to absorb the lesson.
References
1. European Banking Authority - Risk Assessment Report, June 2026
2. European Supervisory Authorities - First annual report on DORA major ICT-related incidents
3. FCA - Operational resilience: insights and observations one year on
4. EUR-Lex - Regulation (EU) 2022/2554, Digital Operational Resilience Act
6. Software and Systems Modeling - Redescription mining-based business process deviance analysis