AML compliance automation before July 2026: what we are building for an Australian accounting practice

On 2026-07-01, every registered tax agent in Australia has to have a working AML and identity verification process for new clients. The Tax Practitioners Board is the regulator. The practice note that defines "verification" is TPN 5/2022. From that date an audit request can land in an accountant's inbox asking for proof that each new client's identity was verified, timestamped, retained. If the proof is missing, the penalty sits with the practice.

Ten weeks away as I write this. Most practices I have spoken to in Perth are aware of the deadline and unsure what the operational answer looks like. The regulatory text says "sight the document, verify the client, record it." It does not say how a three-person or seven-person practice already running at capacity does that for every new client without breaking.

Short version. Two serious answers. Hire another person to carry the compliance load. Or build a system that carries it. One costs sixty to eighty thousand a year forever. The other costs once.

What the TPB is actually asking for

Strip the regulatory prose back. The tax practitioners board anti-money laundering requirements, as they bite on 2026-07-01, come down to four things a practice has to demonstrate under audit.

Identity verification of every new client. Under TPN 5/2022, document sighting is sufficient (driver licence, passport, Medicare, or equivalent). It has to be the real document, and the sighting has to be recorded. A firm that is already a registered Digital Service Provider can upgrade later to DVS-based government database verification, but for the July 2026 deadline, document sighting passes.

A timestamped audit trail. When was the identity sighted. Who sighted it. What the verdict was. If a client was flagged and reviewed, who the reviewer was and when. Seven years of retention, per standard Australian business-record rules.

Ongoing monitoring. The AML/CTF obligation is not a one-shot check at onboarding. The July mandate lands the identity-verification piece first; the broader monitoring obligation is the next layer.

APP (Australian Privacy Principles) compliance on every piece of identity data that touches the practice. If a driver licence image is emailed around in a thread, the practice has an APP problem before it has a TPB problem.

Four things, named explicitly, each of which has to be demonstrable under audit.

The math a practice is looking at

A new paraplanner or junior accountant in Perth runs $60,000 to $80,000 a year fully loaded, and that is someone without the seniority to own compliance end to end. Add on-costs and the real figure is closer to $95,000. That person spends thirty to forty percent of their week on onboarding admin: forwarding forms, re-typing data into Karbon, chasing clients for the driver licence photo, nudging them to finish the Cognito form. A second hire to absorb the AML load is another sixty, every year.

A code-driven system that does the same admin costs a different shape of money. One build fee up front. A managed retainer, sub-$200 a month. A VPS at roughly $24 a month billed directly to the practice. Annualised: one $95,000 salary, or one build under $25,000 and about $2,000 a year to keep running. Same job, a fraction of the bill, and the team does not get bigger.

Onboarding is the most repeatable workflow inside an accounting practice. Every new client goes through the same flow. Every flow hits the same compliance checkpoints. A workflow that repeats runs cleaner as code than as human memory.

How we are building one of these

The system we are in-flight on is being built for an Australian accounting practice. The engagement is real. Phase 1 ships 2026-06-15, with a two-week buffer before the July 1 deadline. Nothing below has measured production outcomes yet. The targets in the "what we expect to measure" section are targets. When the first cohort of real clients runs through, we will publish the actual numbers.

The system is called ZeroTouch. The principal documented an eleven-step onboarding flow verbatim when we scoped it. We rebuilt that flow as a state machine and wired each transition to the right vendor API.

The stack. Python and FastAPI for the service layer. Postgres for state and audit. APScheduler for scheduled reconciliation. SQLAlchemy and Alembic for the data model and migrations. Loguru for structured JSON logs. The whole thing runs on a managed VPS in Australia (Hostinger KVM2, 2 vCPU, 8 GB RAM, 100 GB NVMe) so all client data stays onshore. No Supabase. No frontend portal.

