Trace VCC Investor-Reporting Data Lineage

Define the reporting population

Start with the exact VCC, sub-fund, share class, reporting period, investor population and approved template. Record whether the output is a capital statement, performance report, notice, factsheet or bespoke institutional schedule. The ACRA structure model matters because an umbrella contains independently operated sub-funds, while MAS materials place emphasis on effective fund-management governance and control. Do not build one undifferentiated lineage map across strategies. Identify the responsible manager, administrator, transfer process and data owner for each output, then freeze the report version before tracing fields. A report can be numerically correct and still fail operationally if it uses the wrong population, share class, currency, cut-off or delivery list.

Related guidance: Singapore VCC operating guide · VCC sub-fund guide

Build the field lineage register

Keep one row for each material field rather than one row for the whole report. NAV, units, subscriptions, redemptions, distributions, fees, expenses, performance, benchmarks and narrative disclosures can have different owners and source paths. Where a field is copied from another approved output, link that output and its version instead of treating the copied number as a new source. Record manual overlays openly. A spreadsheet cell without an owner, formula version or source reference is not lineage. For estimates or valuation judgments, point to the approved decision record and identify the final accepted input, not merely the draft received from a provider.

Reconcile transformations and exceptions

Test the lineage in both directions. Forward testing follows selected source records through transformations into the released report. Reverse testing starts with a reported value and reproduces it back to source. Differences should enter an exception queue with effect, owner, decision authority and closure evidence. A correction is not closed when one spreadsheet changes. Recalculate the affected population, regenerate reports, compare old and new outputs, determine whether prior recipients need a corrected version and update the delivery log. Where the issue exposes a repeatable control weakness, change the mapping or workflow under version control and test the next cycle. Retain enough evidence for independent review without storing unnecessary investor information in broad team folders.

Set release and board oversight

The manager and service providers should agree who owns production, review, release and correction. Board reporting should focus on matters that affect the VCC or sub-fund, including repeated breaks, unapproved manual steps, late data, incorrect investor populations and control actions that remain open. It should not turn directors into report preparers. A concise dashboard can show the number of material exceptions, ageing, reports delayed or corrected, root causes and remediation status. Link each dashboard item to the underlying lineage record so challenge is evidence-based. If a provider produces the report, require exportable evidence and exit-ready documentation rather than accepting a platform screenshot as the only audit trail.

Related guidance: VCC compliance checklist · VCC governance roles

Run a worked release test

Use a sample that changes across periods or share classes, because static fields can hide weak lineage. Include at least one manual adjustment and one field supplied by an external administrator. The reviewer should be able to identify the source, reproduce the rule, see the exception decision and confirm the delivered version without relying on the preparer. If the test fails, do not patch only the sample. Define the potentially affected reports and investors, rerun the relevant population and decide whether correction or notification is needed under the governing documents and applicable obligations. Record the decision even when the final value remains unchanged.