Why Modern Investigations Need More Than a System of Record: The Case for Deep Discovery

Between 2017 and 2021, a bank recorded the same customer’s cash deposits more than 500 times, in reports specifically designed to flag large currency transactions. The reports totaled over $400 million. Each one existed. Each one was filed, or should have been, in a system built to keep exactly this kind of record. The bank did not connect them until federal investigators did.

That is not a story about missing data. It is a story about a system that recorded everything and discovered nothing.

A System of Record Answers “What Happened.” It Does Not Answer “What Connects.”

The case is TD Bank’s, and it is now public through a $1.3 billion settlement with the Financial Crimes Enforcement Network — the largest penalty ever assessed against a depository institution under the Bank Secrecy Act. According to FinCEN’s October 2024 consent order, the bank failed to identify one customer, Da Ying Sze, across more than 500 Currency Transaction Reports totaling more than $400 million, even as it facilitated over $400 million in transactions connected to a narcotics money laundering conspiracy Sze later pleaded guilty to. The bank’s systems captured each transaction as required. What they did not do was surface that the same person kept appearing.¹

This distinction matters for any enterprise investigation function, not just banking compliance. A system of record is built to answer a narrow question well: what happened in this transaction, this case, this account. It is authoritative, auditable, and necessary. It was never designed to answer a different question: which of these thousands of individually compliant records describe the same underlying person, entity, or pattern. Investigators are left to ask that second question manually, case by case — usually after a regulator or a journalist has already asked it for them.

The Correlation Failure Can Hide Inside a System That Is Working Exactly as Designed

The uncomfortable part of the TD Bank case is that the failure was not primarily a data problem. FinCEN’s order also describes staffing backlogs, delayed reporting, and internal escalation failures — meaning the record-keeping was there and, in places, so was internal knowledge of the risk. What was missing was the operational capacity and workflow to turn scattered compliant records into a single visible pattern before it became a criminal referral.

This is worth sitting with, because it cuts against a common assumption in enterprise investigation technology: that more complete records automatically produce better investigations. They do not, if nothing in the environment is responsible for asking whether two records describe the same reality. A system of record can be functioning correctly — in the narrow sense that every entry is accurate and retrievable — while the organization built on top of it still cannot see its own risk.

When the Boundary Is Between Systems Rather Than Within One

A second, related failure mode shows up when the disconnect is not inside one system but between systems that were never meant to talk to each other. Danske Bank’s Estonian branch ran its own IT infrastructure, separate from the Copenhagen headquarters, after the branch was acquired in 2007. That separation limited the parent company’s visibility into the branch’s transaction activity. Between 2007 and 2016, high-risk, non-resident customers moved billions of dollars through the branch, generating — according to the SEC’s December 2022 complaint — as much as 99 percent of the branch’s profits in some periods. Danske Bank agreed to pay $413 million to settle SEC fraud charges over its misleading statements about its AML program, part of an integrated resolution exceeding $2 billion with the SEC, the Department of Justice, the U.S. Attorney’s Office for the Southern District of New York, and Danish authorities.²

The TD Bank and Danske Bank failures are not the same failure. One is a correlation problem inside a single institution’s own records. The other is a structural visibility problem between a subsidiary and its parent. Both produced the same outcome: an enterprise that could, in principle, retrieve every relevant record — and still could not see the pattern those records described until an outside party found it first.

The Harder Question: Is This a Technology Problem at All?

It would be convenient — and self-serving for anyone selling investigative software — to conclude that better systems alone would have prevented both cases. That is not fully supportable. FinCEN’s order is explicit that TD Bank’s own personnel were aware of parts of the risk and failed to escalate it. No correlation engine fixes a decision, made by people, not to act on a known problem. Technology can surface a pattern faster. It cannot substitute for the institutional willingness to treat that pattern as urgent once it is surfaced.

What technology can legitimately change is how long it takes for the pattern to become visible in the first place, and whether an investigator has to go looking for it manually or whether the environment surfaces it as a matter of course. That is a narrower claim than “AI would have caught this,” and it happens to be the more defensible one.

What an Investigative Environment Does That a Record System Does Not

The distinction worth building toward is between a system that records and an environment that discovers. A system of record’s job ends once the transaction, case, or account entry is captured accurately. An investigative environment’s job starts there: it treats “does this new record share an identity, address, device, or entity with something we already hold” as a standing question, asked continuously — not as a special project undertaken after a regulator inquiry.

This does not mean replacing systems of record. Danske Bank’s and TD Bank’s underlying transaction systems were, for the most part, doing what they were built to do. The gap was a layer above them: something responsible for treating structurally similar records as connected regardless of which system, subsidiary, or reporting period they originated in, and for making that connection visible to a human investigator before the scale becomes a regulatory matter.

Questions Worth Asking About Your Own Environment

• If the same individual or entity appeared in 500 separate compliant records over four years, would anything in your current workflow surface that as one pattern — or would it take a targeted investigation to notice?
• Do any of your subsidiaries, branches, or acquired business units run on systems that do not feed a shared view of risk to the parent organization?
• When investigators find a connection, is it because the environment surfaced it — or because someone happened to remember a name from a prior case?
• How long, in practice, does it take a known risk identified by front-line staff to reach someone with the authority to act on it?

The Measure That Matters Is Not Whether You Have a System of Record

Every enterprise investigation function already has systems of record. That was never the differentiator, and it is not the diagnosis these cases point to. The differentiator is whether the organization has anything responsible for treating separately recorded facts as one connected picture before an outsider does it first.

The TD Bank and Danske Bank settlements did not happen because either institution lacked data. They happened because the data was never asked the right question until it was too late to matter internally. That is the test worth applying before the next audit does it instead: not “do we keep good records,” but “does anything in our environment notice when the records start describing the same thing.”