AML Client Onboarding

The problem with manual onboarding

Onboarding a new customer means answering two separate questions, not one. Is this a real, currently registered entity. And is this entity, or anyone connected to it, sanctioned. Most teams solve the first with a manual register check and the second with a single sanctions list, usually OFAC, and stop there. Neither shortcut holds up under real scrutiny.

A counterparty can be a legitimate, active entity and still appear on the DFAT Consolidated Sanctions List, the UN Security Council list, or EU financial sanctions — designations that a US-only OFAC screen misses entirely. And an ASIC company status check that returns "registered" tells you nothing about whether the entity is in external administration or has been struck off since the last manual pull.

For AUSTRAC-regulated businesses, the risk is not just operational. The AML/CTF Act requires documented evidence that checks were conducted, against specific sources, at a specific point in time. A screenshot of a register search does not satisfy that requirement in an audit. A logged API call with source lineage and timestamp does.

What AUSTRAC requires for customer onboarding

Under the Anti-Money Laundering and Counter-Terrorism Financing Act 2006 (AML/CTF Act), Australian reporting entities must satisfy three obligations before providing designated financial services to a new customer:

• Identity verification: Confirm the customer is who or what they claim to be. For a business, this means confirming the entity is real, currently registered, and in good standing.
• Sanctions screening: Check the customer against the DFAT Consolidated Sanctions List. The DFAT list is the minimum legal obligation for AU businesses. Correspondent banking relationships and cross-border workflows typically impose additional requirements covering OFAC, UN, and EU lists.
• Record keeping: Maintain evidence of what was checked, when, and against which source, for 7 years. AUSTRAC expects records that can be produced to auditors on request.

The same obligations apply to enhanced due diligence (EDD) for higher-risk customers, where the depth of verification increases but the underlying workflow is the same: confirm the entity, screen for sanctions, log the result.

The AML onboarding process: three steps

The Tech Compass AML client onboarding workflow runs three checks in sequence. Each runs as a separate API call, returns its own result, and carries its own audit trail.

Step 1: Entity verification

A single call cross-references the Australian Business Register (ABR) and the ASIC company register. The response confirms: registered entity name, ABN and ACN, current ABR status (active or cancelled), ASIC company status, GST registration, and entity type. The ASIC status field is the critical signal for onboarding decisions.

High-risk ASIC statuses that typically trigger a review or block:

• EXAD — External administration (includes liquidation, voluntary administration, receivership)
• DRGD — Deregistered
• SOFF — Struck off
• NOAC — Not active, when combined with an active ABR status, signals a likely mismatch worth investigating

Step 2: Multi-jurisdiction sanctions screening

A single call screens the entity name across all five major lists simultaneously: OFAC SDN, UN Security Council Consolidated List, EU Financial Sanctions, UK FCDO Consolidated List, and DFAT Consolidated Sanctions List. This satisfies AUSTRAC's DFAT obligation and covers international exposure in one call, with one logged result.

The response includes match status, matched entity details if a hit is found, the list name and version date for each list screened, and a timestamp. A no-match result is as important to log as a match — it is the evidence the check was conducted.

Step 3: Standalone OFAC screening (optional)

For teams that need granular per-screen billing for OFAC specifically — common in correspondent banking workflows — the OFAC Sanctions Screening product runs a dedicated SDN check with per-screen cost tracking. If you are already running multi-jurisdiction screening, OFAC is covered. The standalone product exists for different billing requirements, not a different coverage gap.

Implementation example

The following Python example shows the onboarding workflow in sequence: entity verification, a status check against high-risk ASIC codes, then multi-jurisdiction sanctions screening. Each response includes a data_lineage object that forms the audit record.

import httpx

API_KEY = "your_api_key"
BASE_URL = "https://api.techcompass.com.au/v1"
HEADERS = {"Authorization": f"Bearer {API_KEY}"}

HIGH_RISK_STATUSES = {"EXAD", "DRGD", "SOFF"}

def onboard_customer(abn: str, entity_name: str) -> dict:
    # Step 1: Entity verification (ABR + ASIC)
    entity_resp = httpx.get(
        f"{BASE_URL}/au/entity/abn/{abn}",
        headers=HEADERS,
        timeout=10.0
    )
    entity_resp.raise_for_status()
    entity = entity_resp.json()

    asic_status = entity["data"].get("asic_status")
    if asic_status in HIGH_RISK_STATUSES:
        return {
            "result": "REVIEW",
            "reason": f"asic_status_{asic_status.lower()}",
            "entity_lineage": entity["data_lineage"]
        }

    # Step 2: Multi-jurisdiction sanctions screening
    sanctions_resp = httpx.post(
        f"{BASE_URL}/global/sanctions/screen",
        headers=HEADERS,
        json={"name": entity_name, "entity_type": "entity"},
        timeout=10.0
    )
    sanctions_resp.raise_for_status()
    sanctions = sanctions_resp.json()

    if sanctions["data"]["match_status"] == "MATCH":
        return {
            "result": "REJECT",
            "reason": "sanctions_match",
            "matched_lists": sanctions["data"].get("matched_lists", []),
            "entity_lineage": entity["data_lineage"],
            "sanctions_lineage": sanctions["data_lineage"]
        }

    return {
        "result": "PASS",
        "entity_verified": True,
        "sanctions_clear": True,
        "audit": {
            "entity_lineage": entity["data_lineage"],
            "sanctions_lineage": sanctions["data_lineage"]
        }
    }

Full endpoint reference: AU Entity Intelligence API docs and Multi-Jurisdiction Sanctions API docs.

What the audit trail contains

Every API call returns a data_lineage object as part of the standard response envelope. For an AML onboarding workflow, the combined audit trail covers:

• Entity verification: ABR source name, ABR data timestamp, ASIC source name, ASIC data timestamp
• Sanctions screening: For each list — list name, list version date, screening timestamp, match status

This gives auditors a complete chain of custody: what was checked, when the check ran, and which version of each source was current at the time of the check. The list version date matters because sanctions lists change daily — a check against an outdated list version is not a valid check.

Storing the data_lineage objects alongside your customer record satisfies AUSTRAC's record-keeping requirement without any additional logging infrastructure on your side.

When to re-screen

AUSTRAC expects ongoing monitoring, not a one-off check at onboarding. Triggers that typically require a re-screen:

• A change in the customer's beneficial ownership structure
• A transaction that falls outside the customer's established pattern
• A change in the customer's ASIC or ABR status
• A scheduled periodic review — most programs set this at 6 or 12 months depending on risk tier
• A new sanctions designation published by DFAT, OFAC, the UN, EU, or FCDO that matches a name in your customer base

Running the onboarding workflow manually on a schedule is one approach. The Compliance Monitoring product (CMaaS) handles ongoing re-screening automatically, monitoring your customer entities against all relevant lists and alerting you when a status changes — without requiring you to re-trigger the workflow per customer.

Which plan you need

Further reading

• AML customer onboarding under AUSTRAC: what the process actually requires
• Five sanctions lists. One screen call. Why multi-jurisdiction screening matters.
• OFAC screening: what it covers, what it misses, and why it needs an audit trail
• ABN versus ACN: what Australian entity verification actually requires

Frequently asked questions