The Minds Behind the Models: Aflin Airil
Aflin Airil: The Accidental Quant
Most people find their way into quantitative finance through a carefully planned career path, a finance degree, or a targeted internship. Aflin Airil found his way in by accident.
Aflin is a Yayasan TM Scholar and a first‑year Engineering student at Multimedia University (MMU), majoring in Computer Engineering. He’s maintained a 3.92 CGPA and a spot on the Dean’s List across his first three semesters, and he’s heavily involved in student leadership and STEM projects outside the classroom. But three weeks ago, he had never encountered concepts like Sharpe ratios, Information Coefficients (IC), or correlation‑based signal selection.
His entry into AlphaNova happened because of a mix‑up.
"A friend mentioned he'd entered a WorldQuant-style competition, and I went looking for it — turned out I'd mixed it up with a completely different platform, AlphaNova. By the time I realized the mix‑up, I was already reading the rules page and thought, why not."
It is a great reminder that in this community, you don't need a decade of industry experience to get started. You just need to be willing to read the rules and give it a try.
The Bug That Looked Like "No Signal"
Given his foundation in engineering, the math wasn't entirely foreign, but the specific mechanics of financial forecasting were new. To bridge the gap, Aflin leaned on walk‑forward validation and standard machine learning tools like scikit‑learn's Ridge regression and LightGBM.
But he learned a crucial lesson early on—one that many data scientists take years to appreciate. He hit a bug where his model was outputting nothing. It looked like the data had no signal. In reality, it was a configuration error.
"I became a lot more careful about regularization after a real bug bit me: a model whose regularization strength was set orders of magnitude too high for the actual target scale, silently zeroing out every coefficient. It looked like 'no signal' when it was actually 'no model.'"
That distinction—between a lack of signal in the data and a broken model—is exactly the kind of debugging rigor that separates good researchers from great ones. Ismam described a similar instinct when he refused to tune an underperforming architecture, choosing instead to retire it and start from first principles.
Structurally Different Signals and the Redundancy Trap
Aflin’s approach to the competition was highly systematic. Rather than iterating endlessly on one idea, he cast a wide net.
"I tested around twenty structurally different signals rather than variations on one idea — momentum, mean‑reversion, cross‑feature interactions, and tree ensembles (LightGBM). Ten made it to submission, three made the Quality set."
His biggest finding was that the signals that succeeded weren't the standard trend‑following ones. They combined a cross‑sectional spread between two features with a multiplicative regime gate—a genuinely different mechanic.
He also discovered the danger of feature redundancy, specifically as it relates to tree‑based models.
"I learned the hard way that tree models overfit badly when fed multiple overlapping‑window transforms of the same underlying features. The redundancy, not the model's complexity, was the actual risk. Every tree I built on genuinely diverse features passed; every tree built on collinear variants of the same one or two features got flagged for overfitting. Linear models on that same collinear data, by contrast, held up fine."
This is a vital technical insight. Tree models are incredibly powerful, but they will ruthlessly exploit redundant features to memorize noise. Linear models, constrained by their coefficients, are more forgiving of collinearity. It's a perfect real‑world example of why matching your model class to the structure of your data is critical.
AI as a Scaffold, Not a Crutch
Aflin is not a programmer by background, which made AI tools like Claude essential for getting his code working against our interface. But the most important part of his journey over the three weeks wasn't what the AI wrote for him—it was how his relationship with the AI changed.
"What changed over the three weeks is that I stopped just accepting outputs and started pushing back on them, asking why a result looked the way it did, testing ideas myself against real data rather than trusting a first answer. That shift, more than any single tool, is probably the real story of this competition for me."
That shift—from treating the AI as an oracle to treating it as a junior collaborator whose work must be checked—is the exact evolution we've seen across this series. Kanishk talked about moving from prompt engineering to system architecture. Mathurin warned that AI is exceptionally good at producing plausible, convincing narratives for noisy results.
Aflin learned to push back. That is the skill that will carry forward.
What We Can All Learn
Aflin’s journey is short but packed with practical takeaways:
- You don't need a quant finance background to start. A background in engineering, math, or just logical problem‑solving is enough to build something competitive.
- Beware the "no signal" illusion. Always check your model configuration before concluding the data is empty. A broken model can look exactly like a random market.
- Redundancy kills tree models. If you are feeding multiple variations of the same feature into LightGBM, you are inviting overfitting. Diversity of features matters more than the complexity of the model.
- Push back on AI. The tool is only as good as the judgment of the person directing it and reviewing its output.
That combination of curiosity, rapid learning, and technical honesty is exactly what the AlphaNova community is built on.
Stay tuned for more profiles from the AlphaNova community. If you’d like to be featured, reach out—we’d love to share your story.