The Registry of Record for Tokenized Securities

The registry of record is the legally authoritative list of who owns what — the register a court, regulator, or liquidator treats as determinative when ownership is contested. In a tokenized structure, that register is either the on-chain record itself, where statute recognizes DLT-based registers, or an off-chain or hybrid register that the on-chain tokens merely mirror. Which one governs is a jurisdiction and documentation question, not a technology preference. Getting it wrong does not degrade the user experience; it puts the enforceability of every investor's position in doubt.

Why the registry question is load-bearing

Most tokenization conversations start with the token. Compliance officers and counsel should start one layer down: when ownership is disputed, which record does the law recognize?

In a dispute — a contested transfer, an estate, a creditor claim, an insolvency — the court does not ask for a blockchain explorer link. It asks for the register of members, the shareholder ledger, the transfer agent's records, or whatever instrument the governing law designates as authoritative. If the tokenized structure never defined that instrument, or defined it inconsistently across the token terms, subscription documents, and the issuer's constitutional documents, the dispute becomes a dispute about which record counts before it can become a dispute about who owns the asset.

This is the same reason jurisdiction is the first structuring decision in tokenized funds: the legal system you issue into determines what your on-chain records are, legally. A token can be the security, evidence of the security, or a receipt pointing at a security recorded somewhere else — the same smart contract can be any of the three depending on where and how the instrument was issued.

The registry of record is therefore a system-of-record decision to be made deliberately, documented in the issuance terms, and enforced operationally — in coordination with qualified counsel in the issuing jurisdiction.

The three registry models

Tokenized structures in production today resolve the registry question in one of three ways.

Model	How it works	Example legal basis	If chain and registry diverge
Native on-chain register	The DLT register is the legal record; token transfer effects legal transfer	Switzerland's ledger-based securities (Art. 973d ff., Swiss Code of Obligations, in force since February 2021); Luxembourg's blockchain laws permitting DLT issuance and transfer of securities (laws of 1 March 2019 and 22 January 2021)	There is no divergence by definition — but a defective transfer on-chain (fraud, coercion, court order) must be remediable on the ledger, so the register needs forced-transfer and correction mechanics built in
Off-chain golden copy with token mirror	A traditional register (often maintained by a registered transfer agent, per Section 17A of the U.S. Securities Exchange Act) is authoritative; tokens are a synchronized representation	The common U.S. pattern for tokenized private securities; Delaware's DGCL §224 separately permits corporate stock ledgers to be maintained on distributed ledgers	The off-chain register wins. The token position is corrected to match — which means the platform must be able to burn, reissue, or reassign tokens without the holder's cooperation
Hybrid with defined reconciliation rules	Both records are maintained; the issuance documents define which record governs which events, and a reconciliation procedure resolves mismatches	Contractual — the hierarchy is written into the token terms and the issuer's constitutional documents	Whatever the documents say — which is exactly why the documents must say it. Undefined precedence is the worst position of the three

Two things follow. First, the "on-chain vs. off-chain" debate is mostly noise. All three models are legitimate; they serve different jurisdictions and instrument types. What is not legitimate is ambiguity — offering documents that imply the token is the security while the SPV's register of members says otherwise, with no written rule on which record controls.

Second, divergence handling is the test of a real registry. Keys are lost, transfers are executed under duress, courts issue orders. A registry of record that cannot express "this transfer is reversed" or "this holder is replaced by their estate" is not a registry — it is a cache. This is one of the areas where legal setup and platform architecture have to be designed together, because the correction mechanics must exist in both the legal documents and the software.

What a defensible registry requires operationally

Whether the authoritative record lives on-chain, off-chain, or in a hybrid, the operational requirements converge. A register that would survive scrutiny in a dispute or a regulatory examination needs:

• Identity-bound entries. Every register entry resolves to a verified legal person — not a wallet address. Addresses rotate, get compromised, and get inherited; legal ownership attaches to persons. The identity-to-address mapping is itself part of the record.
• Corporate-action handling. Distributions, splits, capital calls, redemptions, conversions, and voting entitlements must be computable from the register at a defined record date — which means preserving historical state, not just current balances.
• An immutable audit trail. Every change to the register — who made it, on what authority, under which document — is logged in tamper-evident form. In an examination, the register's history matters as much as its current state.
• Court-order and forced-transfer capability. A register that cannot execute a court-ordered transfer, freeze a sanctioned position, or replace a deceased holder's entry cannot serve as the legal record. The capability must be permissioned, logged, and governed — but it must exist.
• Backup and recovery. The authoritative record must survive infrastructure failure with defined recovery objectives, and the recovery procedure must be documented and tested. An unrecoverable register is a structural default waiting for a trigger.

None of this is exotic — transfer agents and fund administrators have done it for decades. Tokenization does not remove these requirements; it changes where they are implemented, and it removes the excuse of slow reconciliation cycles, because the register can now be updated and verified continuously.

Eligibility is register data, not a separate spreadsheet

KYC, AML screening, accreditation status, and residence are usually treated as an onboarding gate: check once, admit the investor, move on. In a cross-border tokenized structure, that is not enough — eligibility is a property of each register entry, continuously maintained.

