Harsh Maheshwari

Chemical engineers learn something most data scientists never do. Real systems bite back. Batch processes, reaction equilibria, fluid dynamics - these are not abstractions. They fail at the boundaries, not the averages. That instinct - ask what breaks before you ask what works - is the lens I carry into every data problem I touch.

Over five years I have moved through enterprise banking automation, production Machine Learning at scale, cross-border e-commerce intelligence, and live quantitative research - now crypto HFT and MFT. Each stage compounded the previous one. None of it was planned. All of it connected.

What I actually do, underneath the job titles: I build repeatable, scalable, efficient systems with low maintenance - and I can take a problem from first-principles research all the way to a live system, on my own. I’m at my best when the problem is hard, the data is noisy, and someone needs one person who can do the research, ship the engineering, and explain both to a stakeholder who has never opened a notebook.

---

The Journey

Chapter 1 - The Foundation (IIT Bombay, 2017–2021)

AIR 1382 in JEE Advanced, out of ~200,000 candidates. AIR 735 in JEE Mains, out of ~1.3 million - top 0.06%. Those numbers are not about prestige. They are about what the preparation sharpens: systematic thinking under pressure and the discipline of working inside constraints you cannot negotiate away.

Chemical engineering at IIT Bombay was the real education. Batch processes, reaction kinetics, thermodynamics, fluid mechanics - operational systems with real failure modes. Engineering taught me that every system has inputs, outputs, failure modes, and feedback loops, and that you model all of them, not just the happy path.

Early 2019 I spent a semester at Danmarks Tekniske Universitet in Copenhagen as an exchange scholar - batch distillation, liquid-liquid extraction, gas flow in pipes, filtration. Hands-on experimental reports where the variance in your measurements is your problem to explain, not noise to dismiss. That semester permanently changed how I think about data quality: measurement error is a design decision.

Late 2019, Prof. Bryan Hooi’s lab at NUS. Two months. My first real exposure to Machine Learning research - temporal graph learning and link prediction on dynamic networks, 86% AUC. Small scope, permanent mindset shift: a result is not the same as a claim, and models have assumptions that have failure modes.

Chapter 2 - Learning How Real Systems Fail (ANZ Bank, Jun 2021–Mar 2022)

First production role, straight out of IIT Bombay: enterprise data automation, connecting regulatory reporting pipelines across APRA compliance. I built ETL workflows integrating 70+ source systems with IBM DataStage and Teradata. ASCII files, EBCDIC files, mainframe-era structures, zero tolerance for approximation.

A wrong byte in a regulatory report is not a technical-debt item. It is a legal event.

I cut development and testing time by 50% by automating manual validation, and I learned why enterprise systems are conservative: they are optimized for correctness at the cost of speed, not the other way around.

Chapter 3 - Production Machine Learning at Scale (Blue Yonder, Apr 2022–Mar 2023)

A global supply-chain software company, and real scale: 5TB+ of data, seven distinct forecasting problem types, a deployment pipeline running reliably for enterprise clients around the clock. Fulfillment capacity, delivery-time estimation, replenishment, markdown decisions, inventory - each with different distributions, stakes, and latency budgets.

The stack was serious: TFX, Apache Beam, Dataflow, XGBoost, LightGBM, distributed training on GCP. And the lesson every production Machine Learning engineer eventually learns: a model that scores 95% on a held-out set but can’t run in 30 seconds at 3AM is not a model - it’s a prototype someone forgot to finish.

Chapter 4 - The Consulting Turn (GoGlocal, Mar–Oct 2023)

Manager of Data Science - my first role owning a full data product rather than a component of someone else’s. 1,000+ SKUs across Amazon, eBay, Walmart, and Lazada: NLP for product classification and attribute extraction, pricing intelligence, competitor analysis, revenue estimation. Manual effort down 50%, revenue efficiency up 30%.

The consulting dimension meant constant translation between technical output and business decisions. A pricing model a data scientist is proud of is worthless if merchandising can’t act on it. I learned to frame model outputs as decisions, not metrics.

Chapter 5 - Going Deep on Markets (Mastertrust, Jan 2024–2026)

VP of Data Science and Quantitative Research - the most demanding role of my career. I owned quantitative research, Machine Learning systems, and production trading infrastructure at once, and I built and ran live systematic index-options strategies on real capital.

