A large bank’s Real Time Gross Settlement (RTGS) batch processes were missing their completion windows and the problem got worse exactly when it mattered most, during month-end and quarter-end transaction spikes. Here’s how Avekshaa’s performance engineering team traced the bottleneck to the batch architecture itself, and fixed it at the source.
The Challenge: When Real-Time Settlement Isn't Real-Time
A large bank was dealing with business-impacting performance problems that were slowing down its daily inter-bank electronic settlements, transactions that, by design, are supposed to happen in real time. RTGS batch processes weren’t completing within their stipulated time, and that delay wasn’t just an operational inconvenience. It was a compliance issue.
The pattern was predictable and painful: performance degraded further whenever traffic load increased, particularly during month-end and quarter-end transaction volumes, precisely the periods when settlement accuracy and timeliness matter most to regulators, counterparty banks, and the bank’s own customers.
Why This Matters
RTGS in India is regulated under the RBI’s RTGS System Regulations and has operated 24x7x365 since December 2020. Unlike NEFT, which settles transactions in batches, RTGS is designed for continuous, individually settled, high-value transfers with no upper transaction limit. A bank whose internal batch architecture can’t keep pace with that design isn’t just facing a technical bottleneck — it’s exposed to settlement-SLA breaches that carry real regulatory weight.
Diagnosing the Bottleneck: Avekshaa's P-A-S-S™ Approach
Avekshaa was brought in to help the bank improve platform scalability and performance so that electronic transfer processes could be handled reliably within their defined time limits. The engagement followed Avekshaa’s P-A-S-S™ (Performance, Availability, Scalability, Security) consulting methodology – starting not with a fix, but with a full technical audit of the platform actually processing the transactions.
The technology stack under review was an Oracle Database paired with a third-party RTGS/NEFT middleware product — a combination common across Indian banking infrastructure. Rather than treating the slowdown as a capacity problem to be solved by adding servers, Avekshaa’s engineers dug into how the batch jobs were structured and executed against the available hardware.
| Industry | Banking |
| Engagement Type | Application Performance Engineering / Production Performance Troubleshooting |
| Technology Stack | Oracle Database, RTGS/NEFT middleware product |
| Core Problem | RTGS batch jobs missing SLA completion windows under peak load |
| Fix Delivered By | Middleware vendor’s next product release |
The Solution: Rebuilding for Parallel Processing
What the audit found was a batch architecture that wasn’t using the hardware it already had. Transactions were largely being processed in a way that left CPU and I/O capacity idle while jobs queued sequentially, meaning the bottleneck wasn’t insufficient infrastructure, it was underutilized infrastructure.
Avekshaa’s team identified a set of architectural changes centered on parallel processing: restructuring the batch workload so independent transactions could be processed concurrently across available compute resources, rather than one after another. This is a fundamentally different fix than “buy more servers”, it’s about extracting the throughput the existing platform was already capable of.
Two things made this engagement different from a typical tuning exercise. First, the recommendations didn’t stay as a one-off patch, they were accepted by the product vendor and built directly into the middleware’s next release, meaning the fix became part of the platform itself rather than a bank-specific workaround. Second, the change was validated against real peak-load conditions, not just steady-state traffic, since that was where the original failure consistently showed up.
Expert Insight
In performance engagements across core banking platforms, the most common root cause isn’t undersized infrastructure, it’s architecture that was designed for a lower transaction volume and never re-validated as load grew. Parallel processing redesigns tend to unlock far more headroom than hardware upgrades, at a fraction of the cost, because they fix how work is distributed rather than how much capacity is available to absorb inefficiency.
Results: 200% Scalability Gain, SLA Restored
The architectural changes delivered a measurable, structural improvement rather than a temporary fix:
- Compliance restored: RTGS batches began completing within their stipulated settlement windows, removing the compliance risk tied to late settlement.
- Peak-load resilience: The same architecture that struggled under month-end and quarter-end traffic now absorbed those spikes without degrading further.
- No new infrastructure spend: The gain came from better utilization of existing hardware, not additional procurement.
- Durable fix: Because the changes were adopted into the middleware vendor’s next release, the improvement wasn’t dependent on custom, hard-to-maintain patches.
Key Takeaways for Banking IT and Operations Leaders
Settlement delays are a compliance problem before they’re a customer-experience problem. For RTGS specifically, missed SLA windows carry regulatory implications, not just reputational ones.
Peak load is where architecture gets tested. A platform that performs fine on an average day can still be structurally unfit for month-end and quarter-end volume, that’s exactly when the gap shows up.
- Hardware utilization matters more than hardware capacity. Before scaling infrastructure, it’s worth confirming the existing platform is actually using what it has.
- Vendor-level fixes outlast custom patches. Getting an architectural recommendation adopted into a product’s core release is more durable than a bank-specific workaround.
Frequently Asked Questions
What causes RTGS batch processes to miss SLA deadlines?
RTGS batch delays are most often caused by architecture that can’t scale hardware utilization under peak load, commonly serialized processing that leaves CPU and I/O capacity idle while transactions queue, especially during month-end and quarter-end volume spikes.
How does parallel processing improve RTGS batch performance?
Parallel processing restructures batch workloads so independent transactions are processed concurrently across available hardware threads instead of one after another, increasing throughput and hardware utilization without adding infrastructure.
Why is RTGS settlement speed a compliance issue for banks?
RTGS is governed by RBI’s RTGS System Regulations and is designed for real-time, individually settled, high-value transfers. Batch processes that fall behind schedule risk breaching settlement SLAs, which can trigger regulatory and counterparty compliance issues.
What technology stack was involved in this case study?
The reviewed stack was an Oracle Database paired with a third-party RTGS/NEFT middleware product. Avekshaa’s architectural recommendations were implemented directly into the middleware vendor’s next product release.
How much did performance improve after the fix?
The redesigned batch architecture delivered more than a 200% increase in scalability, and batch processes began completing consistently within SLA-defined limits, including during peak month-end and quarter-end load.
