Australia's regulatory calendar places several major software-impacting obligations into effect across 2026 and early 2027. On 31 March 2026, entities preparing for expanded anti-money laundering obligations reach an important readiness milestone ahead of implementation. On 1 July 2026, four significant obligations arrive simultaneously: AUSTRAC's AML/CTF Tranche 2 regime begins, APRA's CPS 230 contract remediation deadline takes effect, Australia's climate-related financial disclosure requirements commence for the first reporting cohort, and core obligations under the Scams Prevention Framework begin for designated banking organisations. On 1 September 2026, the Digital Platforms Code under the Scams Prevention Framework commences for designated digital platforms. On 10 December 2026, new Privacy Act transparency obligations around automated decision-making and the Children's Online Privacy Code commence under the OAIC reforms. Together, these dates shape how regulated Australian organisations evaluate, procure, and build software throughout 2026.

---

Australia's 2026 Regulatory Calendar

Date	Regulation	Who's Affected	What Software Must Do
31 March 2026	AML/CTF Tranche 2 implementation preparation milestone	Professional service firms, software vendors supporting newly regulated entities, implementation partners	Complete customer onboarding changes, identity verification capability, transaction monitoring preparation, risk assessment workflows, and compliance implementation planning before July commencement.
1 July 2026	AML/CTF Tranche 2 Commences (AUSTRAC)	Lawyers, accountants, trust & company service providers, real estate professionals, dealers in precious stones and metals, and software providers supporting them	Support customer due diligence, beneficial ownership, AML risk assessment, transaction monitoring, reporting workflows, audit logging, and record retention.
1 July 2026	CPS 230 Contract Remediation Deadline (APRA)	APRA-regulated banks, insurers, superannuation trustees and their critical service providers	Ensure third-party software contracts, operational resilience controls, incident reporting, business continuity, and vendor governance satisfy CPS 230 requirements.
1 July 2026	Mandatory Climate Reporting Begins	Large reporting entities entering the first climate disclosure cohort	Collect, govern, retain, and report sustainability and climate-related operational data with appropriate audit trails and governance controls.
1 July 2026	Scams Prevention Framework – Core Banking Obligations	Major banks designated under the SPF	Deploy scam detection, customer warning systems, reimbursement workflows, fraud intelligence sharing, and incident response capabilities aligned with the new framework.
29 July 2026	Privacy Act reform implementation milestone	Organisations preparing for later OAIC transparency obligations	Finalise governance documentation, automated decision-making disclosures, privacy notices, and implementation readiness before December commencement.
1 September 2026	Scams Prevention Framework – Digital Platforms Code	Designated digital platforms brought into the SPF by the ACCC framework	Implement scam reporting, account monitoring, fraud detection, consumer notification, evidence retention, and platform governance controls.
10 December 2026	Privacy Act Reforms (OAIC)	Businesses subject to the amended Privacy Act	Provide transparency around automated decision-making, comply with Children's Online Privacy Code requirements where applicable, and update privacy management systems.
1 January 2027	Expanded regulatory implementation period	Organisations completing 2026 compliance projects	Transition from implementation into operational compliance, governance monitoring, audit preparation, and ongoing regulatory reporting.
31 March 2027	First major post-implementation reporting cycle	Early adopters across regulated sectors	Demonstrate operational compliance through documentation, audit evidence, monitoring records, and regulator-ready reporting outputs.

AML/CTF Tranche 2: The Biggest Software Change of 2026

Among all Australian regulatory changes arriving in 2026, AUSTRAC's AML/CTF Tranche 2 reforms are likely to have the broadest impact on commercial software. Rather than introducing entirely new compliance concepts, the reforms expand Australia's existing Anti-Money Laundering and Counter-Terrorism Financing regime to industries that have historically operated outside the framework. For many professional services firms, this marks the first time customer onboarding, identity verification, risk assessment, transaction monitoring, and regulatory reporting become embedded parts of day-to-day operations.

From 1 July 2026, newly regulated entities—including legal practices, accounting firms, trust and company service providers, real estate professionals involved in designated transactions, and dealers in precious stones and precious metals—must comply with AUSTRAC's AML/CTF obligations. While the legislation applies to businesses, its practical implementation almost always depends on software.

This changes procurement priorities for organisations buying new systems during 2026.

Customer relationship platforms, client onboarding portals, document management systems, payment platforms, workflow applications, and internal administration software increasingly need to support compliance features that previously may not have been considered during procurement. Identity verification workflows, beneficial ownership capture, politically exposed person (PEP) screening, sanctions screening, customer risk scoring, record retention, audit logging, and suspicious matter reporting are becoming functional requirements rather than optional extensions.

The shift also affects organisations replacing legacy systems.

