Monitoring supplier and vendor risk with public company signals

A supplier list of several hundred companies is too long to check by hand every week. This guide shows how a procurement or third-party risk team can screen it with public company signals: restructuring and leadership announcements from company newsrooms and regulatory disclosures, a collapse in hiring, changes to a supplier's website and its stated headcount. It covers how to match suppliers to the data, how to turn the signals into a short review queue with the evidence attached, and which false alarms to expect.

The signals and what each can tell you

A signal points to a supplier worth a closer look. It is a prompt for review, and the table pairs each signal with the dataset it comes from and the usual false alarm.

From a supplier list to a company ID

Every dataset is keyed by company_id, the one stable Fokals company ID, so the first job is matching. Match every supplier on its website domain, and a listed supplier also on isin, lei or ticker with mic. A subsidiary carries the identifiers of its listed parent, so a join on isin returns the parent and every brand or subsidiary under it, with all their announcements. Decide whether you want that, and keep the supplier's own company_id as the key.

Then measure coverage before you trust the screen. Count the suppliers with a company ID, with Hiring Activity rows, with Company News rows, and listed. Report that share to whoever owns the programme: a supplier that is thin on one signal is watched through the others and through a manual check scheduled by its tier.

A weekly screen

The SQL is PostgreSQL, with lists and objects held as JSON as delivered. suppliers is your own table with supplier_id, company_id and a criticality tier. The first query lists announcements from Company News in the last seven days that match the event types above.

select
  s.supplier_id, s.tier, n.at, n.event_types, n.roles, n.role_labels, n.items, n.title, n.url
from suppliers s
join company_news n on n.company_id = s.company_id
where n.at >= current_date - 7
  and n.event_types::jsonb ?| array[
    'layoffs_restructuring', 'leadership_change',
    'acquired_or_merged', 'incident', 'regulatory_or_legal']
order by s.tier, n.at desc;

The second query reads Hiring Activity to find a hiring collapse: at least 20 open postings at the 90-day peak, half or fewer open now, and at most one new posting in 28 days.

with d as (
  select
    company_id, day, open_postings,
    sum(new_postings) over (partition by company_id order by day
                            range between interval '27 days' preceding and current row) as new_28d,
    max(open_postings) over (partition by company_id order by day
                             range between interval '89 days' preceding and current row) as peak_90d
  from company_hiring_daily
)
select s.supplier_id, d.day, d.open_postings, d.peak_90d, d.new_28d
from d
join suppliers s using (company_id)
where d.day = (select max(day) from company_hiring_daily)
  and d.peak_90d >= 20
  and d.open_postings <= 0.5 * d.peak_90d
  and d.new_28d <= 1;

The floor of 20 keeps small boards out, the half-of-peak test says half the roles have gone, and one new posting in 28 days says nothing replaced them. Because every day is written once and never revised, the 90-day peak is the same figure whenever you run the query. To pull announcements across all companies through the REST API instead, filter by event type and since date, and match to your suppliers locally:

GET /api/v1/news?since=2026-09-28&event_type=layoffs_restructuring&limit=200
Authorization: Bearer <your key>

Rows from /news come newest first and carry no excerpt. The supplier's own text is in GET /api/v1/companies/{id}/news.

Reading headcount and site changes

These two move more slowly than announcements and hiring, and they help most as confirmation.

Headcount. Employee Headcount holds stated headcount over time, one row per company, date and source. Compare two points from the same source, because a change between two different bases compares two methods, not two years. A stated figure is as current as the company's own report, so read the date beside it and treat the movement between two reports as a trend to confirm.

Site changes. In Technology Changes, three page events carry the most meaning for a supplier: careers removed while open postings fall, status removed from a software or service supplier, and api_docs removed from a supplier whose product you integrate with. Each can also be a redesign, so read the platform events of the same observation first. A supplier that changed platform and removed three pages at once has most likely redesigned its site.

Turning signals into a review queue

Count signals by family, not by volume. The families are announcements, hiring, site changes and stated headcount. Two hiring signals are one family; a restructuring announcement and a hiring collapse are two.

An illustrative case: Acme Robotics supplies a component you cannot replace quickly. Its newsroom announces a restructuring, typed layoffs_restructuring, and in the same week its open postings fall from 41 to 18 with no new postings. That is two families, so the supplier reaches Escalate. The review reads the newsroom item at its url and finds that the restructuring concerns a sales unit, so the announcement is logged as unrelated to supply and the hiring signal stays on watch.

Keep the evidence with every alert: the dataset it came from, the at or observed_at time, the url where there is one, and the label_version. Every record is dated and written once, so the conversation with the supplier can cite exactly what was seen and when.

False alarms and how to cut them

A change of board looks like a collapse. A move to another applicant tracking system can make a board look empty for a time. A fall to zero followed by a return to the earlier level is a change of board. Wait a second week before you act on a drop to zero.

Small boards. A supplier with six postings that closes three has halved, and that tells you little. Keep the floor.

Event types are a first read. Company News classifies each item into 13 event types, and a regulatory disclosure is typed from its item number, such as 2.05 for exit costs and 5.02 for an officer change, so it is as specific as the item. Read the item at its url before you act.

Group news and unit news. A parent's restructuring may concern a unit that does not supply you. The excerpt in Company News is the company's own text and says which.

Seasonal and project hiring. A supplier that hires in waves will dip between them. Compare with the same period of the previous year where it exists.

How to read a quiet supplier

Companies announce what they choose to announce, and a company in difficulty may say nothing, so a quiet newsroom is not a clean bill of health. Credit-reference reports, filings and your own delivery data answer whether a supplier can pay its bills or meet a date, and these signals decide which suppliers to look at first.

A leadership change is recorded by role and direction. The signals are company-level throughout, and the supplier's own announcement names whoever it chose to name. You pull the signals on your own schedule, by REST API or as bulk files, and set the alert rules in your own tooling.

How Fokals delivers it

The announcements and scale dataset holds Company News, with the event type, the disclosure item numbers and the role behind a leadership change, and Employee Headcount. Announcements refresh daily to every three days and Hiring Activity daily. The data is collected from first-party company sources and public records and processed in-house, and each record carries the time it was observed, so an alert can go to the account owner with its evidence; the sourcing statement sets out what is collected. For the same signals read for investors, see detecting restructuring early from postings and announcements and company signals in credit research.

Frequently asked questions

The queries and code on this page are examples to adapt. Test them in your own environment before you rely on them.