There is no data-protection module in this architecture. The General Data Protection Regulation — Regulation (EU) 2016/679 — is the constraint that runs through every module in it, and it is the one constraint a contract cannot discharge, because the thing it protects against is the ledger's defining property. This is a short piece about what that constraint actually says, and about the three places it collides with rules the same stack is built to satisfy.

The architecture it constrains is in the EU-Compliant Tokenized Securities: Smart Contract Architecture pillar; the identity layer it bites hardest on is in the identity and attestations article.

1. The on-chain surface is personal data

Applies to every platform that binds a wallet to a verified investor. That is every platform this series describes.

The comfortable formulation is "no personal data on-chain." It is wrong, and a supervisory authority will say so. Recital 26 treats data as personal where a person is identifiable by means reasonably likely to be used, and the European Data Protection Board's Guidelines 02/2025 on blockchain confirm that wallet addresses and transaction data linked to an identifiable person are personal data. A wallet bound to a verified record is personal data. So is every transfer it makes, every balance entry, and every key in the identity registry. This design cannot reach zero, because the register is the product.

Three consequences, and the first is the one to write down:

• The lawful basis has to cover the on-chain surface itself. It does — Article 6(1)(c), because maintaining the register and enforcing transfer restrictions are legal obligations. But that basis has to be written against the addresses and transfers, field by field, in the record of processing and the impact assessment — not against the off-chain store alone.
• The impact assessment is mandatory by name, not by judgment. Article 35(3)(b) catches large-scale processing of special-category or criminal-conviction data, and biometric identity verification and sanctions and politically-exposed-person screening are exactly that. Where residual high risk survives mitigation, Article 36 requires prior consultation with the lead authority before processing begins, and the authority has eight weeks, extendable by six. That is a 14-week worst case on the critical path, longer than any prospectus or fund-parameter lead time in this series. Sequence it into the roadmap, not launch week.
• Say the true thing in the prospectus. The offer document already has to describe the identity mechanism and transfer mechanics. A disclosure that says personal data is not on-chain would be inaccurate.

2. What goes on-chain — two tests, in order

Applies to every field that describes a natural person.

The architecture's gating test asks whether an on-chain function reads a record. Article 5(1)(c) — data minimization — asks a second question the gating test cannot see. Could the gate read a derived boolean instead of the attribute? A jurisdiction field passes the first test cleanly, because the covenant predicates read it, and may still fail the second, because a jurisdiction-eligible flag would gate identically while storing less. An address alone is a weak identifier; an address plus tier plus jurisdiction plus person type is a profile, and every added field moves re-identification from "possible with the off-chain record" toward "reasonably possible without it."

Run both tests on every field, in that order, and record the answer per field in the impact assessment. Which fields survive on the investor record is a decision for the data-protection officer, not for the engineer, and in our own design it is still open.

A third question comes before both, and it is easy to skip: what is the record keyed by? 

The standard identity-registry shape in this sector keys by wallet, because the pattern it descends from puts the attributes in a per-investor identity contract and leaves the registry holding a pointer. Drop that per-person contract for data-protection reasons — a contract whose storage and address outlive an erasure request is exactly what Article 17 cannot tolerate — and it is very easy to keep the wallet-keyed registry and push the attributes into the wallet row. That is half a pattern, and it fails twice. 

Erasure has nothing to delete, because there is no person record; deleting the wallet rows one at a time is an operation nobody has a complete list for. And one human can hold two answers. Register wallet A as Germany/retail and wallet B as Ireland/professional under the same person, and nothing objects. That second failure is not a privacy problem at all, it is a prospectus-exemption problem, because the per-Member-State money threshold and the 150-person headcount both count people. 

Key the record by the person, give the wallet nothing but a binding, and both failures become unrepresentable rather than merely checked. Minimization improves as a side-effect: one copy of each attribute per human instead of one per address.

Two further measures are settled regardless:

