FCA compliance doesn’t require a specific testing tool or framework — it requires you to prove that your software behaves correctly, consistently, and safely for customers, and that you can produce evidence of that on demand. For most fintech engineering teams, the gap isn’t technical capability. It’s the absence of a testing process that generates auditable evidence as a byproduct of normal delivery, rather than as a scramble before a review.
This matters more than it used to. The FCA’s Consumer Duty rules, in force since July 2023, shifted the regulator’s focus from “did you follow a process” to “can you demonstrate good outcomes for customers” — and testing sits directly underneath that question. If a customer is charged incorrectly, locked out of an account, or shown a rate they weren’t eligible for, the FCA doesn’t ask which sprint that bug shipped in. It asks what your controls were.
What is the FCA actually looking for in a testing process?
The FCA doesn’t publish a testing checklist, because it regulates outcomes, not implementation. But across enforcement actions, Dear CEO letters, and Consumer Duty guidance, three expectations show up consistently:
- Evidence of testing coverage, not just a claim that testing happened — test cases mapped to specific regulatory requirements or customer harms
- Traceability between a requirement (a rule, a risk, a customer scenario) and the test that verifies it, so you can answer “how do we know this works” for any given feature
- Independent verification for higher-risk changes — pricing logic, eligibility checks, complaints handling, financial promotions — where the person who built the logic isn’t the only one who signed off on it
None of this means hiring a compliance officer to sit inside your sprint. It means your test process needs to produce artefacts — reports, coverage maps, sign-offs — that would make sense to someone outside engineering.
Which areas of a fintech product actually get scrutinised?
In practice, four categories draw the most regulatory attention, and they’re where testing gaps cause the most damage:
- Pricing and fee calculation — interest, FX conversion, fee tiers, discounts applied correctly and consistently across every customer segment
- Eligibility and onboarding logic — KYC/AML checks, affordability assessments, and product suitability rules working as designed, including edge cases
- Financial promotions — marketing claims and in-app messaging matching what the product actually delivers
- Complaints and vulnerable customer handling — the system correctly identifying and routing cases that need special handling under Consumer Duty
If your testing effort is concentrated on functional happy-path coverage and light on these four areas, that’s usually where an FCA review — or a customer complaint that escalates — finds the gap.
Why does “we tested it” not hold up under review?
Because “we tested it” describes an activity, not evidence. A regulator, or an internal audit, asks a narrower question: show me the test that proves this specific rule was enforced, and show me who reviewed it.
Most engineering teams can demonstrate that QA happened. Far fewer can, within minutes, pull up the specific test case that covers a specific FCA-relevant scenario, when it last ran, what the result was, and who was accountable for the sign-off. That traceability gap — not a lack of effort — is what usually surfaces first when a firm goes through a s166 review or a Consumer Duty deep-dive.
This is also where independent testing earns its place. A team testing its own pricing logic has an obvious incentive to interpret ambiguous requirements charitably. A second, independent set of eyes — internal or external — doesn’t have that incentive, and that separation is itself part of what “good governance” looks like to a regulator.
What does a defensible testing process look like in practice?
It doesn’t need to be heavyweight. It needs four things to be true:
- Requirements are traceable to tests. Every regulatory-relevant rule (a pricing tier, an eligibility threshold, a disclosure requirement) has at least one test case explicitly linked to it — not just implied by general functional coverage.
- High-risk changes get independent review. Pricing, eligibility, and financial promotions changes are verified by someone other than the author before release.
- Test evidence is retained and retrievable. Reports, pass/fail history, and sign-offs are stored somewhere you can produce them on short notice — not scattered across Slack threads and CI logs that roll off after 30 days.
- Testing runs continuously, not just pre-release. Regression suites covering the four high-scrutiny areas above run on every relevant change, not once per quarter.
Firms that build this into their delivery pipeline stop treating compliance testing as a separate, painful exercise bolted onto the end of a release. It becomes a natural output of how they already ship software.
At Pro-Test, this is the specific gap our regulated-industry testing work is built around — independent verification that produces the traceability and evidence a Consumer Duty review actually asks for, without slowing delivery down. Pro-Verify is our structured approach to exactly this: mapping test coverage directly to regulatory requirements so the evidence already exists when you need it, rather than being reconstructed under deadline.
If you’re not confident you could produce that evidence for your highest-risk features within an hour of being asked, that’s usually the first thing worth fixing. Get in touch for a candid conversation — no pitch, just a look at where the gaps are.