Historically, many professional firms relied on separate compliance tools alongside practice management software. Under Tranche 2, businesses increasingly benefit from integrating compliance directly into operational workflows instead of maintaining disconnected systems that require duplicate data entry and manual reconciliation. Every additional manual process increases the likelihood of inconsistent records and unnecessary administrative effort during regulatory reviews.

Software architecture therefore becomes part of compliance planning.

Applications that treat customer onboarding as a simple form submission may require substantial redesign to accommodate ongoing customer due diligence, periodic reviews, document refresh cycles, beneficial ownership updates, and risk reassessment over time. These capabilities are expected to operate alongside existing business workflows rather than interrupt them.

For software buyers, the important question is no longer simply whether a platform can manage clients or transactions. It is whether the system can generate the evidence required to demonstrate compliance during an AUSTRAC review while remaining usable for operational teams.

This topic is explored in greater technical depth in our AML/CTF software development guide, which examines implementation architecture, identity verification workflows, reporting automation, and compliance integration strategies for organisations preparing for Australia's expanded AML/CTF regime.

Privacy Act × AML/CTF: The Collision Most Buyers Miss

One of the easiest mistakes Australian software buyers can make in 2026 is treating Privacy Act reforms and AML/CTF Tranche 2 as separate compliance projects. In practice, they often affect the same customer records, the same onboarding workflows, and the same data architecture decisions.

AML/CTF obligations require organisations to collect and verify identity information, assess customer risk, monitor ongoing relationships, retain records, and maintain evidence for regulatory review. The OAIC's Privacy Act reforms, meanwhile, increase expectations around transparency, data governance, automated decision-making disclosures, and the handling of personal information. The result is that many businesses will be required both to collect more customer information for compliance purposes and to explain more clearly how that information is used.

This creates architectural tension rather than a simple compliance checklist.

A customer onboarding workflow built solely for AML requirements may capture the necessary identification documents, beneficial ownership information, and risk indicators, but still fail to meet emerging privacy transparency expectations if the organisation cannot explain automated risk scoring, document processing, or decision-making logic. Conversely, a privacy-focused system that minimises data collection may not retain sufficient evidence to satisfy AUSTRAC record-keeping obligations.

The intersection becomes particularly important for organisations implementing workflow automation.

Risk scoring engines, identity verification services, sanctions screening, fraud detection models, and customer segmentation algorithms increasingly involve automated processing of personal information. Under the evolving Privacy Act framework, organisations need stronger governance around how those automated processes operate and what information is provided to customers about them.

For software buyers, this means compliance architecture should be designed once rather than retrofitted twice.

Identity verification, consent management, audit logging, document retention, access controls, and reporting capabilities should operate within a single governed data model instead of being implemented separately by different teams. Applications that fragment compliance responsibilities across multiple disconnected systems often create unnecessary duplication and make regulatory evidence significantly harder to produce later.

The deeper technical implications of Australia's Privacy Act reforms—including automated decision-making transparency, consent architecture, and privacy-by-design implementation patterns—are explored in our dedicated Privacy Act software compliance guide.

---

Scams Prevention Framework: September Is the Date Many Platforms Will Feel

While AML/CTF affects how organisations know their customers, the Scams Prevention Framework (SPF) affects how designated entities prevent financial harm from occurring through their systems. The framework introduces sector-specific obligations that extend beyond traditional fraud monitoring and into customer protection, scam detection, and operational coordination across multiple organisations.

The implementation timeline matters.

Core obligations begin applying to designated banking organisations on 1 July 2026, but 1 September 2026 is the date many technology platforms will notice because the Digital Platforms Code commences for designated digital platforms. This is the point where scam prevention becomes a software workflow rather than simply a customer support issue.

From a developer's perspective, the SPF is less about a single feature and more about operational capability.

Platforms need mechanisms for identifying suspicious activity, escalating potential scam events, retaining evidence, supporting investigations, notifying affected users, and demonstrating that reasonable preventative controls were operating when incidents occurred. These capabilities typically span authentication systems, transaction monitoring, messaging tools, customer service platforms, and internal case management workflows.

What makes the SPF unusual is that it sits at the intersection of fraud, cybersecurity, customer experience, and regulatory compliance.

A scam warning shown to a customer, an account suspension triggered by suspicious behaviour, a reimbursement investigation, and a regulator-ready audit trail may all depend on the same underlying event data. Organisations that treat these as separate departmental systems often struggle to reconstruct what actually happened during a scam incident.

Software buyers evaluating platforms during 2026 should therefore ask a different set of questions than they would for traditional fraud tools.

Can the system link customer interactions, authentication events, payment activity, and investigation outcomes into one case record? Can evidence be retained for future dispute resolution? Can operational teams demonstrate what controls were active at the time of an incident? These questions become increasingly important as SPF obligations move from policy documents into day-to-day operations.

