Test automation for financial systems

What automated regression for money flows covers

A confirmation screen can show EUR 10.00 while the ledger holds two debits for the same transfer. Our suites therefore read ledger entries and balances through the API or the database, and the screen text is checked only where the screen sets the amount. A rounding, cut-off, or duplicate posting regression then fails a build before it reaches customer balances.

Money assertions

Every test that moves money compares integer amounts in the smallest currency unit, never parsed display strings or floating point values. The standard assertions are:

• the entries of each transaction net to zero across debit and credit accounts;
• each account balance after the test equals the sum of its entries;
• each fee, interest, and proration amount equals a reference value computed outside the code under test, with the rounding rule named, as in the banker's rounding guide;
• a request retried with the same idempotency key leaves exactly one set of entries.

Full matching against processor and bank files is the scope of ledger reconciliation testing. The regression suite runs the fast subset on every change.

Deterministic data for amounts, rates, and dates

We remove three sources of random results before the first test is written.

• Amounts. Data builders create synthetic accounts for each test run, so parallel tests never share a balance. Amounts sit on rounding edges: half of the smallest unit, one smallest unit, and currencies with zero and three minor units, such as JPY and BHD.
• Exchange rates. Each test loads a fixed rate table. Illustrative example with a synthetic rate: at a fixture rate of 1 EUR = 1.0850 USD less a 0.50% markup applied to the rate, a single EUR 250.00 transfer must credit USD 269.89 after rounding to the cent.
• Dates and time. The system reads time from an injectable clock, or from a tool such as libfaketime where the code cannot change. Tests move the clock across a partner bank cut-off, a billing cycle from 31 January to 28 February, a leap day, and a daylight saving change, so accrual days and cycle boundaries are checked in seconds.

Simulators for processors and banks

A partner sandbox returns only the responses its operator supports, on the operator's schedule. We build HTTP simulators, with common open-source options such as WireMock or MockServer, that return on command a decline, a timeout after capture, a late or duplicate webhook, a partial settlement line, or a returned bank transfer. Tests use the simulators on every commit, and the real sandbox runs on a schedule.

Contract tests for partner APIs

Consumer-driven contract tests, with open-source tools such as Pact, record the requests your services send to a partner and the response fields they read. A scheduled job verifies those contracts against the partner sandbox, so a renamed field or a new status value fails a build before it breaks posting or settlement. Checks of your own published OpenAPI specification belong to API and webhook testing.

Where the first suite goes

For neobanks and BaaS programmes, the first suite covers card authorisation, top-up, and transfer postings. For acquiring, it covers authorisation, capture, and partial refund. For billing and accounting products, it covers proration, dunning retries, and invoice payments, and for spend management, card controls and accounting sync. For trading and crypto exchanges, it covers order fills, fees, deposits, and withdrawals. For payroll, it covers gross to net pay and pay run files, and for lending, repayment schedules and interest accrual. Browser and mobile end-to-end tests cover only the journeys where a screen sets an amount, such as a transfer confirmation.