Software testing in financial services
In most software, a screen that looks right is evidence. In financial services it is not evidence of anything. A number that is wrong by four pence looks identical to a number that is correct, and the only test that means something is a reconciliation against a figure computed somewhere else.
That is the discipline this page is about. We are an independent testing company, based in Cluj-Napoca, in the EU, ISO/IEC 27001:2022 certified, and working on GMT+2. We did not build your platform and we have no delivery contract to protect by rounding a finding down.
Transaction integrity, which is mostly about crashes
The happy path of a payment gets tested by everybody. The paths that cost money are the ones that involve something stopping halfway.
A retried request that posts twice. A debit that succeeds and a credit that does not. A compensating transaction that was written, reviewed, merged and never once executed in anger. An idempotency key that is honoured by the API and ignored by the batch job behind it.
Testing this means causing the failure rather than waiting for it. Kill the process between the two writes. Return a timeout on a call that actually succeeded. Replay the same message four times. Most systems handle exactly one of those correctly and nobody has ever checked which.
The invariants nobody asserts
Double entry has one invariant: debits equal credits, at every point, including halfway through a batch. It is trivially checkable and almost never checked continuously, because it is assumed rather than tested.
We assert invariants like that as a matter of course, because they catch whole classes of defect at once instead of one input at a time. Balances reconcile to the movement history. The sum of the parts of a split payment equals the whole. No account ends a run in a state it cannot leave.
Rounding is the other one. Half-even against half-up, minor units that are not always two digits, and the timestamp at which an exchange rate was applied. A test suite whose fixtures are all round numbers cannot see a rounding defect, and most suites are written with round numbers because they are easier to read. We choose fixture values that can discriminate, which is a small thing that changes what the suite is capable of finding.
The regulated surfaces
DORA. It has applied to EU financial entities since January 2025 and requires a digital operational resilience testing programme rather than an annual exercise, extending to ICT third parties. We set out what that means in practice at DORA compliance and key DORA requirements.
PSD2 strong customer authentication. Most SCA defects are not in the challenge. They are in the exemption logic: low value, trusted beneficiary, transaction risk analysis, and the cumulative counters that are supposed to force a challenge once a customer has run past the exemption thresholds. Those counters are state, state is where bugs live, and they are rarely tested to the boundary.
PCI DSS. The testing consequence of scope is simple and usually unresolved: your test environment is either in scope or provably out of it, and most organisations cannot demonstrate either. We will tell you which one you are in.
ISO 20022. Migration from MT to MX is not a format conversion. It is a widening of the data model, and the defects are in truncation, in structured versus unstructured party data, and in what happens when a counterparty is still on the old format.
Audit trails. An audit log that the application can rewrite is not an audit log. Completeness, immutability and the ability for someone who was not present to reconstruct what happened are all testable properties, and they are the ones a regulator will ask about.
Security, because in this sector it is not a separate project
Application security testing, dependency and supply chain review, and the penetration testing that sits over both. See security testing, SAST scanning and software composition analysis.
Performance belongs in the same paragraph, because in trading and payments the number that matters is the tail rather than the average. A p50 of nine milliseconds and a p99 of four seconds is a broken system with a good dashboard. See performance testing.
When we are the wrong choice
We would rather say this on the page than on the third call.
We are not a regulated auditor. If what you need is a signature from a registered firm on a regulatory return or an attestation, that is not us, and no amount of testing quality changes it.
Threat-led penetration testing under TIBER-EU requires accredited providers in most jurisdictions. Our security testing is real and independent. It is not a TIBER accreditation and we will not imply otherwise.
We do not validate models. Credit risk models, IRB approaches, capital calculations and pricing models are validated by quantitative teams and their own regulators. We test that the software implements the model as specified.
If your test environment cannot hold data that is representative of production, and nobody will fund changing that, then testing financial correctness is guesswork with a report attached. We would rather scope the data work first.
And outsourcing does not work where the contract requires staff on site or nationals only, which is common in central banking and parts of defence-adjacent finance.
How we start, and what it costs
Two weeks, no contract. We embed, learn the product, write tests and file real bugs against your actual software. If you are not happy with what we deliver in those two weeks, you do not pay for them. You decide whether to carry on and we invoice from week three. We do this because nobody can assess testing quality from a proposal, and a reference call tells you about somebody else's system.
After that, $25 to $45 an hour depending on seniority, commitment length and the mix of work. Every engineer on your product has shipped commercial releases before.
Our ISO/IEC 27001:2022 management system governs how we handle your data, credentials and environments, and we send the scope statement rather than just the certificate. Full list at certifications.
Talk to us
Tell us what you process, what your release cadence is, and what the last incident was. If the honest answer is that you need something we are not, we will say so.