How to test a wholesale bank intraday liquidity dashboard

Wholesale bank intraday liquidity dashboard testing checks that a dashboard presents accurate, timely views of cash positions and expected flows during the business day. It compares displayed balances, projections, statuses and alerts with agreed source data and calculation rules across accounts, legal entities, currencies and payment states. Testing also checks that updates and failures are visible to users who rely on the information for liquidity decisions.

Define the dashboard’s data contract

Before testing, document what each measure means and which system is authoritative for it. A dashboard may combine balances from core banking or treasury systems, payment queues, settlement feeds, nostro accounts and credit facilities. Its scope varies, so agree which sources and liquidity components it includes.

Specify how the dashboard treats pending, settled, rejected, cancelled and reversed payments. Record rules for value dates, cut-off times, time zones, currency conversion, rounding and aggregation by account or entity. Define whether each figure is a current position, a forecast or a limit. These distinctions give testers an oracle for expected results and prevent disagreements over labels from becoming apparent calculation defects.

Prepare controlled test data with identifiable transactions and consistent account relationships. Use synthetic or appropriately protected data. Capture source values and timestamps so results can be reconciled without exposing live customer or counterparty information.

Validate data and liquidity calculations

Compare dashboard fields with their authoritative sources through an application programming interface (API), database extract or controlled report. Check that amounts, currencies, identifiers, statuses and timestamps map correctly. Reconcile totals at account, entity and currency level, then verify that filters and drill-downs preserve the same underlying figures.

Test event lifecycles as well as static balances. Include a delayed payment update, a duplicate event, an out-of-order event, a cancellation and a reversal. Confirm that retries do not double-count a transaction and that a reversal affects the position according to the agreed rule. Check that a missing or stale source is shown as a data-quality condition, rather than silently appearing as a valid zero or current value.

For each scenario, assert both the displayed number and its context: status, as-of time, currency, account scope and any warning. A numerically correct total can still mislead if it combines the wrong entity or omits an unsettled flow without indicating that choice.

Exercise operational scenarios

Cover normal flows and conditions that put pressure on intraday positions. Test a large outgoing payment, a delayed incoming receipt, a queue of payments awaiting release, a payment rejection and a change in available credit, where those items fall within the dashboard’s scope. Verify alert thresholds at, below and above the configured boundary, including the effect of any rule for currency or entity aggregation.

Check refresh behaviour while new events arrive. Confirm that the dashboard updates within its stated service expectations, displays the age of its data where required, and does not mix snapshots from different refresh cycles. During a source outage or partial feed failure, verify the expected degraded state, user message and recovery behaviour. After recovery, reconcile the refreshed position against source records to detect missed or repeated events.

Worked example: current position and forecast

Assume the agreed test fixture starts with an available balance of £12 million. A £5 million receipt settles, an £8 million payment settles, and a separate £4 million payment remains queued. If the agreed rules include settled movements in the current position and queued payments only in the forecast, the dashboard should show £9 million current availability and £5 million projected availability after the queued payment. Assert the currency, account, event statuses and as-of time alongside both figures. If the product defines these measures differently, use its approved calculation rule and adjust the expected values.

Check usability and performance

Verify that users can identify the relevant account, entity, currency, measure and data timestamp without relying on colour alone. Test sorting, filtering, drill-downs, exports and displayed alert details against the same data set. Check that labels distinguish current balances from forecasts and that rounding does not conceal a threshold breach.

For performance testing, use representative data volumes and concurrent access patterns agreed for the service. Measure refresh and query times against the system’s requirements, including during peak event ingestion. Also check for incomplete charts, stale widgets and timeouts under load. A fast page response does not demonstrate that the underlying figures are current or complete.

Retain the test fixture, expected results, source snapshots, application and rules versions, execution timestamps and defect references. This lets reviewers reproduce a discrepancy and trace it to a source feed, transformation, calculation or display behaviour.