Blockchain Addresses Can Be Personal Data: GDPR Requirements for Crypto Compliance Tools

Most compliance teams at crypto asset service providers (CASPs) focus on which sanctions lists their screening tool covers. That's the right starting point -- we've written about what the Chainalysis free oracle does and doesn't cover and published a full comparison of screening tools. But there's a second compliance layer that almost no one talks about: data protection.

Every time you send a customer or counterparty blockchain address to a third-party screening API, you may be transmitting personal data to an external vendor. That transaction needs a GDPR role assessment. If your vendor processes the data on your instructions, you need a Data Processing Agreement; if their servers or support flows are outside the EU without adequate safeguards, or if they can't tell you how long they retain your screening logs -- you have a GDPR problem on top of your sanctions compliance problem.

On 7 July 2026, the European Data Protection Board adopted the final v2.0 of Guidelines 02/2025 on processing personal data through blockchain technologies. This article breaks down what those guidelines mean for your compliance tooling stack.

---

1. Are blockchain addresses personal data under EDPB guidance?

The argument that blockchain addresses are "just random strings" and therefore not personal data has never held up legally. EDPB Guidelines 02/2025, final v2.0 adopted on 7 July 2026, settle the practical point for blockchain identifiers.

Pseudonymous does not mean anonymous

The guidelines explicitly address the classification of on-chain identifiers. Public keys, blockchain addresses, accounts, wallet identifiers, and transaction metadata often operate as pseudonymous data -- not anonymous data. Under GDPR Recital 26, data is personal data if a natural person can be identified "directly or indirectly" by means "reasonably likely to be used."

The EDPB confirms that public keys and other on-chain identifiers qualify as personal data whenever they can be linked to a natural person through means reasonably likely to be used. Those means include:

• Off-chain KYC data -- your own customer records linking addresses to identities
• Exchange deposit/withdrawal records -- centralized exchanges know which user controls which address
• Blockchain analytics -- clustering algorithms, transaction graph analysis, and address attribution databases
• Data breach correlation -- leaked datasets that map addresses to real-world identities

The point is not only whether you can identify the person behind the address. It's whether the person can be identified with reasonably available means. In a CASP context, addresses connected to customer files, exchange records, transaction monitoring, or analytics databases should be treated as personal data unless you have documented a stronger reason not to.

What this covers in practice

For a CASP running sanctions screening, the following data elements should be treated as personal data when they relate to customers, counterparties, or other identifiable natural persons:

• Screening request logs -- the blockchain addresses you submit to a screening API, with timestamps
• Screening results -- whether an address was flagged, which list triggered the match, the risk score
• Audit trails -- historical records of who was screened, when, and what action was taken
• Transaction monitoring data -- origin/destination addresses, amounts, chain identifiers

All of these are routinely transmitted to or generated by third-party compliance tools. When they relate to identifiable people, each collection, lookup, storage, export, or deletion step is a GDPR processing operation.

---

2. How should you classify your sanctions screening vendor?

When you integrate a third-party sanctions screening API, the GDPR roles are usually practical but not automatic. The EDPB stresses that roles and responsibilities require a factual assessment for each processing activity.

• You (the CASP) are normally the data controller for compliance screening. You determine why blockchain addresses are screened -- sanctions and AML compliance.
• Your screening vendor is normally the data processor when it processes addresses only on your behalf, according to your documented instructions.
• Different roles are possible if the vendor determines its own purposes or essential means, reuses data for independent analytics, or combines your screening data with other products. In that case, a processor DPA alone is not the right answer.

If the vendor is your processor, GDPR Article 28 is explicit: a controller may only use processors that provide "sufficient guarantees to implement appropriate technical and organisational measures" to protect personal data. And the relationship must be governed by a contract -- the Data Processing Agreement.

What the DPA must contain

Article 28(3) lists eight mandatory provisions for any DPA. For a sanctions screening vendor, these translate to:

• Subject matter and duration -- sanctions screening of blockchain addresses, for the term of the service agreement
• Nature and purpose -- checking addresses against sanctions lists to fulfill regulatory obligations
• Categories of data -- blockchain addresses, transaction identifiers, screening results, timestamps
• Categories of data subjects -- your customers and counterparties whose addresses are screened
• Processing only on documented instructions -- the vendor cannot use your screening data for their own purposes (training ML models, compiling analytics, marketing)
• Confidentiality obligations -- everyone with access to the data is bound by confidentiality
• Sub-processor disclosure -- if the vendor uses AWS, GCP, or any other sub-processor, they must disclose it and you must approve it
• Deletion or return on termination -- when you stop using the vendor, they must delete your data or return it, at your choice

---

3. Where does your screening data live — and why does it matter?

GDPR Chapter V governs international transfers of personal data. The rules are straightforward in principle: personal data can only leave the EU/EEA if the destination country provides an adequate level of protection, or if specific safeguards are in place. The EDPB also flags cloud computing and non-EU nodes as practical transfer risks in blockchain-related processing.

The Schrems II legacy

The 2020 Schrems II ruling (Case C-311/18) invalidated the EU-US Privacy Shield and raised the bar for all data transfers to the United States. While the EU-US Data Privacy Framework (adopted July 2023) restored an adequacy basis for certified US companies, it only applies to organizations that have self-certified under the framework.

If your screening vendor is a US company that hasn't self-certified under the Data Privacy Framework, transferring blockchain addresses to their servers usually requires Standard Contractual Clauses (SCCs) plus a documented transfer assessment and any needed supplementary measures. The assessment must evaluate whether third-country law and practice could compromise the protection of the transferred data.

For most CASPs, this is compliance overhead you may be able to reduce. EU/EEA-hosted screening can simplify the transfer analysis, but it does not end the question by itself. Check where application servers, databases, backups, support access, telemetry, error logs, and sub-processors are located, and whether any onward transfer is covered by a valid mechanism.

