Tranche 2 started 1 July — AML/CTF obligations now extend beyond financial services.
See who is coveredarrow_forwardCustomer onboarding, screening and ongoing monitoring in one system, with real-time KYC and KYB alerts when a customer's risk changes.
One-to-one identity, document and data checks against the DVS and Australian data sources, run from the Portal or by API.
Customers verify their own identity and biometrics from a link on their phone. The result comes back to you, and they keep control of their data.
Find, verify and identify consumers, with background and contact detail drawn from about 2 billion Australian records.
Verifies, corrects and enriches customer records so they stay accurate — one at a time or across your whole database.
The official national death data source. Match your records against it to find and remove deceased individuals.
Use cases
deceasedDeceased suppressionBuild targeted, privacy-compliant Australian marketing lists with smart filters. Pay only for the records you download.
Solutions
campaignB2C marketing listsUse cases
contact_phoneContact data validationConfirm a person or business is who they claim to be: government IDs, biometrics, business registries and employment checks against authoritative Australian sources.
Meet AUSTRAC obligations and understand customer risk: screening, risk assessment, fraud controls and investigation tools with evidence recorded for each check.
Keep customer records accurate and put them to work: correct and enrich existing data, unify it into a single view, or build compliant marketing lists from opted-in records.
Run the same checks from your own systems. See the developer docs for the full reference.
The WatchEye API gives programmatic access to everything in WatchEye: PEP and sanctions screening, identity checks, IDPass verifications, monitoring programs, events and reports.
Obligations under the AML/CTF Act, from screening at onboarding through to ongoing monitoring — with the evidence for each check recorded.
Verifying who a customer, employee or account holder is — at sign-up and during ongoing checks — against authoritative Australian sources.
Keeping customer records accurate, current and complete: validate contact detail, fill the gaps, locate people and remove deceased records.
9am–5pm AEST, Monday to Friday.
call03 9948 4089Running a monitor on demand queues an immediate run and returns 202 once it is scheduled. A run type of new screens only the entities created since the last run; all re-screens every active entity in the program. The screening happens in the background, and your system polls Show a monitor until the process status leaves pending and processing.
For the technical detail, go to the API documentation. It holds the request and response schema, the integration guides and the error codes for this endpoint.
New accounts begin with sandbox access.
A new sanctions list, a changed threshold, a batch of entities just loaded: each is a reason not to wait for the schedule. A run on demand screens the entities you choose and raises any new matches as events.
The new run type processes entities created since the last run, or every active entity on a monitor that has never run. The all run type processes every active entity regardless of history.
A 409 means the monitor is not runnable: most often it is already mid-run, or it is paused, or the account is inactive, with the reason in the message. A 402 means the account lacks credit for the projected billable count and returns a billing object with the breakdown.
Both run types bill only for entities eligible for the operation. A UK business check skips businesses outside the UK, for example.
An optional Idempotency-Key header returns the original 202 with the same monitor on a retry, marked with an Idempotent-Replay header, and the run is not queued twice.
The run returns 202 once scheduled. Your system polls Show a monitor and waits for the process status to leave pending and processing, then reads the new events in the triage queue.
A run across thousands of entities can take several minutes. Poll every 2 to 5 seconds for the first 30 seconds, then every 15 to 30 seconds.
Charges arise when screening runs against the entities in a program: each check type launched against an entity is charged at launch, and a monitor run is charged for each entity eligible for its operation. Rates are set for your account and communicated by your Global Data account manager, and statements with a per-call breakdown are in the WatchEye portal.
Show a monitor is the endpoint to poll for the run's progress. Update a monitor changes what the run screens with. List events reads what the run raised.
Sandbox accounts are provisioned by your Global Data account manager. API keys are created and managed in the WatchEye portal, and the same endpoints serve sandbox and live; the account behind the key decides which environment you are in.
Call 03 9948 4089, 9am–5pm AEST Monday to Friday