Start with a resolved company
Attach monitoring to the identifier and resolved company evidence selected during onboarding, not to a free-text name.
SCHEDULED COMPANY MONITORING
Recheck supplier and customer records after onboarding.
Recheck resolved supplier and customer company records after onboarding on a daily, weekly, or monthly target cadence.
START WITHPreviously resolved company recordREVIEWChange events + review evidence
Design the control around your systems and policy.Define countries, inputs, match rules, exceptions, evidence and delivery before integration.
WHEN TO USE IT
Keep supplier and customer records current when company status, identity or registration details change.
Use the company match as structured evidence inside the operating workflow. Keep inputs, results, source, retrieval time and exceptions together.
- Approved suppliers remain active for long periods without being re-onboarded.
- Customer or merchant risk policies require event-driven or periodic review.
- Material registry changes need to trigger an ERP, KYB or case-management workflow.
THE WORKFLOW
Four steps. One clear result boundary.
Define material changes
Choose which supported company-status, legal-name, address, registration-number or VAT-number changes matter to the policy.
Receive and classify events
Review changes in the workspace or deliver them through the documented REST, MCP or webhook route.
Record the disposition
Keep the event, source, review outcome and resulting action in the customer or supplier record.
WHAT YOU CAN REVIEW
The record, not just the number.
Fields vary by country, company and delivery method. The web interface can label missing values; REST and MCP clients must also handle optional fields that are absent.
- 01Company status changes
- Updates to the source-reported legal-company status when available.
- 02Identity changes
- Supported legal-name, registration-number or VAT-number changes linked to the monitored evidence.
- 03Address changes
- New registered-address information that may require review.
- 04Event context
- The previous and current values with source and timing information.
- 05Workflow outcome
- The internal review, escalation or record update triggered by the event.
CONTROL OWNERSHIP
Give each team one clear responsibility.
A reliable workflow names who owns the input, who interprets the company evidence and who makes the wider decision. That separation prevents a data result from becoming an unexplained approval.
Third-party risk
Define which company changes require re-review and by when.
Vendor or customer operations
Investigate events and update operating records.
Compliance governance
Record the disposition and ensure consequential decisions remain controlled.
DECISION DESIGN
Define the evidence and action at each stage.
| Stage | Evidence to retain | Controlled action |
|---|---|---|
| Baseline | Approved legal entity, identifiers, address, status, source and verification time. | Create the monitored record from a resolved company—not a free-text name. |
| Change detection | New source value, prior value, event type and observed time. | Deduplicate and classify changes by policy relevance. |
| Re-review | Event context, refreshed company evidence and reviewer decision. | Update, request information, suspend or take no action with a recorded reason. |
IMPLEMENTATION CHECKLIST
Questions to settle before launch.
- Define material events separately from ordinary data refreshes.
- Set severity and response time by event type and counterparty risk tier.
- Link every event to the original resolved company evidence and downstream case.
- Suppress duplicate notifications without hiding repeated unresolved risk.
- Version the evidence used after each material re-review.
WHAT TO MEASURE
Prove the control is useful.
Track operating quality rather than claiming that a company match guarantees the downstream outcome.
- Material events reviewed within policy SLA
- False-positive and duplicate-event rate
- Monitored records still linked to an active canonical entity
READ THE RESULT CORRECTLY
Monitoring coverage depends on source and configured events.
The public lookup does not automatically monitor every result. Monitoring must be explicitly activated with a daily, weekly, or monthly target cadence and selected fields. It tracks source-labelled company-record evidence, not live tax-authority status, and each alert still needs an accountable review process.
Review data and limitationsIMPLEMENTATION QUESTIONS
Before you implement the workflow.
These answers define where company identity evidence fits—and what controls must remain separate.
Why monitor after onboarding?
Company details can change after the original check. Monitoring helps identify events that may affect vendor, customer, merchant or compliance records.
Which changes should trigger review?
Typical triggers include status, legal-name, address and identifier changes. The correct set depends on the organisation’s risk and operating policy.
Does every change indicate risk?
No. Many registry changes are routine. Monitoring should route events for proportionate review rather than treating every update as adverse.
Can events be delivered through an API?
Yes. Configured monitors expose events through the workspace, REST API, MCP tools and signed webhooks.
What information should be prepared before this workflow starts?
Start with previously resolved company record. Use the legal entity and jurisdiction shown on a current business document, and keep the submitted value with the returned evidence so a reviewer can reconstruct the check.
Which evidence should the workflow retain?
Retain the submitted identifier, selected jurisdiction, change events + review evidence, company status changes, identity changes, address changes, source, retrieval time, explicit result status, and any exception or reviewer decision. Do not store only a pass/fail label.