Industries
Software quality in Finance
Financial software fails quietly. A crash is obvious and gets fixed; a rounding rule applied in the wrong order produces numbers that look plausible for months. The testing that matters here is about correctness under conditions the happy path never reaches.
What shapes Finance software
What tends to go wrong
A rounding or currency-conversion error does not crash anything — it quietly produces wrong numbers until somebody reconciles and finds them.
Transactional flows have to be correct under retry, timeout and partial failure, which is exactly the state a happy-path test never reaches.
Idempotency matters: a duplicate submission that debits twice is a customer incident, not a bug report.
Authorisation is per-account and per-role, so the interesting failure is one user reaching another user’s data, not the page failing to load.
What binds you
DORA
Applying since 17 January 2025 to financial entities across the EU. It asks for ICT risk management, incident classification and reporting, and — the part that lands on engineering — a digital operational resilience testing programme, with threat-led penetration testing for entities identified as significant.
PSD2 — strong customer authentication
Two independent factors on payment initiation and account access, with defined exemptions. The engineering consequence is that authentication is a tested flow with real branches — challenge, exemption, fallback, timeout — rather than a single path with a happy case.
GDPR
Transaction records are personal data and generally cannot be minimised away, since retention is itself a regulatory obligation. That tension — keep it because finance law says so, protect it because data-protection law says so — is what makes test-data handling harder here than almost anywhere else.
Engineering practice, not legal advice.
How we work on it
What that means in practice
We test the money paths as contracts rather than as screens: API-level checks on transaction correctness, boundary and precision cases around amounts and currencies, and deliberate fault injection so retries, timeouts and duplicate submissions are exercised rather than assumed. Access control is tested horizontally — one account attempting another account’s operations — because that is where the costly findings are.
Related reading
- Application security
OWASP assessment vs penetration test: which one your requirement names
Suppliers use the two terms interchangeably. Contracts, insurers and regulators do not. How to read the clause you have been given before you buy the wrong thing.
- Application security
Broken object level authorisation: the API risk no scanner will find for you
The top entry on the OWASP API Security Top 10 returns a perfectly normal 200 to the wrong person. Why tooling cannot see it, and how the testing actually runs.
- Application security
Triaging dependency vulnerabilities: what to do with 400 open alerts
A scanner dashboard nobody opens is worse than no scanner. How to sort advisories by whether they can actually be triggered, and how to record the ones you defer.
FAQ
Finance questions we hear often
How do you test something as sensitive as a payment flow?
At the API level first, as a contract rather than as a screen. Amounts, currencies and precision get boundary and negative cases; retries, timeouts and duplicate submissions are injected deliberately rather than waited for. A payment path tested only through the interface is a payment path tested only in the state the interface happens to produce.
What is idempotency testing and why does it get its own attention?
It is checking that the same request submitted twice has the effect of one. Networks retry, users double-click, and mobile clients resend on reconnect — so a debit that applies twice is not an exotic edge case, it is a Tuesday. The test is straightforward and the consequence of not writing it is a customer incident.
Is an OWASP assessment enough for our auditors?
It depends what they asked for. An assessment gives you reproduced findings, severity reasoning and a remediation retest, which satisfies a great many security questionnaires. If the requirement names threat-led penetration testing under DORA or a specific accredited scheme, that is a different engagement with a different provider, and we would rather tell you that early than at the report stage.
Can you work without access to production data?
Yes. Money paths are structural — the interesting cases are about precision, ordering, state transitions and authorisation, none of which need a real customer’s balance. Where a realistic dataset is required we work from synthesised or properly anonymised data, and the distinction between anonymised and pseudonymised is one we take seriously rather than use interchangeably.
Contact
Building for finance?
Tell us what you are shipping and where it worries you. You will get a considered reply from an engineer, not an autoresponder.