(On specifics: I don’t publish Sharpe, PnL, AUM, or strategy logic - that work is confidential. What I can talk about is the discipline.) Volatility-surface modeling, microstructure analysis, regime detection, execution-aware backtesting, walk-forward validation, options Greeks as risk instruments - and the business side: communicating strategy logic to senior stakeholders and holding the discipline to walk away from strategies that looked good on paper but had fragile assumptions.

Markets are the most honest feedback loop I have ever worked in. Paper performance is an opinion. Live performance is a fact.

Chapter 6 - Current Work (NK Securities, 2026–Present)

I now work at NK Securities on crypto HFT market-making and NSE/BSE index-options MFT systematic strategies - the role that best captures what I do.

Crypto markets are structurally unusual: 24/7, fragmented liquidity across exchanges, high variance in microstructure quality, and adversarial order flow that rewards execution discipline as much as signal quality. I work on execution-aware modeling where slippage, latency, and position sizing are first-class variables, not afterthoughts - applying microstructure analysis to high-frequency order flow and building the infrastructure that turns a research signal into a live, monitored strategy.

Chapter 7 - The Through-Line

Chemical engineering → enterprise automation → production Machine Learning → quantitative research. Process thinking transferred to pipeline design. Correctness discipline from banking transferred to model reliability. Scale thinking from supply chain transferred to backtesting rigor. Business translation from consulting transferred to communicating trading logic.

I can read a volatility surface, write a production pipeline, and explain both to someone who has never opened a Jupyter notebook. That combination is rare. It is what I offer.

---

What I’m Like to Work With

I’m direct about what I don’t know, and I’ll tell you early if I think you’re solving the wrong problem - before either of us spends money on the wrong build. I write things down: assumptions, failure modes, and the reasoning behind a decision, so the work survives after I’m gone. I take a small number of engagements at a time because half-attention is worse than none. And I’d rather hand you a smaller system you fully own than a clever one only I can maintain.

What I got wrong, once: early on I built a data pipeline that was completely correct - and unmaintainable. The next engineer couldn’t extend it without breaking it. It taught me that maintainability is a feature, not a nicety. Correct-but-fragile is a liability with a delay on it.

---

How I Think

First principles before frameworks. Every framework is someone’s abstraction over a problem they had. Before reaching for a library or a methodology, I want to understand why the underlying problem is shaped the way it is.

Systems thinking from engineering. Every system has inputs, outputs, failure modes, and feedback loops. I model data and trading systems the way I modeled chemical processes - attention to the boundary conditions, not just the expected case.

Validate like live capital depends on it. Walk-forward analysis with regime splits, not a single held-out set. Out-of-sample confirmation before a signal is treated as real. Feature engineering - not model selection - is where most models quietly fail, so that’s where I spend the scrutiny.

Write down how it breaks before how it works. I document failure modes first. A model has to pass a research-to-production checklist before capital or a client depends on it.

Decisions, not metrics. Every model output should be expressed as an action someone can take, not a number someone has to interpret. A model nobody acts on has negative value, not zero.

Writing is a tool for thinking. I write to find the parts I don’t actually understand yet. If I can’t explain it cleanly, I don’t understand it cleanly - and the gap is usually where the real problem is hiding.

---

Selected Proof

(No confidential trading figures - see Chapter 5 on why.)

Outcome	Context
Live systematic options & crypto strategies on real capital	Mastertrust → NK Securities
7 production forecasting models on 5TB+ data	Blue Yonder
70+ source systems integrated · 50% dev/test time cut	ANZ Bank, APRA compliance
1,000+ SKUs automated · 50% manual-effort reduction	GoGlocal
86% AUC - graph link prediction	NUS, Prof. Bryan Hooi
3rd place - NKSR Kaggle hackathon	before joining NK Securities
JEE Advanced AIR 1382 / 200,000 · JEE Mains AIR 735 / 1.3M	IIT Bombay

Full record on the Credentials page.

---

What I’m Looking For

I take a small number of consulting engagements at a time - quantitative research and trading systems, production Machine Learning and data infrastructure, and fractional data-science leadership. Selective by design, so each one gets real attention.

I’m also open to select senior quant / Machine Learning roles where the problem is genuinely exceptional.

Either way, the best first step is a direct conversation. Get in touch.