The reason is mechanical. Transfer restrictions are enforced at transfer time: is the buyer eligible in their jurisdiction, is the holding-period condition met, does the transfer breach an investor-count or concentration limit? Those checks can only be automated if the eligibility data lives with the register — attached to the entries the transfer would modify — rather than in a compliance spreadsheet reconciled quarterly.

Cross-jurisdiction operation raises the bar: an investor eligible at subscription may become ineligible on a sanctions update or a change of residence, and the register should surface that before the next corporate action or transfer, not after. Automating KYC/AML refresh and sanctions screening as data feeds into the register is what makes multi-jurisdiction transfer control workable — and what regulators increasingly expect to see evidenced, not asserted. How those controls extend into secondary transfers is covered in our approach to controlled transfer workflows and liquidity strategy.

Why regulated entities want to own the registry layer

If the register is the authoritative record of ownership, its failure modes are failure modes of the asset, not the software. That reframing is driving two procurement requirements now common in regulated evaluations.

Source-code ownership. If the registry runs on vendor SaaS and the vendor fails, is acquired, or exits the market, what happens to the authoritative record? Data export is not an answer — an exported CSV without the software that enforces transfer restrictions, computes corporate actions, and maintains the audit trail is not a functioning register. Regulated entities increasingly require source-code access or ownership for the registry layer specifically, so that vendor failure cannot orphan the record. Exit planning for outsourced critical functions is a standing supervisory expectation in most major jurisdictions, and the registry is about as critical as a function gets.

Deployment control and data residency. Register data is investor personal data plus ownership data — the categories most likely to be subject to data-protection and localization rules in the jurisdictions where regulated firms operate. Running the registry on-premise or in the operator's own cloud perimeter keeps register data in-region, keeps access governance inside the regulated entity, and gives examiners a system the firm can actually evidence and control. The broader case for client-controlled deployment — including what "on-premise" does and does not mean — is laid out in our on-premise tokenization platform overview.

Neither requirement is about distrust of vendors. It is about the specific character of the registry: every other system in the stack can be replaced with disruption; the authoritative ownership record cannot be allowed a single external point of failure.

One system of record, or five vendors and a reconciliation problem

The final question is whether registry, compliance, and settlement run as one system or as a chain of vendors — onboarding provider, registry provider, token platform, payments rail, reporting tool — stitched together with APIs and nightly reconciliation.

The multi-vendor chain can work. But every seam is a place where records can disagree: the KYC system flags an investor as ineligible while the registry still shows them as a holder; the settlement rail shows a payment the register has not recorded; token balance and register entry diverge and neither system is authorized to correct the other. In a normal software stack, those are bugs. In a registry-of-record stack, reconciliation gaps are legal gaps — periods during which the authoritative record is arguably wrong and provably unverified.

A unified system of record — where eligibility data, register entries, transfer controls, and settlement status are states of one system rather than messages between systems — eliminates the seams rather than monitoring them. Custody remains a genuine external boundary in most structures (covered separately in the digital asset custody infrastructure guide), but the register, its compliance data, and its transfer logic have no good reason to live in three places.

This is the architecture Asset Haus deploys as tokenization infrastructure for private capital markets — registry, compliance data, and transfer control as one client-controlled system, with legal setup coordinated with qualified counsel in the issuing jurisdiction. Across 32 deals structured and $200M+ facilitated in 9+ jurisdictions, the registry-of-record decision has been part of the structuring workstream from day one, not a post-launch cleanup. Examples of how that decision plays out by asset class and jurisdiction are in our case studies.

FAQ

What is the registry of record in tokenization?

It is the legally authoritative record of who owns the tokenized securities — the register a court or regulator treats as determinative. Depending on the jurisdiction and structure, it is either the on-chain register itself (where statute recognizes DLT registers), a traditional off-chain register that tokens mirror, or a hybrid with documented precedence rules.

Is the blockchain the legal record of ownership?

Only where the law says so and the issuance is structured accordingly — for example, ledger-based securities under Art. 973d ff. of the Swiss Code of Obligations, or DLT issuance under Luxembourg's blockchain laws. In most other structures, including the common U.S. transfer-agent pattern, an off-chain register is authoritative and the tokens are a synchronized representation. The answer is jurisdiction-specific and should be confirmed with qualified counsel.

What happens if the token balances and the register disagree?

Whatever the issuance documents say happens — which is why they must say it. In an off-chain-golden-copy model, the register wins and token positions are corrected to match. In a native on-chain model, correction happens on the ledger through built-in forced-transfer mechanics. A structure with no defined precedence rule has a latent legal defect.

What happens if the platform vendor shuts down?

If the registry runs on vendor-hosted SaaS with no source-code rights, the authoritative ownership record is at risk of being orphaned — a data export alone does not preserve a functioning register. This is why regulated entities increasingly require source-code ownership and on-premise or client-cloud deployment for the registry layer, with documented continuity and wind-down procedures.

Can a court force a transfer on a tokenized register?

A defensible registry must support court-ordered transfers, sanctions freezes, and estate successions whether or not the holder cooperates or their keys are available. The capability must be permissioned, fully logged, and reflected in both the legal documents and the software.

---

Evaluating what your registry of record should be — and where it should run? Start with the readiness assessment.