BD-13 — Investment Data & Reporting

Office: Cross-cutting (data).

Maturity: Provisional · 12 Service Domains across the master-data, market-and-reference-data, document-ingestion, semantic-and-metric, ESG-data, and reporting capabilities

The Business Domain that holds the firm’s data estate — the masters, the feeds, the definitions, the platform — and turns it into reporting. Where the front office decides, the middle office measures, and the back office keeps the books, BD-13 is the layer underneath all three: it owns the golden records every other domain reads, the market and reference data those domains run on, the governed metric definitions they calculate to, and the reporting and dashboards through which the institution sees itself. It is cross-cutting by construction — no domain in BD-01 to BD-12 holds its own master data; they consume BD-13’s.

Each Service Domain below is its own file: the definition, its Service Operations, the entities it consumes and produces, the external standards it conforms to.

Service Domains

Archetype activation

Every archetype — activated wholesale, differentiated primarily by asset-class exposure and, for SD-13.3, by fund-manufacturing activity. Every buy-side institution in the seven-archetype panel (TPAM / DBP / SWF-E / INS / WM / OCIO / HF) runs BD-13’s instrument and entity masters, market and reference data, the metric layer and investment reporting in the same shape. The differentiation across archetypes runs primarily on the asset-class axis, with one archetype-driven exception noted below:

• SD-13.3 Investment Vehicle & Fund Master is now tagged BOTH and activates across two complementary facets. The allocator facet (PM-01 — the commitment-vehicle view) activates in proportion to private-markets holdings. The manager / issuer facet (FO-01 — the issued-product view) activates for any archetype that manufactures funds — a pure-public-markets UCITS/ETF manager with no private holdings still activates this facet. An institution with no fund-manufacturing activity and no private-markets holdings leaves SD-13.3 dormant entirely.
• SD-13.6 GP & manager report ingestion activates in proportion to private-markets holdings.
• No archetype leaves a BOTH-tagged BD-13 Service Domain dormant.

(BD-13’s panel substitution is the “every-archetype, primarily-asset-class-driven” case under the panel-substitution discipline declared in service-domains/INDEX.md, with SD-13.3’s manager facet as the one archetype-driven activation exception.)

Wider-source grounding

The decomposition is grounded against external industry references:

• The DAMA-DMBOK (Data Management Body of Knowledge) — the data-governance, stewardship and master-data-management disciplines behind SD-13.1 / SD-13.2 / SD-13.3 (the three masters) and SD-13.7 Data Quality & Governance.
• The EDM Council DCAM (Data Management Capability Assessment Model) — the financial-services-specific data-management capability model; the closest external analogue to BD-13 as a whole, and the completeness cross-check for the domain’s data-estate-to-reporting shape.
• GLEIF’s Legal Entity Identifier, ISO 6166 ISIN, and the instrument-identifier ecosystem (FIGI, CUSIP) — the identifier standards behind SD-13.1 Instrument & Security Master and SD-13.2 Entity & Counterparty Master, and the concrete evidence for the no-universal-identifier design driver noted below: these registries cover listed public-markets instruments and entities, but private-markets vehicles, GPs and unlisted assets routinely fall outside them, which is why resolution and alias structures are first-class here rather than an afterthought.
• ISO 20022 and SWIFT reference-data messaging — the market-and-reference-data feed standards behind SD-13.4 Market & Reference Data Management.
• The CFA Institute Code of Ethics and Standards of Professional Conduct — Standard V(B) Communication with Clients and Prospective Clients and Standard V(C) Record Retention — the record-keeping and client-reporting obligations behind SD-13.10 Investment Reporting & Dashboards and SD-13.11 Document & Content Management.
• FinDatEx’s European ESG Template (EET), developed with EFAMA participation as the industry-standard data-exchange format for SFDR-related sustainability data between managers and distributors — behind SD-13.9 ESG & Sustainability Data.
• SFDR’s Principal Adverse Impact indicators, the CSRD, and the ISSB’s IFRS S1 / S2 — the source-side sustainability-disclosure regimes SD-13.9 sources issuer- and holding-level ESG and climate data against. This is distinct from BD-16’s SD-16.5, which reports the firm’s own disclosures under these same regimes — SD-13.9 is the data intake, SD-16.5 is the accountable output.
• The buy-side platform data modules (Aladdin, SimCorp, State Street Alpha, SS&C / eFront) as a completeness cross-check on the master-data, reference-data and reporting sub-capability cluster.