Our dedicated Scams Prevention Framework software guide examines the technical architecture behind scam detection, customer warning systems, evidence management, and platform governance in much greater depth.

CPS 230: Operational Resilience Becomes a Software Procurement Issue

While the AML/CTF reforms primarily affect customer-facing processes, APRA Prudential Standard CPS 230 focuses on how regulated financial institutions remain operational when systems, suppliers, or critical business services fail. By 1 July 2026, APRA-regulated entities are expected to complete remediation of contracts and governance arrangements so that critical service providers meet CPS 230 requirements.

Although the standard is directed at APRA-regulated organisations—including banks, insurers, and superannuation trustees—its impact extends well beyond those institutions. Any software vendor delivering a critical business service to an APRA-regulated customer increasingly becomes part of that customer's operational resilience obligations.

This changes how software is evaluated.

Historically, procurement focused on functionality, delivery timelines, and commercial terms. Under CPS 230, organisations must also understand how software providers manage operational risk, business continuity, incident response, subcontractors, disaster recovery, and service restoration. These questions are no longer reserved for enterprise procurement teams—they form part of regulatory compliance.

For software architecture, resilience becomes a measurable capability rather than an infrastructure preference.

Applications supporting critical operations should produce detailed audit logs, maintain clear service dependencies, support disaster recovery planning, provide documented recovery objectives where appropriate, and enable operational monitoring that demonstrates system availability during incidents. Vendor documentation increasingly becomes as important as the application itself because regulated organisations need evidence that outsourced technology can continue supporting critical business services.

This also affects contract design.

CPS 230 expects regulated entities to understand who provides each critical service, how risks are managed throughout the supply chain, and how incidents are reported and resolved. Software vendors therefore find themselves participating more actively in governance conversations that were previously handled only between procurement and legal teams.

For software buyers, CPS 230 is less about purchasing a resilient application than selecting a technology partner capable of supporting ongoing operational resilience throughout the software lifecycle.

Our dedicated CPS 230 software compliance guide explores third-party governance, operational resilience architecture, vendor obligations, and implementation considerations in greater technical detail.

---

Digital Health and My Health Record Interoperability

Healthcare organisations face a different regulatory challenge from financial services. Rather than focusing primarily on financial crime or operational resilience, Australian digital health initiatives continue to prioritise secure information sharing, clinical interoperability, and consistent patient record management across the healthcare ecosystem.

The Australian Digital Health Agency (ADHA) continues expanding interoperability initiatives around My Health Record, making system integration an increasingly important consideration for healthcare software buyers. Hospitals, specialist clinics, allied health providers, diagnostic organisations, and software vendors supporting these sectors are increasingly expected to design systems that exchange information accurately while maintaining appropriate privacy, security, and clinical governance.

This makes interoperability an architectural decision rather than simply an integration project.

Clinical software frequently interacts with electronic medical record systems, diagnostic platforms, referral networks, appointment scheduling solutions, patient portals, identity services, and government digital health infrastructure. Each additional connection increases the importance of consistent data models, secure authentication, auditability, and standards-based information exchange.

Unlike traditional application integrations, healthcare interoperability directly affects clinical workflows.

Delayed pathology results, incomplete referral information, duplicated patient records, or inconsistent medication histories can create operational inefficiencies and increase administrative workload. Software therefore needs to maintain reliable information exchange while preserving comprehensive audit trails and appropriate access controls expected across Australia's healthcare sector.

Healthcare providers also operate within an increasingly connected regulatory environment.

Privacy obligations administered by the OAIC, interoperability guidance from the ADHA, and broader cybersecurity expectations increasingly influence how healthcare applications are designed, hosted, integrated, and maintained throughout their lifecycle. Organisations replacing clinical systems during 2026 should therefore evaluate interoperability capabilities alongside functional requirements rather than treating integration as a later implementation phase.

Our Digital Health software development guide examines My Health Record integration, interoperability architecture, healthcare data exchange, and long-term platform design considerations for Australian healthcare providers.

What's Next, but Not Yet Designated

Australia's regulatory calendar does not end with the obligations that have confirmed commencement dates. Several sectors are expected to come within existing frameworks over time, making them important watch-items for organisations making software investment decisions today.

One of the most closely watched developments is the future expansion of the Scams Prevention Framework beyond its initial designated sectors. Following implementation for banking organisations and designated digital platforms, policymakers have indicated that additional industries may be brought into the framework through future designation instruments.

Two sectors appear most likely to receive continued attention.

The first is superannuation. Superannuation funds increasingly manage significant digital customer interactions, account changes, identity verification processes, and payment instructions that are attractive targets for sophisticated scam activity. Should additional SPF obligations extend into this sector, software supporting member services, authentication, fraud detection, payment approvals, and customer communications would likely require further governance and monitoring capability.

