SD-15.14 — Client & Investor Reporting

Business Domain: BD-15 Distribution, Product & Client Management (Commercial) · Applies: BOTH

Purpose

Produces the discretionary, relationship-driven reporting and communication the firm gives its clients and investors. SD-15.14 is the commercial reporting capability: the bespoke client reports, the investor portal, the relationship reviews and the client communication the firm produces to inform, engage and retain its clients. It is distinct from accountability reporting: SD-16.2 Owner & Investor Reporting produces the mandatory periodic report the firm owes the parties it answers to; SD-15.14 produces the discretionary, commercially-motivated reporting the firm chooses to produce to serve the relationship. It is not internal investment reporting (SD-13.10), and it does not compute the numbers — it consumes them.

Service Operations

Produce bespoke client reporting — produce the tailored client and investor reports, to the format, frequency and content the relationship calls for.
Run the investor portal — provide and run the digital client and investor portal and the self-service reporting.
Run relationship reviews — prepare and support the periodic relationship and portfolio reviews with the client.
Manage client communication — produce the proactive client communication — market updates, portfolio commentary, event-driven notices.
Govern the client-reporting standard — maintain the firm’s client-reporting templates, standards and data sourcing.

Inputs and outputs

Inputs: the internal investment-reporting data from SD-13.10; the governed metric definitions from SD-13.8; performance from BD-09, including the probability-of-meeting-goal forward-looking measure from SD-09.5 for wealth-manager goals-based client reporting; the NAV and capital accounts from SD-12.9; investor dealing data from SD-12.15.
Outputs: client and investor reports, the portal and the client communication — consumed by the firm’s clients and investors and SD-15.13.

Entities

Consumes: the performance, NAV and holdings data; E-01 Legal Entity (the client / investor); FO-01 Fund Product (the issued-fund product the reporting covers — fund name, legal structure, regulatory wrapper and status from FO-01 populate the fund-level header of client reports); FO-02 Share / Unit Class (the class the reporting covers — class ISIN, distribution policy, class_currency and class_fee_schedule on FO-02 populate class-level report headers and fee disclosures; the class is the grain at which the investor’s holding and NAV per unit are reported); FO-03 Investor Unitholding (the per-investor, per-class unit balance and cost basis — the register position that drives the investor’s unit statement, the holdings section of the client report, and the distribution entitlement calculation); FO-04 Dealing Order (from SD-12.15 — the period’s subscription, redemption and switch events that populate the dealing-activity section of the client report); FO-05 Fund Distribution Event (from SD-12.7 — the income distribution declarations and amounts that populate the income section of the client report); FO-06 Fee Accrual (the net_charge by fee_type and the OCF/TER reconstruction chain — the fee amounts and the gross-to-net breakdown (gross accrual, waiver/cap, reimbursement, net charge) feed the class-level fee-disclosure sections of client and investor reports); FO-07 Investor Tax Statement (from SD-17.4 — the investor’s annual tax statement furnished as part of the annual reporting pack; SD-15.14 includes FO-07 in the client communication where the tax-document is part of the reporting relationship); the SD-12.15 investor dealing data; the SD-12.9 NAV and capital accounts; the SD-13.10 internal investment-reporting data; the SD-13.8 governed metric definitions; the SD-09.5 probability-of-meeting-goal measure (for wealth-manager goals-based client reporting); E-33 Financial Plan (from SD-15.15 — the structured plan that drives the household’s plan-based reporting); E-35 Complaint Record (from SD-15.16 — per-client complaint history where the reporting relationship calls for it).
Owns: the client-reporting package — a process artefact.

Standards

No single external standard governs commercial client reporting; the UK Consumer Duty consumer-understanding outcome bears on it.
The GIPS-compliant presentations (SD-09.6) feed the performance content.

Design notes

Investor statement as a derived rendering

The investor’s periodic statement — showing unit balance, period dealing activity, distributions received, NAV-per-unit valuations, and fees borne — is a computed rendering of figures of record already in the model. It is not a stored entity in its own right. The derivation is:

Unit balance and cost basis — FO-03 Investor Unitholding (the register position at the start and end of the period).
Dealing activity — FO-04 Dealing Order records (subscriptions, redemptions, switches, transfers) settled during the period.
Distributions received — FO-05 Fund Distribution Event records (the per-unit income distribution and the investor’s entitlement based on FO-03 units_held at the ex-date).
NAV-per-unit valuations — the class-grain E-07 Valuation records (produced by SD-12.9 at each pricing point; the struck NAV-per-unit series the statement shows).
Fees borne — FO-06 Fee Accrual (net_charge by fee_type, the OCF/TER reconstruction chain, from SD-12.11).

No new entity is needed for the statement itself. The liability attaches to the figures, not to the report format. SD-15.14 consumes these figures and formats them for the client relationship; SD-16.2 consumes the same figures for the mandatory accountability report. The rendering is a process artefact; the figures are the records of truth. This follows the same principle as the KIID/KID design note in SD-12.9 — the document is the rendering of figures of record, never a separate stored source.

Non-derivable residue. The statement’s issuance and dispatch record (date furnished, channel, acknowledgement) is an operational process artefact tracked within the transfer-agency or investor-services workflow. If compliance requires proof-of-issue at investor grain, a light dispatch-log sub-record within the investor-services workflow is sufficient; it is not a model-layer entity.

Guideline compliance vs investor reporting — two different accountabilities

Two reporting accountabilities must not be conflated:

Mandate and guideline compliance reporting (the SD-10.x spine) answers the question: did the portfolio stay within the rules it must obey? This is an internal / mandate matter — a breach event (E-18 Limit Breach) is raised by SD-10.1 and managed by SD-10.8; the reporting is to the firm’s second-line compliance function, fund boards and the regulator. The liability for a breach is internal and regulatory. The SD-10.x spine (nine Service Domains — investment guideline monitoring, rule coding, regulatory compliance, side-letter and fund-term compliance, sanctions screening, trade surveillance, breach management, ESG compliance) owns this accountability entirely.
Investor reporting (the SD-15.x / SD-16.x spine) answers the question: what did we tell the investor about their holding, performance and costs, and was it correct? This is an external-facing, investor-liability matter. A wrong NAV-per-unit disclosed to an investor (or a wrong fee in the KID) is not a guideline breach — it is an investor-liability, potentially regulatory, event. The records that back investor reporting are the figures of record on the deterministic spine: E-07 Valuation (the struck NAV-per-unit, produced by SD-12.9), FO-06 Fee Accrual (the computed fee figure, produced by SD-12.11), FO-03 Investor Unitholding (the register position), FO-04 Dealing Order, FO-05 Fund Distribution Event. SD-15.14 (commercial, discretionary) and SD-16.2 (mandatory accountability) own this accountability.

The two accountabilities share the same portfolio and instrument universe but answer to different principals, carry different liabilities, and are served by different Service-Domain spines. A model or system design that conflates them — routing investor-reporting obligations into the compliance function or vice versa — creates governance gaps. The separation is architecturally load-bearing.

Open extensions

The client-reporting-template sub-model.
The Service-Operation-level input/output contracts.