What does 'ongoing due diligence' mean under the AMLR?

The EU AMLR (Regulation (EU) 2024/1624, from 10 July 2027) treats a business customer's file as something to keep current, not a one-time gate: re-verify on a risk-based cycle and act on trigger events such as a dissolution or a new sanctions match. This describes the obligation in general terms, not legal advice — see /blog/amlr-2026-2027-compliance.

How often should I re-verify a business customer?

A common risk-based cadence is annual for low-risk customers and quarterly for high-risk ones, re-running the same checks used at onboarding. The exact cadence is a decision for your compliance function.

Can sanctions re-screening be automated?

Yes: GET /sanctions/changes?since= reports what was listed, delisted or updated since your last run, and POST /sanctions/screen re-checks up to 50 names per call. Sanctions screening is beta; PEP screening is beta, Spain only, and holds no relatives or close associates, so a clear result is not a FATF determination by itself.

Does ongoing monitoring work the same way in every country?

No. POST /monitor webhooks cover Spain, Ireland and Poland. GET /company-events/search covers Spain, France and the United Kingdom. Norway has no corporate-event stream, so Norwegian customers rely on the periodic lookup diff plus sanctions and insolvency checks. Ireland and Poland are company-level, with no officers to re-verify yet.

What happens if a review batch is bigger than my remaining quota?

POST /companies/lookup, POST /sanctions/screen and POST /insolvency/check count every item as one request. A batch larger than what is left on your plan is refused up front with a 429 (batch_exceeds_quota) and max_items_now, so you can resize the call instead of losing partial results.

Ongoing Due Diligence API — Perpetual KYB Under the AMLR

The EU Anti-Money Laundering Regulation (Regulation (EU) 2024/1624), applying from 10 July 2027, treats KYB as an ongoing duty, not a one-time gate at signup: keep customer records current, re-verify on a risk-based cycle, and act on trigger events. Today's AMLD5/6 transpositions and the UK MLR 2017 already point the same way. Prometiam turns that duty into a scheduled job against one REST API instead of a once-a-year manual re-check.

The pattern

Calendar-driven re-verification: re-resolve each customer with POST /companies/lookup (up to 100 items per call) and diff status, dissolution_date, address, legal_form and previous_names against the stored record — annually for low risk, quarterly for high risk.
Trigger-based monitoring: POST /monitor gives Spanish, Irish and Polish customers HMAC-SHA256-signed webhooks on corporate events, status changes and sanctions matches. A daily GET /company-events/search?date_from= sweep covers Spanish, French and British customers for dissolution, insolvency, director, capital, name and address changes.
Sanctions re-screening: GET /sanctions/changes?since= reports what was listed, delisted or updated since the last run, then POST /sanctions/screen re-checks the book (beta; PEP screening is beta, Spain only, and holds no relatives or close associates).
Insolvency: POST /insolvency/check covers nine corporate-insolvency markets (FR, DE, GB, AT, CH, NO, FI, US, NL); Spanish concursal notices are checked separately, on GET /search, not /insolvency/search.
Audit trail: store each response with its match_score, the threshold used, and the review date.

Scope and pricing

Norway has no corporate-event stream and sits outside the three countries POST /monitor covers, so Norwegian customers get the calendar-driven lookup diff plus sanctions and insolvency checks, not the daily sweep or webhooks. Ireland and Poland are company-level, with no officers to re-verify yet. A 5,000-customer book — annual re-verification, quarterly sanctions re-screening, and a daily events sweep for its Spanish, French and British names — runs to roughly 45,000 to 55,000 calls in its busiest month, inside the Professional tier (100,000 calls a month). A 500-customer book fits Starter. This describes what the API returns; it is not legal advice on whether a program satisfies the AMLR.

Frequently asked questions

What does 'ongoing due diligence' mean under the AMLR?: The EU AMLR (Regulation (EU) 2024/1624, from 10 July 2027) treats a business customer's file as something to keep current, not a one-time gate: re-verify on a risk-based cycle and act on trigger events such as a dissolution or a new sanctions match. This describes the obligation in general terms, not legal advice — see /blog/amlr-2026-2027-compliance.
How often should I re-verify a business customer?: A common risk-based cadence is annual for low-risk customers and quarterly for high-risk ones, re-running the same checks used at onboarding. The exact cadence is a decision for your compliance function.
Can sanctions re-screening be automated?: Yes: GET /sanctions/changes?since= reports what was listed, delisted or updated since your last run, and POST /sanctions/screen re-checks up to 50 names per call. Sanctions screening is beta; PEP screening is beta, Spain only, and holds no relatives or close associates, so a clear result is not a FATF determination by itself.
Does ongoing monitoring work the same way in every country?: No. POST /monitor webhooks cover Spain, Ireland and Poland. GET /company-events/search covers Spain, France and the United Kingdom. Norway has no corporate-event stream, so Norwegian customers rely on the periodic lookup diff plus sanctions and insolvency checks. Ireland and Poland are company-level, with no officers to re-verify yet.
What happens if a review batch is bigger than my remaining quota?: POST /companies/lookup, POST /sanctions/screen and POST /insolvency/check count every item as one request. A batch larger than what is left on your plan is refused up front with a 429 (batch_exceeds_quota) and max_items_now, so you can resize the call instead of losing partial results.