AI × QE / Financial-services evidence

A credible first step
for AI-assisted QE.

Banks and fintech firms are using AI to expand testing capability. Use their reported results to choose a focused trial, define the evidence you need and decide where to begin.

Seven cases connect test design, legacy unit tests, change intelligence and QE modernization. Named vendor cases, a bank report and a controlled coding study answer different questions. These are peer examples; Our Banking Client remains a fictional proposal.

Choose a first trial →Explore the cases →

01 / What has been reported

Evidence for an opportunity worth testing

Libra Internet Bank

35% less time

Test-creation timeIndex: previous time = 100

Previous 100

Reported 65

0100

UiPath customer case. Normalized from the reported reduction; review effort is unspecified. F1

Goldman Sachs

36% → 72%

Unit-test coverageShare of a selected module (%)

Before 36

After 72

0100

Diffblue customer case. Coverage measures exercised code; it does not establish financial correctness. F2

Fiserv

65% fewer incidents

Major incidentsIndex: previous year = 100

Prior year 100

Reported 35

0100

Tricentis modernization case. AI testing was a later pilot; this is not an AI-attributed reduction. F4

Separate outcomes and denominators. Each panel has its own meaning; no combined savings rate is calculated.

Our conclusion: start where a team can independently judge the output and measure the work. Public cases support that opportunity, but they do not establish a transferable QA savings rate. No case reviewed here supplies an independently audited, comparable bank-wide net AI-QE saving.

02 / Inspect the example behind the headline

Find a case relevant to the client's constraint

AI in testing covers direct test-generation examples. QE foundations covers broader modernization results. Adjacent AI covers coding and change-risk work that informs the approach without measuring test-team savings.

Named customer / vendor case

Libra Internet Bank

35% less test-creation time

Reported bank-level test design time

1. Starting contextRequirement-to-case preparation
2. InterventionAI-generated cases in the existing toolchain
3. Reported outcomeReported: 35% less test-creation time

UiPath reports 35% less time creating test cases and AI generation for more than 60% of cases used. The pilot began with two onboarding teams.

What changed

Requirements in Jira feed AI-generated cases alongside Xray and Test Manager; smoke automation expanded separately.

Evidence boundary

Vendor-published customer account. Sample, measurement window and net review effort are undisclosed. The 90%+ smoke automation figure applies to teams using UiPath.

Application to a client trial

Try reviewed scenario drafting on one onboarding journey; measure accepted coverage and total effort.

F1 · Read the original · Explore a related trial

Named customer / vendor case

Goldman Sachs

36% → 72% coverage

Reported unit-test coverage for a selected module

1. Starting contextLegacy Java regression coverage
2. InterventionAI-generated unit-test candidates
3. Reported outcomeReported: selected module coverage 36% → 72%

Diffblue reports this coverage increase within 24 hours. A separate application received 3,211 generated tests; review took one day.

What changed

AI-based Java regression-test generation supports legacy modernization.

Evidence boundary

Vendor case. Manual-time savings are modelled using 30 minutes per test and six productive hours per day. Coverage records exercised code, not proven business correctness; this is not an LLM rollout benchmark.

Application to a client trial

Generate candidates in a buildable module, then challenge assertions against independently specified behavior.

F2 · Read the original · Explore a related trial

Bank-authored operational report

DBS

5% → 100% of changes screened

Reported change-request screening coverage

DBS reports an 81% decrease in monthly average change-related incidents with AI risk scoring. It separately describes JIRA Assist for user stories and test cases.

What changed

Near-production testing, stronger change practices and ML-based screening support delivery reliability.

Evidence boundary

Bank self-report, without a causal control or raw incident counts. The incident result belongs to change-risk management; no JIRA Assist productivity percentage is reported.

Application to a client trial

Evaluate change-risk suggestions against known outcomes before allowing them to alter mandatory testing.

F3 · Read the original · Explore a related trial

Named customer / vendor case

Fiserv

65% fewer major incidents

Reported year-over-year incidents

1. Starting contextShared testing and delivery reliability
2. InterventionQE centre of excellence + integrated tooling
3. Reported outcomeReported: 65% fewer major incidents

Tricentis reports the decline during testing standardization across a large application estate.

What changed

A testing centre of excellence connects Jira, qTest, Tosca and data validation, with shared training.

Evidence boundary

Vendor case with multiple simultaneous changes. AI testing is a subsequent pilot; the quoted 25% AI uplift is an expectation, not a measured result.

