Customer 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 4089List events returns the triage queue: each event is a thing your team should look at, produced by a screening check, such as a PEP or sanction match, a phone or email match or an adverse media hit. Events carry a lifecycle status from new through investigating to a closure with a reason, and filters narrow the queue by status, check type, entity, program, check and date.
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.
Screening produces matches; someone has to decide which are real. The events list is that queue: what is new, what is being investigated, and what was closed and why. A case system pulls new events from it and writes decisions back with Update an event.
The check type that produced it, a check summary of what was searched, the entity and program it belongs to, the originating check UUID, and the check result identifiers that point at the underlying match data.
The status of new, investigating or one of the four closures, and how many notes are attached.
Under separate grouping the check response index says which match in the parent check the event represents. Under grouped, it is null and the event aggregates every match for the entity.
Filter by status, check type, entity, program, check, and created between two times. The archived parameter selects archived or non-archived events. Sort by created at or status.
A match arrives as a new event. Someone picks it up as investigating. It is closed with one of four reasons, of which only closed confirmed means the match was real.
Events are not deleted on their own; closing sets the status to one of the closed values. A filter that targets an entity, program or check UUID that does not exist on the account returns an empty page.
The status carries the triage decision. The four closures are not interchangeable: three record why a match was not real, and one records that it was.
Screening produced a match that someone should review. The check summary says what was searched, the check result identifiers point at the underlying match data, and the notes count is zero until someone writes one.
A person or an integration has picked the event up. Notes attached along the way record what was found, and the event stays here until it is closed with a reason.
The only closure that means the screening found something true. The other three, dismissed, duplicate and error, record why the match did not stand, which is the reporting value of the queue.
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 an event reads one event with its notes. Update an event moves it through triage and attaches notes. Show a check reads the match data an event points at.
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