---
Banks are moving tokenization from pilots to live production because settlement cycle compression and real-time custody drive measurable operational value. Yet the gap between pilot success and production failure isa consistent pattern. The technology works. The smart contracts pass audit. TheHSM integration is clean. And then the project stalls, not on code, but on governance.
This post draws on our work deploying tokenization infrastructure at financial institutions, including custody and settlement systems in multi-bank environments. The pattern is consistent: projects that treat governance as a design requirement succeed. Those that treat it as a downstream compliance concern encounter significant delays before go-live.
Tokenization pilots succeed for a simple reason: they operate under conditions that will not exist in production.
A pilot typically runs with a single team, one validator, a simplified governance model, and compliance requirements that have been pre-approved by a single institution. The pilot asks: can we tokenize an asset?Can we settle it? Can we confirm it on chain? The answers are almost always yes. Smart contracts work. Settlement infrastructure works. Pilots succeed.
Production systems operate differently. When you move from pilot to production, you move from a single institution to a consortium, from one validator to multiple, and from pre-approved rules to runtime governance.You also move from internal approval to live compliance obligations across multiple jurisdictions.
This transition is where most projects stall. Not because the technology fails, but because the governance architecture is either missing or misaligned.
Production tokenization systems settle real assets, manage real custody, and create regulatory reporting obligations. They are subject to the same governance and operational control frameworks that apply to traditional settlement infrastructure.
In our work with banks deploying tokenization systems, pilots tend to define a single policy rule: settle when both sides agree. Production requires explicit answers to questions such as:
These are governance questions. But they are also architectural constraints that shape the entire system.
Consider settlement finality. In a pilot, you might define finality as when both validators confirm the block. In production, finality isa legal and operational concept that may need to satisfy clearing rules, auditability requirements, and compatibility with existing collateral management workflows. These requirements force architectural decisions. You cannot bolt compliance onto a finality definition after the fact. The finality mechanism, the custody model, and the policy enforcement layer must be designed together.
Most tokenization projects underestimate the operational governance layer and encounter the consequences during testnet validation or after go-live.
The core problem is that technology teams and compliance teams operate on different timelines and with different vocabularies. Technology teams build systems and expect compliance to review the output. Compliance teams need to understand policy decisions before the system is built. When these timelines misalign, the project does not fail on code. It fails on communication.
Here is how it happens in practice. A technology team designs a custody architecture: HSM-based key management, multi-signature settlement, and a smart contract that enforces settlement logic. The design passes internal code review. It integrates with the existing HSM infrastructure. The team runs a testnet, and it works.
Then the compliance team reviews it. They ask: if a settlement transaction is initiated but not confirmed within a defined window, who stops it? How is that decision logged? Which system is authoritative for policy enforcement: the smart contract or the operational policy system? What happens if the policy and the smart contract disagree?
The technology team realizes these questions were never answered because they were not asked during design. The smart contract has settlement logic baked in. The operational policy system has settlement logic baked in. They were never reconciled. A rework now requires either rebuilding the smart contract or the policy system.
This is not unique to any particular platform. It is inherent to any system that combines on-chain and off-chain governance. The fix is to treat governance design as a first-class technical problem:
Institutions that do this move from testnet to production on schedule. Those that discover governance gaps at testnet rebuild and slip by months.
Key management topology is one of the most consequential governance decisions in a tokenization system, and it is often deferred until late in the project.
For institutional deployments, HSM-based custody is the right answer. Banks integrating tokenization into settlement infrastructure already operate HSMs for other systems, for payments, for key signing, for operational risk controls. HSM-based key management integrates into that existing certified infrastructure, creates hardware-level audit trails, and fits the security architecture frameworks that banking regulators expect. It is not a new paradigm. It is tokenization infrastructure that speaks the language of existing banking security.
Kaleido's Custody offerings supports several enterprise HSM vendors natively, including Thales Luna, Fortanix, GCP Cloud HSM, AWS CloudHSM, Azure Key Vault, Hashicorp, and IBM,and provides a Remote Signing Module that connects to any PKCS#11-compliant hardware. The RSM deploys co-located with the HSM, validates signing payloads before authorizing the hardware to sign, and enforces OPA-based policy at the key management layer. Custody operations and settlement operations are logically separate but operationally coordinated through the same policy rules, which supports the kind of operational segregation that institutional custody frameworks require.
For institutions that need cryptographic separation of signing authority across multiple independent parties, distributed key management approaches exist and are worth evaluating. But this is a narrow use case, not the norm for institutional tokenization deployments.
Regulatory frameworks vary by jurisdiction and are evolving. Rather than prescribe specific compliance requirements here, it is worth identifying the categories of regulatory obligation that consistently force architectural decisions in tokenization systems.
Custody segregation requirements in most institutional regulatory frameworks require that custody operations be separable from settlement operations, with auditable key management. This shapes your key management topology and audit logging infrastructure.
Business continuity obligations typically require defined recovery time and recovery point objectives for settlement systems. If your tokenization system relies on a single validator or a single HSM, your recovery time is the time to bring that component back online. If your regulatory framework sets a maximum recovery window, this forces a multi-region deploy mentor a hot standby configuration.
Settlement finality requirements in clearing frameworks often specify that finality must be irreversible after a defined point, with both parties having access to a complete settlement record. This affects when smart contract reversions can execute, how settlement disputes are handled, and what must be logged.
The consistent pattern across all of these categories is the same: these are not compliance bolt-ons. They are constraints on your architecture. Institutions that model them as design requirements during architecture work move from design to production on schedule. Institutions that treat them as post-build compliance review add months to their timeline.
We recommend reviewing the specific regulatory frameworks applicable to your jurisdiction and asset class during architecture design, not after. The specific obligations will vary, but the architectural implications listed above are broadly consistent.
Kaleido's Policy Manager is built around a specific problem we encountered repeatedly in deployments: most blockchain platforms provide smart contracts for settlement logic and a blockchain for audit trails, but no way for compliance teams to define and modify policy rules independently of smart contract development.
This forces a difficult choice: either embed all settlement policy in smart contracts, which makes policy changes expensive and slow, requiring developer and auditor involvement for any modification, or manage settlement policy outside the chain, which loses auditability and creates a parallel governance system.
The Policy Manager decouples policy from settlement logic.Compliance teams define rules in Rego, the policy language of the Open PolicyAgent standard. The technology team implements the enforcement point. Policy changes take effect without smart contract redeployment. Enforcement happens prior to transaction signing at the key management layer, not as a post-hoc check, which means updated rules apply to the next transaction without any chain-level change. All policy evaluations, workflow steps, and signing events are logged and queryable.
Institutions need custody separated from settlement for regulatory reasons, but integrated operationally so the two flows work together. The Key Manager addresses this directly: custody and settlement are logically separate but coordinated through the same policy rules, satisfying operational segregation requirements without creating two disconnected systems.
Consortium tokenization systems add another governance layer: multi-party decision-making.
In a single-bank system, governance is hierarchical. Your compliance team owns the rules, your operations team enforces them. In a consortium, governance is distributed. Each participant has its own compliance requirements, and settlement rules must satisfy all of them.
Suppose three banks are settling tokenized collateral through a shared smart contract. One bank requires that settlement failures trigger manual approval from a compliance officer. Another requires that settlement limits be enforced per counterparty pair. A third requires that reversions be logged to its internal risk management system within a defined window.
These requirements are not in conflict, but they require a policy framework that accommodates them simultaneously. Our consortium deployments address this through a layered governance architecture:
This model scales to consortiums of dozens of banks and allows each bank to maintain operational control without requiring all banks to agree on internal procedures.
---
What is the difference between a tokenization pilot and a production system?
A pilot asks whether tokenization works. A production system asks whether tokenization can operate reliably under real institutional constraints. Pilots run with a single team, one validator, simplified governance, and pre-approved compliance rules. Production systems operate across multiple parties, must satisfy regulatory frameworks in real time, and require explicit answers about who owns policy rules, how changes get approved, and what happens when something fails. The technology that powers both is largely the same. The governance architecture is not.
Why do some pilots succeed but fail at production?
Pilots succeed because they eliminate the hard governance questions. A single team, a single institution, and pre-approved rules mean there is no ambiguity about who owns what. When a project moves to production, those questions surface: who owns the settlement policy, how does compliance sign off on a parameter change, which system is authoritative when the smart contract and the operational policy disagree. If these questions were not answered during design, the architecture may need to be rebuilt before go-live.
What does a policy change actually look like in production?
In a well-architected system, a compliance officer updates a rule in the policy engine, for example changing a settlement limit or adding anew counterparty approval requirement, without any involvement from the technology team and without touching the smart contract. The change is logged, timestamped, and auditable. It takes effect on the next transaction. In a system where policy is embedded in smart contracts, the same change requires a contract modification, an audit review, a redeployment, and a testing cycle.The difference is whether policy was decoupled from settlement logic at design time.
What happens if we discover governance gaps during testnet?
The answer depends on where the governance logic lives. If policy rules are embedded in smart contracts, closing a gap requires modifying and redeploying the contract, which means another audit cycle and significant delay. If policy is managed through a separate policy engine, you update the policy layer without touching the smart contract, retest, and move forward.This is why separating policy from settlement logic is worth the upfront architectural investment.
How do consortium networks handle conflicting settlement policies?
Through a tiered policy model. Shared policies covering finality rules, reversal windows, and audit logging are defined at the network level and enforced by the settlement smart contract. Participant policies covering internal approval workflows, counterparty limits, and system integrations are defined at the institution level and enforced by each bank's own policy engine. Banks do not need to agree on internal procedures to participate in a shared settlement network. Each institution maintains operational control over its own rules while the shared contract enforces the rules everyone has agreed to.
How do we know if our governance architecture is production-ready?
Run it through three questions before you start building.First, can your compliance team change a settlement policy rule without a smart contract redeployment? Second, does every decision point in the settlement flow produce a log that both parties can access? Third, if your primary validator orHSM goes offline, what is your recovery time and does it meet your regulatory obligation? If any of these lack a clear answer, governance is not yet a design requirement in your project.
---
Tokenization is moving from pilots to production, and the institutions that move fastest are those that treat governance as a first-class architectural concern. The technology, smart contracts, consensus, custody infrastructure, is mature. The differentiator is governance: how you structure policy ownership, separate policy from enforcement, integrate compliance into settlement flows, and coordinate multi-party rules in consortiums.
Start with governance. Define who owns policy rules, how compliance teams approve settlement parameters, and which on-chain events trigger audit trails. Build your architecture around these decisions, not after them.
That pattern holds across the deployments we have worked on. Institutions that move from pilot to production on schedule are the ones that started with governance architecture, not the ones that built the fastest smart contracts.
To explore how Kaleido supports production tokenization deployments, review our Tokenization in Finance: A Guide for Enterprise Architects or our Consortium Blockchain: Architecture, Governance, and Real Deployment Tradeoffs. For technical depth on how to integrate governance into settlement systems, contact our solutions team.