Application to a client trial

Establish shared evidence, framework ownership and reusable data checks while piloting AI.

F4 · Read the original · Explore a related trial

Named customer / vendor case

Bank of Queensland

5+ weeks → 5 days

Reported regression cycle

The case reports shorter regression cycles within an 18-month transformation and releases moving from every three to four months to monthly.

What changed

Tosca and qTest support existing testers, traceability and daily environment health checks.

Evidence boundary

Vendor modernization case. Service virtualization and Vision AI appear as future work; the reported cycle reduction cannot be assigned to them.

Application to a client trial

Remove environment waits and build usable automation before promising a shorter release cycle.

F5 · Read the original · Explore a related trial

Bank-authored controlled coding experiment

ANZ

30.98 → 17.86 minutes

Mean self-reported time per Python challenge

The controlled crossover study involved over 100 engineers. Analysis retained 172 task observations after removing six duplicates and 22 unsolved tasks.

What changed

Copilot access switched between groups; participants attempted fixed Python problems.

Evidence boundary

Coding experiment, not QE delivery. Time was self-reported; failed tasks were excluded. The time test used 22 paired participants; unit-test success improvement was not statistically significant.

Application to a client trial

Compare matched tasks, retain unsuccessful attempts and measure quality separately from speed.

F6 · Read the original · Explore a related trial

Anonymous supplier case

Unnamed fintech software provider

42% less QA cycle effort claimed

Supplier-reported QA cycle effort

TestingXperts reports AI use in test design, automation, impact analysis, reporting and investigation.

What changed

Several workflow interventions are bundled in one engagement.

Evidence boundary

Client, sample and measurement period are undisclosed. The separate 60–70% productivity claim is not reconciled with its 10-hour to 4–5-hour example. Seek definitions and raw data before quoting it as a benchmark.

Application to a client trial

Use the workflow ideas to frame discovery; exclude the headline from the client savings forecast.

F7 · Read the original · Explore a related trial

03 / Patterns to adopt

Six practices for a credible first engagement

These are our recommendations drawn from the cases and measurement guidance, to be adapted to the client's environment.

1. Start with a bounded journey

Choose one onboarding or payment change with clear expected outcomes. Preserve the current toolchain where it supports the trial.

Proof to collect. A domain reviewer can accept or reject each proposed scenario.

F1

2. Give tests an independent correctness check

Coverage and passing tests are useful signals. Challenge money movement, rounding and retries with known failures and reviewed expected outcomes.

Proof to collect. A duplicate transfer or wrong balance causes the candidate test to fail.

F2, F10

3. Modernize the execution foundation

Assign owners to environments, fixture reset, dependency models and reusable frameworks. Track their improvements separately from AI.

Proof to collect. Another engineer reproduces the run and locates its original evidence.

F4, F5, F8

4. Keep the comparison honest

Use comparable work, the same readiness level and explicit task allocation. Include failures, review, rework and setup; record missing observations.

Proof to collect. The team can explain selection, exclusions and uncertainty in the result.

F6, F9

5. Run recommendations beside the existing process

Observe risk-based test selection or triage suggestions before changing required suites. Inspect missed defects and incorrect groupings.

Proof to collect. Mandatory payment checks still run, and wrong suggestions are visible.

F3

6. Scale a supported service

Coach domain QA and automation engineers together. Name a support owner and test transfer to a second team before expanding across 50–100 staff.

Proof to collect. The second team uses and maintains the pattern without its original authors.

F1, F4, F5

Connect the practices to the modernization backlog →

04 / Conditions for adoption

QE modernization is an AI adoption dependency

Assess the required capabilities for the selected application and workflow. Reviewed scenario drafting can begin when its own inputs and reviewers are ready; broader AI execution depends on repeatable tests, controlled environments and trustworthy evidence.

1. Assess the foundationInspect actual work, reliability and ownership.
2. Prove required capabilitiesFund gaps; retain evidence of repeatable results.
3. Enable the agreed AI scopeReview outputs; prove reuse before wider adoption.

One adoption model, two views: six modernization workstreams connect to the twelve assumptions in the readiness worksheet. A marked cell means that some capabilities in that workstream are required.

Which foundations enable the workflow?

