Suit Up · Asia's institutional desk on tokenisation

TL;DR

This is the playbook for the bank programme owner or asset manager strategy head sitting with a tokenisation initiative on their desk and trying to decide what to build, what to license, and where the line between the two should run. The decision is structural, not religious. In-house build is the right answer when the institution has GSIB-scale balance sheet, a multi-product roadmap that amortises the platform cost across at least three live mandates, distribution rails that already pull institutional flow at meaningful volume, and an executive view that the relevant tokenisation layer is an institutional core competence rather than a supporting capability. Partner-licensing is the right answer when the programme is a single-product line in a single jurisdiction, when speed-to-market is binding, when the team to operate the layer at production-grade does not yet exist inside the institution, and when the strategic franchise sits somewhere other than the layer in question. Most institutions land in the second profile; the small number that genuinely belong in the first profile (the JPMorgan Kinexys case, the HSBC Orion case, the DBS Token Services case, the Wells Fargo Digital Cash case) are easy to identify because the rationale is structural rather than aspirational.

Decision frame

The build-vs-partner question is rarely uniform across the stack. An institution typically builds one or two layers and partners for the rest, and the right cut runs through the same layer-by-layer view that any tokenisation programme has to assemble: issuance platform, custody, settlement rail, on-chain accounting, transfer-agent integration. Conflating the layers is the most common upstream mistake. A bank that decides "we will build our tokenisation programme in-house" without separating the build decision per layer ends up either over-building (committing capital to layers where it has no differentiating capability, like transfer agency or chain-level infrastructure) or under-building (partnering for layers that turn out to be the actual moat, like the bank-money settlement rail).

The right discipline is to take each layer in turn, score it against the same five-question framework, and let the answer fall out of the per-layer scoring rather than the franchise-level instinct.

The five-question decision framework

Is this layer a strategic differentiator for our institution, or a supporting capability?

The first cut. A layer is a differentiator when getting it right (or wrong) materially changes the institution's competitive position in the relevant market. A layer is a supporting capability when the institution wins or loses on something else and the layer is plumbing that has to be present but is not the source of the franchise. For a GSIB tokenised-deposit programme, the bank-money settlement rail is the differentiator because the entire product is the bank's deposit liability moving on-chain. For an asset manager distributing a tokenised MMF, the differentiator is the underlying fund and the distribution franchise; the issuance platform is plumbing. Differentiator: build, with the operating discipline that comes with building. Supporting: partner, and pick the vendor that operates the layer to the standard your buyers expect.

The honest test is what happens if the layer fails. If the franchise survives with a vendor switch and a few weeks of integration work, it is a supporting capability. If a layer-level failure compromises the franchise itself (the bank's payment-rail credibility, the asset manager's allocator relationships, the issuer's transfer-agent obligations), it is a differentiator that justifies build.

Do we have the team to build and operate this at production-grade?

Tokenisation infrastructure is a discipline, and experienced talent at the cross-section of regulated finance, smart-contract engineering, and bank-grade operational controls is scarce. An institution staffing this from scratch with three new hires, no established platform team, and no production track record on a comparable programme is signing up for two to three years of organisational learning before the first mandate ships. That is the right investment if the programme is the institutional core competence and the multi-product roadmap is real; it is the wrong investment if the programme is a single-mandate strategic experiment.

The harder version of this question is whether the institution can keep the team. Build a tokenisation team, ship one product, watch the team get hired into a vendor or competitor at twice the salary. The retention model has to be in place before the build commitment. Partnering at the start, then in-housing once the programme has scaled, is a legitimate sequencing strategy.

What's the lifecycle cost of build vs partner over a 5-year horizon?

Build is a higher upfront cost amortised over time. Partner is a lower upfront cost but ongoing fee, often basis-points-on-AUM plus transaction-based components plus per-investor charges that compound as the programme scales. The crossover point depends on AUM growth, the vendor's pricing curve, and the institutional cost of running the layer in-house (which is almost always higher than the build team's first model, because the operational, security, audit, and incident-response overheads compound).

A useful rule of thumb. If the AUM growth path projects to USD 500m within 24 months and USD 5bn within 5 years across at least three product lines, build economics typically work. If the AUM path tops out at USD 500m total on one mandate, partner economics work. Pad the in-house operating assumption by 50 to 75 per cent over the build team's initial estimate.

