What is wholesale bank money market deal testing?

Wholesale bank money market deal testing checks that a bank’s short-term funding and investment transactions are captured, processed and recorded according to their agreed terms. It covers deals such as interbank deposits and repurchase agreements (repos), from booking through settlement and maturity, including interest, counterparty limits and downstream records. The exact checks depend on the products and systems in scope.

What wholesale bank money market deal testing covers

A test typically starts with deal capture in a treasury or trading system. It checks that required fields are present and valid, including counterparty, currency, principal, rate, trade date, value date, maturity date, day-count convention and settlement instructions. Product configuration determines which fields and rules apply.

Lifecycle checks follow the deal through relevant stages. These can include validation and approval, confirmation generation, settlement instruction creation, interest accrual, maturity repayment, rollover, amendment or cancellation. Tests should verify the expected status changes and confirm that each downstream system receives consistent deal data.

Financial calculations need explicit expected results. For a fixed-rate deposit, checks may cover accrual periods, day-count basis, rate application, rounding and payment amount. Floating-rate deals may also depend on reference-rate fixings, reset dates, fallback rules and rate floors or caps where configured. A calendar or product-rule change can affect valid dates and calculations, so the test environment must use the intended configuration.

Testing also checks control and exception behaviour. Examples include rejecting a deal with an inactive counterparty, stopping a booking that exceeds an applicable limit, preventing settlement with invalid instructions, and handling a duplicate submission safely. Where a workflow requires approval, verify that unauthorised users cannot bypass it and that the audit trail records material changes.

Preconditions and dependencies

Reliable results depend on controlled test data and a representative environment. The counterparty, currency, product, settlement account, limits, market data and business calendars must be set up for the scenario. Where external services are unavailable, teams may use controlled simulations, with expected messages and responses defined in advance.

Environment drift can make a valid test appear to fail. For example, a different holiday calendar can shift a value or maturity date, while changed product settings can alter interest accrual. Record the configuration and input data used for each run so a calculation or workflow discrepancy can be reproduced.

Worked example: fixed-rate deposit

Assume a bank books a GBP 10,000,000 deposit for 30 days at 3.6% per annum, using simple interest and an Actual/360 day-count basis. The expected interest is:

GBP 10,000,000 × 0.036 × 30 ÷ 360 = GBP 30,000

For a bullet repayment with no date adjustment, the test should verify the booked terms, the GBP 30,000 interest amount and the GBP 10,030,000 maturity proceeds. It should also check that the settlement and accounting outputs use the correct dates, currency and amounts, and that a generated confirmation reflects the agreed deal. If the bank’s product rules apply a date adjustment or a different payment structure, calculate the expected result from those rules instead.

How to verify the result

Compare the recorded deal terms and calculated amounts with an independently prepared expected result. Check the trade record, lifecycle status, generated confirmation, settlement instruction and relevant accounting entries or reconciliation outputs. Where a downstream system receives the deal through an interface, verify both the message content and the receiving system’s processed record. A successful user-interface response alone does not establish that the deal completed correctly across the workflow.

Use negative and boundary cases alongside the standard path. Examples include invalid dates, unsupported currencies, missing settlement details, rate limits and attempted amendments after a restricted lifecycle state. These checks help expose validation gaps and inconsistent handling between connected systems. For wider workflow coverage, relate the scenarios to end-to-end testing in banking and maintain controlled records through banking test data management.