Forensic data analytics applies repeatable tests to every bank transaction in scope, instead of reading statements by eye, to find the few items that deserve a document review. It needs a clean table with a source reference on each row, tests chosen for the question at hand, and a record of how each result was produced.
What does forensic data analytics do with bank transactions?
Forensic data analytics turns statements into a table and asks questions of all of it at once: which payees grew fastest, which amounts sit just under a limit, which accounts trade money back and forth. A person reading 4,000 lines notices the strange ones they happen to see. A test sees every line, every time.
The output is a short list, not a conclusion. Each flagged transaction still needs an invoice, an approval or an explanation before it means anything. Analytics earns its place by cutting thousands of lines down to dozens that justify that effort.
It also changes what you can say in a report. "We reviewed the statements" is weak. "We tested all 4,112 debits from three accounts over 30 months against six rules, and these 27 items remain unexplained" can be checked, repeated and argued with on its merits.
Building the forensic analytics dataset from bank statements
The forensic analytics dataset is one table holding every transaction from every account in scope, with the same fields in the same format and a pointer back to the exact page and line it came from. Most analysis errors start here, in a missing month, a sign flipped on a credit or a description cut short.
Fields the table needs
| Field | Purpose | Example value |
|---|---|---|
| Row ID | A stable key for each line | TX-000418 |
| Account | Which account the line belongs to | Operating ending 4471 |
| Statement and page | Where to find it in the PDF | 2025-11, page 3 |
| Posting date | When the bank applied it | 2025-11-14 |
| Description | The bank's text, unedited | ACH EXAMPLE SUPPLY CO |
| Payee (cleaned) | A normalized name for grouping | Example Supply Co |
| Amount | Signed, debits negative | -4,950.00 |
| Running balance | For checking completeness | 18,322.71 |
| Check number | For sequence tests | 10233 |
The values are examples. Keep the bank's original description in one column and your cleaned payee name in another. Grouping needs the cleaned version; evidence needs the original.
Prove the table is complete
Before any test, confirm each statement foots from opening to closing balance and that each month's close equals the next month's open. Then confirm the row count per statement against the PDF. A table that is one page short will still produce results, just wrong ones.
Outlier tests that run on the forensic analytics dataset
Outlier tests are rules that mark transactions unlike the rest: amounts that look chosen, payments on odd days, payees whose totals jump. Each test is cheap to run and each has a known innocent explanation, so the skill lies in choosing tests that fit the suspected scheme and reading the results with that in mind.
| Test | Field used | What it flags | Usual false positive |
|---|---|---|---|
| Round amounts | Amount | Payments in whole hundreds or thousands | Rent, loan payments, owner draws |
| Just under a limit | Amount, approval policy | Clusters below an approval threshold | Contract prices set at a round figure |
| Relative size | Amount, payee | A payment far larger than that payee's usual | One-off annual invoices |
| Weekend and holiday | Posting date | Activity when the office is closed | Card subscriptions, automatic debits |
| Duplicate | Payee, amount, date | Same payment twice within days | Split shipments billed separately |
| Gap | Check number | Missing numbers in a sequence | Voided checks, checks still outstanding |
| Payee growth | Payee, month | A payee whose total climbs steadily | A real supplier taking on more work |
Run the tests in a sensible order
Start with duplicates and gaps, because they are mechanical and their results are easy to confirm or dismiss. Move on to payee growth and relative size, which need a baseline period to compare against. Leave round amounts and just-under-limit tests until last, after you have read the approval policy and listed the payments that are round by contract. Running them in this order means each later test works on a population you already understand, and the exception lists stay short enough to read.
Round amounts deserve a careful setup, since many honest payments are round by nature. Testing round dollar transactions and the exclusions to make first covers that. For how these patterns map to particular schemes, see the bank statement red flags for embezzlement and kiting.
Some questions need a different method. When the issue is hidden income rather than a suspicious payment, an indirect approach such as the net worth method in forensic accounting estimates what someone must have earned from what they own and spend, and bank data feeds it.
Link analysis between payees, accounts and people
Link analysis connects transactions through shared details: a payee whose bank account matches an employee's, two vendors with the same address, money that leaves one account and arrives in another under a different name. Single transactions look normal; the link between them is what shows the scheme.
A worked example
The case below is invented for illustration. A company pays three vendors that each look ordinary.
- List vendor details from the vendor file: name, address, bank account for ACH.
- List employee details from payroll: name, home address, direct-deposit account.
- Join the two lists on bank account and on address.
- Result: "Northside Parts" and "NS Industrial" share a street address, and the ACH account for NS Industrial matches the direct-deposit account of a purchasing clerk.
- Bring in the bank data: payments to the two vendors total 186,400.00 over 22 months, all approved by the same clerk, none above the clerk's approval limit.
None of the 41 payments would stand out alone. The link between the vendor file and the payroll file is the finding. Bank statements alone would not have shown it, because a statement shows the payee name, not the account it went to; you need the vendor master or the bank's payment detail for that join.
Links inside the bank data
Transfers between related accounts are links too. Pair every outgoing transfer with an incoming one by amount and date, allowing a day or two of float. The unmatched ones, and the ones that cycle back, are the leads.
How do you keep forensic analytics results defensible?
Forensic analytics results are defensible when someone else can take your inputs, run your steps and get the same flagged list, and when each flagged item can be traced to a page in an original statement. That means versioned data, recorded test settings and a log of what happened to every flag.
Four habits cover most of it:
- Version the dataset. Name each version, record its hash and never edit it in place after tests start.
- Record parameters. "Duplicates within 5 days, same payee, amount equal to the cent" is reproducible. "Possible duplicates" is not.
- Trace every flag. Each flagged row keeps its statement and page reference, and the outcome (explained, unexplained, referred) is written next to it.
- Separate tested from untested. State which accounts and months were outside scope.
Write each test so a non-specialist can follow it. A judge, an insurer or a board member will read the description before the numbers. "We listed every payment to a vendor that shared a bank account with an employee" is clear on first reading. A description that needs the reader to understand join types or regular expressions invites the other side to say the method is a black box.
Extraction is the weak point in many datasets. If a converter misread a digit, the analytics inherit the error. PreciseBankFlow scores the confidence of each field it reads and marks any statement that does not foot as out of balance, so low-confidence lines can be vouched to the PDF before any test runs.
Institutions that analyze their own members' or customers' accounts face a related problem at much larger volume. Reconciliation software for credit unions discusses the examiner-ready evidence that work needs.
When forensic data analytics points the wrong way
Forensic data analytics points the wrong way when tests run on too little data, on the wrong data, or with no question behind them. A long exception list feels like progress but can bury the one item that matters, and a statistical test on a small sample can flag noise as fraud.
Watch for these failure modes:
- Small sets. Distribution tests need hundreds of amounts to mean anything. On 60 transactions, use rule-based tests and read the lines.
- Mixed populations. Payroll, rent and supplier payments behave differently. Test them separately, or the patterns of one hide the oddities of another.
- Schemes that avoid the data. Cash skimmed before deposit never appears on a statement. Analytics on the bank account will report a clean result for a real theft.
- Confirmation bias. If you already suspect one person, every flag starts to look like theirs. Record the explanation for each flag before you look at who approved it.
A clean result from analytics is a statement about the tests you ran, not about the absence of fraud. Say that in the report, in those terms.