The short answer is yes, and it has been settled since 2016. The useful answer is that this does not stop you checking an address for fraud, because the Regulation names fraud prevention as a legitimate interest in its own recitals.

This is a practical read of where the line sits, written by people who ship an IP check rather than by lawyers. It is not legal advice, and the balancing test at the end is one your own counsel should sign.

The short answer, and where it comes from

In Breyer v Bundesrepublik Deutschland (C-582/14, 2016) the Court of Justice held that a dynamic IP address is personal data in the hands of a website operator, provided that operator has legal means available to identify the subscriber behind it, typically by going through the access provider. The operator does not need to be able to do the identification alone, which is what killed the old argument that dynamic addresses were anonymous because they rotate.

Treat every IP address you handle as personal data. The exceptions are narrow enough that building on them is not worth the exposure.

Personal data is a starting point, not a prohibition

A surprising number of teams stop at the classification and conclude they cannot run the check. That is the wrong inference. The GDPR does not forbid processing personal data. It requires a lawful basis, a purpose, proportionality, and limits on how long you keep it.

For fraud work the basis is almost always legitimate interests, Art. 6(1)(f). Recital 47 says so directly: processing personal data strictly necessary for the purposes of preventing fraud constitutes a legitimate interest of the controller. That is unusually helpful language and it is worth quoting in your own documentation.

Consent is the wrong basis here and you should resist reaching for it. A fraud check that a fraudster can decline is not a fraud check, and consent obtained under those conditions is not freely given, which makes it invalid twice over.

What changes in practice

Four things, and none of them are difficult.

  • Minimise. Send the address, and send it for a decision you actually make. Sending every request through a risk API so the data is there in case someone wants it later is not minimisation, and it is the pattern regulators find first.
  • Keep the answer, not the input. The verdict, the score and the boolean signals are what your fraud team reviews six weeks later. The raw address is rarely needed past the decision itself. Hashing or truncating it after a short window keeps the audit trail and drops the identifier.
  • Retain briefly and say the number out loud. A stated period you meet beats a vague one you exceed. It also forces the question of what the older rows are for, which usually turns out to be nothing.
  • Write the balancing test down. Not because anyone reads it, but because Art. 6(1)(f) is the basis that requires you to have done it, and reconstructing the reasoning two years later under pressure is miserable.

Is your API vendor a processor or a controller?

This determines what paperwork you need, and vendors are not always straight about it.

A vendor that evaluates the address on your instruction, for your purpose, and does not reuse it for their own ends is acting as a processor. You need a data processing agreement under Art. 28, a sub-processor list, and transfer safeguards if the processing leaves the EEA.

A vendor that feeds what you send into a shared reputation database used to score other customers is doing something for their own purposes as well. That makes them a controller for that part, and it means end-user data you sent is being used in ways your own privacy notice probably does not describe. Ask the question directly, in writing, before you integrate. The answer is a design decision on their side and they will know it immediately.

Device fingerprinting is a different question

Do not let the IP answer settle the device one. Reading an address off a connection is not storage of or access to information on terminal equipment, so ePrivacy Art. 5(3) and its consent requirement do not attach to it. A fingerprint gathered in the browser generally does, and the fraud-prevention exemption from consent is narrower than most implementations assume.

Two adjacent techniques, two different legal analyses. We wrote that one up separately.

What we do, specifically

Stated plainly so you can compare it with whatever else you are evaluating. Evaluation records are retained for the life of the account, and the raw IP address in each row is one-way hashed after seven days, leaving the country code, the boolean signals and the score. Deletion from the Security page removes your data from live systems immediately under Art. 17, and encrypted EU-stored backups expire on a rolling schedule of at most sixty days, after which it is gone from those too.

The full detail is in the privacy notice and the data processing agreement, including the sub-processor list and the transfer position.

The balancing test, in five lines

If you need to produce one this afternoon, this is the shape of it. Have your own counsel check it.

  • Purpose. Preventing fraudulent signups, payments and account takeover on our service.
  • Necessity. The address is the minimum signal that distinguishes automated abuse from a customer at the moment of the decision. No less intrusive measure achieves it.
  • Impact. One address is processed per decision, hashed after a short retention window, never sold, never used for advertising or profiling unrelated to abuse.
  • Expectations. A user signing up for an account reasonably expects the operator to check whether the request is fraudulent. Recital 47 anticipates exactly this.
  • Safeguards. Stated retention, one-way hashing, no automated decision with legal effect without human review, and a documented route to object under Art. 21.

That last safeguard is the one teams forget. If the check can refuse a signup on its own, look hard at Art. 22 and keep a human path available for anyone who asks for one.

FAQ

Frequently Asked Questions

Is a dynamic IP address personal data under GDPR?

Yes. The Court of Justice held in Breyer (C-582/14) that a dynamic IP address is personal data in the hands of a website operator where that operator has legal means available to identify the subscriber, usually through the access provider. Rotation does not make an address anonymous. Treat every address you handle as personal data.

Do I need consent to run an IP fraud check?

Generally no, and consent is the wrong basis to choose. Legitimate interests under Art. 6(1)(f) is the normal basis, and Recital 47 names fraud prevention as a legitimate interest directly. A fraud check a fraudster can decline is not a fraud check, and consent given under those conditions would not be freely given anyway.

How long can I keep IP addresses collected for fraud prevention?

The Regulation sets no number. It requires that you keep them no longer than necessary for the stated purpose and that you can justify the period you chose. In practice a short raw-address window followed by hashing or truncation covers the investigation need while dropping the identifier. State the number publicly and meet it.

Is my fraud API vendor a processor or a controller?

It depends on what they do with what you send. A vendor evaluating the address on your instruction and for your purpose is a processor, and you need an Art. 28 agreement with them. A vendor that also folds your traffic into a shared reputation product used for other customers is a controller for that part. Ask in writing before integrating.

Go deeper

A fraud check that states its retention

Raw addresses one-way hashed after seven days, EU-stored backups, deletion under Art. 17 from your own dashboard. Free at 1,000 requests an hour.

Get a free API key