Risk monitoring

The problem

Risk signals are geographically scattered and linguistically inaccessible. A supplier problem in a market nobody on the team reads reaches you through the wire days after it reached the people already acting on it.

How does a news API support risk monitoring?

Continuous cross-language monitoring with story-level grouping, so the alert volume stays proportional to events rather than to syndication, and coverage in any indexed language is reachable from a query written in one.

What the workflow looks like

1. Define exposure as a set of entities, regions and languages.
2. Draw a radius with near around the plants, ports and warehouses you depend on, so reporting that names only a neighbouring town still reaches you. Run event_type for classes such as outage, supply_shortage and labor_strike alongside the queries in words, not instead of them: a class is precise rather than complete.
3. Resolve the entities to ids and run shared_exposures over up to five at a time: the stories, sources and risk signals that name several of them at once are where one incident touches more than one exposure.
4. Alert on the appearance of a story rather than on volume — by the time volume moves, the lead time has gone.
5. Require a second independent outlet before escalating anything expensive to act on.
6. Keep a standing quiet-period check: coverage stopping is a signal too.

What will a news API not do for risk monitoring?

Early signals are unconfirmed by definition, so this trades precision for lead time and there is no setting that gives both. Budget for human review. It is also not a sanctions, watchlist or adverse-media screening product — those have compliance obligations this does not attempt to meet.

The mistake teams make here

The mistake that kills these systems is not a bad alert, it is a good alert nobody can act on. A feed that escalates on single-source early reports will be right often enough to feel valuable and wrong often enough to be muted, and the muting is informal — a filter rule, an ignored channel, a person who stops reading — so it never appears in any review. By the time someone asks whether the system is working, it has not been working for two quarters. Requiring a second independent outlet before anything expensive fires costs lead time on purpose, and it is the difference between a monitor that survives a year and one that is quietly abandoned.

How would you know risk monitoring is working?

Track two numbers: time-to-first-signal on incidents you eventually learned about anyway, and the false-escalation rate. The second is what kills these systems — a feed that cries wolf gets muted within a quarter, and the muting is never recorded anywhere. Require a second independent outlet before anything expensive fires, and audit what was suppressed as well as what was sent.

What to build in the first week

Write down what happens when an alert fires, before you make any fire. Who receives it, what they are expected to do within the hour, what threshold justifies waking someone, and who decides. Then run the queries in a channel nobody is on call for, for a week, and check the volume against that plan. Almost every risk monitoring project is specified as though alerts will be rare and discovers in week one that they are not, at which point the escalation design has to change anyway. Doing it in that order costs a week and saves the credibility you only get to spend once.

What are the alternatives for risk monitoring?

Dedicated risk platforms add proprietary sources, structured incident databases and geopolitical analyst commentary, which matter most for physical security and country risk. Sanctions and adverse-media screening is a regulated adjacent problem with its own vendors and audit requirements — do not substitute this for one. News is the fastest and broadest layer, and the least authoritative.

The queries that implement it

• Catch supply chain disruption before it reaches the wires — /stories in semantic mode
• Notice when coverage stops — /stories in hybrid mode
• Monitor a market whose language nobody on the team reads — /stories in semantic mode

Each recipe makes the case for its parameters. Response fields, failure modes and scheduling cost are in the technical documentation.