How to Run a Fraud Risk Assessment That Actually Finds the Holes

Most fraud risk assessments are written to be filed, not used. They satisfy an auditor, tick a governance box, and sit untouched while the actual losses walk out through a door nobody mapped. A useful assessment is a different animal: it follows the money, thinks like the person stealing it, tests the controls that are supposed to stop them, and turns what it finds into detection rules and fixes that ship. This is the method we use — for banks, fintechs, exchanges, e-commerce, gaming operators and corporates alike — laid out step by step.

Why most fraud risk assessments are shelf-ware

Walk into almost any organisation that moves money and ask to see the fraud risk assessment. You will usually be handed a spreadsheet or a slide pack with the same failure modes, in some combination:

• The generic register. The risks were copied from a template, a framework appendix or a previous employer's document. They describe fraud in the abstract — "risk of unauthorised payments" — with no reference to how this business actually takes, moves and releases money. A register that could apply to any company applies usefully to none.
• Written by people who have never seen the fraud. The exercise was run by a governance function or a graduate rotation, interviewing managers who described the process as designed. Nobody in the room had ever investigated a real loss, so nobody knew which questions expose the gaps.
• Scored by vibes. Likelihood and impact were assigned in a workshop by consensus and gut feel, producing a heat map with confident colours and no evidential basis. The numbers were invented, so the priorities built on them are invented too.
• No money-flow map. The assessment is organised by department or by risk category, not by the paths money actually travels. Fraud does not respect the org chart — it follows the money — and an assessment that is not anchored to money flows cannot find the holes in them.
• Refreshed annually into oblivion. Each year the document is rolled forward, dates updated, a row added, nothing re-tested. After three cycles it describes a business that no longer exists.

None of this is malicious. It is what happens when the assessment's real audience is an auditor rather than an attacker. The document is optimised for defensibility, not discovery — and discovery is the entire point.

What a useful assessment looks like

A fraud risk assessment worth the name has a simple test: did it find holes you did not already know about, and did those findings change what you do? Everything else is packaging.

In practice, a useful assessment shares a handful of properties. It is anchored to a map of every path money enters, moves through and leaves the business. Its threat scenarios are specific enough that you could hand one to an engineer and they would know what to build against it. Its view of controls comes from watching people work, not from reading the policy library. Its scores lean on loss data the business actually holds. And its output is a sequenced plan — not a heat map — that flows directly into detection rules, process changes and build work.

The seven steps below are how you get there. They are presented in order because each one feeds the next: you cannot catalogue threats against flows you have not mapped, and you cannot score honestly against controls you have not tested.

Step 1: Scope by money flow, not org chart

The single biggest upgrade you can make to a fraud risk assessment is to change its unit of analysis. Do not scope by department, product team or risk category. Scope by money flow: every distinct path by which value enters, moves within, and leaves the organisation.

For most businesses the inventory looks something like this: payments in (cards, bank transfers, direct debits, wallets), payments out (customer withdrawals, payouts, settlements), refunds and reversals, payroll, supplier and accounts-payable payments, treasury movements between accounts and entities, and — where relevant — crypto rails in and out. Each flow gets mapped end to end: where it originates, which systems it passes through, where it can be created, amended, approved, held or released, and crucially who and what can touch it at each point — people, roles, service accounts, APIs, third parties.

Two things happen when you do this properly. First, you find flows nobody owns — the refund path that finance thinks operations controls and operations thinks finance controls. Second, you find touch-points nobody talks about: the shared team login, the integration account with payment permissions it never needed, the supplier portal that can change bank details. These orphaned flows and forgotten touch-points are where losses concentrate, precisely because no one is watching them.

The map does not need to be beautiful. It needs to be complete. A flow you left off the map is a flow you have silently accepted every risk on.

Step 2: Build the threat catalogue against each flow

With the flows mapped, you build the threat catalogue — and the discipline here is to build it per flow, not as a global list. For each path money travels, you ask one question, seriously and repeatedly: "If I wanted to steal this, how would I do it?"

Cover three categories against every flow:

