Real-World Asset Tokenisation: A Platform View for Regulated Institutions

Real-world asset tokenisation has moved decisively out of the conference keynote phase and into live institutional infrastructure. Major regulated issuers — Franklin Templeton with its on-chain money-market fund (BENJI), BlackRock with the BUIDL institutional treasury fund, Ondo Finance with OUSG and a growing set of bank-issued tokenised deposits — now operate products that settle, reconcile and compliance-check on shared ledgers. Estimates of the outstanding tokenised real-world asset base sit in the low tens of billions of dollars as of 2026, a fraction of the global securities and fund complex but a credible foothold, and growth rates over the last twenty-four months have been meaningfully faster than the total asset base of the host chains.

The shift from pilot to product has changed the conversation. The question for banks, asset managers, custodians and treasurers is no longer whether tokenisation is a real operating model but how a tokenisation platform should be designed, what regulatory and operational constraints it must absorb, and where the platform sits in relation to existing systems of record, settlement rails and compliance infrastructure. This pillar article sets out the tokenisation platform stack from the perspective of regulated institutions. It is not a retail or speculation primer. It addresses the architectural questions that determine whether a tokenisation programme can be operated at scale, within licence, and against the kind of internal-audit and supervisory expectations that apply to traditional securities and fund administration.

Bridge's tokenisation platform is organised around this stack. The discussion below references Bridge's implementation where relevant but is framed to be useful to any institution evaluating a build-or-buy decision, regardless of the specific vendor shortlist.

A tokenisation platform is often described as a smart-contract factory. That description is accurate but incomplete. The smart-contract layer is a component. The platform is the full set of services required to bring a real-world asset onto a ledger, keep its representation synchronised with its off-chain legal form, enforce the compliance constraints that apply to its holders and its transfers, settle trades in it against an acceptable cash leg, and produce the records that auditors, supervisors and fund administrators need.

Five capability groups define the platform.

Issuance is the first. This covers the legal structuring, the token design (fungible or non-fungible, divisible or indivisible, transfer restrictions, voting rights), the deployment of contract instances and the minting process. Issuance is tightly bound to the prospectus, trust deed or equivalent legal document that governs the asset. A tokenisation platform that treats issuance as a pure software operation misses the point: the token is a representation, and the representation must remain legally coherent with the underlying instrument through its full lifecycle.

Custody is the second. A tokenised asset is a bearer instrument for operational purposes: control of the private key is control of the holding. Institutional custody — HSM-backed key management, multi-signature approval policies, audit trails, segregation of duties — is non-negotiable for regulated holders. The custody layer also connects to the traditional custody chain: the on-chain holding has to reconcile to the off-chain register of members, the transfer agent record or the equivalent system of record. Our article on how banks evaluate digital asset custody providers treats the vendor-selection side of this in detail.

Compliance is the third. Regulated tokens are not free-transfer instruments. Transfers between holders have to satisfy investor qualification (accredited, qualified-purchaser, jurisdiction of residence, KYC status), ownership limits (for funds subject to concentration rules), holding-period restrictions (for restricted or lock-up securities) and sanctions screening. The platform enforces these checks in the transfer path, either at the smart-contract level through transfer hooks and allow-lists, or at a control-layer service that sits between the user and the contract. The identity and compliance stack that underpins this is as important as the token contract itself.

Secondary market is the fourth. A tokenised asset without a secondary market is a novelty. Secondary trading requires a venue (an order book, an auction mechanism, a request-for-quote interface or a bilateral settlement mechanism), a matching engine if applicable, and — critically — delivery-versus-payment settlement against an acceptable cash leg. The platform is responsible either for operating the venue or for integrating cleanly with third-party venues, and in either case for ensuring that every executed trade settles atomically with its cash counterpart.

Settlement is the fifth. Delivery-versus-payment on tokenised assets requires a cash leg that lives on the same ledger or on a ledger interoperable by design. The options are a wholesale central bank digital currency, a tokenised deposit from a regulated bank, a regulated stablecoin or a tokenised reserve equivalent. Our settlement infrastructure and the broader RTGS on DLT pillar cover the settlement-layer choices; what matters for the tokenisation platform is that the cash leg is chosen deliberately and that the delivery-versus-payment logic binds the two legs into a single atomic transaction.

A platform that delivers all five layers — issuance, custody, compliance, secondary market and settlement — is operationally complete. One that covers only some of them forces the issuer to assemble the rest, which is the main reason platform evaluation often takes longer than the smart-contract build.

A tokenised security is a security. A tokenised fund unit is a fund unit. A tokenised bond is a bond. The legal classification of the underlying instrument is preserved through the tokenisation process, and every obligation that attached to the instrument in its conventional form continues to attach to the token. The regulators that supervise the issuer, the custodian, the trading venue and the transfer agent continue to supervise them in the tokenised model.

Three regulatory frames are most relevant for institutional tokenisation programmes in 2026.

