Compliance / Swootle Research / 2026-07-18
Compare AUSTRAC Tranche 2 software by workflow coverage, provider boundaries, human review, implementation fit and post-commencement operating needs.
AUSTRAC Tranche 2 software: a buyer guide for Australian AML/CTF workflows
AUSTRAC Tranche 2 software should help an Australian reporting entity operate the customer, evidence, risk, review and escalation steps in its AML/CTF program. The strongest buying candidates let a team configure questions, conditions, branches, document requests, individual and entity relationships, risk routes and human approvals, while making clear which verification or screening work is performed by another provider. No software product decides whether a business is regulated, supplies legal advice or proves compliance by itself.
This is a commercial evaluation guide, not legal advice. The AML/CTF regime for newly regulated sectors has been in force since 1 July 2026. AUSTRAC says the new regime includes real estate, conveyancing, legal services, accounting and precious stones and metals, with obligations including AML/CTF programs, customer due diligence, suspicious matter reporting and relevant records. Read the Tranche 2 AML requirements checklist for the regulatory overview and use AUSTRAC’s current material for your own scope and implementation decisions.
Answer first: what should AUSTRAC Tranche 2 software do?
Choose software that can turn your approved AML/CTF operating model into a visible workflow for the actual services you provide. It should be able to:
- ask different questions and request different documents for individuals, companies, trusts, relationships, matters or transactions;
- apply configured conditions and risk routes, including additional evidence, escalation and human approval;
- give customers a controlled portal for submissions and give staff a clear view of missing information and review work;
- carry provider-dependent KYC, KYB or screening results into the relevant workflow when the implementation supports those connections;
- start a reusable refresh workflow and retain the new submission and decision context alongside the relationship’s earlier context; and
- show the boundary between workflow support, external checks, reporting, records, legal interpretation and the firm’s own AML/CTF program.
If a demonstration only shows an individual identity pass, it has shown one possible input, not an AUSTRAC Tranche 2 operating model. If a vendor claims that its platform automatically enrols every customer, continuously monitors every relationship or creates a complete immutable audit history without defining the underlying service, ask for the exact implementation evidence before relying on the claim.
For buyers ready to evaluate the commercial operating model, see the Australian AML workflow software hub.
What changed for Australian buyers after 1 July 2026?
The post-commencement question is no longer simply whether a firm can prepare for a future rule change. A business providing a designated service needs to understand its current scope, enrolment position, AML/CTF program, customer due diligence path, reporting responsibilities and records. The AUSTRAC factsheet for Tranche 2 reporting entities says businesses providing newly regulated designated services must enrol within 28 days of providing a designated service. It also identifies 29 July 2026 as the typical due date for the initial new-service cohort.
That distinction matters on 4 August 2026. The 29 July date was the initial cohort milestone, not a universal replacement for the standing 28-day rule. A firm that has commenced a designated service should confirm its enrolment and reporting-entity position with AUSTRAC and qualified advisers. A firm that has not commenced should not use software marketing copy as a substitute for the scope and timing analysis.
AUSTRAC’s updated regulator statement of expectations says the AML/CTF approach is risk-based rather than one-size-fits-all. It expects businesses to understand and document their risks and controls, to consider whether a program starter kit suits their characteristics, and to keep improving implementation after commencement. That gives buyers a useful software test: can the product carry the firm’s configured differences, or does it force every customer and service through the same checklist?
Category boundaries: do not buy the wrong layer
“AML software” can describe several different product categories. Compare the layers explicitly before comparing feature lists.
Workflow and orchestration software
Workflow software coordinates questions, conditions, branches, document requests, customer submissions, review tasks, approvals and decision context. It is useful when a firm has an AML/CTF policy and risk approach but needs a repeatable operating path for staff and customers. It should make responsibility and next action visible.
Workflow software does not automatically determine whether the policy is legally sufficient, whether a designated service applies, or whether a suspicious matter must be reported. Those remain the firm’s responsibility.
Identity verification and KYC/KYB providers
Identity verification checks information using a method or external provider. KYC and KYB providers may verify individuals, businesses or documents, depending on the arrangement. These checks are inputs to customer due diligence, not the complete CDD process.
Ask whether the proposed workflow connects the provider result to the right person or entity, what happens when a result is unavailable or ambiguous, and which team reviews the outcome. Confirm the provider, data source, country coverage, integration method, data retention and commercial terms separately. Do not assume native DVS, registry or broad named-provider integrations.
Screening providers
PEP, sanctions and adverse-media screening are separate provider-dependent capabilities. A workflow can request a screening step, receive or record an external result where configured, and route an exception to a reviewer. That does not mean the workflow product performs native screening, owns list coverage or decides whether a match is relevant.
Case management
Case management organises queues, ownership, notes, priorities, tasks and investigation status. It can sit beside a workflow, but a case record alone may not enforce the questions, branches, evidence requests or approval path that the firm needs. Conversely, workflow software may support structured review without being a full investigation or enterprise case-management system. Compare the operating sequence, not just the category label. The case management versus workflow comparison explains the distinction.
AML program and legal advice
An AML/CTF program contains the firm’s risk assessment, policies, procedures, systems and controls. AUSTRAC’s program starter kits may help a business whose characteristics fit a kit, but the firm must decide whether that fit exists and how its own risks are addressed. Software can implement selected questions and controls; it is not the program owner, legal adviser or regulator.
Reporting and records
The firm remains responsible for suspicious matter reporting, other applicable reports, records and the controls around them. A workflow may route an internal concern, capture an approval or record that a reporting decision was made, but it should not be described as native AUSTRAC reporting unless that exact capability is verified. Likewise, ask what records can be retrieved and exported; do not infer a complete immutable audit ledger or complete export history from a generic activity log.
Buyer matrix: what to compare and how to qualify it
Use this matrix during demos and procurement. Ask the vendor to label each item as native, configurable, provider-dependent, integration-owned or out of scope.
| Capability | Evidence to request in a demo | Boundary to confirm |
|---|---|---|
| Service and scope context | A service, matter or transaction selection that changes the workflow path | The tool does not decide legal applicability or reporting-entity status |
| Customer and relationship intake | Individual, company, trust and related-party questions with visible relationships | Relationship collection is not universal beneficial-ownership resolution |
| Conditional evidence | Different document requests for customer type, risk or service | Document collection does not establish that evidence is legally sufficient |
| Configured risk | A declared factor routes a file to added questions, review or approval | The configured result is not a universal risk model or legal conclusion |
| Provider-dependent checks | An external KYC, KYB or screening result is associated with the right subject | Verify provider, integration, coverage, errors and commercial scope |
| Human review | Reviewer return, escalation, approval, comments and decision context | Accountable judgement remains with the firm |
| Reporting pathway | A suspicious indicator or concern routes to the nominated internal owner | Confirm how, where and by whom any report is submitted |
| Refresh workflow | New information and a new decision are retained alongside earlier context | Do not infer a native scheduler or continuous-monitoring runtime |
| Records and retrieval | The vendor identifies the fields, documents, actions and exports available | Do not assume complete immutable history or complete export coverage |
| Change management | A configured flow is tested, reviewed and published with ownership | Confirm versioning, permissions, rollback and implementation support |
The matrix is deliberately less impressive than a long feature checklist. It makes the buyer ask who operates each control and what evidence will exist when the file is reviewed.
Representative-file demo tests by sector
Bring representative files, not generic sample data. A vendor should be able to explain what the product handles, what an external provider handles and what your staff must decide.
| Sector | Representative file | What to observe |
|---|---|---|
| Legal services | A property or entity-transfer matter with a company, trust, representative, source-of-funds request and partner approval | Matter context, related parties, conditional evidence, escalation and approval rationale |
| Conveyancing | A buyer represented under an authority, with third-party funds, settlement pressure and an incomplete document request | Customer and matter branches, missing information, return path and reviewer ownership |
| Accounting | A company owned through a trust with overseas participants, related entities and a service-specific risk route | Entity and relationship collection, configured risk, added evidence and human review |
| Real estate | Buyer and seller files involving a property, overseas party, transaction context and a question requiring internal escalation | Separate party paths, transaction context, document requests and decision handoff |
| Trust and company services | A layered structure with a corporate trustee, controller changes, intermediary instructions and a refresh request | Role-specific questions, ownership context, new submission and retained decision context |
| Precious stones and metals | A customer and repeat transaction path where the firm’s risk assessment requires additional information | Customer and transaction questions, conditional evidence, reviewer route and reporting pathway ownership |
The minimum success condition is not a green dashboard. It is a coherent path from the selected service to the customer questions, documents, configured route, reviewer decision and next action. A vendor that cannot run a realistic file may still supply a useful point capability, but the buyer should not call that an end-to-end Tranche 2 solution.
Implementation architecture for a post-commencement program
Software selection is only one part of implementation. Separate the following layers so that missing responsibilities do not disappear into a product label.
1. Scope and program ownership
Confirm the designated services, Australian nexus, customer types, risk assessment, AML/CTF compliance officer, governance approvals and applicable reporting duties. Use AUSTRAC’s latest guidance updates as a dated source index, and record where the firm has adopted its own reasonable position because the guidance does not settle an issue.
2. Workflow design
Map the service, customer, entity, relationship and transaction questions that the approved program requires. Configure branches for individuals, companies, trusts, representatives and higher-risk paths. Make each document request and approval stage explainable to the operations team that will use it.
3. Provider and integration design
Identify where KYC, KYB, identity, sanctions, PEP, adverse-media or other external results originate. Define the subject identifier, result fields, error handling, retry or manual fallback, reviewer handoff and retention. An API or generic HTTP call is an integration mechanism, not evidence of broad native coverage.
4. Decision and reporting design
Define who reviews missing information, high-risk routes, provider-dependent results and suspicious indicators. Specify return, escalation, approval and decline or stop-work outcomes. Keep the workflow’s internal context distinct from the firm’s reporting decision and the mechanism used to submit any report.
5. Test, train and improve
Run synthetic and controlled files from each relevant sector. Include missing, contradictory and late evidence, an external result needing human review, an ownership change and a post-commencement reporting-pathway exercise. Train staff on the firm’s program and the workflow’s actual boundaries. Revisit the configuration as risks, services and AUSTRAC material change.
Post-commencement action list
For a newly regulated business that is already providing a designated service, the sensible sequence is:
- Confirm the service and geographical-link analysis with AUSTRAC’s current guidance and qualified advice.
- Check enrolment status against the 28-day rule and the initial 29 July 2026 cohort date where relevant; do not treat the cohort date as an ongoing universal deadline.
- Confirm the AML/CTF risk assessment, program approval, compliance officer, staff training and review responsibilities.
- Define the customer due diligence, enhanced due diligence, suspicious matter and record workflows your business actually needs.
- Test the software with representative files before relying on it in live operations.
- Record the provider, integration, retention and export boundaries that remain outside the workflow product.
The Tranche 2 calculator can help structure an initial conversation, but it does not decide legal applicability.
Red flags in a Tranche 2 software demo
Be cautious when a vendor:
- presents a single identity result as the full customer due diligence process;
- treats compliance or audit conclusions as a product setting rather than a firm-specific conclusion;
- claims that one workflow resolves every beneficial owner, controller or layered structure;
- describes provider-dependent KYC, KYB or screening as native without naming the provider and execution boundary;
- implies native PEP, sanctions, adverse-media or continuous-monitoring runtime without showing the data source, timing and owner;
- promises automatic enrolment or reporting without showing the responsible system, approvals and failure handling;
- calls a generic activity log a complete immutable audit ledger or complete export history;
- cannot show a reviewer returning a file, requesting more information, escalating it and approving it with context; or
- refuses to separate configurable product behaviour from implementation work and legal responsibility.
Questions to ask every vendor
- Which parts of this file are native workflow configuration, and which require an external provider, API, generic HTTP call or manual work?
- Can we branch by designated service, customer type, entity, relationship, matter, transaction and configured risk factor?
- Can a customer submit documents through a portal, and can staff return a request without losing the earlier context?
- How are individuals, companies, trusts and related relationships represented, and what does the product not resolve automatically?
- How does a provider-dependent KYC, KYB or screening result enter the correct review path?
- Can reviewers add a decision, rationale, approval, escalation or unresolved item without presenting the workflow as legal advice?
- Can we reuse a refresh workflow and distinguish the new submission and decision from earlier context?
- What triggers a refresh in this deployment, and who owns scheduling or event detection if the product does not?
- What records can be retrieved or exported, for which roles, with what retention and history limitations?
- How are configuration changes approved, tested, versioned, published and rolled back?
Where Swootle fits
Swootle is workflow infrastructure for teams that have defined their AML/CTF operating requirements and need a configurable way to run them. Swootle supports configurable workflows, questions, conditions and branches; a customer portal; document requests; individual, entity and relationship collection; configured risk; human review and approval; and reusable refresh workflows that retain new submission and decision context.
That means a team could configure an individual, entity or matter journey, request the documents required by its own policy, route a configured risk outcome to a reviewer, capture an approval decision and use a related refresh workflow when new information is supplied. KYC, KYB and screening checks are provider-dependent and must be confirmed for the proposed deployment. Swootle does not claim to determine AUSTRAC scope, provide an AML program or legal advice, submit reports by default, provide native scheduling or continuous-monitoring runtime, automatically enrol customers, execute native PEP/sanctions/adverse-media checks, resolve every beneficial-owner chain, provide native DVS or registry integrations, or guarantee a complete immutable audit ledger or complete export history.
Start with the workflow orchestration product page, review the customer portal and risk review surfaces, consider ongoing review workflows, read the security overview, or book a product walkthrough. Bring one of the representative files above so the fit can be tested against actual requirements.
Frequently asked questions
What is AUSTRAC Tranche 2 software?
It is a buyer term for software used by newly regulated Australian businesses to operate selected AML/CTF work such as customer intake, due-diligence questions, evidence requests, configured risk routes, human review, approval and refresh. It is not a regulatory product category with one mandatory feature set.
Is AUSTRAC Tranche 2 software mandatory?
No specific software product is mandatory. The business must meet the obligations that apply to its designated services and circumstances. Software may help make the agreed process repeatable, but it does not replace the firm’s AML/CTF program, judgement, reporting responsibilities or legal advice.
What should I test first?
Test a realistic file from the firm’s highest-volume or highest-complexity service. Include an individual or entity, a relationship or ownership question, missing evidence, a configured risk route, human approval and a new review context. Then ask which parts are native, provider-dependent and implementation-owned.
Does Tranche 2 software need identity verification and screening?
The firm may need identity verification, KYC, KYB or screening arrangements as part of its customer due-diligence process, depending on its program and risk. Those are separate capabilities and are often provider-dependent. A workflow product can route or record a result where configured; verify the provider, integration and reviewer process rather than assuming native checks.
Can software decide whether my business is regulated?
No. Applicability depends on the designated services, geographical link and circumstances. Use AUSTRAC’s current scope material and qualified advice. A calculator or workflow may help structure the questions but should not be treated as a legal determination.
Does the 29 July 2026 deadline still apply to every business?
It was the typical initial due date for the new designated-service cohort. AUSTRAC’s factsheet also states that enrolment is generally within 28 days of providing a designated service. Businesses should assess their actual commencement and enrolment position rather than treating 29 July as a universal ongoing deadline.
Is Swootle an AML or legal compliance provider?
No. Swootle provides configurable workflow infrastructure. The business remains responsible for its scope analysis, AML/CTF program, risk settings, provider arrangements, reporting decisions, records and professional advice.
Sources and review note
This guide uses AUSTRAC’s new reporting regime now in force, Tranche 2 obligations factsheet, May 2026 regulator statement of expectations, program starter kits and latest guidance updates, all checked on 4 August 2026. AUSTRAC’s material is authoritative for its published guidance; this article is general commercial information, not legal advice or a statement that any particular workflow is compliant.
Swootle Compliance Research reviewed this guide against the official AUSTRAC sources and current Swootle product boundaries on 4 August 2026. No third-party product was hands-on tested for this page, and this is not a named legal opinion or procurement endorsement. Read about the team’s compliance-operations background, then recheck the official sources, the firm’s own program and the proposed product scope before implementation.
Put the guide into practice
Evaluate a representative AUSTRAC workflow with Swootle
Bring one anonymised representative case. We will map the customer request, evidence, exceptions and accountable decision, then identify whether Swootle fits the operating model.