What does AUSTRAC require for AML customer onboarding of a company?

Under Part B of an AML/CTF program, reporting entities must collect and verify the company's full legal name, ACN, whether it is registered as a public or proprietary company, its registered office address, its main place of business address, and the identity of beneficial owners holding 25% or more of the entity. Verification must be against a reliable, independent source such as ASIC registers.

What is the beneficial owner threshold under AUSTRAC rules?

AUSTRAC defines a beneficial owner as an individual who ultimately owns (directly or indirectly) 25% or more of the entity, or controls (directly or indirectly) the entity. Where no single individual meets the 25% threshold, reporting entities must take reasonable steps to identify an alternative individual, such as someone who controls 25% or more of the entity's voting rights.

Which sanctions lists does Australia require screening against?

Two Australian legal frameworks are relevant. The Charter of the United Nations Act 1945 (Cth) gives effect to UN Security Council sanctions. The Autonomous Sanctions Act 2011 (Cth) covers Australia's autonomous sanctions administered by DFAT, covering country-specific programs for Russia, Iran, Myanmar, Syria, Zimbabwe, North Korea, and specified regions of Ukraine. Organisations with USD exposure or US counterparties are also subject to OFAC screening requirements as a matter of US law.

Can an API automate AML beneficial owner checks in Australia?

Not fully. The ABR and ASIC registers do not publish beneficial ownership data via structured API. Entity verification (confirming the company exists and is currently registered) can be automated via the ABR and ASIC register APIs. But the beneficial owner chain, following ownership through corporate shareholders to identify the natural person, typically requires ASIC document review alongside the API lookup.

AML Customer Onboarding in Australia: What AUSTRAC Requires

Q: What is the difference between Part A and Part B of an AML/CTF program?

Part A covers broader risk governance: policies, controls, employee due diligence, transaction monitoring, and ongoing customer due diligence. Part B is the customer-facing component: it documents the procedures for identifying and verifying each customer before commencing a designated service.

← All posts

AML KYC AUSTRAC Sanctions Screening Entity Verification Australia

AML customer onboarding is the set of checks a reporting entity must complete before commencing a designated service for a new customer. For most regulated businesses in Australia, this happens at account opening. Get it wrong, and the consequences include civil penalties, AUSTRAC enforcement action, and reputational exposure. Get it right, and you have a documented, auditable record of exactly what was verified and when.

The checks involved come from different sources, run against different datasets, and need to produce a combined audit trail. Most teams solve this manually, or with a patchwork of tools that do not talk to each other. Neither holds up when AUSTRAC comes asking.

What the AML/CTF rules require at onboarding

Australia's Anti-Money Laundering and Counter-Terrorism Financing Act 2006 (Cth) requires reporting entities to have a written AML/CTF program. The program has two parts.

Part A covers your broader risk governance: policies, controls, employee due diligence, transaction monitoring, and ongoing customer due diligence. Part B is the customer-facing component. It documents the procedures you must follow to identify and verify each customer before commencing a designated service.

For a company customer, Part B requires you to collect and verify:

The company's full legal name
Its Australian Company Number (ACN), the primary verification identifier for companies
Whether it is registered with ASIC as a public or proprietary company
Its registered office address
Its main place of business address (if different from the registered office)
The identity of beneficial owners holding 25% or more of the entity

Verification means confirming this information against a reliable, independent source. A customer declaring their ACN is not verification. Checking it against ASIC registers and confirming the name, status, and type match is.

Step 1: entity verification

The first question in any AML onboarding workflow is whether the entity is real and currently registered. In Australia this means cross-referencing two sources: the Australian Business Register (ABR) for ABN status, entity type, and trading names; and the ASIC Company Register for registration status and company type.

These registers cover different things. The ABR holds the tax registration. ASIC holds the legal corporate registration. A company can have an active ABN but be deregistered as a company. Treating either register as a complete picture on its own produces gaps.

The Tech Compass AU Entity Intelligence API queries both in a single call. The response covers ABN status and effective date, entity type, registered business names, the paired ASIC status code (active, deregistered, externally administered, struck off, or not registered), and company type. It also includes a cross-register KYC signal that flags when ABR and ASIC statuses are inconsistent. For example, an ABN showing as Active while the ASIC record shows the company is deregistered. The data lineage block identifies the ABR and ASIC sources and the record timestamps.

