Security tokens must only reach investors who have passed KYC/AML and are eligible for the offering — but personal data must never be written to a public ledger. The solution is to keep verification off-chain with a regulated provider and put only signed, revocable claims (or whitelist entries) on-chain, which the token checks on every transfer. This keeps compliance enforceable in code while respecting GDPR and similar privacy laws.
Key takeaways
- Separate verification from enforcement: providers verify people; contracts enforce the results.
- Options: address whitelists, claim-based identity (ONCHAINID / ERC-3643), DIDs with Verifiable Credentials, soulbound attestations.
- Design for expiry, revocation, re-verification and wallet recovery.
- Add ongoing AML: sanctions screening, transaction monitoring and travel-rule data where applicable.
Identity models compared
| Model | How it works | Pros | Cons |
|---|---|---|---|
| Whitelist | Admin adds approved addresses | Simple | Manual, no attributes, hard to share across tokens |
| Claims (ONCHAINID) | Trusted issuers sign claims on an identity contract | Reusable, multiple issuers, expiry and revocation | More contracts |
| DIDs + VCs | Credentials held by user, presented to verifier | Strong privacy, standards-based | Verifier infrastructure needed |
| Soulbound tokens | Non-transferable NFT as attestation | Visible, easy | Public, revocation design needed |
We used a pluggable KYC/AML module on our real estate platform so a regulated provider can be connected without changing token logic, and DIDs with W3C Verifiable Credentials for devices on our solar PPA platform.
How claim-based compliance works
- Investor completes KYC/AML with a regulated provider (document check, liveness, PEP/sanctions screening, source of funds).
- The provider signs claims — e.g. “KYC verified”, “country = FR”, “professional investor” — and attaches them to the investor’s on-chain identity.
- The investor’s wallet(s) are linked to that identity in the token’s identity registry.
- On each transfer the token checks the receiver has valid claims from trusted issuers.
- When KYC expires or a sanction hits, the claim is revoked and the investor can no longer receive tokens.
See ERC-3643 for the full architecture.
GDPR and privacy by design
- No personal data on-chain — not in metadata, events or calldata. Blockchains cannot honour erasure requests.
- Pseudonymous identifiers only; map them to people in access-controlled systems.
- Minimal claims — prove eligibility, not identity details.
- Data processing agreements with KYC providers; documented legal bases and retention.
- Consider zero-knowledge proofs for attributes like age or accreditation.
Ongoing AML obligations
- Periodic KYC refresh and claim renewal.
- Sanctions and PEP screening of holders and counterparties.
- On-chain analytics to detect exposure to illicit funds.
- Transaction monitoring for unusual patterns.
- Travel-rule data exchange for transfers between VASPs where applicable.
Wallet recovery
Investors lose keys. Plan for re-verification and agent-driven recovery (forced transfer to a new verified wallet), or use smart accounts with social or institutional recovery. See custody and wallets.
Onboarding flow with a regulated KYC provider
- Investor signs up and consents to data processing (recorded with timestamp).
- Platform launches the provider’s verification flow (ID document, selfie/liveness, address, source of funds as needed).
- Provider returns a decision and risk score via API/webhook.
- Platform maps the result to eligibility: country, investor category, offering-specific approvals.
- Platform (or provider as trusted issuer) writes claims to the investor’s on-chain identity.
- Investor’s wallet is linked to the identity; they can now subscribe.
- Scheduled jobs re-screen against sanctions lists and trigger refreshes before claims expire.
Corporate and institutional investors (KYB)
For companies and funds, verification covers registration documents, directors, ultimate beneficial owners and authorised signatories. On-chain, the identity represents the entity; multiple wallets (e.g. a multisig and a custodian account) can be linked, and signer changes are managed off-chain with updated claims.
Data minimisation in practice
| Instead of storing on-chain… | Store on-chain… |
|---|---|
| Name, date of birth, passport number | Signed claim: “KYC verified by Provider X until 2027-10-01” |
| Country of residence | Country code (only if required for compliance rules) |
| Investor income / net worth | Claim: “Professional investor (category)” |
| Corporate documents | Claim: “KYB verified” + hash of internal record reference |
Frequently asked questions
It should not be. Store it with the regulated provider or in your secure systems; put only claims or hashes on-chain.
Their claim expires or is revoked, so they cannot receive new tokens until re-verified. Policies define whether they can still sell or receive distributions.
Yes, with shared identity registries or reusable credentials — a major advantage of claim-based models.
Yes. Identities can represent companies, funds and custodians, with claims for their status and authorised signers.
With reusable identity or verifiable credentials, yes — if the receiving platform trusts the original issuer.
The issuer’s agent can freeze the holding and follow legal procedures; the compliance design should define this in advance.
NUVZ is the RWA and Web3 engineering brand of ESS ENN Associates (est. 1993). Our team has designed and shipped tokenization platforms for real estate, education loans, solar PPAs, energy, carbon credits, bank deposits and trade documents. About us · Case studies
This article is for general information only and is not legal, tax or investment advice. Token standards evolve — always confirm the current status of an ERC at eips.ethereum.org and take advice from qualified counsel in each jurisdiction before issuing tokens.
