Devancore Inc.
Devancore Post-Trade Glossary
Glossary
CSD Reference Data
The governed reference layer for CSD identity, market coverage, participants, settlement calendars, eligible securities, notices, and source evidence.
Document source: https://devancore.com/glossary/csd-reference-data
On this page
Actions
Devancore Post-Trade Glossary
CSD Reference Data
The governed reference layer for CSD identity, market coverage, participants, settlement calendars, eligible securities, notices, and source evidence.
Definition
What is CSD reference data?
CSD reference data is the governed data layer that describes central securities depositories and related settlement infrastructure. A central securities depository is the infrastructure that holds securities and executes settlement finality. CSD reference data is the operating record that makes that infrastructure usable by systems.
A complete CSD reference record answers practical questions: which CSD serves this market, which legal entity operates it, which country and market profile does it belong to, which instruments are eligible, which settlement calendar applies, which participants or account structures matter, which notices or downloads should be monitored, and what evidence supports each field?
This is not the same as a static list of depository names. Institutional post-trade systems need source-backed, effective-dated, reviewable infrastructure data. A CSD name without source evidence is not enough. A CSD website without a retrieved date is not enough. A public notice without review status is not enough. The value is in turning public and internal infrastructure knowledge into controlled operating data.
CSD reference data domains
The record turns settlement infrastructure into controlled operating data.
| Domain | Examples | Operational use |
|---|---|---|
| CSD identity | Name, acronym, country, operating entity | Market infrastructure map and settlement route selection |
| Entity linkage | LEI, regulator, operator, ownership group | Entity controls, onboarding, and audit evidence |
| Market coverage | Country, exchange links, MIC context, eligible asset classes | Instrument eligibility and market master data |
| Participant context | Members, account structures, access model | Settlement instruction routing and counterparty setup |
| Settlement rules | Cycle, DvP model, finality event, cutoffs | Fail prevention, finality tracking, operating calendar |
| Public sources | Sitemaps, notices, RSS feeds, PDFs, XLS, CSV, XML, APIs | Source refresh, evidence capture, machine-readable updates |
| Review status | Raw, normalized, reviewed, approved | Control boundary before production use |
CSD reference data sits inside market master data. The market master describes the country, currency, venue, tax, sanctions, and infrastructure context. The CSD record supplies the settlement infrastructure layer inside that profile. It links market identity to settlement routing, finality, reconciliation, and evidence.
CSD data versus adjacent records
CSD reference data connects market, instrument, and settlement records.
| Record | Primary question | Connection to CSD data |
|---|---|---|
| Instrument master | What instrument is this? | Needs CSD eligibility, settlement location, and safekeeping context |
| Market master | Which market and jurisdiction does this belong to? | Stores CSD as part of market infrastructure |
| MIC | Where did the trade execute? | May differ from settlement location and CSD route |
| SSI | How should the settlement instruction be delivered? | Needs CSD, custodian, account, and participant details |
| IBOR | What position does the firm expect? | Must reconcile expected position to CSD-confirmed finality |
| ABOR | What position is booked for accounting? | Needs evidence that settlement finality and cash movement occurred |
The most important distinction is venue versus settlement infrastructure. A Market Identifier Code can describe the execution venue or market segment. It does not necessarily identify the CSD that will hold or settle the position. A trade can execute in one market context, clear through a CCP, settle through a CSD, and be held through a custodian or sub-custodian chain. CSD reference data keeps those layers separate.
CSD reference data also has a source-discovery dimension. Public CSD websites often publish notices, participant lists, fee schedules, eligible securities, settlement calendars, regulatory disclosures, XML or CSV downloads, PDFs, sitemaps, RSS feeds, and API candidates. Those sources can be useful, but only if they are captured with provenance and review status.
The purpose is not to scrape everything. The purpose is to know which public sources exist, which ones matter, how they map to operating fields, and whether they are strong enough to support automation.
CSD reference data — settlement infrastructure record
Devancore Glossary · devancore.com
How it works
How CSD reference data works
The first step is infrastructure identification. The system identifies the CSD or equivalent post-trade infrastructure for a country, market, or asset class. The record should store the CSD name, acronym, country, domain, operator, regulator or oversight context where known, and legal entity identifier where available.
The second step is source discovery. A useful CSD reference layer records machine-readable access points and important public pages: robots.txt, sitemaps, RSS or Atom feeds, OpenAPI or Swagger candidates, CSV files, XLS files, XML files, JSON files, PDFs, participant pages, notices, settlement calendars, fee schedules, corporate-action pages, eligible-security lists, and rulebook pages.
The third step is classification. Not every discovered source has the same operational meaning. A marketing page, rulebook PDF, daily notice, settlement calendar, participant list, and eligible-securities file should not be treated the same way. Each source should be classified by page type, file type, expected refresh pattern, source owner, and downstream field relevance.
The fourth step is normalization. CSD source data should map into controlled fields: CSD identity, market coverage, country, currency, MIC links, settlement cycle, finality model, participant model, account structure, eligible instruments, notices, calendar dates, source URL, retrieved date, and review status.
CSD reference data failure modes
Infrastructure data errors usually show up as settlement or evidence failures.
| Failure | Where it appears | Likely impact |
|---|---|---|
| Missing CSD link | Settlement routing | Manual instruction repair or wrong custodian path |
| Stale settlement calendar | Settlement date calculation | Wrong intended settlement date and preventable fails |
| Wrong eligibility assumption | Instrument onboarding | Instrument routed to a CSD that cannot settle it |
| Weak participant mapping | SSI and account setup | Instruction rejects, matching breaks, reconciliation gaps |
| Unreviewed public source | Controls and audit | No evidence that the rule was current or approved |
| Venue confused with CSD | Market operations | Execution venue treated as settlement infrastructure |
The fifth step is review. Public data is not automatically production data. A discovered page may be stale, incomplete, translated, duplicated, blocked, redirected, or only partially relevant. CSD reference data should preserve raw source evidence while separating raw, normalized, reviewed, and approved records.
The sixth step is distribution. Once reviewed, CSD reference data can support standing settlement instructions, settlement date calculation, finality tracking, reconciliation, trade lifecycle management, and audit evidence. Downstream systems should consume the governed CSD record rather than each module interpreting CSD websites independently.
The control principle is simple: settlement infrastructure data should be traceable from system behavior back to source evidence.
CSD reference data — source to control workflow
Devancore Glossary · devancore.com
CSD reference data — source to control workflow
Devancore Glossary · devancore.com
In Devancore™
CSD data quality — automation boundary
Devancore Glossary · devancore.com
CSD reference data in Devancore
Devancore treats CSD reference data as part of the market intelligence and settlement-control layer. The platform can connect CSD identity, country, MIC context, settlement infrastructure, source evidence, and review status into the same operating record used by trade enrichment, settlement routing, finality tracking, and reconciliation.
In market onboarding, CSD reference data helps determine which settlement infrastructure belongs to a country or market profile. That record can be linked to currencies, venues, MICs, eligible instruments, participant access models, settlement calendars, and source evidence. This gives the market master data layer a settlement backbone.
In trade enrichment, the CSD record helps distinguish execution context from settlement context. A trade may arrive with an instrument identifier and MIC. Devancore can use the instrument master, market master, and CSD record to determine whether the trade needs CSD settlement, custodian routing, ICSD treatment, cross-border handling, or manual review.
In settlement operations, CSD reference data supports routing, validation, and exception handling. The workflow can check whether the instrument is eligible for the expected infrastructure, whether the settlement calendar is current, whether the intended settlement date is valid, and whether the account or participant path is complete enough to generate an instruction.
In finality tracking, Devancore uses CSD context to record where settlement finality occurred and which evidence supports it. A DTC-confirmed position, an ICSD-settled position, a foreign CSD position, and an on-chain finality event may all update the same economic position view, but they do not share the same infrastructure, legal basis, or evidence trail.
In controls, CSD reference data gives reviewers a better audit package. A reviewer can see the CSD source, retrieved date, file or page type, review status, settlement rule, and downstream workflow that consumed the record. That is stronger than relying on undocumented operational memory.
Devancore's approach is conservative: discover sources, preserve raw evidence, classify access points, normalize into controlled records, require review before production reliance, and keep CSD finality distinct from execution venue and on-chain settlement.
Related terms
- Central Securities Depository (CSD)
https://devancore.com/glossary/central-securities-depository
The financial market infrastructure that holds securities in book-entry form and executes DvP settlement finality — the legal transfer of ownership that converts a CCP's netted instruction into a confirmed change in beneficial ownership.
- Market Master Data
https://devancore.com/glossary/market-master-data
The authoritative reference layer for countries, currencies, venues, CSDs, settlement rules, tax signals, sanctions evidence, and market infrastructure.
- Market Identifier Code (MIC)
https://devancore.com/glossary/market-identifier-code-mic
The ISO 10383 four-character code that identifies trading venues, operating markets, and market segments for enrichment, reporting, and post-trade routing.
- 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.
- 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.
- Standing Settlement Instructions
https://devancore.com/glossary/standing-settlement-instructions
Pre-agreed instructions specifying how a counterparty's securities and cash should be delivered or received, applied automatically to every qualifying trade.
- 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.
- NSCC Continuous Net Settlement
https://devancore.com/glossary/nscc-continuous-net-settlement
DTCC's central counterparty that novates equity trades, nets obligations multilaterally by CUSIP, and carries unsettled positions until DvP finality at DTC.
- Central Counterparty Clearing (CCP)
https://devancore.com/glossary/ccp-central-counterparty-clearing
Financial market infrastructure that legally interposes itself as the counterparty to every trade through novation, eliminates bilateral credit risk, and reduces settlement volume through multilateral netting.
- 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.
- System of Record Securities Operations
https://devancore.com/glossary/system-of-record-securities-operations
The authoritative single source of truth for a firm's positions, trades, and accounts — the system of record that all other systems, reports, and compliance functions derive from.
- 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.
Contact
Request a briefing or platform walkthrough with the Devancore team.
Request access https://devancore.com/access