MiCA record-keeping adds another layer

MiCA Article 68 requires CASPs to retain records of all crypto-asset services, activities, orders, and transactions for a minimum of five years -- up to seven if requested by a national competent authority. These records must be detailed enough for regulators to reconstruct every transaction.

Sanctions screening results are part of these records. If your screening vendor deletes logs after 12 months or doesn't provide data export, you can't meet MiCA's retention requirements. If those logs are stored outside the EU, you have both a GDPR transfer issue and a MiCA record-keeping issue simultaneously.

---

4. What should your vendor selection checklist include for GDPR?

When evaluating a sanctions screening tool, sanctions list coverage is only half the assessment. Here's what a GDPR-aware vendor selection process looks like:

1. EU-hosted infrastructure and access. Verify that the screening API processes and stores data within the EU/EEA. Ask specifically: where are the application servers, databases, backups, logs, support teams, and sub-processors located? "Cloud-hosted" is not an answer -- you need regions and access paths.
2. Data Processing Agreement available. The vendor should provide a DPA that meets Article 28(3) requirements -- not buried in general terms, but as a standalone, signable document. If they don't have one, they haven't thought about GDPR.
3. Data retention and deletion policy. How long does the vendor retain your screening queries and results? Can you request deletion? Is deletion verifiable? The policy must be documented and specific -- not "we follow industry best practices."
4. Sub-processor transparency. The vendor must disclose all sub-processors (cloud providers, list providers, analytics services) and their locations. You must have the right to object to new sub-processors. This should be in the DPA.
5. Breach notification process. Under GDPR Article 33, controllers must notify supervisory authorities within 72 hours of a breach. Your DPA must require the vendor to notify you "without undue delay" -- which means faster than 72 hours, because you still need time to assess and report.
6. Data subject rights support. If a customer exercises their GDPR rights (access, rectification, erasure), the vendor must be able to locate and handle data related to that individual's blockchain addresses. Ask: can you search your systems by a specific address and return or delete all associated records?
7. Security certifications. SOC 2 Type II or ISO 27001 certification demonstrates that the vendor has been independently audited for security controls. These aren't strictly required by GDPR, but they're strong evidence of "appropriate technical and organisational measures" under Article 32. For smaller CASPs, asking for at least a SOC 2 Type I report is reasonable.
8. No data reuse clause. The DPA should explicitly prohibit the vendor from using your screening data for their own purposes -- product improvement, aggregate analytics, benchmarking, or resale. If the vendor's business model depends on aggregating customer screening data, that's a GDPR red flag.

---

5. What are the common GDPR pitfalls with compliance tools?

We've reviewed the data protection posture of several common screening setups. These are the patterns that create the most risk:

Free tools with no DPA

Free screening APIs -- including free tiers from major providers -- typically come with terms of service, not a Data Processing Agreement. A ToS is not a DPA. It doesn't contain the mandatory Article 28(3) provisions, doesn't address sub-processors, and doesn't give you the contractual basis you need. If you're processing personal data through a service governed only by a ToS, you're operating without the required legal framework. This applies even if the tool is from a reputable vendor.

US-hosted audit logs

Some vendors offer EU-hosted APIs but route audit logs, analytics, or error reporting through US-based services. Screening metadata -- which addresses were checked, when, and what the result was -- can be personal data. If that metadata ends up on a US server without Data Privacy Framework coverage, SCCs, or another valid transfer mechanism, the transfer risk remains even though the primary screening happened in the EU.

No data deletion mechanism

If your vendor can't delete your historical screening data when you offboard, they're retaining personal data without a legal basis after the processing relationship ends. Ask before you sign: what happens to my data when I cancel? "We'll archive it" is not the same as "we'll delete it within 30 days and provide a certificate of deletion."

Mixing compliance data with marketing

Some compliance platforms are part of larger companies that also offer marketing, analytics, or research products. If the same entity processes your sanctions screening data and your newsletter sign-ups, the purposes need to be strictly segregated. Cross-contamination of compliance data into marketing systems is a purpose limitation violation under GDPR Article 5(1)(b) -- and it would be extremely difficult to explain to a regulator.

Vendor lock-in through data inaccessibility

If you can't export your screening history in a structured format, you can't migrate to another vendor without losing your audit trail. MiCA requires you to keep those records for five years. A vendor that holds your compliance records hostage is a regulatory liability.

---

How do common screening setups compare for GDPR compliance?

Here's how typical screening configurations stack up against GDPR requirements:

The difference is not about which setup is "more secure." All three can implement strong encryption and access controls. The difference is regulatory overhead: US-hosted vendors may require additional legal instruments, transfer assessments, and ongoing monitoring, while EU-hosted vendors can reduce that work if all processing, logs, support access, backups, and sub-processors stay in the EEA. Free tools without DPAs lack the legal foundation entirely.

---

What does this mean for vendor selection?

Data protection is becoming a competitive differentiator in the compliance tooling market. CASPs that have been through a regulatory inspection know that auditors don't just ask about sanctions lists -- they ask about data flows, vendor contracts, and retention policies.

The practical takeaway: when evaluating screening tools, your assessment should have two tracks running in parallel. Track one: does this tool screen against the sanctions lists I need (EU, UN, OFAC, UK)? Track two: have I classified the vendor's GDPR role correctly, and if it is a processor, does it meet my Article 28 obligations?

Failing on track one means you might miss a sanctioned address. Failing on track two can turn your screening archive into a data protection finding. Both carry regulatory risk. But the data protection risk scales with volume -- every screening request tied to an identifiable person is a separate processing operation.

---

Frequently asked questions