Non-functional
Performance and load testing for financial systems
Performance and load testing measures whether payment, payroll, trading, and banking systems keep latency, throughput, and balances correct at real peaks: authorisation spikes, payday and month-end batches, market open, and filing deadlines. Buyers receive a load model from the product's peak patterns, test scripts with environment setup, a latency and throughput report against agreed thresholds, and capacity bottleneck findings.
What performance testing for financial systems covers
We put the operations that move or hold money under the volumes and timing of the product's own peaks, then check that every amount is still correct. A fast response that posted a transfer twice fails the run. Sources below were checked on 2026-09-16.
Peaks the load model reproduces
- Authorisation peaks and settlement windows. For acquiring and POS products, the model combines an authorisation spike during a retail sales event with the capture batch and settlement file that must finish in the same window. A capture batch that overruns its cut-off settles merchant funds a day late.
- Payday and month-end batches. Payroll, earned wage access, and BaaS products post pay runs, early wage withdrawals the evening before payday, and bursts of webhooks to programme partners. For month-end, the model runs statement, fee, and interest jobs against the same tables as live traffic.
- Market open. For trading, crypto exchange, and trading tools products, the model concentrates order submissions and quote subscriptions in the first minutes after the open and during volatility spikes. We record quote age at order submission, because a stale quote at peak fills orders at the wrong price.
- Deadlines and scheduled refreshes. For tax software, the model covers filing traffic in the days before the IRS due date, which was April 15, 2026 for calendar year filers (IRS, When to file). For cashback products, it covers merchant transaction feed ingestion after sales events. For open banking products, it covers scheduled consent and account data refreshes against each bank connector's rate limit.
Illustrative example, not a measured result: if the busiest minute of last November held 2,400 authorisation requests and the product team plans for 1.5 times that volume, the model targets 3,600 requests per minute, or 60 per second, held for the observed length of that peak.
Failure paths under load
- Idempotent retries under latency. When a processor or bank answers after the client timeout, the client retries. We add latency to the simulated partner and check that the same idempotency key produces one charge, one ledger entry, and one webhook. The payment idempotency testing guide shows the request sequence.
- Ledger lock contention. Concurrent postings to one balance row, such as a merchant settlement account or a programme's omnibus account, cause lock waits and deadlocks. We check that a rolled-back deadlock leaves no half-posted transfer and that each balance after the run equals the sum of its entries, using checks from ledger reconciliation testing.
- Queue backlog and ordering. At peak, settlement events and webhooks arrive late or out of order. A refund processed before its capture, or a withdrawal approved before its deposit posts, is a defect even when latency passes.
- Partner limits. Card network simulators, bank connectors, and market data feeds return HTTP 429, timeouts, or throttled streams. We check backoff, the customer-facing status, and that no request is dropped silently.
Test types
Load tests hold the modelled peak. Stress tests raise load until a component fails and record the failure mode. Spike tests jump from normal traffic to peak in seconds, as at market open. Soak tests run for hours across a batch window to expose connection leaks and growing queues. Every run ends with a money check: requests sent, entries posted, duplicates, and balances.
DORA capacity and testing requirements
For EU financial entities outside the simplified framework of Article 16, DORA Article 7(c) says financial entities shall use and maintain updated ICT systems "equipped with sufficient capacity ... to deal with peak orders, message or transaction volumes, as needed" (Regulation (EU) 2022/2554). Article 25(1) names performance testing among the tests the resilience testing programme shall provide for. The DORA testing requirements page maps the rest. Our load model and report are input to that programme and to the capacity and performance management procedures for "the identification of capacity requirements" in Article 9(1)(a) of Delegated Regulation (EU) 2024/1774, and they cover only the operations and peaks in the model.
Related
Segments
Standards
Guides
Deliverables
Load model built from the product's peak patterns
A workload model that sets the request mix, arrival rate, and duration for each peak the product faces, such as payday, month-end, market open, or a sales event, and names the production data behind each figure, for the engineering lead and capacity planners.
Performance test scripts and environment setup
Versioned load scripts that use synthetic accounts, cards, and idempotency keys, plus the environment configuration and data seeding steps to rerun them, for the client's engineering team.
Latency and throughput report against agreed thresholds
A report that compares measured percentile latency, throughput, error rate, and post-run ledger totals for each money-moving operation with the thresholds agreed before the run, and records build, environment size, and date, for engineering leads and resilience programme owners.
Capacity bottleneck findings
A list of the components that limit throughput first, such as lock waits on ledger balance rows, exhausted connection pools, or partner rate limits, each with the load level where the limit appeared, the effect on payments or orders, and the retest result, for the engineering lead.
How performance tests fit your release process
Environment and data. Tests run in a staging environment whose size is written into every report, so a result is never read as production capacity. Accounts, cards, and employees are synthetic, and no live cardholder data or account data enters the load environment. Where a processor, bank, or exchange sandbox cannot take peak volume, we replace it with a simulator that has configurable latency, error rates, and rate limits.
On every merge. A short load test of the main money-moving endpoints runs in CI against a stored baseline. The build fails when 95th percentile latency or the error rate moves past the margin your team agreed, or when the post-run money check finds a duplicate entry.
Before release and before known peaks. The full load model runs before any release that changes authorisation, posting, order, or batch code. It also runs ahead of dated peaks: a sales event, tax season, the first pay run after onboarding a large employer, or a new asset listing. Failover and recovery under load belong to operational resilience testing.
After release. During the next real peak, we compare production metrics with the model and update arrival rates and request mix where they differed.
Cadence and handover. Scripts in k6, Gatling, JMeter, or Locust live in your repository, matching the tool your team already runs. Reports and bottleneck findings go to your shared evidence folder with build numbers and dates. Your team owns the thresholds, production capacity decisions, infrastructure changes, and the go or no-go call before a peak.
Sample deliverable
Sample, synthetic data
| ID | Flow | Defect | Severity and status | Financial impact (XTS) and basis | Rule touched |
|---|---|---|---|---|---|
| DEF-101 | Instalment loan interest accrual | Daily interest uses a 360-day year while the loan agreement and the APR disclosure use a 365-day year, so a 20.00% nominal loan accrues at about 20.28% | Critical; fixed, retest passed | 1.14 overcharged per affected loan per 30 days at 5,000.00 principal | 12 CFR 1026.22(a)(2): APR accurate within 1/8 of 1 percentage point |
| DEF-102 | Credit line repayment | App payments received after 16:00 on the due date are credited the next day and trigger a late fee | Critical; open | 25.00 late fee charged in error per affected account per billing cycle | 12 CFR 1026.10(b)(2)(ii): payment cut-off no earlier than 5 p.m. on the due date |
| DEF-103 | Instalment loan early payoff | Payoff quote adds a prepayment fee while the loan disclosure states that no prepayment charge applies | Major; fixed, retest passed | 50.00 charged in error per affected early payoff | 12 CFR 1026.18(k)(1): prepayment charge disclosure |
| DEF-104 | Loan application decisioning | Applications declined after a decision service timeout stay in pending status and no adverse action notice is sent | Major; open | 0.00 direct loss per affected applicant; the exposure is regulatory | 12 CFR 1002.9(a)(1)(i): notice of action within 30 days of a completed application |
| DEF-105 | BNPL merchant fee calculation | Merchant fee at 5.99% is calculated on the order total including shipping, while the merchant fee schedule excludes shipping | Major; fixed, retest passed | 0.90 overcharged per affected order with 15.00 shipping | No regulation clause; merchant fee schedule |
| DEF-106 | BNPL partial refund | A 40.00 partial refund reduces the last instalment instead of the next instalments, so the next instalment is collected in full | Minor; deferred to the next release with a manual adjustment procedure | 40.00 collected early per affected order until the final instalment date | No regulation clause; customer instalment agreement |
| DEF-107 | Wallet peer-to-peer transfer | A transfer retried after a client timeout is sent with a new idempotency key, so the wallet balance is debited twice | Blocker; fixed, retest passed | 60.00 debited in error per duplicated transfer in the test case | 12 CFR 1005.11(a)(1)(ii): incorrect electronic fund transfer |
| DEF-108 | Wallet dispute handling | The provisional credit job skips disputes received on a weekend, so the credit posts on business day 11 | Critical; open | 150.00 held one business day too long per affected dispute | 12 CFR 1005.11(c)(2)(i): provisional credit within 10 business days |
Amounts use XTS, the ISO 4217 code reserved for testing. Loans, orders, wallets, and disputes are generated test records with no customer data.
Questions
What is performance testing?
Why is performance testing important?
What is load testing?
Scope your performance testing
Tell us which peaks matter to your product and which operations move money during them. We return a load model outline and the first thresholds to agree.
Scope your testing