How to test correspondent bank fee deduction reconciliation

Correspondent bank fee deduction reconciliation testing verifies that fees charged by intermediary banks match the payment instructions, applicable fee rules and settlement records. It checks that the correct amount reaches the beneficiary, that fee deductions are accounted for once, and that unmatched or unexplained amounts enter an investigation or exception workflow.

What to reconcile

A cross-border payment may pass through one or more correspondent banks. Depending on the agreed charge-bearer instruction and the route, an intermediary may deduct a fee from the payment amount, or a bank may debit a fee separately. The expected treatment depends on the payment terms, bank configuration and applicable route. A test should use those rules as its oracle rather than assuming every payment follows the same deduction model.

Trace each payment across the systems that create, route and account for it. Compare the original instructed amount and currency with the amount sent to the next bank, any reported intermediary fee, the amount received by the beneficiary bank, and any separate fee debit. Use stable payment references and, where available, correspondent transaction references to link records. Check that the same deduction is not recorded twice and that any currency conversion or rounding follows the configured rules.

Keep fee calculation and fee reconciliation distinct. Fee calculation tests whether a rule produces the expected charge. Reconciliation testing checks whether the charge recorded or reported during processing agrees with the expected charge and the related cash movements. A calculated fee can be correct while the settlement record is missing or incorrectly matched.

How to design the tests

Start with the rules for each route, currency, correspondent and charge-bearer option. Confirm which systems provide the expected fee, actual fee and settlement amount. These may be held in payment instructions, processing messages, fee advices or account statements. A statement may report a net amount without identifying each deduction, so the test design should define when reconciliation can complete and when it must wait for more evidence.

Prepare controlled test data with known fees and distinct references. Cover a payment with no deduction, one with a single deduction, and a route with multiple intermediaries. Add cases for a fee that differs from the expected value, a missing fee record, a duplicate advice, a late-arriving record and a currency mismatch. Include boundary cases from the fee rules, such as a minimum charge or a percentage fee reaching a cap, if those rules apply.

For each case, assert the financial outcome and the processing state. A successful match should link the expected and actual records, produce the correct net amount or separate debit, and mark the payment as reconciled. A mismatch should retain the source records, identify the variance and create the configured exception or investigation state. Reprocessing the same statement or advice should not create a second deduction or close an unrelated exception.

Practical example

Assume test data specifies a USD 1,000 payment and a USD 15 intermediary deduction. The receiving-bank record reports USD 985, while the fee advice reports USD 15 against the same payment reference. Assert that the records match, that USD 985 is treated as the amount received, and that the USD 15 fee is recorded once in the agreed accounting location.

Then change the advice to USD 18. The payment should remain unreconciled or enter the configured investigation state, with a USD 3 variance. If the advice is missing, the system should not infer that the fee was zero unless the rules explicitly permit that conclusion. These assertions should check both the reconciliation result and any resulting ledger or subledger entries.

Verify the result across systems

Run the scenario through the payment processing and reconciliation components, using test environments with consistent fee configuration and settlement data. Check the generated payment record, fee record, statement or advice input, reconciliation output and accounting entries. For automated tests, assert amounts as decimal values in the correct currency, compare references and statuses, and verify that retrying a feed does not duplicate postings.

When a test fails, separate a matching defect from an upstream data issue. A missing advice, changed correspondent route or stale fee schedule can produce a valid exception rather than a reconciliation bug. Preserve the input records and processing identifiers so the result can be reproduced and traced.