Modernization workstream	Test design	Automation	Failure diagnosis only	Triage & retest
Test strategy and testability	● Required	● Required	● Required	● Required
Containerization and environment lifecycle	— Outside scope	● Required	— Outside scope	● Required
Service virtualization and contract fidelity	— Outside scope	● Required	— Outside scope	● Required
Data, fixtures and domain checks	— Outside scope	● Required	— Outside scope	● Required
CI execution and diagnostic evidence	● Required	● Required	● Required	● Required
Shared platform service and team skills	● Required	● Required	● Required	● Required

AI access, permitted context, evaluation, baseline measurement and funding also apply to every workflow. “Outside scope” does not mean a capability is unnecessary elsewhere.

Read all six modernization workstreams and their proof

Test strategy and testability

Readiness evidence. A known defect is caught by an independent assertion, and another engineer reproduces the result.

Accountable role. QE lead + application developers

Containerization and environment lifecycle

Readiness evidence. Two runs do not interfere, a clean runner recreates the environment, and failed runs leave no unowned resources.

Accountable role. Platform / DevOps owner

Service virtualization and contract fidelity

Readiness evidence. A deliberate contract mismatch fails a check, and timeout and duplicate scenarios can be replayed.

Accountable role. Integration lead + provider owner

Data, fixtures and domain checks

Readiness evidence. The retry scenario rejects a duplicate transfer or a wrong journal entry even if the API reports success.

Accountable role. Domain QA + data / application engineer

CI execution and diagnostic evidence

Readiness evidence. A failed required check stops promotion; evidence remains accessible after environment cleanup.

Accountable role. Developers + QE automation + DevOps

Shared platform service and team skills

Readiness evidence. A second squad runs the pattern, troubleshoots a failure and knows who owns the next action.

Accountable role. QE platform product owner + supplier delivery lead

Client assumption. These capabilities are unverified until the client supplies evidence. A roadmap or license purchase is insufficient. Capture each required gap, a named owner, remediation cost and a review date; unresolved execution dependencies hold that scope.

Containerization is an implementation option where suitable. Legacy, mobile and batch testing may need reproducible VMs, devices or reserved integration environments. Service substitutes require owned behavior and separate real-integration checks.

Assess client dependencies → · Modernization sources and technical guidance →

05 / How a generated test earns trust

Challenge the candidate before maintaining it

For PAY-142, the accepted behavior is one transfer and the expected journal and balances. A test that passes a deliberately duplicated transfer is inadequate even if its code coverage is high.

SYS Real systemsAI AssistanceREVIEW Human decisionPROOF EvidenceSIM Virtual serviceSTOP Failed check

Proposed design, not a bank's deployed architecture. The guided example ends at rejection. Independent checks and review determine acceptance. Practice and evidence.

Read the validation sequence

1. Approved intent reaches the assistant. The domain owner supplies expected behavior and permitted context.
2. A candidate reaches review. Generated tests remain proposals. A reviewer checks their intent and assertions.
3. Reviewed tests face an independent challenge. CI runs the normal build and a known-bad variant against controlled fixtures.
4. Invalid candidates return for correction. A compile error, wrong assertion or failure to detect the known fault rejects the candidate. Nothing is promoted.

A separate candidate that meets all agreed checks may enter the maintained suite. Rework alone does not establish acceptance.

06 / Make the trial persuasive

Show the incremental AI effect

Shared conditions · Comparable tasks, same framework, environment and acceptance rules

Conventional work

1. Engineer drafts
2. Reviewer checks
3. Tests challenge behavior
4. Retain results and effort

AI-assisted work

1. AI + engineer draft
2. Reviewer checks
3. Tests challenge behavior
4. Retain results and effort

Compare accepted outcomes · Include unsuccessful attempts, review, rework and operating costs

Proposed evaluation design informed by ANZ's study limitations and METR's selection findings. Separate modernization gains from incremental AI effects.

ANZ's experiment used self-reported time and excluded unsolved tasks; its quality results also differ by metric. METR's February 2026 update reports selection problems and uncertain effect estimates. Our proposal is to record every assigned attempt, keep unsuccessful work visible and use the same acceptance criteria in both groups. F6, F9

Measure	What to record	Decision use
Accepted work	Agreed coverage, correct assertions and reviewer disposition	Compare usable outputs, including rejected attempts.
Active effort	Drafting, review, repair, reruns and support in non-overlapping stages	Calculate net effort per accepted task; record setup separately.
Quality	Known-defect detection, critical omissions, flaky failures and escapes	Pause expansion when required correctness checks fail.
Elapsed time	Queue, environment and provider waits alongside active time	Identify whether the critical path actually shortens.
Economic capture	Tool/runtime costs and a named redeployment or budget mechanism	Distinguish usable capacity from cash savings.

