Tokenised Securities Infrastructure: The Stack Behind Regulated Issuance

Tokenised securities are now a routine product line at major asset managers and a live pilot at several systemically important banks. The headline products — the regulated on-chain money-market funds, the tokenised institutional treasuries, the bank-issued tokenised deposits — rest on an infrastructure stack that is considerably richer than the contract-on-a-chain stereotype suggests. This article walks through the layers of that stack, with a particular focus on the components that determine whether a tokenised securities programme is operable at institutional scale.

This is a companion piece to our tokenisation platform pillar, which addresses the business and regulatory frame for RWA tokenisation. Here the focus is the infrastructure itself: what each layer does, how the layers connect, and what the practical choices look like for a bank, asset manager or specialist issuer building a production-grade capability.

A production tokenised securities infrastructure sits across six identifiable layers.

At the base is the ledger — the distributed substrate on which tokens exist. This can be a public chain (Ethereum, Solana, several others), a permissioned chain (Corda, Besu and similar enterprise stacks), or a hybrid architecture that uses a permissioned ledger for settlement and a public chain for distribution. The choice is determined by the regulatory frame, the counterparty set, the privacy requirements and the interoperability needs of the specific product.

Above the ledger sits the token standard. On EVM chains, ERC-3643 (the "T-REX" standard) is the dominant choice for regulated securities because it embeds compliance hooks into the token contract itself. ERC-1400 remains in production use. On Solana, Token-2022 with transfer hooks provides the equivalent capability. On Corda, the tokenisation SDK provides a state-based representation appropriate to the permissioned-ledger privacy model.

Above the token standard sits the identity and compliance layer. This is the on-chain or off-chain registry that records which participants are eligible to hold or to receive which tokens, the policy engine that evaluates transfer requests against those eligibility rules, and the integration with the off-chain KYC and sanctions infrastructure that sources the underlying attestations. Our identity platform and the Travel Rule architecture piece cover the compliance components at the level of a full identity-and-compliance stack.

Above the compliance layer sits custody. Institutional custody of tokenised securities is functionally similar to custody of any other tokenised asset — HSM-backed keys, multi-signature approval, segregation of duties, audit trails — but the reconciliation to the securities register and the connection to the transfer-agent function are specific to the securities context. Our custody for banks page and custody for asset managers page set out the institutional custody surface.

Above custody sits the trading venue or settlement gateway. This is the component that matches orders (for venue-based models), processes RFQs (for bilateral models), or processes settlement instructions from external venues (for post-trade integration models). The critical property in all cases is delivery-versus-payment against an acceptable cash leg.

At the top is the integration layer — the API, webhook and reporting surface that connects the tokenised-securities platform to the issuer's existing systems, to the transfer agent, to the fund administrator, to the auditor and to the supervisor. This layer is often underestimated in the initial build but is where the operational cost concentrates once the system is live.

The token standard is the single most consequential choice below the business-model layer. It determines what compliance hooks are available, what the upgrade path looks like, and how the token interoperates with the rest of the on-chain ecosystem.

ERC-3643 is purpose-built for regulated securities on EVM chains. Its two-contract architecture separates the token ledger from the identity registry, and its permissioned transfer model enforces compliance checks at the contract level. Transfers between wallets that are not both registered and eligible revert at the contract call, which makes the standard suitable for securities with strict holder restrictions. Our compliance-native fintech API piece discusses protocol-level compliance in more general terms; ERC-3643 is a mature embodiment of that principle.

ERC-1400 predates ERC-3643 and is still in use at several issuers. It offers partitioned holdings, which matter for tokens with restricted and unrestricted tranches of the same instrument, and it has mature tooling around document-hash attestation. The trade-off is that its compliance model is less tightly integrated than ERC-3643's and more often relies on external controller contracts.

Token-2022 on Solana is the programmable-token primitive of the Solana Program Library. Transfer hooks invoked on every transfer allow compliance checks, transfer fees, holder validation and arbitrary custom logic to run at the protocol level. The performance characteristics of Solana — sub-second finality, low transaction costs — make Token-2022 an attractive choice for securities products with high-volume secondary trading. Our Solana platform page covers the specifics of Bridge's Token-2022 integration.

Corda's tokenisation toolkit does not compete at the same level of abstraction as the EVM or Solana standards; Corda's data model is per-transaction state rather than global state, and the tokenisation pattern reflects that. For permissioned banking deployments — particularly those involving central-bank participation or strict counterparty-privacy requirements — Corda is often the right foundation. The Bridge settlement stack uses Corda 5.2 for the settlement-layer components.

The choice among these standards is driven by three questions: where are the holders (which chains will they custody on), what privacy model does the supervisor require, and what is the expected trading volume and latency profile? A public-chain ERC-3643 issuance suits a product with a distributed institutional holder base. A Corda deployment suits an interbank-settlement product where privacy and supervisor participation are paramount. A Solana Token-2022 issuance suits a product designed for high-frequency composability with the broader on-chain ecosystem.

Every production tokenised-securities deployment has an identity registry at its heart. The registry is the mapping from on-chain address to verified off-chain identity, with the attributes — KYC status, jurisdiction, investor qualification, sanctions clearance — attached to each identity.

The design choices around the registry determine the compliance properties of the system.

Centralised on-chain registries store the attribute set on-chain, linked to the address, with a trusted registrar (the issuer, a compliance service provider, or a regulator-approved third party) authorised to write. ERC-3643 uses this model: the ONCHAINID identity contract holds the attested claims and the compliance module reads them at transfer time.

