How to test interest allocation in a corporate bank cash pool

Cash pool interest allocation testing verifies that interest credited or charged across participating accounts follows the pool agreement, configured allocation rules and source balances. It checks the calculation inputs, the allocation between participants, rounding and resulting postings. The expected result depends on the bank’s product and the company’s agreement, so tests need an approved rule specification rather than an assumed universal formula.

Define the allocation rules and inputs

First identify whether the arrangement is a physical cash pool, where balances are swept to a header account, or a notional pool, where balances remain in participant accounts and the bank calculates an interest benefit. The arrangement affects which interest amounts are available for allocation and which systems provide the source data.

Document the rules that determine each participant’s share. These may use daily or average balances, eligible credit and debit positions, agreed rates, tiers, currencies, value dates and a specified day-count convention. Confirm how the process handles fees, limits, inactive accounts, rate changes during a period and rounding. The agreement and approved configuration are the test oracle.

Check dependencies before running calculations. Relevant inputs can include account membership, pool hierarchy, effective-dated rates, bank statements, balance feeds, calendars and the general ledger mapping. Use controlled test data with known balances and dates. Record the source and version of each input so a mismatch can be traced to the calculation or its upstream data.

Build calculation and allocation tests

Create cases for ordinary credit and debit positions, zero balances, multiple participants, tier boundaries and effective-date changes. Include a pool with only one eligible participant to check whether the full amount is assigned correctly. Test excluded or inactive accounts and any agreement-specific limits. For each case, calculate an independent expected result using the documented method.

For example, suppose the agreed rule allocates a $120 pool interest credit in proportion to eligible average credit balances. Participant A has $60,000 and participant B has $40,000. Their shares are $72 and $48 respectively: $120 × 60,000 / 100,000 and $120 × 40,000 / 100,000. Assert both participant amounts and that their sum equals the source credit. If the system rounds each share to currency precision, also check the defined treatment of any rounding residual.

Keep interest accrual testing distinct from allocation testing. Accrual testing checks whether the bank or treasury system calculated the pool interest from balances, rates, dates and conventions. Allocation testing checks how an agreed source amount is distributed among participants. When both are in scope, validate each stage separately before checking the end-to-end result.

Reconcile postings and test failure paths

Reconcile the allocation output to its source amount and to participant-level postings. Check that the total allocated amount equals the amount eligible for distribution, subject to documented exclusions or adjustments. Verify account identifiers, currency, period, debit or credit direction and value date. Where postings flow to a subledger or general ledger, reconcile those records as well.

Test missing or duplicate balance records, an unknown participant, a missing rate, an invalid pool membership date and an unavailable source amount. Confirm that the process raises a clear exception or routes the item for authorised review. Check that a failed or repeated run does not create duplicate postings, and that any correction leaves an auditable link to the original result. These checks fit within broader reconciliation testing and banking software testing.

Verify evidence and regression impact

Retain the input balances, applicable rules, independent expected values, system outputs, reconciliation results and exception records. Evidence should identify the run and calculation period, and should allow a reviewer to reproduce the result. When rates, pool membership or allocation rules change, rerun affected cases and check downstream postings. Include an end-to-end test where balances arrive from a source system and allocations flow to accounting, since a correct calculation can still be posted to the wrong participant or period.