Near Miss, Loss Data and Scenario Analysis
Atlas Global Bank's treasury operations uses a spreadsheet of 1,800 standing settlement instructions (SSIs) to populate payment templates. In six weeks there were three failed settlements caused by outdated SSIs after counterparties changed custodians; each was caught by the counterparty or a manual check, so no loss was recorded. A fourth incident was a near miss: a USD 40 million payment was about to be sent to a predecessor custodian's account at 17:55 on a Friday; a payment analyst spotted the mismatch during a final check. The SSI change log is a shared spreadsheet with no four-eyes review and no reconciliation to counterparty confirmations; the last full review was 14 months ago. A peer bank disclosed a USD 250 million loss from a similar SSI error. Atlas's internal loss database covers five years with a USD 20,000 threshold; the largest operational loss is USD 12 million. Near misses are not captured. The business says no loss means no incident and no need to change the capital model, which uses internal loss data only.
1. Should the near miss be recorded, and how should it be aggregated with the three failed settlements?
Read the worked answer
The near miss should be captured. A near miss is a control failure that did not become a loss; it is leading evidence of risk. Record it as a near-miss incident with actual loss zero and potential loss USD 40 million, the root cause (static SSI not updated), the control failures (no four-eyes, no reconciliation), and the detection point (analyst check). Do not add it to the actual loss database as a loss, because that would distort loss data; hold it in a separate near-miss dataset linked to the same incident taxonomy. Aggregate the three failed settlements and the near miss by root cause, not by amount; they are one issue with four manifestations. The business's 'no loss means no incident' position is wrong because it removes the warning signal. The near miss should also trigger a review of the SSI population, an RCSA update, and a scenario analysis. If the bank's policy requires reporting of potential losses above a threshold, USD 40 million clearly meets it.
2. Is internal loss data alone sufficient for the capital model? What would you do instead?
Read the worked answer
Internal data alone is not sufficient. Five years of losses above USD 20,000 with a maximum of USD 12 million does not represent the tail; the peer loss of USD 250 million is direct evidence that a much larger outcome is plausible. The near miss was USD 40 million and was caught by chance, not by design. A capital model using only internal data will understate operational risk. Use scenario analysis: assemble experts from treasury, operations and risk; define the event (undetected SSI error across multiple payments); estimate frequency and severity with evidence; challenge the estimates; combine with external data and near misses. The scenario should feed capital, risk appetite and controls. Also consider whether the USD 20,000 threshold is excluding relevant small-error data. The model should be validated and the limitations documented. Do not simply add the peer loss to internal data; use it to inform the scenario.
3. What control remediation would you prioritise, and how would you measure success?
Read the worked answer
Priority 1: four-eyes approval on every SSI change, with maker-checker in the system, not the spreadsheet; reconcile SSIs to counterparty confirmations at least annually and on notification of a custodian change; retire the 1,800-line spreadsheet or restrict it to read-only with a controlled master. Priority 2: retrospective review of all 1,800 SSIs, risk-ranked by payment volume and recent changes; validate high-risk records within 30 days. Priority 3: payment screening against a verified SSI at the point of release; independent callback for payments above a threshold; hard stop for new beneficiaries. Metrics: percentage of SSIs reconciled, number of changes without four-eyes, failed settlement attempts, near misses, and ageing of SSI reviews. Assign owners and dates; report to the Operational Risk Committee monthly. The control design should prevent the error, not rely on a Friday afternoon check.