The second is the digital asset and cryptocurrency exchange sector.

Digital asset providers already operate within a complex regulatory environment involving AUSTRAC registration and anti-money laundering obligations. Future inclusion within additional scam prevention requirements would introduce another operational layer, particularly around transaction monitoring, customer warnings, account intervention workflows, evidence retention, and coordinated fraud response.

At present, however, these sectors should be treated as emerging policy rather than confirmed compliance deadlines.

Organisations planning long-term platform investments may benefit from building flexible compliance architecture capable of accommodating additional regulatory workflows without requiring significant redevelopment. Identity management, event logging, audit trails, notification engines, investigation workflows, and configurable governance controls tend to adapt more easily to future regulation than highly specialised point solutions designed around a single obligation.

For software buyers, the practical lesson is straightforward: build for adaptability where possible, while prioritising confirmed regulatory milestones over anticipated future requirements.

---

2026–2027 Compliance Summary

Date	Regulation	What Software Must Do
31 Mar 2026	AML/CTF Tranche 2 implementation readiness	Prepare onboarding, customer due diligence, monitoring, reporting, and record management capabilities before commencement.
1 Jul 2026	AML/CTF Tranche 2 (AUSTRAC)	Support identity verification, beneficial ownership, transaction monitoring, suspicious matter reporting, audit logging, and compliance evidence.
1 Jul 2026	CPS 230 Contract Remediation (APRA)	Demonstrate operational resilience, vendor governance, business continuity, and incident management capability.
1 Jul 2026	Climate Disclosure Requirements	Collect, govern, retain, and report climate-related operational data with appropriate auditability.
1 Jul 2026	Scams Prevention Framework – Core Banking Obligations	Enable fraud detection, customer protection workflows, reimbursement support, and investigation evidence.
29 Jul 2026	Privacy Act Implementation Milestone	Complete governance updates, transparency documentation, and implementation readiness activities.
1 Sep 2026	Scams Prevention Framework – Digital Platforms Code	Deploy scam detection, account monitoring, customer notification, evidence retention, and investigation workflows.
10 Dec 2026	Privacy Act Reforms (OAIC)	Support automated decision-making transparency, Children's Online Privacy Code obligations, and updated privacy governance.
1 Jan 2027	Operational Compliance	Transition completed implementations into ongoing governance, monitoring, and reporting.
31 Mar 2027	Early Reporting Cycle	Demonstrate operational compliance through regulator-ready documentation, audit evidence, and monitoring records.

---

Frequently Asked Questions

When does AML/CTF Tranche 2 start affecting Australian professional services firms?

AUSTRAC's expanded AML/CTF obligations commence on 1 July 2026, bringing a range of designated professional service providers—including lawyers, accountants, trust and company service providers, real estate professionals, and dealers in precious metals and stones—within Australia's AML/CTF framework.

What happens if my business isn't ready for the Scams Prevention Framework by September 2026?

Organisations designated under the Digital Platforms Code are expected to have the required scam prevention controls operating from 1 September 2026. Businesses should review the ACCC-administered framework and confirm whether their services fall within the designated scope.

Does CPS 230 apply to my software vendor if I'm not APRA-regulated myself?

CPS 230 is issued by APRA and applies directly to APRA-regulated entities. However, software vendors supporting those organisations may need to demonstrate operational resilience, governance, and service continuity because their customers must satisfy CPS 230 obligations.

What's the difference between the Privacy Act reforms and AML/CTF Tranche 2 obligations?

The Privacy Act reforms, overseen by the OAIC, focus on how organisations collect, manage, and explain the use of personal information, including automated decision-making transparency. AML/CTF Tranche 2, administered by AUSTRAC, focuses on customer identification, financial crime prevention, transaction monitoring, and regulatory reporting.

Will superannuation funds and crypto exchanges be added to the Scams Prevention Framework?

At the time of writing, no confirmed commencement dates have been announced for these sectors. Government consultation indicates that future designation remains possible, so organisations operating in these industries should continue monitoring developments rather than assuming immediate obligations.

Discovery Session

Australia's 2026 compliance calendar is unusual because several unrelated regulatory reforms arrive within the same six-month window. Organisations replacing or commissioning software during this period often discover that AML/CTF, privacy, operational resilience, scam prevention, and interoperability requirements overlap far more than expected once implementation begins.

Rather than assessing each regulation independently, it is often more practical to map business processes against the complete regulatory timeline before software architecture is finalised. That allows compliance requirements to be incorporated into one implementation programme instead of multiple retrofit projects over the following year.

If your organisation is planning software that will operate under any of these frameworks, Pixbit can help scope the technical implications during an initial discovery session, identifying where regulatory obligations intersect with system architecture, integrations, workflows, and long-term operational governance before development begins.

---