Mt Gox checklist: would your org have caught a slow drain?

A slow drain is caught by reconciliation, not by perimeter alerts. Prosecutors allege Mt Gox lost customer bitcoin in periodic transfers over about three years. If your org cannot compare its ledger to its real balances every day, and review every outbound movement, a similar pattern could run for a long time unseen.

What is actually known about Mt Gox?

In June 2023 the US Justice Department unsealed charges against two Russian nationals, Alexey Bilyuchenko and Aleksandr Verner. These are allegations, not findings of a court. Reporting on the charges says prosecutors claim the pair gained control of a Mt Gox server in Japan between September 2011 and at least May 2014, and moved bitcoin to themselves in periodic transfers until the "vast majority" of customer coins were gone. The charges concern about 647,000 bitcoin.

The coverage we fetched does not say how the access was first gained, so this post does not guess. Mt Gox filed for bankruptcy in March 2014, saying the loss left it insolvent.

The useful lesson is not who failed. Any custodian, exchange or fintech holds assets that can be moved by someone with enough access. The question is how fast you would notice.

Which controls would shorten the time to detection?

Read each item as a yes or no question about your own organization. A "no" is a gap to schedule, not a verdict on anyone.

Reconciliation

• Do you compare your internal ledger to actual on-chain or bank balances at least daily?
• Does a person outside the team that runs the system review the result?
• Is there a written rule for how large a mismatch triggers an incident?

Key and access custody

• Is the signing key for large moves held in a way that needs two people or two systems?
• Can one server, with one set of credentials, move a meaningful share of customer assets alone?
• Do you cap how much sits in the online (hot) store, and top it up in reviewed steps?

Alerting on movement

• Does every outbound transfer above a threshold page someone?
• Do you alert on patterns, such as many small transfers to the same destination, and not only single large ones?
• Are the alerts sent from a system the server being watched cannot silence?

Logging

• Are logs shipped off the host, in a store the application administrators cannot edit?
• Can you reconstruct who or what initiated each transfer, for the full retention period?

Independent assurance

• Does someone outside the company check that customer balances are backed by real assets?
• Do you practice the first hour of a theft incident: freeze, preserve logs, notify?

Why does a multi-year loss matter for modern teams?

The same shape shows up outside finance. A slow leak of data, or a quiet change to a build pipeline, passes through the same blind spot: nothing breaks, so nobody looks. Controls that compare "what should be true" against "what is true" on a schedule catch it. Controls that wait for a loud event do not.

Software supply chain work has the same pattern. An inventory (an SBOM) that you diff after every release tells you when a dependency changed quietly. Without the diff, the inventory is a document, not a control.

What to do

1. Pick the asset that would hurt most to lose, whether funds, customer data or signing keys.
2. Write down every path by which one person or one machine could move it.
3. Add a second approver or a second system to the largest paths.
4. Start a daily reconciliation with a named reviewer outside the operating team.
5. Move logs and alerts off the hosts they describe.
6. Run a tabletop exercise on a slow theft, and record how long detection took.

Quick check

Sources

• Cointelegraph: US Justice Department charges two men in Mt Gox hack
• TechCrunch: US DOJ charges two Russians for hacking crypto exchange Mt Gox

Last reviewed: 18 October 2026.