Eric Mannes on Turning Messy External Data Into Trading Research

Eric Mannes tells Ron that he studied mathematics and tried three paths over three undergraduate summers: research, technology and finance. Jane Street was the most interesting and the best fit. As a trading intern he was struck by how much people taught him about markets, adverse selection and research.

Eric describes markets as anti-inductive: once a useful pattern is discovered, competition can make it disappear or matter less. Traders must keep learning, and actions by other participants can change behavior in ways absent from historical data. Ron adds that competition feeds information into prices, making markets a more informative gauge of the world.

Ron asks how the internship teaches market intuition. Eric points to mock trading, where decisions have consequences but stakes are controlled. Interns use a simulated exchange in one- or two-hour scenarios that distill real trading concepts. Feedback from making a commitment is different from discussing good decisions in the abstract.

In Figgie, four players have private information about card values and trade with each other. Players watch what others do, infer what information might motivate them, and update their own decisions. It also gives practice in market-making language and deciding under uncertainty without the pressure of actual trading.

Ron observes that markets can benefit participants overall while particular trades still have an adversarial element. Eric says it matters to distinguish mutually beneficial trades from disagreements between equally capable people about a fact: in the latter case, one person is wrong, so examine why you believe you are not the one making the mistake.

After the internship Eric joined the commodities desk, where he learned about oil and natural gas ETFs and commodity-index ETFs. Unlike in the internship, he could discuss the firm's actual positions and decisions. He examined whether trades made sense and why the desk had done more or less of them.

An experienced mentor would ask Eric what the desk should do and then explain other factors behind its actual decision. Repeated examples and feedback improved his judgment. He says a newcomer can add value quickly by becoming the local expert on a small area that others have not had time to study; independence grows with experience, while seeking input remains useful.

Eric initially studied where a new generation of trading systems, roughly two orders of magnitude faster than the old ones, gained or missed opportunities. Another area was futures, their multipliers and risk. Ron notes that equities invite a simple starting calculation of price times size, but futures have more complicated conventions.

A futures contract is an agreement tied to a future benchmark or delivery. An oil contract can involve physical delivery of 1,000 barrels at Cushing, Oklahoma; cattle contracts also involve physical quantities. Jane Street generally participates financially and does not want delivery. Margin is posted, and gains or losses are credited or debited as prices move, with additional margin sometimes required.

A futures spread gives a long position in one contract and a short position in another, but the sign convention can differ between crude oil and S&P 500 spreads. Eric explains that the quoted price might be per barrel while a contract represents 1,000 barrels. Different sources may quote dollars or cents and use different multipliers; mixing them up can create a position 100 times larger or smaller than intended.

Ron says this is a metadata problem: risk controls need to understand contract details, even when outside a strategy's logic. The complexity comes from inconsistent conventions and units. A model cannot safely put an envelope around risk if it does not know what the position actually represents.

On April 20, 2020, the nearly expiring CME crude oil future settled at a negative price for one day. Storage at Cushing was filling, supply was high and pandemic-era demand was low. Eric cautions that the final settlement of the contract was positive: the negative settlement was a particular day's event, not the final delivery price.

Systems that assumed prices could only be positive could break. Ron notes that order entry might not know how to handle a negative 100% return, and Eric asks how other products should be modeled from an anomalous oil price. Their larger point is that trading requires both technology and close attention to physical details such as storage capacity.

Ron asks about Eric's technology work on the desk. Eric says developers originally concentrated on common trading infrastructure, while desks used those systems. Over time the firm built desk-specific tools and embedded developers. Eric, who had a technical internship and learned OCaml in boot camp, helped the commodities desk articulate what it needed.

A risk system needed to move between aggregate energy exposure, oil-related products, West Texas Intermediate and individual contracts, and explain where exposure came from. Previously a large Excel workbook pulled trades and positions and calculated the numbers. It could be slow and had grown over time; rebuilding from sound foundations made more ambitious work possible.

