Right to Erasure vs Fraud Records: Deleting by visitorId and linkedId

Sooner or later two obligations meet in one support ticket. A user asks you to delete everything you hold about them. Your fraud team wants to know whether that user is the person who opened thirty accounts last quarter. Both concerns are legitimate, and the right answer is rarely “delete everything” or “delete nothing”.

This article is a practical guide, not legal advice. The legal analysis belongs to your counsel. What follows is how to structure the decision and how to carry it out with device data.

What the law actually asks

Under GDPR Article 17, the right to erasure applies on specific grounds. Examples include data no longer being needed for its purpose, consent being withdrawn, or a successful objection. It also has explicit exceptions in Article 17(3), among them processing needed to comply with a legal obligation and processing needed for the establishment, exercise or defense of legal claims.

Fraud prevention usually rests on legitimate interest, and Recital 47 says outright that processing strictly necessary for preventing fraud is a legitimate interest. When processing relies on legitimate interest, the person can object, and the controller has to stop unless it shows compelling legitimate grounds that override the person’s interests, rights and freedoms.

In practice, that leaves room for three outcomes:

1. Erase. The usual answer for an ordinary customer with no fraud history.
2. Erase most, retain a minimal fraud record. Where there’s documented, specific fraud evidence and a reason to keep it, such as an open chargeback, a dispute or a ban you need to be able to enforce.
3. Retain and explain. Rare. Usually tied to legal claims or obligations, with a written rationale.

Other regimes such as LGPD in Brazil and US state privacy laws have their own deletion rights and exceptions. The structure below carries over, but the details differ. GDPR and device fingerprinting covers the lawful-basis question in more depth.

Two kinds of subject in device data

Fraud-prevention data about a person usually sits in two places, and they need different handling.

The device (visitorId). A browser or phone. Often one person’s, but not always: a family laptop or an office workstation is shared.

The account (linkedId). The id you attached to identification events after signup or login. It’s yours and unambiguous, and it maps to exactly one customer record.

Prynt supports erasure along both axes. An admin in the console can erase by visitorId or by linkedId, and the two behave differently on purpose.

Erasing by visitorId

Removes the device record and everything keyed to it: identification events, raw signal observations, feedback labels, allow and deny list entries on that visitorId, and stored webhook payloads that reference the device or its events.

Use it when the person is clearly the only user of the device, or when they explicitly ask for device data to be removed and nothing argues for keeping it. Rows of other devices that only shared an IP address with this one are left alone. An IP address isn’t a person.

Erasing by linkedId

Removes every event, label, list entry and webhook payload that carries that account id. The devices themselves stay. Other people may use the same device, and their history isn’t the requester’s to erase.

This is the right default for “delete my account” requests. It removes the person’s footprint in your fraud data without destroying evidence about a shared device.

In both cases, the erasure itself leaves an audit entry, for accountability. For linkedId erasures, the audit trail stores a hash of the account id rather than the raw value, since account ids are often email addresses.

Where the tension really is

The friction shows up in one specific place: deny lists and bans. If you erase a banned account’s records, including its deny-list entry, the same person can sign up again and nothing will recognize them. That’s exactly what the ban was meant to stop.

Work through it per case:

• Is there documented fraud? A confirmed outcome, a chargeback or a terms violation with evidence. Suspicion alone usually doesn’t justify keeping data after an erasure request.
• Is the retention specific and minimal? Keeping one deny-list entry and the evidence for it differs a lot from keeping full browsing history.
• Is there a time limit? Set a retention period for fraud records and enforce it. “Forever” is hard to defend.
• Is a hash enough? Hashing an identifier before keeping it reduces exposure, but a hashed identifier that still lets you recognize the person is still personal data. It’s a minimization measure, not an exemption.

Whatever you decide, the honest version is to tell the person: their account data was erased, and a minimal record was kept for fraud prevention on a stated basis for a stated period.

A workable runbook

1. Verify the requester. Erasure requests are themselves an attack vector. Someone erasing a victim’s history, or a fraudster trying to clean their own record.
2. Look up their footprint. Find their linkedId in your system, and the devices it used.
3. Check for fraud holds. Open disputes, confirmed fraud labels, active bans.
4. Decide and document. Erase by linkedId by default. Add visitorId erasure when the device is clearly theirs alone. Record any retained items with their basis and expiry.
5. Execute in every system. Your own database, your logs, and every vendor that holds the data. Device data in Prynt is one of those places, not the only one.
6. Respond within the statutory deadline with what was done and what was kept, and why.

Reduce what you need to erase

The easiest erasure is of data you never stored. Prynt’s privacy controls help here. It honors Global Privacy Control by default, so no event is stored for those visitors. IP minimization (PRYNT_IP_MODE set to truncate or none) reduces how much network data is kept, and retention follows your plan. Data retention for fraud signals covers choosing retention periods, and the privacy page and DPA describe the processing terms.

Wrap-up

Erase by account by default and by device when the device is clearly the person’s alone. Keep a minimal, documented, time-limited record only where specific fraud evidence justifies it. Write down each decision. Then ask counsel to review the policy once rather than deciding each ticket from scratch. Privacy-preserving fraud detection covers the design choices that keep these tickets rare.