Exception Handling & Repairs

Why this topic matters

Exception handling and repairs is the discipline for controlled recovery when the happy path fails. A payment may reject, a posting may time out, a batch may partially process, a file may contain invalid records, a balance may not update, a statement may fail, an account may be closed, a mandate may be missing, or a settlement entry may not match. The bank needs a defined way to detect the exception, assess the impact, repair safely, communicate honestly, reconcile the financial effect, and prevent repeat failure.

Repairs are dangerous when they become informal. A manual correction can help a customer quickly, but it can also create a duplicate debit, hide a GL break, bypass sanction screening, override a business mandate, or erase evidence. World-class repair design treats every exception as both a customer service event and a control event. The goal is not only to clear the queue. The goal is to restore the correct financial truth with evidence.

Shared servicing controls

The Operations and Servicing chapter covers shared intake, queue ownership, approvals, communication and quality review. This chapter applies them to the specific financial process below.

Triage an unknown payment outcome before any financial repair

Harbour Tools sees a 25,000 supplier payment time out. Operations first collects the instruction ID, payload/version, approval record, journal reference, rail reference and recorded events. A timeout is a communications observation. It is not proof that the bank failed to debit, the scheme failed to accept or the beneficiary failed to receive.

Do not repair by changing a database balance, deleting a journal, bypassing screening or clearing suspense with an unexplained balancing entry. A sanctioned-party review can require rejection or blocking under law; an operations manager cannot release it solely because payroll is urgent. Repairs should use authorised service operations with validation, separation of duties, reason codes and linked financial entries.

Give each break a customer impact, currency/value, age, permitted actions, due time and escalation owner. Protect customer communications from disclosing confidential monitoring while explaining the known state and next update. Close the case only when the customer outcome, journal, external outcome and reconciliation agree or a documented remaining obligation has an owner. A cleared technical alert does not prove the financial break is resolved.

Test a crash after posting but before acknowledgement, a repeated repair click, a stale approval, a weekend investigation, a reopened case and an incorrect operator proposal. Retain before/after evidence, including why an attempted repair was rejected. Root-cause review should distinguish bad source data, control failure, system defect and legitimate external return; otherwise repeated harms become routine manual work.

Build a repair queue that preserves financial evidence

An exception record needs the original instruction and item identifiers, customer/entity reference, amount and currency, booking/value dates, current authoritative status, failure category, dependency responses, reconciliation break, investigation owner and next action. Record what is known separately from what is inferred. A channel timeout, a business-rule rejection and a settlement mismatch should not share an undifferentiated “failed” status. Mask sensitive data in queue views while retaining controlled access to the underlying evidence.

Classify repairs by financial effect. A validation failure before financial commitment may be corrected through a new version and reapproved. A committed debit with no response needs outcome tracing before any resubmission. A definitively rejected external instruction can require release of its reservation or a permitted customer credit, depending on where the failure occurred. A settled payment to the wrong beneficiary requires the applicable investigation/return process; changing an internal status or cancelling a workflow cannot undo final settlement.

Suppose an SME uploads 200 salary items. One item has a malformed beneficiary identifier, another times out after submission, and a third was already posted when the portal lost the acknowledgement. The malformed item can return to the maker for correction without touching the released population. The timed-out item remains unresolved under its original identifier. The already posted item returns its existing result. A blanket “re-upload file” instruction risks paying some staff twice. If an item changes amount or beneficiary, bind approvals to the new immutable version and apply the required mandate again.

Technical support should supply evidence and restore components; it should not silently acquire authority to move customer money. Operations proposes the permitted action, a separate authorised reviewer approves material financial repairs, and posting/rail services enforce the decision. Restrict bulk repair tools by action, amount, population and expiry. Record before/after state, journal or rail reference and maker/checker identities. Privileged emergency access needs a defined owner, time limit and review.

Prioritisation considers customer harm, payment value, statutory/scheme clocks, payroll urgency and financial exposure rather than queue age alone. A queue contains controlled work, not a place to conceal missing money. Escalate missing source evidence, contradictory statuses and repeated failures to incident management and reconciliation. Do not close the financial case solely because a technical incident was resolved.

Useful acceptance tests include a duplicate callback, a corrected payload under an old key, two operators repairing the same item, a retry after the business day closes, a beneficiary bank response arriving during manual review, and a service restart between approval and posting. Success means the intended financial effect occurs once, or remains explicitly unresolved with a responsible owner; merely draining the queue is insufficient.