Australia's Scams Prevention Framework (SPF) didn't introduce new ideas about what good scam prevention looks like. Security practitioners have known for years what's needed: proactive detection, fast disruption, structured reporting, cross-sector coordination. What SPF did is make those ideas legally mandatory — and in doing so, it exposed exactly how far the industry has to travel to actually deliver on them.
This is a breakdown of what changes in practice, sector by sector, and where the implementation gaps are most severe.
The Before State: What Passed for Scam Prevention
To understand what SPF changes, you need to be honest about what existed before it.
Banking: Transaction monitoring designed to catch fraudulent transfers, not the social engineering upstream of them. By the time a bank's system flags a suspicious payment, the scam has already succeeded psychologically. The financial loss is the trailing indicator.
Telecommunications: Caller ID and some blocklist-based call filtering. Effective against known scam numbers. Useless against campaigns that rotate through fresh numbers daily. No structural visibility into coordinated vishing operations.
Digital platforms: Trust and safety teams operating on report-and-review cycles. A fake account impersonating a bank stays live until enough people report it. "Enough people" in practice often means "after victims have already been contacted."
Government portals: Intake systems for consumer reports. High volume, low action rate. The reports go in; the intelligence rarely comes back out in a form that any single regulated entity can act on in time to matter.
None of these are failures of intent. They're failures of architecture. Every sector built tooling for its own channel and its own threat model. Scam campaigns are multi-channel by design specifically because that's where the gaps are.
What SPF Actually Changes: The Five Obligations in Operational Terms
Prevent
Pre-SPF: Prevention meant awareness campaigns. "Don't click suspicious links."
Post-SPF: Prevention means demonstrable systems. Regulated entities must show they have proactive controls in place — not after-the-fact education, but technical and operational capability that blocks scam activity before it reaches consumers.
In practice: this pushes banks to monitor for scam-pattern onboarding, pushes telcos to deploy more sophisticated call analytics, pushes platforms to proactively scan for impersonation infrastructure rather than waiting for reports.
Detect
Pre-SPF: Detection happened mostly at the transaction level or after consumer complaint.
Post-SPF: Detection must be ongoing, across the full surface area of the regulated entity's operations.
In practice: this is where most operators face the biggest internal gap. Detection at depth requires signal processing infrastructure that many regulated entities simply haven't built. Real-time monitoring of domain registration patterns, certificate issuance, social account creation, and phone number behaviour is a different capability class from transaction fraud detection.
Report
Pre-SPF: Reporting was voluntary, ad hoc, and largely one-directional (consumer to regulator).
Post-SPF: Reporting obligations run in multiple directions — to regulators, and to other designated entities. The framework is trying to create cross-sector intelligence sharing at speed.
In practice: the infrastructure for this is still being built. The willingness to share threat intelligence between a bank, a telco, and a platform — entities that are sometimes competitors — requires both technical interoperability and trust frameworks that don't exist at scale yet.
Disrupt
This is the hardest one. And the most important one.
Pre-SPF: Disruption was optional, slow, and usually reactive. File a report with a domain registrar. Wait. File again. Eventually the domain might come down — days or weeks after the campaign has already cycled on.
Post-SPF: Disruption is an obligation. Entities must have the capacity to act against scam infrastructure — not just document it.
In practice: this is where the largest tooling gap sits. Taking down a scam domain quickly requires relationships with registrars, hosting providers, and certificate authorities. Taking down a spoofed phone number requires coordination with the originating carrier. Taking down a fake social account requires platform-specific escalation paths. Doing all of this simultaneously, at speed, across a multi-channel campaign — that's an operational capability very few organisations have built internally.
Respond
Pre-SPF: Consumer response was discretionary. Banks might offer ex gratia payments. Platforms might restore suspended accounts. There was no baseline obligation.
Post-SPF: Response obligations are structured. Dispute resolution pathways are required. Consumer harm must be taken seriously as an operational outcome, not just a reputational risk.
Where Each Sector Is Underbuilt
| Sector | Biggest SPF Gap | Root Cause |
|---|---|---|
| Banking | Disruption capability | Built for transaction fraud, not infrastructure fraud |
| Telecommunications | Coordinated vishing detection | Channel-level visibility only |
| Digital platforms | Proactive impersonation monitoring | Reactive report-and-review architecture |
| All sectors | Cross-sector intelligence sharing | No existing trust or technical framework |
What the Industry Response Has Looked Like
The market response to SPF has been uneven.
Some vendors have repositioned existing compliance dashboards as "SPF-aligned." If the dashboard generates reports and shows activity logs, it satisfies the letter of some reporting obligations. It does not deliver disruption capability.
Some enterprise security vendors have added scam-specific modules to existing fraud detection platforms. This tends to improve detection coverage incrementally. The disruption gap usually remains — because disruption requires external relationships and takedown workflows that fraud detection platforms weren't built to manage.
A smaller set of platforms approached the problem from the operational question the SPF's disrupt principle actually poses: how fast can you take down scam infrastructure across multiple channels simultaneously? Cyberoo's NothingPhishy platform, for instance, is built around external threat disruption — multi-channel takedown of scam websites, scam phone numbers, and social impersonation accounts — rather than detection dashboards. The product design reflects a view that Fast Takedown speed is the real performance benchmark for SPF compliance, not just coverage breadth.
The contrast between these approaches is not subtle in practice. A detection dashboard that takes three weeks to surface an actionable takedown request is architecturally incompatible with what "disrupt" means under SPF. The framework has a time dimension. The tooling has to match it.
The Cross-Sector Coordination Problem Is Unsolved
The most structurally difficult part of SPF implementation isn't any individual obligation. It's the cross-sector reporting and coordination requirement.
Scam campaigns work because they exploit the seams between sectors. The initial contact happens via text (telco). The credential theft happens via a fake website (digital platform). The fraudulent transaction happens via banking. Each sector sees one piece of the campaign. None sees the whole.
SPF's reporting obligations are designed to change this by creating structured intelligence sharing between designated entities. In theory: a telco detecting a new scam number pattern shares that signal with banks, who share it with platforms, who can proactively remove the associated fake accounts.
In practice: this requires the signal to be structured enough to be actionable when it arrives. Unstructured reports — "we think this number is suspicious" — don't propagate usefully through a coordinated intelligence system. Structured signals — "this number is associated with this domain cluster, registered on this date, using this infrastructure pattern" — do.
This is why verification quality upstream matters. Tools that help consumers and businesses submit evidence-structured scam reports — with enriched metadata rather than just screenshots and descriptions — improve the collective intelligence flowing through SPF's reporting infrastructure.
The Liability Shift Is the Real Change
Technical architecture aside, the most consequential thing SPF changes is where the liability sits.
Pre-SPF: scam harm landed almost entirely on victims. Banks might offer discretionary refunds. Platforms might remove content eventually. There was no legal baseline.
Post-SPF: regulated entities that fail to implement adequate prevent, detect, report, disrupt and respond systems face regulatory exposure. The ACCC has enforcement powers. The External Dispute Resolution pathways create escalation routes for consumers.
This shifts the incentive structure. Compliance is now the floor, not the ceiling. Entities that treat the five obligations as checkbox exercises will find that the framework's dispute resolution and enforcement mechanisms create continued exposure. Entities that treat them as operational engineering problems — and build the tooling to match — reduce both regulatory risk and actual scam harm.
Those are different strategic postures. And they produce meaningfully different outcomes for the people the framework is designed to protect.
The Practical Engineering Takeaway
If you're building or evaluating systems that need to operate under SPF, the questions worth asking are:
On detect: Is your detection real-time or batch? Does it cover external infrastructure (domains, phone numbers, social accounts) or only internal transaction data?
On disrupt: What is your actual takedown workflow? How many manual steps does it involve? What's your average detection-to-disruption time on a fake domain?
On report: What format do your outgoing intelligence signals take? Can they be consumed by a bank, a telco, and a platform without human translation?
On prevent: Can you demonstrate proactive controls, or do you have retrospective documentation that controls exist?
The SPF doesn't specify exact technical implementations. It specifies outcomes. The engineering question is how to build systems that reliably achieve those outcomes — at the speed the framework's intent actually requires.
Top comments (0)