EU-Compliant Tokenized Securities: Smart Contract Architecture<\/a><\/strong>\u00a0pillar.<\/p>\n\n\n\nNo platform owes all of it.<\/strong> The first section is about which of the three regimes actually reaches you.<\/p>\n\n\n\n1. Which regime reaches you<\/strong><\/h2>\n\n\n\nApplies to every reader. Answer it against the operating entity's licence, not against the activity it performs.<\/em><\/p>\n\n\n\nThe anti-money-laundering regime binds obliged entities<\/strong>, and Article 3 lists them. Investment firm, credit or financial institution, payment or e-money institution, fund manager, crypto-asset service provider, crowdfunding provider. An issuer of securities is not on the list. A genuinely unlicensed pure issuer is outside the regime and is caught only if it is independently one of the listed types. The moment any licence is held \u2014 venue, dealer, fund manager \u2014 it attaches in full.<\/p>\n\n\n\nTargeted financial sanctions bind everyone<\/strong>, irrespective of obliged-entity status. That is a separate regime with its own basis, and it is why the screening control in section 6 is built in every lane and cited differently depending on who you are.<\/p>\n\n\n\nInvestor classification binds anyone distributing to EU clients<\/strong>. And the tier it produces retail, professional on request, per-se professional, eligible counterparty is read by more regimes than any other single fact about an investor.\u00a0eIDAS 2.0 relying-party duties<\/strong>\u00a0attach the moment you accept an EU Digital Identity Wallet attribute as identification.<\/p>\n\n\n\nSo the registry is built regardless. What changes with the licence is the citation against each control, and an audit map that grounds a control in an anti-money-laundering Article for an entity outside Article 3 is a defect in the artefact the regulator reads.<\/p>\n\n\n\n
2. One instance, platform-wide \u2014 regulation decides this, not preference<\/strong><\/h2>\n\n\n\nApplies to any operator running more than one tokenized asset. For a single asset the question does not arise yet; it will.<\/em><\/p>\n\n\n\nEvery other layer in this architecture is one-per-asset. The identity layer is not, and it is not an engineering choice:<\/p>\n\n\n\nComponent<\/th> What forces one instance<\/th><\/tr><\/thead> The investor record and its due-diligence claims<\/td> Article 19(1)(a)<\/strong> makes the trigger the business relationship<\/strong>, not the product. Article 20's refresh cadence and Article 21's \"do not carry out the transaction\" are per customer. Per-asset identity puts one investor on several refresh clocks, and lets a lapse on one asset coexist with continued trading on another \u2014 the exact breach<\/td><\/tr>The classification tier<\/td> Classification is per client. One classification, many regimes<\/td><\/tr> Trusted issuers and claim topics<\/td> eIDAS Article 45d(4)<\/strong> makes revocation of a qualified attestation final. It has to kill transferability everywhere at once<\/strong><\/td><\/tr>The restriction store<\/td> A listing is against a person<\/strong>, not a product. Per asset, one list hit becomes several writes with a window between them, during which the person is stopped on one asset and exiting through another<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nTwo costs land on the choice, and both answers are wrong if left unstated.<\/strong>\u00a0<\/h3>\n\n\n\nWith a shared registry, one lapsed due-diligence record freezes that investor across every asset simultaneously \u2014 correct, and a blast radius nobody has sized against the refresh-workflow commitment the gate article says expiry requires. With per-asset identity, the lapse freezes one asset while the investor keeps transacting on another, which is the breach. Pick deliberately.<\/p>\n\n\n\n
\"One per platform\" is not \"one per chain.\"\u00a0<\/strong><\/h3>\n\n\n\nAn operator whose issuance runs on a public chain and whose venue runs on a permissioned one has two deployments of every row above, and no atomic write across them. No contract closes that. What the design owes is a named sync mechanism, a stated worst-case propagation lag, and an owner, the restriction store anchors a list version and the version it swept to so the lag is at least measurable.<\/p>\n\n\n\n
3. What the record holds, and what it must not<\/strong><\/h2>\n\n\n\nApplies to every registry. This section is a data-protection constraint before it is a design.<\/em><\/p>\n\n\n\nIdentityRegistry<\/code>\u00a0resolves in\u00a0two hops, not one<\/strong>. a wallet holds a binding to a person, and the person holds the record \u2014 the classification tier, the jurisdiction, natural-or-legal, the reporting identifiers, the review horizon, and a set of claims each carrying an issuer and an expiry.\u00a0<\/p>\n\n\n\n\npersonIdOf()<\/code>\u00a0is the first hop and the join every other contract uses \u2014 the restriction store, the managers' register, wallet recovery.\u00a0<\/li>\n\n\n\ntierOf()<\/code>\u00a0and\u00a0jurisdictionOf()<\/code>\u00a0are the second hop, done for you, and are what the covenant predicates and the subscription path read.<\/li>\n<\/ul>\n\n\n\nThe second hop is a compliance requirement, not an implementation taste, and getting it wrong is a control failure before it is a privacy one.<\/strong>\u00a0The registry shape most of this sector inherits keys by wallet, because the pattern it descends from parks the attributes in a per-investor identity contract and leaves the registry holding a pointer. Drop that per-person contract and there are good data-protection reasons to. Since a contract whose storage and address outlive an erasure request is exactly what the right to erasure cannot tolerate and the tempting move is to keep the wallet-keyed registry and push the attributes into the wallet row.\u00a0Do not.<\/strong>\u00a0<\/p>\n\n\n\nAttributes stored per wallet with no cross-wallet check mean one investor can hold two answers: wallet A registered as Germany\/retail, wallet B as Ireland\/professional, same human, nothing objecting. The prospectus exemptions count\u00a0people<\/em>\u00a0\u2014 a per-Member-State money threshold and a 150-non-qualified-person headcount \u2014 so that is a subscriber choosing whichever Member State still has room, or the classification that skips the headcount entirely. Key the record by the person and the divergence is unrepresentable rather than merely checked: registering a second wallet against an existing person either matches the record or reverts.<\/p>\n\n\n\nPerson-keyed storage does not cost you the standard's read surface, and conflating the two is why this looks like a harder choice than it is. <\/strong><\/h3>\n\n\n\nERC-3643's identity registry is consulted\u00a0by wallet<\/em>\u00a0\u2014 is this address verified, what identity and what country does it resolve to. That is the shape of the read, not a statement about where attributes live. <\/p>\n\n\n\nThe wallet-keyed calls resolve wallet \u2192 person \u2192 attribute and write through to the person record, reverting on any divergence. So the standard's surface sits over the person key without weakening it. Where the standard asks for more than a read \u2014 typing the registry against a deployed per-investor identity contract, and carrying the investor's country on-chain as a numeric code \u2014 we record a\u00a0declared deviation<\/strong>\u00a0with its reason rather than leaving a reader to discover it.\u00a0<\/p>\n\n\n\nA third falls out of the same reasoning: the standard offers an optional storage contract the registry can delegate to, explicitly shareable across several tokens, and we decline it<\/strong>. One person register shared across issuers\u00a0is<\/em>\u00a0the cross-issuer correlation problem, not an efficiency.\u00a0How you decline matters as much as declining.<\/strong>\u00a0The functions are present and refuse: the setter reverts a named error, the getter answers zero. Omitting them would have been the tidier-looking choice and the worse one \u2014 a refusal leaves a readable trace a venue can act on, while a function that simply is not there fails inside the caller's tooling with nothing on-chain to explain why. The second of those is the same on-chain-attribute question the data-protection article puts to the data-protection officer, and the standard answers it in the direction that article treats as the one to justify.<\/p>\n\n\n\nThe first of those is a substitution, and it is worth being precise about what replaces what.\u00a0<\/strong><\/h3>\n\n\n\nThe standard types its registry against\u00a0IIdentity<\/code>\u00a0\u2014 a contract deployed per investor, holding that person's attestations at its own address. This design deploys no such contract.\u00a0identity()<\/code>\u00a0answers a stable per-person handle: derived from the person identifier, comparable across calls, and never callable. The attestations it would have held are the claims on the person record, reached through the registry rather than through an address of their own.<\/p>\n\n\n\nThe cost is an interoperability one, and it is deliberately loud.\u00a0<\/strong><\/h3>\n\n\n\nA venue whose tooling takes the handle and calls it breaks against this design immediately and visibly, which is why a non-callable handle was preferred to returning a zero address, the same reasoning as the refusing setter above. It is a declared deviation and a disclosure item, not a silent narrowing. Why the registry holds the record rather than a per-investor contract is the erasure question, and the data-protection article is where it is worked through.<\/p>\n\n\n\n
What is on-chain is a pointer, hashes and attestation references \u2014 never a direct identifier.\u00a0<\/strong><\/h3>\n\n\n\nThat is a minimization rule, not an exemption. The wallet key the claims hang off is itself personal data once bound to a verified record, so the registry is inside the data-protection regime whatever the claim payload looks like. Which further fields belong on the record and whether a gate could read a derived boolean instead of the attribute is a per-field decision for the data-protection officer, covered in the data-protection article. <\/p>\n\n\n\n
Three rules are settled regardless.\u00a0Events emit the wallet and an opaque hash and nothing else<\/strong>, because storage can be deleted and a log cannot.\u00a0One wallet per investor per issuer<\/strong>\u00a0\u2014 address reuse across issuers is the linkability problem no erasure measure reaches. And\u00a0the eligibility check fails closed on a broken binding<\/strong>. A wallet whose person has gone leaves the required-claim set empty, and an empty required set passes everything. So the resolution failure has to be its own refusal rather than a silent one.<\/p>\n\n\n\n4. Onboarding \u2014 the due-diligence limbs that end up as claims<\/h2>\n\n\n\n Applies in full to obliged entities. For an unlicensed issuer the screening survives on sanctions grounds and the rest is a commercial counterparty-risk control.<\/em><\/p>\n\n\n\nArticle 19(1)(a)<\/strong> makes establishing a business relationship the trigger for full customer due diligence, with no value threshold. Every investor you onboard is a business relationship from the first subscription \u2014 which is why there is nothing to count on-chain, and why the value-based triggers elsewhere in Article 19 are not built.<\/p>\n\n\n\nArticle 20<\/strong> then sets the measures: identification and verification before the customer holds anything (20(1)(a)); the purpose and intended nature of the relationship; source of funds and source of wealth to risk; ongoing monitoring of transactions against the risk profile; and periodic refresh on a documented, risk-tiered cadence. Article 21<\/strong> requires that where due diligence cannot be completed, the relationship is not established or continued, the transaction is not carried out, and a suspicious-transaction report is considered.<\/p>\n\n\n\nEnhanced due diligence<\/strong> is triggered by high-risk third countries, politically exposed persons \u2014 a status continuing for at least 12 months after leaving office \u2014 cross-border correspondent relationships with third-country crypto-asset service providers, and unusually complex or large transactions with no apparent purpose. Article 34<\/strong> requires senior-management approval to establish or continue such a relationship. The correspondent-crypto-firm trigger is new in this Regulation and is the most-missed item in onboarding flows.<\/p>\n\n\n\nOn-chain<\/strong><\/h3>\n\n\n\nAll of the above is an off-chain determination written back as a claim. The identity service calls\u00a0setClaim()<\/code>\u00a0with a topic, a value and an expiry;\u00a0ClaimTopicsRegistry<\/code>\u00a0holds the set of topics required before a wallet is eligible, as a baseline plus per-jurisdiction additions through\u00a0requiredTopics()<\/code>. One design point does the compliance work:<\/p>\n\n\n\n\nThe refresh cadence becomes the claim's expiry, and the expiry is mandatory at the write.<\/strong> Articles 20 and 21 together mean the eligibility claim carries a validity window, and the gate treats an expired claim exactly as a missing one. setClaim()<\/code> therefore rejects a zero or past expiry and refuses anything further out than a governance-set maximum: a registry that accepts \"never expires\" has made the refresh cadence opt-in for whoever writes the claim, and one issuer passing zero turns the control off for every wallet it attests. Expiry then fails closed on a live position, which is what gives the refresh workflow a service-level commitment.<\/li>\n<\/ul>\n\n\n\nPartial.<\/strong> The determination behind each claim \u2014 tier, risk rating, beneficial ownership \u2014 is made off-chain and written back as the claim the gate reads.<\/p>\n\n\n\nOff-chain.<\/strong> The due diligence itself, all of it. The risk-tiered refresh policy, and senior-management approval on every enhanced case.<\/p>\n\n\n\n5. Trusted issuers, and a revocation with no undo<\/strong><\/h2>\n\n\n\nApplies to any platform accepting third-party attestations \u2014 a KYC provider, a qualified trust-service provider, or the EU Digital Identity Wallet.<\/em><\/p>\n\n\n\nThe identity record does not attest anything itself. It holds claims signed by issuers the platform trusts, and TrustedIssuersRegistry<\/code> is where that trust is recorded \u2014 registerIssuer()<\/code> names an issuer against the claim topics it may attest, and nothing else. eIDAS 2.0 supplies most of the rules:<\/p>\n\n\n\nArticle 5b<\/strong>\u00a0makes attributes presented from the EU Digital Identity Wallet acceptable identification, and imposes relying-party duties. Registration,\u00a0pre-declaring exactly which attributes you consume<\/strong>\u00a0(Article 5b(3)), updating on change, identifying yourself at each interaction, and authenticating what is presented. The pre-declared set is also the data-minimization control.<\/p>\n\n\n\nArticle 45d(4)<\/strong> is the one that shapes the contract: revocation of a qualified attestation is final and shall never be reversed.<\/p>\n\n\n\nWhat is verified on-chain, and what is not \u2014 state this before the revocation design, because it is routinely overclaimed.\u00a0<\/strong><\/h3>\n\n\n\nNo contract verifies an attestation signature or a selective-disclosure presentation. It cannot: verifying a presentation on-chain means writing the presented attribute where anyone can read it. It's permanent publication of personal data, which is the outcome the data-protection article treats as the one to design out.\u00a0The claims service verifies the signature off-chain.<\/strong>\u00a0<\/p>\n\n\n\nWhat the chain holds is the two things a contract can actually decide. <\/p>\n\n\n\n
A\u00a0write gate<\/strong>\u00a0\u2014 a claim is only accepted from an issuer the trust registry currently names for that topic.<\/p>\n\n\n\nA\u00a0revocation read<\/strong>, because issuer trust is re-checked on every read of the claim rather than at the write. <\/p>\n\n\n\nSo a revocation invalidates outstanding claims without touching a single claim record, and the transfer that comes after it fails. An audit map that reads \"signature verified on-chain\" describes a control nothing implements.<\/p>\n\n\n\n
On-chain<\/strong><\/h3>\n\n\n\nWe build<\/strong>\u00a0two revocation paths, because the Article does not say which the issuer meant.\u00a0<\/p>\n\n\n\nrevokeProspectively()<\/code>\u00a0stops the issuer attesting from now on but leaves claims issued earlier standing.<\/p>\n\n\n\nrevokeRetroactively()<\/code>\u00a0invalidates everything the issuer ever attested.\u00a0<\/p>\n\n\n\nisTrustedFor()<\/code>\u00a0takes the claim's issue time as an argument for exactly that reason.\u00a0<\/p>\n\n\n\nThere is no un-revoke.<\/strong>\u00a0A holder re-verified after a revocation receives a\u00a0new<\/em>\u00a0claim from a currently trusted issuer, not a restored one.<\/p>\n\n\n\nTwo further eIDAS limbs constrain the shape rather than the data.\u00a0Article 45h<\/strong>\u00a0requires logical and functional separation for anyone issuing attestations. If the same entity both issues and consumes claims, that is a service-boundary requirement, and it argues against one investor record shared across an issuer entity and a venue entity.\u00a0Article 5a(16)<\/strong>\u00a0forbids the attestation issuer from being able to track or correlate a user's transactions. Which rules out any design where the claim issuer is called back on every transfer. Verification happens against what was presented and stored, never by pinging the issuer per movement.<\/p>\n\n\n\n6. The restriction store \u2014 every stop, one flag<\/strong><\/h2>\n\n\n\nApplies to every platform. Sanctions bind regardless of licence; this is the one control no client scopes out.<\/em><\/p>\n\n\n\nArticle 20(1)(f)<\/strong> requires re-screening on every sanctions-list update, of the customer record and<\/strong> every beneficial-owner record, across the whole existing base. Article 75<\/strong> requires refraining from executing a suspicious transaction where possible. Neither Article says where the resulting block lives, and the answer decides whether the tipping-off prohibition is real or cosmetic.<\/p>\n\n\n\nWe build<\/strong>\u00a0one store,\u00a0RestrictedPartyRegistry<\/code>, and it holds\u00a0every<\/strong>\u00a0reason a wallet may not move. A sanctions listing, a suspicion block, a probate hold, a court attachment, a lost-key hold, an operational hold pending investigation. All set the same flag and emit the same event shape. There is no class field and no reason code anywhere in the contract. Every entry carries a mandatory opaque case reference. <\/p>\n\n\n\nFour reasons it is not a flag on the identity record:<\/strong><\/h3>\n\n\n\n\nScope.<\/strong> A listing is against a person, so it is keyed by personId<\/code> and follows them across every wallet and every asset. A second, wallet-keyed map covers addresses that were never onboarded \u2014 a counterparty flagged by chain analytics has no investor record to hang a flag on.<\/li>\n\n\n\nRemovability.<\/strong> Every anti-money-laundering rule in this architecture is removable, because an unlicensed issuer correctly drops them. Sanctions are not removable. Bundle the sanctions block into the removable claim set and the issuer who correctly drops the AML modules silently drops sanctions with them. So the token and the distribution agent each take the store as a constructor argument that rejects a zero address, and read it above the module list.<\/li>\n\n\n\nLifecycle.<\/strong>\u00a0A claim is revoked by its issuer on a cadence. A listing is list-driven, instant on the existing base, blocks receive as well as send, and never expires and only a delisting clears it.<\/li>\n\n\n\nObservability \u2014 the decisive one.<\/strong> Contract storage is public. If a sanctions listing lived in one slot, a lapsed refresh in another, and a suspicion block in a third, an observer would read the three slots and know which class fired, whatever the revert code said. One store, one flag, and a population that also holds the boring majority is where the inference actually dies.<\/strong> A store named for sanctions would defeat that on its own \u2014 membership would be the disclosure.<\/li>\n<\/ul>\n\n\n\nThree operating properties follow<\/strong><\/h3>\n\n\n\nTwo write roles, one flag<\/strong><\/p>\n\n\n\nThe screening vendor's key and the transfer agent's registrar key both write the same entry, because the vendor has no business recording a death and the registrar has no business running a list. Release is governance-only for both<\/strong>, since placing a restriction fails safe and lifting one releases a frozen position.\u00a0<\/p>\n\n\n\nA permitted-destination carve-out is mandatory<\/strong><\/p>\n\n\n\nThe forced-transfer path reads the store too. Without it, the restriction meant to route value to a freezing order's own seizure destination, or to the heir who ends a probate hold, would block them instead \u2014 it relieves only the sender limb, and a restricted party may never be a recipient.<\/p>\n\n\n\n
A stale sweep blocks entry, not exit<\/strong><\/p>\n\n\n\nScreeningIsStale()<\/code>\u00a0fails mints when the whole-base sweep has fallen behind the list, and leaves existing holders trading, because freezing the book over an operational lag is a self-inflicted outage on people who did nothing.<\/p>\n\n\n\nA screening hit is a restriction, never a claim and the claim catalogue enforces that by refusing to take the number back.\u00a0<\/strong><\/h3>\n\n\n\nThe tempting shortcut adds a \"sanctions screened\" claim topic recording pass or fail beside the record. But this rebuilds the two-slot leak exactly: anyone can publicly read the raw claim, and an eligibility check that reverts and names the missing topic reveals which question the wallet failed. So the design retires the topic that once held it \u2014 a retired number can never be required again, nothing un-retires it, and nothing reassigns it. Because a stale claim resolving to nothing fails closed while one resolving to some later topic fails open. A hit is written to the restriction store. A clear is written nowhere at all.<\/p>\n\n\n\n
What the forced-transfer path actually runs, since the carve-out above depends on it.\u00a0<\/strong><\/h3>\n\n\n\nIt is not \"the transfer gate\" wholesale, reads the restriction store on both parties in the mandatory layer, checks the\u00a0recipient's<\/strong>\u00a0eligibility, and runs the rule modules. This deliberately does not re-check the\u00a0sender's<\/em>\u00a0eligibility, a seizure ordered against a holder whose due-diligence record has lapsed is exactly the case the order exists for, and blocking it would make an administrative lapse a defence against a court.<\/p>\n\n\n\nRe-pointing the store is three calls, not on<\/strong>e. The gate adapter, the token and the distribution agent each hold a reference. Do one and not the others and two stores are live with different contents, which is the observability failure the consolidation exists to end.<\/p>\n\n\n\nOne thing the store does not answer.<\/strong>\u00a0Its opacity answers the tipping-off prohibition. It does not answer whether data-protection law's criminal-offence-data rule permits a permanent public record that blocks a person \u2014 especially after someone corrects a false-positive match. The data-protection officer must make that decision before the first live screening run, and the data-protection article discusses it.<\/p>\n\n\n\n7. Fan-out \u2014 the question the diagram hides<\/h2>\n\n\n\n Applies from the second asset onward. Decide it before the second asset deploys, not after.<\/em><\/p>\n\n\n\nThe token calls the identity registry and the rule engine independently, and the rule engine holds no identity reference. Every module that needs an identity attribute wires its own. That is a star, not a chain, and it is a fan-out. A revoked claim, a lapsed record, or a new listing has to reach every module-held reference on every asset. On a single token, propagation is immediate by construction. Across several, it is several writes, and\u00a0whether they must be atomic is a decision with a wrong default in both directions<\/strong>. A partial propagation leaves the same investor revoked on one asset and live on another, which is the Article 21 and Article 45d(4) failure in one. A fully atomic propagation across chains does not exist. State the mechanism, the worst-case lag, and the owner.<\/p>\n\n\n\nOne fan-out in this design\u00a0is<\/em>\u00a0atomic, and it is worth knowing which.<\/strong>\u00a0An erasure request has the same shape as a revocation. One person can leave residue in many contracts, so a dedicated coordinator handles it: it reads the person's wallet list from this registry, calls every registered store, and erases the registry last, because the address-keyed stores cannot expand a person identifier themselves. Any store refusing stops the whole run. That is the opposite default from claim propagation, and deliberately. A stale claim on one asset is a window you can close, while a half-erased person is a state nobody can describe to a supervisor. Note the wiring risk it creates. A store that exists but was never registered as a target is\u00a0silently skipped<\/strong>, so the target list belongs in the deployment checklist beside the module list.<\/p>\n\n\n\n8. Reporting \u2014 what the indexer has to be able to answer<\/h2>\n\n\n\n Applies to obliged entities.<\/em><\/p>\n\n\n\nArticle 69<\/strong>\u00a0requires a suspicious-transaction report for every suspicion including attempted transactions, filed personally by a named compliance officer (Article 69(6)<\/strong>). And requires requests from the financial intelligence unit to be answered within five working days, or under 24 hours where urgent. Nothing on-chain files a report. What the 24-hour limb does is set the query latency the event indexer has to support against historical transfer, block and restriction events, the structured record the response is answered from.<\/p>\n\n\n\nArticle 77's five-year retention is the one limb that reaches back into \u00a77.<\/strong>\u00a0Someone can call the coordinator described above inside the retention window, and it must refuse. The legal-obligation basis documents the five years as a retention period, which is what makes refusal lawful rather than obstructive. The data-protection article works through the reconciliation.<\/p>\n\n\n\nInnBlockchain<\/strong> is an RWA tokenization development company building this architecture end to end. Scope your build<\/a>.<\/strong><\/p>\n\n\n\nAt a glance<\/h2>\n\n\n\nObligation<\/th> On-chain<\/th> Partial<\/th> Off-chain<\/th><\/tr><\/thead> Record shape<\/strong><\/td>Wallet \u2192 person \u2192 record.<\/strong> Attributes on the person; the wallet holds only a binding. A second wallet either matches the person's record or reverts<\/td>\u2014<\/td> The prospectus headcount and the money threshold both count people<\/em>, so this is a control, not a preference<\/td><\/tr>AMLR Art 3<\/strong> \u2014 obliged entities<\/td>Decides the citation, not the build<\/td> \u2014<\/td> Verify against the licence, not the activity<\/td><\/tr> Art 19(1)(a)<\/strong> \u2014 business-relationship trigger<\/td>Claim must exist before any transfer; nothing to count<\/strong><\/td>\u2014<\/td> Full due diligence before any claim is written<\/td><\/tr> Art 20; Art 21<\/strong> \u2014 measures, refresh, inability to complete<\/td>setClaim()<\/code> \u2014 expiry mandatory, capped at a governance maximum; expired = missing; fails closed<\/td>Purpose, source of funds and wealth, ongoing monitoring<\/td> Risk-tiered cadence with a service-level commitment<\/td><\/tr> Art 34<\/strong> \u2014 enhanced due diligence<\/td>Risk-tier claim<\/td> Determination<\/td> Senior-management approval<\/td><\/tr> Arts 52, 53, 61<\/strong> \u2014 beneficial ownership<\/td>\u2014<\/td> Determination written back as a claim<\/td> Two-track determination, ownership and control<\/td><\/tr> Art 20(1)(f); Art 75; sanctions<\/strong><\/td>RestrictedPartyRegistry<\/code> \u2014 one flag, every stop, opaque case ref; constructor-mandatory; read on the forced-transfer path too; stale sweep blocks mints only. A hit is never a claim topic<\/strong><\/td>Whole-base re-screen on every list update<\/td> Owner and worst-case lag for the sweep<\/td><\/tr> eIDAS Art 5b, 5b(3)<\/strong><\/td>Trusted-issuer write gate; pre-declared claim set. The attestation signature is verified off-chain<\/strong><\/td>Signature and presentation verification by the claims service; relying-party registration<\/td> \u2014<\/td><\/tr>