• One wallet per investor per issuer. No address reuse across issuers or venues. Linkability is the limb of this problem that key destruction cannot reach.
• The pre-declared attribute set is the minimization control. The relying-party duty under eIDAS 2.0 to declare exactly which attributes are consumed doubles as the Article 5(1)(c) record.

A third measure is genuine and easy to over-read: on a permissionless chain the set of parties for whom re-identification is reasonably possible includes every chain-analytics vendor. So restricted read access is a real Article 32 supplementary measure. That is a data-protection argument for a permissioned deployment. It is not the market-integrity argument for one, and the two should not be merged.

3. Erasure is approximated, not achieved

Applies to every investor record. This is the section to get the wording right in, because the wording is what the authority reads.

Article 17 gives the data subject a right to erasure. An immutable ledger cannot honor it. There are only two states: the personal data was designed off-chain, which is acceptable, or it was put on-chain knowing erasure was impossible, which is a structural breach of Article 17 and of Article 25's design duty. "We can't delete it because it's on-chain" is not a defense.

We build the first state. Direct identifiers stay off-chain; the ledger holds a wallet, claim hashes and attestation references. Erasure is the off-chain record deleted and its encryption key destroyed, after which the on-chain anchor becomes non-resolving. Non-resolving is not non-personal. The orphaned address is unlinkable without the deleted record; it is not unlinkable to anyone at all, which is what anonymization under Recital 26 requires. Say "approximation" in the erasure plan. An authority that reads "erased" and finds an immutable identifier will treat the document, not just the system, as the problem. The documented erasure plan is itself a required artefact under the Board's guidelines — designed in from inception, naming the measures.

One request, one call — and the order inside it is load-bearing. 

An erasure request names a human, and the human's residue is spread across every contract that ever recorded something about them. The covenant store, the venue's membership and trading limits, the managers' register, the offer's headcount slot. Chasing those by hand inside a one-month response window is how a partial erasure gets certified as a complete one. So the erasure path is a single coordinator with a governance-managed list of targets. It reads the person's wallet list from the identity registry, fans out to every target, and erases the identity registry last. Because most of those stores are keyed by address and cannot expand a person identifier themselves. So erasing the registry first destroys the list the rest of the run depends on. Four properties are deliberate.

The fan-out is atomic

One target refusing stops the whole request, because a half-erased person is worse than an un-erased one, and a receipt for an erasure that did not happen is worse than both. Skips are recorded, with a mandatory reason digest in both directions, so a target excluded from a run leaves a trail. There is a short timelock — ours defaults to 24 hours with a hard ceiling of seven days which sits comfortably inside the one-month response window and gives the operator somewhere to stand while deciding. And the erasure role is separate from every onboarding role. The key that registers investors is not the key that deletes them.

Some legs must be able to say no, and saying it by refusing is better than saying it by skipping. 

Article 17(3) has exceptions, and three of ours are structural rather than discretionary. A venue member who is still admitted cannot be erased: the admission is a live regulatory decision the operator is accountable for and a row in a periodic report to the regulator, so the sequence is withdraw, then erase. An offer that is still open cannot release its headcount slot, or the same person can be counted twice against the 150-person exemption. A managers' register entry cannot go until the declaration is revoked and the operator's retention window has run. 

One thing worth checking rather than assuming there.

The market-abuse regime's managers'-transactions article carries no retention period at all, the five-year duties in that regulation sit in the market-soundings, disclosure and insider-list articles instead. So a retention window on a managers' register is operator policy by analogy, not a statutory minimum, and the duty that actually binds is the standing obligation to maintain the list. Say which it is in the impact assessment. And one store is never wired into the erasure path in the first place: the restriction register that holds sanctions listings, because Article 17(3)(b) is precisely the point. Erasing a listing on request deletes the reason the platform must refuse the transfer.

The honest limit: a coordinator like this is complete as to storage and silent as to history. 

