At a glance
- Client: a large state-owned bank serving hundreds of government organisations and corporations
- System: FIS Profile - the bank's core transaction engine, running 65 million customers, 55 million contracts, 9 million loan agreements and 45 million cards
- Load tested: approximately 6 million operations per hour (throughput matching real production intensity)
- Cadence: 11 releases per year for 7 years, each with a 24-hour reliability run across 50+ business cases
- Automation result: building a test plan went from 3–4 hours to 5–10 minutes
- Tools: Apache JMeter, LoadRunner, PFLB in-house tools, Grafana and InfluxDB for results
- Engagement type: continuous - performance testing embedded in the bank's release cycle, not a one-off project
Why this system is hard to test
FIS Profile is a NoSQL transaction processing engine from Fidelity Information Services, used by banks worldwide and running 24/7 for decades. It is also one of the least test-friendly platforms in banking:
- Built on IBM POWER architecture and written in MUMPS, a language with a small talent pool
- Console interface only, with no integration into common automation tools or frameworks
- Behaves as a black box - input and output, with the internals opaque
- Tens of terabytes of data
- Full support comes only from FIS, so information exchange is slow
The system carries user actions, regulatory batch operations, and Visa and Mastercard transaction processing simultaneously. If a release degrades it, employees do not get paid and customers cannot access cash - the failure mode is social, not just technical.
What the engagement involves
Each of the 11 annual releases contains roughly ten functional changes, and each change needs its own treatment. For every release the team:
The FIS Profile testing task.
- analyses execution statistics and performance requirements, then builds the load profile and the list of emulated operations
- runs 24-hour reliability testing across more than 50 business cases - account management, loans, payroll projects, card processing, customer data management
- determines maximum and peak performance metrics, verifies test reliability, and compares results against previous releases
- isolates the performance impact of each individual system change
- delivers analysis and recommendations for tuning Profile's settings
Before each release the team also generates data to grow the database so tests reflect the bank's future scale, not just today's: 160,000 clients, 160,000 accounts, 240,000 loans and 560,000 cards are added per release.
Tools built specifically for this system
Off-the-shelf load testing does not reach Profile, and neither does off-the-shelf capacity testing, so PFLB engineers built what was missing:
- an emulator for card operations over the ISO 8583 protocol
- external system emulators generating additional load through Java, JDBC and SOAP
- a framework that records request changes caused by system updates and automates test-data connection
Test-plan creation was automated end to end: a profile is assembled from collected statistics, a file is generated from it, values are compiled into XML, and the plan is created in LoadRunner over REST API. Results come back through Grafana and InfluxDB, and post-test data collection, charting and report preparation run automatically.
Results
- Test plan preparation dropped from 3–4 hours to 5–10 minutes through automation.
- Regular comparative testing of different system configurations under a real industrial load of ~6 million operations per hour became routine rather than exceptional.
- Automated test pools removed the need to process all data on the Virtual Table Server, making verification both faster and more accurate.
- The bank minimised the risk of production failures where the system becomes unavailable and customers cannot transact - avoiding both downtime and its cost.
- Performance degradation is now caught at release time, not in production.
Questions this engagement answers
Can performance testing work on a legacy core banking system?
Yes - including MUMPS on IBM POWER with a console-only interface, provided the missing tooling is built: here, an ISO 8583 emulator and external-system emulators over Java, JDBC and SOAP.
What load can a core banking system be tested at?
This one is tested at approximately 6 million operations per hour, matching production intensity, across 50+ business cases in 24-hour runs.
How does performance testing fit a release cycle?
Eleven releases a year, each tested before shipping, with per-change impact isolated - the testing process lives inside the software development life cycle rather than beside it.
How long do these engagements last?
This one has run for seven years and is ongoing. Continuous performance testing of a core system is a programme, not a project.
Running a core system you cannot afford to break?
Legacy cores rarely come with modern tooling, and that is usually the reason they go untested - not the risk appetite. Building the missing emulators is a known, finite piece of work; running blind through eleven releases a year is not.
