Part 1 established that a wallet has to be on the registry before it can hold the token. Getting onto the registry is a KYC and AML process that happens almost entirely off-chain, with a small but load-bearing on-chain footprint. The verification work runs in the issuer's regulated compliance pipeline; the result, an attestation that the wallet is verified, lives on the chain so the token contract can read it without knowing anything about the underlying documentation. This part walks through the flow, the named issuer-agent pairs running it in production, and the refresh cadence.

Off-chain work, on-chain claim

KYC produces a signed claim, not a database row. The documentary work (beneficial ownership, source of funds, FATCA and CRS classification, accredited or qualified-purchaser status, sanctions and PEP screening) happens inside the issuer's or its agent's existing AML pipeline. The agents running it have done the same work for traditional fund subscriptions for decades. What is novel is the output: instead of a row in a transfer-agent system, the pipeline produces a cryptographic attestation written to an on-chain identity contract.

In an ERC-3643 deployment, that contract is the OnchainID. Each claim sits on it as a tuple: claim type (KYC verified, accredited investor, jurisdiction code, sanctions clear), issuing entity, expiry, and signature. The token's compliance layer reads the relevant claims at transfer time. The signing entities are listed in a Trusted Issuers Registry maintained by the issuer or the platform, which means a token can accept verifications from multiple KYC providers (the issuer's own compliance team, a third-party provider, an internal bank desk for in-house clients) without each requiring a separate registry.

The verification flow in five steps

An institution applies. The trigger is a subscription request through the issuer's onboarding portal or its relationship manager. The application captures the prospective wallet address, the legal entity, the beneficial-ownership chain, and the regulatory classifications (US person or non-US, accredited or not, qualified purchaser threshold). For BUIDL, the portal is run by Securitize; for Apollo's ACRED, by Securitize again; for MONY, by Morgan Money; for Franklin Templeton's FOBXX, by Franklin Templeton's own transfer agent.

The KYC provider verifies. Beneficial ownership is documented to the regulator-relevant standard (FinCEN's CDD rule for US persons, MAS Notice 626 for Singapore, equivalent rules elsewhere). Sanctions screening runs against the relevant lists (OFAC SDN, EU consolidated, UK OFSI, MAS targeted). Source of funds is checked for materiality. FATCA and CRS classification is recorded for tax reporting. The work is identical in shape to a traditional fund subscription; the difference is that the output binds to a wallet rather than a brokerage account.

An OnchainID is created or updated. A new institution gets a fresh OnchainID; an institution already verified for another product on the same platform reuses the existing identity and adds a product-specific eligibility claim. The identity-registry pattern means onboarding once and reusing the verified identity for incremental product approvals.

The wallet is whitelisted. The compliance admin (an EOA or multi-sig holding the registry role) links the wallet address to the OnchainID and adds it to the eligible-holder set. The gap between verification completion and on-chain whitelisting is hours, not days, because most issuers run a batched job several times a day.

The institution can now subscribe, hold, and transfer. All subsequent transfers flow through the canTransfer check, which now finds a verified identity, an unexpired claim, and a registered eligibility. The KYC outcome is the precondition; everything in Part 3 is a layered check above it.

Named issuer-agent pairs in production

Securitize for BUIDL and ACRED. Securitize is both the SEC-registered transfer agent and the KYC provider for BlackRock's BUIDL and Apollo's ACRED, and runs the same role for several other tokenised funds. The shared identity layer lets a verified investor subscribe to multiple Securitize-administered funds without redoing KYC.

Morgan Money for MONY. Morgan Money is JPM Asset Management's existing institutional MMF subscription platform, extended to handle the on-chain transfer-agent and KYC role for MONY. An existing Morgan Money client subscribing to MONY does not duplicate the KYC done for a traditional MMF position at the same desk.

Franklin Templeton for FOBXX. Franklin Templeton runs transfer-agent and KYC in-house for FOBXX. The on-chain whitelist sits inside the Franklin Templeton compliance perimeter.

JPM's internal compliance for JPMD. JPMD is a tokenised deposit, so the holder set is narrower (institutional clients of JPMorgan Chase Bank with a deposit relationship). KYC happened when the deposit account was opened; the on-chain whitelist reuses that determination.

Re-verification and ongoing screening

Re-verification is annual for most institutional clients, faster on trigger. The cadence mirrors traditional fund administration: a full refresh once a year, with material-change triggers (beneficial-ownership change, change of control, registered-address change, change of regulatory classification) producing immediate re-verification. The contractual obligation on the holder to notify the issuer of material changes is in the subscription documents.

Sanctions screening is continuous and automated. Every approved wallet is screened against the active sanctions lists daily, and against any newly designated entity within hours of the designation. A hit triggers an immediate freeze of the wallet through the compliance module's freeze function, pending investigation. JPM's internal compliance infrastructure runs this for JPMD; Securitize runs it for BUIDL and ACRED; equivalent pipelines run for every other production tokenised security. The freeze and forced-transfer mechanics that make this work at the contract level are covered in Parts 3 and 5.

The KYC layer is where the regulator gets the comfort that lets the on-chain product exist at all. The claim that ends up on the OnchainID looks small from the chain's perspective, a few signed bytes, but the off-chain pipeline that produces it is the same pipeline a regulated issuer has been running for traditional securities for decades. Tokenisation changes the surface, not the substance.