Use client baselines to agree targets before starting. Keep inconclusive results as inconclusive; a small successful pilot supports a next increment, not an enterprise effect-size claim.

07 / A practical client invitation

Choose one workflow to prove together

Requirements ready

Onboarding design

Draft scenarios in the current test-management workflow.

Proof

Accepted coverage and measured review effort.

Execution repeatable

Payment API tests

Generate candidates in the existing framework and CI pipeline.

Proof

Correct behavior passes; a known fault fails.

Diagnostics available

Failure triage

Draft diagnoses alongside the existing disposition process.

Proof

Faster correct decisions with traceable evidence.

Proposed entry points. Choose one using the client's constraints; inspect prerequisites and prepare a trial brief.

Onboarding test design

Manual case writing dominates; requirements and domain reviewers are available.

Example stack

Jira + Xray, or Azure Boards + Test Plans; an approved assistant drafts into the existing review workflow.

Client inputs

One onboarding journey, approved acceptance rules, historic cases and known omissions.

Deliverable

A reviewed scenario matrix, rejected drafts and traceable expected outcomes.

Prerequisites

Approved source access, consistent requirements, reviewer time and a conventional-work baseline.

QE modernization dependency

QE modernization for this scope: versioned requirements, a curated scenario catalog, independent expected outcomes and a named domain reviewer. Reviewed drafting may start while execution foundations are improved; generated execution waits for its own prerequisites.

Measures

Active minutes per accepted scenario, review/rework, missed critical cases and duplicate cases.

Acceptance condition

All required onboarding rules are covered and independently reviewed; net effort improves on comparable work.

Pause condition

Pause if reviewers cannot establish correctness or critical scenarios are omitted.

Discovery question

Which onboarding rule is repeatedly missed, and who can judge a proposed test against it?

Assess this workflow’s dependencies → · Plan QE modernization →

Payment API test generation

A buildable service, stable API tests and repeatable test data already exist.

Example stack

JUnit + REST Assured; Testcontainers or a supported environment; WireMock at the provider boundary; existing CI.

Client inputs

PAY-142 rules, repository conventions, synthetic accounts and provider scenarios.

Deliverable

A reviewed test pull request, deliberate-fault results and retained CI artifacts.

Prerequisites

Build access, permitted AI tooling, runtime capacity, isolated fixtures, owned stubs and independent financial assertions.

QE modernization dependency

QE modernization for this scope: a maintained unit/API suite, independent financial assertions, resettable synthetic data, repeatable environments, controlled provider behavior and retained CI evidence. Use containers where suitable or a supported reproducible alternative; validate virtual services against contracts and separate real integration.

Measures

Effort per accepted change, assertion strength, flaky failures, setup time and repeatability.

Acceptance condition

Required checks pass on the intended build and fail on a deliberately broken duplicate-posting variant.

Pause condition

Stop if a candidate weakens assertions, silently skips required checks or passes the broken variant.

Discovery question

Can two engineers reproduce the same payment failure in an isolated environment today?

Assess this workflow’s dependencies → · Plan QE modernization →

Failure triage and evidence

Test runs already retain usable logs, traces, assertions and defect dispositions.

Example stack

Existing CI and test management; Playwright traces or API logs; approved AI summaries linked to source artifacts.

Client inputs

A bounded set of historical failures with independently adjudicated causes, then new failures in shadow mode.

Deliverable

Evidence-linked draft diagnoses with uncertainty, reviewer corrections and original run links.

Prerequisites

Accessible diagnostics, run IDs, reviewer capacity and a policy for retaining permitted evidence.

QE modernization dependency

QE modernization for this scope: reliable test outcomes, stable run IDs, retained logs/traces, known defect dispositions and named owners for tests, data and environments. Recommendations stay in shadow mode until their accuracy is reviewed; missing diagnostics require remediation first. This diagnostic-only trial does not execute fixes or retests; assess Triage & retest separately before expanding its scope.

Measures

Time to correct disposition, unsupported claims, wrong grouping, missed product defects and review burden.

Acceptance condition

Reviewers can trace every material claim to evidence, and product defects remain visible.

Pause condition

