Identity Registry and Compliance Engine

AI-assisted manuscript. Registry records and policy rules below are fictional and contain no personal documents.

Learning objectives

• Separate identity evidence, product permission and transaction policy.
• Model credential issue, expiry, suspension and correction.
• Trace a transfer decision to its actual evidence and rule version.

Two components, different jobs

An identity registry records or references information needed to associate an address with an identity and relevant claims. A compliance engine evaluates a transaction under specified policies using that information and other inputs. Storing a fact is not the same as consuming it at the operation that changes balances.

ERC-3643 describes identity-registry relationships, claim-based verification and a compliance component for permissioned transfers. The specification supplies a technical architecture; it does not decide which legal policy applies to every country or financial instrument. ERC-3643

FATF's virtual-asset work provides international standards and implementation guidance, including information obligations. It must not be turned into a fictional global investor whitelist. Jurisdictional implementation, product eligibility and authorization remain separate questions. FATF

Worked example: an unused suspension

Imagine a teaching registry links wallet W1 to participant P7. Its product-specific permission is valid through day 30. On day 20 an authorized reviewer suspends P7 pending a material evidence update. The user interface immediately displays “suspended,” but a transfer service uses a cached day-10 permission and continues to approve transfers.

The registry writer worked; the control still failed at its consumer. To repair the model, specify what freshness the transaction requires, which revision is authoritative and how the consumer handles unavailable or conflicting evidence. For this teaching policy, unknown or stale permission should enter a review state rather than silently pass.

Suppose the record is corrected on day 22 and permission is restored. Preserve suspension and restoration revisions, the authorized actor, evidence reference and effective scope. Deleting the suspension would make later investigation unable to explain transfers between days 20 and 22.

Evidence reference → authorized review → registry revision
                                            ↓
Transfer request → policy version + current scoped permission
                                            ↓
                        allow / reject / review required
                                            ↓
                        decision evidence linked to operation

A single Boolean called verified cannot explain all these states. The model needs enough structure to distinguish missing identity, expired product permission, suspension, unsupported transaction and a technical outage.

Design the boundary deliberately

Keep sensitive documents outside public transaction records. Use references and access controls appropriate to the process rather than publishing passports or addresses to prove that a review happened. The decision trail should be useful without revealing unnecessary personal details.

Separate participant identity from wallet association. People can change wallets, and one wallet association can be revoked while an underlying person record remains. Conversely, a current identity credential does not grant every product permission. Include product scope, policy revision and effective dates in the decision inputs.

Test the real balance-changing path: normal recipient, expired permission, revoked wallet association, stale evidence, mismatched product, unauthorized registry update and unavailable policy service. Rejecting a forbidden operation must preserve balances and avoid a success event that falsely implies completion. A registry unit test alone does not establish that consumers enforce it.

Common misconceptions

“The registry says suspended, so all transfers are blocked.” Only consumers that read and enforce the current rule make that true.

“Country code proves legal eligibility.” A field does not establish the full evidence or legal conclusion.

“A credential is permanent.” Claims can become stale, expire or be corrected under their governing process.

Risks and limits

This is an educational control model, not an identity service or compliance determination. It sets no legal retention term and processes no real applicant. Legal authority, privacy, review quality and operational recovery require a specific arrangement. Technical fail-closed behavior also needs a documented recovery route so an outage does not become an indefinite unexplained denial.

Exercise and answer

Exercise: A registry is current but a transfer consumer uses a stale cached approval. Is the restriction proven effective?

Answer: No. The balance-changing consumer must use evidence meeting the defined freshness and scope rules. Test that path, including the unavailable-evidence outcome.

Related learning

Continue in engineering with privileged access and reconciliation, and connect this design to onboarding in product architecture.

Source map

erc3643 is a technical specification; fatf-virtual-assets is international standards and implementation guidance. Both were directly read on 2026-10-18. W1, P7, dates and cache rules are original teaching examples. No KYC service, legal policy or real personal data was tested.