Non-overlap — where the boundaries run

Service Domains are non-overlapping by construction. The boundaries inside and around BD-13 worth stating, because the topics look adjacent:

• SD-13.1 vs SD-13.2 vs SD-13.3 — the three masters. OpenIM keeps three separate master Service Domains because they curate three different kinds of golden record with three different lifecycles. SD-13.1 owns the instrument golden record (E-02 and its public-markets specialisations) — the holdable thing. SD-13.2 owns the legal-entity / party golden record (E-01) — issuers, counterparties, managers, custodians, administrators, all as roles of one party master. SD-13.3 owns the investment-vehicle / fund golden record across two facets: the allocator facet (PM-01 Fund & Vehicle — the fund as an instrument an LP holds and a structure with terms, vehicles and a manager) and the manager / issuer facet (FO-01 Fund Product — the fund as a product the issuing manager registers, prices and distributes). A fund interest is an instrument (PM-01 specialises E-02), so SD-13.1 and SD-13.3 touch the same conceptual record: SD-13.1 owns the generic instrument shell, SD-13.3 owns the fund-specific structure, terms and family hierarchy (allocator facet) plus the product-lifecycle, dealing-terms and regulatory-authorisation attributes (manager facet).
• SD-13.1 vs SD-13.4. SD-13.1 Instrument Master holds the durable, slow-changing attributes of an instrument — what it is, its identifiers, its static terms, its classification. SD-13.4 Market & Reference Data Management sources the feeds — including the vendor instrument-reference feeds SD-13.1 is populated from, and the fast-moving market data (prices, rates, FX) that is not master data at all. SD-13.4 is the data-supply pipe; SD-13.1 is the curated golden record at the end of it.
• SD-13.2 vs SD-13.1 — shared resolution machinery. Both masters carry alias (E-13) and external-identifier (E-14) structures and run entity resolution. They are still two Service Domains: an instrument and a legal entity resolve on different evidence, are stewarded by different people, and serve different consumers. The resolution pattern is shared; the records are owned separately.
• SD-13.5 vs SD-09.4 (cross-Business-Domain). SD-09.4 Benchmark Management selects and constructs the benchmark a portfolio is measured against — a front/middle-office judgement. SD-13.5 Benchmark & Index Data Management holds and maintains the benchmark as a data asset — the E-10 header and the PB-09 constituent rows. SD-09.4 decides which benchmark; SD-13.5 owns the data. A custom benchmark SD-09.4 constructs becomes an E-10 record SD-13.5 then maintains.
• SD-13.5 vs SD-13.4. SD-13.5 is the specialised master for benchmark and index data because index data has its own lifecycle — effective-dated constituent membership, rebalances, reconstitutions, provider methodology. SD-13.4 distributes general market and reference data; the index-constituent estate is heavy and distinct enough to warrant its own Service Domain rather than being one feed inside SD-13.4.
• SD-13.4 Market & Reference Data Management vs BD-08 Valuation & Pricing (cross-Business-Domain). SD-13.4 delivers raw market data — the feeds, the curves, the reference prices — as a data-management capability; it owns Price & Market Data (E-08). BD-08 turns that data into a governed valuation of the firm’s actual holdings; it owns Valuation (E-07). A raw vendor price is SD-13.4’s; the firm’s chosen, validated price for a position it holds is SD-08.1’s.
• SD-13.6 vs SD-12.7 / SD-12.8 (cross-Business-Domain). SD-13.6 GP & Manager Report Ingestion is the unstructured-data on-ramp — it parses the capital-account statement, the quarterly report, the capital-call notice into structured data and validates it. SD-12.7 Income & Distribution Processing and SD-12.8 Capital Call & Distribution Processing then process the operational event — booking the cash, the accounting, the waterfall. SD-13.6 turns the document into data; BD-12 acts on the event. The split is data-capture versus transaction-processing.
• SD-13.8 vs the analytics in BD-09 (cross-Business-Domain). SD-13.8 Semantic & Metric Layer holds the governed definition of a metric — what “time-weighted return” or “TVPI” formally means, its calculation logic, its certified inputs. BD-09 computes the metric to that definition. SD-13.8 owns the definition as data; BD-09 owns the calculation as a capability. One metric, defined once in SD-13.8, computed by whichever domain owns the result.
• SD-13.9 ESG & Sustainability Data vs SD-07.8 Climate Risk Analytics (cross-Business-Domain). SD-13.9 sources and manages ESG and climate data — scores, ratings, controversy flags, impact metrics, issuer- and asset-level emissions data — as a data asset, the same way SD-13.4 manages market data. SD-07.8 Climate Risk Analytics (BD-07 Investment Risk) produces analytics — carbon footprints, physical- and transition-risk measures, net-zero pathway tracking — computed over holdings and over the data SD-13.9 supplies. SD-13.9 is a data-management Service Domain; the climate analytics it feeds are a risk capability, in BD-07. Climate data is part of SD-13.9 — there is no separate climate-data Service Domain.
• SD-13.10 vs BD-16 reporting (cross-Business-Domain). SD-13.10 Investment Reporting & Dashboards produces internal investment reporting — portfolio reporting, management dashboards, the ad-hoc query service for investment staff. The external, accountable reporting is BD-16’s: SD-16.2 owner & investor reporting, SD-16.3 regulatory filings, SD-16.4 financial disclosure. SD-13.10 serves the firm looking at itself; BD-16 serves the firm answering to others. BD-16’s reporting Service Domains consume SD-13.10’s data and the SD-13.8 metric definitions but apply their own audience, format and assurance.
• SD-13.11 vs SD-13.6. SD-13.11 Document & Content Management is the repository — it holds documents, runs deal rooms, indexes content, enforces retention. SD-13.6 is the extraction capability that reads a manager document and turns it into structured data. SD-13.11 stores and governs the document as an artefact (E-15); SD-13.6 mines it. A capital-account statement lives in SD-13.11’s repository and is parsed by SD-13.6.
• SD-13.12 vs every other BD-13 Service Domain. SD-13.12 Data Platform & Integration Services is the infrastructure — pipelines, integration, the warehouse / lakehouse — beneath the whole estate. The other eleven Service Domains are capabilities that run on that platform. SD-13.12 moves and lands data; it does not own, define or interpret it. It is the BD-13 analogue of an infrastructure layer, deliberately separated from the data-curation capabilities so that platform engineering and data stewardship are not conflated.
• SD-13.10 self-service enablement vs SD-13.12 environment provisioning. Both Service Domains “provision an environment”, and the boundary is the layer. SD-13.10 provisions the analytical self-service environment — the governed, semantic-layer-backed surface on which an analyst builds a view inside the certified-data perimeter. SD-13.12 provisions the platform environments — the production / test / development data stores and the compute beneath them. SD-13.12 stands up the infrastructure; SD-13.10 enables the analyst on it.

