MiCA, GDPR, and Crypto Wallet Addresses
A Bitcoin address is 26–35 characters in Base58Check encoding. It starts with "1", "3", or "bc1". An Ethereum address starts with "0x" and holds 40 hex characters. Both are pseudonymous. Neither names a person directly.
The law still applies.
When a Wallet Address Becomes Personal Data
Pseudonymous records are personal records if they link to a real person. A crypto exchange holds KYC files. Those files tie these addresses to verified identities. The address alone names no one outside the exchange. Inside its systems, it names a customer. That makes it personal data.
The regulation covers it in full.
MiCA Adds a Second Layer
EU MiCA (Markets in Crypto-Assets) took effect in December 2024. It requires crypto asset service providers — CASPs — to protect customer records. A European exchange now faces two rules at once. MiCA sets financial controls. The regulation sets data protection rules. Both apply to the same identifier.
The Detection Gap in Standard Tools
Standard PII tools were built for traditional finance. They know IBAN. They know SWIFT/BIC. They know routing numbers. They do not know crypto address formats.
Send a document with a Bitcoin address, an Ethereum address, and a SWIFT code through a standard tool. It finds the SWIFT code. It misses both on-chain addresses.
For a CASP processing KYC files, this gap is serious. These identifiers are as sensitive as bank account numbers. Missing them means no encryption, no masking, and no audit trail.
Article 32 and the Encryption Gap
GDPR Article 32(1)(a) requires pseudonymization and encryption as baseline controls. 56% of GDPR fines cite poor encryption as a factor. An exchange that encrypts all detected PII but misses wallet addresses has protected nothing at the core of its work.
Detection must cover the full identifier set. For a CASP, that set includes these address formats.
What a Compliant Pipeline Looks Like
A compliant exchange adds these entity types to its detection step. Bitcoin and Ethereum formats are included. The addresses are flagged, encrypted, and logged in the ROPA next to IBANs and account numbers. The DPIA names each identifier type covered. MiCA audit trails align with processing records.
No new policy is needed. The gap is technical. Adding the right entity types to the detection step closes it.
For technical measures under Article 32, see GDPR Article 32 and AI tools monitoring PII exposure. For how pseudonymization works in practice, see EDPB 2025 pseudonymization guidelines.
When This Approach Has Limits
Adding Bitcoin and Ethereum address formats to the detection step is exactly the right fix for the crypto gap, and the technical point is sound. But three limits apply.
Address formats are a moving target. Base58Check, bc1 SegWit, and 0x hex cover the common cases, but the chain ecosystem keeps adding formats: bech32m Taproot addresses, Layer-2 and rollup conventions, and dozens of altcoin and token-standard schemes with their own encodings. A detector configured once will quietly miss the formats invented after it shipped. Custom and emerging address types need explicit configuration and held-out testing against your real KYC files, and the entity set needs review whenever the exchange lists a new asset.
Detecting the address is not encrypting the person out of scope. Flagging and encrypting a wallet address protects one identifier, but the KYC file links it to a verified name, document, and account. Encryption with a retained key is pseudonymization, not anonymization: the data stays in GDPR scope and the burden shifts to guarding the key. The ROPA and DPIA must reflect that the linked records remain personal data, and that breach exposure depends on key custody as much as on detection.
Detection volume does not equal compliance. A CASP faces MiCA financial controls and GDPR data-protection duties on the same identifier, and no detection step resolves either on its own. Whether encryption and pseudonymization meet the Article 32 baseline, and whether MiCA audit obligations are satisfied, are judgments that require human review of the pipeline and its records. Treat the detector as one logged control, and keep a compliance owner confirming that addresses are handled the way the DPIA claims.