It reaches every deletable field in every contract on its list. It reaches no event and no calldata, ever. So the surfaces the minimization rules below protect are the whole residual, and there is no later fix for anything written to them. Which is the argument for taking those rules seriously before the first emit, not the argument for treating erasure as hopeless. State the limit in the impact assessment in terms. An authority that finds it stated is reading a controller who understands their system; one that finds it omitted is reading a claim that does not survive inspection.

Events are the worst surface, not the exempt one. 

The architecture's carve-out — emitting an event is not storing state — is about what a contract reads. Article 17 is about what a person can get erased, and on that axis the reasoning runs backwards: storage can be deleted, a log cannot. So a registration event that carried tier and jurisdiction would leave them readable forever after the record was deleted. Every event that describes a natural person emits the wallet and an opaque hash and nothing else. One residual survives by design: the event that records a wallet recovery links two wallets of the same person permanently, because that linkage is the point of the audit trail. It goes in the impact assessment as a documented residual, not engineered away.

The person key is the sharpest case, not an exception. 

Every wallet an investor holds resolves to one internal person identifier. The value that lets wallet recovery prove two addresses are one investor, that lets the restriction store follow a listing across every wallet. And that lets the headcount exemptions count people rather than addresses. Put that identifier in a log, even once, and the log states permanently that a set of addresses is one human. In a managers' register it states whose spouse or child that human is.

The identifier lives in storage, where a single erasure call can remove every wallet under it, and in no event anywhere. And the same holds for every other attribute of the person. Jurisdiction, classification tier, natural-or-legal, claim outcomes, a declared covenant, the ground on which a director was permitted to trade in a closed period. 

The rule, stated positively: an event says that something happened to a wallet; storage says what. What may appear in a log is the wallet as the subject of the action, digests the operator minted and can resolve, a legal entity identifier (legal persons are outside the Regulation), and aggregates that are about nobody.

"Then how does the indexer know who it was?" 

It already knows. The operator's onboarding system ran the verification, minted the person identifier, stored identifier-to-wallet-to-record in its own database, and only then wrote to the chain. When the event arrives carrying a wallet, the indexer resolves the person from that database from data the operator held before the chain was ever involved. Nothing was lost by keeping the identifier out of the log; the operator is the party that invented it.

And the database row is the one copy of the linkage that can be deleted, which is exactly why it must be the copy that holds it. Erasure is delete the row, deregister the person on-chain, and the surviving event resolves to nothing. A third party without that database is meant to be able to do less after erasure, not the same. This is the pattern the Board's guidelines and CNIL describe, and the one every regulated deployment we are aware of runs.

Calldata is a log for this purpose. 

A function argument sits in the transaction, on every archive node, forever. Taking an identifier out of an event and passing it as a keeper's argument instead moves the disclosure; it does not remove it. Where a value must reach the contract and must not be retained, the contract resolves it in storage from a wallet, it is never supplied. The residual this leaves is the registrar's own writes, which carry the attributes they write by necessity. On a permissioned ledger that surface is not publicly readable and the question closes; on a public chain it does not, and it belongs in the impact assessment under legal obligation, with the five-year retention as its outer bound.

Two adjacent rights, one of them awkward. 

Article 19 requires every rectification, erasure and restriction to be notified to each recipient for a shared identity registry, every consuming surface. For erasure the coordinator above discharges that duty by execution rather than by correspondence: the target list is the recipient list, and one transaction reaches all of it. Rectification and restriction have no equivalent, and recipients outside the contract set never will. Article 18 gives a right to restriction: processing flagged and suspended without deletion, a third state that is neither active nor erased. The obvious implementation is a flag on the identity record. That is barred, because a second wallet-level state beside the restriction store is precisely the two-slot leak the tipping-off design removes.

