What is securities position reconciliation testing?

Securities position reconciliation testing verifies that holdings recorded by connected investment systems agree with an approved reference position for the same account, security and business date. It checks the matching rules, data transformations and exception handling used to identify missing, duplicated or mismatched positions. The aim is to confirm that the reconciliation produces accurate results and routes genuine breaks for investigation.

What securities position reconciliation testing checks

A reconciliation compares position records from systems such as portfolio accounting, an order management system or a custodian. The comparison needs a defined matching key, commonly the account or custody account, security identifier and position date. Testers should confirm how the systems map identifiers and represent quantities, including decimal precision and units.

Expected results depend on the business rules. A system may compare settled holdings, total holdings, or settled and unsettled quantities separately. The test specification should state how pending trades, transfers, corporate actions and other position movements affect the expected position at the reconciliation cut-off. A mismatch can arise from incorrect data, timing differences or a defect in those rules.

Tests should cover exact matches and breaks, including a missing record on either side, duplicate records, incorrect account or security mappings, quantity differences and stale or incorrectly dated inputs. Where a tolerance is allowed, verify its boundary and confirm that it applies only to the fields and circumstances defined by the requirement. Unauthorised tolerance can conceal real discrepancies.

How to test the reconciliation

Start with controlled test data in which the expected position can be calculated independently. Establish the source records, the business date, the expected matching key and the handling rules for unsettled activity. Confirm that the test environment uses compatible reference data and configuration; identifier mapping or calendar differences between environments can produce misleading results.

Run the reconciliation and compare its output with expected results. Verify both the matched positions and the breaks. For each break, check that the output identifies the affected account and security, reports the relevant source quantities and records the reason or category where the system supports one. If users can investigate or resolve breaks, test that workflow and check that changes leave an auditable record.

A useful test set includes an exact match, a quantity difference within any permitted tolerance, a difference outside that tolerance, a record missing from one source, a duplicate and a position affected by a pending trade. Add cases for corporate actions or transfers when those events fall within the system's scope. Re-run a resolved break to verify that the reconciliation reflects corrected source data without retaining a stale exception.

Practical example

Assume a portfolio accounting system reports 100 units of a security in a client account at the end-of-day cut-off. The custodian reports 100 settled units and a purchase of 20 units awaiting settlement. If the configured reconciliation compares settled positions, the expected result is a match at 100 units, with the pending purchase treated according to the agreed rule. If the configured comparison includes unsettled activity, the expected total may be 120 units. The test should establish which basis applies before execution.

Then change the custodian's settled quantity to 99. The reconciliation should report a one-unit break, identify the correct account and security, and display the relevant quantities. If the output still reports a match, check the matching key, quantity conversion, cut-off logic and any tolerance configuration before treating the result as a reconciliation defect.

Common failure modes and verification

Common failures include comparing different business dates, applying inconsistent settled-versus-unsettled rules, losing precision during conversion, mapping a security to the wrong identifier, and processing a file twice. Delayed feeds can also create temporary breaks that disappear when both sources reach the same processing point. Tests should distinguish these timing conditions from persistent data or calculation errors.

Verify outcomes against independently prepared expected results, rather than using the reconciliation output itself as the oracle. Check the input data, calculated positions, matched records, exceptions and any downstream status or report. For a repeatable regression test, control the source data, event timing and reference-data version so environment drift does not change the expected result.