AML/CTF Tranche 2 Software Requirements Australia

Australia's AML/CTF Tranche 2 regime requires newly regulated businesses to do more than document a compliance policy: their systems need to support customer due diligence, ongoing risk management, suspicious matter reporting, and required recordkeeping. Real estate professionals, lawyers, accountants and other affected businesses came under the regime on 1 July 2026, with AUSTRAC enrolment required for newly regulated businesses. Software therefore needs to turn these obligations into repeatable operational workflows rather than leave them in spreadsheets and disconnected files.

Who does AML/CTF Tranche 2 actually capture?

AML/CTF Tranche 2 brings a range of professional services into Australia's AML/CTF regime for the first time. From 1 July 2026, the reforms apply to businesses providing specified designated services in sectors including real estate, legal services, accounting, conveyancing, and precious metals and stones. The important qualification is that being part of one of these professions does not automatically mean every activity is regulated. The obligations attach to businesses when they provide designated services covered by the legislation.

For real estate firms, this can mean parts of property transactions that previously operated without direct AML/CTF reporting obligations now require formal controls around customer identification, risk assessment, monitoring and reporting.

For law firms, the impact depends on the designated services they provide. Client onboarding, beneficial ownership information, source-of-funds considerations and transaction activity can become part of a broader AML/CTF workflow where the firm's services fall within the regime.

Accounting practices face a similar shift. Certain services involving financial transactions, structures or assets can bring the practice within the scope of the new requirements, making AML/CTF controls part of the operational process rather than an isolated compliance exercise.

AUSTRAC's current guidance makes the operational expectation clear: newly regulated businesses need an AML/CTF program, an AML/CTF compliance officer, trained staff, appropriate customer due diligence processes, reporting capability and recordkeeping arrangements.

This is the key distinction for software planning. The question is not simply whether a firm has an AML/CTF policy document. The question is whether its day-to-day systems can consistently execute the controls described in that policy.

What software needs to do differently under Tranche 2

A conventional practice management or CRM platform is usually designed around clients, matters, documents, communications and billing. AML/CTF requirements introduce another layer: the system needs to capture evidence that the firm identified its customers, assessed relevant risks, monitored relationships and acted when activity required further investigation.

That starts with customer due diligence.

A software workflow should be able to collect and validate the information required for customer identification and verification, while also recording beneficial ownership and relevant risk information where applicable. It should distinguish between information that has been requested, information that has been verified, and information that remains outstanding.

The workflow also needs to accommodate risk-based decision-making.

Not every customer presents the same level of money laundering, terrorism financing or proliferation financing risk. The software should therefore allow the firm to apply its documented risk methodology rather than treating every customer as identical.

A higher-risk relationship may require additional information, enhanced review or more frequent reassessment. A lower-risk relationship may follow a simpler workflow. The system needs to preserve the reason for the resulting risk classification rather than merely storing a risk label.

Ongoing customer due diligence creates another requirement.

Customer information does not become permanently correct simply because it was verified during onboarding. Changes in ownership, business activity, transaction behaviour or other risk indicators can require information to be reviewed and updated. AUSTRAC describes ongoing CDD as including monitoring transactions and behaviours for suspicious activity, updating customer risk profiles in response to triggers, and reviewing or re-verifying information when needed.

That makes an event-driven workflow considerably more useful than a static onboarding checklist.

The system can create review tasks when defined triggers occur, maintain the history of previous assessments, and show compliance staff why a customer's risk status changed.

Customer due diligence needs an audit trail

One of the easiest mistakes is to build a KYC form without building the evidence around it.

A compliance team may need to establish not only what information was collected but when it was collected, who reviewed it, what verification occurred, what risk assessment was made, and what action followed.

The software therefore needs an audit trail that is difficult to alter retrospectively and easy to review.

Each significant compliance event should have a clear timestamp, responsible user and relationship to the relevant customer or matter. Changes to important fields should be traceable rather than simply overwriting the previous value.

Document management also matters.

Identity documents, ownership information, risk assessments, review notes and supporting evidence may need to remain associated with the customer record for the required retention period. The application should make those records searchable and accessible to authorised personnel without turning the compliance team into a document-retrieval service.

Permissions are equally important.

AML/CTF information can contain sensitive customer and risk information. A system should therefore distinguish between users who can view customer records, users who can conduct compliance reviews, and users authorised to submit or approve reports.

This becomes particularly important for larger professional services firms where multiple offices or practice teams share the same technology platform.

Transaction monitoring and suspicious matter reporting

Customer due diligence establishes who the firm is dealing with. Monitoring helps the business identify activity that may require further investigation.

The software does not need to make an automated accusation that a customer is involved in criminal activity. That is not the purpose of a compliance system.

Instead, it should help surface activity and indicators that require human review.

Transaction monitoring can be designed around the firm's actual risk profile. A real estate business may need to identify unusual transaction patterns, complex ownership arrangements or activity involving higher-risk jurisdictions. A legal or accounting practice may have different indicators based on the designated services it provides.

