Data Analytics in Fraud Investigations

A vendor fraud rarely involves one vendor and one employee. It typically involves a web: an employee with approval authority, a vendor registered at an address the employee controls, a second vendor with a different name but the same phone number, and a third entity that receives transfers from the second. Each relationship, looked at alone, might seem coincidental. Mapped together, they show a deliberate network.

The practical inputs for network analysis in a forensic accounting case are the vendor master file (names, addresses, registration numbers, phone numbers, bank accounts), the employee master file (same fields), corporate registry data (director names, registered addresses), and the transaction file (payment flows). Tools such as IBM i2 Analyst's Notebook, Maltego, and open-source libraries such as NetworkX in Python convert these into node-edge graphs that can be explored visually.

In the 1MDB investigation, network analysis was central to tracing the web of shell companies across Singapore, Cayman Islands, and the British Virgin Islands that routed funds from the Malaysian state investment fund. The network had too many layers and entities to trace manually, but graph analytics reduced it to a comprehensible structure showing the flow of $4.5 billion across linked entities.

Frauds require a specific order of operations. A ghost vendor must be set up before it receives payments. A journal entry used to conceal a loss must be posted before the accounts are closed. A purchase order must be ante-dated to appear to precede the invoice it was created to cover. These temporal inconsistencies leave signatures in the data: creation timestamps that post-date transaction dates, approval records that follow rather than precede the events they supposedly authorised.

Timeline reconstruction pulls timestamps from multiple sources: ERP transaction logs, email metadata, system access logs, document metadata (the 'last modified' date stored in a Word or Excel file's internal properties), and bank clearing records. These are normalised to a common timezone and plotted chronologically. Gaps between what the paper trail says and what the log records show are often where the fraud lives.

• End-of-period spikes: a disproportionate number of large journal entries posted in the last hours of a reporting period is a classic financial-statement manipulation signature, as seen in the WorldCom investigation.
• Approval-transaction reversals: if an ERP log shows that a vendor was approved for payment one day and the vendor record was created in the system the next day, the approval documentation was fabricated retroactively.
• Document metadata inconsistencies: a contract supposedly signed in 2019 whose file metadata shows a creation date of 2021 is a reconstructed document, which is itself evidence of obstruction.

A single anomaly test produces a binary output: flagged or not. Many legitimate transactions share features with fraudulent ones and get flagged, producing a high false-positive rate. Anomaly scoring addresses this by combining multiple features into a single numeric score per record, so that a transaction that triggers five separate anomaly indicators gets a much higher score than one that triggers only one.

In practice, the scoring model is built around the specific scheme hypothesis. A procurement-fraud score might combine: vendor age at first payment (newer is riskier), number of approvers who processed that vendor (one is riskier), payment amount relative to contract value (over-contract is riskier), payment timing relative to invoice date (same-day processing skips review), and whether the vendor address appears in any other register. Each factor is scored and combined, producing a ranked list from most to least anomalous.

The Isolation Forest algorithm, introduced by Liu, Ting, and Zhou in 2008, works by randomly selecting a feature and randomly selecting a split value within the feature's range, then partitioning the dataset. It repeats this across many trees. Records that end up isolated in very few splits are anomalous, because they are different from the rest of the data in ways that are easy to separate out. No labelled examples of fraud are needed. The model learns what normal looks like from the data itself and flags whatever departs from it.

Logistic regression takes the opposite approach. It requires a labelled training set: historical transactions that are known to be fraudulent and known to be legitimate. It learns which features predict fraud and assigns coefficients to each, producing a probability score for new records. Because the coefficients are interpretable (a unit increase in vendor age reduces fraud probability by X), the model can be explained in a courtroom. This is its main advantage for forensic use over black-box approaches such as gradient boosting or neural networks.

Courts in the US and UK have addressed algorithmic evidence under the same framework that governs any scientific or expert testimony. In the US, Daubert requires that the method be testable, have a known error rate, be subject to peer review, and be generally accepted in the relevant scientific community. Benford analysis and Isolation Forest have published peer-reviewed methodologies and documented case applications, placing them on solid ground. A proprietary scoring tool whose algorithm is a trade secret is much harder to defend.

The practical implication for forensic accountants is that the algorithm is not the evidence. It is the pointer to the evidence. The actual evidence is the documents, transactions, interview statements, and financial records that the algorithm directed the investigator toward. Presenting a model score as proof of fraud is procedurally incorrect and likely to be excluded. Presenting the underlying transactions, which the model helped identify, as evidence of a specific scheme is the correct approach.

No single analytics technique is comprehensive. A network analysis that identifies a suspicious cluster of connected vendors should be followed by CAAT duplicate and gap tests on their transaction histories. A timeline reconstruction showing end-of-period journal entry spikes should be followed by stratification and Benford analysis of those specific entries. An anomaly score that flags a transaction should be followed by document review, interview, and financial tracing to determine whether the anomaly reflects fraud, error, or a legitimate unusual business event.

The integration workflow in a complex investigation typically runs in three layers. The first is broad screening: Benford, CAAT, and initial anomaly scoring applied to the full dataset. The second is targeted network and timeline analysis on the flagged subset, building a hypothesis about the scheme structure and the actors involved. The third is substantive testing: document review, interview, financial-flow reconstruction, and beneficial-ownership investigation to test the hypothesis and produce the evidence that goes to court.