Financial software testing services for fintech and banking
We test the parts of a financial product that cost money when they break: payment retries, rounding, open banking consents, card data in logs and the release that went out on Friday. An independent QA team in the EU, ISO 27001:2022 certified, working inside your sprints.
Written by Alexandru Zamfira, QA engineer on payments and lending platforms. Reviewed by Tudor Brad, founder.
What we check on every release
- Money pathsPayments, refunds, retries, timeouts
- Customer journeysOnboarding, consents, strong authentication
- RegressionCore flows, before every release
- Security and dataPermissions at the API, card data in logs
What we test
Most teams start with their money paths and add the rest as the regression suite grows.
Payments
Retries that post twice, refunds, partial captures, split amounts that lose a penny, and what happens when a provider times out after the money moved.
Open banking and SCA
Consent journeys, expired tokens, re-authentication and the exemption logic behind strong customer authentication, not only the challenge screen.
Lending and onboarding
Application and decision rules, identity checks and document upload, and the edge cases where a new applicant is matched to the wrong existing customer.
APIs and integrations
REST and GraphQL, webhooks, partner and core banking integrations, and permissions tested at the API rather than the screen. See API testing.
Security
Our AI Security Toolkit runs 20 checks we wrote plus 15 open-source scanners, and an engineer reviews every finding before it reaches you.
Accessibility
WCAG 2.2 AA with screen readers and keyboard, on the journeys customers with support needs rely on. See accessibility testing.
Four places payment systems break
Illustrative examples built from defect patterns we test for. Not client data.
A retried payout posts twice
Failure: the ledger commits, the response times out, and a nightly batch replays the payout without its idempotency key.
How we catch it: we make the write succeed and the response fail, retry, run the batch, then assert one debit and a balanced ledger.
A split payment loses a penny
Failure: 100.00 split three ways and rounded per part gives 99.99, and the ledger cannot explain the difference.
How we catch it: property-based tests over thousands of awkward amounts check that the parts always add up to the total.
The exemption counter resets
Failure: the low-value exemption counter lives in app memory, so a restart sets it to zero and the challenge never comes.
How we catch it: we walk the thresholds, then restart the app, refund and switch devices; the payment over the limit must still be challenged.
Message translation drops the address
Failure: a long structured address in a pacs.008 is cut to fit four MT103 lines, and sanctions screening matches on half of it.
How we catch it: round-trip tests on the longest real field values; anything lost must be flagged, never dropped silently.
The rules, in testing terms
Where each requirement tends to break in the software, and the tests we run for it.
| Requirement | Where it breaks | What we test |
|---|---|---|
| Consumer DutyFCA | Journeys a customer cannot understand or finish, and support routes that dead-end | Journey and content tests on sign-up, switching, cancelling and complaints, including customers with support needs |
| Operational resilienceFCA and PRA | An important business service that fails on a dependency nobody tested | Failover, timeout and third-party outage tests on the services you mapped, with evidence for your scenario testing |
| Open banking and SCAPayment Services Regulations 2017 and the FCA SCA-RTS | Exemption counters, consent expiry and re-authentication | Boundary tests on exemptions, state across restarts and devices, consent renewal |
| PCI DSSv4.0.1 | Card numbers in logs, exports and test data | Card-number pattern scans on logs and exports, and checks that test environments hold no live card data |
| UK GDPRand the Data Protection Act 2018 | Real customer data in test environments, and data a role should not see | Synthetic or masked test data, permission tests at the API, export and deletion requests |
| AccessibilityEquality Act 2010, with WCAG 2.2 AA as the usual benchmark | A customer using assistive technology cannot finish a core journey | WCAG 2.2 AA audits with assistive technology, then a re-test of every fix |
We test your software against these requirements. For EU entities we also cover DORA resilience testing. For teams that take card payments, see how we test against the PCI DSS requirements.
How we work
A 30-minute call
What you process, how often you release, and what the last incident was.
NDA and DPA
Signed before anyone sees your code, environments or data.
Week one
We learn the product, map the money paths and agree what to test first.
Week two
Tests run in your pipeline and the first bugs land in your tracker.
Every release
Regression on core journeys and a release report from BugBoard that your auditor can read.
Working with a UK team
Our engineers work from Cluj-Napoca, Romania, inside the EU.
All year round
Romania is two hours ahead of the UK in winter and in summer, and our team covers the full UK working day, 09:00 to 17:00 London time.
In your stand-ups
English-speaking engineers in your Slack or Teams, your Jira and your sprint ceremonies.
Your data comes to the EU
We work under GDPR and our ISO 27001:2022 management system. UK GDPR treats the EU as adequate, so no extra transfer safeguards are needed.
One published range
Invoiced in euros, from the same €20-45 range we publish for everyone.
Pricing and the trial
The rate depends on seniority, how long you commit for, and the mix of manual, automation and security work. BugBoard and the AI Security Toolkit are included at no licence cost.
- First month is a trial
- First two weeks complimentary if you are not happy
- 30 days notice after that
- NDA and DPA from day one
Financial software testing: common questions
What do financial software testing services cover?
Testing of payments, lending, banking and trading software: functional and regression testing, API and integration tests, security testing and accessibility. With us it runs inside your release cycle, not as a one-off audit.
Are you FCA-regulated or PCI certified?
No. We are a software testing company, not a regulated firm, an auditor or a PCI QSA. We test your software against the requirements and give you the evidence; your compliance team and assessors make the call.
Can you help with Consumer Duty and operational resilience?
With the testing part. We test the journeys Consumer Duty cares about and run failover and outage tests on your important business services. The assessments and impact tolerances stay yours.
How do you handle our customer data?
NDA and DPA from day one, under our ISO 27001:2022 management system. We prefer synthetic or masked test data, and the team works from Romania, inside the EU, under GDPR.
Do your hours suit a UK team?
Yes. Romania is two hours ahead of the UK all year, and our team covers the full UK working day, 09:00 to 17:00 London time. Our engineers join your stand-ups in English.
How much does fintech testing cost?
€20 to €45 per hour, depending on seniority, commitment length and the mix of work, invoiced in euros. BugBoard and the AI Security Toolkit are included.
Do you work with US fintech companies?
Yes, we work for clients in the US and across Europe. Our afternoon overlaps with the start of the US East Coast day, and the same PCI DSS and WCAG testing applies.
How do we start, and what if it does not work out?
After a 30-minute call. The first month is a trial, and if you are not happy with the first two weeks they are complimentary. After that either side can end it with 30 days notice.
Talk to us about your financial product
Tell us what you process, how often you release and what the last incident was.