Regtech doesn’t solve compliance because technology doesn’t determine whether compliance is performed correctly. The system in which that technology operates does. ASIC has encouraged the use of Regtech and recognised its potential, but it doesn’t require licensees to have specific tools; it does however expect outcomes, effective systems, consistent application of controls, and defensible evidence.
Slow journeys on uneven paths
Despite regulatory expectations, Regtech adoption remains limited and uneven.
The uncomfortable reality is that too many organisations rely on a mix of manual processes and partial tooling, rather than fully integrated platforms. We shouldn’t be surprised, regulatory studies confirm adoption is typically gradual and non-uniform, with firms implementing solutions in stages rather than as integrated systems
Australian industry press and regulatory initiatives continue to focus on the accelerating uptake rather than celebrating mature, embedded solutions. Government and ASIC programs support pilots and encourage adoption, and the industry responds with forward-looking language. Regtech is described as becoming increasingly important, with an increasing focus driven by regulatory pressure and cost, rather than as an established standard operating model.
Where Regtech is introduced, it’s typically incremental rather than transformative. Many platforms promise automation, efficiency, and better visibility, with the expectation that outcomes will improve as capability increases. Few deliver.
In practice, outcomes still vary because underlying processes and controls are not consistently defined or applied.
Regtech isn’t new. Regulators have been promoting its potential for nearly a decade. ASIC engaged the industry on its use as early as 2017, while identifying barriers and constraints to adoption.
Since then, investment has increased and capability has improved. The Thomson Reuters Cost of Compliance Report (2023) noted continued growth in spending on compliance technology and Regtech solutions across financial services institutions.
But the underlying problem has not changed.
Breaches are handled differently depending on who assesses them. One team classifies an issue as significant, another treats a similar issue as minor. Records exist, but they don’t explain the reasoning behind the decision. When reviewed, the organisation cannot demonstrate consistency or justify its position. Reporting still struggles to withstand scrutiny.
The issue is not the presence of tools. It’s the absence of a system that produces consistent, defensible outcomes.
This isn’t a new problem. ASIC has been identifying the same patterns for years. In Report 515, it found that although large licensees had compliance frameworks in place, they weren’t operating effectively in practice. Outcomes were inconsistent, documentation was inadequate, and oversight was weak.
Since then, investment in technology has increased, but the underlying issue hasn’t changed. Breaches are still handled inconsistently. Evidence still fails under review. Reporting still struggles to withstand scrutiny.
This is the same structural issue outlined in You Don’t Need More Tools You Need Infrastructure and reinforced in the broader compliance infrastructure argument. While Licensees can add capability, the underlying design of how their compliance actually works often remains undefined or inconsistent.
The Misunderstanding at the Centre
Regtech improves efficiency. Compliance depends on consistency, control, and evidence.
Those are fundamentally different things.
A tool can automate and enforce a defined process, but it cannot determine whether that process is complete, appropriate, or consistently applied. It can capture data, but it can’t ensure that the right data is captured at the right point in a decision. It can generate reports, but it can’t guarantee that those reports reflect consistent or defensible outcomes.
If the underlying process varies between users, the technology will replicate that variation at scale.
Design isn’t the only possible failure point. Implementation quality, vendor configuration, and data integrity can independently degrade compliance outcomes. However, design remains the controlling variable. Where workflows, controls, and decision logic are clearly defined, these issues become visible, testable, and correctable. Where they are not, those same issues are amplified and obscured.
If controls are informal or inconsistently applied, the system won’t correct it. It will simply make the inconsistency harder to detect until it matters.
Failure patterns
In practice, the failure pattern is consistent, but it’s often described too superficially.
At the surface level, organisations see inconsistent outcomes. Similar breaches are classified differently across teams.
Beneath that, the issue is decision ambiguity. Thresholds for materiality, significance, or reportability are not clearly defined, so outcomes depend on individual judgment.
At a system level, this reflects an absence of enforceable workflow and control logic. Decision points are not structured, controls are not embedded, and required steps can be skipped or applied inconsistently.
From a regulatory perspective, this creates a more serious problem: the organisation cannot demonstrate that it has adequate arrangements to ensure compliance, as required under s912A(1)(a)–(c).
What appears to be an inconsistency is, in reality, most often a failure of system design.
What Actually Drives Compliance Outcomes
Effective compliance is the result of infrastructure. Not in theory, but in how work is performed.
Three elements determine whether outcomes are consistent and defensible.
Workflows must be defined. Key obligations need to be translated into clear processes with explicit decision points so that similar scenarios are handled consistently.
Controls must be embedded. They need to be triggered within workflows and enforced by design so that required steps cannot be skipped or applied inconsistently.
Governance and evidence must be structured. Decisions need to be recorded with their reasoning, reviewed, and attributable to specific roles.
When these elements exist, compliance becomes repeatable. Outcomes stabilise, and evidence becomes defensible.
Only then does Regtech deliver its intended value. It scales a system that already works.
The objective is not to introduce more tooling. It’s to operationalise compliance so it’s executed consistently and withstands regulatory scrutiny.
What Regulators Assess in Practice
It’s worth repeating; regulators don’t focus on whether technology is in place but on whether outcomes are predictable and defensible.
This is the critical distinction. Regulators do not require specific tools. They expect outcomes. If those outcomes are inconsistent or indefensible, the presence of technology is irrelevant.
That expectation translates into a small number of practical tests. The same scenario should lead to the same outcome. When similar breaches are classified differently, it becomes clear that the process is not defined or enforced.
Decisions should follow a defined and repeatable path. Controls should be embedded within the workflow, not dependent on individuals remembering to apply them. Evidence should explain not just what happened, but why it happened. Oversight should be visible and documented.
These are not technology features. They are properties of a well-designed compliance infrastructure.
When those properties are absent, the symptoms are predictable. Similar issues are handled differently across teams. Records exist, but they don’t explain decisions. Monitoring identifies problems late, and responses vary. Reporting is produced, but it can’t be traced back to consistent underlying activity.
None of these failures is solved by adding another platform.
Where Regtech Breaks Down
Regtech doesn’t fail randomly. It fails in predictable ways when applied to environments with the failure pattern described above.
Where decision thresholds are undefined, systems cannot enforce consistency. They capture variation rather than eliminate it, resulting in inconsistent breach classification and reporting that cannot withstand regulatory scrutiny, including expectations reflected in RG 78.
Where workflows are incomplete, controls sit outside the system and depend on user behaviour rather than design, preventing the organisation from demonstrating that it has adequate arrangements to manage compliance risk under s912A(1)(a)–(c).
Where evidence requirements are not specified at each decision point, systems produce records without justification, which fail to meet the defensible-evidence standard required during ASIC surveillance or audit.
When multiple tools operate independently, these issues compound, resulting in duplicated data, fragmented processes, and reduced visibility, undermining oversight and making it difficult to evidence effective supervision and control.
In this context, technology does not resolve the problem. It scales it. What appears to be increased capability often results in reduced control, because the underlying system remains undefined or inconsistently applied.
A Simple Diagnostic
Most environments fall into one of three categories.
In tool-driven environments, systems exist, but decision-making processes vary, leading to inconsistent outcomes.
In supported environments, some structure exists, but inconsistencies remain, particularly in how borderline cases are assessed and documented.
In integrated environments, workflows, controls, and governance operate as a single system. Technology enforces the process. Outcomes are consistent, repeatable, and defensible.
The distinction is not the maturity of tooling. It’s the maturity of design.
The Sequence That Determines Success
Unfortunately, the failure pattern is consistent when organisations start with technology.
They should, instead, start with design.
Compliance needs to be defined in operational terms. How decisions are made. Where controls apply. What evidence is required. Who is accountable. Once that structure exists, technology can support it and extend it.
If that structure doesn’t exist, technology optimises inconsistency.
Final Position
Regtech isn’t the answer to compliance.
It’s a multiplier.
Where controls are weak or the design is inconsistent, Regtech will scale decisions that can’t be defended.
If the underlying system is inconsistent, it will scale with inconsistency.
If the evidence is incomplete, it will widen the gaps.
These are not isolated issues. They are the observable symptoms of the underlying failure pattern described above.
But when compliance infrastructure is properly designed, Regtech becomes effective. It enables efficiency without compromising control. It supports consistency rather than undermining it.
The relevant question is not whether the right tools are in place. It’s whether the system produces the same defensible outcome every time.
Until that’s true, adding more technology won’t solve the problem.
What To Do Next
If your compliance outcomes are inconsistent, the issue isn’t your tooling. It’s how your compliance actually operates.
Start by examining how decisions are made in practice. Where does variation occur? Where are controls dependent on individuals rather than embedded in the process? Where is the evidence incomplete or disconnected from the underlying decision?
If you can’t clearly answer those questions, you don’t have a tooling problem. You have a design problem.
[complye] is built to address that gap. It doesn’t add another layer of technology. It structures how compliance is executed, so workflows, controls, and evidence operate as a single system.
If you’re serious about moving from inconsistent outcomes to defensible compliance, start with a structured review of how your environment actually works today.
If you enjoyed this, we recommend that you read:
- Why AFSL Licensees Are Adopting Compliance Infrastructure
- What Compliance Infrastructure Do You Actually Need
- How to Design a Compliance Monitoring Program That Works
Frequently asked questions
Regtech refers to technology used to support compliance activities such as monitoring, reporting, and record-keeping. It improves efficiency, but it doesn’t define how compliance should operate.
Because compliance depends on consistent processes, embedded controls, and defensible evidence. Technology can support these, but it can’t create them where they don’t exist.
No. ASIC is technology neutral. It encourages innovation and recognises the potential of Regtech, but it doesn’t require specific tools. It expects outcomes: effective systems, consistent control application, and defensible evidence.
Inconsistent decisions, incomplete evidence, fragmented processes, and failure under regulatory scrutiny. Technology can scale these issues if the underlying system is weak.
As part of a defined compliance infrastructure. Workflows, controls, and governance need to be designed first. Regtech should then be applied to support and scale that structure.
