What’s new

8 October 2026

Superseded alerts and business event text

Superseded alerts

• Alerts have a new status, SUPERSEDED. When the matches for a monitored person change, a new alert opens and the earlier open alert for the same person and product closes as SUPERSEDED. Before this, the earlier alert stayed open and could not be decided.
• Alerts have a new field, supersededByAlertId. It names the alert that replaced this one and is null on every other alert.
• You receive a monitoring.alert.updated webhook with status SUPERSEDED. Review the newer alert instead. A superseded alert refuses every decision, REOPEN included, with 409 ALERT_ALREADY_CLASSIFIED. Its evidence can still be read.
• Only open alerts are superseded. An alert you have decided is never closed this way. Treat SUPERSEDED as closed in your own grouping and accept it as a status filter value.
• If a superseded alert’s matches become current again, it returns to OPEN and the newer alert becomes SUPERSEDED. You get a monitoring.alert.updated webhook for each change.
• An alert that moves into the same status again, for example OPEN after a reopen, now always sends monitoring.alert.updated. Before, a repeat was not sent. De-duplicate alert webhooks on type, monitoringAlertId, status and occurredAt, not on status alone.
• Webhook notification ids for monitoring.alert.updated now end in the alert revision, for example monitoring-alert:{alertId}:OPEN:r3, followed by the endpoint suffix. Treat notification ids as opaque.

Business event description

• Business alert evidence now includes description in event: Admiin’s description of the reported event, when known, for example Court action lodged. It is null when the event is not one we describe and on alerts opened before this release.
• A reported business event with no valid date now opens an alert with eventDate null instead of being held back.

Demo simulation

• The monitoring simulate route in Demo now sends the same notification shape as Production, for both individual and business monitoring. Simulated alerts follow the production path end to end. Repeated business simulations open separate alerts. A simulated business event has a null description.

Alert decisions

• A decision on an individual alert no longer has a 15 minute time limit after you read the evidence. The listings are checked again when the decision is recorded. 409 EVIDENCE_STALE no longer means your read is too old. It means the listings changed since you last read the evidence, or you have not read it. Read the evidence again, review the update and decide. If the listings cannot be checked you get 503 EVIDENCE_UNAVAILABLE and no decision is recorded.
• The onboarding AML review has no time limit either. You can submit result tokens to aml-matches/dispositions however long ago you read aml-matches/evidence. The results are checked again when the decision is recorded. 409 EVIDENCE_STALE means they changed since your last read, or you have not read them. If they cannot be checked you get 503 AML_PROVIDER_READ_UNAVAILABLE and no decision is recorded. The decision is your own, made under your AML/CTF program.

6 October 2026

Monitoring review, PEP class and alert fixes

PEP class

• Monitoring alert decisions accept a PEP class in pepSubtype: FOREIGN, DOMESTIC, INTERNATIONAL_ORG or FORMER. Send it with a true-positive decision on a case whose categories include PEP.
• pepSubtype becomes required for those decisions 30 days after this release reaches Production. We will add the exact date here when it does. From that date a decision without it returns 400 PEP_SUBTYPE_REQUIRED.

Monitoring evidence

• Ongoing monitoring covers PEP, sanctions and watchlists. Adverse media is no longer returned in monitoring evidence, alert categories or monitoring alert webhook categories.
• Evidence now includes groups: each screening search behind the listings, with a comparison of the searched and listed name, date of birth and country. Each listing carries the groupId of its search.
• Each listing has an opaque match id. It is stable for the case and is not a screening-service identifier.
• The dataSource field is now always null on monitoring evidence, AML matches, match groups and AML profile evidence. The field is kept so existing parsers keep working.
• Evidence includes sanctionsChecklist in Demo and Production. The current version is v2. Build the sanctions acknowledgement from it rather than hard-coding item ids or text. The checklist records your own steps under your AML/CTF program. The sanctions decision is yours.

Alerts and subjects

• Alerts carry the latest decision in disposition and the PEP class in pepSubtype. Classify responses and repeated requests with the same idempotency key return the decision you recorded.
• Business subjects in verification monitoring use an opaque subject id that starts with org_. Use it as returned. If you received a business preview before this release, request a new one.

Fixes

• Some matches for people monitored through a verification or a contact did not open an alert. They now do.
• Every opened case now sends a monitoring.alert.created webhook.
• A contact monitored both directly and through a verification now gets one case per match, on the verification. Two monitored verifications for the same contact still get a case each.
• On business cases, entityId is now your contact id, as documented. Earlier business cases return the contact id too.
• Repeating an enable or re-include request with the same idempotency key now returns the original result instead of 409 MONITORING_PREVIEW_ALREADY_USED.

25 September 2026

Passing verification results reach partner records

• A passing identity check now updates the individual and parent verification request when document approval was recorded before the final result arrived.
• Partners receive the usual completion webhook. The same check is not billed again when its result is processed.
• No integration change is needed.

23 September 2026

Previous addresses in hosted identity checks

• Enabled verification flows can ask people who moved within the last 12 months for an optional previous residential address.
• Selecting Yes opens a structured Australian address form. Selecting No, or skipping the form, continues without one.
• An accepted address is included as the second residential address in the original verification request, without creating a second submission.
• The form does not use address autocomplete. Audit metadata records the collection outcome and notice version without copying the address lines.

16 September 2026

Role-aware business ownership results

• Business lookups now report separate counts for beneficial owners, directors, officers and all returned parties.
• Ownership results expose clearer completeness, truncation and unlinked-owner details for reliable UI states.
• Lookup-bound verification responses now retain their business lookup reference and registered business name.
• Full ownership lookups can be bound automatically for identity checks. Organisation-only lookup parties must be selected deliberately instead.

11 September 2026

Ongoing monitoring for each verification

Available to enabled partners as part of a controlled production rollout.

• Enable or disable monitoring separately for each verification.
• View monitored subjects, alerts and supporting evidence through the API.
• Classify monitoring alerts and test monitoring events in non-production environments.

10 September 2026

More verification party roles

• Added support for settlors, protectors or guardians, other controllers, senior managing officials, authorised representatives and individual owners.
• Parties found during deed analysis can now be added to a verification without remapping their role.
• Existing roles are unchanged. Unrecognised roles continue to be saved as Other.

2 September 2026

Monitoring and deed analysis

• Manage monitoring settings and review alerts and evidence.
• Start a deed analysis and check its progress through the API.
• Receive webhook updates for monitoring and deed analysis.
• Verification failures now use a clearer, consistent set of reasons.

27 August 2026

Webhook categories and delivery controls

• Choose the webhook categories your integration receives, including payments, verifications, business lookups, customer billing, deed analysis and monitoring.
• Leave categories unset to receive all events or use an empty list to pause a destination.
• Send a test event from Developer settings before going live.

10 August 2026

Contact billing and verification changes

• Contact billing responses now explain payment failures in more detail.
• Verification and webhook examples are easier to follow.
• Existing integrations remain compatible with these changes.