Before you begin
You need an access token and your partner id. See Authentication and first request.
X-Partner-Id is required on every route below and is
checked against the OAuth principal.
Monitoring is available to enabled partners. Until we confirm
activation for your production integration, monitoring routes can
return 503 MONITORING_UNAVAILABLE or
503 BUSINESS_MONITORING_UNAVAILABLE. Contact your
Admiin integration contact before treating monitoring as active.
The two products
Monitoring covers two separate things. Every route takes a
product and they do not overlap.
product |
What it watches |
|---|---|
INDIVIDUAL_AML |
A verified individual, for PEP and sanctions changes. |
BUSINESS_DETAILS_OWNERSHIP |
A business's registered details and ownership. Named after the screening service's own wording so it is never read as AML coverage. |
BUSINESS_DETAILS_OWNERSHIP is only available for a
verification bound to a completed business lookup and a durable
payer contact. The server follows that exact verification to its
lookup and organisation. It never selects the latest lookup for the
contact.
Adverse-media monitoring is deliberately not selectable. The screening service gives no way to choose a coverage level, and cross-border disclosure of adverse-media screening is unresolved.
Business change alerts
Business monitoring reports registry events for eligible Australian organisations after a completed ownership report. An alert does not update the ownership structure. A court-action alert is a registry event and does not by itself establish an ownership change.
Business evidence contains event with
eventType, eventDate,
summary and
ownershipDetailsStatus: NOT_REFRESHED. Review the event
locally. Receiving or opening it does not purchase a report. A
refreshed ownership report is a separate purchase.
Use state: ENABLED for either product. Obtain a preview
for the same verification, product and command, then submit its
exact previewToken,
authorityConfirmed: true and an idempotency key.
The business preview shows the applicable currency and monthly rate. A full UTC calendar-month fee accrues after confirmed activation, without proration. Collection occurs after that month closes. Report refreshes are excluded. Existing subscriptions without recorded authority are not retrospectively charged.
Settings and overrides
GET /v1/verifications/{verificationId}/monitoring?product=INDIVIDUAL_AML
PATCH /v1/verifications/{verificationId}/monitoring
Include product, state and an
idempotencyKey. Enabling also requires
authorityConfirmed: true and the preview's opaque
previewToken. Disabling does not require billing
consent or a preview.
State is exact: ENABLED or DISABLED. There
is no partner default, contact override or inheritance on a
verification route. A new verification for the same contact starts
independently.
Each product starts DISABLED. Eligible subjects are
materialised only through explicitly accepted authority and are
never resubmitted for KYC by preview or simulation.
Preview the cost
POST /v1/verifications/{verificationId}/monitoring/previewPreview returns the exact command, cohort and unit price before you make the change. The opaque token binds those values to this verification and payer. Two separately enabled verifications for one contact are two disclosed service units and may each be charged.
Subjects
GET /v1/verifications/{verificationId}/monitoring/subjects?product=INDIVIDUAL_AML
GET /v1/verifications/{verificationId}/monitoring/subjects/{subjectId}?product=INDIVIDUAL_AML
PATCH /v1/verifications/{verificationId}/monitoring/subjects/{subjectId}
A subject is one eligible person or the bound organisation in this
verification. The PATCH excludes or re-includes that
subject without changing any other verification.
Subscription webhook events
Four events report what the screening service is actually running
for a subject. Only terminal states are sent: the pending states in
between are our own retry loop. Every event carries
contactId, product and
occurredAt. Full payload shapes are in
Webhooks.
| Event | What it means |
|---|---|
monitoring.subscription.enabled |
The contact is monitored. Carries
coverage when one is recorded.
|
monitoring.subscription.disabled |
The contact is no longer monitored. No further alerts will open until it is re-enabled. |
monitoring.subscription.coverage_mismatch
|
The contact is screened at
observedCoverage, not at
requestedCoverage. Treat it as an open
compliance issue, not an informational ping.
|
monitoring.subscription.error |
The subscription is failing at the screening service. No
coverage is claimed and no error code is sent, because we
cannot assert what is being screened while it fails. Treat
the contact as not reliably monitored until an
enabled event follows.
|
Alerts
GET /v1/verifications/{verificationId}/monitoring/alerts?product=INDIVIDUAL_AML
GET /v1/verifications/{verificationId}/monitoring/alerts/{alertId}?product=INDIVIDUAL_AMLAn alert is raised when a monitored subject changes. Subscribe to the monitoring webhook category to be told as they arrive rather than polling. See Webhooks.
Alert webhook events
| Event | What it means |
|---|---|
monitoring.alert.created |
A new compliance case is open against a monitored contact. A possible match to adjudicate, not a verdict. |
monitoring.alert.updated |
An existing case changed, most often because it was
adjudicated and status moved off
OPEN. The category set can also widen.
|
Both carry monitoringAlertId, contactId,
product, categories and
status and nothing else. No name, no screening-service
entity id, no article snippets or URLs and no raw match records are
pushed: fetch those from the alert and evidence routes above.
Evidence
GET /v1/verifications/{verificationId}/monitoring/alerts/{alertId}/evidence?product=INDIVIDUAL_AMLReturns the live match evidence behind an alert: the matched entity detail that caused it to fire. This is fetched from the screening service when you call it.
Evidence is personal information. Handle and store it in line with your data-handling obligations and the partner agreement.
Classifying an alert
POST /v1/verifications/{verificationId}/monitoring/alerts/{alertId}/classifyRecord your decision on an alert, whether the match is your customer or not. Classification is your AML/CTF record of the review, so classify every alert you action rather than only the ones that turn out to be real.