Imagine you're in a fraud operations meeting when someone suggests, "What if we could see when the same synthetic identity opens accounts at three other banks in the same week?" The room goes silent. Everyone knows that kind of visibility could stop fraud rings before they drain accounts, but the legal team would likely shut it down immediately.
These questions are common in fraud prevention and compliance because the gap between effective strategies and legal allowances feels vast. Below are the questions we hear most often, with practical answers that won't get you fired.
Why Are These Questions Arising?
Fraud teams at banks and fintechs face organized criminal operations that recruit money mules through social media, use synthetic identities across multiple institutions, and coordinate at scale. The fraud is collaborative, but your defenses aren't.
Privacy-enhancing technologies (PETs) are seen as a bridge. They promise to let you share fraud intelligence across institutions while keeping personal data protected through pseudonymized or tokenized identifiers. However, implementing these technologies presents challenges, and most guidance overlooks the practical obstacles you'll encounter.
What Are Privacy-Enhancing Technologies in This Context?
PETs aren't a single product. They include techniques that let you analyze or compare data without exposing personal information.
For fraud detection, consider:
- Tokenization or pseudonymization: Replaces identifiers (account numbers, SSNs, email addresses) with consistent but non-reversible tokens. Consistency is key: the same real-world identity produces the same token across participating institutions, allowing pattern detection without revealing actual PII.
- Secure multi-party computation (SMPC): Allows multiple parties to compute a function (like "does this identity appear at more than two institutions?") without any party seeing the others' raw data.
- Homomorphic encryption: Enables computation on encrypted data without decrypting it first.
Most fraud use cases start with tokenization because it's the most operationally feasible. SMPC and homomorphic approaches are powerful but require more infrastructure and coordination.
How Do We Handle Different Identifiers Across Institutions?
This is a major hurdle. Bank A might use email addresses, Bank B uses phone numbers, and Bank C prioritizes device fingerprints.
You need a common schema before tokenizing anything. The consortium must agree on:
- Which data elements to share (email, phone, device ID, IP address, account opening date range)
- How to normalize them (lowercase emails, strip phone formatting)
- The token generation algorithm
- Who operates the tokenization service (neutral third party, rotating lead institution, or vendor)
Tokenization must be deterministic across institutions. If Bank A's token for [email protected] differs from Bank B's, the system can't detect anything.
Most implementations use a trusted third-party service that tokenizes inputs from all participants using the same key material, then returns the tokens for local analysis. No institution sees another's raw data, and the third party doesn't store the mapping.
Can We Use Dark Web Intelligence Without Violating Data Protection Laws?
Yes, but you must be precise about your actions.
Dark web threat intelligence involves scanning forums, chat channels, and data dumps where stolen credentials and fraud tools are traded. This intelligence can identify connections between bad actors, reveal new fraud techniques, and surface compromised credentials before they're used against you.
The legal concern is whether finding your customers' stolen credentials on the dark web constitutes processing personal data in a new context requiring notification or consent.
The practical approach:
- Alerting customers: If you find credentials tied to your customer base, notify affected customers as part of your fraud prevention obligations. Document this as part of your incident response and fraud prevention program.
- Intelligence analysis: Aggregated intelligence about fraud techniques, criminal infrastructure, and attack patterns doesn't implicate individual customer data. Integrate this into your risk models and detection rules without additional consent.
- Cross-institution sharing: If using PETs to share tokenized indicators, dark web intelligence becomes another input. You're not sharing "John Doe's email appeared on a dark web forum." You're sharing "token XYZ7 matches known compromised credentials," and only institutions that can independently generate XYZ7 from their own data can act on it.
What's the Legal Basis for Sharing Tokenized Fraud Data Across Institutions?
You need a legitimate interest or contractual basis, depending on your jurisdiction.
Under GDPR, fraud prevention is recognized as a legitimate interest (Article 6(1)(f)), but you must demonstrate proportionality and necessity. Tokenization helps because it minimizes the data shared to what's necessary for fraud detection.
In the US, you're working within the framework of the Bank Secrecy Act (BSA) and your institution's fraud prevention obligations. Sharing information to detect money laundering or fraud is generally permissible, but document:
- The specific fraud risk you're addressing (synthetic identity fraud, mule account networks)
- Why cross-institution data is necessary to detect it
- How tokenization protects customer privacy
- What governance controls the consortium
Your legal team will want a data sharing agreement specifying access, purposes, retention limits, and security controls.
How Do We Detect Synthetic Identities or Mule Networks Once We Have Shared Tokens?
The detection logic depends on your use case.
- Synthetic identity detection: Look for the same tokenized identity opening multiple accounts across institutions within a short timeframe. If token ABC123 appears at three banks within two weeks, investigate further. Legitimate consumers might open accounts at multiple institutions, but velocity and account behavior (immediate cash-out attempts, unusual transaction patterns) indicate fraud.
- Mule account detection: Track tokenized identifiers associated with known mule behavior at one institution and check if they appear elsewhere. Since organized criminal rings recruit money mules through social media and manage them using "mule-herders," the same individual often opens accounts at multiple institutions. Shared intelligence lets you spot the network before each institution independently discovers pieces of it.
The key is identifying patterns, not individuals. When a pattern triggers an alert, each institution investigates using its own customer data and files Suspicious Activity Reports (SARs) as warranted.
What Happens When a Tokenized Alert Fires? How Do We Investigate Without De-Anonymizing?
Each institution investigates independently using its own customer records.
The consortium system sends an alert: "Token XYZ7 appears at three institutions with mule-like behavior." Your fraud team checks your internal systems to see if XYZ7 corresponds to any of your accounts and reviews that account's activity using your normal investigation procedures.
You're not asking the consortium to tell you who the customer is. You already know your own customers. The consortium just told you which of your tokens is worth a closer look.
If your investigation confirms suspicious activity, you file a SAR through your normal BSA compliance process. The SAR includes the actual customer details (which you have) and the investigative findings (which you developed). Other institutions do the same independently. Law enforcement can then connect the SARs and see the full network.
How Do We Get Started Without Building a Whole Consortium from Scratch?
Start with bilateral data sharing between two institutions that already have a relationship, or join an existing industry consortium if one operates in your market segment.
For bilateral sharing:
- Define one specific fraud pattern you both want to detect (e.g., account takeover attempts using compromised credentials).
- Agree on which data elements you'll tokenize (email, phone, device ID).
- Select a tokenization vendor or build a shared tokenization service.
- Draft a data sharing agreement covering purpose, retention, security, and governance.
- Run a pilot with a limited dataset before scaling.
For consortium participation, look for initiatives led by industry groups, payments networks, or regional banking associations. These often provide the legal framework, tokenization infrastructure, and governance model, so you're not starting from zero.
Where to Go for More
If you're building a business case, focus on the fraud patterns your institution can't currently detect in isolation. Quantify the loss exposure from synthetic identity fraud and mule networks based on your SAR filings and fraud write-offs.
For technical implementation, work with your data privacy officer and information security team early. The tokenization architecture needs to satisfy both fraud detection requirements and data protection controls.
The Wolfsberg Principles provide guidance on information sharing for AML and fraud prevention purposes. Your legal team should review these as part of the framework for any consortium participation.
Fraud is already collaborative. Your defenses need to be, too. PETs offer a way to close the intelligence gap without handing over customer data. The question isn't whether to share fraud intelligence, but how to do it within the rules you're required to follow.
