The Recommendation Engine for Commodity Traders — Anekha Sokhal, Moshi
Anekha Sokhal, founder and CEO of Moshi, explains how her background in energy derivatives trading and machine learning research led to a real-time intelligence platform for financial traders. The discussion covers how Moshi structures public, alternative, and private data into a connected graph, why recommendation and UI design matter as much as modeling, how trusted sources and conflicting reports are handled, and the pressure on AI engineers to become the whole team.
Anekha Sokhal, founder and CEO of Moshi, traces her path from a math and statistics undergraduate at Warwick to energy derivatives trading at JP Morgan, then to a Fulbright scholarship, machine learning research published at ICLR with Stability AI, and collaboration with NASA. The conversation centers on what she is building and why trading professionals need a different kind of software.
From Trader to Founder
Her background shaped the product directly. She describes her trading years as a search for a fast-paced career built around data, and her work on the commodities desk taught her to break markets into their component parts: fundamentals, physical supply and demand, news flow, and sentiment. The entrepreneurial turn came from a side project in computer vision applied to the jewelry business her family ran, which led her to want a data company founded in the United States. Her Fulbright interview, built around how energy market volatility during COVID connected to data, was the route into the country.
What Moshi Does
Moshi provides real-time insights for financial traders, starting with commodity, energy, and macro markets. The goal is to process more information than a human can and surface what matters to a specific portfolio at a given moment. She frames the scale concretely: while she speaks one sentence, Moshi ingests roughly 300 new pieces of information.
The data is organized the way a trader would think about it. Structured market data includes futures time series, technical indicators, and moving averages. Fundamentals cover supply and demand dynamics, particularly in commodities. Unstructured data includes the news, along with alternative sources such as social media and podcast audio. The fourth category is private data belonging to each user: the analysts and subscriptions they rely on, plus internal operational data, such as how many LNG ships are moving through the Strait of Hormuz.
These sources are cleaned, transformed, tagged with statistical and machine learning methods, and mapped onto a proprietary ontology inside an n-dimensional graph. The output is software that pushes new, portfolio-relevant information to the user each time they open it. Questions that would normally take days of research can, in her words, be answered in around 30 seconds.
Positioning Against Bloomberg and the Recommendation Problem
She is wary of being called the new Bloomberg. Bloomberg’s chat is a standard that traders rely on, and she recalls parsing Bloomberg chat into structured pricing sheets early in her NLP work. Her framing is that Moshi is a different kind of software. Her joke that Bloomberg, Claude, and Netflix had a baby, resulting in Moshi, points to the core of the product.
The Netflix part is a recommendation system built for traders. A trader cares about second- and third-order effects that are not obvious from a news feed. An energy equities company doing something that indirectly moves oil is only useful if it is connected to the trader’s exposure at the right time. A connected graph can surface that relationship, much as a human analyst would or a recommender system mimicking that reasoning can.
The discussion broadens into recommendation systems as an underrated field. Recommendation is arguably one of the most consequential systems in AI, powering feeds at YouTube, Netflix, Instagram, and TikTok, yet engineers often underrate it. Spotify and Instagram are cited as companies that do it especially well by pushing relevant data to users so that they engage without thinking about it.
She also points to a shift in how software is built. Anyone can now produce a dashboard with an LLM, but the hard part is getting others to adopt it inside their workflow. That makes the problem a UI and adoption problem as much as a modeling problem. Moshi’s working thesis is that solving the recommendation problem and the interface problem are closely linked, and that the real challenge in a world where everyone can build software is making it something people actually use.
Trust, Noise, and Conflicting Sources
On the buy side, the first question is whether a platform is looking at the firm’s own data. Alternative data sources like the Twitter firehose, which cost hundreds of thousands of dollars a month, are noisy, and people sometimes manipulate markets with posts. Moshi’s approach is to identify trusted voices, such as suppliers, LNG facilities, and industry participants who post status updates, and then attach a confidence score that places any single claim against everything else happening around it.
Disagreement between sources is treated as information rather than error. When Reuters, Bloomberg, and the Wall Street Journal report different things about the same event, that divergence can itself signal an opportunity.
For private data, messy PDFs are processed by a vision language model that Moshi built. The bigger question is whether to build that capability in-house or rely on a third-party vendor. Her position is that sending client data to outside processors creates a privacy problem, so the terms of any agreement matter. Whether to build or buy depends on the team: a company with strong engineers can and should build the models, while a smaller team may be better served by a vendor.
AI Engineers as the Whole Team
The conversation turns to the pressure on AI engineers to become the entire team. Many people she meets are being told that they no longer need a team because they are the team, even though the system they are now expected to build would once have taken ten people. Some engineers ask whether they need a swarm of agents, and what happens when something breaks. She also notes a common frustration: a builder creates a tool, people say they need it, and then no one clicks it.
Conference Outcomes and the Case for Structured Meetings
The talk generated more inbound interest than expected, especially for a finance-focused session at a general AI conference. The audience included traders at funds, consultants, and AI engineers, and the response was strong enough that Sokhal extended her stay in New York to keep meeting people, with a full week of follow-up meetings, including some in Houston for energy-focused prospects.
From this came an idea she is considering: a round-table format modeled on investor relations days in finance, where a company meets five funds at once, or a conference-hosted room where attendees book short slots, perhaps 30 minutes each, with speakers. The format would reduce travel and lost time for both sides, and pre-assigned rooms with dynamic allocation could make it work. Her team is also moving some of this to webinars because one-on-one calls cannot keep up with inbound volume.
Hiring Versus Selling
Her current priority is meeting clients rather than hiring. Hiring inbound is overwhelming: a single LinkedIn posting drew about 2,500 applicants in four days. Much of that volume is noise, including people who are not legally eligible to work and candidates who are simply shopping or gathering information. Finding someone who both has the problem and is ready to buy is harder than it sounds, and she has not yet found anyone who has done both well.
The conversation ends with the host’s own move from hedge funds into AI. He left the hedge fund world, moved into tech, and then made a fast pivot as the AI wave arrived, creating the AI Engineer conference and its media work. Sokhal says she misses trading a little, but the work is more fulfilling because it puts her in contact with people rather than in front of a screen.