I remember our first two fraud cases as though they happened yesterday. The first became visible on a Sunday while I was in church. I noticed that one of our withdrawal accounts was lower than it should have been, and although I did not yet have a complete explanation, I could not dismiss the feeling that something was wrong. I kept looking at the balance, checking it again and trying to understand what could have changed.
Something was wrong.
We had recently begun a promotion and were attracting attention, including the attention of people who were not interested in using the product honestly. That experience taught me that once a financial product becomes visible, bad actors will not wait for the company to feel ready. They will test the system, learn from every response and keep trying to find a weakness.
Fraud is painful because it creates financial loss, customer risk and emotional pressure. However, it also reveals what your system really is. Policies, diagrams and intended workflows describe the system you believe you built. An adversarial attempt shows how the system behaves when someone actively searches for the distance between your assumptions and reality.
Honest customers follow the path you designed
Most product testing is based on cooperative behaviour. The user enters the expected information, follows the intended sequence and wants the transaction to succeed in the ordinary way. A fraudster approaches the product differently. They ask what happens when information is manipulated, actions are repeated, steps occur in an unusual order or two individually valid functions are combined in a way the designers did not anticipate.
This is why fraud can expose gaps that ordinary testing misses. The individual feature may work correctly, but the interaction between features creates an unintended outcome. A payment can be legitimate in isolation, an account can pass a basic check and a withdrawal can follow the documented process, while the combined sequence still creates risk.
Bad actors do not respect the boundaries between product, engineering, operations and customer support. They attack the complete system. The company must therefore defend the complete system as well.
The first lesson is alertness
My Sunday experience reinforced the importance of noticing when something does not look right. In a young company, founders and early employees often develop an intuitive sense of ordinary behaviour because they remain close to transactions and customers. A balance that appears unusual, a pattern that suddenly changes or an account behaving differently can trigger investigation before a formal alert exists.
That intuition is useful, but it cannot remain the control system. As the company grows, what the founder once noticed personally must become visible through monitoring, thresholds and alerts. The organisation should not depend on one person happening to inspect the right account at the right moment.
The important question after an incident is therefore not only how the fraud occurred. It is also how the company discovered it. Did a system detect the anomaly, did an employee notice it or did a customer report the consequence? How long had the activity continued before discovery? Which signal existed but was not being watched?
Detection time matters because some incidents become expensive not through one action but through repetition. A weakness that appears small can be tested again and again until the attacker finds its limit. Fast detection reduces the period during which that learning can be exploited.
Money systems must assume abnormal behaviour
Financial software has little room for casual assumptions. A thoughtful engineering note by Adebayo Opesanya, “Some things you should know if you’re building an API/Backend for Financial Services”, captures several principles that appear simple until an incident demonstrates why they matter.
Money should be represented precisely rather than through number types that can introduce rounding problems. Inputs must be validated because a system should not assume that every amount will be sensible or positive. Related debits and credits should succeed or fail together, rather than leaving one side of a transaction completed and the other incomplete. Every transaction needs a unique reference and enough associated information to support reconciliation, investigation and customer service.
The article also emphasises realistic testing, audit trails, careful logging and caution with retries. These are not merely engineering preferences. They are the mechanisms through which the company knows what happened, reconstructs a disputed transaction and prevents an apparently harmless automatic retry from creating a duplicate financial effect.
The general principle is that a financial system must be designed for abnormal conditions, not only for the successful demonstration. Third-party providers will time out, return inconsistent responses or behave in ways the integration did not expect. Users will submit unusual inputs. Networks will fail at the worst moment. An attacker will deliberately search for the sequence that ordinary users never attempt.
Fraud attacks assumptions before it attacks code
Not every fraud case begins with a sophisticated technical vulnerability. Some begin with an assumption about people, process or authority.
The company assumes that possession of certain information proves identity, that an employee will notice a suspicious request, that a partner has performed a check or that an action below a particular amount is too small to deserve scrutiny. A bad actor succeeds by discovering which assumption nobody verifies.
This is why fraud prevention cannot belong only to engineers. Product teams decide which actions are possible, operations teams create exceptions, customer-support teams respond to requests, finance teams reconcile accounts and leaders determine which risks the business will tolerate. A secure codebase inside a weak operating process is not a secure system.
After an incident, map the complete journey. How was the account created? What information was trusted? Which limits applied? What action moved value? Who could see it? What prevented an employee from intervening, and what made the behaviour appear normal for long enough to succeed?
The objective is to understand the chain. Fraud often depends on several individually modest weaknesses aligning at the same time.
Reconciliation tells you whether your story is true
Every financial product tells a story through its records. Money entered, a transaction was instructed, value moved, fees were charged and balances changed. Reconciliation tests whether all the independent records agree with that story.
Without frequent reconciliation, a company may rely on what its application says happened while a bank, payment partner or ledger tells a different story. The difference can arise from fraud, integration failure, duplication, timing or an accounting error, but it must be understood.
Reconciliation should be treated as an operating control, not an end-of-month accounting ritual. Important accounts and high-risk transaction flows may require continuous or daily review. Unexplained differences should have owners, escalation timelines and thresholds that reflect their potential consequence.
My first discovery began with a balance that did not look right. A mature system should make that difference visible automatically and provide the references required to trace it quickly.
Every incident should leave the system stronger
It is possible to survive fraud without learning enough from it. The company recovers what it can, blocks the affected account, warns employees and returns to ordinary work. The immediate danger disappears, but the underlying weakness remains available in another form.
A proper incident review should ask what happened, how it was detected, why existing controls did not prevent it, how far the effect travelled and what must change. The review should include technology, process, people and third parties. It should produce owners and deadlines rather than general promises to be more careful.
The company must also examine whether the fix introduces new friction for honest customers. The easiest response to fraud is often to make every transaction slower and every customer prove themselves repeatedly. Some additional friction may be necessary, but indiscriminate controls allow attackers to damage the product even after the incident has ended.
Good fraud controls are risk-based. They concentrate scrutiny where behaviour, value or context indicates greater danger, while allowing established and ordinary activity to proceed with appropriate speed. This balance requires continued learning because attackers change their methods in response to the controls they encounter.
Do not publish the map of your own weakness
Founders should share lessons from fraud because the ecosystem becomes safer when companies learn from one another. At the same time, transparency requires judgment. A public account should not disclose the precise weakness, thresholds, recovery procedures or present-day controls in a way that helps another attacker reproduce the incident.
Share the principles, organisational changes and defensive lessons. Share enough for another founder to ask better questions of their system. Keep the operational details that would expose customers or infrastructure within the people who need to know them.
Internally, the opposite principle applies. Relevant teams need honest access to the facts. Concealing an incident to protect reputations prevents the organisation from seeing the complete system and allows the same assumptions to survive elsewhere.
Fraud prevention is a permanent capability
There is no final moment when a financial company can declare that fraud has been solved. The product changes, new partners are integrated, customer behaviour evolves and new tools become available to both defenders and attackers. Growth itself changes the attractiveness and attack surface of the business.
The company therefore needs a continuing capability: monitoring, reconciliation, incident response, access controls, realistic testing, employee awareness and leadership attention. It needs people who can think adversarially without becoming so suspicious that the product becomes unusable.
Our early incidents were unpleasant, but they changed the way I understood the business. They taught me that trust is not protected by good intentions and that a system is not defined only by how it serves an honest customer. It is also defined by how it behaves when someone tries to make it do what it was never designed to do.
Fraud shows you the boundaries you thought existed but never enforced, the records you assumed would be sufficient and the alerts you wished you had built earlier. The loss is real, but the lesson must become equally real.
Bad actors will continue to try. The responsibility of the company is to ensure that every attempt makes the system more observant, more precise and more difficult to exploit the next time.
Leave a comment