Counterparty Monitoring: A Screening Loop Without a Recipient Changes No Decisions
Our second in-house product was built as simply as possible: a list of counterparties, a recurring check against the enforcement-proceedings registry, a notification to the responsible employee, and a record of the result in the client's CRM card. Four steps, and only the last one was hard.
The check itself wasn't the value: any employee could look up the same data by hand. The value came from two other properties — regularity and addressing. The check ran without anyone having to remember it, and its result went not into a report but to a specific person whose decision depended on it.
A counterparty monitoring loop has four parts, and the first two are the cheapest and least valuable. Data and screening are available to everyone; the loop only works once the result is routed to the decision maker and stays in the system of record as a fact. A screening loop without a recipient produces information that changes no decision.
The Four Parts of the Monitoring Loop and What They Actually Cost
Let's break monitoring into its components. It's more useful to look not at each part's technical complexity, but at what happens if you remove it.
Data source. Registries, public disclosures, counterparty filings. The most technically discussed part, and in practice the most replaceable: there are many sources, and switching from one to another changes nothing about how the process works.
Regular screening. A one-time check at onboarding is stale within a month. A recurring one stops being an action and becomes a property of the process — and that's exactly where the human factor disappears: an employee can't check something they forgot to check.
Routing to the decision maker. The result doesn't go "to the company" — it goes to a specific person who has a decision to make: whether to ship the batch, extend the payment term, or demand prepayment. Without this part, the loop produces information no one is obligated to read.
Recording as fact. The screening result becomes an entry in the system where the truth about the counterparty lives. Six months later, it's visible that the decision was made with the known risk in view — and that protects both the employee and the company.
| Part of the loop | What happens if you remove it | Cost to build |
|---|---|---|
| Data source | Nothing left to check | Low, sources are interchangeable |
| Regularity | Data goes stale, checks get forgotten | Low, set up once |
| Routing to the decision maker | Information exists, decisions don't change | Medium, requires naming a recipient |
| Recording as fact | You can't prove the risk was known | High, requires integration |
The order in the third column is the reverse of the order of value. What's cheapest to build is what's replaceable; what's most expensive is what makes the loop useless without it. That's exactly why most implementations stop at the first two parts.
Why Counterparty Risk Stopped Being Just Finance's Problem
Payment discipline in Europe is measured annually, and the numbers show that counterparty risk moved out of accounting long ago.
European businesses receive 12,13% of all revenue late — above the 12,08% threshold companies themselves call the limit for staying financially sound. 62% of companies hit by client payment delays go on to delay payments to their own suppliers because of it.
I'll name the limitation myself: this is a survey of perceptions and self-assessment, not transaction data, and the publisher earns money managing overdue debt — meaning it has an interest in painting a sharper picture. What's useful here is the cascade effect: a late payment travels down the chain. That means counterparty risk isn't local — it reaches you through a company you don't even work with.
The average days sales outstanding (DSO) for German businesses rose to 32,21 days in the first half of 2026 — the highest since 2019, with the average payment delay reaching 8,14 days.
Here the method is stronger: not an opinion survey but an analysis of actual payment records. The limitation is that the sample represents the bureau's own client base, not the whole economy, and covers only one country. The direction of the finding is unambiguous either way: payment terms are getting longer, which means the window during which you need to know a counterparty's condition is getting longer too.
What the Official Insolvency Statistics Show
Between January and May 2026, German courts registered 10 546 corporate insolvencies — 4,9% more than in the same period of 2025. Meanwhile, the total value of creditor claims filed dropped to 15,4 billion euros, down from 25,7 billion a year earlier.
Notice the methodological detail the source discloses itself: about three months pass between a filing and its appearance in the statistics. That's the cost of managing by report — by the time a fact becomes public statistics, decisions about that counterparty have already been made. The monitoring loop exists precisely to close that gap.
Western Europe recorded 197 610 corporate insolvencies in 2025 — 4,8% more than the year before, the highest level in more than twenty years. Germany saw growth of 8,8%, while Eastern Europe posted a decline of 7,1%.
The publisher is a commercial credit bureau that sells scoring and monitoring services, and national definitions of insolvency differ across countries, which makes strict comparison difficult. I'm using this data as a directional indicator, not a precise figure.
What a Working Monitoring Loop Looks Like
The first node matters more than it seems. The counterparty list has to come from the system of record, not be maintained separately — otherwise a new client won't make it into monitoring, and new clients are exactly where most of the risk sits.
The third node requires a decision that usually gets postponed: who exactly is the recipient. "The account manager" works worse than "the head of sales for counterparties with payment terms over a million." A credit exposure threshold routes different amounts to different people and clears out the stream of low-stakes notifications.
The fourth node delivers what the loop is ultimately built for: proof. Six months later, it's visible not just that the risk was known, but what decision was made about it. The same requirement — an event instead of a report — holds in other processes too.
Four Decisions to Make When Building a Monitoring Loop
Where the list comes from
Only from the system of record. A separately maintained list goes stale and misses new counterparties.
Who the recipient is, and at what threshold
Different amounts, different recipients. One recipient for the whole stream stops reading notifications within a month.
What decision is prescribed
Not "noted," but something specific: hold the shipment, request prepayment, escalate to committee.
Where the trail is kept
The counterparty's file, with a record of the fact and the decision made. Without a trail, the loop protects no one.
If the answer to "who receives the screening result" is a department name rather than a person's name and a threshold, the loop is collecting information, not managing risk.
Frequently Asked Questions
How do you set up regular counterparty screening?
Start not with picking a data source, but with two decisions: where the list of counterparties to check comes from, and who receives the result. The list should be generated automatically from the system of record; the recipient should be defined by a credit exposure threshold or payment-term conditions. The data source is chosen last and is easy to replace; the first two decisions are expensive to redo.
Why isn't a one-time check at contract signing enough?
Because a counterparty's condition changes while decisions keep getting made — shipments, extended payment terms, new orders. Official insolvency statistics lag the actual filing by about three months, and payment terms across European business are getting longer — meaning the window for reacting is shrinking. A check done at signing describes the state as of the contract date and says nothing about today.
How do you avoid drowning in notifications?
With thresholds and different recipients. A notification about a fact that changes no decision shouldn't be sent at all. A practical benchmark: if a recipient hasn't made a single decision based on their notifications in a month, the threshold is wrong — either set too low, or routed to the wrong person.
Do you need a separate system for this?
No. The loop is built from what already exists: the list from the CRM, screening through an available data source, notification through the system's built-in tools, and the record in the counterparty's file. Our own service worked exactly this way and integrated with several different CRMs, because no one is going to switch their accounting system just for monitoring.
The description of the loop (counterparty list, recurring screening against the enforcement-proceedings registry, notification to the responsible employee, result recorded in the CRM) and the list of supported accounting systems come from the product description of Alego.Digital, the author's own enforcement-proceedings monitoring service. This is the author's internal company material; it hasn't been verified by an independent party and is presented here as an illustration of the mechanics. No quantitative effect metrics for this product exist in the available documents, so none are cited here. The rule of routing to different recipients by a credit exposure threshold is the author's own practice, not a construct described in the company's documents.
- Intrum. European Payment Report 2026, April 2026 (survey of 8 385 executives in 20 countries). intrum.com
- Creditreform. Zahlungsindikator Deutschland – Sommer 2026, August 2026. creditreform.de
- Statistisches Bundesamt (Destatis). Press release PD26_288 of 14 August 2026. destatis.de
- Creditreform Wirtschaftsforschung. Unternehmensinsolvenzen in Europa, Jahr 2025, May 2026. creditreform.de