Skip to content
In force

Tranche 2 started 1 July — AML/CTF obligations now extend beyond financial services.

See who is coveredarrow_forward
WatchEyeOnboarding & monitoring

Customer onboarding, screening and ongoing monitoring in one system, with real-time KYC and KYB alerts when a customer's risk changes.

Visit WatchEyearrow_forwardcheck_circleIncluded in the Global Data Portal
IDFEX ID CheckIdentity verification

One-to-one identity, document and data checks against the DVS and Australian data sources, run from the Portal or by API.

Visit IDFEX ID Checkarrow_forwardcheck_circleIncluded in the Global Data Portal
ID PassSelf-service verification

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.

Visit ID Passarrow_forwardcheck_circleIncluded in the Global Data Portal
InsiightData quality

Verifies, corrects and enriches customer records so they stay accurate — one at a time or across your whole database.

Visit Insiightarrow_forwardcheck_circleIncluded in the Global Data Portal
Australian Death CheckDeceased data

The official national death data source. Match your records against it to find and remove deceased individuals.

Visit Australian Death Checkarrow_forwardcheck_circleIncluded in the Global Data Portal
QuesterMarketing lists

Build targeted, privacy-compliant Australian marketing lists with smart filters. Pay only for the records you download.

Visit Questerarrow_forwardcheck_circleIncluded in the Global Data Portal
verified_userVerify identities7 solutions

Confirm a person or business is who they claim to be: government IDs, biometrics, business registries and employment checks against authoritative Australian sources.

All solutionsarrow_forwardcheck_circleAvailable in the Portal and by API
policy_alertStay compliant6 solutions

Meet AUSTRAC obligations and understand customer risk: screening, risk assessment, fraud controls and investigation tools with evidence recorded for each check.

All solutionsarrow_forwardcheck_circleAvailable in the Portal and by API
databaseImprove your data3 solutions

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.

All solutionsarrow_forwardcheck_circleAvailable in the Portal and by API
monitoringWatchEye API14 categories

The WatchEye API gives programmatic access to everything in WatchEye: PEP and sanctions screening, identity checks, IDPass verifications, monitoring programs, events and reports.

View allarrow_forwardcheck_circleSandbox environment for integration testing
policyAML & screening6 use cases

Obligations under the AML/CTF Act, from screening at onboarding through to ongoing monitoring — with the evidence for each check recorded.

All use casesarrow_forwardcheck_circleMapped to the products and data that cover it
how_to_regOnboarding & identity3 use cases

Verifying who a customer, employee or account holder is — at sign-up and during ongoing checks — against authoritative Australian sources.

All use casesarrow_forwardcheck_circleMapped to the products and data that cover it
databaseData & enrichment4 use cases

Keeping customer records accurate, current and complete: validate contact detail, fill the gaps, locate people and remove deceased records.

All use casesarrow_forwardcheck_circleMapped to the products and data that cover it
Global Data
Portalarrow_forward
Productsexpand_more
Solutionsexpand_more
Use casesexpand_more
Dataexpand_more
APIarrow_forwardIndustriesarrow_forwardResourcesarrow_forwardAboutarrow_forwardContactarrow_forward Request a Demo
Talk to the team

9am–5pm AEST, Monday to Friday.

call03 9948 4089
WatchEye · Monitors

Run a monitor on demand

Running 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.

  • Screen only what is new, or re-screen everything after a configuration change
  • Entitlement, credit and run state checked before anything is queued, with a billing breakdown on a 402
For developers

After the technical detail?

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.

  • Request and response schema
  • Run types and pre-flight checks
Go to the API docs

New accounts begin with sandbox access.

ISO 27001 certified Handled under Australian privacy law Every API call written to the audit log
What the check gives you

Screening the whole program now, not on the next schedule

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.

Which entities were screened

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.

That the run was safe to start

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.

What it will cost

Both run types bill only for entities eligible for the operation. A UK business check skips businesses outside the UK, for example.

That a retry will not queue a second run

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.

How a check runs

Queued now, screened in the background, read from the monitor

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.

What it costs

Charged when screening runs, not when records are managed

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.

  • Billed per screening operation
  • Refunded if the provider fails
How billing works
Credits drawn down against your account balance
  • A screening check is charged per check type when it is launched, and refunded if the provider fails.
  • A monitor run bills only for the entities eligible for its operation; a UK check skips businesses outside the UK, for example.
  • A run that would exceed the account's credit is refused with 402 and a billing breakdown, before anything is queued.
  • Reads, lists and PDF downloads are not billed.
Talk to us about rates
Related checks

Others in WatchEye Monitors

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.

Questions

Questions we get asked about running a monitor

Do we need a developer to implement this?
Yes. The run is a REST call that queues the work, and Show a monitor is polled for completion, so a developer connects the two-step flow to your system. A sandbox account is available for development at no charge. It is a separate account with its own API keys, it returns test data in the same response shapes as live, and the same base URL serves both environments.
What does our system need to send?
The monitor UUID in the path and a run type of new or all. An Idempotency-Key header is optional.
What comes back?
A 202 with the monitor, its process status now pending, once the run has been scheduled.
How long does it take?
A run across thousands of entities can take several minutes. Poll Show a monitor every 2 to 5 seconds for the first 30 seconds, then every 15 to 30 seconds, until the process status is null, failed or paused.
What does it cost?
Each entity eligible for the operation is billed. Insufficient credit for the projected count returns 402 before anything is queued, with a billing object showing what would have been charged against what is available.
Why did we get a 409?
The monitor is not currently runnable. The most common cause is that it is already mid-run, with a process status of pending, processing or paused. It may also be paused, or the parent account inactive. The message states the reason.
What if the connection drops after we send the request?
Send an Idempotency-Key header, typically a fresh UUID per logical request. A retry with the same key and body returns the original response verbatim, marked with an Idempotent-Replay header, and the run is not queued a second time. Keep polling the original monitor. A successful response is remembered for 24 hours, and the same key with a different body is rejected with 422.
Getting started

The first step to access is a conversation

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

ISO 27001 certified
Handled under Australian privacy law
Every API call written to the audit log