Issue taxonomy and exception management

From operational defect to governed risk: categories, owners, and escalation

Purpose. Give a practical issue language that links governance Layer 4 to daily operations. The exact labels vary by bank; the pattern matters: trivial defects that stay in email become silent risk when they repeat at scale.

Why taxonomy matters

Without categories, every problem becomes “urgent” or nothing gets escalated. A shared taxonomy lets you measure volume, severity, ageing, and repeat causes, and it gives audit a trail from detection through closure. It also stops vendor management meetings from mixing a missed file timestamp with a systemic conduct failure.

Category A: operational defects

Character: single-account or small-batch errors that should clear inside operational SLAs: wrong balance on placement row, missing phone permission flag, one-off duplicate key, delayed delta file within tolerance.

Typical owner: CP operations with DCA operations counterpart.

Escalation: stays in weekly forum unless repeat pattern emerges.

Example: DCA shows arrangement “active” while CP shows “broken”; one customer impacted; fixed same day with dual-state correction.

Category B: control weakness

Character: a process gap that could affect many accounts but has not yet caused customer harm at scale: reconciliation threshold set too wide, manual workaround used every day, missing monitoring on a feed.

Typical owner: CP operations lead with risk awareness; fix plan with date.

Escalation: monthly governance if not cleared; second line may request testing evidence.

Example: payment file routinely arrives after DCA outbound window, causing stale balance contact attempts.

Category C: customer harm or conduct event

Character: actual or likely unfair treatment, incorrect information to customer, missed suppression, excessive contact, or breach of hardship handling.

Typical owner: first line with immediate compliance involvement; DCA stops work on affected population as required.

Escalation: executive notification per policy; regulator reporting if thresholds met.

Example: customer on known hardship hold receives demand letter due to bad merge of flags.

Category D: financial or strategic materiality

Character: large misstatement in fees or recoveries, systemic data corruption across cohorts, fraud suspicion, or failure that threatens continuity of the programme.

Typical owner: executive task force: finance, risk, operations, legal.

Escalation: immediate; may pause placements or recalls until containment.

Example: fee calculation error affecting three months of remittance across the entire portfolio.

Lifecycle of an issue

Detect: monitoring, reconciliation break, complaint, or DCA escalation feed.
Log: category, owner, population scope, start time. Avoid “verbal only” for Category B and above.
Contain: stop loss for customers (suppression, recall) before root cause is fully understood when harm is plausible.
Remediate: fix data, process, or vendor behaviour; back-correct reporting if needed.
Evidence pack: what happened, why, what changed, how you tested, who signed off.

From operations to governance

Weekly meetings should clear Category A and drive owners for Category B. Monthly meetings should show ageing of open Category B items and any repeat drivers. Quarterly meetings should ask whether issue trends imply incentive or policy problems, not only vendor underperformance.

Silent operational leakage becomes risk when the same workaround exists for a year and nobody measures how many accounts touched it.

Reporting hooks

Layer 3 packs often include a risk indicators section. Tie issue counts and ageing there, not only in a separate spreadsheet, so finance and risk see the same story as operations.