The United States operates through the Securities and Exchange Commission for securities, the Commodity Futures Trading Commission for derivatives and certain commodity-linked instruments, and state banking supervisors for custody of non-security tokens. The regulatory approach is enforcement-led rather than framework-led; tokenised treasuries operate under existing securities law with particular attention to broker-dealer registration, transfer-agent rules and custody under the Investment Advisers Act. The BlackRock BUIDL and Franklin Templeton BENJI products are structured within this envelope as traditional funds with a tokenised share class.

Europe has moved toward a framework-led approach. The Markets in Crypto-Assets regulation (MiCA) covers non-security tokens, and the DLT Pilot Regime provides a supervised environment for secondary trading of tokenised securities. For tokenised funds, the UCITS and AIFMD regimes continue to apply, with the tokenisation adding an operational dimension that supervisors expect to see addressed in the fund's operating memorandum. The United Kingdom has signalled a similar direction through the Digital Securities Sandbox and the FCA's tokenisation work under its asset-management review.

Asia-Pacific is a patchwork with credible leading jurisdictions. The Monetary Authority of Singapore's Project Guardian has produced production-grade pilots with global banks; Hong Kong's tokenisation initiatives span green bonds and funds; Japan's Payment Services Act permits tokenised deposits; Australia's ASIC has issued guidance on tokenised managed investment schemes.

Pakistan's Virtual Assets Act 2026 establishes the Pakistan Virtual Assets Regulatory Authority (PVARA) as the domestic licensing body for virtual asset activities, including the issuance and custody of tokenised assets. Our PVARA licensing guide and the PVARA sandbox overview set out the domestic frame for issuers that intend to operate in Pakistan or to offer tokenised products to Pakistani investors, and the tokenisation page for Pakistan sets out the institutional routes available under the current regime.

The point for a tokenisation platform is that the legal-classification assumption is baked into every layer. Compliance hooks must accept jurisdictional inputs; custody must reconcile to the legal system-of-record; secondary-market rules must enforce transfer restrictions specific to the relevant regulation.

Issuance in a tokenisation programme begins well before any contract is deployed. The legal instrument is drafted and approved under the relevant regulatory process, the transfer agent and administrator appointments are in place, and the constitutional documents reference the tokenised form explicitly. Only at that point does the platform contribute.

The platform's role in issuance covers four functions.

Token design translates the constitutional properties of the instrument into contract parameters. A fund unit that pays daily accrual needs a contract that accommodates daily rebasing or distribution. A bond that pays semi-annual coupons needs a coupon-distribution mechanism that reconciles against the paying-agent schedule. A restricted security with a defined lock-up period needs a transfer hook that enforces the lock. These are not generic choices; the design is specific to the instrument.

Standards selection picks the token standard appropriate to the jurisdiction and the ledger. On Ethereum and EVM-compatible chains, ERC-3643 (the "T-REX" standard) is the dominant choice for regulated tokenised securities because it builds compliance hooks into the base contract. ERC-1400 remains in use. On Solana, Token-2022 with transfer hooks provides the equivalent control surface; our Solana page sets out the specifics of this architecture. On permissioned ledgers such as Corda, the token itself is a state representation within the privacy model of the ledger; there is no "standard" in the same sense but there are reference contract libraries.

Deployment and minting executes the contract instantiation, the assignment of roles (issuer, compliance officer, transfer agent), the configuration of the allow-list or identity registry, and the initial minting of tokens to the initial holders. In an institutional deployment this is gated behind a formal change-management process with supervisor notification where required.

Reconciliation establishes the binding between the on-chain representation and the off-chain register. In a well-designed platform this is continuous rather than end-of-day: the transfer agent record and the on-chain holdings are cross-checked at each transfer event, with exceptions raised immediately. The on-chain record and the transfer agent record are not duplicates — one is the system of record, the other is the operational reflection — but they must remain synchronised within the tolerance the supervisor expects.

Regulated tokenisation stands or falls on the control surface at the transfer point. The platform's compliance layer is responsible for ensuring that no transfer completes that should not complete, and that every transfer that does complete generates the records needed for audit, supervisory reporting and downstream reconciliation.

The most robust architecture is protocol-level enforcement. In this pattern the compliance check is part of the transfer call — the contract itself rejects a transfer that fails a check — rather than a pre-trade or pre-settlement check that runs in an application layer and that can be bypassed if the user interacts with the contract directly. Token-2022 transfer hooks on Solana and the ERC-3643 transfer path on EVM chains both implement this pattern. Our compliance-native fintech API piece sets out the architectural case for protocol-level compliance at greater length.

The checks that sit behind the transfer hook typically include the following:

• Identity and KYC status of the sender and the recipient, resolved against an on-chain identity registry or a control-layer service that maintains one.
• Jurisdictional eligibility — certain tokens cannot be held by residents of particular jurisdictions and the check runs against the attested jurisdiction of the recipient.
• Investor qualification — accredited-investor, qualified-purchaser or equivalent local categories, attested and time-bound.
• Sanctions screening — both parties cross-checked against applicable sanctions lists, with the check re-run at the transfer time rather than relying on an onboarding-time check.
• Holding-period and lock-up restrictions that apply to the specific token under its issuance terms.
• Ownership concentration limits that apply to the token under its fund or partnership structure.
• Travel Rule data exchange where the transfer crosses a regulatory threshold — our Travel Rule platform addresses this as an operational component.

