Devancore Inc.
Devancore Post-Trade Glossary
Glossary
Enterprise Data Management
Enterprise data management (EDM) in capital markets is the control plane that joins instrument, entity, account, market, calendar, SSI, and price masters so post-trade workflows share one approved version at event time.
Document source: https://devancore.com/glossary/enterprise-data-management/
Devancore Post-Trade Glossary
Enterprise Data Management
Enterprise data management (EDM) in capital markets is the control plane that joins instrument, entity, account, market, calendar, SSI, and price masters so post-trade workflows share one approved version at event time.
Definition
Enterprise data management (EDM) in capital markets is the control plane that makes several masters usable as one operating record. Instrument, entity, account, market, calendar, SSI, and price each have a source. Post-trade work consumes the join. If that join is ungoverned, settlement, accounting, and reporting inherit a quiet error that looks like an operations break.
Reference data management governs a domain. A securities master keeps the instrument copy. Enterprise data management is the enterprise layer that decides which version of each master a workflow may use, how conflicts are resolved, and how that choice is evidenced at event time.
Masters the operating join must hold
Masters the operating join must hold
A clean instrument record with a stale SSI or calendar is still an EDM break.
| Master | What it holds | Post-trade question |
|---|---|---|
| Instrument | Identifiers, terms, classification, and lifecycle attributes | Are all systems talking about the same security or token? |
| Entity | LEI, issuer, counterparty, parent chain, and status | Can exposure and reports roll up to the legal person that actually exists? |
| Account and book | Fund, desk, custody account, and book mapping | Did the event post to the book that settlement and accounting will use? |
| Market and calendar | MIC, trading phases, holidays, and settlement cycle | Was value date computed on the calendar that was in force on trade date? |
| SSI | Place of settlement, cash correspondent, and instruction set | Did the instruction use the standing details the custodian still honors? |
| Price and FX snapshot | Source, as-of time, and the quote actually consumed | Can valuation or NAV replay the price that was used, not today's file? |
The practical control problem is attribution. A fail can be an identifier split, a stale standing instruction, a holiday missing from the calendar, or a book mapping that sent the trade to the wrong custody account. If those facts live in separate spreadsheets, the break is investigated as a settlement mystery. If they live in one versioned join, the owner is obvious.
Golden source and system of record answer different questions. The OMS may be the system of record for the order. A vendor may be the system of record for a coupon. The golden source is the approved copy after hierarchy and maker-checker. Downstream systems should consume the approved copy, not whichever file arrived last.
Lineage is not the same as evidence. Lineage shows that a maturity date came from a vendor file. Evidence shows who approved an override, why the hierarchy was broken, and which consumer stamped that version onto a settlement instruction or a report. Without the second record, a later correction cannot explain what the firm actually used.
Event time matters. Calendars, SSIs, LEI status, and prices change. Computing a settlement date on today's holiday file for a trade booked last week is an EDM error, not a market error. The operating record must keep the version that was in force when the event occurred.
Enterprise data management — source to workflow gate
Devancore Glossary · devancore.com
Enterprise data management — source to workflow gate
Devancore Glossary · devancore.com
How it works
Enterprise data management works by ingesting sources, resolving conflicts, joining masters onto the event, gating the workflow, and retaining the version that was used.
EDM control points before a workflow may proceed
EDM control points before a workflow may proceed
Unapproved conflicts should stop instruct and report, not silently pick a vendor row.
| Step | Data required | Failure mode |
|---|---|---|
| Ingest | Vendor file, GLEIF, CSD, custodian SSI, OMS, and internal override | Two sources land with no recorded hierarchy or as-of |
| Conflict | Field-level trust rule, exception owner, and unmatched identifier | A 1bp coupon gap or split CUSIP/ISIN map is auto-published |
| Join | Instrument, entity, account, calendar, and SSI on the same event | The ISIN is right and the settlement still fails on SSI or holiday |
| Version | Event time versus current master, and which version was consumed | Today's calendar is applied to yesterday's trade |
| Gate | Required fields complete, override approved, consumer named | Enrichment proceeds while the SSI exception is still open |
| Evidence | Lineage, actor, reason, and the version stamped on the workflow | Operations can see the fail but cannot replay which master caused it |
Sources include market-data vendors, GLEIF for legal entities, CSD and custodian SSI files, OMS and PMS books, internal overrides, and price snapshots. Normalization maps identifiers, parties, accounts, venues, and calendars onto one model. Identifier mapping is a join rule. Two codes that point at different instruments must not be treated as one security.
Conflict handling is field-level. A firm may trust one source for equities and another for structured products. An uncovered disagreement belongs in a queue with an owner. Auto-publishing the last file received is how a 1bp coupon gap or a broken CUSIP-to-ISIN map reaches every downstream book.
The join is where EDM earns its name. Settlement instruction generation needs instrument plus SSI plus calendar plus account. Regulatory reporting needs instrument plus LEI plus venue. Custody reconciliation needs the same instrument identity the custodian uses. Asset servicing needs terms and issuer. If those consumers read locally cached copies that drifted, the masters were never enterprise.
Quality control is a gate, not a dashboard. Missing SSI, expired LEI, unmatched identifier, or unapproved override should block instruct or report for that event. Data quality management that only scores completeness still lets dirty records travel. Transfer agency, fund accounting, and custody systems are consumers. They are not a substitute for the gate.
Identifier mapping, SSI currency, and calendar version are the three silent fail sources most teams mislabel as counterparty error. A conversational query is useful only after those fields are records: which instructions used an SSI superseded last week, which trades computed value date on a calendar version dated after trade date, which reports stamped an LEI that was not active at event time.
Enterprise data management — source to operating join
Devancore · message matrix
| Rail | Message | Purpose | Record |
|---|---|---|---|
| Instrument | security master | identity and terms | ISIN, CUSIP, FIGI, DTI, coupon, factor, classification, and the map that keeps one instrument from splitting |
| Entity | party master | legal person | LEI, issuer, counterparty, parent chain, and status used for roll-up and reporting |
| Calendar | market diary | value date | MIC, holiday, settlement cycle, and the calendar version in force on trade date |
| SSI | settlement standing | instruction | place of settlement, cash correspondent, and the instruction set the custodian still honors |
| Evidence | approved version | replay | source hierarchy, override, actor, event-time stamp, and the consumer that used that version |
In Devancore™
Devancore — enterprise data management evidence chain
Devancore · evidence stack
Source ingest
Vendor, GLEIF, custodian SSI, OMS, and override files enter with source, as-of, and version.
Master join
Instrument, entity, account, market, calendar, SSI, and price snapshot stay attached to the same event.
Conflict state
Trusted, conflicting, overridden, or blocked is owned workflow, not a silent vendor pick.
Event-time version
The master used at booking, instruct, or report remains distinct from the master as later corrected.
Workflow evidence
Lineage, approver, consumer, and gate result stay with the operating record.
Devancore supports capital markets enterprise data management as a post-trade operating-record layer around masters, joins, conflict state, event-time versions, and the evidence a workflow consumed. It can help teams keep instrument, entity, account, calendar, SSI, and price lineage attached to settlement, recon, and reporting events.
Devancore does not act as a data vendor, golden-source utility, SSI agent, or official identifier registrar. It does not issue ISINs, LEIs, or DTIs, and it does not replace the appointed master-data owners. The product boundary is the controlled operating copy of the join that post-trade already depends on.
In a Devancore-style workflow, a vendor file, SSI update, LEI change, calendar amendment, price snapshot, or override enters as a source event. The record is mapped to master type, field, version, consumer, and workflow state. Trusted, conflicting, overridden, gated, or consumed remains visible with actor, timestamp, reason, and source reference.
That structure is what operations actually use. The vendor may know the coupon. The custodian may know the SSI. Accounting may know the book. The operating question is whether those facts still join as one approved version when a fail, a NAV, or a report has to be explained.
Conversational finance depends on the same chain. A user can ask which settlement fails trace to SSI changes, which value dates used a later calendar than trade date, which instruments have split identifier maps, or which overrides lack an approver. The answer should resolve to masters, versions, consumers, owners, and evidence.
Related terms
- 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.
- Securities Master Data
https://devancore.com/glossary/securities-master-data/
The operational discipline of maintaining a firm's golden copy — the single authoritative securities reference record kept current through daily vendor scrubbing, conflict resolution, and event-driven lifecycle enrichment.
- Legal Entity Identifier (LEI)
https://devancore.com/glossary/legal-entity-identifier/
20-character alphanumeric code under ISO 17442 that uniquely identifies legal entities in financial transactions, required for MiFID II, EMIR, and CAT regulatory reporting, and the primary party identifier in ISO 20022 sese.023 settlement instructions.
- Securities Identifiers ISIN and CUSIP
https://devancore.com/glossary/securities-identifier-isin-cusip/
ISIN and CUSIP are the alphanumeric codes that uniquely identify financial instruments — referenced in almost every trade capture, matching, settlement instruction, and regulatory report.
- Digital Token Identifier (DTI)
https://devancore.com/glossary/digital-token-identifier/
A globally unique identifier under ISO 24165 that fingerprints a digital token by blockchain network, smart contract address, and genesis parameters.
- FIGI Instrument Identifier
https://devancore.com/glossary/figi-instrument-identifier/
An open 12-character financial instrument identifier used to normalize securities, listings, share classes, and vendor symbols across systems.
- 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.
- 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.
- CSD Reference Data
https://devancore.com/glossary/csd-reference-data/
The governed reference layer for CSD identity, market coverage, participants, settlement calendars, eligible securities, notices, and source evidence.
- 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.
- Custody Reconciliation
https://devancore.com/glossary/custody-reconciliation/
Custody reconciliation is the daily match of internal positions and cash to the custodian statement: timing versus genuine breaks, owners, aging, and the evidence that holdings are actually safekept.
- 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.
Contact
Request a briefing or platform walkthrough with the Devancore team.
Request access https://devancore.com/access/