How do you test a loan calculator when identical inputs can quietly produce two different monthly payments?
Azati's QA engineer found that a bank's construction loan product sometimes returned a different monthly payment for identical inputs, traced the cause to inconsistent caching between the scoring and loan calculation services, and helped the team fix it before the release reached customers. Calculation discrepancies fell from about 5-7% to 0%, and incorrect API responses dropped from up to 8% to under 0.5%, on a system handling several thousand applications a day.
discrepancy between repeated loan calculations on identical inputs, before and after the cache fix
share of incorrect loan-calculation API responses after the fix, down from up to 8%
loan applications a day passing through the system
It was a new way to borrow money to build a house, and quality mattered because every customer would see a monthly payment and trust it.
A customer applies for a construction loan to build a residential house, or to build one while buying the land plot. The bank reviews the attached documents, the customer goes through verification, compliance, and anti-fraud checks, and when the checks pass and both sides accept the amounts, the loan is issued. The bank then tracks repayment for years afterward.
As the project team recalls, no application of this kind existed on the market at the time, so the product was a startup-style bet inside the bank's existing Pega-based banking app. The bank's earlier approach to the problem had been developing the application from scratch.
Azati was one of the bank's technology vendors, working in Agile over 1.5 years. This case covers the part where QA mattered most: a release that changed how loan terms were calculated and how applications were handled.
A construction loan moves through six stages: application, document review, verification and checks, scoring and terms, approval and issuance, and repayment. The QA risk concentrated in the fourth, where the platform calculates the loan terms.
| Stage | What happens |
|---|---|
| Application | The customer applies for a loan to build a house, or to build a house and buy the land plot. |
| Document review | The bank reviews all attached documents. |
| Verification and checks | The customer passes verification, compliance, and anti-fraud checks. |
| Scoring and terms | The platform scores the application and calculates loan terms, including the monthly payment. |
| Approval and issuance | If the checks pass and both the customer and the bank accept the amounts, the loan is issued. |
| Repayment | The bank tracks repayment over the life of the loan. |
The release changed three connected pieces at once, loan calculation, user data caching, and scoring, so a mistake in one could quietly distort the others.
Before the release, the team received changes to how loan terms were calculated and how applications were handled. QA named the risk early: complex logic plus many dependencies. The changes touched:
When an application was reopened, the calculated monthly payment sometimes changed even though the inputs stayed the same. The difference reached a few percent, which is small enough to wave off and large enough to matter:
A wrong payment is not an internal log entry. The customer sees it, and the bank has to stand behind it:
Calculation sits in the middle of a chain that starts with documents and runs through verification, compliance, and anti-fraud checks, and it ends with years of repayment tracking:
By treating the odd result as evidence, forming a hypothesis, and trying to break it with parallel actions until it reproduced every time.
Reopening an application occasionally changed the calculated monthly payment by a few percent. Nothing in the inputs explained it, and that was the signal.
The first guess was a stale cache, a classic cache invalidation problem, or data falling out of sync between services. It stayed a guess until the behavior could be reproduced on demand.
Opening the same application in several tabs and triggering quick recalculations made the problem appear consistently: identical inputs, different results.
Under higher load the behavior repeated, which showed the issue was systemic rather than a one-off.
QA localized the cause to inconsistent caching and data desynchronization between the scoring service and the loan calculation service, and helped reproduce the scenario in an isolated environment. The team then changed the cache update and synchronization logic.
If your product turns inputs into money, such as loan terms, premiums, prices, or fees, consistency is a feature that needs its own tests. Tell us what your next release changes.
Ask us about testing financial calculationsFour pieces: risk analysis of the changed areas, reproduction of the inconsistency, root-cause localization, and regression safeguards that stay in the suite.
QA started from what the release actually touched: the loan calculation API, user data caching, and scoring. The risk was named up front as complex logic with many dependencies, and the test scope followed from it, covering standard scenarios plus load and repeated application submission.
QA opened one application in several tabs and ran quick recalculations until identical inputs gave different results on demand, then repeated the check under higher load to confirm the issue was systemic.
The cause turned out to be inconsistent caching and data desynchronization between the scoring service and the loan calculation service. QA helped recreate the scenario in an isolated environment, and the team changed the cache update and synchronization logic.
Three additions keep the defect from returning silently.
After the fix, the discrepancy between repeated calculations fell from about 5-7% to 0%, incorrect API responses dropped from up to 8% to under 0.5%, and stability under parallel requests was fully restored.
| Area | Before the fix | After the fix |
|---|---|---|
| Discrepancy between repeated calculations | About 5-7% | 0% |
| Incorrect responses from the loan calculation API | Up to about 8% | Under 0.5% |
| Stability of calculations under parallel requests | Inconsistent results for identical inputs | Fully restored |
It prevented customers from seeing the wrong loan conditions on a system that handles several thousand applications a day.
That is a result measured in an incident that never happened, so the numbers above are the evidence and the rest is risk avoided.
Even a deviation of a few percent would have put incorrect conditions in front of customers, across several thousand applications a day.
A few percent of error meant tens of thousands in potential financial discrepancies.
Incorrect conditions could have been contested by customers, which turns a calculation bug into a legal problem.
A payment that changes between visits undermines confidence in the whole lending product.
Consistency, parallel-request, and cache checks live in the regression suite, so the same kind of drift gets caught by tests, not by customers.
Three lessons: the same input giving a different output is a correctness bug even at a few percent, parallel actions belong in the test plan of any calculator, and a hypothesis is not a finding until it reproduces.
The problem was not the size of the difference. It was that the same input produced different answers. In ISO/IEC 25010 terms, that is a functional correctness failure. A small, intermittent drift is easy to dismiss and expensive to ignore.
Opening one application in several tabs and recalculating quickly turned an occasional anomaly into a reproducible defect. That pattern is cheap to run and expensive to skip.
Caching was only a guess until QA reproduced the problem on demand, confirmed it under load, and recreated it in an isolated environment. That reproducible case is what let the team fix the cause, not the symptom.
When a release changes loan calculation, QA should cover four things first, in this order: consistency of repeated calculations, parallel and repeated user actions, cross-service data sync, and behavior under load. Each of them can change a number the customer sees without raising any error.
| Priority | Why it matters | When it becomes urgent |
|---|---|---|
| Consistency of repeated calculations | The same inputs must always produce the same terms, or customers lose trust in the numbers. | When a release touches calculation logic, caching, or scoring. |
| Parallel and repeated user actions | Several tabs and quick recalculations expose shared-state problems that one-user-at-a-time tests tend to miss. | When customers can reopen or edit an application while it is being recalculated. |
| Cross-service data sync | If scoring and calculation hold different versions of the same data, results diverge. | When more than one service contributes to the same number a customer sees. |
| Behavior under load | Problems that look occasional can turn out to be systemic as traffic grows. | When the system handles thousands of applications a day. |
Azati worked as one of the bank's technology vendors, with a single specialist on the project.
The engagement ran for 1.5 years in Agile, and QA worked on releases as they arrived, including the one that changed how loan terms were calculated.
Azati was one of the bank's technology vendors, working inside the bank's own product and delivery landscape, with a single Azati specialist on the project.
It fits teams shipping financial calculations that customers see and rely on, such as loan terms, premiums, prices, fees, or schedules.
If you're the one who has to explain to a risk or product owner why a few percent in a payment calculation was worth a deep investigation, this FAQ is written for that conversation.
Azati's QA engineer tested a Pega-based construction loan product for a bank, covering the loan calculation API, caching, and scoring logic before release.
The work included load, repeated-application, and parallel-request scenarios, and ended with regression tests that stay in the suite.
A construction loan platform takes a customer from application to loan issuance and repayment tracking for building a house.
On this project, the customer applies to build a residential house, or to build one while buying the land plot. The bank reviews the attached documents, the customer passes verification, compliance, and anti-fraud checks, and the loan is issued when the checks pass and both sides accept the amounts.
Azati, one of the bank's technology vendors, tested the part of this flow that calculates loan terms.
Consistency testing runs identical inputs repeatedly, across sessions and in parallel, and checks that the result never changes.
Azati's QA engineer applied this to the bank's construction loan product by reopening applications, opening them in several tabs, and triggering quick recalculations, which exposed a monthly payment that shifted by a few percent.
Inconsistent caching and out-of-sync data between the scoring service and the loan calculation service caused the changing payment.
Azati's QA engineer localized the cause through parallel-action testing and helped recreate it in an isolated environment, after which the bank's team changed the cache update and data synchronization logic.
Parallel actions expose shared-state problems, such as stale cache data, that one-user, one-step tests often miss.
In this engagement, Azati's QA engineer used several tabs and rapid recalculations to turn an occasional payment change into a defect that reproduced every time.
Calculation discrepancies fell from about 5-7% to 0%, and incorrect API responses dropped from up to 8% to under 0.5%.
Azati's QA engineer also confirmed that calculation stability under parallel requests was fully restored after retesting.
Regression coverage aimed at consistency, parallel requests, and cache behavior keeps this class of defect from returning unnoticed.
For this project, Azati added automated tests for calculation consistency, parallel-request scenarios, and cache checks in the regression suite.
A few percent of error means customers see wrong loan conditions, which creates financial and legal exposure for the bank.
With several thousand applications a day passing through the system, even that deviation could mean tens of thousands in financial discrepancies, contested terms, and lost customer trust. Azati's QA work traced it to a root cause and covered it with permanent regression tests.
Azati was one of the bank's technology vendors, with a single specialist working in Agile over 1.5 years.
On the construction loan product, Azati's QA engineer tested the changed loan calculation API, caching, and scoring logic before release, including load, repeated-application, and parallel-request scenarios.
Bring the release scope. We will tell you which consistency, parallel-request, and load scenarios are worth running before customers see the numbers.
Talk about your release testing
Live capital-markets modernization: Java 11 to 21 migration, configurable competition rules, and financial-system integrations delivered inside an existing product and security environment.
Phased clearing modernization: 40+ Java microservices built alongside the legacy monolith, with adapter-based integrations to trading, accounting, and CRM systems.
Fintech payment platform infrastructure modernization: AWS automation, CI/CD optimization, and platform engineering that freed engineering leadership from daily operations and accelerated delivery.
Enterprise banking payroll module: React microfrontends, role-based access control, electronic signatures, and 75 reusable components delivered over 13 months.
Benelux equipment leasing platform: 10+ integrations across KYC, AML, and credit bureaus, contract automation with QES, and 5x sales growth in the Netherlands after rollout.
Ruby on Rails FinTech platform enhanced: banking integrations, reconciliation workflows, AI transaction categorization, and 10+ security mechanisms across 6 core platform domains.
Last updated
