How to test private bank client reporting accuracy

Private bank client reporting accuracy testing checks that each figure and attribute in a client report agrees with the applicable source data and approved business rules for the reporting date. It covers positions, cash, valuations, currencies, fees and other reported measures, including how data moves between portfolio, custody, pricing and reporting systems. The aim is to detect errors that could misstate a client’s holdings or activity.

Define what the report must show

Start with the report specification: report type, portfolio or account scope, as-of date, valuation basis, included transaction statuses, currency and rounding rules. Record which system owns each field and the rule used to calculate it. A total market value, for example, may depend on position quantity, instrument price, price source, currency conversion and rounding.

Agree expected behaviour for exceptional data. This includes missing prices, stale prices, suspended instruments, pending transactions, corporate actions and closed accounts. The correct output depends on the bank’s approved policy and report definition. A test should assert that policy, rather than assume a particular treatment.

Separate content accuracy from presentation and access checks. A correctly calculated figure can still be displayed under the wrong heading, clipped in a PDF, or delivered to the wrong client. Include those checks in the wider reporting test scope, with clear ownership for each.

Build a trustworthy expected result

Use controlled test data with known positions, cash movements, prices, foreign exchange rates and fees. Calculate expected values independently from the reporting path where possible. Reusing the report’s own transformation logic to create expected results can allow the same defect to affect both actual and expected values.

Compare at field level before comparing totals. Check identifiers, quantities, currencies, dates, statuses and values. Apply exact comparisons to fields such as account identifiers and currency codes. For calculated amounts, define precision and rounding points explicitly. A tolerance should reflect the documented calculation rule, rather than conceal unexplained differences.

Reconcile the report through its data layers. Compare source records with the portfolio or custody view, then compare that view with the generated report. Check for omitted or duplicated records as well as incorrect values. For totals, reconcile the relevant components and confirm that grouping, filtering and aggregation match the report specification. This is a practical use of reconciliation testing principles across systems.

Exercise boundaries and changes

Include cases that expose common calculation and data-handling errors: a position with a fractional quantity, a zero balance, a transaction close to the reporting cut-off, multiple currencies, a changed price, and a portfolio containing both cash and securities. Test date boundaries around market close and the report’s stated as-of date. Where relevant, cover accrued income, fees, tax treatment and corporate actions as separate fields or calculation paths.

Run the same report against a fixed source-data snapshot to check reproducibility. Then change one input at a time and confirm that only the expected output fields change. Include regression tests when pricing, foreign exchange, portfolio aggregation, report templates or upstream interfaces change. Environment drift can also affect results, so record relevant configuration and source-data versions with the test evidence.

Worked example

Suppose a test portfolio contains 10 units of a security priced at EUR 50 and EUR 100 cash. The report converts the total to US dollars at a rate of USD 1.10 per EUR. The expected security value is EUR 500; the expected portfolio value is EUR 600, or USD 660 before any separately specified fees or adjustments.

Assert the reported quantity, price, currency, security value, cash value, exchange rate and converted total. Then change the quantity to 11 and verify that the security value becomes EUR 550 and the converted portfolio value becomes USD 715. If the displayed total changes while the line-item quantity or price does not, investigate the transformation or aggregation path rather than accepting the total alone.

Verify the result and retain evidence

For each failed assertion, retain the report output, source snapshot, calculation inputs, expected values and relevant configuration. Record the report version and as-of date so another tester can reproduce the comparison. Investigate whether a mismatch comes from source data, mapping, timing, calculation, rounding or rendering before assigning the defect.

Use synthetic or appropriately protected test data and restrict access to generated reports. A report can pass every numerical assertion and still expose one client’s information to another. Keep access and delivery checks alongside accuracy tests, while reporting their results separately.