• External fraud. Stolen card payments, account takeover of your customers, authorised push payment (APP) scams that con customers into sending money, business email compromise (BEC) redirecting your outbound payments, mule accounts washing proceeds through your platform, refund and promotion abuse at scale.
• Internal fraud. Payment tampering by someone with access to create or amend transactions, supplier collusion and false invoicing through accounts payable, ghost employees in payroll, data theft that enables external fraud later, and the quiet override — the person who can both raise and approve, or who can edit records after approval.
• Hybrid fraud. The combinations that pure external or internal framing misses: an insider feeding customer data to an external crew, an employee coached or coerced by an outside party, a compromised supplier whose "legitimate" invoice carries changed bank details.

The attacker's-eye question is what separates a threat catalogue from a risk register. A register says "risk of supplier payment fraud". A catalogue says: "an attacker emails accounts payable from a lookalike domain two days before a known payment run, quoting a real invoice number, requesting a bank-detail change — who receives that email, what do they check, and what happens if they check nothing?" One of these can be tested. The other can only be filed.

This is also where most organisations flinch: the internal-fraud angle. It is uncomfortable to catalogue how your own payments manager, your own developer with production access, or your own finance lead could steal — so most assessments simply don't. That omission is exactly backwards. Internal actors know the controls, know the thresholds, and know which reports nobody reads. If your catalogue contains no scenarios that would embarrass someone in the room, it is not finished.

Step 3: Walk the actual controls, not the documented ones

Every organisation has two control environments: the one in the policy library and the one that operates at speed under pressure. A fraud risk assessment that only reads the first is assessing a fiction.

So you walk the floor. Sit with the payments team while they process a run. Watch a refund get approved. Ask the person who releases payouts to show you — not tell you — what they check. Follow a bank-detail change request from the inbox to the ledger. What you are looking for is the gap between the documented control and the operated one: the call-back that became a reply-to-the-same-email, the four-eyes check where the second pair of eyes approves from their phone without opening the record, the exception queue that gets bulk-cleared at the end of the day.

These gaps are rarely hidden and never in the documentation. People will tell you about them, often cheerfully, if you ask the right way — "what do you do when the system's slow and the queue's backing up?" is worth more than any control matrix.

Step 4: Test the controls where it matters

Walking the controls tells you how they operate. Testing tells you whether they hold. You do not need to test everything — you test where the threat catalogue says the money is, with the process owner's knowledge and proper authorisation, and you test the control as an attacker would meet it.

Concretely, that looks like: submit a supplier bank-detail change through the normal channel and see whether it really triggers an independent call-back to a known number — or whether it sails through on a polite email. Push a transaction that should breach the velocity rule and confirm the rule actually fires, alerts someone, and that the someone acts. Attempt a payment above the delegation threshold and see whether the second approval is a genuine review or a rubber stamp. Check whether a user who raises a payment can also approve it under any role combination — including the legacy roles nobody has reviewed since the last restructure. Try the dormant account, the expired delegation, the test environment that can reach production money.

Every test resolves a control from "documented" to one of two states: demonstrated or failed. Both are wins. A failed test found a hole before someone else did, at zero loss. What you may not do is leave the control marked "in place" because a document says so — an untested control is an assumption, and assumptions are what fraud is made of.

Step 5: Score honestly, with loss data you actually have

Now — and only now — you score. Likelihood times impact is a fine frame; the failure is in where the numbers come from. Workshop consensus produces a heat map that reflects the room's anxieties, not the business's exposure.

Instead, anchor every score you can to data the organisation already holds: chargeback records, fraud write-offs, disputed transactions, refund anomalies, near-misses that got caught, incident tickets, whistleblower reports, reconciliation breaks that were "probably errors". Most businesses are sitting on years of this evidence and have never once read it as a data set. It tells you which flows already leak, which controls have already been beaten, and roughly what an event costs when it lands.

Where you genuinely have no data — a new rail, a threat you have never experienced — say so, and score it as an explicit judgement with the reasoning written down. An honest "we believe this is high, because the control test failed and the flow moves material value daily" is worth ten invented decimal-pointed ratings. The test of the scoring is whether two people with the same evidence would land in roughly the same place — and whether anyone could challenge a score by pointing at the record behind it.

