Nostro account reconciliation testing verifies that a bank's records for an account it holds with a correspondent bank agree with the correspondent's statements and transaction data. It checks balances, payment movements and matching rules, then confirms that unmatched or inconsistent entries are identified and handled according to the bank's defined workflow. The account is held in the correspondent's books, often in a foreign currency.
What nostro account reconciliation testing covers
A reconciliation process compares two representations of activity: the bank's internal nostro ledger and the correspondent's statement, balance report or transaction feed. Testing checks that both sources are read correctly, transactions are matched using configured fields, and the resulting balance and exceptions are accurate.
Matching rules can use references, amount, currency, debit or credit direction, booking date, value date and counterparty details. The rules depend on the bank's configuration and correspondent data. Tests should verify how exact matches are treated, which fields can differ, and whether permitted tolerances or date windows are applied consistently.
The test scope can include statement ingestion, transaction matching, balance calculation, exception queues, investigation and resolution, and downstream accounting or reporting. It may also cover a correspondent's data format, file delivery or interface. This makes [correspondent banking integration testing] relevant when reconciliation depends on messages or feeds from external banks.
Preconditions and dependencies
Reliable results require controlled source data and a known expected outcome. Set up an internal ledger, correspondent statement and matching configuration with agreed opening balances, transaction directions, currencies and dates. Confirm how the system handles cut-off times, time zones, holidays, late-arriving entries, fees and reversals. Where these rules are unclear, expected results will be ambiguous.
The test environment should use representative interface mappings and reference data, including correspondent identifiers and currency codes. Environment drift, such as a changed mapping or an outdated test configuration, can create apparent reconciliation defects. Keep test data isolated so that repeated runs do not introduce duplicate postings or affect unrelated tests.
Failure modes and verification
Test both successful matches and exceptions. Useful negative cases include a missing statement entry, a duplicate transaction, a wrong currency, a sign or debit-credit error, a truncated reference, an amount mismatch and an entry outside the permitted date window. Verify that a failure appears in the correct exception category and retains enough source detail for investigation.
Also test operational conditions. A delayed or malformed file should not silently produce a complete reconciliation. Reprocessing the same input should follow the system's duplicate-handling rules. A reversal or fee should be represented and matched according to the configured accounting treatment. Confirm that closing balances and exception totals remain consistent after users resolve, reject or carry forward items.
Evidence should include the input records, configuration, matched and unmatched results, calculated balances and any audit events produced by the workflow. Balance checks should use the agreed sign convention and account currency. A reconciliation status alone is insufficient evidence if underlying transactions or exceptions are wrong.
Practical example
Assume the internal ledger has an opening balance of USD 10,000, a USD 500 debit and a USD 200 credit. The correspondent statement contains the same two movements, with one payment reference formatted differently. If the approved matching rule allows that reference variation and all other required fields agree, the test should expect both entries to match and the closing balance to be USD 9,700.
Run a second case with the statement's debit recorded as USD 550. The system should leave the item unmatched or raise the configured amount exception. Verify that the balance difference is visible, the source values are retained, and the reconciliation cannot be reported as fully matched while the discrepancy remains unresolved.
Nostro testing is closely related to [cross-border payment reconciliation testing], which follows payment data across payment and settlement processes. It is also a specialised form of [reconciliation testing], focused on correspondent-held accounts and their operational data.
Frequently asked questions
How does a nostro account differ from a vostro account?
A nostro account is an account a bank holds with another bank, described from the account-holding bank's perspective. The host bank may describe that same account as a vostro account in its own records.
What test data is useful for nostro reconciliation?
Use controlled internal ledger entries and correspondent records covering exact matches, timing differences, fees, reversals, duplicate inputs and mismatched transaction attributes. Include expected match status, balance and exception outcomes for each case.
Can nostro reconciliation tests run without a live correspondent bank?
Yes. A test can use representative statement files, messages or simulated interface responses, provided their formats and data reflect the integration contract being tested. Validate live connectivity separately where correspondent delivery or network behaviour is in scope.