Corporate Bank Reaches 450% Load Capacity Reserve After Performance Testing

Sona Hakobyan

Author

Sona Hakobyan

Sona Hakobyan is a Senior Copywriter at PFLB. She writes and edits content for websites, blogs, and internal platforms. Sona participates in cross-functional content planning and production. Her experience includes work on international content teams and B2B communications.

Senior Copywriter

Reviewed by Boris Seleznev

Reviewed by

Boris Seleznev

Boris Seleznev is a seasoned performance engineer with over 10 years of experience in the field. Throughout his career, he has successfully delivered more than 200 load testing projects, both as an engineer and in managerial roles. Currently, Boris serves as the Professional Services Director at PFLB, where he leads a team of 150 skilled performance engineers.

The problem

The bank decided to develop its remote banking services in-house and lift them up the market ratings. Three platforms were being renovated at once. At the same time the banking group was going through integration, so load arrived in step increases rather than smoothly - and on one payday the system went down.

Remote banking does not fail in isolation: it runs inside a web of integrations with accounting, active operations, sales channels and terminal networks. Finding which component actually broke means evaluating the whole complex, not one application.

What made this urgent rather than merely important is what a payday outage means for a bank of this size. Salaries do not arrive, people cannot withdraw cash, and the failure is visible to every customer at once. The bank's CIO and CTO decided the fastest route to an answer was an outside team that does this daily, rather than an internal search under time pressure.

What we found in the first two weeks

PFLB engineers started with the immediate risk - the next banking day - and then went after root causes.

• 200+ system errors were identified that degraded both performance and stability.
• The most critical bottleneck: when the application server opened new database connections, they were rejected as timed out. Raising the database session timeout from 5 to 30 seconds removed the crash condition.
• Performance tests were run immediately before the next payroll period to confirm the fix under real peak conditions. The bank passed that day without failures.
• Stress testing was added to predict behaviour on future peak days rather than react to them.

The whole urgent phase took less than two weeks, and it produced a prioritised backlog of stabilisation work rather than a one-off patch.

Building a process that outlives the engagement

The bank's remote banking system was under active development, so every release could change performance. Rather than repeat the emergency, the client chose to make performance testing part of routine business process. That second phase ran for six months.

• Scaling, new module launches and development became predictable and transparent to plan against.
• The available performance reserve was quantified against performance metrics by evaluating RBS components against a quick-response service mockup.
• Non-optimal database queries - the kind that stay hidden even in Oracle statistics - were found and optimised.
• Duplicated queries affecting business logic were reorganised.
• Comparative load testing was written into the in-house release policy, so performance changes surface at release time.

“PFLB helped us with the most complex technical part. This contribution was priceless. Our system can now handle a load of 450% of a peak load day profile.”

CIO of the client bank

Results

• 450% load capacity relative to the production peak-day profile - the bank can run critical business processes without crash risk.
• Performance testing moved in-house. During the project the bank's own team learned to locate and diagnose bottlenecks; it is now a function of the IT department.
• Embedding performance testing into development raised the maturity of the bank's engineering culture - which was the point, given the bank's in-house development policy.

Questions this engagement answers

How fast can a bank stabilise a failing system?

In this case, under two weeks from engagement to a payday survived without failures - because the first phase targeted the immediate peak, not a complete rebuild.

What does performance testing find in a banking system?

Here: 200+ errors affecting performance and stability, a database connection timeout that caused crashes under peak load, non-optimal and duplicated database queries invisible in standard Oracle statistics.

Can a bank run performance testing itself afterwards?

Yes - that was the explicit goal of the six-month second phase, and the bank's IT department now owns the process.