Skip to main content
Request a demo
Tokenization

White Label Tokenization

Running the platform under your own brand and domain, with your tenants isolated from every other tenant by three independent layers.

Standards, ordered by control over a transferFour token standards as rungs, from one where anyone may hold up to one where a transfer can be refused by the contract itself.ERC-20anyone may holdERC-1155batched, still openERC-4626a vault around oneERC-3643a transfer can be refused

Definition

White-label tokenization is operating the tokenization system as your own product: your brand, your domain, your customers, your commercial terms. The platform underneath is multi-tenant, and each tenant is isolated at the schema, the client and the database.

What it solves

  1. Build-versus-buyThe register, the ledger and the compliance engine are eighteen months of work before a first issuance. Licensing them is a different decision from outsourcing the customer relationship.
  2. Brand ownershipAn institution putting its name on an instrument rarely wants a third party’s brand in the investor’s browser.
  3. Isolation you can evidenceA regulator asking how one client’s data is separated from another’s wants a mechanism, not a policy document.

How it works

  1. A tenant per customerEvery tenant-owned row carries its tenant, and indexes lead with it.
  2. A client that cannot forgetEvery query is rewritten to carry a tenant predicate, including bare primary-key lookups.
  3. A database that refusesRow-level security enforces the same rule independently, with tenant context set per transaction rather than per connection so a pooled connection cannot carry it into the next request.
  4. Branding as configurationName, legal name, domain and palette are configuration, not a fork.

Architecture

Multi-tenancy is enforced in three places that fail independently. A test reads the generated data model and fails if any table is unclassified, so a new table cannot ship without somebody deciding how it is isolated.

How the platform is arrangedFour stages — asset, compliance, offering and register — connected left to right, all enclosed by a single transaction boundary that rests on a double-entry ledger.AssetStructured and documentedCompliancePolicy in forceOfferingA book that is derivedRegisterHolders of recordOne transaction boundaryA movement and the entries behind it commit together, or neither doesDouble-entry ledgerEvery movement, both sides, in minor unitsBalanced at COMMIT
Four stages inside one transaction boundary, on one ledger. A register that disagrees with the cash is not a state the software can reach.

Tokenization lifecycle

  1. ProvisionA tenant is created with its own branding, roles and policy.
  2. ConfigureJurisdictions, asset classes, payment methods and approval thresholds.
  3. OperateYour team, your customers, your issuances.
  4. ReportPer-tenant audit, ledger and register exports.

Supported token model

Whatever each tenant’s instruments require. Tenancy is orthogonal to the instrument. A white-label operator runs the same standard-selection logic per asset that a direct issuer does.

Asset requirements

What must be true before this can responsibly be tokenized at all.

  • A legal entity able to contract with your customers.
  • A decision about who is the regulated party for each issuance.
  • Support and escalation paths your customers can reach.

Compliance considerations

  • Each tenant publishes its own compliance policy; nothing is inherited by default.
  • Segregation of duties is enforced per tenant, including conflicting-role detection.
  • Platform-operator access across tenants is explicit, time-boxed and audited — never a default.
A compliance policy as ordered rulesRules are evaluated in sequence and the first match decides. A subject matching no rule is denied, and a fact the platform does not know never satisfies a rule.Subjectan investor's facts#1Screening hit is openreject#2Country in the blocked listreject#3Professional or institutional, verifiedallowMatched no ruledenyFirst matchdecides. A laterallow cannot undoan earlier reject.Eligibility comesfrom a rule saying so.
Rules are data, evaluated in sequence, and the first match decides. A subject matching nothing is denied — eligibility comes from a rule saying so, never from no rule objecting.

Investor workflow

  • The investor sees your brand throughout.
  • Verification, subscription and holding are identical to a direct issuance.

Issuer workflow

  • Your team administers tenants and users.
  • Your customers run their own issuances inside their own tenant.

Payments

Payment configuration is per tenant, so one customer’s rails and accounts are never another’s.

The payment railMoney is matched to a subscription by its reference and no other attribute, then screened and settled. Provider adapters for card and crypto rails are not built, and are drawn as an absent component.ReferencechecksummedFunds arrivebank or custodyReconcilereference or nothingScreenAMLSettlesecond authoriserSuspense (2900)unidentified, and visibleNo reference matchProvider adaptersCard, local rail, stablecoinNot built — the registry ships empty
A reference is the only thing that matches money to a payment. Everything else is an exception for a person, and unidentified credits post to suspense where they stay visible.

Lifecycle servicing

Lifecycle servicing runs per tenant with per-tenant approvals and per-tenant ledgers.

How a distribution is splitA funded pool is divided among holders of record as at the record date using largest-remainder allocation, then withholding is deducted from each holder's gross rather than from the pool.Funded poolone exact amountRegister as atthe record dateRebuilt from confirmedmovements, not today’sbalancesNet to the holderWithheld, from that holder’s grossThe lines sum to exactly what was fundedLargest-remainder allocation, so no minor unit is created or lost. Rounding each slice independently leaves the issuer a few units out every cycle.There is no per-jurisdiction withholding matrix in this build — one rate is entered per run.
Holders of record as at the record date, split by largest remainder so the lines sum exactly, with withholding taken from each holder’s gross rather than off the top of the pool.

Secondary transfer

Transfer policy is a tenant decision, constrained by the instrument’s own restrictions.

The transfer gateA transfer request passes through eight compliance checks. Any single failure refuses the transfer; the same gate is evaluated off-chain and on-chain.Senderholds unitscanTransfer( )Sender holds the unitsNeither party frozenLockup expiredRecipient eligible under policyJurisdiction permittedInvestor type permittedHolding limit not breachedSanctions screening clearRecipientunits move, or none doOne implementation. The Solidity module and the register evaluate the same rules.
One implementation of the gate, not two. The function the register calls is the same one that mirrors the Solidity compliance module check for check, so an off-chain gate and an on-chain gate cannot drift.

Risks

Named plainly. An instrument whose risks are only in a footnote has been mis-sold before it has been issued.

  1. Regulatory perimeterWho is regulated for what must be settled before launch, not after a complaint.
  2. Support burdenYour brand means your support queue, including questions about the underlying platform.
  3. Isolation is only as good as its weakest layerWhich is why there are three, and why the classification test exists.

How we support it

  • Brand as a single configuration surface — no package, component, contract or copy string hard-codes a name.
  • Tenant isolation checked before permission, so a denial cannot confirm that a foreign resource exists.
  • Per-tenant audit trails, hash-chained and append-only.

Questions

Can each tenant have its own domain?

Yes. Branding and URLs are configuration per tenant.

Can platform operators see tenant data?

Only through an explicit supervisory path that is read-only at the database level and audited. Writing into another tenant is refused by the database regardless of application code.

Who holds the customer relationship?

You do. That is the point of the model, and it is also why the regulatory perimeter needs settling first.

Next steps

Bring an instrument you are actually considering. Structuring something real is the only way to judge whether the model fits.

Request Enterprise DemoAll tokenization topics