Net asset value data integration testing checks that financial data is transferred and transformed correctly between systems used to produce a fund’s net asset value (NAV). It verifies that positions, prices, cash, liabilities and other required inputs arrive in the right format and are complete, accurate and available for the relevant valuation cycle. The scope is the movement and integrity of data; calculation logic may be tested alongside it, but is a separate concern.
What net asset value data integration testing checks
A NAV process can draw data from portfolio management, custody, market data, foreign exchange, fund accounting and investor register systems. Integration testing follows selected records across these boundaries, including any extract, transform, load (ETL) jobs or application programming interfaces (APIs) that move them.
Tests check that source fields map to the intended destination fields and retain their meaning. For example, a security identifier must resolve to the correct instrument, a price must carry the correct currency and valuation date, and a cash balance must retain its sign and account context. Where a transformation converts currencies or applies a unit conversion, the test verifies the rule and resulting value.
Data controls commonly cover completeness, accuracy, uniqueness, referential integrity and timeliness. A test may compare source and destination record counts, reconcile amounts by currency or portfolio, detect duplicate transactions, and flag missing instrument reference data. It should also check whether a value is stale or outside the expected valuation date, rather than treating every populated field as valid.
Preconditions and test design
Reliable results depend on agreed interface contracts, field mappings, valuation cut-offs and business rules. The team needs to know which source is authoritative for each data item, how missing or late records are handled, and which precision and rounding rules apply. Without these decisions, a mismatch may be difficult to classify as a defect or an accepted processing outcome.
Use controlled test data with known source records and expected destination values. Include ordinary records and cases such as a missing price, an invalid currency, a duplicate transaction, a late-arriving file and a corrected record. Test the full hand-off where practical, while retaining checks at individual interfaces to help locate failures. Keep expected results independent of the transformation under test, or the same mapping error may appear in both the output and the expected value.
Environment drift can affect results. Reference data, calendars, interface versions and configuration may differ between test and production-like environments. Record the versions and valuation date used for each run, and make sure test data does not contain live customer or investor information unless its use is authorised and protected.
Practical example
Assume a test portfolio receives 100 units of a security priced at £20, cash of £500 and a liability of £100. The source systems provide the position, price, cash and liability records. The integration tests verify that the destination receives the correct instrument, quantity, price date, currency and signed amounts, with no missing or duplicate records.
The expected net assets from these inputs are £2,400: £2,000 of securities plus £500 cash less £100 liabilities. If the fund has 120 units outstanding, the expected NAV per unit is £20. The integration checks establish that the inputs reached the fund accounting system correctly; a separate calculation assertion checks the net assets and per-unit result. This distinction helps identify whether a failure arose during data transfer or in valuation logic.
Handling failures and verifying outcomes
A failed integration check should identify the affected interface, record or control total, along with the expected and actual values. Useful scenarios include a failed file transfer, a partial load, an out-of-order event, a rerun after a timeout and a corrected source record. Verify that retries do not create duplicates, partial processing is visible, and corrected data can be traced through to downstream outputs.
Reconciliation provides evidence that transferred data agrees across systems, while record-level assertions help explain discrepancies. A successful test run should show that expected records and totals reached the intended destination, rejected data followed the defined exception path, and rerunning the same input produced a controlled result. These checks support wider [Integration testing in banking] and [End-to-end testing in banking] when NAV data feeds downstream reporting or investor services.
Frequently asked questions
Does NAV data integration testing prove regulatory compliance?
No. It provides evidence about data flows and controls, which may support compliance work, but compliance depends on the applicable requirements, the full process and other control evidence.
Can NAV integration tests use production data?
They can use production data only where the organisation has authorised the use and applied suitable access, privacy and security controls. Masked or synthetic data is often suitable for repeatable test scenarios.
How should a team set acceptable NAV data tolerances?
Set tolerances from approved fund rules, source-system precision, currency conventions and valuation procedures. Apply exact comparisons to identifiers and dates, and define explicit precision or rounding tolerances for numeric values.