Asher's Blog

Some of the most expensive fraud cases inside companies begin with a process everybody has accepted for years. One person can initiate and approve a transaction, reconciliations are delayed, exceptions are handled informally, or a senior employee is trusted so completely that nobody checks the work. The company eventually introduces software and believes that the process has become safer because it has become digital.

What the technology may have done, however, is make the same weakness faster and more difficult to see.

Fraud has taught me to look at processes differently. When a bad actor succeeds, the immediate temptation is to focus only on the person, but the more valuable question is how the system made the behaviour possible. Which control was absent? Which responsibility was concentrated in one person? Which warning existed but reached nobody? Which exception became normal because the team wanted to move quickly?

The answer is rarely to add technology immediately. First, write down what is actually happening from beginning to end. Follow the traditional process, including the inconvenient manual steps that experienced employees no longer mention because they perform them instinctively. Identify who supplies each piece of information, who changes it, who approves it, where money or data moves and how the company knows that the expected outcome occurred.

This is first-principles work. You break the process into its smallest important parts and then ask why each part exists. Some steps protect the customer or the company and must be strengthened. Some exist only because an old system required them and can be removed. Others conceal a gap that employees have been bridging through memory, private spreadsheets or WhatsApp messages.

Only after understanding the process should technology tighten and automate it. Automation can enforce separation of duties, make approvals traceable, reconcile records continuously and escalate unusual activity. It can reduce human error and reveal patterns no individual would notice. But it cannot decide that a fundamentally confused process is sound simply because it now has a dashboard.

Consider a payment process in which one employee uploads beneficiary details and another person approves a total amount without seeing changes to individual accounts. Digitising that process may allow the first employee to prepare a larger batch in less time, while the approval remains superficial. The correct redesign would ensure that important changes are visible, permissions are limited, unusual beneficiaries are flagged and the completed payment is reconciled against an independent record. The software should embody the control, not decorate the weakness.

There is also a cultural dimension. Companies sometimes treat controls as evidence that management does not trust employees. That is the wrong interpretation. A well-designed process protects honest employees from suspicion because decisions are documented and responsibilities are clear. It also reduces the temptation and opportunity available to a dishonest person. Trust is important, but trust without verification places both the company and its people at risk.

AI makes this lesson more urgent. Intelligent systems can examine more transactions, generate code and automate decisions at extraordinary speed. If the objective, authority and escalation rules are sound, that speed is valuable. If they are not, AI can reproduce a bad decision across thousands of cases before a human notices. The more powerful the technology becomes, the more carefully we must define the process it is accelerating.

Before automating any critical workflow, I would ask four questions. What outcome is this process supposed to produce? How will we know that the outcome is correct? Where can error or malicious behaviour enter? Who has the authority to stop or reverse the process when something unusual happens? If the team cannot answer those questions clearly, it is not ready to automate.

Technology is strongest when it captures a process the company genuinely understands and then makes that process more consistent, visible and secure. It should not be used to avoid difficult operational thinking. A broken manual process is slow enough for people to notice its failures. A broken automated process can fail at scale.

The work, therefore, begins before the code. Follow the process, question every assumption, rebuild the controls and then automate what remains. Technology will accelerate whatever you give it. Our responsibility is to ensure that what it accelerates is worth scaling.