Yuki Tanaka

What did an investigation look like before you brought AI into it?

For most of my career, the constraint was volume. A fraud or dispute engagement lands with hundreds of thousands of transactions, sometimes several years of a general ledger, and I could not read all of it. So I sampled. I pulled a statistically defensible slice, tested it, and reasoned outward from what I found. That method is sound, but it has a blind spot: fraud rarely distributes itself evenly, and a careful scheme can sit entirely outside your sample. I also spent long stretches on manual tie-outs and keyword searches through document productions, work that was necessary but slow. The honest tradeoff was that thoroughness cost time, and time is exactly what a client in the middle of a dispute does not have.

What was the first thing you tried, and how did it go?

The first real test was pointing an anomaly-detection tool at a full general ledger instead of a sample. I fed it a client's ledger and asked it to risk-score every entry rather than pick a subset. It surfaced the usual statistical tells: Benford's Law deviations, round-dollar amounts that hinted at structuring, duplicate and near-duplicate payments, entries posted at odd hours. My first reaction was caution, because most of what it flagged was ordinary. A round number is not a crime, and plenty of legitimate entries look strange out of context. What convinced me was not the volume of flags but the ranking. It gave me an ordered list of where to look first, and two of the top items turned out to matter. It did not find fraud. It told me where to spend my attention.

How do you actually use it now, in your own routine?

Two ways, mostly. First, full-population scanning. Every engagement now starts by running the complete ledger, not a sample, through anomaly detection: outliers by vendor, user, amount, and timing, related-party fund flows, and threshold splits sitting just under approval limits. I get a risk-ranked worklist instead of a random slice. Second, document review. Investigations generate enormous document sets, contracts, emails, bank records, and I use AI to summarize and cluster them and to pull the passages that reference a given account or counterparty. That turns weeks of reading into a directed search.

Both outputs are starting points, never conclusions. The tool narrows a haystack of a million rows to a few hundred that deserve a human's eye. I still open the source records, trace each flag to its documentation, and build the actual finding by hand.

Where don't you trust it, and where do you keep control?

The line I hold is that AI flags an irregularity, but only I can decide whether it is a bookkeeping error, a policy exception, or a deliberate act. That judgment is the work, and it does not transfer to a model. Anything I intend to rely on has to be independently verified against source documents, because my findings can end up in a report, a deposition, or a courtroom, and the evidentiary process has not changed just because the review method did.

Confidentiality is the other hard rule. I handle privileged and highly sensitive financial records, so client data does not go into consumer tools or anywhere it could train a public model. I document how each conclusion was reached and keep the tooling inside controlled, reviewed processes. If I cannot explain a finding without leaning on the model, it is not ready to leave my desk.

Is there a specific moment it earned its place?

One matrimonial dispute stands out as an illustrative example. The opposing side produced years of records for a small business and claimed the books were clean. A full-population scan flagged a cluster of payments to one vendor that, on the surface, looked routine: consistent amounts, regular timing. What the tool caught was that they sat just below an internal approval threshold and clustered around period-ends. That pattern would have been invisible in a sample. When I pulled the underlying invoices myself, several had no supporting detail and traced back to a related entity. The model did not make that case. It pointed me at the right two hundred rows out of a few hundred thousand, and the manual work that followed is what stood up. Without the scan, I might never have looked there.

What would you tell a peer who's skeptical?

I would tell them the skepticism is correct, and to keep it. The failure mode I worry about is a practitioner treating a flag as a finding, or worse, dropping a model's summary into a report without reading the source. These outputs are not always transparent, and in a field that has to defend its work under oath, you cannot rely on something you cannot explain.

What I would not do is dismiss it. Sampling was always a compromise we made because full review was impossible, and now it is possible. A peer who refuses to look at the whole population when the technology allows it is choosing a weaker method. The point is to let the machine widen your coverage while you keep every conclusion your own.

How has it changed your work, and your clients' experience?

The biggest change is coverage. I now review whole ledgers rather than sampling them, which means I can say I looked at everything, and in this work that sentence carries real weight with counsel and in court. The second change is speed to the real issue. I reach the handful of transactions that matter in days instead of weeks, so more of my hours go to analysis and less to hunting.

For clients, that shows up as faster answers and often lower cost, because the slow manual phase is compressed. They also get a clearer story, since I can show the population I tested and why specific items drew scrutiny. The work is more defensible and more thorough at once. What has not changed is who is accountable for the opinion. That is still me, and it always will be.