Both speakers praise Excel's flexibility and ability to put data in view. Eric calls spreadsheet formulas perhaps the world's most widely used functional programming language, now with lambdas and let bindings. Unlike typical Python code, a spreadsheet foregrounds the data while hiding much of the logic.

The limitations were performance at critical moments and complexity: Visual Basic macros generated sheets, formulas and positions, effectively a program writing a program. A type-safe language, compiler checks, robust tests and interfaces can help catch mistakes. Version control, searching and large migrations were also difficult in spreadsheets.

Throwaway formulas accumulated, leaving an artifact that nobody fully understood. Replacing it required recovering its embedded domain knowledge. Eric translated between traders' understanding and an engineer's model: the sources, basic concepts and data flow needed to represent commodity risk reliably.

The exchange goes both ways. Eric says domain experts can become accustomed to painful workflows and underestimate what good software could make possible. Ron describes the need to communicate both what improvements are possible and their costs; developers can also propose better ways for the desk to work.

Eric now helps lead alternative data. On Wall Street the term usually means information used in investment that is not traditionally part of that process, such as satellite images of retail parking lots. At Jane Street, the category includes even company filings, because its traditional core was real-time market data and instrument metadata.

The firm's market-making history shaped the distinction: dedicated teams handled market data and metadata, while other external data was more fragmented. Eric saw that difficult-to-use external data was preventing the firm from finding trades. In contrast, the real-time market-data infrastructure already had substantial engineering support.

Before a central team existed, a desk might request a dataset, vendor management would buy it, and whichever developer, trader or operations engineer was available would put it in a shared filesystem or database. Different desks repeated similar work without always considering reuse across the firm or consistent data practices.

The proposed central team would source unusual datasets, build pipeline tools and maintain datasets with broad impact. Eric says the team demonstrated value incrementally: improve one basic but awkward dataset, understand its edge cases, and see researchers discover effects they had missed when it was hard to use.

Jane Street hired its first data engineer in 2023. As people saw what good data engineering enabled, demand for it grew; by the time of the conversation the team had more than 20. Ron calls this induced demand: making data easier to use encourages people to seek more of the same help.

Eric divides the work into data strategy, infrastructure and data engineering. Data strategy identifies internal needs and external sources, then obtains suitable data. Staff speak with trading desks and attend vendor conferences, sometimes holding a succession of short buyer-seller meetings arranged through data catalogs.

Buyers include hedge funds, asset managers and banks; sellers range from satellite providers and large data businesses to specialists in consumer transactions or companies with incidental data from their operations. Eric says trading applications generally seek aggregate behavior, such as spending at a retailer, rather than the identities of individual consumers, unlike some advertising uses.

Data strategy can also start from a question and ask who might possess the information, even if it is not already offered for sale. Infrastructure engineers build ingestion, transformation and monitoring tools. Data engineers use those tools to produce reliable datasets, learning how sources are produced, what they represent and how trading or research will use them.

Ron asks how much of a pipeline is mechanical. Eric says the team tries to automate that part; the hard work includes discovering what each field means. Company financial statements are familiar data, but converting filings and announcements into useful rows requires decisions about company identity, reporting periods and securities.

Some dual-listed structures contain formally separate companies with common management and agreements that make ownership economically equivalent. Does a record refer to one company or both? Does it apply to every security, a share class or one listing? Different identifiers and clearing conventions add further ambiguity.

Financial statements can also be revised, and fiscal calendars or accounting can change, making periods less comparable. A useful dataset must reflect what was knowable at each time and which features a trading application needs. Understanding the real-world entity is part of producing the table, not a detail that parsing alone resolves.

Ron returns to the famous satellite-photo example. Eric is skeptical that counting cars in Walmart parking lots is particularly good: photos can be sparse and noisy, online purchases are missed, and parking lots reveal little about New York City shoppers. Most importantly, the number of visitors is only an indirect measure of how much they spend.

