Fintech and financial software due diligence
You are acquiring something that moves or accounts for money. The demo settles a payment, the dashboard shows a balance, and the data room says the controls are in place. None of that tells you whether the ledger can be reconstructed from first principles, whether a retry can move the same money twice, whether sanctions screening is a control or a checkbox bought from a vendor, or what a regulator or a partner bank would find if they looked this quarter. In financial software the risk sits in the gap between what the product appears to do and what its records can prove. I read the ledger design, the money paths and the controls as they are implemented in code, then tell you where the exposure is and what it costs to close.
What makes diligence different in financial software
A generalist reviewer confirms that payments work and that a compliance vendor is integrated. Both can be true while the business carries risk nobody in the room can see.
Everything here is downstream of the ledger, so that is where I begin. The question is not whether balances are correct today — it is whether they are reconstructible: whether every balance is the sum of an immutable, ordered series of entries, and whether the current state could be rebuilt from those entries after an incident. Plenty of products keep balances as mutable columns and treat history as a log nobody replays. That holds until the first time a number has to be defended.
Then the money paths. Rails fail in the middle, and they fail in ways that create duplicates: a timeout that was actually a success, a webhook delivered twice, a retry carrying a fresh key. Whether the system survives those conditions is a question about code, and no policy document will answer it. So is reconciliation — whether the target compares its own records against the processor and the bank on a schedule, what happens to a break, and whether anyone has looked at the unresolved pile recently.
Controls are where the paperwork and the implementation part company. Sanctions screening and AML monitoring bought from a vendor prove that a contract exists; what matters is where the call sits in the flow, what happens when it times out, whether matching is tuned to something defensible, and whether decisions are retained in a form an examiner would accept. The audit trail has the same property: completeness and immutability count for more than volume.
Last, the perimeter of the business. PCI scope is routinely wider than the target believes, because card data touched a service nobody mapped. Obligations multiply with each jurisdiction, and they are often met by an undocumented manual process that lives outside the system entirely. And a great deal of value can rest on one sponsor bank or one processor — a concentration that is both a commercial risk and an engineering one.
What I look for
The technical foundation is assessed on every engagement — architecture, code quality, security, intellectual property, key-person risk and running costs. What follows is specific to software that handles money.
A ledger you cannot rebuild
Balances held as mutable columns updated in place, and a history table nobody treats as the source of truth. Nobody notices until a number has to be defended — a dispute, an audit, a partial outage — and the system cannot say what the truth was at 14:07. Retrofitting double-entry into a live product is one of the most expensive fixes in this sector.
Duplicate money under retry
Idempotency built for the happy path: the key is derived from a request the client regenerates, or it protects the API call but not the transfer behind it. Payment rails fail mid-flight by design, so a system that was not built for it will eventually send the same money twice. Usually a customer reports it before any alert fires.
Reconciliation that is somebody’s spreadsheet
Whether the target’s own records agree with the processor’s and the bank’s, on what schedule, and what happens to a break. A manual monthly reconcile owned by one person is a control weakness and key-person risk at once, and the size of the unresolved break pile is the fastest honest read on how well the money layer works.
Compliance controls that are really a vendor contract
Sanctions screening and transaction monitoring exist as an integration, but the call sits outside the critical path, fails open on timeout, or is tuned so that nothing ever alerts. What an examiner asks for is the decision and the reason behind it, retained and reproducible. That part is almost always thinner than the vendor logo suggests.
An audit trail with gaps in it
Events written by the same service that wrote the record, editable by anyone with admin rights, missing the fields that would identify who acted and on whose behalf. An audit trail is worth exactly what it can prove. The useful test is to pick one transaction and ask the system to account for it end to end, including the reversals.
One sponsor bank, one processor
Where the model rests on a single banking relationship or one payment provider, switching cost is an engineering question as much as a commercial one. Provider-specific assumptions rarely stay behind an interface; they spread through the money layer, which turns “we can move” into a rebuild with a date attached.
Where AI changes the picture
A model sitting in a credit, fraud or AML decision path inherits obligations a recommendation engine never has. A declined application or a frozen account is an adverse action, and the target has to be able to say why, in terms a person can understand and an examiner can test. “The model scored it 0.82” is not an explanation, and a system that cannot reconstruct the feature values and the model version behind a decision made six months ago cannot produce one either.
Training data carries a sharper edge here than elsewhere. Transaction data comes with customer consent terms and, frequently, contractual limits imposed by the bank or processor that produced it. A model trained past those limits is a liability that travels with the asset.
Drift matters more too, because the failure is asymmetric. A fraud model that decays produces losses; an AML model that decays produces reports that were never filed, which is a compliance failure with a regulator attached rather than a bad quarter. And where the model is a third-party API, the decision path of a regulated process now runs through a vendor whose behavior can change between releases.
Why me for this
I built banking and payment API integrations for a US cross-border payments platform, moving money between institutions in multiple jurisdictions under sanctions, anti-money-laundering and audit requirements. That work is where you learn that the interesting part of a payment is never the successful case: it is the timeout that turned out to be a success, the settlement file that does not agree with your own records, and the reconciliation nobody wants to own. It is also where you learn how thin the line is between a control that works and a control that merely exists.
Behind that is twenty years as a software architect and engineering leader, including scaling backend systems to tens of millions of monthly users on distributed data stores — so whether a ledger holds up at volume is not a theoretical question for me.
Common questions
- Do you review AML and sanctions controls as part of technical due diligence?
- Yes, as they are implemented rather than as they are described. A signed vendor contract and a written policy tell you what the target intends; the code tells you where the screening call sits in the flow, what happens when it times out, how matches are triaged, and whether the decision and its reason are retained in a form an examiner would accept. I am not your regulatory counsel — what I give you is whether the control does what the policy claims, and what it costs to make the evidence hold.
- Can you assess the ledger without access to real customer transactions?
- Yes. Ledger integrity is a design question: the schema and its migrations, the code that writes entries, whether balances are derived or stored, and how reversals, adjustments and partial failures are recorded. Where a walkthrough of live records is useful, it happens in the target’s own environment with their staff at the keyboard. I do not need an export of customer transaction data to tell you whether the books can be rebuilt.
- The target uses a payments provider and a BaaS partner. Is there anything left to assess?
- Quite a lot. A provider owns the rail; the target still owns its own books, and that is where the risk concentrates — idempotency under retry, webhook handling, reconciliation against the provider and the bank, the audit trail, and how much of the money layer would have to be rebuilt to switch providers. Outsourcing the rail moves the hard problems around; it does not remove them.
Have a deal in motion?
Tell me the target, what you need to know, and your timeline. I will tell you whether and how I can help, usually the same day.
Engagements are confidential and run under a mutual NDA.