A compliance layer that cannot demonstrate on-chain enforcement of these checks will struggle to pass institutional due diligence. An issuer or custodian that relies on off-chain checks exposes itself to the risk that a transfer completes that should not have, and regulated institutions do not accept this risk lightly.

The secondary market layer is where tokenisation either delivers on its institutional promise or fails to. A primary issuance that sits in frozen custody is operationally easy but economically limited; the reason tokenisation attracts institutional capital is the prospect of faster, cheaper and better-governed secondary trading.

Three models dominate current practice.

A regulated trading venue that settles tokenised assets against tokenised cash on the same ledger is the cleanest model. It gives native delivery-versus-payment, continuous trading hours, and deterministic settlement finality. The DLT Pilot Regime venues in Europe operate in this mode. The cost is that the venue must be appropriately licensed, and the tokenised-cash leg must be available on the same ledger at the relevant scale.

A bilateral or request-for-quote model settles trades between two known counterparties against an on-ledger cash leg. This is well-suited to institutional products with a limited counterparty universe — interbank tokenised deposits, institutional fund units — and it avoids the market-making and matching-engine costs of a full order book. Delivery-versus-payment still binds the two legs into a single transaction.

A cross-venue model executes price discovery on a traditional venue and settles on-chain. This can work where the tokenised form is a mirror share class of a conventional instrument and where the execution venue is part of the issuer's distribution network. The platform's role is to keep the on-chain mirror in sync with the post-trade message stream from the execution venue.

In every model the platform is responsible for making the settlement atomic. A secondary trade that settles the cash leg but not the asset leg — or vice versa — creates reconciliation and credit exposure that a regulated participant will not accept. Delivery-versus-payment is not optional.

A tokenisation platform is a system that operates continuously under regulatory supervision. The operational questions that determine whether a build-or-buy decision succeeds are not usually the headline questions about the contract language or the chain choice. They are the less visible questions about controls, audit, interoperability and vendor governance.

Controls and audit come first. The platform must produce an audit trail that satisfies internal audit, external audit and the relevant supervisor. This means that every significant action — issuance, mint, burn, transfer, compliance override, key rotation, contract upgrade — is logged to a tamper-evident store, that the logs reconcile to on-chain events, and that they can be extracted on demand in the formats that auditors expect. A platform that lacks an audit story will fail vendor due diligence regardless of how elegant its contracts are.

Interoperability comes next. A tokenised asset that can only be held in custody on a single platform has limited utility. Institutional clients expect that the asset can move between custodians, that the compliance state transfers with it, and that the cash leg can settle across several approved options. The platform's architecture — the contract standard, the identity registry, the transfer-hook design — either enables this or forecloses it.

Vendor governance closes the set. A platform vendor that operates critical tokenisation infrastructure must meet the same vendor-risk expectations as any other critical supplier. This includes financial stability, operational resilience, information security certification (SOC 2, ISO 27001), and a clear exit plan. A tokenisation programme that cannot articulate how it would migrate off its platform vendor in a stressed scenario has not completed the vendor-risk assessment.

The build-or-buy decision is, for most institutions, a buy-with-customisation decision. Building the full stack from first principles requires a team and a time budget that most issuers do not have. Buying a vendor platform out of the box often leaves too many institution-specific requirements unmet. The middle path — a vendor platform with a defined extension surface, operated alongside the institution's existing systems of record and under the institution's own controls — is the model we see in production. Our build page covers the integration surface Bridge exposes, and our consulting work often focuses on the customisation and controls layer that sits between a vendor platform and an institution's existing operating model.

Bridge's tokenisation platform is built to serve regulated issuers, custodians and distributors end-to-end. The tokenisation stack covers issuance (with contract libraries for EVM, Solana Token-2022 and Corda), institutional custody (HSM-backed key management, multi-signature approval policies, audit-grade logging), protocol-level compliance (identity registry integration, transfer hooks, sanctions screening, Travel Rule), secondary-market integration (bilateral, RFQ and venue-integration patterns) and settlement (delivery-versus-payment against stablecoins, tokenised deposits or wholesale CBDC where available).

For Pakistan-specific programmes, the PVARA-aligned tokenisation route integrates with the domestic identity and compliance stack, and the PVARA sandbox gives a supervised route to production. For banks evaluating the custody side specifically, the bank custody page and the asset manager page set out the relevant product surface.

Our research team works with prospective issuers on the full lifecycle — from legal structuring through to operational go-live — and the consulting surface is available for institutions that want external capability alongside an internal build. Get in touch if you are scoping a tokenisation programme; we prefer conversations that start with the instrument and its regulatory frame rather than the contract language, because that is where the design questions that matter actually live.