Design notes

• Three master Service Domains, not one. A single “Reference Data Management” Service Domain is the common shortcut. OpenIM splits it three ways — instrument, entity, vehicle — because the masters have genuinely different lifecycles, stewards and resolution evidence, and because the fund master (SD-13.3) covers both the private-markets commitment-vehicle view (PM-01, the capability the liquid-markets vendor stacks were never built for) and the manager-side issued-product view (FO-01, activated for any fund-manufacturing archetype). The instrument and entity masters are BOTH; the fund master is now BOTH (covering both allocator and manager facets).
• The no-universal-identifier reality is a BD-13 design driver. Every OpenIM master carries an internal golden key, an alias set (E-13) and an external-identifier map (E-14), and assumes entity resolution rather than a shared key. That design choice lives in BD-13: SD-13.1, SD-13.2 and SD-13.3 are the Service Domains that run resolution. Public markets resolve mostly on identifiers; private markets resolve mostly on aliases. The model serves both because resolution is a first-class capability, not an afterthought.
• Data management is split from analytics throughout. SD-13.4 / SD-13.5 / SD-13.9 manage data; SD-13.8 defines metrics; BD-07 and BD-09 produce analytics and compute performance. The recurring boundary — a data-management Service Domain feeds an analytics capability that consumes it — is applied consistently so that no Service Domain both sources data and interprets it. Climate analytics sit in BD-07 as SD-07.8 Climate Risk Analytics; the climate data sits here, in SD-13.9.
• SD-13.8 Semantic & Metric Layer is an OpenIM addition, not a benchmark-framework capability. The external buy-side capability frameworks (BIAN, the EFAMA / IA value chain, the consultancy operating models) do not name a discrete semantic-and-metric-definition capability — it is a data-architecture pattern OpenIM elevates to a Service Domain deliberately, because an agent-native model needs the “what does this number mean” definition to be a governed, addressable capability rather than an implicit convention. The addition is sourced from data-architecture practice (the semantic-layer / metric-store pattern), not from the benchmark frameworks; it is recorded here so the divergence is explicit and not mistaken for a framework-derived domain.
• SD-13.6 GP & Manager Report Ingestion is a PRIV Service Domain in its own right. It is one of OpenIM’s named frequently-omitted domains: the unstructured-data on-ramp for the entire private-markets book, routinely treated as a data-entry afterthought rather than a governed capability. Public markets have no equivalent because their data arrives structured, from feeds (SD-13.4) — so there is no public-markets counterpart Service Domain, and this asymmetry is deliberate.