Do we have a multi-product roadmap, or a single-product programme?

This question follows from the lifecycle-cost question and sharpens it. A platform built for a single tokenised MMF is a sunk cost amortised across one product. A platform built for a tokenised MMF, a tokenised credit fund, a tokenised structured-note programme, and a tokenised collateral mobility offering is a sunk cost amortised across four products with shared infrastructure. The multi-product case justifies the build investment; the single-product case rarely does.

The build-it-yourself examples in DBS Token Services, Kinexys, HSBC Orion, and Wells Fargo Digital Cash all share the multi-product profile: each platform serves multiple internal franchises (corporate treasury, institutional payments, wealth, markets) rather than one. The pattern that did not work historically was the bank that built bespoke infrastructure for one bond issuance and watched it sit unused while the next product went to a vendor.

Is the regulatory perimeter for this layer settled or moving?

A moving regulatory perimeter (stablecoin issuance under the GENIUS Act in 2026, tokenised-deposit treatment in cross-border contexts, transfer-agent registration for genuinely-tokenised securities under SEC §17A, agentic-commerce custody and authorisation primitives) is hostile to in-house build because each regulatory shift forces re-architecting on the institution's own balance sheet. A settled regulatory perimeter is friendlier to build because the design surface is stable. Partnering means letting the vendor absorb the regulatory churn and re-architecting cost; building means owning it.

Where the regulatory perimeter is moving fast and the institution does not have a regulatory affairs function staffed at the cross-section of digital assets and capital markets, partner. Where the perimeter is settled (US qualified custody for institutional crypto post-OCC trust bank charter and post-SAB 121 rescission, US transfer-agent registration for tokenised funds, MAS Major Payment Institution licence for Singapore stablecoin issuance), build is more defensible.

Layer-by-layer build/partner heuristics

Issuance platform

Most institutions partner. Build only if you are a tier-1 GSIB with a multi-asset-class roadmap that crosses tokenised funds, tokenised securities, tokenised collateral, and possibly tokenised deposits (JPMorgan Kinexys, HSBC Orion). For everything else, the platform vendors (Securitize, Centrifuge, Ondo, Tokeny) are the right counterparty. See Evaluating tokenisation issuance platforms for the per-vendor scoring and the asset-class-by-platform matrix.

Custody

Most institutions partner with a regulated custodian. Build only if you ARE a custodian by mandate (BNY, State Street, the large clearing banks). Asset managers and bank programme owners that are not in the custody business should partner with a credentialled provider (Anchorage, Zodia, BNY Digital Assets, State Street Digital, BitGo Trust). The custody build cost is structurally underestimated because the SOC 2 Type II posture, the insurance stack, the proof-of-reserves discipline, and the regulator-facing licence map all compound. See Evaluating custody providers.

Settlement rail

The build-vs-partner cut depends on the rail type. Bank-money rails (tokenised deposits) are typically built in-house because they require the bank charter and because the deposit liability has to sit on the bank's balance sheet. The Kinexys, DBS Token Services, HSBC, and Wells Fargo Digital Cash patterns all share this shape: the rail is the bank's franchise. Stablecoin and CBDC settlement rails are partnered with the issuer or the operator (Circle, Paxos, the central-bank operator for any wholesale CBDC). Cross-bank settlement is consortium-shaped (Partior, Fnality, the Korean won-stablecoin consortium), which is structurally a hybrid: each participating bank builds its leg, the consortium operates the multi-bank ledger.

On-chain accounting, oracle, data

Hybrid is the dominant pattern. Most institutions partner for the on-chain side (Chainlink, the platform vendor's data feed, the issuer's own price oracle for NAV updates) and integrate via APIs into an in-house ledger. Building the on-chain side from scratch is rarely justifiable; ignoring it and assuming the vendor's default is sufficient is the more common failure mode. The right discipline is to partner for the on-chain primitive, integrate to the institutional ledger of record, and commit to operational reconciliation between the two as a discipline owned in-house.

Transfer agent and registrar

