Compliance by design is becoming central to Web3 identity

At a glance

What this is: IDnow’s interview argues that Web3 adoption is increasingly dependent on compliance by design, with identity assurance, data minimisation, and off-chain evidence handling doing the heavy lifting for regulated use cases.

Why it matters: IAM, fraud, and identity teams should read this as a governance signal: blockchain does not remove verification obligations, it redistributes them across KYC, AML, GDPR, and audit evidence decisions.

By the numbers:

• The European Blockchain Sandbox facilitated 60 cross-border regulatory dialogues across multiple sectors and regulatory topics.

Context

Web3 compliance is not a question of whether regulation applies, but how identity, data flow, and evidence are arranged so the system can meet it without creating avoidable privacy or retention problems. In blockchain and DLT environments, the governance gap is usually between immutable technical design and regulatory expectations for deletion, minimisation, and accountability.

The interview frames the European Blockchain Sandbox as a structured way to reduce that gap by giving regulators and innovators a controlled space to test use cases, discuss jurisdictional questions, and clarify where data should live. That matters for identity programmes because the same design choices that shape AML, KYC, and auditability also shape whether verification is defensible in production.

Key questions

Q: How should teams design Web3 identity flows to stay compliant with GDPR and AML requirements?

A: Start by separating the legal purpose of each data element from the technical place it is stored. Keep personal data off-chain where possible, minimise what is recorded on-ledger, and preserve an off-chain trust layer for verification, audit evidence, and deletion handling. That approach reduces conflict between immutable infrastructure and regulatory obligations.

Q: What breaks when identity data is stored on-chain in regulated blockchain use cases?

A: The main failure is loss of control over retention and erasure. Once identity data is written to an immutable ledger, teams can struggle to correct, delete, or restrict it later, which creates tension with privacy and compliance duties. The architecture may still work technically, but it becomes far harder to defend legally and operationally.

Q: How do organisations know whether a blockchain identity design is privacy by design?

A: Look for evidence that data minimisation was built into the workflow, not added later. A privacy by design model should show clear data purpose mapping, off-chain storage for sensitive information, controlled access to records, and a defined process for handling exceptions without expanding what goes on-chain.

Q: Who is responsible for compliance in a consortium-based Web3 identity model?

A: Responsibility is shared, but it is not diluted. Each participant remains accountable for the part of the workflow it designs, stores, or operates, while the overall model still needs clear ownership for data handling, verification logic, and regulatory interpretation. Without defined roles, compliance gaps tend to move between partners instead of being closed.

Technical breakdown

Why on-chain identity data creates a governance conflict

Blockchain systems are durable by design, which makes them awkward for personal data handling. Once information is written on-chain, deletion and erasure become difficult or impossible in practical terms, so the governance model has to decide up front what should never be stored there. For regulated identity flows, that means separating proof from payload. The identity event may need to be verifiable, but the underlying personal data often belongs off-chain, where access, retention, and deletion can still be controlled. The key technical issue is not blockchain itself, but whether the architecture treats immutability as a storage feature or a compliance hazard.

Practical implication: Treat on-chain storage as the exception path and keep personal data off-chain unless you can justify the retention model.

How compliance by design changes the identity workflow

Compliance by design means regulatory constraints are present at architecture time, not added after launch. In Web3 and tokenised systems, that requires documenting what data is processed, where it is stored, who can access it, and what purpose each step serves. The interview also points to the importance of roles and conditions, because regulated identity decisions depend on which stakeholder can act, under what authority, and with what evidence. That is a governance pattern familiar to IAM and KYC teams: controls fail when the access and evidence model is added later, after the workflow has already been built. See the Role Mining and Role Design Guide.

Practical implication: Build data, role, and evidence decisions into the workflow design review before deployment.

What off-chain trust layers actually do in regulated web3

The trust layer is the part of the system that makes identity, verification, and exception handling operational when blockchain alone cannot do it. In practice, it can support identity proofing, fraud checks, selective disclosure, and audit evidence without forcing every field onto a ledger. That is especially important where automated checks need a human fallback for edge cases or where the legal basis for sharing data is narrower than the product design assumes. The article’s central technical point is that decentralised infrastructure still depends on controlled verification logic, and that logic is where governance lives.

Practical implication: Design an off-chain verification layer that can support exceptions, evidence, and revocation without exposing unnecessary data.

NHI Mgmt Group analysis

