A quarterly review of a fund counterparty slips. The analyst was covering for someone, the NAV statement went to a shared mailbox and stayed there, and the review that should have happened in April happens in July. When it happens, the numbers are fine. Nothing has breached. The limit did not need to move. Most teams would file that as a near miss with no consequence.
We think that is the wrong classification, and the reason is worth setting out carefully, because it changes what a monitoring function is for.
The desk was pricing exposure off old information
Between April and July the bank kept trading with that counterparty. The limit was in force, the desk used it, and the credit decision behind every trade rested on a NAV figure that was, at the end, five months old. That the fund's NAV happened not to move much is a fact about the fund. It is not a fact about the control.
Put another way: the control's job was to ensure that exposure was taken against current information. For three months it did not do that job. A control that fails and is rescued by the underlying risk staying quiet has still failed, and if you only count the failures that produced losses, you will systematically underestimate how often the control is not working.
A breach tells you the counterparty deteriorated. Stale data tells you the bank would not have known if it had. The second is the control failure; the first is just the weather.
What this means for how you measure
The practical consequence is that the reporting to a risk committee should carry two separate populations, and the second is usually the more informative.
| Population | What it measures | Who owns it |
|---|---|---|
| Breaches and near-breaches | Credit deterioration in the book | Credit officers; the limit decision |
| Stale, late and missing data | Whether the control is operating | Credit control; the process |
The second population needs its own metrics: the count of positions whose latest official figure is past due, the oldest of them, the exposure that sits behind them, and the trend. Exposure against stale information is the number that gets attention, because it turns a data-ops statistic into a risk statistic. A hundred million of settlement limit outstanding against NAVs older than their reporting cycle is a sentence a committee understands.
What this means for how you build
If stale data is a control failure, then the system has to treat it as an event, not a report. Concretely:
- Every deliverable has a due date derived from the agreement, not from a global setting. Monthly funds go stale after a month plus the delivery lag; quarterly funds after a quarter.
- Passing the due date changes state. The figure is flagged stale on every screen where it is used. The limit that depends on it is shown as resting on stale data. A policy decides whether it is held, haircut or frozen.
- The chase is logged against the item, so the difference between "we asked twice and were ignored" and "nobody asked" is visible. The first is a counterparty problem; the second is ours.
- Cure closes the item and records how late it was, so the on-time rate per counterparty, per team and per fund type is a fact rather than an impression.
Why this lands with committees
Risk committees have always been asked to look at breaches. What they are increasingly asked by their own second line and by regulators is whether the monitoring framework operates as designed, continuously, across the whole population in scope. That question cannot be answered from breach statistics. It can be answered from staleness statistics, and a monitoring function that reports them is answering the question before it is asked.