So an Article 18 restriction either suspends processing off-chain only, or enters the same store as every other stop where it is indistinguishable from a suspicion block, which is its own problem. Unresolved, and stated here rather than papered over. Article 20 portability, by contrast, largely does not apply: it covers processing on the consent or contract bases, and this stack runs on legal obligation. Do not build the export pipeline for it.

4. The five-year retention collision

Applies to every entity inside the anti-money-laundering regime, and to every entity that screens against sanctions lists regardless.

The Anti-Money-Laundering Regulation ((EU) 2024/1624, applying from 10 July 2027) requires at Article 77 that

• due-diligence records, transaction records and suspicion assessments be retained for five years,
• extendable by a further five on the supervisor's direction, retrievable by the financial intelligence unit within two working days,
• and then deleted in a GDPR-compliant and auditable way.

GDPR's storage-limitation principle requires deletion once the purpose ends. Read carelessly, an erasure request in year two and a retention duty running to year five contradict each other, and a design drafted from either side alone ends up doing whichever the writer thought of last.

They do not contradict. Article 17(3)(b) disapplies erasure where processing is necessary for compliance with a legal obligation under Union or Member State law, and Article 77 is one. The reconciliation is documentary and mechanical, and it must be agreed before either the identity layer or the erasure plan is built.

Four rules that make the five-year floor and erasure coexist on paper.

• The five-year period is documented as the GDPR retention period, under the legal-obligation basis, in the record of processing. An erasure request inside it is refused on that ground, and the refusal is recorded.
• Deletion runs on day one of year six unless an extension is justified and recorded. The retention store supports an event-driven extension on supervisory direction without re-papering the base.
• The retention floor is a floor. National law may require longer for tax or judicial purposes, and the Regulation does not override it. Until July 2027 the prior directive as transposed governs, and the periods vary.
• The Board and the anti-money-laundering authority are still finalizing joint guidance on this interface. Register the date and re-check.

What this means for the ledger is narrower than it sounds. The anchor persists regardless; the off-chain record is what the five years govern. What the collision decides is when key destruction may run never before the retention period ends, whatever the data subject asks.

5. Two collisions with the tipping-off prohibition

Applies to every platform that blocks transfers for anti-money-laundering or sanctions reasons.

The transfer gate refuses a blocked wallet with one generic reason, because disclosing that a refusal was suspicion-driven is a criminal offence in most Member States. Two GDPR rights pull the other way, and neither is resolved by the reason being hidden.

Is a transfer refusal an Article 22 decision? 

Article 22 restricts decisions based solely on automated processing that produce legal or similarly significant effects, and where an exception applies it requires safeguards human review and a right to contest. A contract call that refuses to move an investor's holding is automated and arguably produces a legal effect. If it applies, the investor may demand human review of a refusal that the tipping-off rule forbids explaining.

The reconciliation is procedural: the on-chain revert stays generic, and contest requests route to a human reviewer permitted to know the reason. What counsel has to decide is the wording of the refusal notice and who may issue it not whether to change the contract, which is already built the way both answers require. Note that exclusion from a distribution is a stronger case than a transfer refusal, because it withholds money the holder is contractually owed.

Is a permanent public record that a person was restricted lawful under Article 10? 

The restriction store publishes, permanently and to everyone, that a wallet was blocked. The reason never reaches the chain; the block itself does. Article 10 restricts processing of data relating to criminal offences to processing under official authority or authorized by law with safeguards, and the sharper test is the false positive. Sanctions screening produces name-collision hits routinely, and lifting a block emits a further event rather than removing anything. So the public record of having been blocked survives its own correction, an accuracy problem under Article 5(1)(d) before it is an Article 10 one.

Widening the store to hold probate holds and lost-key holds alongside sanctions entries makes membership no longer imply an offence, and at the same time puts people under no allegation into a store an observer knows also holds suspicion blocks. Three candidate answers exist. The anti-money-laundering obligation is itself the legal authorization and the residual goes in the impact assessment. The wallet-level event is dropped and blocking is observed only through a pseudonymous record identifier; or the block is not evented at all. This design does not choose between them. The data-protection officer does, before the first live screening run.