Compliance by design is the only durable governance model for regulated Web3. The article shows that the core problem is not blockchain adoption itself, but the mismatch between immutable infrastructure and regulatory duties that still require minimisation, deletion, and accountable disclosure. That makes identity architecture a compliance control surface, not a downstream paperwork exercise. Practitioners should treat early regulatory design as part of system engineering, not post-build remediation.

The trust layer, not the ledger, is where regulated identity decisions are actually made. The interview makes clear that production use cases still need off-chain logic for verification, evidence, exception handling, and data segregation. That means the real governance question is whether the identity process can prove what happened without over-collecting what should never have been public. Control mapping becomes useful here because the same control evidence often has to satisfy multiple regulatory expectations at once.

Web3 identity programs still need classical IAM thinking about roles, access, and evidence. The recurring questions in the article, who is behind the action, what can be proven, and what can be minimised, are IAM questions in a new technical setting. When projects fail, it is usually because they treat identity as a feature rather than a governance function. Practitioners should apply identity lifecycle discipline to proofs, roles, and off-chain records.

Compliance-grade identity in Web3 depends on separating proof from payload. That is the specific concept this article sharpens: a system can prove something about a participant without embedding all of the underlying personal data in an immutable ledger. This reduces legal friction, preserves auditability, and keeps room for exception handling. The practitioner implication is simple: design for selective disclosure, not total transparency.

What this signals

Compliance-by-design will become the differentiator for regulated Web3 deployments. The projects that scale will be the ones that can explain not only how identity was verified, but why each data element was collected, where it lives, and how it can be governed after the fact. For practitioners, that shifts the programme from proof of concept thinking to evidence-led architecture.

Identity governance in blockchain environments will increasingly look like evidence choreography. The practical challenge is to preserve verifiable trust without turning the ledger into a permanent repository of unnecessary personal data. Teams that solve this will be better positioned to support auditability, selective disclosure, and exception handling without overexposing data.

For practitioners

• Define what must stay off-chain Classify personal data, pseudonymised data, and evidence artifacts before any blockchain workflow is built, then prohibit on-chain storage for items that need deletion or restriction.
• Document regulatory purpose for each data flow Map each identity event to its AML, KYC, GDPR, or sector-specific purpose so teams can show why the data is collected, where it is stored, and who can access it.
• Build off-chain verification and exception handling Use a controlled verification layer for identity proof, fraud checks, and manual fallback paths so operational decisions do not depend on irreversible ledger writes.
• Separate evidence from identity payloads Keep audit evidence, transaction proofs, and participant records in distinct systems so retention and deletion decisions do not collide with immutable ledger design.
• Review partner and provider compliance assumptions Require service providers and consortium partners to show how their components support minimisation, access control, and audit-ready evidence before integration.

Key takeaways

• Web3 governance gets harder, not easier, when immutable infrastructure meets privacy, retention, and audit obligations.
• The article’s strongest evidence is the Sandbox’s 60 cross-border regulatory dialogues, which shows that regulatory interpretation is still central to adoption.
• Teams should separate proof from payload, keep sensitive identity data off-chain where possible, and build exception handling into the trust layer.

Related NHI Mgmt Group resources: Control Mapping Guide · Role Mining and Role Design Guide · Compliance Automation Buyer's Guide

Key terms

• Compliance-by-design: Compliance-by-design means control requirements are built into workflows, systems, and evidence generation from the start. Instead of relying on manual review after the fact, the organisation makes the process itself produce the records needed to prove that policy was followed and exceptions were handled correctly.
• Off-Chain Trust Layer: The supporting verification and governance logic that sits outside the blockchain and handles identity proof, evidence, exception processing, and controlled data storage. It is the part of the system that preserves operational flexibility when the ledger itself is immutable.
• Data Minimization: Data minimization is the practice of limiting personal data collection to what is adequate, relevant, and necessary for a specific purpose. It reduces exposure by shrinking what is gathered, transferred, retained, and processed. Strong minimization depends on careful form design, purpose review, and strict collection discipline.
• Selective Disclosure: Selective disclosure is the practice of sharing only the identity attributes needed for a specific decision. In credential-based systems, it reduces oversharing, lowers retention burden, and limits exposure when a verifier does not need the full record to make a trustworthy judgment.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, IAM, and secrets management. It helps practitioners connect identity decisions to the governance controls their programmes depend on.