The vendor surfaces: Calendly for booking, Cognito Forms for pre-meeting and onboarding collection, Karbon for contacts (the practice's CRM and workflow tool), Xero Practice Manager for the accounting client record, VXT via Karbon's native sync, Mailchimp via the existing Karbon-to-Mailchimp sync, Stripe Identity for document-sighting verification, and the ATO Tax Agents Portal at the end as a manual operator checkpoint. The portal has no API; myID plus RAM authentication is browser-bound.

Step by step, here is what happens.

A prospect books on Calendly. The invitee.created webhook fires into FastAPI. A prospects row is written. State moves to BOOKED. Daily polling catches any missed webhooks, because Calendly does not retry.

The service sends the prospect a Cognito pre-meeting form link. On submission the webhook lands, and the service creates the prospect in Karbon via POST /v3/Contacts, deduplicating against existing contacts by email.

The meeting happens. Staff notes go into Karbon manually. This step does not automate; there is no point forcing a human conversation into a state machine.

Staff creates the engagement in the Karbon UI and sends the proposal. Karbon has no Engagements API (confirmed with Karbon support on 2026-04-16; no endpoint exists, none is coming). The architecture works around it. The service subscribes to Karbon's Contact Updated webhook, fetches Accounting Details on every fire, and diffs the DateSignedEngagement field against the prior snapshot. When the field transitions from null to a populated date, the engagement is signed. State moves to PROPOSAL_SIGNED.

The service sends the welcome email and the onboarding Cognito form. Identity documents, banking details, KYC fields, agreements.

Identity verification. Stripe Identity creates a verification session; the URL goes to the prospect. They upload document and selfie. The identity.verification_session.verified webhook comes back on pass. The identity.verification_session.requires_input webhook comes back on fail, and the staff alert fires.

The compliance gate that matters. Identity verification has to pass before the Karbon contact flips from prospect to client. The practice's original flow ordered the identity check after client creation. We reversed it structurally. A prospect does not become a client until their identity is verified. The AML obligation is enforced by the system, not by anyone remembering. There is no procedural way to bypass the check.

On CLIENT_IN_KARBON, the service posts to XPM via POST /clients. VXT picks up the change through Karbon's native ten-minute sync. Mailchimp picks it up through the existing Karbon-to-Mailchimp pipeline.

ATO Tax Agents Portal registration. For individual clients, a task is generated for the operator (default: the principal, reassignable in config), who completes the portal action in a browser and clicks a confirmation link. For companies, trusts, and other entity types, the client first has to authorise the firm as their tax agent via the ATO portal; the service tracks that authorisation, follows up at 48 hours if it has not arrived, and then generates the registration task. Every action records a timestamp and the operator ID.

Every transition writes one row to an append-only audit_events table. Seven-year retention. No update, no delete. Under audit, the principal runs one query per client and gets a complete timestamped history of every action on that client's onboarding.

What we expect to measure

In-flight, targets below. Real numbers published when the first cohort runs in production.

Time from first Calendly booking to fully onboarded client: expected to measure under 5 business days, down from the practice's current estimate in the two-to-three week range.

Staff-hours per new client, onboarding only: expected to measure under 1 hour, from a current estimate of 4 to 6 hours of combined staff time spread across forwarding, re-entering, chasing, and checking.

Percentage of the eleven onboarding steps automated: expected to measure at least 70 percent. Steps 3 (meeting notes), 5 (engagement creation in Karbon UI, because no Engagements API exists), and 11 (the ATO portal manual action) stay human. Everything else runs without staff touching it.

AML/ID audit completeness post 2026-07-01: expected to measure 100 percent. Every new client from go-live onward has a Stripe Identity session ID, pass or fail verdict, both timestamps, the operator ID on any review, and the full Cognito onboarding form snapshot, all in the audit table.

Onboarding drop-off rate (started but not completed within 14 days): expected to measure under 15 percent. Currently unknown because nothing tracks it.

Data re-entry incidents per month: expected to measure zero. Currently somewhere between "several" and "I have no idea" depending on which staff member you ask.

These are targets because they have to be. The first cohort of real clients running through the Phase 1 system is the first evidence. We will publish what we actually observe once the data is in.

For practices not ready yet

Ten weeks is not enough time to commission a build like ZeroTouch from scratch if you have not started. The 2026 TPB AML deadline does not care about project timelines. A practice that wants a coded system live by July 1 needed to start in February.

Three moves still possible inside the remaining window, in order of operational return.

One. Pick one identity vendor and configure it standalone. Stripe Identity is quick to stand up: the practice issues a verification session link by hand from the dashboard, sends it to a new client, archives the completed verdict PDF. Not automated. Audit-compliant under TPN 5/2022. A staff member opens Stripe once per new client. Ugly interim, and it works.

Two. Lock the retention. A shared folder with a fixed naming convention (client name, date of verification, PDF verdict) is defensible under audit. Not elegant. The thing that fails an audit is not having the record.

Three. Write one SOP for staff. Who sends the Stripe Identity link. Where the PDF gets saved. What the staff member writes in Karbon to mark the verification done. When the SOP says "escalate to principal," what triggers that. Fifteen minutes with a senior staff member, written down, shared across the team, is a baseline that gets the practice to July 1 standing.

When capacity exists to think beyond the deadline, the honest next move is a scoped audit of the full onboarding flow, decide which steps are worth automating, build from there. A sixteen-week build from cold becomes a four-to-six-week build if the audit has already been done and vendor access is in place.

Close

The AI automation for Australian accounting practices conversation is going to keep getting louder between now and July. Most of what will be said is noise. The signal is whether a practice can demonstrate, on audit, that every new client has a sighted identity document, a timestamped record, an auditable chain of custody on the data, and a team not burning out to keep it together.

If you are running a practice and you want to look at the build-vs-hire shape honestly for your own firm, there is a page on the site that walks through the back-office engagements we scope. A twenty-minute call is how we start. We are not the biggest Karbon automation consultant you will find. We are the one building a working AML compliance automation Australia system right now, under the same deadline you are under, for a firm whose principal decided he would rather own the code than rent the compliance.

Phase 1 ships June 15. We will write back when the first cohort of real clients has run through it.