An early-warning system is useful when it leads to a timely and proportionate response. A list of red entries does not reduce risk by itself. We need to understand how a signal arose, who received it, who assessed it and what happened next. I would therefore examine the full path from source information to decision and follow-up, not stop at the indicator’s arithmetic. This connects process analysis with system testing: both ask whether the expected outcome actually occurs under a specific combination of conditions. A functioning calculation and a functioning response are different pieces of evidence.
A documented case of incomplete follow-through
On 9 December 2022 the FCA announced enforcement against Santander UK for anti-money-laundering control failures in business banking. Its official account includes an account recommended for closure in March 2014 without timely implementation. This is a UK AML case, not a credit early-warning finding. The transferable analytical question concerns the gap between an alert and completed action; it does not establish a credit rule or a defect at another institution.
A system that creates warnings without clear follow-up ownership can offer reassurance without an effective control. I would want an understandable state model: new, assigned, awaiting evidence, decided and followed up. Each state should mean something more than a colour. Closing a case should not merely remove it from a dashboard. The record should show why it was considered immaterial or what action resulted. This is my own reasoning about process design, not an additional factual finding about Santander. The relevant evidence would be the history of specific cases and their actual outcomes.
Signal, diagnosis and decision
A fall in account turnover can reflect difficulty, seasonality or payments moving elsewhere. An overdue instalment may have a technical explanation. An adverse indicator is therefore not automatically a diagnosis. Its purpose is to trigger an appropriate question. I would examine which combinations matter, whether they share a source and how evidence quality is assessed. Two alerts based on the same incorrect invoice are not independent confirmation. Without understanding those dependencies, a team can overstate or understate significance, particularly when an automated score gives several points to what is effectively one underlying observation.
I would also consider missing evidence and behavioural changes. An absent update does not prove deterioration, but it reduces confidence in the assessment. The process should be able to request clarification and handle uncertainty. From an IT perspective I would check timestamps, refresh frequency and visibility of failed transfers. Stale information should not look like a current quiet state. “No signal occurred” and “there is no fresh data” are fundamentally different conclusions. A dashboard should allow a user to distinguish them before relying on its reassuring appearance in a portfolio discussion.
A hypothetical portfolio example
Imagine 5,000 companies. A rule flags 200 whose incoming payments fell more than twenty-five per cent against a comparable period. Of those, 120 reflect normal seasonality, fifty moved payments and thirty remain unexplained. Reporting only the total of 200 describes activity rather than a clear risk picture. I would add assessment results and ask whether the thirty unexplained cases show other independent indicators. These numbers and thresholds are invented for illustration; they are not recommended regulatory limits or evidence that the same pattern exists in any actual bank’s customer population.
Suppose ten of the thirty also show repeated late instalments. I would propose prioritising those cases for specialist assessment, not automatically rejecting further lending or assigning one rating. I would verify obligations, the reason for falling receipts and a realistic cash-flow outlook. I would also check whether borrowers share a major customer. Individual signals may reveal a common dependency that separate reviews miss. That is why the output should connect with portfolio analysis while retaining the evidence for each customer. A shared cause remains a hypothesis until the relevant relationships have been verified.
How I would test the response
I would select open and closed alerts and reconstruct their lifecycle. When did the source arrive? When was the alert created and accepted? What counted as adequate explanation? Who verified that proposed action was completed? A simple timeline can expose the weakness: a technically correct response months later may not serve the original purpose. However, I would assess timing in relation to seriousness and information availability rather than judge every delay identically. The record should also distinguish waiting for necessary evidence from an unassigned case that nobody has meaningfully considered.
In testing I would prepare an input change, a transfer interruption, a repeated signal and a return to normal. I would check whether repetition overwrites the first detection date, whether unresolved cases disappear and whether decision history remains available. Access tests should establish who can cancel a warning and what explanation is required. When a rule changes, the original rule version should remain identifiable. Otherwise it becomes difficult to explain why similar information generated an alert on one occasion but not another, and whether that difference reflects an intended methodological change or a defect.
Evaluate usefulness rather than volume alone
I would track time to assessment, unresolved-case age and the proportion with documented explanations. I would also examine apparently quiet cases that later deteriorated. This is not a demand to predict every event; it is an opportunity to understand a missed pattern and whether a change would help. Retrospective assessment must respect information available at the time. Hindsight can otherwise produce unfair criticism and over-sensitive rules that generate too many warnings without improving decisions. A useful review asks what could reasonably have been detected, not merely what looks obvious after the outcome is known.
High alert volumes can exceed team capacity, but increasing every threshold is not necessarily the answer. I would separate seasonality, source defects, poor definitions and genuine change. Each requires a different response. I would not redesign a rule solely to reduce the count: I would examine which material situations the revised version would miss. A metric should support the control’s purpose. If it rewards rapid closure alone, it can undermine meaningful assessment. A balanced view combines throughput with evidence quality, unresolved risk and the performance of the rules that generate work.
Summary and recommendations
I would assess early warning as an end-to-end process, with clear states, ownership, proportionate timing and traceable closure reasons. Data loss, repeated signals and permissions deserve explicit tests. The British AML case is used only as a documented illustration of follow-through, while credit monitoring requires its own rules and specialist judgement. The useful outcome is a team that identifies a relevant question early, obtains the necessary evidence and can explain what it did. That is more meaningful than a large collection of technically correct alerts with no reliable path to action.