The important architectural principle is that monitoring rules should be configurable.

The firm should be able to define what constitutes an alert, who receives it, what information must be reviewed, and what escalation path applies. A monitoring alert should then become part of a controlled investigation workflow rather than an email that disappears into someone's inbox.

If a matter results in a suspicious matter report, the system should preserve the reasoning and supporting evidence behind the decision.

AUSTRAC's current guidance states that businesses need processes to identify suspicious activity, review relevant material and submit an SMR when the reporting obligation arises. For suspicious matters involving terrorism financing, the reporting timeframe is 24 hours after the suspicion is formed; for other suspicious matters, the timeframe is three business days.

The software therefore needs to make deadlines visible and actionable.

It can record the point at which a suspicion was formed, assign the matter to an authorised reviewer, maintain investigation notes, track approval steps and retain the information used to prepare the report.

AUSTRAC's updated reporting system and forms are now in force for the reformed regime. Businesses enrolled after 30 March 2026 must use the new SMR form from 1 July 2026, while entities enrolled on 30 March 2026 have a transition period for the new form.

That does not mean every firm needs to build a direct API integration with AUSTRAC immediately. The right architecture depends on the firm's reporting volume, internal controls and operational model. What the software should provide is a reliable reporting workflow that can prepare, review, authorise and document the information required for submission.

AUSTRAC enrolment is part of the system context

Enrolment is an organisational obligation, but software needs to account for it because the firm's regulatory status affects the wider compliance workflow.

AUSTRAC states that newly regulated businesses must enrol, with the general requirement being to apply through AUSTRAC Online no later than 28 days after the day the business starts providing a designated service. AUSTRAC also previously set 29 July 2026 as the enrolment deadline for businesses newly regulated from 1 July 2026.

Most newly regulated businesses only need to enrol. Additional registration requirements apply to businesses providing remittance or virtual asset designated services.

For software, the practical implication is that regulatory status, designated services, compliance officer information and AML/CTF program details should be represented clearly where the organisation needs them for internal governance.

The application should not pretend that completing a software form constitutes AUSTRAC enrolment. Instead, it should help the firm maintain the internal evidence and controls required around its regulatory obligations.

Recordkeeping cannot be an afterthought

AML/CTF compliance generates records at almost every stage of the customer relationship.

A firm may need to retain customer identification information, verification evidence, risk assessments, review outcomes, transaction monitoring records, investigation material, reporting information and other records required by the AML/CTF framework.

The software architecture needs to treat those records as part of the compliance system rather than incidental files.

This means defining retention rules, access permissions, document relationships and auditability from the beginning. It also means ensuring that deleting or changing a customer record does not unintentionally destroy evidence that the firm is required to retain.

Search and retrieval are operational requirements too.

A compliance review should not require someone to search through email threads, shared drives and multiple matter folders to reconstruct what happened. The system should be able to show the relevant customer history, decisions, documents and actions in a coherent timeline.

That becomes especially valuable during an internal review or regulatory engagement.

AUSTRAC expects newly regulated businesses to have systems and processes in place to meet their reporting and recordkeeping obligations. Its current regulatory expectations also emphasise that newly regulated businesses should be enrolled, have an AML/CTF program and compliance officer, train staff, and be ready to report when a suspicious matter arises.

The compliance checkbox problem

The most common software mistake is treating AML/CTF as a form that needs to be added to an existing workflow.

A firm may add a KYC page to its CRM, upload a copy of its AML/CTF policy and create a checkbox labelled "verified". On paper, the system now appears to support compliance.

Operationally, very little may have changed.

If the software does not know when a review is due, who needs to complete it, why a customer was classified as higher risk, what evidence supports the classification, whether a suspicious activity alert was investigated, or when a report was submitted, the firm is still relying heavily on manual processes.

That creates the risk of compliance drift.

A policy may say that certain customers require enhanced review, while the software provides no workflow for triggering that review. Staff may be expected to monitor activity, but transaction data may remain in a separate accounting or practice management system. A suspicious matter may be identified, but there may be no controlled process for escalation and reporting.

The technology therefore needs to reflect the firm's actual AML/CTF operating model.

The strongest implementations do not attempt to automate every compliance judgement. They automate the repeatable parts while preserving human review where professional judgement is required.

That distinction matters because AML/CTF is fundamentally risk-based. Software can collect evidence, calculate or surface risk indicators, trigger reviews and maintain records. It should not obscure the human decisions that sit behind those controls.

Build vs. retrofit for existing practice systems

For a firm that already has a practice management, CRM, accounting or case management platform, the first question should not be whether to replace it.

A retrofit can make sense when the existing platform already contains reliable customer and matter data and exposes suitable integration points. An AML/CTF layer can then add customer due diligence workflows, risk assessment, monitoring, alerts, reporting workflows and compliance records without replacing the firm's core operational system.

The architecture needs to be carefully designed around system ownership.