Bash

curl "https://api.techcompass.com.au/v1/au/abr/31632578342" \
  -H "Authorization: ApiKey tc_live_YOUR_KEY"

Response (abbreviated)

{
  "data": {
    "abn": "31632578342",
    "abn_status": "Active",
    "abn_status_effective_from": "2019-03-28",
    "registered_name": "TECH COMPASS PTY LTD",
    "entity_type_code": "PRV",
    "entity_type_description": "Australian Private Company",
    "business_names": [],
    "gst_registered": true,
    "state": "VIC",
    "postcode": "3032",
    "acn": "632578342"
  },
  "kyc": {
    "overall_risk": "LOW",
    "is_active_legal_entity": true,
    "in_external_administration": false,
    "strike_off_pending": false,
    "is_gst_registered": true,
    "abn_asic_mismatch": false,
    "flags": null
  },
  "meta": { "request_id": "req_01J4...", "timestamp": "2026-08-05T02:10:00Z" },
  "data_lineage": {
    "source": "ABR Lookup Web Services",
    "source_url": "https://abr.business.gov.au/json/AbnDetails.aspx",
    "retrieved_at": "2026-08-05T02:10:00Z",
    "license": "ABR Web Services Agreement — ref ABNL27735.",
    "source_asic_snapshot_date": "2026-08-04"
  }
}

Address verification gap: the API returns state and postcode from ABR, and ASIC status fields. It does not return a full registered office address or main place of business address. If your Part B procedures require verifying a company's registered address against an independent source, supplement with a direct ASIC company search for that field.

Step 2: beneficial owner identification

Once you have confirmed the entity exists, the next requirement is identifying beneficial owners. AUSTRAC requires reporting entities to identify any individual who ultimately owns or controls 25% or more of the customer entity. Where no single individual meets that threshold, you must take reasonable steps to identify and verify an alternative individual, typically someone who controls 25% or more of the entity's voting rights.

This step cannot be fully automated via register-based APIs in Australia, and it is worth being direct about why.

The ABR and ASIC registers do not publish beneficial ownership, director, officer, or shareholder data via structured API. The Tech Compass API returns no director, officer, shareholder, or ownership chain data. For a simple proprietary company with two directors and two individual shareholders, beneficial owner identification may be achievable through customer self-declaration plus ASIC company document review. For a company with a corporate shareholder, or a trust with a corporate trustee, following the chain to the natural person beneficial owner requires document review at each layer, not an API call.

In practice, the entity verification call handles the first layer: confirming the top-level entity is real and currently registered. Beneficial owner identification sits on top of that, and currently requires a combination of customer self-declaration and ASIC document review for anything beyond a flat ownership structure.

Step 3: sanctions screening

With the entity verified, the third onboarding check is sanctions screening. Two separate Australian legal frameworks are relevant.

The Charter of the United Nations Act 1945 (Cth) gives domestic legal effect to UN Security Council sanctions. All Australian persons and entities are prohibited from dealing with UN-designated parties.

The Autonomous Sanctions Act 2011 (Cth) covers Australia's autonomous sanctions administered by DFAT. These cover additional designations beyond the UN list, including country-specific programs for Russia, Iran, Myanmar, Syria, Zimbabwe, and North Korea, as well as specified regions of Ukraine.

For organisations with USD exposure or US counterparties, OFAC screening is also required as a matter of US law, regardless of where the transaction originates.

Screening against a single list is not sufficient. A party may be on the DFAT list but not OFAC. A party may be on the UN list but not yet actioned onto the DFAT list. A party may appear on the EU Financial Sanctions Files under a different alias than the one used for their UN designation.

The Tech Compass Multi-Jurisdiction Sanctions API screens a name simultaneously against five lists in a single call: OFAC, UN, EU, UK FCDO (OFSI), and DFAT. The response includes a result per jurisdiction, with the specific matched entry detail and the list version used for each. If a name matches on DFAT but not OFAC, both results are clearly attributed. A single audit log entry covers all five lists.

Bash

curl "https://api.techcompass.com.au/v1/global/sanctions/screen?name=Acme+Holdings+Pty+Ltd&entity_type=entity" \
  -H "Authorization: ApiKey tc_live_YOUR_KEY"