Impact, too, deserves honesty: count the full cost of an event — the direct loss, the investigation and recovery effort, the scheme fees or regulator attention, the customer trust — not just the number that would appear in the write-off column.

Step 6: Sequence the treatment plan by loss-per-effort

The output of the assessment is not the heat map. It is the treatment plan — and the plan's ordering principle should be loss prevented per unit of effort, not risk-score rank. A medium-scored risk with a one-day fix often deserves to jump the queue ahead of a high-scored risk that needs a six-month platform change.

Sequence it in three horizons:

• Quick wins — first 30 days. Configuration and process fixes that close tested holes now: enforce the call-back on bank-detail changes, split the raise/approve role combination, kill the shared login, turn on the alert that existed but was never routed to a human, tighten the refund threshold that testing showed was being gamed.
• Structural fixes — around 90 days. Changes that need design and coordination: segregation-of-duties rework, a proper supplier-onboarding verification step, monitoring rules built from the threat catalogue, an exception-handling process that survives the Friday-afternoon test.
• Build items — beyond 90 days. The things worth engineering: transaction-monitoring coverage for the flows that have none, automated payee verification, detection logic tuned to your actual loss patterns rather than a vendor's defaults, and the reporting that lets the board see fraud exposure move quarter to quarter.

Every treatment gets an owner, a date and a re-test. A treatment plan without a named owner per item is a wish list, and the assessment that produced it will be shelf-ware within a quarter.

Step 7: Make it live

The final step is the one that separates an assessment from an artefact: wiring it into the way the business runs.

Three mechanisms do the work. First, findings become detection: every credible scenario in the threat catalogue should map to a monitoring rule, an alert or a report — and where it cannot, that gap itself is a finding. The assessment and the transaction-monitoring rulebook should read like two views of the same document. Second, change triggers re-test: when a flow changes — new approval path, new system, new team — the controls on that flow get re-tested then, not at the next annual review. Third, refresh is event-driven: a new product, a new payment rail, a new market or an acquisition means a new assessment of the flows it touches, because fraud exposure arrives with the change, not with the calendar. The annual cycle remains as a backstop for slow drift — it is the floor, never the driver.

Run this way, the assessment stops being a document and becomes an operating loop: map, catalogue, test, fix, detect, re-test. Each pass gets cheaper because the map already exists, and sharper because the loss data keeps accumulating.

Who should run it

Method matters, but so does who holds the pen. Two requirements are non-negotiable.

Independence from the process owners. The people who designed and operate a payment process cannot objectively assess it — not because they are dishonest, but because they will assess the process as they intend it to work, and because challenging your own design is one of the hardest things to do well. Where internal fraud is in scope the requirement hardens further: the person best placed to explain a flow is also, by definition, a person who could exploit it, and an assessment reviewed only by insiders will be quietly steered away from the uncomfortable scenarios. Whether independence comes from a genuinely separate internal function or from outside the organisation matters less than it being real.

Senior practitioners, not juniors with checklists. The value of the exercise lives in the follow-up question — the "show me", the "what about when the system is down", the instinct for which polite answer is hiding a hole. That instinct comes from having investigated actual fraud, sat in the recovery meetings and seen how controls fail in the wild. A checklist in inexperienced hands produces a completed checklist; it does not produce discovery. If the team running your assessment has never seen a real loss end to end, you are paying for documentation, not assurance.

This is the work we do. Financial Crime Advisory runs fraud risk assessments as senior-practitioner engagements — money-flow mapping, threat catalogue, control walk-throughs and live testing — delivered as a fixed-price Exposure Audit, with findings that flow straight into detection, monitoring and build work rather than a binder. If you want to know where your business would bleed first, talk to a specialist.

Fraud risk assessment: phases at a glance

The table below summarises the method end to end. Elapsed times are deliberately qualitative — the honest answer depends on the number of flows and entities in scope — but the shape holds: this is an exercise measured in weeks, and any single phase that stretches into months has lost the plot.

Sequence matters more than speed. Each phase feeds the next, and skipping ahead — scoring before testing, planning before mapping — reintroduces exactly the guesswork the method exists to remove.