Banks, card networks and firms operating card programs can have a more direct view of spending and may share anonymized or aggregated statistics. But a panel of cards is not a random sample of all US transactions. Credit-union cardholders may differ from premium cardholders, demographics can be unrepresentative, and participants can enter or leave the panel.

If total observed spending rises, one must ask whether people spent more or the panel simply gained members. Adjusting for these factors and comparing sources involves both data engineering and trading research. Eric says the engineer provides essential groundwork by understanding what the dataset reports and when.

Vendors can have missing values, incorrect calculations or transactions assigned to the wrong company or brand. They may later correct these records. That creates a causality problem: a backtest using a corrected historical dataset might use information unavailable at the time, effectively simulating a trader with a time machine.

Ron says the details matter: a purely mechanical correction may not introduce future information, but leakage can be subtle. Eric prefers vendors to preserve exactly what they delivered and when, including later revisions. Jane Street saves received data and its own receipt timestamps so it can reconstruct what was known at a given time.

Ron compares this with market data: exchange timestamps are useful but can be affected by clock synchronization or other issues, so the firm also records when data reaches its own network. Eric says precise receipt times give more confidence in historical studies than approximate timestamps.

Ron asks how AI has changed the work. Eric distinguishes better predictive models from LLMs as productivity tools. Better models increase the value of good datasets, while LLMs make it easier to extract structured features from text that previously required manual work or brittle patterns.

There is a causality issue with text extraction too: a modern LLM may know what happened later, or have seen later financial statements during training. Using it to process historical text can inadvertently bring future knowledge into a backtest. Both speakers treat that as a serious complication rather than assuming extracted features are automatically safe.

LLMs can help data engineers write code and perform analysis when the engineers know the goal and can judge the output. They also make bad code easy to generate. Eric warns that producing something can create the false impression that a problem is solved even when it was not understood.

More capable models can learn features that once required handcrafting, but Eric argues that cleaning data becomes more valuable, not less. Future leakage, outliers and unusual patches can mislead or affect models differently. Human judgment remains important for deciding what to build and verifying the result, even as execution becomes faster.

On build versus buy, Eric says the team uses external tools where they fit. dbt describes and orchestrates warehouse transformations in a reviewable, testable and composable way, breaking down unwieldy SQL. Trino is the query engine, and Python tools help process tabular data.

The firm also builds its own systems. It already operated on-premises data centers for low-latency trading, where proximity to exchanges and control over hardware, multicast and FPGAs matter. Ron says cloud offers other benefits and the firm uses both; a firm starting entirely in the cloud might choose different tools.

The alternative-data team uses the firm's existing Superstore warehouse, which was not built primarily for it. Eric values having large volumes of trading and other data in one place and joining it to internal services. He and Ron say their workload's economics differ from cloud pricing based on data read or compute time.

Ron emphasizes the practical effect of pricing: applying cloud rates to their workloads would give a strong incentive to spend time shaping and reducing queries. Eric says the team still considers Trino and warehouse performance, but in its setup spends less time optimizing the bill. This is their assessment for their workload, not a universal claim about every deployment.

On hiring, Eric values curiosity and a careful investigative process. Data engineers encounter unfamiliar industries, trading practices and messy datasets, and must enjoy learning the details while distinguishing what they know from what remains uncertain. Science and social-science experience with real-world data can be relevant.

Engineering skills matter as well: pipelines are software and should be clear, correct and maintainable. Eric says systems complexity may be lower than in some software engineering roles, but data and business complexity remain high. Candidates can come from finance, research or smaller companies where they combined business context and data work.

At the time of the interview, hires have been experienced. Eric and Ron discuss a planned internship pipeline: interviews in 2026 for summer 2027, potential graduates starting in 2028 and becoming fully productive later. For this role they prioritize excitement about understanding data; people most interested in models or scalable systems may be better suited to other roles.

Their data investigation interviews give candidates an unfamiliar dataset and ask them to understand and use it. Eric looks for careful attention to details, explicit assumptions and ways to test them, rather than code written with only a hope that it works. Ron connects this back to understanding the real world underneath the data.