Rahul Bhatia SAP S/4HANA Cloud Solution Architect, HCL Tech.

getty

I have spent over 20 years delivering finance system implementations for large private and public sector organizations globally, and I have lost count of how many versions of this I have seen. The uncomfortable truth is that it is not a people problem or a process problem. It is a design problem. We built our systems to check transactions after the fact, and fraud lives in the word "after."

​Here is how most payment fraud actually works. Someone changes a vendor’s bank details. A genuine invoice gets paid days later, to the new account. The real vendor calls a month on, asking where their money is. By then it has gone through three banks.

No rule was broken at any single step. The person who changed the bank details was allowed to. The payment was approved properly. The fraud sat in the combination and in the fact that nobody was looking at the two together when they happened.​

Our controls were designed for old systems.

Think about how controls typically work in most large companies. A transaction posts in seconds, a batch job checks it overnight and an exception report lands in someone’s inbox, and a person gets around to it when they can. The auditors turn up months later.

There was a good reason for this. Twenty years ago, checking every transaction as it happened was not affordable, so we sampled, we batched and we reviewed after the event. Fair enough, at the time.

But the reason went away and the habit stayed. Systems today can check everything, instantly. Most finance departments still run controls the way they did in 2005 because nobody has asked why.

The systems have changed. The controls can, too.

Modern finance systems no longer work as one big application writing to one database. They work as a flow of events. An invoice arrives—that is an event. A bank account is changed, which is an event. A payment is released—another event. Each one is recorded the moment it happens, in order.

Most people treat this as plumbing. I think it is the most useful thing to happen to financial control in my working life, because for the first time, everything the business does financially passes through one place, in real time, before it is final. So the checking can happen there, too, not tomorrow morning, and not at quarter end. There.

In practice, that means a few things.

The check sits in the way of the payment, not next to it. A payment that fails the rules does not get flagged. It does not go. There is no route to the bank that skips the check, because the check is the route.

The record cannot be quietly changed, and each event is locked to the one before it. If anyone edits history, including a system administrator, then it shows. Your audit trail stops being a report someone runs and becomes something that protects itself.

You check what people do, not what their job title says. Standard controls compare roles: This person may raise, that person may approve. But roles do not commit fraud; actions do. If the same person changes a vendor’s bank account and then pays them, the payment stops there. That is the fraud I opened with: dead before it settles.

And you check all of it. Not a sample, not the big ones. Everything, every time. On modern systems, this adds a fraction of a second. The old excuse that it was too slow stopped being true years ago.

One fix is not enough. You need an architecture.

There is a trap here, and I have watched plenty of organizations fall into it. They buy a tool that does this, bolt it on and 18 months later, they own one more dashboard and the same gaps.

Continuous control only works if it is designed in, and you cannot design one control in isolation. It has to fit how your finance data is structured, how your systems talk to each other and where your processes are headed. Finance needs what engineering has had for decades: a reference architecture. A deliberate blueprint that says what sits where, what checks what and why it's been agreed to before anyone buys anything.

Almost no finance function has one. Most run on an accidental architecture, inherited from ERP decisions made years ago by people who have since left. That accident is where fraud, cost and failed transformations come from.

This is starting to change. Approaches like the Digital Finance Reference Architecture (DFRA) give organizations a structured way to do it, mapping how finance data, systems, controls and processes fit together as one design, and where capabilities like continuous control belong in it. Whether you use a framework or your own blueprint, the point stands: Fix the design first. The controls follow.

Ask your team these questions.

You do not need to understand the technology to push on this. Here are three things to ask your finance and IT leaders:

1. For our riskiest payments, how much time passes between the money moving and the first check? If the answer is hours or days, that is the size of your exposure.

2. If an administrator changed a posted transaction tonight, would anyone know? If not, your audit trail is a comfort blanket.

3. Do our controls look at what people are allowed to do, or what they actually did? There is a world of difference, and fraud lives in it.

Here is the point.

Fraud investigations feel like a normal cost of doing business because we have run finance this way for decades. They are not. They are the bill for checking transactions after they happen, in systems that no longer require us to.

You will still need auditors. But their job should be confirming the controls held, not working out where the money went.

The best fraud investigation is the one you never had to run.​

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?