Organisation AUSTRAC screen

The AUSTRAC screen of an organisation answers the questions AUSTRAC's initial customer due-diligence form for a body corporate asks: what sets this customer's risk rating (A1), which ownership exemptions apply and where the trace of the structure ends (C1), who the beneficial owners are and how they exercise control (C2), and whether each representative and each beneficial owner is listed or a politically exposed person (E1.1, E1.2, E2.1, E2.2). It is sold mainly to integrators, as the AUSTRAC part of their own onboarding or remittance platform; VerityRadar supplies the screening and the register reading, and this page documents exactly what that part returns and what it still leaves to you.

The screen is deterministic. It reads the customer's own list determination from the structured screening hits, reads the register facts the pipeline holds, applies the ownership and control tests to the structure you declare, and writes one austrac_compliance module into the investigation response. No model authors any field under it, and it never decides for you whether a customer falls within an exemption or provides a designated service: it puts the facts and the citations in front of the reporting entity.

1. The request

POST /api/ai-investigate (bearer JWT or long-lived API key; rate-limited under ai-investigations-per-ip).

A complete organisation AUSTRAC request:

{
  "subjectType": "organization",
  "organizationName": "Apex Capital Holdings Pty Ltd",
  "country": "AU",
  "austracScreen": true,
  "additionalIdentifiers": [ { "type": "acn", "value": "004085616" } ],
  "privacyNoticeAcknowledged": true,
  "ownershipStructure": {
    "parties": [
      { "id": "p1", "kind": "company", "name": "Apex Group Holdings Ltd", "country": "AU" },
      { "id": "p2", "kind": "individual", "name": "Alex Tan", "country": "AU", "dateOfBirth": "1981-06-14" }
    ],
    "links": [
      { "holderId": "p1", "heldId": "customer", "ownershipPct": 100 },
      { "holderId": "p2", "heldId": "p1", "ownershipPct": 60, "roles": ["director", "shareholder"] }
    ],
    "documents": [
      { "type": "ASIC company extract", "issuer": "ASIC", "date": "2026-10-01" }
    ]
  },
  "customerProfile": {
    "sector": "real_estate",
    "purpose": "buy_commercial_property",
    "funding": "mortgage",
    "valueBand": "5m_and_over",
    "charityOrNpo": "no"
  }
}

A screen costs 1 credit (Basic), 2 (Advanced) or 3 (AUSTRAC). AUSTRAC includes the Advanced research, so advancedSearch adds nothing to an AUSTRAC screen. A declared structure that names more than ten parties adds one credit for each further ten parties; the organisation being screened is not a party, so it is never counted.

400 rules

Every guard below runs ahead of the billing path, so a refused request costs nothing. organizationName is required and the declared-structure privacy_notice_required are returned without creditsCharged; every other refusal carries creditsCharged: 0.

A 402 (insufficient credits or an exhausted per-key budget) is a billing failure, not a refusal: the request was valid but could not be paid for.

2. The declared ownership structure

A public register does not publish every beneficial owner, and a private company's members are not public at all. The structure you declare is how the screen learns who holds the customer and how. The pipeline applies the AUSTRAC ownership and control tests to it and records, for every fact, whether it came from your declaration, a public register, or public sources researched for the screening.

Party kinds

individual, company, trust, partnership, government_body and listed_company. Only an individual can be a beneficial owner; every other kind is a layer the trace passes through. A listed_company or a government_body can end the trace under the Rules 6-7 deeming, which is what the C1 exemptions report.

Links and roles

A link is directed: holderId holds an interest in heldId. The reserved id "customer" is the organisation being screened and is never a party. A party is the customer's holder when a link runs from it to "customer". The roles are shareholder, director, ceo, trustee, appointor, protector, settlor, general_partner and nominee_for.

A role belongs to the link's holder. That direction decides a nominee: a nominee_for link names the nominee as the holder and the party it holds for as the held party. The nominee's holdings move onto that principal, and the moved link records the nominee by name — "who is behind this holding" is the question a nominee exists to obscure. The nominee_for link itself is not a stake.

A holder with no percentage — a director or a CEO — is declared through roles with no ownershipPct, because for many structures the office is the only evidence of control. A band (ownershipPctMin and ownershipPctMax) is recorded as a floor and a ceiling, never as a point percentage the source did not state.

3. The declared customer profile

