I build research systems for finance. The thread running through everything here is a single question I find genuinely hard: how do you know a financial claim is true?

Not "does the model look good," but: is this number traceable to a source, does it survive a test that could have failed, and would I notice if it were wrong? Most of my projects are attempts to make that checkable in code rather than trusted by convention.

CFA Level I passed, Level II candidate. Working toward the intersection of finance, AI, and forensic research.

Four repositories, all Python, all with tests you can run.

agentic-equity-research — An auditable research pipeline for Indian small and mid caps. Deterministic code computes every number; an LLM may only narrate numbers that already exist. An agent that invents a figure, cites a fact that is not in the store, or narrates past a computed hard-fail fails the run instead of getting cleaned up.

The forensic layer is the part I care most about: Beneish M-score with all eight indices, cash-reality checks including cumulative CFO/PAT across a decade, and separate lender tests for NPA drift and originate-to-sell behaviour. Every check resolves to PASS, FLAG, UNAVAILABLE(reason) or NOT_APPLICABLE(reason), so a check that never ran can never read as a check that passed.

667 tests; 100% line coverage on the compute layer, enforced in CI.

quant-research-os — A research platform built so an idea has to survive something before it counts. The validation toolkit is written from the primary papers: purged and combinatorial cross-validation with embargo, probability of backtest overfitting, deflated Sharpe, White's Reality Check and Hansen's SPA, permutation testing on a stationary block bootstrap.

23 pre-registered experiments: thirteen passed, five passed only partially, four failed outright, and one split — its infrastructure pilot worked while the alpha it was testing died. That alpha, funding mean-reversion, was later re-specified and killed a second time. Both kills are still in the repository with their original pre-registrations, which is the point.

quant-options-engine — Options pricing and volatility-surface calibration for crypto options. Black-Scholes with full second-order Greeks, Heston by COS expansion cross-checked against an independent quadrature of the same characteristic function, Merton jumps, SABR, and Gatheral SVI with the analytic butterfly condition. Signals are netted against the actual spread and fee of the specific contract, and arbitrage violations are quarantined rather than reported as edge — on live data they are usually a stale quote, not free money.

smallcap-pump-reversal — A short mean-reversion rule on Binance perpetuals, and more usefully, the written record of the 29 pre-registered experiments behind it. Eighteen ended in an explicit kill and two more were judged not deployable. One had an in-sample AUC of 0.918 and an out-of-fold AUC of 0.42 — worse than a coin flip, and the sort of result a naive backtest would have shipped.

The rule is paper-forward only. No live capital, and promotion is gated on a decision rule fixed before collection started.

These look like four unrelated projects. They are four attempts at the same problem from different directions:

Two habits carry across all of them. Pre-register the test so a negative result stays negative. Separate computation from narration so the part that can be checked is not tangled with the part that merely sounds convincing.

The second one has turned out to be the more general idea. A language model is good at explaining a number and poor at being accountable for it, so I'd rather the architecture not give it the opportunity.

Wiring the remaining agents in agentic-equity-research, so a full run reaches a report rather than three of fourteen roles. After that, a calibration record. The system already emits dated, falsifiable criteria, but nothing scores them yet, so there is no measured record of whether its judgements hold up.

The technique I want to move across next is multiple-testing correction. quant-research-os does this properly; the options engine scans a whole chain for dislocations and controls for nothing, which means its output is a list of candidates rather than findings.

Splitting this out because the honest answer to "do you know X" is usually partial.

Comfortable with: Python, numerical methods, statistical validation, financial statement analysis, valuation, derivatives pricing, building the kind of engineering scaffolding that keeps research reproducible — typed interfaces, injected clocks, provenance-tracked data, CI that fails on the things I said mattered.

Actively learning: NLP applied to filings and transcripts beyond the structured extraction I do now; time-series machine learning that survives its own validation, which is harder than training it; market microstructure at a level where I could argue with someone who trades for a living.

Interested in, not yet built: blockchain and on-chain analytics as an alternative data source; anomaly detection across a universe of filings rather than one company at a time; connecting fundamental, forensic and market-based signals into one view of a business.

I have not deployed any of this with real capital, and I have no live track record. Everything above is research.

The long-term version is AI-assisted forensic research: reading a filing the way an investigator would — line by line, cash against earnings, disclosure against behaviour, each period against the last — at a scale a person cannot do manually, without giving up traceability for coverage.

The obstacle so far has not been model capability. It is evidence handling: keeping every number traceable to a source, making an absent check visible rather than silent, and leaving every claim open to refusal. That is mostly a systems problem, which is why a lot of this code is plumbing.

LinkedIn · agarwalchirag535@gmail.com

Open to conversations about any of the above.