Financial and banking systems
Ledgers that balance, transactions that are never lost or applied twice, and a record of who did what that holds up when somebody asks months later.
Talk about scopeCorrectness here is not a quality bar, it is the product
Most software can tolerate an occasional wrong number and fix it later. Financial software cannot, and that changes how it is built rather than how carefully it is tested. Money moves as double entry so a mistake is visible as an imbalance rather than a plausible figure. Operations are idempotent, because the network will retry and a duplicated transfer is worse than a failed one. Nothing is ever updated in place — corrections are new entries that reference what they correct. None of that is expensive if it is the shape from the first commit, and close to unaffordable if it is retrofitted.
The failure everyone has to design for
A request times out and nobody knows whether it happened. That single case is the source of most real financial bugs, and it is handled by making the operation carry its own identity so a retry is recognised rather than executed again, and by settling the ambiguity through reconciliation rather than by guessing. A system that treats a timeout as a failure will eventually pay someone twice.
The request never reached the ledger. The money is still where it was, and a retry is exactly right.
Retry is correct
The ledger posted and the acknowledgement was lost on the way back. A retry sends it a second time.
Retry pays twice
The decision that removes the ambiguity
The transfer carries its own identifier, generated before it is sent. The second attempt presents the same one, the ledger recognises it, and the operation is applied once no matter how many times it arrives.
Where we are useful, and where we are not
Being specific about this is more useful to you than a longer feature list.
- Systems that sit around a bank rather than replacing its core.
- Loan, savings and member ledgers for smaller institutions.
- Payment reconciliation, settlement files and the reporting on top.
- Onboarding and approval workflows, with the audit trail they need.
- Not a licensed core for a commercial bank — that is a different undertaking, and a different kind of supplier.
- Not a payments licence or a card scheme membership; we integrate with providers who hold those.
When not to build this
A packaged product is the right answer more often than a development company usually admits, and if your problem is an ordinary one that something off the shelf already solves, we will tell you so rather than quote for it. What follows is the case for the other answer — the conditions under which building is worth what it costs.
The workaround has become the process
A packaged system that mostly fits leaves a residue — the spreadsheet kept alongside it, the step done by hand every month, the field used to mean something it was not named for. When that residue is where the actual work happens, you are already maintaining custom software, just without any of the benefits of having built it.
The thing you do differently is the thing it cannot do
Every business has a few processes that are genuinely its own, and those are usually the ones it competes on. Off-the-shelf software is built for the average of a sector, so it handles the ordinary parts well and the distinctive part not at all. Building is worth it exactly where that overlap fails, and rarely anywhere else.
A vulnerability shared by every deployment
A vulnerability in a packaged product is a vulnerability in every deployment of it, and attackers only have to find it once. A system built for one business is not on that list.