Response (abbreviated, clear result)

{
  "data": {
    "query_name": "Acme Holdings Pty Ltd",
    "screened_at": "2026-08-05T02:14:33Z",
    "entity_type_filter": "entity",
    "jurisdictions_screened": ["UN", "EU", "DFAT", "FCDO", "OFAC"],
    "total_matches": 0,
    "results": {
      "UN":   { "match_count": 0, "list_date": "2026-08-04", "matches": [] },
      "EU":   { "match_count": 0, "list_date": "2026-08-04", "matches": [] },
      "DFAT": { "match_count": 0, "list_date": "2026-08-04", "matches": [] },
      "FCDO": { "match_count": 0, "list_date": "2026-08-04", "matches": [] },
      "OFAC": { "match_count": 0, "list_date": "2026-08-04", "matches": [] }
    }
  },
  "meta": { "request_id": "req_01J5..." },
  "data_lineage": {
    "list_dates": {
      "UN": "2026-08-04", "EU": "2026-08-04",
      "DFAT": "2026-08-04", "FCDO": "2026-08-04", "OFAC": "2026-08-04"
    }
  }
}

The audit trail

AML/CTF compliance is a documented process, not just a technical one. AUSTRAC expects reporting entities to be able to demonstrate what checks were performed, when, what result was returned, and what decision followed.

Each API call returns a meta.request_id. Store this alongside the customer record in your system. When AUSTRAC or your internal audit team asks for evidence of onboarding checks, you retrieve those IDs and the corresponding records: the name checked, the list versions used, the result per jurisdiction, and the timestamp, all stored server-side and immutable after the fact.

One important distinction: the audit trail records what the data showed. The compliance decision is yours. A clear sanctions result does not mean you must onboard a customer. A matched result does not automatically mean you cannot. The records support the decision — they do not make it.

What an automated onboarding sequence looks like

Putting it together, a workflow using the Tech Compass API covers the entity verification and sanctions screening steps:

Bash: Step 1, entity verification

curl "https://api.techcompass.com.au/v1/au/abr/{abn}" \
  -H "Authorization: ApiKey tc_live_YOUR_KEY"

# Store: data.abn_status, kyc.overall_risk, kyc.abn_asic_mismatch
# Store: meta.request_id alongside customer record

Bash: Step 2, sanctions screening

curl "https://api.techcompass.com.au/v1/global/sanctions/screen?name={entity_name}&entity_type=entity" \
  -H "Authorization: ApiKey tc_live_YOUR_KEY"

# Store: data.total_matches, data.results per jurisdiction
# Store: meta.request_id alongside customer record

Two calls. Two request_id values stored in your customer record. Together they document that entity verification and multi-jurisdiction sanctions screening were completed, when they were completed, and what each returned.

The beneficial owner identification step sits outside what register-based APIs can currently fully automate in Australia.

Ongoing monitoring after onboarding

Initial onboarding checks are a point-in-time snapshot. Part A of your AML/CTF program requires ongoing customer due diligence; your program needs controls to detect when a previously verified customer's risk profile changes.

The Tech Compass CMaaS (Compliance Monitoring as a Service) product monitors a registered customer roster against the OFAC SDN list daily and sends an alert when a match is detected. Ongoing monitoring across the full set of sanctions lists used at onboarding (UN, EU, DFAT, FCDO, and OFAC) is on the roadmap. For now, if your ongoing monitoring requirement extends beyond OFAC, the current approach is scheduling periodic rescreening calls via the Multi-Jurisdiction Sanctions API.

Common shortcuts that don't hold up

Checking ABN Lookup manually. The public ABN Lookup interface is designed for humans. It does not produce a machine-readable record that an entity was verified at a specific point in time against a specific register state.

Screening against OFAC only. Required for US-exposure situations, but leaves UN, EU, UK, and DFAT designations unchecked. For Australian entities with cross-border exposure, this is a gap.

Running checks at onboarding and not again. Part A requires ongoing customer due diligence. A counterparty clean at onboarding can be designated months later.

Storing screenshots or PDFs of search results. These are not structured records. They cannot be searched, aggregated, or reliably retrieved for regulatory examination.