Engine performance and capacity: throughput, latency budgets and load testing

A payment engine must handle the bank's peak volume without slowing down, and peak volume is not the average: it is the busiest hour of the busiest day, often the end of month payroll run, the morning after a bank holiday, or the hour before a clearing cut off. A bank that processes 250 million payments a year averages about 8 payments a second, but its peak may be 200 payments a second, twenty five times the average. An engine sized for the average will collapse at peak, and a collapse at peak means payments queue, customers complain, and the bank misses cut offs. Capacity planning starts by measuring the peak, not the average, and by understanding what drives it. Source: bank payment platform capacity planning; Site Reliability Engineering, Google. Throughput is the number of payments the engine can process per second, and it is limited by the slowest step. If validation takes 50 milliseconds, enrichment takes 200 milliseconds because it calls an external reference data service, and posting takes 100 milliseconds, the engine can process at most 5 payments a second through a single thread, because enrichment is the bottleneck. For a business analyst, the requirement is to define this behaviour explicitly, because the engine does what the requirement says and nothing more. The engine increases throughput by running steps in parallel where they are independent, and by scaling out: running more instances of the slow service. But scaling out only helps if the bottleneck is CPU or memory in the engine itself. If the bottleneck is the external reference data service, adding more engine instances makes the problem worse, because more instances call the same slow service. The fix then is to cache the reference data, or to call the service asynchronously and continue processing while waiting. Latency budgets assign a time allowance to each step, and the sum of the allowances is the total the customer experiences. For an instant payment, the total budget might be 10 seconds from intake to beneficiary credit, as required by the SEPA Instant regulation. The budget is split: intake 200 milliseconds, validation 300 milliseconds, screening 2 seconds, enrichment 1 second, routing 200 milliseconds, clearing 3 seconds, posting 500 milliseconds, and the remainder as contingency. Each step reports its actual time, and the engine alerts when a step consistently exceeds its budget. A step that takes 5 seconds when its budget is 2 seconds is a defect, even if the total is still within 10 seconds, because the next slow step will push the total over. For a business analyst, the requirement is to define the latency budget per payment type, per step, and the alert threshold for each. Load testing proves the engine can handle peak before peak arrives. A load test replays a realistic mix of payments at peak volume and measures throughput, latency and error rate. The mix matters: a test that sends only simple domestic payments will not reveal that cross border payments, which need enrichment and correspondent routing, are three times slower. The operations team must be able to see this state on a dashboard, because a payment that cannot be seen cannot be managed. A good load test includes the full mix, including the payments that fail validation, the payments that hit sanctions holds, and the payments that need repair, because those consume capacity too. The test also measures what happens when a downstream system is slow: if the clearing system responds in 5 seconds instead of 200 milliseconds, does the engine queue gracefully, or does it run out of threads and stop accepting new payments? A load test that passes is evidence; a load test that has never been run is an assumption. Seasonality drives capacity in ways that surprise banks that only look at averages. The busiest day of the year for many banks is the last working day before Christmas, when payroll, supplier payments and consumer spending all peak at once. The second busiest is the end of the financial year, when tax payments and year end settlements coincide. A bank that sizes its engine for an ordinary Tuesday will fail on both days. Capacity planning must therefore model the peak day, not the average day, and must include a margin for growth: if volume grows 15 percent a year, the engine must handle next year's peak, not this year's. The plan must also cover the recovery from a failure: if the engine is down for 30 minutes at peak, it must clear the backlog within the next hour, which means it needs spare capacity above the peak rate, not just at it. Cost is the other side of capacity. An engine that is sized for ten times the peak volume wastes money on idle servers, and an engine that is sized exactly for the peak will fail when volume exceeds it. The right size is the peak plus a margin, typically 30 to 50 percent, and the margin is reviewed every quarter against actual volume. Cloud infrastructure makes this easier, because the bank can scale out for a known peak, such as the end of month payroll run, and scale back down afterwards, paying only for the capacity it used. But cloud scaling is not instant: it takes minutes to start new instances, so the bank must scale up before the peak arrives, not when it is already happening. For a business analyst, the requirement is to define the capacity model, the peak scenarios, the margin, and the scaling triggers, and to review them quarterly against actuals. Further reading: Site Reliability Engineering, Google; bank payment platform capacity planning guides. Last reviewed 7 November 2026.