How BD-13 relates to the rest of the model

• Consumes the source-side artefacts that populate the data estate — vendor and administrator feeds, manager documents (E-15 Document Metadata), the index-provider universes — and the structured records every transactional domain produces (Holding E-04 any book, Transaction E-05, Cash Flow Event E-06, Valuation E-07 any method) when assembling reporting and certified datasets. SD-13.10 also consumes Risk Measurement (E-19, any risk_type); SD-13.4 / SD-13.9 consume External Identifier (E-14) across the instrument-side and entity-side partitions to join vendor feeds; SD-13.6 consumes Entity Alias (E-13) across the entity-side and fund-side partitions for resolution. It also consumes the front- and middle-office decisions that give data its business meaning: the SD-09.4 benchmark assignment, the SD-08 valuation policy, the BD-01 mandate definitions.
• Owns the firm’s data masters and the data layer’s governed artefacts: SD-13.1 owns E-02 Instrument / Asset and the public-markets instrument specialisations (PB-01, PB-02, PB-08; the derivative instrument shells DR-01, DR-02; the directly-held real asset RA-01); SD-13.2 owns E-01 Legal Entity (and its role-faceted specialisations PM-02, PM-03, PM-04, PM-11); SD-13.3 owns PM-01 Fund & Vehicle, FO-01 Fund Product, PM-05 Legal Vehicle and PM-10 Fund Terms; SD-13.4 owns E-08 Price & Market Data and E-09 Asset Class; SD-13.5 owns E-10 Benchmark / Index, PB-09 Index Constituent and PM-12 Benchmark Cross-Reference; SD-13.6 owns E-23 Extraction Record; SD-13.7 owns E-11 Classification Type & Value and E-12 Classification History; SD-13.8 owns E-22 Metric Definition; SD-13.9 owns E-21 ESG Measurement; SD-13.11 owns E-15 Document Metadata. Aliases (E-13) and external identifiers (E-14) are partitioned across SD-13.1 / SD-13.2 / SD-13.3 per the master kind.
• Feeds essentially every other Business Domain. The masters (SD-13.1 / SD-13.2 / SD-13.3) supply the golden records BD-01 to BD-12 all read; market and reference data (SD-13.4) and benchmark data (SD-13.5) supply the pricing, valuation and performance domains (BD-08, BD-09); the semantic layer (SD-13.8) supplies the governed metric definitions BD-07, BD-09 and BD-12 calculate to; ESG and climate data (SD-13.9) feeds the climate-risk analytics (SD-07.8), portfolio diagnostics (SD-09.5), risk (BD-07) and stewardship (SD-12.12); reporting (SD-13.10) is the internal-reporting surface, and its data and definitions feed the external, accountable reporting of BD-16. The data platform (SD-13.12) is the substrate the entire firm’s data movement runs on.