Pause if the tool invents a cause, hides an unresolved failure or collapses distinct product defects.

Discovery question

How much time is spent finding evidence versus making the actual diagnosis?

Assess this workflow’s dependencies → · Plan QE modernization →

“Let's choose one workflow your team already owns. We'll agree what good looks like, keep the existing tools where they fit, and compare reviewed outcomes and total effort. You'll leave with reusable assets and evidence for the next decision.”

Questions to settle in the first conversation

We already own Selenium, Playwright or a commercial suite. What changes?

Keep the framework when it fits. The trial can improve the work around it: drafting scenarios, producing reviewed pull requests or assembling evidence. Compare incremental benefit before buying a replacement platform.

How does this work for a manual-heavy offshore QA team?

Begin with a coached group of domain testers and automation engineers. Domain QA owns expected behavior and acceptance; engineers own executable checks and integration. Reuse the resulting templates and coaching with a second team before wider rollout.

What would make us continue or stop?

Agree the required quality checks, total-effort measurement and a review date. Continue only when the evidence supports the next scope. If readiness or net benefit is insufficient, retain the baseline, reviewed assets and a specific remediation backlog.

Fit it into the Our Banking Client delivery plan

The existing fictional case assumes 75 offshore QA staff, with eight in the pilot cohort. Use weeks 1–2 to establish readiness and the baseline, weeks 3–8 for the bounded payment pilot, and weeks 9–12 for a second-team reuse trial. This is an illustrative planning sequence; change scope or timing when prerequisites are missing.

Commercial structure. Treat QE modernization as a costed dependency workstream with owners, acceptance evidence and review dates. Separate assessment and foundation remediation from pilot delivery, licenses/runtime, coaching and ongoing support. The client approves scope and acceptance conditions before wider adoption; the case's setup allowance does not price a real engagement.

Check adoption prerequisites →Review the Our Banking Client implementation →Open the presentation room →

08 / Evidence you can inspect

Source library

Reviewed 2026-09-07. Unspecified publication dates remain unknown; retrieval dates do not establish when an outcome occurred. KPMG supplies industry context, not an additional independently measured client case. No licensed analyst report or publisher endorsement is implied. Source register CSV · JSON.

F1 · Libra Internet Bank: AI-assisted test design

UiPath · Named customer / vendor case

Inspect: Bringing AI-powered software testing to banking teams; Outcomes.

Public full text · Reviewed 2026-09-07

F2 · Goldman Sachs: automated Java unit tests

Diffblue · Named customer / vendor case

Inspect: Results; Time spent writing unit tests and manual-effort footnote.

Public full text · Reviewed 2026-09-07

F3 · DBS annual report 2024: CIO statement

DBS · Bank-authored operational report

Inspect: Change management; JIRA Assist; AI-powered change risk scoring.

Public full text · 2024 reporting year · Reviewed 2026-09-07

F4 · Fiserv: testing transformation

Tricentis · Named customer / vendor case

Inspect: Company overview; Embracing the future with AI; Result.

Public full text · Reviewed 2026-09-07

F5 · Bank of Queensland: quality as a service

Tricentis · Named customer / vendor case

Inspect: Results; Looking to the future.

Public full text · Reviewed 2026-09-07

F6 · ANZ: empirical study of GitHub Copilot

Chatterjee, Liu, Rowland and Hogarth · Bank-authored controlled coding experiment

Inspect: Sections 3, 4.6, 4.9 and 5; PDF pp. 4, 6–7, 11–13.

Public full text · 2024-04-17 · Reviewed 2026-09-07

F7 · Unnamed fintech provider: AI-led QE

TestingXperts · Anonymous supplier case

Inspect: Summary; AI-Led Test Design Transformation; Impact-Driven Test Prioritization.

Public full text · Reviewed 2026-09-07

F8 · Software testing in financial services: Market Insights 2025

KPMG · Consultancy synthesis

Inspect: Pages 10–13; used for context, not as an independent outcome study.

Public full text · 2025 · Reviewed 2026-09-07

F9 · Changing the developer productivity experiment design

METR · Independent research / methodological update

Inspect: Selection effects; raw estimates and confidence intervals.

Public full text · 2026-02-24 · Reviewed 2026-09-07

F10 · What is Diffblue Cover?

Diffblue · Product documentation

Inspect: How it works: regression tests capture current behavior.

Public full text · Reviewed 2026-09-07