Decentralised identity models use verifiable credentials issued by authorised attesters and presented by the holder at transfer time. This model is earlier-stage in institutional deployment but addresses privacy concerns around on-chain attribute disclosure by keeping the attribute set off-chain.

Hybrid models store a pointer to the off-chain identity on-chain, with the transfer check resolving through a service call to the off-chain identity system. This is common in Corda and permissioned-ledger deployments where the identity system is operated by a trusted member of the network.

The practical requirement is that the registry can answer the question "can address X transfer token Y to address Z?" within the latency budget of a transfer, with a defensible audit trail, and in a way that reconciles to the issuer's off-chain system of record. Our KYC infrastructure pillar sets out the components on the off-chain side that feed the registry.

The policy engine behind the transfer hook is where the business logic lives. For a production-grade tokenised security, the transfer control set typically includes the following:

KYC status — both the sender and the recipient must have current, valid KYC. "Current" is specific to the jurisdiction and the security; a security distributed under Reg S has different refresh requirements than one distributed under a private-placement exemption.

Jurisdiction eligibility — each security has an allow list and a deny list of investor jurisdictions, derived from the prospectus and the regulatory exemptions under which the security was issued.

Investor qualification — accredited, qualified-purchaser or equivalent category, time-bound and re-attested per the jurisdiction's rules.

Sanctions screening — performed at transfer time, not only at onboarding, against the applicable sanctions list. Re-screening at transfer catches the case where a holder becomes sanctioned between onboarding and an outbound transfer.

Lock-up and vesting — for securities with a defined holding period, the contract enforces the lock rather than relying on administrative enforcement.

Ownership concentration — for funds subject to concentration rules or for securities with maximum holder caps, the contract checks the receiver's position before allowing the transfer.

Travel Rule — for transfers above the applicable threshold (typically USD 1,000 under FATF Recommendation 16), the transfer is gated on successful exchange of originator and beneficiary data between the sending and receiving custodians.

The policy engine is either implemented in the token contract itself (the ERC-3643 pattern) or in a permissioned control-layer service that holds the token's mint and transfer authority (a common pattern in custodian-fronted models and in Token-2022 hook implementations). Both patterns work; the trade-off is between the full on-chain enforcement of the contract-level pattern and the operational flexibility of the control-layer pattern.

A tokenised security without a reliable settlement mechanism is, for institutional purposes, a display asset. The settlement layer determines whether the system can operate at scale and within supervisory expectations.

The acceptable cash legs are the same as for tokenised sovereign debt and tokenised funds: wholesale central bank digital currency where available, tokenised deposits from regulated banks, regulated stablecoins from supervised issuers, and — in some permissioned deployments — tokenised reserves acting as a cash-equivalent instrument.

The critical property is atomic delivery-versus-payment. On a single ledger, atomic DvP is a native capability: the contract binds the asset transfer and the cash transfer into one transaction that either completes fully or not at all. Across ledgers — for example, where the security is on Ethereum and the cash leg is on a permissioned settlement ledger — atomic DvP requires either a bridging protocol (hash-time-locked contracts, for example) or a settlement-layer intermediary that holds both legs in escrow until both can be released.

The cross-ledger case is the source of most settlement complexity in the current market. Our cross-border payment infrastructure pillar and the RTGS on DLT pillar both address the cross-ledger settlement question from different angles; the common conclusion is that the direction of travel is toward shared settlement infrastructure that reduces the cross-ledger surface area.

The technical layers described above are tractable. The integration layer — the connection between the tokenisation platform and the issuer's existing operational stack — is where most production projects encounter friction.

Transfer-agent integration. The conventional transfer agent is the legal system of record for the register of holders. In a tokenised model the on-chain register is authoritative for the on-chain holdings, but the transfer agent's record remains authoritative for the legal register. Continuous reconciliation between the two is non-negotiable, and the operational process around breaks must be defined, documented and tested.

Fund administrator integration. The fund administrator calculates the NAV, produces the investor statements and handles subscription and redemption flows. Tokenisation changes the subscription and redemption flow — the fund administrator must be able to issue and burn tokens through the platform — but the NAV calculation and the reporting remain fund-administrator functions. The integration is typically a direct API plus a reconciled reporting feed.

Auditor integration. The auditor needs a clear line of sight from the on-chain state to the financial statements. This is practically a reporting feed, a confirmation of private-key control of the addresses that hold assets, and a walkthrough of the smart-contract logic sufficient to support the auditor's controls testing. Most audit firms have developed a methodology for this; the issuer is expected to provide the evidentiary base.

Supervisor integration. Where the supervisor has a node on the permissioned ledger, supervisory reporting is partially automatic. On public-chain deployments the supervisor receives reporting through existing regulatory-reporting channels, enriched where appropriate with on-chain references.

Bridge's tokenised-securities infrastructure is built as an integrated stack across the six layers above. The tokenisation platform provides the issuance, contract-deployment and lifecycle-management tooling across EVM (ERC-3643 and ERC-1400), Solana (Token-2022) and Corda (tokenisation SDK). The identity platform delivers the identity registry, the policy engine, the KYC integration and the Travel Rule implementation. Bridge's custody layer provides institutional-grade custody across the three ledger families, with HSM-backed keys and configurable approval policies.

For institutions evaluating the build-or-buy decision in 2026, the integrated-stack model substantially reduces the integration surface area. Bridge's build page covers the API and webhook integration points; our consulting team supports the operational integration with transfer agents, fund administrators and auditors, and the contact page is the right starting point for a scoping conversation.