Access control did not answer intent
A quantitative trader is accused of using two years of legitimate access to build a competing firm on his employer's code, then telling his own staff to delete the history. The case is a clean lesson in why "who accessed the repository" is the wrong first question, and what an investigation has to reconstruct instead.
- In the Headlands case, the accused had every right to be in the repository. Access logs would have shown a developer doing his job for two years.
- On the allegations, the signal was never in access. It was in context: a firm formed while still employed, a relationship with a competitor, and code breadth beyond the assigned work.
- The indictment also alleges an attempt to delete communications and source history. Evidence under the suspect's control is evidence you may not get.
- Reconstructing suspected source-code theft means building the employment and business timeline first, then placing every technical artifact on it. Alerts are inputs, not the investigation.
In January 2025 the Southern District of New York unsealed an indictment against a former quantitative trader at a global trading firm. The allegation is not that he broke in. It is that he was let in, for about two years, and used that time to walk out with the firm's core trading code and build a competitor on it.
Read as a security incident, it is unremarkable. Read as an investigation, it is one of the clearest illustrations I know of a question most organizations spend heavily to answer, and a harder one they rarely ask.
What the indictment alleges
According to the press release and subsequent reporting, Cheuk Fung Richard Ho worked as a quantitative developer and trader at a New York trading firm from roughly July 2019 to August 2021. The firm is unnamed in the release and has been identified in press coverage as Headlands Technologies.
Prosecutors allege that while still employed he formed his own trading company, partnered with a competitor of his employer, and misappropriated core components of the firm's trading strategies. The firm says the code took years and more than a billion dollars to develop. The indictment further alleges that he later directed employees of his new company to delete their internal communications and the development history of its source code. They are said not to have complied.
He was arrested in Los Angeles on 8 January 2025. The original indictment charged one count of theft and attempted theft of trade secrets, which carries a maximum of ten years. A superseding indictment filed in May 2026 charges theft of trade secrets and wire fraud, which carries a maximum of twenty years, and he has pleaded not guilty to both counts. On 1 June 2026 the judge denied his motion to dismiss the trade secrets charge, and trial is set to begin on 2 November 2026. Everything above is an allegation, and he is presumed innocent unless and until proven guilty.
The question that gets funded, and the one that matters
Much of the spend on insider risk goes to one question: who accessed the source code? Identity providers, repository permissions, privileged access management and DLP all exist to answer it, and they answer it well.
In this case the answer was useless. A quantitative developer is supposed to be in the repository. Every clone, every checkout, every build for two years would have been a legitimate entry in an access log. Nobody reading that log would have found a single line to object to.
The harder question is the one an investigator is eventually paid to answer: what was this person doing with completely legitimate access in the six months before anyone suspected them? Not whether they touched the code, but what they touched relative to their assigned work, who they were talking to at the time, what they were building outside the firm, and whether those things line up.
That question cannot be answered by an access control product, because access control is not designed to hold context. It records that a door opened. It does not record why, or what else was going on in the building that week.
What an investigation actually reconstructs
In a case like this, the technical evidence is the smaller part of the work. The rest is putting it against everything else that was true at the time. Six strands, always the same:
- The employment timeline. Start date, role changes, assigned projects, performance conversations, the notice, the last day. This is the spine everything else hangs on, and it usually lives in HR, not in security.
- Repository history. Not "did they clone", but which repositories, how broad, how often, and whether that breadth matches the work they were assigned. A developer on one strategy who pulls the entire library is a fact worth a sentence.
- Communications. New external contacts, message volume with a particular person, a competitor's domain appearing in a calendar. Content is opened only when the review needs it and every access is logged.
- Business relationships. Company registrations, a new LinkedIn title, an investor conversation, a partnership with a firm that competes with the employer. Public records answer more of this than people expect, and on a case an examiner may consult them, company registries included.
- Movement of data. Personal devices, personal cloud, mail rules, archives created and deleted. The routes are old. What matters is when they were used relative to strand one.
- Behavior against baseline. Not a score, a comparison: this person, this month, against the same person's own earlier months.
None of these is decisive alone. A clone matches a ticket. A new company might be a hobby. A competitor's name in a calendar might be a recruiter. The finding is the alignment: the clone that does not match a ticket, in the month the company was registered, in the week the competitor appeared.
The evidence you may not get
The most instructive allegation in the case is not the theft. It is the instruction to delete.
Prosecutors say he told his own staff to erase internal communications and the source code history of the new firm. Whether or not that happened, the instinct is universal and every investigator has met it. Commit history can be rewritten. Chat can be deleted. A laptop can be wiped and reissued by an IT team that is simply following the offboarding checklist.
Two consequences follow for anyone who might one day have to answer the question.
Evidence under the suspect's control is evidence you may not get. The record you rely on has to be captured at the source, continuously, into storage the person being reviewed cannot touch. Reconstructing it afterward from what survived is a forensics engagement, and forensics engagements are where we spent years finding that not enough survived.
Retention decides the case before the case exists. Here, three years and five months passed between the last day and the indictment. Most audit logs roll long before that, and laptops are often reimaged soon after the last day. If the preserved window is ninety days, the answer to "what was he doing six months before anyone suspected him" is "we do not know", and it is permanent.
If you run a team with broad, legitimate access
Quant shops, research groups, platform engineering, anyone whose engineers hold wide access by design. The controls that answer "who accessed it" are already in place. These are the ones that answer the harder question.
- Write down what assigned work looks like. Tickets, projects, ownership. Deviation is only visible against a definition. This is the single cheapest change on the list.
- Preserve repository, identity and mail activity beyond the default window. Export and keep the audit logs. The vendors' defaults are set for their storage costs, not for your investigation three years from now.
- Look for pairs, not events. A change in code breadth plus a new external contact. A spike in downloads plus a drop in commits to assigned work. One signal is noise. Two, aligned in time, is worth a review.
- Make the last day a review, not a wipe. Hold the device and the mailbox. Open the record of the months before the notice, before the account is closed, and conclude in writing either way.
- Decide who can look, and log it. Broad legitimate access cuts both ways. A review that anyone can run on anyone is not defensible, and your engineers will rightly ask.
Where Excavate fits
This is the case coverage was built for. Excavate reads the systems a company already runs and keeps a tamper-evident record outside the reach of the people it covers, so most of what these strands need is already preserved when the question is asked. On a case, a named forensic examiner puts all six strands on one timeline and writes the conclusion.
If you hold code that took years to build and hand broad access to the people who build it, see how coverage works, or bring us the systems you run and we will tell you what it would have shown.
Corrected 14 October 2026: an earlier version misstated the charges and the status of the case.