The AUSTRAC form's A1 risk factors are questions about the customer's own circumstances, which a public screen cannot observe. customerProfile lets the reporting entity pass on what the customer declared so the screen can apply the rules, cite them, and show the reader which inputs were never answered. It is optional, and it is never a clearance: every raised factor names the starter-kit rule it rests on, and an input that was not given is listed under notAssessed rather than left silent.

The lists are versioned (2026-10) and served by GET /api/austrac/customer-profile/options (bearer JWT), which returns each entry's code, label and appliesTo — the same spelling as subjectType, so a client can match the two. A value band's minAud is exclusive and its maxAud inclusive, so a value on a boundary sits in the band below it; the labels say so ("Over $1 million to $1.5 million", "Up to $10,000", and "Over $5 million" for the open-ended top band).

Each factor the declaration raises appears in riskFactors and in customerProfile.raisedFactors with its starter-kit citation, and counts toward indicativeRating exactly as an evidence-raised factor does. The citations name the source page: AUSTRAC's real estate program starter kit, step 2, A1 risk factors. The report prints the declaration as declared, the raised factors with their citations, and the not-assessed lines, so nothing the customer left blank reads as clear.

4. The response

The response is the v2 investigation envelope. The screen is the austrac_compliance module in modules[] (moduleId: "austrac_compliance", category: "compliance", displayOrder: 190, tier: "free"). Its status is one of listed, possible_match, found, not_found or inconclusive; its severity is derived by the same rules as every other module. A body-corporate screen is marked by data.reportForm: "body_corporate", which is what the report renderers read to print the form's sections rather than the person layout.

The module's data object:

5. Mapping to AUSTRAC's Initial CDD form for a body corporate

The screen is organised in the order AUSTRAC's initial-CDD form for a body corporate asks its questions.

Two readings are deliberate. The customer's own PEP question is not_applicable, never none: a body corporate holds no office, and "none" would read as a clearance nobody made. And a person's PEP question is inconclusive with pepNotDetermined when no source that tags PEPs answered for them — an unanswered check is never presented as a clearance.

The C1 candidates are listed_with_disclosure (a listed company that discloses its beneficial owners, r 6-7(1)(a)), government_body (r 6-7(1)(b)), regulated_and_low_risk (an APRA-regulated body or an ASIC AFS or credit licensee) and strata. Each either applies and names the party, or the customer itself, that the exemption attaches to, or is reported not applied with its reason. strata is always reported not applied, because no public register decides it. A register that could not be read and a register that answered "no row" are different renderings, and neither is reported as "the entity does not exist".

What the screen does not cover

cddRecord.notCovered names what remains the reporting entity's responsibility and is not part of this screen:

• Identity verification of the customer, each beneficial owner and each representative — that each is who they claim to be.
• A representative's authority to act for the customer.
• Each beneficial owner's basis of ownership or control as evidenced by the customer's own documents.
• The nature and purpose of the business relationship. When the customer declares a purpose in customerProfile, this line narrows in cddRecord.notCovered to "the nature and purpose of the business relationship beyond the purpose the customer declared" rather than disappearing: what the customer said is recorded, it is not verified evidence, and the rest of the list stays.
• The customer's governing documents — constitution, company extract and register of members.
• Source-of-funds and source-of-wealth evidence — the screen can trigger the obligation, but it does not collect the evidence.

6. Sample response and sample report

A fictional sample is published alongside this guide and kept in sync with the live schema by the report-sample tests.

• Sample response — verityradar-sample-organisation-austrac.json, a fictional remittance provider whose austrac_compliance module carries every field in the table above; an array is empty where the fictional subject produced no evidence.
• Sample report — Organisation, AUSTRAC, the same subject rendered through the product's own PDF renderer.

7. Data coverage

What this screen can find is bounded by the data the crawler ingests. The Screening Data Coverage Statement is the authoritative record of that; it is available on request from VerityRadar while its public host is prepared. The screen itself draws on three dated lists, recorded in cddRecord.lists:

• the DFAT Consolidated List (dated in dfatListUpdated, or not recorded when no DFAT row was read),
• the FATF high-risk and other monitored jurisdictions (the countryRisk band source),
• the DFAT sanctioned countries (the country-specific regimes Australia implements).

Register facts come from the public registers cddRecord.registerFacts names, each with its own as-at date. The AUSTRAC registers of remitters and of virtual asset service providers are not among them: AUSTRAC publishes those only through a CAPTCHA-gated interactive search, so the screen reports them under exemptions.undeterminedRegisters, and where no other source answers, it leaves the s 6 answer not_determined rather than guessing.