Devancore Inc.
Devancore Post-Trade Glossary
Glossary
CDM for Tokenized Securities
A machine-readable lifecycle model that standardizes how tokenized securities, collateral, repo, securities lending, and derivatives events are represented and automated.
Document source: https://devancore.com/glossary/common-domain-model-tokenized-securities
On this page
Actions
Devancore Post-Trade Glossary
CDM for Tokenized Securities
A machine-readable lifecycle model that standardizes how tokenized securities, collateral, repo, securities lending, and derivatives events are represented and automated.
Definition
What is the Common Domain Model?
The Common Domain Model, or CDM, is a standardized, machine-readable, and machine-executable model for financial products, trades, and lifecycle events. It gives market participants a shared way to describe what a trade is, what state it is in, and what event has changed that state.
For tokenized securities, this matters because tokenization solves only one part of the problem. A shared ledger can synchronize state across participants, but it does not automatically make every participant interpret that state the same way. If one platform treats a tokenized bond redemption as a transfer, another treats it as a corporate action, and a third treats it as a settlement event, the industry has simply moved the old reconciliation problem onto faster infrastructure.
CDM is the missing translation layer. It defines the financial product, the trade, and the lifecycle event in a structured format that systems can process. That is the difference between a token that only moves on-chain and a tokenized security that can participate in regulated post-trade workflows.
CDM role in tokenized securities
Tokenization gives shared state. CDM gives shared meaning.
| Layer | Without CDM | With CDM |
|---|---|---|
| Instrument | Each platform defines token attributes differently | Token attributes map into a common asset model |
| Lifecycle | Coupon, redemption, transfer, and substitution logic is proprietary | Events follow a shared machine-readable lifecycle model |
| Collateral | Margin and pledge events require custom mapping | Collateral events can be represented consistently across systems |
| Securities lending | Loan, recall, return, and collateral states fragment by platform | SFT events share a common post-trade event language |
| Repo | Opening, closing, repricing, and substitution events are system-specific | Repo lifecycle events can be automated from a shared model |
| Reporting | Regulatory outputs require bespoke interpretation | Machine-readable events support consistent reporting logic |
The core thesis is simple: tokenized securities need a common event language. Without it, every issuer, custodian, trading venue, collateral platform, and post-trade system writes its own version of coupon logic, redemption logic, pledge logic, substitution logic, loan recall logic, and margin logic. That creates fragmentation. It also creates operational risk because two systems can see the same ledger event and assign different business meaning to it.
CDM reduces that ambiguity by standardizing product, event, process, and reference-data structures. It does not remove the need for legal agreements, prospectuses, smart contract review, CSD or custodian controls, finality rules, or regulatory reporting logic. It makes those things easier to connect because the event language is shared.
Tokenized asset events that need a common model
The token is only useful if lifecycle events are interpreted consistently.
| Event | Operational question | CDM value |
|---|---|---|
| Issuance | What was created, by whom, with what rights? | Standardizes asset and legal-event representation |
| Transfer | Did ownership or entitlement move? | Defines state transition and settlement context |
| Coupon or dividend | Who is entitled and how is the amount calculated? | Links entitlement logic to lifecycle event data |
| Redemption | Was the instrument partially or fully retired? | Represents principal return and position reduction |
| Collateral pledge | Is the asset encumbered, reusable, or released? | Standardizes collateral state and control status |
| Fork or token change | Did technical infrastructure alter the asset state? | Routes token-specific events into reviewable lifecycle logic |
The CDM direction is especially important because tokenized securities do not stay in one workflow. A tokenized bond may be held as an investment, pledged as collateral, used in repo, lent in a securities financing transaction, substituted during collateral optimization, redeemed at maturity, and included in regulatory reports. If each workflow uses a different data model, automation breaks at every handoff.
CDM gives the market a better foundation: one model for lifecycle events across derivatives, repo, securities lending, collateral, and beyond.
CDM — shared meaning for tokenized securities
Devancore Glossary · devancore.com
How it works
How CDM works for tokenized securities
The first step is product modeling. The system needs to describe what the instrument is: security type, issuer, terms, identifiers, currency, rights, obligations, and token-specific attributes such as token standard, blockchain protocol, contract address, and settlement mechanism. The FINOS Tokenized Assets Working Group is focused on extending CDM asset and settlement structures so tokenized asset details can be represented without breaking the existing model.
The second step is event modeling. A tokenized security is not useful if it only has a balance. It needs lifecycle events: issuance, transfer, pledge, release, coupon, dividend, redemption, split, maturity, substitution, loan, recall, return, margin call, and close-out. CDM gives these events a consistent structure so they can be understood across systems.
The third step is process modeling. A lifecycle event rarely stands alone. A collateral substitution may require eligibility checks, valuation, haircut calculation, approval, transfer, finality confirmation, and books-and-records update. CDM helps define the process path so the event can drive workflow, not just appear as a static data record.
CDM automation map
The model becomes valuable when lifecycle events drive workflow.
| Workflow | Legacy problem | CDM-enabled direction |
|---|---|---|
| Trade processing | Each system translates trade events differently | Shared event model reduces reconciliation and mapping |
| Collateral management | Margin calls, substitutions, and releases are manually interpreted | Events can trigger standardized collateral workflows |
| Repo | Opening, closing, repricing, and pair-off logic varies by platform | Repo lifecycle can be modeled as reusable event logic |
| Securities lending | Recall, return, and collateral states fragment across counterparties | SFT lifecycle events can share one model |
| Derivatives | Confirmations, margin, valuation, and termination are complex to automate | CDM aligns events with ISDA-style lifecycle logic |
| Regulatory reporting | Rules are reinterpreted by each firm and vendor | Machine-readable events support more consistent reporting outputs |
The fourth step is ledger interaction. A distributed ledger can record the final state transition, but CDM should define the business event that the ledger transaction represents. The transaction hash proves that something happened. CDM helps explain what happened in financial-market language.
For example, a token movement may look technically identical whether it represents outright sale settlement, collateral pledge, repo opening leg, securities loan delivery, or return of recalled securities. The ledger sees movement. The operating platform needs business meaning. CDM supplies the model for that meaning.
A simplified event representation might look like this:
{
"eventType": "CollateralSubstitution",
"productModel": "CDM",
"asset": {
"instrumentId": "US-TREASURY-TOKEN",
"tokenStandard": "permissioned-token",
"settlementNetwork": "approved-dlt-rail"
},
"beforeState": "pledgedCollateral",
"afterState": "substitutedCollateral",
"approvalStatus": "approved",
"settlementStatus": "pendingFinality"
}
This is not a replacement for CDM. It is the kind of operating shape a platform needs: structured event, asset context, state transition, approval status, and settlement status.
The fifth step is automation. Once lifecycle events are represented consistently, systems can automate more safely. Margin calls can be calculated from the same event model. Repo open and close events can be processed with reusable logic. Securities lending recall and return events can flow through the same state machine. Regulatory reporting can consume event data directly instead of relying on after-the-fact mappings.
The final step is control. CDM does not eliminate operational risk. It reduces one major source of risk: semantic mismatch. The firm still needs maker-checker controls, finality checks, smart contract risk controls, oracle governance, exception handling, and audit retention.
Tokenized security lifecycle through CDM
Devancore Glossary · devancore.com
Tokenized security lifecycle through CDM
Devancore Glossary · devancore.com
In Devancore™
CDM in Devancore — post-trade translation layer
Devancore Glossary · devancore.com
CDM in Devancore
Devancore treats CDM as a post-trade translation layer between legal terms, instrument master data, token state, lifecycle events, settlement finality, and books-and-records outputs. The goal is not to force every workflow into a generic token model. The goal is to preserve business meaning as the asset moves across workflows.
In instrument master data, Devancore can connect the tokenized asset record to traditional identifiers, token identifiers, issuer data, CFI classification, market data, and legal terms. CDM-shaped events then describe what happens to that instrument over time.
In trade lifecycle management, Devancore can record lifecycle events as structured state transitions instead of free-text operational notes. A transfer, coupon, redemption, collateral pledge, repo opening leg, securities loan recall, or margin event can each be tied to the same event log, approval path, and finality record.
In tokenized collateral repo settlement, CDM helps separate the economic event from the rail. Repo economics remain repo economics. The settlement rail may be CSD-based or DLT-based. CDM helps keep the product and lifecycle logic consistent while Devancore records the rail-specific finality evidence.
In securities lending operations, CDM-style modeling is useful because loan, recall, return, collateral, rebate, and substitution events are stateful. They are not just messages. Devancore can attach those events to positions, collateral records, counterparty obligations, and Rule 10c-1a or other reporting workflows where applicable.
In collateral management, CDM supports a cleaner path from exposure calculation to margin call to collateral movement to finality confirmation. The system can distinguish proposed event, approved event, executed event, settled event, and disputed event. That distinction matters when tokenized collateral moves faster than traditional operational review cycles.
In DLT books and records, CDM helps translate ledger activity into regulated records. A transaction hash is evidence, but the regulated record also needs product, party, account, event type, approval state, lifecycle state, finality state, and reporting context. Devancore keeps those together.
Devancore's operating stance is conservative: use open industry models where they reduce semantic mismatch, preserve source evidence, keep legal terms separate from executable code, and maintain one system of record across traditional and tokenized workflows.
Related terms
- Instrument Master Data
https://devancore.com/glossary/instrument-master-securities
The authoritative golden record of reference data — identifiers, static attributes, and lifecycle parameters — for every instrument a firm can trade, settle, or report.
- Smart Contract Risk in Financial Markets
https://devancore.com/glossary/smart-contract-risk-financial-markets
The operational and control risk created when deterministic smart contract code executes settlement, collateral, lifecycle, or books-and-records functions in financial markets.
- DLT Books and Records Financial Institution
https://devancore.com/glossary/dlt-books-and-records-financial-institution
The use of distributed ledger technology as books and records infrastructure for financial institutions, subject to the same substantive standards as traditional recordkeeping systems.
- Tokenized Collateral Repo Settlement
https://devancore.com/glossary/tokenized-collateral-repo-settlement
Repurchase agreements using tokenized securities as collateral, settled on distributed ledger infrastructure for atomic DvP and intraday availability.
- Securities Lending Operations
https://devancore.com/glossary/securities-lending-operations
The operational workflow that sources, manages, and recalls loaned securities — underpinning short selling and collateral financing through regulated locate and borrow processes governed by Regulation SHO Rule 203.
- Securities Lending Settlement
https://devancore.com/glossary/securities-lending-settlement
The two-leg settlement lifecycle of a securities loan — FoP delivery of loaned securities, daily mark-to-market margining, and sese.034 recall return — managed as a continuous operational process across the relevant settlement infrastructure.
- ISDA Digital Asset Derivatives
https://devancore.com/glossary/isda-digital-asset-derivatives
OTC digital asset derivatives documented under ISDA frameworks, covering confirmations, price sources, margin, collateral, close-out netting, and lifecycle controls.
- Trade Lifecycle Management
https://devancore.com/glossary/trade-lifecycle-management
The discipline of tracking a securities trade through every stage — from order and execution to settlement and position update — with exceptions detected at each handoff.
- Trade Enrichment Automation
https://devancore.com/glossary/trade-enrichment-automation
The automated augmentation of a raw trade capture with settlement instructions, counterparty identifiers, and regulatory fields required for clearing and settlement.
- Settlement Finality DLT Blockchain
https://devancore.com/glossary/settlement-finality-dlt-blockchain
The point at which an on-chain transaction becomes irrevocable — a property of the consensus mechanism rather than a declaration by any central infrastructure operator.
- Settlement Finality Securities
https://devancore.com/glossary/settlement-finality-securities
The irrevocable transfer of legal ownership in a securities transaction — achieved through deterministic, conditional, or probabilistic finality depending on the settlement rail.
- Delivery Versus Payment
https://devancore.com/glossary/delivery-versus-payment
A settlement mechanism (DvP) that links the transfer of securities to the simultaneous transfer of payment, ensuring neither leg completes without the other.
- Investment Book of Record
https://devancore.com/glossary/investment-book-of-record
The IBOR — a real-time position record used by investment managers, capturing unsettled trades, accruals, and corporate actions ahead of custodian confirmation and ABOR settlement.
- Accounting Book of Record
https://devancore.com/glossary/accounting-book-of-record
The ABOR: custodian-confirmed settled positions used as the authoritative basis for NAV calculation, financial statements, and regulatory reporting.
- Reference Data Management
https://devancore.com/glossary/reference-data-management
The governance and maintenance of static data that financial systems depend on — instrument identifiers, counterparty LEIs, and settlement rules — to process transactions correctly.
- Regulatory Reporting — Securities
https://devancore.com/glossary/regulatory-reporting-securities
The post-trade obligation to submit structured trade data — transactions, positions, and order lifecycle events — to regulators under MiFID II, EMIR, Dodd-Frank, and CAT to establish the supervisory record of each trade.
Contact
Request a briefing or platform walkthrough with the Devancore team.
Request access https://devancore.com/access