6. Controller, processor — or joint

Applies wherever more than one legal entity reads the same investor record.

The working allocation is that the issuer is controller, the contract operator is processor under an Article 28 agreement, and the wallet provider is a controller for the attributes it issues. That is asserted, not established. Article 26 provides a joint-controllership path where two or more parties jointly determine purposes and means. Requiring a transparent arrangement with its essence made available to data subjects and an issuer, a venue operator and a fund manager consuming one shared identity registry look more like joint controllers than like a controller and its processor. eIDAS 2.0's requirement of logical and functional separation for anyone issuing attestations points the same way. 

The simplest answer to both is not to share one investor record across legal entities. Test the classification before building the shared registry, not after.

7. One incident, up to four clocks

Applies to every platform. The tightest clock is not this Regulation's.

Article 33 gives 72 hours from awareness to notify the lead authority where there is a risk to rights and freedoms, with a reasoned justification if late, phased notification permitted, and a continuously maintained internal breach register. Article 34 adds communication to affected data subjects where the risk is high escapable by encryption or mitigation, but the authority can compel it.

Those duties coexist with, and do not substitute for, the financial-sector and cyber-security reporting regimes: a single incident can trigger the data-protection authority, the financial regulator, the national cyber-security team, and the financial intelligence unit where anti-money-laundering data is implicated. Build one incident-classification engine. A pipeline built to the financial regime's four-hour clock satisfies Article 33 by construction; one built to 72 hours fails the other.

If you're planning to build a GDPR-compliant tokenization build, then our RWA tokenization deveopment company is what you need of.

At a glance

Article	What it means for the build
Recital 26; EDPB 02/2025	A KYC-bound wallet is personal data. Never claim otherwise — to an authority, in the DPIA, or in the prospectus
Art 6(1)(c)	Legal-obligation basis, documented against the on-chain fields themselves
Art 5(1)(c); Art 32	Two tests per field — is it gated on, and would a boolean do. Then a third that comes first: key the record by the person, not the wallet. One wallet per investor per issuer. Restricted read access is a real supplementary measure
Art 17; Art 25	Off-chain delete plus key destruction plus one on-chain coordinator — atomic fan-out, identity registry erased last, short timelock, erasure role separate from onboarding. Still labelled an approximation: complete as to storage, silent as to history. Events carry the wallet and a digest, never the person key or an attribute — an event says that, storage says what. The erasure plan is the artefact
Art 18; Art 19	Restriction is a third state with no safe on-chain home yet. For erasure the coordinator's target list is the recipient list; rectification, restriction and off-chain recipients stay manual
Art 20	Do not build — legal-obligation basis, not consent or contract
Art 17(3)(b) ↔ AMLR Art 77	Five years documented as the retention period; erasure refused inside it; deletion on day one of year six unless extended. Agree it before the identity layer is built. The sanctions register is never wired into the erasure path at all
Art 17(3) — structural refusals	A live venue admission, an open offer's headcount slot, an unrevoked managers'-register entry. Each refuses rather than skips, so the request lands on a human inside the month. ⚠️ The managers'-transactions article carries no retention period — that window is operator policy, not statute
Art 22	Generic revert stays; contest requests route to a human who may know the reason. Wording and issuer of the notice are counsel's
Art 10; Art 5(1)(d)	The block event, not the reason, is the sensitive datum. Three candidate answers; the DPO picks before the first live screening
Art 26; Art 28	Controller/processor is asserted. Test for joint control before sharing one record across entities
Art 33–36	72 hours; one classification engine across four regimes; DPIA mandatory by name; 14-week prior-consultation worst case

This is engineering commentary on regulatory requirements, not legal advice. Data-protection conclusions turn on supervisory practice and on the specific processing, and need sign-off from counsel and the data-protection officer.