In every cross-functional fraud prevention meeting, the same questions arise. A fraud analyst identifies a pattern, AML wants to alert partners, legal says no, compliance cites GDPR, and engineering wonders what they're allowed to log. The line is unclear, and fraudsters keep moving.
The Canadian Anti-Scam Coalition has highlighted the same tension: real-time data sharing could stop scams before they escalate, but privacy regulations and sector-specific rules create friction at every handoff. Here's what compliance and fraud teams are actually asking when they try to build cross-organizational defenses.
Can We Share PII with Other Banks to Stop a Scam in Progress?
Short answer: it depends on your jurisdiction and what "sharing" means.
In most regulatory frameworks, you can't freely exchange customer PII with competitors without explicit consent or a legal basis. However, many jurisdictions allow limited information sharing for legitimate fraud prevention purposes, provided you anonymize or pseudonymize data where possible.
For instance, sharing a hashed phone number or a device fingerprint doesn't require the same controls as sharing a full name and address. If you're building a consortium fraud model, focus on derived signals like velocity flags, risk scores, and behavioral indicators rather than raw PII. Document your legal basis under your privacy framework, whether that's GDPR Article 6(1)(f) for legitimate interests or an equivalent provision in your jurisdiction.
The real constraint isn't always privacy law itself. It's often sector-specific regulations that limit what banks, telecoms, or payment processors can disclose to each other. A bank might share certain fraud indicators under Bank Secrecy Act safe harbor provisions, but a telecom has no equivalent protection. This asymmetry creates "choke points" when organizations try to coordinate in real time.
What Can We Share with Telecoms or Social Media Platforms?
This gets complex because you're crossing regulatory regimes.
Banks operate under BSA, FATF Recommendations, and AML obligations that encourage information sharing within financial services. Telecoms operate under communications privacy laws. Tech platforms vary by jurisdiction and whether they're classified as payment facilitators.
You can share non-PII threat intelligence freely: attack patterns, malware hashes, phishing domain lists, known scam scripts. These don't trigger privacy concerns and are genuinely useful. If a telecom sees SMS phishing campaigns using the same language your customers reported, that's actionable even without customer identifiers.
For PII-linked intelligence, you need a framework agreement defining what gets shared, under what legal basis, with what retention limits, and who can access it. The Canadian Anti-Scam Coalition model involves law enforcement and regulators, providing legal cover that purely private-sector arrangements don't have. If you're building something similar, involve your legal and compliance teams from day one.
How Do We Handle AI-Scraped Social Media Data in Fraud Detection?
This is the new frontier, and it's why old privacy frameworks feel inadequate.
Fraudsters scrape public social media posts to personalize scams, pulling details about jobs, vacations, and family to craft convincing pretexts. That data is technically public, but using it at scale for fraud profiling creates privacy risks your customers didn't anticipate.
From a compliance perspective, distinguish between defensive and offensive use. Monitoring for your own customers' data appearing in fraud forums is defensible. Proactively scraping social media to build fraud profiles on non-customers is murkier.
The practical approach: focus on known-bad indicators. If a phone number or email appears in confirmed scam campaigns, flagging that in your onboarding or transaction monitoring is justified. Inferring fraud risk from someone's LinkedIn posts is likely overstepping.
What Regulatory Changes Would Actually Help?
Privacy law isn't the main blocker. The problem is the lack of safe harbor provisions for cross-sector sharing.
Financial institutions have some protection under BSA Section 314(b) in the US, allowing sharing of Suspicious Activity Reports and fraud data among institutions. Telecoms and tech platforms have no equivalent. A bank can share certain fraud indicators with another bank, but sharing the same data with a telecom that could block the scam phone call exposes both parties to regulatory risk.
What would help: sector-specific carve-outs allowing real-time fraud intelligence sharing across banks, telecoms, and payment platforms for documented fraud prevention purposes. The framework would need to define what qualifies, what data elements are permissible, and what governance is required.
Some jurisdictions are moving this direction. The UK's Economic Crime and Corporate Transparency Act creates new information-sharing gateways. Canada's coalition model brings regulators into the process, providing implicit regulatory cover. But most compliance teams still operate in a gray zone where the safest answer is "no," even when "yes" would stop real fraud.
Should We Wait for Regulatory Clarity or Build Now?
Build now, but with constraints.
Start with anonymized threat intelligence: attack patterns, indicators of compromise, known-bad phone numbers and domains. None of that requires regulatory reform, and it's immediately useful.
For PII-linked sharing, start small with bilateral agreements that have clear legal review. If you're a payment processor working with a specific bank, define exactly what fraud signals you'll exchange, document your legal basis, and build audit trails. Don't try to solve the entire ecosystem on day one.
The real risk isn't regulatory action against good-faith fraud prevention efforts. It's building systems that can't adapt when the rules change. If you hardcode assumptions about what you can share, you'll have to rebuild when safe harbor provisions expand. Design for flexible data governance so you can adjust policies without rewriting code.
Where Does This Leave Fraud Prevention Teams?
In a frustrating middle ground.
You know that real-time data sharing across banks, telecoms, and platforms would stop scams that currently succeed. Privacy regulations and sector-specific rules create friction at every step. Fraudsters don't have these constraints. They share data freely, use AI to scrape and personalize at scale, and move faster than your legal review process.
The practical path forward is to push on two fronts simultaneously. Technically, build systems that can ingest and act on external threat intelligence without requiring PII exchange. Politically, work with your industry associations and regulators to create safe harbor frameworks that allow real-time fraud intelligence sharing across sectors.
The Canadian Anti-Scam Coalition model, bringing together banks, telecoms, payment providers, law enforcement, and regulators, is one template. It won't solve everything, but it creates a structure where cross-sector sharing has regulatory visibility and implicit approval. That's better than the current state, where every fraud analyst knows what should happen but compliance says it can't.
Where to Go for More
If you're building cross-organizational fraud defenses, start with your industry association. Most major banking and payments groups have working groups on fraud intelligence sharing. The Financial Services Information Sharing and Analysis Center (FS-ISAC) provides a model for threat intelligence exchange that stays within legal bounds.
For the privacy and regulatory framework, involve your DPO or chief privacy officer early. The question isn't whether you can share fraud data. It's what data, with whom, under what legal basis, and with what controls. That's a compliance design problem, not a binary yes/no.
And if you're waiting for perfect regulatory clarity before you act, you'll be waiting while the fraud losses compound. Build what you can build now, document your legal basis, and design for flexibility when the rules catch up.
