When a regulatory framework assigns penalties to your institution but leaves the platforms where scams originate unregulated, you're not just managing compliance risk. You're absorbing liability for a chain of events you can't see or control.
Australia's Scams Prevention Framework, effective March 2027, highlights this issue. Banks and telecoms face penalties up to $52.7 million per contravention, while dating apps, crypto exchanges, and certain digital wallets remain outside the regulated perimeter. The Australian Securities and Investments Commission reported 3,106 crypto investment scams over the past financial year, a 30% increase, yet crypto platforms aren't covered.
This isn't just an Australian problem. It's a global pattern. Regulators often build scam prevention rules around sectors they understand, like banking and telecoms, while excluding digital platforms where scams actually start. This leaves compliance teams with impossible mandates. Here's where teams keep getting caught.
Why These Mistakes Keep Happening
Split-liability frameworks create a mismatch between accountability and visibility. Your institution gets penalized for failing to stop a scam that began on an unregulated platform, moved through an excluded payment rail, and landed at an international receiving bank with no obligation to report anything. You're expected to detect patterns you can't observe and reimburse victims for transactions you didn't facilitate.
Most compliance programs aren't built for this. They assume regulatory scope aligns with operational control. When it doesn't, teams default to familiar practices: tighten transaction monitoring, add friction to high-risk payments, update customer warnings. None of that addresses the core problem: you're being held responsible for risks generated outside your perimeter.
Mistake 1: Treating This as a Transaction Monitoring Problem
Why it happens: Your existing anti-fraud stack monitors your own channels. When scam volumes rise, the instinct is to tune detection rules, lower thresholds, or add behavioral analytics.
The real consequence: You catch more legitimate transactions and still miss the scams. Romance scams don't look suspicious in your data because the trust-building happened on a dating app you can't see. By the time the victim initiates a transfer, they believe they're helping someone they know. Your system sees an authorized payment to a new beneficiary. There's no anomaly to detect.
The specific fix: Map the full scam journey, not just your segment of it. Document where initial contact happens (excluded platforms), where relationship development occurs (messaging apps outside your view), and where funds exit (crypto exchanges, international accounts). Then build detection logic around the handoff points you do control. If a customer suddenly adds a beneficiary in a high-risk jurisdiction after weeks of no contact changes, that's a pattern. If they move funds to a newly-opened account at a non-bank provider immediately after, that's another. You're not detecting the scam itself; you're detecting the moment it enters your infrastructure.
Mistake 2: Assuming Reimbursement Liability is Clear
Why it happens: The framework says regulated entities must reimburse victims. Your legal team reads that as a straightforward obligation and provisions accordingly.
The real consequence: When a scam crosses multiple platforms, reimbursement becomes a negotiation with no clear answer. Fraud expert Ken Palla raised this directly with Australian Treasury: if a scam starts with an email, moves through an excluded non-bank payment provider, and lands at an excluded international receiving bank, who actually pays the victim back? Treasury confirmed verbally that receiving banks would be liable, but the term "receiving bank" doesn't appear in the banking sector's code provisions. Your CFO provisions for 100% liability. The receiving bank provisions for zero. The victim gets stuck in between.
The specific fix: Don't wait for regulatory clarity that may never come. Build bilateral agreements with the payment providers, fintechs, and correspondent banks you work with most frequently. Specify liability allocation for scam scenarios in writing. If they won't sign, that tells you something about their risk posture and your exposure. Document every refusal. When Treasury eventually issues guidance, you'll have a paper trail showing you tried to close the gap.
Mistake 3: Relying on Customer Warnings Alone
Why it happens: Warnings are cheap, measurable, and create an audit trail. You can show regulators that customers were informed.
The real consequence: Warnings don't work against scams that manipulate trust over weeks or months. A victim who believes they're in a relationship will dismiss generic fraud alerts. Worse, scammers now coach victims on how to bypass bank warnings. They'll say, "The bank will try to stop this because they don't understand our situation. Just tell them it's for family." Your warning becomes proof, in the victim's mind, that the scammer predicted exactly what would happen.
The specific fix: Replace static warnings with dynamic interventions that match scam typology. For romance scams, the intervention isn't "Are you sure you want to send this?" It's "You added this beneficiary three days ago, and you're now sending your third payment this week. Scammers build trust quickly, then create urgency. Can you verify this person's identity through a video call before we process this?" Make the intervention specific to the pattern you're seeing. If you can't tailor it, don't deploy it.
Mistake 4: Treating Excluded Platforms as Someone Else's Problem
Why it happens: They're not in the framework, so they're not your compliance responsibility. Your audit scope ends at your own systems.
The real consequence: Scammers don't care about regulatory boundaries. They'll use whatever platform has the weakest controls. Dating apps are excluded, so that's where romance scams concentrate. Crypto exchanges are excluded, so investment scams route through them. You're liable for the outcome, but you have no leverage to push those platforms toward better verification, no data-sharing agreement, and no way to trace funds once they leave your infrastructure.
The specific fix: Build informal intelligence-sharing relationships with the platforms scammers exploit most. You can't compel them to participate, but many will engage if you frame it as mutual benefit. Share typologies, not customer data. "We're seeing an increase in payments to new beneficiaries immediately after customers report contact from your platform" is actionable for them and doesn't breach privacy rules. Some platforms will ignore you. The ones that respond become part of your extended defense perimeter.
Mistake 5: Waiting for Treasury to Publish the Liability Chart
Why it happens: Ken Palla asked Australian Treasury in January to publish detailed guidance showing how liability and recovery work when scams cross from regulated to unregulated entities. It's a reasonable request. Surely Treasury will clarify before March 2027.
The real consequence: It's been eight months. The chart still doesn't exist. Waiting for regulatory clarity is a strategy that assumes regulators have answers they're withholding. Often, they don't. They're waiting to see how the first cases play out, which means your institution might be the test case that establishes precedent.
The specific fix: Build your own liability model. Map every scam scenario you've seen in the past year. For each one, identify which entities touched the transaction, which are regulated under the new framework, and where the funds ultimately went. Then assign provisional liability based on the framework's language, your legal team's interpretation, and your bilateral agreements. You won't get it perfect, but you'll have a working model. When the first dispute arises, you'll have a position to defend instead of scrambling to build one under pressure.
Prevention Checklist
- Map full scam journeys across platforms, not just your transaction segment
- Establish bilateral liability agreements with high-volume payment partners
- Replace generic fraud warnings with scam-specific dynamic interventions
- Build informal intelligence-sharing relationships with excluded platforms
- Create internal liability models for cross-platform scam scenarios
- Document every request for clarity sent to regulators (with dates and responses)
- Review scam typologies quarterly and update detection logic at handoff points
- Provision for 100% reimbursement liability until bilateral agreements are in place
- Train frontline staff to recognize trust-manipulation patterns, not just transaction anomalies
- Escalate unresolved liability questions to executive risk committee with specific scenarios
Split-liability frameworks won't fix themselves. The gaps are features, not bugs, because closing them requires political will to regulate platforms with lobbying power. Your job isn't to wait for that. It's to build defenses that work within the framework you actually have.
