The problem. Finance has no strong code-publication norm: most papers ship no implementation, official repos often produce “illustrative” results rather than the paper’s tables, and the third-party reimplementations that fill the gap inherit and add bugs. Finding code is easy; finding code you should trust is the actual skill.

The four tiers, and where to look

Tier 1 — Official code. Check, in order: the paper’s abstract/footnotes for a repo link; Papers With Code (thin for finance, improving for ML-finance crossovers); authors’ GitHub profiles and academic homepages (code sometimes posts after publication — check again in six months); and journal supplementary materials, where “replication package” requirements at some finance journals quietly deposit real code. Pin the commit hash the moment you find it.

Tier 2 — Third-party reimplementations. GitHub-search the paper title in quotes, the method’s distinctive name (“DeepLOB”, “Avellaneda-Stoikov”, “deflated Sharpe”), or its equation’s distinctive term. These are simultaneously the ecosystem’s gift and its trap: an audit of one such notebook — untrained baseline, label-as-return backtest, inverted labels — is this site’s standing exhibit on why stars ≠ correctness. Popular reimplementations of famous papers have propagated known bugs for years.

Tier 3 — Library implementations. The method may live, hardened, in the ecosystem already: statsmodels (econometrics), arch (GARCH family), QuantLib (pricing), skfolio/PyPortfolioOpt (allocation), mlfinlab-descendants (López de Prado methods — CSCV, purged CV), vectorbt (backtesting). A maintained library beats a dissertation repo on every axis except exact-paper fidelity — and fidelity is checkable.

Tier 4 — Nothing exists. For most finance papers, this is the tier. Then the paper’s flowchart-level pipeline is your spec, and writing the implementation is the reproduction — with the known-answer tests that entails.

The 15-minute audit before found code touches your research

  • ☐ Does it run and reproduce a paper number? Not “runs without error” — produces a table entry within tolerance. Illustrative repos fail this in the first ten minutes and save you the next ten hours.
  • ☐ Grep the red flags: seeds unset, strict=False-style silent loading, full-sample fitting before splits, test data touched during training, hardcoded lookahead indices.
  • ☐ Check the environment: no lockfile/pinned versions means results drift with dependency updates — pin before running, per reproduction stage 3.
  • ☐ Read the issues tab: unanswered “results don’t match the paper” issues are the most informative documents on GitHub.
  • ☐ Diff against the paper’s methodology, not its README. Reimplementations drift toward what was easy, and READMEs describe intentions.

Using found code without inheriting its conclusions

The disciplined pattern: use third-party code to understand (reading a working implementation clarifies ambiguous notation faster than the paper), but validate independently before any result enters your experiment log — known-answer tests, one-bar-lag checks, and reconciliation against the paper’s own numbers. Code you didn’t audit is an assumption you didn’t list.

Questions to ask of any repo

  1. Which paper table can this code reproduce, and has anyone (issues, forks) confirmed it?
  2. What’s the commit history — active refinement, or a graduation-day snapshot?
  3. Where does the data come from, and can you get it?
  4. If it’s a library: does its implementation match the paper’s variant, or a simplified cousin? (Check the docstring’s citations.)

How our scoring treats code availability

Papers with linked, working code score higher on rigor’s reproducibility component — code is the strongest single falsifiability signal a paper can send. The score can’t audit the code itself (that’s tier-2 caution and yours to apply), which is why paper pages carry discussion sections: replication notes on real repos are precisely the knowledge the field undersupplies.


The chain: find the data → · reproduce properly → · what to replicate first →

The shortlist below is generated from the archive: every paper whose page links a public repository, ranked by rigor-weighted score. The full, daily-updated list lives at papers with code, and the Has code filter in search combines it with topic and rigor filters.

595 papers link a repository · ranked by rigor-weighted score