Getting your client base into Detekta
Three files. This page defines every field, says plainly which ones we cannot work without, and explains what each one buys you in monitoring coverage.
If a field is not available in your systems, leave it blank. Do not guess — we would rather have an honest gap than invented data.
Which of these are you?
The answer changes how much of this you fill in, and nothing else.
Newly in scope, and you have never been required to collect dates of birth, residential addresses, ownership percentages or source-of-funds statements. You will not have most of this, and that is fine. Send the nine mandatory client columns — things any practice already holds — and we collect the rest from the people themselves during verification.
You already run AML and hold a customer file. Send everything you have. The additional columns exist for you: they carry your existing verification and risk work across so nobody is asked the same question twice, and they let us cross-check what people tell us against what you already knew.
Only 9 of the 33 client columns are mandatory either way. The rest exist so that where you do hold something, it does not go to waste.
The two halves are not symmetrical
If this is your first mandate: client data barely exists yet, and transaction data already exists in full.
9 and 4 mandatory columns. The nine are things a practice already holds: your reference, the entity type, the legal name, an email, the country, the ABN, the date they became a client, their status, and — for a trust — what kind of trust it is. You have never been required to collect dates of birth, residential addresses, ownership percentages or source-of-funds statements, so we assume you do not have those. We gather them during verification.
9 mandatory columns, all of which are already on your bank statement. Date, amount, direction, the narrative line and the other party are printed on every row of the export. Nothing here asks you to research anything.
This is why the monitoring can start before the verification finishes. Two clocks run in parallel: transaction rules run the day your file lands, because they need the transaction and the counterparty, not your client’s date of birth. Screening of your clients’ people starts when each person responds to their verification link.
What we determine, not you
We deliberately do not ask you to declare whether a client is politically exposed, foreign tax resident, or higher risk. Those are conclusions, and they are ours to reach — we screen every person against sanctions, PEP and adverse-media sources and we compute the risk from the entity, the structure and the actual transaction behaviour. A client-supplied declaration would only ever be something we then have to confirm or contradict, so asking for it is noise.
What we collect, so you do not have to
Give us an ABN and we pull the company’s officeholders, registration status and incorporation date from the registry ourselves — you do not need to type the directors. Give us a person’s name and email and the verification flow collects their date of birth, address and identity document from them directly, then screens them. Ownership percentages, PEP status and source of funds are gathered as part of that same conversation.
Where you already hold any of it, send it — it saves the client a question and it lets us cross-check what they tell us.
The three files
Load order matters: entities exist before the people attached to them, and both exist before transactions can be linked.
The entities you act for — companies, individuals, trusts, partnerships, SMSFs.
The humans behind each entity. This is the file that makes identity verification possible.
Money movement across your accounts, for monitoring.
Each template carries a few worked examples — including a family trust held through a corporate trustee, because that structure is the one most often filled in incorrectly. Replace them with your data, or leave them and we will strip anything beginning C-000 or P-000.
Priority levels
Every field below carries one of four levels. The gap between the second and the third is the one worth understanding.
The minimum needed to run the monitoring rules and keep the record under ongoing due diligence. A record missing any of these will load, and we will list exactly what is missing — but it cannot be monitored or reviewed until they arrive.
Monitoring runs without it, measurably worse. Where a specific pattern becomes undetectable, we name it.
Enrichment. Changes nothing structural.
Only what is genuinely needed to run the rules and maintain the record is marked mandatory. email is mandatory because verification and ongoing review both reach the person through it; phone is not, because nothing depends on it.
Alongside the level, each field carries an Applies when note. A dash means the field applies to every row; otherwise it is only expected under that condition — abn matters for an Australian business and not for a UK one, counterparty_iban matters for an international wire and not for a BPAY.
If a field is genuinely unavailable, send the file with the cell blank. Please do not use a placeholder. A fabricated date of birth is worse than a missing one — it produces a confident wrong verification result instead of an honest gap.
Three things that matter more than the rest
Ordered by how often each one breaks a migration.
client_ref is the spine
Your own client identifier, from whatever system you already use. It joins all three files together.
Two rules: unique per entity, and stable forever. If it changes between imports we create a duplicate client and the history splits in two.
Amounts are always positive — direction carries the sign
A refund is money_out with a positive amount, not a negative deposit. This is the single most common cause of broken monitoring in a migration, so it is worth a second look at your export before you send it.
If you hold client money, tag the underlying client
This applies to anyone operating a trust account, a controlled-money account or any client account — accountants, law firms, conveyancers, real estate agencies, brokers. If every transaction on that account is tagged to your firm, we monitor your firm and learn nothing about your clients.
Tagged to the underlying client, the same file lets us see that one client made two $9,850 cash deposits on consecutive days — which is exactly the pattern that matters. For movements that genuinely belong to the firm — your own fee transfers, bank charges — create a client_ref for the firm itself in 1a and use it rather than leaving it blank.
Format rules
All three files.
- Encoding
- UTF-8. Not CP1252 or Latin-1 — accented names break.
- Dates
YYYY-MM-DD- Timestamps
- ISO 8601 with timezone:
2026-06-02T09:14:00+10:00. A date alone is accepted; we treat it as 00:00 local. - Amounts
- Positive, decimal point, no thousands separator, no currency symbol:
48500.00 - Booleans
TRUE/FALSE- Blanks
- Leave the cell empty. Not
NULL,N/A,-orunknown. - Currency
- ISO 4217 —
AUD,USD,EUR - Country
- ISO 3166-1 alpha-2 —
AU,NZ,DE
1a · Clients
One row per entity you act for. 42 columns; most entities use a subset determined by entity_type.
Identity
| Field | Level | Applies when | Notes |
|---|---|---|---|
| client_ref | Mandatory | — | Your identifier. Unique, stable. |
| entity_type | Mandatory | — | Determines which other fields we require. See accepted values. |
| legal_name | Mandatory | — | Exactly as registered. For an individual, their full legal name. |
| country | Mandatory | — | Where the entity is established. |
| trading_name | Improves detection | If it trades under another name | Helps us match the name that appears in transaction narratives. |
| abn | Mandatory | Every entity that has one | AU business entities. Without it there is no registry lookup, so the entity stays unverified. |
| acn | Improves detection | AU companies | Companies. Lets us pull officeholders directly from the registry. |
| other_registration_number registration_country | Improves detection | Non-AU entities | Non-AU entities. Company number in the home registry. |
| date_of_birth | Improves detection | individual · sole_trader | individual and sole_trader only. Identity verification is impossible without it. |
| date_of_incorporation | Improves detection | All types except individual | Entity age is a genuine risk signal — newly formed entities score higher. |
Contact and address
| Field | Level | Applies when | Notes |
|---|---|---|---|
| registered_address_line1 …_suburb, _state, …_postcode, _country | Improves detection | — | Cross-checked against the registry and against proof of address. |
| Mandatory | — | Where the identity-verification link is sent. No email, no KYC. | |
| phone | Optional | — | Fallback delivery and a weak identity signal. |
| postal_address_same_as_registered | Optional | — | If FALSE, put the postal address in notes for now. |
Business profile
| Field | Level | Applies when | Notes |
|---|---|---|---|
| industry_description | Improves detection | All types except individual | Drives the risk model. “Consulting” and “money remittance” are not the same risk. |
| anzsic_code | Optional | If you already hold it | If you already hold it. |
| relationship_start_date | Mandatory | — | Distinguishes a new client from a ten-year one. |
| client_status | Mandatory | — | active · inactive · ceased · prospective |
| cash_intensive | Improves detection | — | TRUE if the client routinely deals in cash. Turns on cash-specific rules. |
| notes | Optional | — | Anything that does not fit a column. We read it. |
Trusts
If the trustee is a company, give that company its own row in 1a and point trustee_client_ref at it. That is how we unwrap the structure and show the people behind it. If the trustee is an individual, list them in 1b with role trustee and leave trustee_client_ref blank.
The template shows this worked end to end: client-0003 is the trust, client-0004 is its corporate trustee with its own row, and the trustee’s sole director appears in 1b.
Discretionary trusts have no ownership percentages. That is the nature of them — the trustee decides distributions. Leave ownership_percentage blank for a discretionary beneficiary and still set is_beneficial_owner = TRUE: they are a beneficial owner by benefit and control, not by a measurable share. Unit trusts and partnerships do have measurable interests, so send those.
| Field | Level | Applies when | Notes |
|---|---|---|---|
| trust_type | Mandatory | trust · smsf | discretionary · unit · testamentary · charitable · smsf |
| trustee_client_ref | Improves detection | trust · smsf with a corporate trustee | Points at the trustee’s own row in this file, when the trustee is a company. |
| settlor_name | Improves detection | trust | AUSTRAC names the settlor specifically for trusts. |
| trust_deed_date | Optional | trust · smsf | |
| partnership_type number_of_partners | Improves detection | partnership | Partnerships. We reconcile the count against 1b; a mismatch flags an incomplete structure. |
Expected activity
These are the baseline the monitoring compares against. Without them every rule falls back to a generic threshold, which produces both false positives and misses.
| Field | Level | Applies when | Notes |
|---|---|---|---|
| expected_annual_turnover | Improves detection | — | A $40,000 transaction is unremarkable for a $10m client and a red flag for a $200k one. Blank means we cannot tell the difference. |
| expected_transaction_count_monthly | Improves detection | — | Enables velocity rules. |
| expected_transaction_value_monthly | Improves detection | — | Enables value-deviation rules. |
| funds_source_description | Optional | — | Source of funds is a standing obligation, not an optional field. Free text is fine. |
| purpose_of_relationship | Optional | — | Why they engaged you. Free text. |
1b · People
One row per person behind each entity. Entities are verified against a registry; people are verified against documents, and that is impossible without these rows.
Yes — client_ref in this file is exactly the same value as the entity’s client_ref in 1a. That is the join. A person attached to Harbour Freight carries client-0001; the same human attached to the trust carries client-0003 on a second row.
There is no “date became client” on a person — that belongs to the entity, in 1a. What a person has is appointed_date: when they took the role. For company directors the registry gives us that from the ABN, so you do not need to type it.
What each role actually needs
Everyone goes in the same file. For the four roles we have to verify, all we need from you is a name and an email — the person supplies the rest to us. A settlor is a matter of record, so the name alone is enough. Directors we can usually pull from the registry with the ABN, so send them only if it is easy.
| Role | Name | Everything else | |
|---|---|---|---|
| ubo | You send | You send | We collect |
| trustee | You send | You send | We collect |
| partner | You send | You send | We collect |
| authorised_ | You send | You send | We collect |
| director | You send | If you have it | Registry, or not needed |
| settlor | You send | Not needed | Not needed |
A director who is also a beneficial owner follows the beneficial-owner row. Set role = director and is_beneficial_owner = TRUE and send the full set — that is the common case in a small company, and it is how the template’s client-0001 example is filled in.
Where a role appears twice for the same human under different entities — Margaret is a client in her own right, the settlor of the trust, and the director of the corporate trustee — send all three rows with the same person_ref. We verify her once and link the three.
All fields
| Field | Level | Applies when | Notes |
|---|---|---|---|
| client_ref | Mandatory | — | Which entity from 1a this person belongs to. |
| person_ref | Mandatory | — | Your identifier for the person. Reuse the same value when the same human appears under several clients — that is how we see one person controlling four entities, which is worth seeing. |
| role | Mandatory | — | A trust beneficiary goes in as ubo. See accepted values. |
| is_beneficial_owner | Improves detection | — | TRUE if they ultimately own or control the entity. role is the label; this is the substance the regulator cares about. |
| full_name | Mandatory | — | Full legal name, as it appears on their ID. |
| date_of_birth | Improves detection | See per-role table | The field most often missing in a migration, and it stops verification dead. |
| ownership_percentage | Improves detection | When the interest is measurable — see note | ubo and partner. We apply the 25% beneficial-ownership threshold to this; blank means we cannot compute who qualifies. |
| Mandatory | See per-role table | Where the verification link goes. Each person needs their own — one shared office address means only one person can be verified. | |
| residential_address_line1 …_suburb, _state, _postcode | Improves detection | See per-role table | Residential, not business. A registered office address fails an address check. |
| country_of_residence | Improves detection | — | Determines which verification method and which sanctions lists apply. |
| phone | Optional | — | |
| nationality | Optional | — | |
| is_pep pep_details | Optional | — | As declared to you. We screen independently. |
| appointed_date ceased_date | Optional | — | Leave ceased_date blank for current people. Historical people are still worth sending. |
| place_of_birth | Optional | — | Improves sanctions match accuracy on common names. |
| notes | Optional | — |
2 · Transactions
One row per money movement.
Core
| Field | Level | Applies when | Notes |
|---|---|---|---|
| client_ref | Mandatory | — | The underlying client the money belongs to — not your own firm, where you hold client money. See point 03 above. |
| transaction_ref | Mandatory | — | Unique and stable. This is how we avoid double-counting when next month’s file overlaps. The bank’s own reference is ideal. |
| occurred_at | Mandatory | — | When it happened, with timezone. |
| amount | Mandatory | — | Positive. Always. |
| currency | Mandatory | — | |
| direction | Mandatory | — | money_in or money_out, from the account’s point of view. |
| description | Mandatory | — | The bank’s narrative line, verbatim. Please do not clean it up. It is one of the richest signals available and it is already in your export. |
The accounts
| Field | Level | Applies when | Notes |
|---|---|---|---|
| account_bsb account_number | Improves detection | — | Which of your accounts the money moved through. |
| account_type | Improves detection | — | trust · operating · general. These behave completely differently; without it we apply one profile to both. |
| account_name | Mandatory | — |
The counterparty
| Field | Level | Applies when | Notes |
|---|---|---|---|
| counterparty_name | Mandatory | — | This is what gets screened against sanctions, PEP and adverse-media sources. Blank means no screening happened on that transaction. |
| counterparty_country | Improves detection | — | Drives the high-risk-jurisdiction rules. Blank and we cannot flag a payment into a FATF-listed country. |
| counterparty_iban counterparty_swift_bic | Improves detection | rail = international_wire | International transfers. |
| counterparty_type | Improves detection | — | individual · business |
| counterparty_bsb counterparty_account_number | Improves detection | rail = npp · becs | Domestic. Lets us recognise the same counterparty across transactions. |
Classification and context
You are the most reliable source for the classification fields. When you declare them we take them as fact; when they are blank we infer, and inference is sometimes wrong.
| Field | Level | Applies when | Notes |
|---|---|---|---|
| rail | Improves detection | — | Each rail carries a different risk profile. See accepted values. |
| balance_after | Improves detection | — | Sounds trivial. It is how we detect funds passing straight through — in and out, balance returning to near zero. A core layering pattern that is invisible without it. |
| lifecycle_event | Improves detection | If not an original payment | Defaults to original_payment. |
| purpose | Improves detection | — | Why the money moved. Free text. |
| related_transaction_ref | Improves detection | Refunds, reversals and disbursements | Links a refund to its original, or a disbursement to the receipt that funded it. |
| channel | Optional | — | online · branch · atm · api · phone |
| source_statement_ref notes | Optional | — | Helps us reconcile against your statements. |
How much history? Twelve months if you have it. Six is workable. Under three months the behavioural baselines have little to learn from, so early monitoring will be noisier while it calibrates.
Accepted values
Anything outside these lists is rejected at import rather than silently mapped to something else.
- entity_type
individual·sole_trader·company·trust·partnership·smsf·association·government- role
ubo·trustee·partner·director·settlor·authorised_representative- trust_type
discretionary·unit·testamentary·charitable·smsf- partnership_type
general·limited·incorporated_limited- client_status
active·inactive·ceased·prospective- direction
money_in·money_out- account_type
trust·operating·general- rail
npp·becs·bpay·cash·cheque·card·international_wire·internal_transfer- lifecycle_event
original_payment·refund·reversal·fee·interest- counterparty_type
individual·business- channel
online·branch·atm·api·phone
Who to list in 1b
Send everyone who fits. An entity with no rows in 1b cannot be verified — it will import and sit as incomplete.
| Entity type | Who to list |
|---|---|
| individual · sole_trader | The person, role = ubo, 100% |
| company | Every director, plus anyone holding 25% or more |
| trust | The trustee (or point to the corporate trustee’s own row in 1a), the settlor, and every named beneficiary |
| partnership | Every partner |
| smsf | Every member and every trustee |
| any of the above | Anyone with authority to operate the account, as authorised_representative |
What happens once you send these
- We load the clients and run registry lookups on the entities.
- Each person in
1breceives an identity-verification link by email, and is screened against sanctions, PEP and adverse-media sources. - Transactions load and the rules run across the full history — so alerts appear for past patterns immediately, not only from today forward.
- We walk you through what fired and why, and tune the thresholds to your book before anything becomes an obligation.
Questions, or a field your system cannot produce? Tell us which ones and we will tell you exactly what it costs you in coverage, and whether there is a workaround. Nothing here is worth guessing at.