For US tokenised securities, partner with an SEC-registered transfer agent unless you ARE one (Securitize, Ondo via Oasis Pro). The transfer-agent registration is the gating credential for the on-chain entry to be the legally operative share register. Building this in-house is a multi-year regulatory project that only makes sense if transfer agency itself is the franchise. For other jurisdictions, the equivalent registrar function may be in-house at the issuer or partnered (Singapore-side issuance often uses the platform vendor's registrar function; Hong Kong tokenised authorised funds typically use the existing fund administrator).

Worked example

An APAC asset manager launching a tokenised MMF programme into Singapore and Hong Kong qualified-investor channels walks the five-question framework across the stack.

Issuance platform. Differentiator: no, the asset manager's franchise is the underlying fund and the distribution relationships, not the platform. Team: not present in-house. Lifecycle cost over 5 years: vendor pricing on a USD 1bn AUM single-product line lands well below the build cost. Multi-product roadmap: not yet. Regulatory perimeter: moving, with cross-jurisdictional differences between SEC transfer-agent registration, MAS Capital Markets Services licensing, and the SFC tokenised authorised funds regime. Decision: PARTNER with a vendor that bundles transfer agent, broker-dealer, and ATS into one counterparty (Securitize is the canonical fit for the US perimeter; the APAC distribution leg requires a separate sub-custody arrangement).

Custody. Differentiator: no. Team: the existing primary custodian relationship covers the underlying fund. Lifecycle cost: tokenisation custody as an add-on to the existing custodian (BNY Digital Assets if the manager already uses BNY; State Street Digital if the relationship runs there) is materially cheaper than building. Multi-product: not yet. Regulatory perimeter: settling but still moving on the digital-asset custody side. Decision: PARTNER, prefer the incumbent custodian's digital-asset arm to minimise integration friction.

Settlement rail. Differentiator: no. Team: not present. Lifecycle cost: building a bank-money rail is structurally not available to an asset manager (no bank charter), so the question is which existing rail to use. Decision: PARTNER, default to an established stablecoin (USDC or USDG for the Singapore-side flows, fiat-stablecoin equivalent for the Hong Kong leg) or a tokenised-deposit issuer if the distribution leg has the right counterparty access (Kinexys, DBS Token Services, the DBS-Kinexys interoperability framework for cross-bank flows).

On-chain accounting. Hybrid. The vendor's on-chain NAV updating and holder-position attestation feeds into the asset manager's in-house fund accounting system via API. The integration discipline (reconciliation cadence, exception handling, dispute resolution) is owned in-house even though the on-chain primitive is the vendor's.

Transfer agent. Differentiator: no. Decision: PARTNER, use the issuance platform's bundled transfer-agent capability (the Securitize bundle is the canonical fit for the US perimeter).

The conclusion lands cleanly. Partner across the stack, in-house focus on distribution and product design where the manager actually differentiates. Institutional energy goes into picking the right vendors, integrating them well, and building the allocator relationships that move the AUM. This is the typical asset-manager profile and the right answer for the typical asset-manager programme.

Red flags

Building a layer because the vendor's pricing scares you. The operational cost of running production infrastructure (engineering, security, audit, regulatory affairs, incident response) often exceeds the vendor fee by a meaningful margin. If the build decision is anchored to a single line in the vendor's quote rather than to a strategic differentiator analysis, the model is wrong.
Partnering with a vendor for a layer that's actually your competitive moat. Give it away and you do not have a programme; you have a vendor relationship that any competitor can replicate by writing the same cheque to the same vendor. A bank that partners on the bank-money rail does not have a tokenised-deposit franchise.
Underestimating the integration cost between layers. Build-and-partner is a commitment to integration discipline. The handshakes between the issuance platform and the custodian, between the transfer agent and the on-chain whitelist, between the on-chain NAV oracle and the in-house fund accounting system, all have to be owned by someone with operational authority across vendor lines. The integration cost is rarely in the first model.
Vendor-lock decisions made without an exit clause. Token contract ownership, smart-contract source-code control, holder-register data export, KYC evidence base portability, customer relationship ownership. If any of these are structurally tied to the vendor's infrastructure with no exit path, the institution does not actually own the programme.
Treating "we built it ourselves" as evidence of seriousness. It is evidence of capital allocation, not of strategic clarity. The right question is whether that capital allocation generates differentiated returns in the relevant market. A well-built in-house platform that nobody uses is worse than a partnered programme that is shipping flow.

[Suit Up]

Build vs partner: tokenisation vendor due diligence