How Keizu monitors for change

What gets re-checked

For a company under monitoring, Keizu re-fetches its current state from the source register and compares it against the last recorded state for that entity. The comparison is structured, not a raw text diff - it distinguishes five kinds of change: a new filing, a change in ownership, a change in registration status, a change in whether the register itself is currently accessible, and what Keizu calls a possible discrepancy - a signal worth a human look rather than a clean, classifiable change.

Why "possible discrepancy" is its own category

Not every difference between two fetches is a real-world change. A register temporarily returning incomplete data, a parsing edge case, or a genuine but ambiguous filing can all produce a difference that isn't simply "ownership changed." Keizu keeps this case distinct rather than forcing it into one of the other four categories, so a compliance reviewer looking at a company's signal history can tell the difference between a confirmed change and something that needs a second look.

Re-check frequency

How often a monitored entity is re-fetched is a deployment-level setting, not a fixed promise baked into the product - it depends on the register's own update cadence, its access terms, and the monitoring tier configured for that entity. We'd rather state that plainly than publish a specific interval here and have it drift out of sync with what a given deployment actually runs. Pricing describes what's included at each tier; if a specific SLA on re-check frequency matters to your use case, ask us directly rather than assuming a number from this page.

What this is not

This is not a live feed or a webhook pushed the instant a register changes - registers themselves don't offer that. It's scheduled re-resolution: the same resolution engine described in how Keizu determines a UBO, run again against fresh data, with the difference from last time recorded as a structured event rather than silently overwriting the previous result.