DTCC Tokenization Services enablement checklist

For broker-dealers (including prime brokers) and custodian banks running a repo against tokenized Treasuries, settled in on-chain cash (stablecoin or deposit token).

DTCC's onboarding covers 8 steps and 25 tasks. Running a repo in production adds 40+ steps inside your firm. Knova runs in your dedicated environment alongside your core systems and automates what happens before and after the trade.

DTCC checklist Additional internal scope With Knova: configurable, production- and operation-ready

Get live on DTS

The project kicks off with DTCC approving you and your wallet.

DTCC checklist · summarized; full checklist shared by DTCC

☐Qualify: confirm DTC Participant status, choose an approved network and wallet provider
☐Attest to your AML/KYC program
☐Form the project team and hold the kick-off call with DTCC
☐Sign the application documents
☐Book DTS training and decide whether to use the interface, APIs or both
☐Name your coordinators and users, create API service accounts, register your wallets
☐Write the test plan, run every test case, submit the test attestation
☐Confirm the go-live date and set up production users and wallets

With Knova · Top institutional wallets are already integrated. Add other wallet providers through self-serve connectors you build and own, without rebuilding your workflows. Through Knova’s messaging adapter, DTS activity flows into your internal books and ledgers as MT or ISO 20022 messages, webhooks or REST, in your chosen format, on Canton or Besu.

With Knova · The same workflows run whichever identity hosting option you choose, so switching later does not mean rebuilding them.
With Knova · No in-house Daml team is needed; DAR versions are tracked and coordinated across that set through Knova’s node operator network.
With Knova · Addresses are generated and tracked for you.
With Knova · Allowlists, limits and approval steps are set as policy and checked before every transfer; approvers come from your identity provider (OIDC, SAML or LDAP).
With Knova · Maintain these windows alongside venue cut-offs and policies as configurations without additional build.
With Knova · The rules run as policy around the clock instead of being watched manually.
With Knova · Our digital twin tracks every instance in one standard, cryptographically verifiable data model mapped to your CUSIP records.
With Knova · Every transfer is logged in a full audit lineage based on the position you have documented for legal and finance inspections.
With Knova · Knova’s messaging adapter writes on-chain activity to your books in the API or message format they already accept.

Prepare the Treasuries and cash

Before the trade, the Treasuries you will post move from your DTC account into your wallet, and the cash you lend must be a stablecoin or deposit token that can move at any hour.

DTS gives youTokenization and detokenization via DTCC Tokenization Services. You instruct DTC and matching tokens are credited to your registered wallet — but you arrange and operate your own cash leg.

If you post tokenized Treasuries

With Knova · Eligibility is an attribute of each asset in the digital twin, so an allowlist check blocks ineligible securities before the instruction is submitted.
With Knova · Those steps run as configured workflows with approvals and an audit trail.

If you lend on-chain cash

With Knova · Stablecoins and deposit tokens sit in one model, so cash-token inventory is managed across issuers with automations.
With Knova · Funding rules run as policies Knova triggers and monitors around the clock, while your bank and payment systems move the money.

For every repo

With Knova · Stablecoins, deposit tokens and Treasuries share one digital-twin data model. Changing the instrument does not change the workflow; the instrument and agreed terms are set once as a template for each use case.
With Knova · Prefunding and cash-token rules run around the clock with monitoring and alerts.
With Knova · The failure is detected, internal dependent actions pause, teams are alerted and every step is recorded in one place.
With Knova · The proposal is cancelled, locked assets are released, and the item goes to the operations queue with those actions attached.

Open the repo

The lender's cash token and your tokenized Treasuries swap in one step, at any hour. Steps are venue specific.

DTS gives youTokens you can move wallet to wallet on Canton or Besu, with more networks planned. The cash leg runs on a separate rail, so your venue and cash provider have to be orchestrated.

With Knova · The condition is detected and the RFQ is raised through your OMS API, or FIX where connected, under your approvals and limits. Negotiation and execution stay at the venue.
With Knova · Agreed terms such as haircut and margin floor are set once as a template.
With Knova · Venue differences are handled at the connector, so trades reach your systems the same way from each supported venue.
With Knova · On-chain events are remapped, matched to bookings in either order, and delivered in the format your systems already use: MT, ISO 20022, FIX, MQ, REST or your own messages.
With Knova · Each booking is validated and normalized as it arrives.
With Knova · Eligibility and routing rules send ineligible trades to your existing settlement process automatically.
With Knova · The proposal is built from the booking using a contract both counterparties have deployed on their nodes. The counterparty’s acceptance doubles as trade affirmation, so mismatched economics are rejected before anything settles.
With Knova · Readiness is checked against your allowlists before you send. If they do not respond in time, the item escalates to your operations queue under your chosen fallback. Your counterparty does not need Knova.
With Knova · Your workflow fetches and checks those terms the moment the request arrives, before anything moves.
With Knova · Each asset in Knova’s digital twin carries its type, eligibility and pricing, so the check runs automatically against your own rules and records.
With Knova · Limit and allowlist checks run before every instruction; wallet screening runs through your own provider.
With Knova · Your side is allocated and sent for signing automatically under the rules you defined.
With Knova · Your side’s instruction is automated under your approvals and signing rules; your chosen model is set as configuration.
With Knova · Internal ledger updates and on-chain state logging can run as one workflow. Transaction state is stored persistently so you can see where each transaction stands.

Manage collateral and records

For hours or a weekend, you margin, substitute and monitor while your records stay in line.

DTS gives youTransaction data for reconciliation, DTCC’s record of tokenized holdings by wallet, and DTC’s controls to pause or claw back tokens.

With Knova · Every position is watched around the clock, with alerts when a threshold is crossed.
With Knova · Margin calls, substitution and maturity run as configured templates, started by a margin-call message or core banking alert, with approval where you want it.
With Knova · Routing rules decide the path and Knova holds the state during each window.
With Knova · Knova can scan DTCC LedgerScan and Canton participant nodes, or listen to messages on existing systems, to detect events, reconcile and push notifications. Unexpected changes are flagged, affected orders are blocked, and collateral is revalued using workflows you define.
With Knova · Knova’s reconciliation engine continuously reconciles on-chain, off-chain and manual activity across systems, client by client, with full-precision decimals normalized to your core’s format and full audit lineage.
With Knova · Funding rules are monitored around the clock.
With Knova · Transaction state is kept persistently and settlement status flows back to your systems, so operations see a failed settlement as it happens.

Close the repo

The borrower returns the cash token plus interest, the lender returns the Treasuries, then each side settles out.

DTS gives youDetokenization, which removes the tokens and credits the security back to your DTC book-entry account.

With Knova · A rule configured in advance releases and returns collateral at maturity; excess capital is freed automatically through your selected workflows.
With Knova · The closing DvP is created and sent for approval and signing automatically at maturity using the agreed rate, day-count convention and rounding rules with supported decimals.
With Knova · Redemptions can be triggered and monitored; your bank or the issuer moves the money.
With Knova · The runbooks run as configured workflows with approvals.

If you also hold tokenized positions for clients

A client asks you to hold its tokenized Treasuries and post them in a repo. Mainly custodian banks.

With Knova · Knova’s audit lineage makes every client instruction and position traceable in one place for investigations and inquiries.
With Knova · Client accounts and sub-account balances are mapped to your wallet structure.
With Knova · A per-client view is mapped to your core ledger, without replacing it.
With Knova · Instructions run through your existing approvals and maker-checker steps.

DTCC tokenizes the asset.
Knova handles the rest.

Talk to the Knova team →Back to the article