Romanian Registry Change Monitor (ONRC) — CAEN-Sector Change Feed

Monitor the Romanian company registry (ONRC) for changes in a target CAEN activity sector: new registrations, deregistrations, and status flips (funcțiune / insolvență / dizolvare / lichidare / radiată / …). A scheduled monitor — run it daily or weekly and consume only what changed since a date, instead of re-pulling the whole registry.

Built for the recurring-revenue slot in the Romanian business-data niche: directory lookups are one-shot, a change feed is something customers schedule.

What it does

For the requested CAEN code (default 6201 — software development), the actor emits one dataset item per change:

Field	Meaning
cui	Company fiscal code (CUI)
company_name	Registered company name
caen	Matched CAEN code (version-resolved)
county	County (județ)
event_type	NEW_REGISTRATION / DEREGISTRATION / STATUS_CHANGE
status_before	Previous status (null for new registrations)
status_after	New status (null-able)
event_date	Registration date (new) or dump date (status changes)
source_url	Where the record came from

Plus source, caen_requested, and detected_at for provenance.

How it works — two layers

1. Live freshness layer (cuiscan.ro public API). New registrations get sequentially-allocated CUI numbers, so the newest firms sit at the top of the CUI range. The actor probes a CUI window (default anchored just above the observed Aug-2026 frontier) and reports firms whose declared CAEN matches the requested sector and whose registration date is >= since. This is what makes since dates inside the current month return records while the official dump lags.

2. Official dump delta layer (data.gov.ro monthly ONRC open data). Every month ONRC publishes a full-registry snapshot (od_firme.csv, od_caen_autorizat.csv, od_stare_firma.csv). The actor streams the newest dump filtered to the target CAEN codes, diffs it against the last-seen snapshot stored in the key-value store, and emits exactly the changes — the authoritative source for STATUS_CHANGE and DEREGISTRATION. Idempotent: a dump is processed once (keyed by dump id), and when the newest dump predates since the layer is skipped entirely.

CAEN version aliasing. The registry migrated from CAEN v2 to v3; "software la comandă" is 6201 in v2 and 6210 in v3 (same activity name in the official n_caen.csv). The actor resolves the requested code to all codes sharing its activity name across versions, so caen: 6201 also matches v3-coded firms.

Input

Field	Type	Default	Description
caen	string	6201	Target CAEN activity code. Version-equivalent codes matched automatically.
since	string	last 30 days	Report only changes with event_date >= this date (YYYY-MM-DD).
county	string	—	Restrict to one county (e.g. Cluj, Bucuresti). Empty = all.
output	string	json	json = one item per change; table = same records plus a human-readable summary field.
maxItems	int	100	Max change records emitted per run.
probeBudget	int	1500	Max CUI probes in the live layer per run.
frontierStart	int	55449500	CUI anchor for the first live probe (see frontier note below).
useLiveLayer	bool	true	Enable the cuiscan freshness probe.
useDumpLayer	bool	true	Enable the official dump delta layer.

Example input:

{
  "caen": "6201",
  "since": "2026-08-12",
  "output": "json",
  "maxItems": 100
}

Frontier note (important for scheduling)

New companies get the next available CUI number, so the frontier moves up over time. The actor keeps a frontier cursor in its named KV store: the first run probes downward from frontierStart (default anchored just above the observed Aug-2026 frontier) to cover the recent window; later runs probe upward from the last-known frontier, catching only newly allocated CUIs — efficient daily monitoring without re-probing history.

If the registry outgrows the default anchor (months from now), raise frontierStart above the newest CUI you know, or clear the actor's KV store to force a fresh downward sweep.

Output

One dataset item per change (see table above). Nothing is emitted when nothing changed in the window. Example:

{
  "cui": 55449288,
  "company_name": "PIXELMAN GAMING S.R.L.",
  "caen": "6210",
  "county": "MUNICIPIUL BUCUREŞTI",
  "event_type": "NEW_REGISTRATION",
  "status_before": null,
  "status_after": "funcțiune",
  "event_date": "2026-08-18",
  "source_url": "https://cuiscan.ro/api.php?action=company&cui=55449288",
  "source": "cuiscan",
  "caen_requested": "6201",
  "detected_at": "2026-08-19T09:00:00.000000+00:00"
}

Use cases

• Lead generation — new companies in a sector = fresh prospects (software shops registering this week, etc.).
• Insolvency / risk monitoring — status flips (funcțiune → insolvență) for a watchlist sector.
• Market intelligence — deregistrations and new entrants per CAEN.

Idempotency & re-runs

• The emitted-set in the named KV store (ro-registry-change-state) prevents duplicate emission across runs with the same since date.
• The frontier cursor makes consecutive runs probe only new CUIs.
• The dump snapshot is keyed by dump id, so a dump is never processed twice.

Pricing

Pay per event — result per change record emitted (set at launch; this build is held private until Adrian decides). Nothing emitted, nothing charged beyond the actor start.

Limitations

• The live layer relies on cuiscan.ro's public API, which rate-limits aggressive probing — the actor paces probes (~0.4 s) and budgets its window per run. Very wide since windows with a small probeBudget may not cover the whole window in one run; the frontier cursor covers the rest on subsequent runs.
• Status changes and deregistrations come from the monthly ONRC dump, so they reflect the latest published dump, not intra-month flips.
• The official dump is published monthly; when it predates since, only the live layer contributes records for that window.