VIRTICUSDiscuss your situation
← Back to experience

Financial crime

Fraud rule review and calibration in a bank

Detection thresholds that drifted over time, and a rationale that had to be recoverable the moment a decision was questioned.

Illustrative · anonymised and reconstructed from real work

The scenario

Where the decision had to hold under scrutiny

Fraud rules were screening for suspicious behaviour across large volumes of transactions, but the basis for individual thresholds had drifted over time. The challenge was not only detection performance, but whether each decision could be understood, reviewed, and defended when a false positive harmed a genuine customer or a missed risk led to loss. Illustrative review work strengthens traceability around rule outputs and identifies where a control’s rationale must be documented. This reduces the chance of a decision nobody can explain in a high-scrutiny environment.

What the scenario turns up

The issues

Finding 01

Thresholds set years earlier can stop matching current fraud patterns, and often there is no record of why they were chosen — so the rule set could neither be trusted nor defended.

Finding 02

Cases that had not actually been assessed were being treated as low risk, blurring the line between a genuine all-clear and a gap in coverage.

What the work does about each one

The response

Response 01

Reviews each rule against current fraud typologies, recalibrates the thresholds, and re-documents the rationale, establishing a traceable basis for every decision the rules produce.

DiscoveryDesign

Response 02

Introduces a review discipline that separates assessed-safe from not-yet-assessed, so an unknown is never quietly recorded as low risk and coverage gaps are made visible.

Build

How the work is done

The same five steps, applied to this decision

Every piece of work runs the same path. For this one, the weight falls on Discovery, Design, Build — the steps where a decision of this kind is most often challenged.

01Core

Discovery

Map where the decision is made, who could challenge it, and the regime that binds it — before any logic is written.

02Core

Design

Set the logic out in the open so it can be read and questioned: the same inputs always give the same decision, and nothing is a black box.

03Core

Build

Build it with the checks in: coverage and oversight are confirmed before anything ships, and nothing unassessed is waved through as safe.

04

Deploy & test

Run it against real cases behind a human checkpoint, and keep a dated record of exactly what was decided and on what basis — one that cannot be edited afterwards.

05

Assure & hand over

Hand over the decision log and a plain-language write-up, so your team owns the record the moment someone says prove it.

Built for this problem

These automations can be shown to you running

What this kind of work once did by hand is now an automation that runs. It is shown by invitation rather than published, because every example in it is constructed and a synthetic case read out of context reads as a real one. Ask, and you will be walked through it deciding — including the cases where it refuses to conclude.

SYSC 6.3 · SS1/23

Fraud Rule Change Defensibility

The calibration record this kind of review has to rebuild from memory, produced as a by-product of the change instead of an archaeology exercise afterwards.

POCA 2002 Part 7

SAR Assessment and Escalation

The same refusal carried into the disclosure: what was not assessed is never reported as nothing found, and the gap is named instead of closed by silence.

Discuss your situation

A decision like this can be made correctly, and shown to be correct, on the record

A short discussion is usually enough to locate where the risk sits — in the logic, the controls, the evidence, or a combination — and where it is made to hold.