The existing practice platform may remain the source of truth for customer and matter information, while the AML/CTF application manages compliance-specific assessments and events. APIs can synchronise relevant information between the systems while maintaining clear ownership of each data domain.

This approach can work particularly well for firms that have invested heavily in their existing technology.

The alternative is a deeper rebuild where compliance workflows are designed directly into a new practice or case management platform. This can make sense when the existing system is highly fragmented, cannot expose the required data, has limited workflow capabilities, or would require extensive customisation simply to support basic AML/CTF controls.

The decision should be based on architecture rather than the novelty of the technology.

A retrofit is not automatically simpler if the existing system has poor data quality or no usable integration layer. Conversely, a new application is not automatically better if the existing platform already handles customer and matter management effectively.

The practical objective is to create one reliable compliance workflow without forcing staff to maintain parallel customer records.

For a real estate agency, that could mean connecting property transaction data, customer identity information and risk assessments. For a law firm, it could mean connecting client and matter records with CDD and monitoring workflows. For an accounting practice, it could mean connecting client records and relevant transaction information with risk review and reporting processes.

The technology should follow the firm's actual operating model.

AML/CTF Tranche 2 software requirements at a glance

Requirement	What It Means	Software Implication
Customer due diligence	Customers need to be identified, verified and assessed according to the firm's risk-based AML/CTF approach.	Structured onboarding, identity verification, beneficial ownership data, risk assessment and review workflows.
Ongoing monitoring	Customer risk and relevant activity need to be reviewed when circumstances or defined triggers require it.	Configurable monitoring rules, risk-profile updates, alerts and scheduled reviews.
Suspicious matter reporting	Firms need processes to identify, investigate and report suspicious matters within the applicable timeframe.	Alert escalation, investigation workflows, deadline tracking, reporting records and controlled access.
AUSTRAC enrolment	Newly regulated businesses need to enrol with AUSTRAC and maintain the required organisational arrangements.	Regulatory-status records, compliance officer information and internal governance workflows.
Recordkeeping	Required CDD, monitoring, reporting and supporting records need to be maintained and retrievable.	Audit trails, document retention, searchable histories, permissions and controlled record changes.
Existing system integration	AML/CTF controls need to operate alongside the firm's existing practice, case, CRM or accounting systems.	API-based integration, clear data ownership and synchronised customer and matter information.

Frequently Asked Questions

What is AML/CTF Tranche 2 in Australia?

AML/CTF Tranche 2 refers to the expansion of Australia's anti-money laundering and counter-terrorism financing regime to specified designated services provided by sectors including real estate, legal services, accounting, conveyancing, and precious metals and stones. The new obligations for these newly regulated businesses commenced on 1 July 2026.

Do Tranche 2 businesses need AML/CTF software?

Not necessarily. The law requires regulated businesses to meet their AML/CTF obligations, but it does not prescribe that they must purchase or build a particular type of software. However, software can be important for implementing repeatable customer due diligence, risk assessment, monitoring, reporting and recordkeeping processes, particularly as transaction and customer volumes increase.

What does AML/CTF software need to track?

It should be capable of supporting customer identification and verification, relevant beneficial ownership information, risk assessments, ongoing reviews, transaction or behavioural monitoring, suspicious matter investigations, reporting workflows and required records. The exact implementation should reflect the firm's designated services and documented risk profile.

Can existing practice management software be adapted for AML/CTF Tranche 2?

Yes. A firm may be able to retrofit AML/CTF workflows into an existing practice management, CRM or case management system if the platform has suitable data structures, workflow capabilities and integration points. A separate compliance application may be more appropriate where the existing system cannot reliably support the required controls.

When did AML/CTF Tranche 2 obligations start?

For newly regulated businesses providing covered designated services, the AML/CTF obligations commenced on 1 July 2026. AUSTRAC's current guidance also states that newly regulated businesses must apply to enrol no later than 28 days after the day they start providing a designated service.

Build AML/CTF compliance into the workflow, not around it

Tranche 2 changes the operational reality for Australian real estate, legal and accounting firms. Compliance is no longer something that can sit entirely inside a policy document while customer onboarding, transactions and matter management happen elsewhere. The technology needs to create a reliable connection between the firm's AML/CTF program and the work staff actually perform.

That does not automatically mean replacing an existing practice management system or building a completely new platform. In many cases, a well-designed integration layer or targeted compliance workflow can extend an existing system. Where the underlying architecture cannot support the required controls, a more substantial rebuild may be justified.

Pixbit Solutions works with businesses that need to translate operational and regulatory requirements into custom software, using technologies including Laravel, React, Next.js and Flutter. The focus is on understanding the existing workflow first, then determining what should be integrated, extended or rebuilt.

If your firm is assessing its technology requirements under AML/CTF Tranche 2, Pixbit can scope the appropriate approach around your existing systems, workflows and compliance requirements. Pixbit scopes exact cost and timeline in a single discovery session.