What is banking day-count convention testing?

Banking day-count convention testing verifies that a banking system counts the days in an interest accrual period and applies the agreed year basis correctly. It checks that dates, convention variants, rate and principal produce the expected interest for products such as deposits, loans and bonds. A day-count convention may count calendar days, so it should not be confused with a rule for moving payments that fall on non-working days.

What banking day-count convention testing covers

A day-count convention defines how an accrual period is converted into a year fraction. A common calculation is principal multiplied by annual rate multiplied by the year fraction. For conventions such as Actual/360, the year fraction is the actual number of counted days divided by 360. For Actual/365 Fixed, it is the actual number of counted days divided by 365.

The convention is often specified in product configuration or contract data. The system may also need a particular variant, such as a defined Actual/Actual method or a specific 30/360 rule. Similar names can represent different date-counting rules, so test expectations must identify the exact convention and variant rather than rely on a generic label.

Testing checks the dates used for accrual, including whether the start date or end date is included, how the system handles leap days, and how it treats irregular periods. For scheduled products, verify regular periods as well as short or long stub periods. Confirm that the convention applies consistently through calculation, posting, statements and downstream reporting where those components use the same accrual amount.

Test design and dependencies

Start with the product specification and map each convention to its precise calculation rule. Establish the source of each date, such as the contractual accrual start and end dates, and confirm whether payment-date adjustment changes the accrual dates. A business-day convention such as Following can move a payment date; it does not, by itself, define how many days accrue.

Use independently calculated expected results. Test ordinary periods, month ends, year ends, leap years and periods that cross February. Include boundary cases where a date moves by one day, and verify zero-length or invalid periods according to the product rules. For 30/360 conventions, include dates near month ends because the applicable variant can adjust those dates differently.

The calculation also depends on rate representation, principal precision, currency precision and rounding policy. Assert both the unrounded year fraction or intermediate value where observable and the final posted amount. Check whether rounding occurs per accrual period, per day or only when the final amount is posted. Compare values at the precision required by the specification rather than accepting a result merely because it looks plausible on a screen.

Environment and data dependencies can affect results. Keep the product convention, rate, dates, calendar and account data controlled. If a test uses an application programming interface (API), assert the calculation fields in the response as well as any resulting ledger entry. In an end-to-end flow, reconcile the accrued amount with the amount posted to the account or loan.

Worked example

For a principal of £100,000 at an annual rate of 6% over 30 actual days, the expected simple accrual is:

• Actual/360: £100,000 × 0.06 × 30/360 = £500
• Actual/365 Fixed: £100,000 × 0.06 × 30/365, or about £493.15 when rounded to two decimal places

Use identical inputs for both cases and change only the configured convention. The different expected amounts confirm that the system applies the configured denominator. A separate test should use the contract's exact date-inclusion and rounding rules, since this example assumes a 30-day accrual period and final rounding to two decimal places.

Failure modes and verification

Common defects include using the wrong denominator, counting one endpoint incorrectly, mishandling a leap day, applying a different 30/360 variant, or using a payment-adjusted date as an accrual date without authorisation. Configuration drift between environments can also make a correct calculation appear defective, or conceal a production configuration error.

Verify calculations against an independent reference implementation or reviewed test vectors, then check the resulting posted amount and relevant audit data. When a defect is fixed or a product configuration changes, rerun cases for the affected convention and date boundaries. See Banking rounding and precision testing for related checks on numeric representation.