Understanding The Critical Differences
BY ANDREW MILLS - LAST UPDATED NOVEMBER 9, 2026
THE BOTTOM LINE
QUALITY ASSURANCE (QA) IS THE WORK THAT KEEPS DEFECTS OUT OF A CORE BANKING PROJECT.
Quality Control (QC) is the work that finds the ones that got in anyway. Your core vendor will run QC on its own build. QA across the whole program, from requirements through hypercare, is the institution’s job, and it needs an owner who is independent of the vendor.
On a core conversion, the two are easy to blur because the vendor’s testing can look like quality management for the whole program. It isn’t, and the confusion shows up later as rework, delays, and member complaints.
Understanding The Fundamental Difference
QUALITY ASSURANCE:
Quality Assurance is your prevention strategy. It's a proactive approach focused on establishing robust frameworks and standards before work begins. QA asks, "How can we prevent problems from occurring?" By implementing the right processes upfront, QA ensures consistent quality outcomes across your organization.
QUALITY CONTROL:
Quality Control, conversely, is your cure. This reactive approach involves inspecting and testing final products or services to verify they meet requirements. QC asks, "Does this output meet our quality standards?" It identifies and corrects defects in finished work.
| At a glance | Quality assurance (QA) | Quality control (QC) |
|---|---|---|
| The question it asks | How do we stop defects getting in? | Did any defects get in? |
| When it happens | From requirements and vendor selection through hypercare | From the first mock conversion through stabilization |
| Who owns it on a core conversion | The institution, independent of the vendor | Mostly the vendor for its own build; the institution for reconciliation and UAT |
| Core conversion example | Agreeing mapping rules and the exit criteria for each mock | Reconciling converted balances against the legacy system |
Who checks Whose Work
In a core conversion, QA and QC usually sit with different parties, and that is where institutions can get into trouble.
Your core vendor tests its own configuration and conversion programs. That is QC. But a vendor testing its own build can only confirm that the system does what the vendor understood you to want. It can’t tell you whether your ancillary systems, staff, and procedures are ready for the first business day after conversion.
That wider assurance belongs to the institution. Someone on your side needs to own the test strategy, good enough to live, and sign off on reconciliation results. That person, and any advisor supporting them, should be independent of delivery. As we noted in our post on implementation governance, an advisor who takes on delivery responsibility gives up the independence that made their review worth having. Vendor readiness works the same way: as we cover in planning a core banking implementation, it should be assessed independently, not just self-reported.
We’ve seen what happens when that ownership is missing. In one engagement, an implementation partner stepped away after a 30-day warranty and left the client to rebuild its own testing and acceptance process (read the case study).
When To Apply Each Approach
QUALITY ASSURANCE: SETTING THE FOUNDATION
QA work starts before the vendor contract is signed and runs through the whole program.
Requirements: Capture requirements and trace each one through design decisions, test cases, training materials and go-live procedures (See Banking System Requirement Gathering.)
Selection and Planning: Assess vendor readiness independently and build the test strategy, including how many mock conversions and dress rehearsals the program needs.
Governance: Shift governance attention toward quality assurance, defect resolution, and cutover planning as the project moves into testing.
Data and Integrations: Profile and cleanse data before conversion, and decide how each ancillary system will be integrated or replaced (see The Hidden Risks of Ancillary Systems in Core Banking Transformation.)
QUALITY CONTROL: VERIFYING RESULTS
QC runs from the first mock conversion through stabilization.
Mock Conversions: Test conversion programs and individual technical components in a controlled environment.
Dress Rehearsals and Integration Testing: Run the full conversion end to end with people, processes, and data together, including every ancillary interface. (See The Art of Mocks and Dress Rehearsals.)
Reconciliation and UAT: Reconcile converted balances and data against the legacy systems, and confirm staff can complete real work in the new one (See our data migration services.)
Hypercare and Stabilization: Monitor production against defined exit criteria. A vendor’s warranty period, typically around 30 days, is not enough for true stabilization, which usually runs from three months to a year. (See Beyond the Go-live.)
The Impact of Proper Implementation
Less rework: Defects caught at requirements or design cost less to fix than defects found in a mock conversion, and far less than those found after go-live.
Cleaner conversions: Mapping rules and exit criteria agreed up front leave fewer reconciliation exceptions to chase on conversion weekend.
Fewer member complaints: Staff who have rehearsed real work in the new system make fewer errors on the first business day.
Testing evidence on file: When an examiner or auditor asks how the program was tested, the answer is already documented.
Real-World Examples
Core Conversion: Mocks and Dress Rehearsals
A credit union replacing its core system shows how the two disciplines hand off to each other:
QA (Prevention): Before the first mock conversion, the team agrees on conversion mapping rules, traces requirements to test cases, and sets the criteria each mock and dress rehearsal must meet before the project moves on. The output of each mock becomes the input for the next round of testing.
QC (Detection): Mock conversions test the conversion programs and data in isolation. The dress rehearsal then runs the conversion weekend end to end, with staff, procedures, and ancillary systems involved. On one 2Oaks project the dress rehearsal revealed that cleaners needed to be scheduled at specific times over the conversion weekend, a detail no technical test would have caught.
Lesson: Mocks test the code. Dress rehearsals test the people. A program that runs only mocks can pass every technical test and still stumble on go-live weekend.
PITFALLS AND BEST PRACTICES
Common Pitfalls to Avoid
The most dangerous misconception is that testing alone constitutes a complete quality strategy. Testing is a QC activity - essential but insufficient without proper QA frameworks. Organizations focusing solely on QC often face:
Escalating costs from constant rework
Extended project timelines
Higher risk of major quality issues
Inconsistent project outcomes
Best Practices for Implementation
To maximize the effectiveness of your quality management strategy:
Establish Clear Standards: Define specific, measurable quality criteria tied to your institution’s goals, member expectations, and regulatory requirements, not generic industry benchmarks.
Document Everything: Document every quality-related process so it’s accessible to your team and ready for an examiner or auditor to review. That includes updating your business continuity plan as part of the project (Derrick Smith explains why in this short video).
Invest in Training: Train your team on both QA and QC principles and where each one’s responsibility begins and ends.
Review Regularly: Revisit your quality processes regularly and adjust them based on what each project surfaces.
Choose the Right Tools: Use test management, automated regression, and parallel-run reconciliation tools suited to the scale of your core banking or digital transformation project.
Key Questions to Ask Before Testing Begins
Who on our side, independent of the vendor, owns the test strategy?
Can every requirement be traced to at least one test case?
How many mock conversions and dress rehearsals does the plan include, and what has to be true to move from one to the next?
Which reconciliation results will we sign off before go-live, and who signs?
What are the exit criteria for hypercare, and how long have we budgeted for stabilization?
If an examiner asked for our testing evidence tomorrow, could we produce it?
Frequently Asked Questions
What is the difference between QA & QC?
QA prevents defects by setting the standards, processes, and checks before and during the work. QC finds defects by testing and inspecting what was built.
Is testing QA or QC?
Testing is QC: it checks whether the output works. Deciding on what to test, how much evidence is enough, and who signs off is QA.
Who should own QA on a core banking project?
The institution, not the vendor. The vendor tests its own build; someone on the institution’s side, independent of delivery, should own the test strategy and the go-live decision.
Conclusion
For credit unions, banks, and other regulated financial institutions, quality management is not optional. A core conversion or digital transformation project either goes smoothly, or generates rework, member complaints, and examiner attention.
2Oaks specializes in helping financial institutions build the right balance of QA and QC for exactly this kind of project. Contact us to discuss how we can help strengthen your quality management approach for your next core banking, ERP, or digital transformation initiative.
Further Reading
U.S. examiner expectations for testing and change management: FFIEC IT Examination Handbook: Development, Acquisition, and Maintenance booklet
For Canadian institutions: OSFI E-21 Is Here. The Questions Canadian Banks and Credit Unions Are Still Asking (Derrick Smith, 2Oaks).
ABOUT 2OAKS
2Oaks emerged from deep within the banking sector, where our founders personally navigated the challenges of core system modernization. This hands-on experience shaped our unique approach to technology consulting -one that combines technical expertise with practical wisdom. We're not your typical consultancy. As a vendor neutral partner, we work exclusively for our clients' interests across banking, financial services, retail, and public sectors.
What sets us apart is our commitment to co-creation and knowledge transfer. We work alongside your team, ensuring that our solutions aren't just implemented but truly integrated into your organization. Our lean, efficient approach eschews unnecessary complexity in favour of practical, results-driven outcomes. Whether you're facing a system transformation, technology upgrade, or strategic shift, reach out to 2Oaks to discover how our principled, authentic approach can drive your success.
