Overview
Part 1 of this series covered what Australia's Scams Prevention Framework (SPF) means for banks: who is regulated, what the "reasonable steps" legal standards require, and when they take effect.
Next, we move from what the framework asks to how banks decide where to start. The SPF doesn't answer that question for you.
There is no prescribed list, no approved technology stack, and no channel the regulator will tell you to prioritize. That leaves each bank to decide for itself, which sounds like freedom until you're the one deciding.
The way through is a triage model. Map the customer journeys scammers exploit, find the channels where your customers are most at risk, and decide which threats to address first.
Key takeaways from the Scams Prevention Framework
Australia's Scams Prevention Framework leaves "reasonable steps" deliberately undefined. Regulators will judge you against what a well-resourced bank in your position could have done.
Two banks can take completely different actions and both be compliant, or both fall short. What separates them is whether their priorities match the scams their own customers face.
The scams that reach your customers mostly happen where you can't see them, so exposure can't be measured from transaction data alone.
Speed is the whole game. Under the SPF, a scam you've detected but haven't taken down still counts against you.
Start with customer exposure
No bank can address every risk at once, so the SPF lets banks decide where to focus, as long as those choices are evidence-based and reduce customer harm. That decision is easier to make well when you start from the customer rather than the tooling.
Three questions are a useful way in:
Which scam types generate the greatest losses?
Which customer groups are targeted most often?
Which channels are those scams using?
The answers differ for every institution, which is exactly why the SPF avoids a universal checklist. What a bank prioritizes should follow from who it serves.
Customer segment | Common scam types |
|---|---|
Older retail banking customers | Investment scams, romance scams, invoice fraud, tech support scams |
Younger, digital-first neobank customers | Money mule recruitment, fake ticket/marketplace scams, instant payment fraud |
Small business banking customers | Invoice fraud, business email compromise (BEC), vendor impersonation |
High-net-worth/wealth management customers | Investment scams, impersonation of advisors or executives |
A bank serving older customers will likely prioritize investment scams and impersonation fraud, while a digital-first institution sees more marketplace scams and money mule recruitment.
Neither is more compliant than the other. What matters is whether priorities reflect the risks each bank's own customers face.
Look beyond transaction data
Banks have a detailed view of what happens inside their own environment. Customers don't.
They move between search engines, paid search advertising, social media, online marketplaces, messaging apps, SMS, phone calls, and lookalike websites. Every one of those touchpoints is a chance for deception before a fraudulent transaction ever reaches your organization.
So internal data alone can't answer the broader question the SPF poses: Where are customers being targeted?
Answering it takes visibility across the channels scammers use. Solutions like Netcraft Domain Protection monitor those channels, from domains and social media to search, SMS, phone infrastructure, and app stores, while actionable scam intelligence shows how attacks move between them.
Together they give fraud teams the context to see where scams originate and where disruption will do the most good.
Build brand protection into your SPF response
Much of what the SPF asks for comes down to one capability: Protecting your brand across the channels criminals use to impersonate you.
Fake domains, cloned apps, spoofed profiles, and fraudulent ads all trade on customer trust in your name, and all of them sit outside your own systems.
That is why brand protection belongs at the center of an SPF program rather than off to the side. Brand protection for financial services brings detection and takedown together across the external channels where scams begin, giving banks a single way to see impersonation as it emerges and disrupt it before more customers are exposed.
It's the practical expression of prevent, detect, and disrupt working as one.
Detection needs to lead to disruption
The SPF recognizes that detection alone doesn't protect customers and treats disruption as a separate obligation.
Detection tells you a phishing domain, fake social profile, or spoofed number exists. Disruption is what takes it down. Under the framework, spotting a scam only counts if it leads to taking it down before more customers are hit.
The difficulty is volume. A single campaign can throw up hundreds of phishing domains, cloned apps, and fraudulent ads within days. Reviewing each one by hand takes time attackers are happy to use, so detections pile up while the scams they describe stay live. Automation is the only realistic way to keep pace.
This is where "reasonable steps" stops being abstract.
The SPF doesn't tell banks which scam protection software to use, but it does hold them to what current technology can deliver. Today, phishing URLs can be removed in as little as 33 minutes, and Netcraft has achieved a 99.8% takedown success rate across more than 50,000 takedowns.
Once that kind of speed is available, a manual process that leaves scams live for days becomes hard to defend as reasonable.
That's the shift the SPF is really asking banks to make. Scams now move faster than manual review can follow, which makes automated threat detection and takedown less of an upgrade than a requirement for keeping customers safe.
Prioritization should be easy to explain
Deciding where to act is one obligation. Being able to explain that decision is another, and the SPF weighs both.
Prioritization decisions have to be defensible. Your governance arrangements should be able to answer questions like:
Which scam types create the greatest customer harm?
Which channels present the highest exposure?
Which risks have already been reduced?
Which priorities have changed since the last review, and why?
The framework expects evidence: what a bank knew, what it did, and how fast it acted.
That record can't be rebuilt after the fact. It has to come out of everyday fraud operations as scams are detected and disrupted, not pieced together later from memory and screenshots.
The most effective digital risk protection programs set up reporting and dashboards from the very beginning to answer the reasonable steps question on their own.
Prioritization may need to stand up to independent review
The SPF introduces another layer of accountability. Customers who aren't satisfied with a bank's internal dispute resolution mechanism can ask the Australian Financial Complaints Authority (AFCA) to independently review their complaint through the country’s external dispute resolution scheme.
Every channel a bank hasn't prioritized is now a potential claim, which turns "where is our exposure worst" from a compliance question into a financial one. Showing how priorities were set and reviewed is how a bank defends those decisions when they're tested.
The draft sector-specific codes will offer more guidance on demonstrating compliance in regulated sectors, but they won't remove the need for judgment.
Treating this as a yearly statement of compliance misses the point: governance policies and priorities should adapt as customer behavior, scam tactics, and attack channels change.
Getting ahead of the March 2027 deadline
The obligation is live and the codes are being finalized. The scams the framework targets are already reaching customers, and they won't wait for anyone's implementation timeline.
Banks that begin now will have a defensible, tested program by the time the obligations take full effect. The ones that wait will have a very expensive calendar problem.
Reasonable steps start with knowing where your exposure is. Request a scam exposure assessment to identify and prioritize your customer risk across domains, search, social media, app stores, SMS, and phone infrastructure.
