Legal, Compliance & GovTech
Regulatory Change Monitoring API
Rules change constantly and announce themselves badly. The difficulty is not finding the change — it is working out whether it touches you.
- Compliance software vendors
- GRC platforms
- Banks and insurers
- Regulated industry operators
- Law firms and advisers
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
A regulated firm of any size is subject to rules from a dozen bodies across every jurisdiction it operates in, and those rules change through consultations, final rules, guidance notes, enforcement actions, technical standards and quiet updates to an existing handbook. Each regulator publishes differently: some have a clean feed, some bury amendments in a PDF, some update a web page in place with no notice at all.
Most firms handle it with people. Someone in compliance reads what they can, forwards the relevant items, and maintains a spreadsheet of upcoming obligations. It works until coverage grows, and it fails invisibly — nobody discovers the update that was not read until an examination or an incident finds it for them.
The genuinely hard part is relevance, not collection. A new rule on operational resilience reporting matters enormously to one business line and not at all to another, and the mapping between a published rule and the internal functions, processes and controls it touches is specific to each firm. That mapping is where a monitoring product either becomes indispensable or becomes another inbox nobody reads.
Who buys this
Compliance software vendors, GRC platforms, Banks and insurers, Regulated industry operators, Law firms and advisers
What the API returns
What comes back
- Change events with source document, publication date and status — consultation, final, in force
- Diffs against the previous version where a regulator amends existing text in place
- Classification by regulator, jurisdiction, instrument type and subject
- Relevance mapping to the firm's own functions, processes and controls
- Key dates — consultation close, implementation deadline, transitional end
- Obligation summary in plain language, with every assertion cited to the source text
- Enforcement action monitoring as a signal of supervisory focus
- Coverage register stating exactly which sources are monitored and how often
Endpoints
| Method | Path | Returns |
|---|---|---|
| GET | /v1/changes | Regulatory change events filtered by regulator, jurisdiction and status |
| GET | /v1/changes/{id} | Full detail including source text, diff and key dates |
| POST | /v1/relevance/map | Map changes to a firm's functions, processes and controls |
| GET | /v1/deadlines | Upcoming implementation and consultation deadlines |
| GET | /v1/enforcement | Enforcement actions by regulator and theme |
| WS | /v1/stream | Push change events as they are published |
Request and response
illustrativeRequest
{
"subscriptions": [
{ "regulators": ["eu-eba", "gb-fca"], "jurisdictions": ["EU", "GB"],
"subjects": ["operational_resilience", "outsourcing", "ict_risk"] }
],
"map_to_profile": "profile_grp_12",
"statuses": ["consultation", "final", "in_force"],
"since": "2026-09-01"
}Response
{
"generated_at": "2026-10-21T06:30:00Z",
"changes": [
{
"change_id": "chg_30f71",
"regulator": "gb-fca",
"instrument": "handbook_amendment",
"title": "Amendments to operational incident reporting thresholds",
"status": "final",
"published": "2026-10-17",
"in_force": "2027-04-01",
"diff": { "sections_changed": 4, "obligations_added": 2,
"obligations_removed": 0 },
"summary": "Reporting threshold for operational incidents lowered and the initial notification window shortened to 24 hours.",
"citations": [ { "section": "SUP 15.14.3", "page": 11 } ],
"relevance": [
{ "function": "operations", "process": "incident_management",
"control": "ctl_incident_notify", "basis": "obligation_scope_match",
"score": 0.91 }
],
"action_required_by": "2027-04-01"
}
],
"coverage_note": "3 monitored sources publish by in-place web update; detected by scheduled diff, not by feed.",
"advice_note": "Summaries are drafting aids for qualified staff, not legal advice."
}Where the data comes from
| Official regulator publications | Primary sources — handbooks, registers, consultation pages and technical standards, which is where the authoritative text lives |
| Legislative gazettes and registers | Official journals and statute databases for primary and secondary legislation |
| Regulator feeds and alert services | Where a clean machine-readable feed exists, which is the minority of cases |
| Enforcement and decision notices | Published actions, which indicate supervisory priorities earlier than rule changes do |
| Your own control and process register | The other half of the product: without the firm's own mapping there is nothing to be relevant to |
| Licensed legal research sources | Where consolidated or annotated text is needed, under a licence that permits redistribution through your product — most do not permit passing the text itself on |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Source-specific collection per regulator, including scheduled differencing for bodies that edit pages in place without publishing a change notice
- Document versioning with structural diffing at section level, so an amendment is reported as what changed rather than as a new document
- Obligation extraction into actor, action, condition and deadline, which is what makes relevance mapping possible at all
- Relevance scoring against the firm's own function, process and control register, trained and tuned per tenant because the mapping is firm-specific
- Summaries generated under citation constraint: every assertion must point to source text and is validated against it before release, with the summary withheld if validation fails
- Explicit status modelling — consultation, policy statement, final rule, in force — since acting on a consultation as if it were binding is its own failure
- Coverage register published as data, so a compliance officer can see what is monitored, by what method and when it was last checked
- False-negative monitoring against regulator-issued change lists where those exist, because a missed change is the failure that matters here
What it changes for the business
Fewer missed changes
Scheduled differencing catches in-place amendments that feed-based monitoring never sees.
Relevance instead of volume
Mapping to the firm's own controls turns a daily digest into a short list with owners.
Evidence for examinations
A dated record of what was published, assessed and actioned is what a supervisor asks for.
Earlier implementation starts
Deadline tracking from consultation stage gives projects months rather than weeks.
How it fits into your product
How it embeds
- Alert feed into your GRC platform, with relevance scoring applied before anything reaches a user
- WebSocket and webhook delivery so a change becomes a task in your workflow, not an email
- Control register import so mapping runs against the firm's actual framework
- Deep links to the source document and the changed section, since a compliance officer will always want to read the text
- Per-tenant relevance tuning with feedback capture, because the first month of mapping is always wrong somewhere
- Deployment inside your infrastructure where control and process registers cannot leave
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 20 weeksDiscovery and feasibility
Weeks 1–3
This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.
Architecture and baseline model
Weeks 4–6
A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.
Production build
Weeks 7–16
Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.
Validation and integration
Weeks 17–20
Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
Is this legal advice?
No. The API reports that a rule changed, what the text says, and which of your registered controls it appears to touch. Deciding what the firm must do about it is regulatory and legal judgement that belongs to your compliance function and your advisers. The summaries are drafting aids with citations attached, built so a qualified person can check them quickly, not so they can be skipped.
Can you guarantee nothing is missed?
No, and we would not accept a contract that said otherwise. Some regulators amend web pages silently, some publish only in PDF, and some change a definition in an annex with no change log. Scheduled differencing catches most of it. What we will do is publish the coverage register as data — which sources, which method, last checked — so the gaps are visible rather than assumed away.
How is relevance determined?
By mapping extracted obligations onto your own function, process and control register, scored and explained. It is firm-specific and it needs tuning: expect the first few weeks to produce both false positives and missed mappings, with your feedback improving it. A vendor claiming accurate relevance on day one has not done this before.
Can you redistribute the regulatory text itself?
Official primary sources are usually reproducible, often under an open government licence, but the terms vary by jurisdiction and body. Consolidated and annotated text from commercial legal publishers almost never is — you may read it, not pass it on. We design around that, which sometimes means linking rather than displaying, and we identify the licensing position per source during discovery.
What about jurisdictions where we have no coverage?
We say so rather than returning an empty result that looks like 'no changes'. The coverage endpoint distinguishes monitored-and-quiet from not-monitored, which is a difference that matters a great deal during an examination.
Related blueprints
Contract Intelligence API
Clause extraction, obligation tracking and renewal alerting across a contract portfolio, as an API your legal or procurement software embeds.
Permit and Licence Intelligence API
Permit and licence requirements, application status and renewal alerting across jurisdictions, as an API for operations and compliance software.
Litigation Intelligence API
Case search, filing summaries and trend analysis over court records, as a research layer inside legal software or an insurer's claims system.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.