APP fraud is a cross-institution problem. A scammer who successfully extracts funds from a victim at PSP A can immediately target a victim at PSP B using the same campaign infrastructure, the same mule accounts, and the same conversation scripts. The fraud fingerprint is portable. The victims aren't.
The obvious response — share the fingerprint data between PSPs so that an identified scammer at PSP A is flagged before they complete a second operation at PSP B — runs into a genuine UK GDPR compliance challenge. Scammer fingerprint data is personal data. Its subject (the scammer) has data rights. The legal basis for processing and sharing that data requires careful analysis. But the analysis is tractable, and the paths forward are real. This article maps them.
Is Scammer Fingerprint Data Personal Data?
UK GDPR Article 4(1) defines personal data as any information relating to an identified or identifiable natural person. A scammer fingerprint — comprising a phone number, messaging account identifiers, message cadence patterns, linguistic signatures, and associated mule account numbers — almost certainly constitutes personal data. Even where no name is attached, the combination of identifiers is likely sufficient to identify the individual, particularly when combined with other data held by PSPs or law enforcement.
Practitioners sometimes assume that because the data subject is a criminal actor, ordinary data protection rules don't apply. That's incorrect. UK GDPR applies to personal data processing regardless of the data subject's activities. The criminal status of the data subject may affect the proportionality assessment under Article 6(1)(f) (legitimate interests) — it's clearly harder for a scammer to argue that their legitimate interests override the PSP's fraud prevention purpose — but it doesn't remove the requirement to identify a lawful basis.
Special category data is less likely to be implicated in a typical scammer fingerprint unless the data includes health or biometric information. Behavioural and linguistic data that doesn't amount to biometric identification (as defined in Article 4(14) — requiring specific technical processing to uniquely identify a person) generally falls outside Article 9.
The Lawful Basis for Fraud Intelligence Processing
For PSPs processing scammer fingerprint data generated from their own honeybot engagements or fraud operations, Article 6(1)(f) legitimate interests is the most applicable basis. The legitimate interests assessment (LIA) needs to establish:
The purpose is legitimate and clearly defined — in this case, fraud prevention and protection of the PSP's customers and business from APP fraud losses. This is well-established as a legitimate purpose in UK GDPR guidance and in ICO published practice notes on fraud prevention.
Processing is necessary for that purpose — the fingerprint data is directly used to identify fraud attempts targeting the PSP's customers and to flag suspected campaign activity before funds move. If less intrusive means would achieve the same outcome, those must be considered; in most cases there is no less intrusive way to generate a specific scammer fingerprint than from direct engagement data.
The scammer's interests do not override the PSP's legitimate interests — given that the data subject is actively conducting fraud, their interest in preventing detection is not a legitimate interest that the balance protects. The data subjects most at risk from fraud (potential victims) are the ones protected by the processing.
For sharing that fingerprint data between PSPs, the analysis extends to whether the receiving PSP's processing falls under the same lawful basis and whether the transfer itself is separately authorised.
The Section 29 DPA 2018 Exemption for Crime Prevention
The Data Protection Act 2018 Schedule 2, Part 1, paragraph 2 (implementing UK GDPR Article 23 derogation) provides an exemption from certain data subject rights where processing is required for the prevention or detection of crime, apprehension or prosecution of offenders, or the assessment or collection of a tax or duty. This exemption allows PSPs to disclose personal data — including fraud intelligence — to other controllers where the disclosure is in connection with crime prevention, without needing the data subject's consent and without triggering the normal transparency obligations.
The exemption applies where complying with the data subject rights (for example, providing a subject access request response) would be likely to prejudice the crime prevention or detection purpose. For scammer fingerprint data, it would clearly prejudice fraud prevention to notify the scammer that their fingerprint is being shared with other PSPs. The exemption therefore applies to the disclosure itself.
This is the same exemption that underpins Cifas member data sharing — PSPs share confirmed fraud indicators about individuals through the Cifas network without notifying those individuals, relying on the crime prevention exemption under DPA 2018 Schedule 2.
The Data Sharing Framework for PSP-to-PSP Exchange
For direct PSP-to-PSP scammer fingerprint sharing (outside a network like Cifas), the following framework is required:
Data Sharing Agreement (DSA). The two PSPs should document their respective controller roles, the categories of data to be shared, the purposes of sharing, the security controls, the retention periods, and the process for handling data subject rights requests and law enforcement requests. The ICO published a data sharing code of practice that is directly applicable here.
Data minimisation. Only the fingerprint elements necessary to identify a repeated attack should be shared. A full conversation transcript is almost never necessary — the derived fingerprint (hashed identifiers, behavioural signature hash, campaign classification label) is typically sufficient. Including raw conversation content in an inter-PSP share raises additional processing questions that can be avoided through proper data minimisation at source.
Purpose limitation. The receiving PSP should only use the shared data for fraud prevention against their own customer base, not for secondary analytical or commercial purposes. The DSA should make this explicit and include audit rights for the sharing PSP to verify compliance.
Retention limits. Scammer fingerprint data should have defined retention periods that reflect its operational relevance. A fingerprint from a campaign that was active in Q1 2025 is probably not operationally relevant in 2027. Automatic deletion after a defined retention period (typically 12-24 months from last confirmed campaign activity associated with that fingerprint) is good practice.
The Cifas Model and Its Limitations for APP Fraud
Cifas operates the National Fraud Database, which PSP members use to share confirmed fraud markers against individuals. It's the established UK mechanism for fraud intelligence sharing and it works well for its intended purpose — marking confirmed fraud perpetrators and confirmed victim accounts to prevent further losses.
Its limitation for APP fraud intelligence is timing. A Cifas marker is typically filed after a fraud has been confirmed — after the loss has occurred, the claim has been processed, and the investigation has reached a conclusion. For pre-transfer APP fraud detection, the signal needs to arrive before the transfer is attempted. The investigation timeline doesn't fit.
What would complement the Cifas model is a real-time or near-real-time sharing mechanism for suspected (not yet confirmed) scammer fingerprints — essentially a "hot list" of active campaign fingerprints that PSPs could query against pending transfers. This is the gap that direct PSP-to-PSP fingerprint sharing, facilitated by a technology intermediary operating under appropriate DPA governance, can fill.
Data Minimisation in Honeybot-Derived Fingerprints
A point worth addressing specifically: fingerprints derived from honeybot engagements are inherently more data-minimal than fingerprints derived from victim-reported communications. A victim's communication record contains content from both the victim and the scammer — including potentially sensitive victim information. A honeybot engagement record contains content only from the honeybot and the scammer, since the honeybot is the party being communicated with.
This means honeybot-derived fingerprints are structurally cleaner for data minimisation purposes. The derived fingerprint — the behavioural signature, the platform identifiers, the linguistic markers — is separated from victim personal data at source. Sharing that fingerprint between PSPs doesn't require transmitting any victim data.
We're not saying this makes the compliance framework trivial — it doesn't. The lawful basis analysis, the DSA, and the data minimisation discipline all still need to be in place. But the starting material is cleaner, which makes the path to compliant sharing more tractable than it is for victim-communication-derived intelligence.