What a Tokenisation Programme Costs in Year One

Nine cost centres, three decisions that dominate the total, and the line almost every business case omits — running two operating models at once until risk will stand behind the new one.

5 September 2026 · 11 min read

Ask a vendor what tokenisation costs and you get a platform fee. Ask a firm that has finished its first year and you get a longer, less comfortable list — on which the platform is rarely the largest line. Here is the full shape of the spend, which three decisions actually move it, and the item almost every business case omits.

In short

Nine cost centres, of which technology is typically a minority of year-one spend.
Three decisions dominate the total: whether you need a licence, how many investors you onboard, and how long you run two operating models in parallel.
Parallel running is the most commonly omitted line and frequently the largest surprise.
Year two is not year one minus the build. It has its own floor, and you should model it before committing.

The nine cost centres

These are the buckets a first-year programme actually spends against. The relative weight shifts with structure, but the list does not.

Cost centre	What it buys	What drives the number
Legal and structuring	Characterisation, vehicle documents, register provisions, investor agreements	Jurisdictions in scope; whether existing documents can be amended
Regulatory	Authorisation or variation of permission, regulator engagement	Whether you need a licence at all — the single biggest fork
Platform	Issuance, register, compliance rules, investor portal	Build vs buy; number of share classes and products
Smart contract assurance	Independent audit of contracts and configuration	Custom code vs an audited standard; number of review rounds
Custody	Safekeeping of keys and assets, segregation, reporting	Model chosen; asset types; number of chains
Identity and onboarding	KYC, AML, eligibility verification, ongoing screening	Per investor — scales with the book, not the build
Administration and transfer agency	NAV, register control, corporate actions, reporting	Dealing frequency; whether your administrator supports the model
Settlement and data	Cash rails, chain fees, price and reserve feeds	Transaction volume; chains published to; feed cadence
Internal people	Programme, operations, risk, compliance, engineering time	Almost always underestimated by a factor, not a percentage

The technology is the line you can get a quote for, which is precisely why it dominates the business case and not the invoice.

The three decisions that actually move the total

1. Does the activity need a licence?

This is the largest single fork in the entire programme. Issuing an instrument into an existing regulated structure, through parties who already hold the permissions, is one order of cost. Taking on a regulated activity yourself — custody, operating a venue, a service provider authorisation — is a different order, measured in professional fees, capital requirements, hiring against defined functions, and a timeline set by a regulator rather than by you.

The answer usually turns on which functions you perform versus partner for. Deciding that early and deliberately is the highest-leverage cost control available.

2. How many investors, and how are they onboarded?

Onboarding is the one cost that scales with your book rather than your build. Each investor needs verification, eligibility assessment, screening, and periodic review — and for institutional investors, look-through to beneficial owners and, for nominee and fund-of-fund structures, the underlying layers too.

A hundred professional investors is a very different programme from ten thousand retail subscribers, and the difference shows up in onboarding operations long before it shows up anywhere else. If the roadmap includes reusable identity so an investor verified once can subscribe to your second and third product without repeating it, that is an operating-cost decision, not a feature.

3. How long do you run two operating models?

Here is the line that gets left out. For a period — usually measured in quarters, not weeks — the traditional book and the tokenised one run side by side, with reconciliation between them, because risk and audit will not stand behind the new record alone until it has been demonstrated.

That is two operating models plus the work of comparing them, and it lands on the team you already have. It is not waste; it is how a regulated firm adopts a new system of record. But a business case that shows the new model's cost without the overlap is understating year one by the cost of running the old one as well.

The integration line nobody quotes

Six connections, six projects. Each needs a data contract, a reconciliation rule, an error path and an owner on both sides — and the counterparty's roadmap, not yours, sets the delivery date.

Vendor pricing covers the platform. It does not cover joining it to the systems your firm already runs, and this is consistently the line that slips. Each connection carries the same four costs: agreeing the data contract, building and testing it, defining what happens when the two sides disagree, and then maintaining it as either side changes.

The awkward part is that most of these counterparties are outside your control. A fund administrator's ability to consume an on-chain register, a custodian's support for a given chain, a screening provider's API — each is a dependency with its own release cycle. Programmes routinely discover in month three that a key counterparty can support the model next year, which turns an integration into either a manual workaround or a delay.

Mitigation: confirm counterparty readiness in writing before the plan is fixed, not during delivery. A one-page capability questionnaire to your administrator, custodian and auditor at the outset is the cheapest schedule insurance available.

Build versus buy, honestly

Building looks cheaper in a spreadsheet because the comparison is usually engineering salaries against a licence fee. The comparison that matters includes what a platform carries that a first build does not: independent contract audits, compliance rule coverage across jurisdictions, custody integrations, an administrator-facing interface, upgrade paths as standards move, and the operational tooling — reconciliation, exception handling, reporting — that nobody scopes and everybody needs by month four.

Building is the right answer when your requirement is genuinely unusual, or when the capability is strategic and you intend to run it for a decade. It is the wrong answer when the driver is that a licence fee is a visible number and engineering time is not.

Is tokenisation cheaper than traditional issuance? Not in year one, and anyone promising otherwise is comparing the wrong things. Year one carries the build, the legal characterisation, the assurance work and the parallel run, on top of the operating costs you already have. The savings arrive later and come from specific places: transfer processing that no longer requires manual handling, settlement that does not need days of exposure, corporate actions executed programmatically, and distribution to investors you could not previously serve economically. Build the case on those, with a realistic date for when the parallel run ends — not on a year-one saving that will not appear.

What gets cut, and what should not

When the number comes in high, the same items get trimmed, and two of them should not be.

Contract assurance. Reducing audit rounds saves a modest amount and concentrates risk on the component that is hardest to fix after launch. Immutable code with a defect is a very expensive way to economise.
Reconciliation tooling. The first instinct is a spreadsheet and a person. That works until volume arrives, and then the tool gets built anyway — in a hurry, by the team handling the incident it was needed for.
The exception path. Happy-path builds demo beautifully and fail in operations. Failed transfers, lost keys, forced transfers, stale feeds and disputed entitlements are not edge cases; they are the work.

Reasonable things to trim instead: the number of share classes at launch, the number of chains, dealing frequency, portal features, and anything whose absence is an inconvenience rather than a control gap.

Modelling year two

Year two removes the build and the characterisation work, and keeps a floor: platform, custody, administration, onboarding for new investors, chain and data costs, assurance for changes, and the people who run it. Add the cost of whatever you launch next — which is far cheaper on the second product than the first, and that is the real economic argument for the programme.

Building a defensible number

Settle the licensing question first. Everything else is a rounding error against it.
Forecast investors by type, and price onboarding per investor including periodic review.
Put parallel running in the model explicitly, with a named exit test for ending it.
Price internal time at loaded cost, in days, by function. Then add the contingency you were going to add anyway.
Model year two separately, and judge the programme on the second product rather than the first.

On numbers. This is deliberately a structure rather than a price list. Fees for legal work, authorisation, audit, custody and administration vary by jurisdiction, structure and scale to a degree that makes any "typical" figure misleading — the useful output is a build-up populated with your own quotes. Nothing here is accounting, tax or legal advice.