Continuous risk monitoring that knows when to stay quiet
How we built a listening system for a risk function that surfaces meaningful change, not more articles to read.
The problem
Organizations hear too late
A global risk management function at a large accounting firm monitors a portfolio of client and counterparty exposures. The signals that matter are public, fragmented, and constantly moving: a covenant breach, a rating downgrade, a leadership change, a regulatory action. The information is available. The problem is not access. It is attention.
Most teams find these signals manually, through periodic reviews, inbox scanning, and whoever happens to be paying attention that week. At portfolio scale, that fails quietly. A material development goes unnoticed, a decision gets made on partial information, and when someone later asks how it was missed, the answer is almost always the same: no one was listening continuously.
The usual fix is media monitoring, which delivers volume rather than awareness. It answers "what was published that mentions this name?" It does not answer the harder question the risk team actually has: what changed, and does it matter?
What we built
Detection, not alerts
We built a system organized around change, not mentions. Ten articles about a company do not mean ten things happened. Usually it means one thing happened and nine outlets covered it, or nothing happened and the company was mentioned in passing. So the system detects meaningful developments against an explicit risk rubric, not keyword matches: financial stress indicators like covenant breaches and rating downgrades, operational disruptions, regulatory actions, management turnover that threatens continuity.
Three things make it work. It listens continuously across defined sources and keeps a time-indexed history for each entity, so a new item is evaluated against what was already known rather than in isolation. It applies confidence scoring that weighs source reliability and how many independent sources corroborate a signal. And it never surfaces a flag without showing its evidence: the specific criterion that triggered, the filings or coverage behind it, and whether this is new, worsening, or already resolved. A risk analyst can ask why something was flagged and see the answer, rather than trading human intuition for a black box.
What we learned
The hardest part was not listening. It was remembering accurately. Early versions threw false positives when a development from three months ago resurfaced and the system could not reliably tell it had seen it before. Getting deduplication right meant building entity resolution that recognizes the same story across outlets, follow-up coverage, and articles that cite older ones.
The harder design problem was restraint. Monitoring tools are rewarded for coverage; every alert justifies their existence, and silence feels like failure. We built the system to be rewarded for restraint instead. When a monitoring cycle finds nothing material, it says so explicitly: monitored across this many sources, no rubric criteria met, last meaningful signal on this date. That turns silence from ambiguity into information. Users distrusted it at first, when nothing was flagged, the reaction was "is it broken?" rather than "nothing changed." Making the absence of a signal visible was what earned their trust.
The takeaway
Even when the system does not provide advance warning, it provides defensible documentation of when a risk was detected and on what basis. For a risk function, that audit trail matters as much as the speed. The design goal was never to hear everything. It was to make sure the right people know the right things and are not buried by the rest. That line, between what the machine watches and what a person should judge, is the whole product.