CASE STUDY · FINANCIAL SERVICES · AGILE DELIVERY
An Independent IV&V Review Catches Vendor Vulnerabilities Before Go-Live for a Regional Bank
Findings surfaced while fixes were still cheap, so the vendor hardened the paying agency application before it went live.
The Enterprise Challenge
A vendor-built application had no independent review to verify its objectives or surface vulnerabilities before launch.
The client is a publicly traded regional bank, a full-service, community-oriented institution offering commercial and business banking, personal banking, and wealth management. The bank is committed to helping its customers grow their personal wealth and finance real estate investments, equipment, and businesses, and it uses the latest technology to provide innovative banking products and superior customer service designed with its customers in mind. That technology commitment is the backdrop for this engagement: the bank’s standards for the systems it runs are as high as its standards for the products it offers.
A third-party vendor was building the bank’s Paying Agency Application, and the bank required an independent verification and validation (IV&V) code review to ensure its objectives were being met. It needed an objective firm to identify and mitigate any risks, ensure quality and compliance, and validate that the application was being built based on the bank’s requirements, because in the financial industry, objectivity, quality, and adherence to standards are paramount, and a vendor cannot independently verify its own work. The bank engaged i3solutions to be that check.
The Solution
At a Glance
A regional bank’s vendor-built paying agency application had never gone through an independent review before launch. i3solutions ran an IV&V assessment that caught vulnerabilities while they were still inexpensive to fix, before the system went live.
The independent review identified vulnerabilities and addressed them early, before they became costly post-implementation fixes or security incidents, and gave the bank independently validated confirmation that the vendor’s application met its objectives and milestones.
Strategic Trigger
The Only Check on the Vendor’s Work Was the Vendor
The bank was not short on development capacity; the Paying Agency Application already had a builder. What it lacked was any check on that build that did not originate with the party being checked. Objectives had been set, milestones existed, and success criteria were defined, but the only entity confirming the application actually met them was the vendor writing the code. In most industries that is an uncomfortable arrangement; in banking it is an unacceptable one.
The trigger was therefore structural rather than an incident: no defect had to surface for the bank to act. The bank required an independent verification and validation code review while the application was still in development, and engaged i3solutions to check the vendor’s work against the bank’s own requirements and to surface any risks in time to mitigate them.
Conditions That Triggered the Engagement
- A Paying Agency Application under development by a third-party vendor, with no independent verification that the bank’s objectives were being met
- Quality, compliance, and requirements alignment resting entirely on the assurances of the same vendor doing the building
- Potential vulnerabilities and security issues that would become costly post-implementation fixes and security breaches if not identified early
A Bank Shouldn't Take a Vendor's Word for Its Own Application
This bank brought in a firm with no stake in the build to confirm its own targets and surface weak points early. If a vendor-built application in your environment hasn’t had that independent check, it’s worth having before go-live, not after.
Stakes
What a Defect Costs After a Banking Application Ships
The Paying Agency Application would run inside a full-service institution offering commercial and business banking, personal banking, and wealth management, so its failure modes were not internal inconveniences. Errors, crashes, and security breaches in a customer-facing banking application put real accounts and real transactions at risk; a vulnerability that survived to production meant exposure to data breaches or unauthorized access; and the application’s quality would carry straight through to how customers experienced the bank’s services.
The economics ran the same direction. Issues that surface after implementation are the expensive kind: costly post-implementation fixes and security breaches, remediated under pressure in a live system. Issues identified early in the project are the cheap kind. The stakes of skipping the review were not hypothetical: every defect the vendor’s own process missed would eventually be found, and the only question was whether it would be found by an independent reviewer during development or by the bank and its customers after it.
Constraints and Complexity
Independence Is the Constraint, Not a Feature
The defining constraint was the role itself. i3solutions worked in an independent analysis and assessment role rather than a development one: the value of every finding depended on the reviewer having no stake in the code being reviewed. That shaped the engagement’s boundaries. i3solutions did not build the Paying Agency Application and was not there to take over the build; it was there to verify the build against targets the bank itself had set and confirmed jointly with i3solutions at the start of the work.
The second constraint was coverage. A review that only read source code would miss runtime behavior, and one that only ran tests would miss structural weaknesses, so the engagement had to span both: reading the code for weaknesses, and testing the running application for behavior the reading could not show. A bank cannot certify half a review, so partial coverage was never an option.
Selection Rationale
An Objective Firm with More Than 25 Years of Development and Testing Experience
The vendor profile the bank needed was unusual: not another builder, but a reviewer credible enough that its findings would stand up. That meant real development and testing depth, because a reviewer who has not built comparable systems cannot judge one; real independence, because a reviewer with a stake in the build cannot be objective about it; and discipline about scope, agreeing the review’s reference points with the bank first so the review measured the application against the bank’s requirements rather than the reviewer’s preferences.
The bank engaged i3solutions as that objective firm. i3solutions brought more than 25 years of development and testing experience to the work and applied it strictly as a reviewer, never as the application’s builder. The combination matched the engagement: enough delivery experience to recognize a weak codebase when reading one, and enough distance from the build to say so without conflict.
The Engagement Approach
i3solutions was engaged to provide an IV&V consultation and code review for the bank’s Paying Agency Application, and devised a structured approach to address the bank’s challenges: confirm the targets, review the code, validate the behavior, and get findings addressed while fixes were still inexpensive.
PHASE 01
Assessment and Planning
i3solutions initiated the project by conducting a thorough assessment of the bank’s specific requirements, working closely with the bank to confirm objectives, milestones, and success criteria. That agreement gave the review its reference point: every subsequent finding was measured against what the bank required, not against what the vendor had chosen to build.
PHASE 02
Code Review
The i3solutions team reviewed the Paying Agency Application’s code to identify areas for optimization, security enhancements, and potential vulnerabilities. Every weakness found here cost the bank a fix. Any weakness found after launch would have cost far more.
PHASE 03
Quality Assurance and Testing
i3solutions implemented a quality assurance process built on testing rather than sampling. Automated testing tools and manual testing procedures were employed, with testing frameworks used to evaluate the application systematically rather than by spot check. The target was to validate the application’s functionality, performance, and security before the bank had to depend on any of the three.
PHASE 04
Early Remediation and Verification
Vulnerabilities and security issues identified during the code review were promptly addressed, while the application was still in development and fixes were still inexpensive. The completed review added an independent layer of validation and verification to the application’s development, helping ensure quality, compliance, risk mitigation, and the successful achievement of the project’s objectives.
Technical Transformation
This engagement’s technical work product is a verification layer wrapped around another vendor’s build. The static half read the Paying Agency Application’s codebase for weak points: places needing optimization, spots where security had to be hardened, defects that had not yet surfaced. The behavioral half validated what the code actually did when run, exercising the application with automated tooling, hand-run test procedures, and frameworks that check a system end to end instead of piecemeal. Neither half floated free. Both ran against a fixed reference: the objectives the bank confirmed with i3solutions at the start of the engagement. That anchoring is what turned the review from a technical opinion into a check that the application was being built to the bank’s requirements. Behind the tooling sat more than 25 years of development and testing experience, applied from outside the vendor relationship. The distance is the point. A finding is only as credible as the independence of the firm that produced it, and a bank cannot take the builder’s word for the build.
Measurable Outcomes
Vulnerabilities Caught Before Launch
An independent code review tested the application from outside the vendor relationship and surfaced issues while they were still cheap to fix.
| Outcome | Before | After |
|---|---|---|
| Application quality | Vendor-built code with no independent review | Enhanced application quality with reduced risk of errors, crashes, and security breaches |
| Security posture | Potential vulnerabilities unexamined outside the vendor relationship | Vulnerabilities identified and promptly addressed; reduced risk of data breaches or unauthorized access |
| Requirements alignment | Objectives verified only by the vendor building to them | Objectives, milestones, and success criteria confirmed and independently validated |
| Cost of defects | Costly post-implementation fixes and security breaches | Issues identified and addressed early in the project |
| Customer confidence | Application quality taken on faith | Higher customer satisfaction and confidence in the bank’s services |
The review’s impact shows up as risk removed rather than hours saved. The code review and quality assurance measures implemented by i3solutions resulted in enhanced application quality, reducing the risk of errors, crashes, and security breaches in an application the bank’s customers would transact through. Security moved the same direction: vulnerabilities and security issues identified during the code review were promptly addressed, significantly reducing the risk of data breaches or unauthorized access. And because the issues surfaced during development rather than after it, i3solutions helped the bank avoid costly post-implementation fixes and security breaches, which is where an IV&V engagement pays for itself.
The independence of the findings is what made them worth having. The review added an independent layer of validation and verification to the application’s development, helping ensure quality, compliance, risk mitigation, and the successful achievement of the project’s objectives, confirmed by a party outside the vendor relationship rather than by the vendor grading its own work. That mattered to this client because of the industry it operates in: a financial institution’s standards have to be verifiable by someone other than the party being held to them. And it carried through to the people the application serves: the quality of the Paying Agency Application translated to higher customer satisfaction and confidence in the bank’s services.
PENDING-CLIENT-QUOTE
Who This Engagement Serves
This engagement is relevant for
- A financial institution whose critical application is being built by a third-party vendor, with no verification of the work independent of that vendor
- A bank or regulated organization whose risk, audit, or compliance posture requires objectivity and adherence to standards that a building vendor cannot self-certify
- A project owner who wants vulnerabilities, security issues, and optimization needs surfaced during development, when fixes are cheap, rather than after implementation
Less relevant for
- You need the application built rather than independently reviewed; that is a custom application development engagement, not an IV&V one
- The application is a low-stakes internal tool where a post-release defect is an inconvenience rather than a regulatory, financial, or customer-trust event
What This Engagement Established
Quality, Security, and Compliance Confirmed Outside the Vendor Relationship
The engagement established that a bank does not have to take a vendor’s word for the quality of an application the vendor is building. An independent verification and validation code review, run by a firm with no stake in the build, confirmed the targets the bank itself had set, surfaced the code’s weak points before they hardened into production defects, and tested the application’s behavior with automated and manual procedures.
Issues found during development were promptly addressed instead of becoming costly post-implementation fixes, and the result was confirmed by a party outside the vendor relationship. That independent confirmation, in an industry that demands it, is the deliverable.
Frequently Asked Questions
An IV&V code review adds an independent layer of validation and verification to an application’s development: a party outside the vendor relationship reviews the code and tests the application against the client’s own requirements. In this engagement, a publicly traded regional bank had a Paying Agency Application being built by a third-party vendor and needed an objective firm to identify and mitigate any risks, ensure quality and compliance, and validate that the application was being built based on the bank’s requirements. The banking context is what makes the review necessary rather than optional: objectivity, quality, and adherence to standards are paramount in the financial industry, and a vendor confirming its own work provides none of the three. The reviewer’s independence is the product; the code review and the testing are how it is delivered.
Target first, measurement second. i3solutions began this project with an assessment of the bank’s specific requirements, working closely with the bank to confirm objectives, milestones, and success criteria. Only then did the review begin. The code review measured the application against that agreement and flagged where the code needed optimization or security work. Automated and manual testing followed, validating how the application behaved rather than how it read. The firm doing all of this had no stake in the code: i3solutions held an analysis and assessment role, not a development one, which is what made the findings worth acting on. A vendor’s own QA answers to the vendor’s deadline. An independent reviewer answers to the bank’s requirements.
Yes; that is exactly what this engagement was. i3solutions did not build the bank’s Paying Agency Application; a third-party vendor did, and i3solutions was engaged strictly as the independent reviewer. The arrangement works because the roles stay distinct. The vendor keeps building. The reviewer verifies the work from outside the build. The engagement started with an assessment of the bank’s specific requirements and joint confirmation of the review’s reference points, so the findings judged the vendor’s application against the bank’s requirements rather than the reviewer’s opinions. For the bank, that meant vulnerabilities and security issues were identified and promptly addressed during development, without changing who was responsible for delivering the application itself.
Two layers, one static and one behavioral. The code review reads the application’s source for areas needing optimization, security enhancements, and potential vulnerabilities. The quality assurance layer then validates what the application actually does, testing functionality, performance, and security with automated testing tools, manual testing procedures, and testing frameworks that evaluate the application systematically. Both layers are anchored to the criteria confirmed with the client at the start. That anchor is what distinguishes verification and validation from a generic quality audit: the question is never only whether the application is built well, but whether it is being built to the client’s requirements. In this engagement, both layers ran against a vendor-built banking application while it was still in development.
Four classes of benefit. Enhanced application quality: the code review and quality assurance measures reduced the risk of errors, crashes, and security breaches. Heightened security: vulnerabilities and security issues identified during the review were promptly addressed, significantly reducing the risk of data breaches or unauthorized access. Improved customer satisfaction: the quality of the Paying Agency Application translated to higher customer satisfaction and confidence in the bank’s services. And increased cost savings: issues found and addressed early in the project spared the bank costly post-implementation fixes. Beneath all four sits the structural gain: an assurance produced outside the vendor relationship, which is the one kind a financial institution cannot get from the vendor itself.
Because credible IV&V requires two things that rarely travel together: enough delivery depth to judge another team’s work, and enough independence to say plainly what the judgment finds. i3solutions brought more than 25 years of development and testing experience to this engagement and applied it strictly as a reviewer, never as the builder. The pattern of the work is repeatable: confirm the client’s success criteria first, review the code, test the behavior, and get findings addressed early, while fixes are inexpensive. For an institution that cannot take a vendor’s word for the vendor’s own work, a short scoping conversation establishes what an independent review of your vendor’s build would cover and what evidence it would return.
Yes, that is the specific service an IV&V engagement provides. i3solutions reviewed this regional bank’s vendor-built application independently of the vendor relationship, verifying it against the bank’s own objectives and surfacing vulnerabilities and security issues while they were still inexpensive to fix, rather than after go-live. Because the review sits outside the building vendor, it can flag issues a vendor reviewing its own work has no incentive to surface.
Related Insights
More From i3solutions
Related Engagements
Confirmed Outside the Vendor Relationship
That independent confirmation, in an industry that demands it, was the actual deliverable here. We’re glad to discuss what a comparable independent review would look like for your application.
