The following is part of a series of posts about 2026 summer intern projects—for more, see “What the interns have wrought, special jumbo 2026 edition”

Trading Desk Operations Engineers (TDOEs) keep our trading desks running smoothly. They collaborate deeply with traders, desk developers, and operations teams like finance and accounting. On a given day a TDOE might investigate an outage in a critical system, write OCaml code to automate an error-prone process, or sit with a trader to build a dashboard together. TDOEs must balance steadily making workflows and systems more resilient with the urgent needs of trading.

This summer’s internship had more projects across more teams than ever before. Each of our interns completed three trading desk projects and then spent two weeks sitting with teams including Marketdata, Metadata, and Order Engines. Their work on the desks ranged from convertible-bond trade analysis with Global Capital Markets to cash flow reconciliation for exotic options trading.

We traditionally haven’t described TDOE intern projects publicly because they often involve sensitive details about our trading systems or strategies. This year we wanted to give a flavor for the actual work that interns do during the summer, so we purposely chose projects that we could talk about. A common thread running through them is that, like most TDOE work, they involve very quickly building up an understanding of a complex domain. Interns aren’t expected to know any of this before they start—not even how to write OCaml code, and certainly nothing about trading. But very soon they find themselves driving impactful work for the trading desk.

Let’s dive deeper on a few projects.

Eagerly rectifying old-school voice trades

Some trades are still agreed upon directly between a trader and a broker through voice trading, rather than electronically via an exchange. These phone trades, known as “shows” (from the phrase “show me a market”) also unfold over IM platforms like Bloomberg IB and ICE Chat. A broker calls or IMs a Jane Street trader, the two of them agree to a trade, then the conversation ends. But how does the market know the trade happened?

Immediately after the conversation, the broker executes the trade, and sends us and the counterparty that they’re representing a receipt. We log that in our systems both for compliance reasons and so that we have an accurate picture of our trading risk. Then, sometime later, but before the end of the day, the trade gets appended anonymously to the public tape. Finally, at the end of the day we then get an official confirmation from the broker via a combination of email and IM.

In the period between our initial record and the EOD confirmation, it’s important that we have an accurate representation of what happened. Waiting to rectify a trade booked on our end as 100,000 shares, when it’s actually 10,000, would have serious implications. We also want to make sure we’re ready in the event that the external confirmation shows up later that day with discrepancies. How can we proactively figure out if we’ve made an error before the confirmation arrives?

09:39:08  BROKER_A   ACME Sep26 50c at 1.27 seller 2k
                     BETA Oct26 40p 100x  .85 / .95
09:39:21  JS_TRADER  acme bid 1.255 for half cant get higher
09:40:04  BROKER_A   done, you buy 1k acme @ 1.255
09:40:32  JS_TRADER  tyty

Sample broker conversation where only ACME trades.

Nick Pianfetti, an intern on Options, built a system that compares our internal phone trade records with public reports and flags discrepancies. This sounds simple, except that the public tape shares trades without any identifiers. So we have to comb through our trades searching for a matching public print based on the time, size, and price.

Worse, sometimes the shape of the public trade is different from what we wrote down. Let’s take the example above with ACME. This product trades in 1-cent ticks, so the price that the traders agreed to, $1.255, might actually appear on the tape as two prints: one 500x ACME $1.25 trade and another 500x ACME $1.26, where the average price matches our 1000x $1.255 trade. When this happens it’s called a split print.

Split prints are one of many reasons that two records of the same trade might look different. Understanding these situations was central to the project. Nick talked to traders placing the orders, and others who managed the positions, to ensure they were targeting the most valuable scenarios and that they’d gotten the logic right. Being in a tight loop with the desk helped them build something that fit naturally into existing workflows, and they ended up with a tool that the desk can use to get early reports of discrepancies.

Poring over exchange specifications

Exchanges have complex rules for trading, and ways of representing orders, that are described at length in natural language in specification documents. For our trading systems to use this information it has to be carefully translated into code. For instance, while two distinct exchanges may refer to the same concept with the same field name, their underlying definitions could vary, and we have to make sure not to collapse these into a single attribute in our systems. During a two-week stint on the order engines team, Nathan Zhao combed through exchange documentation to enable trading on an attribute that we hadn’t yet encoded.

The attribute was for an order type called a “Primary Peg”, offered by MEMX and IEX but defined differently by each. Nathan reviewed rulebooks from these two exchanges and found that MEMX describes its primary peg as “an order with instructions to peg to the NBB [national best bid], for a buy order, or the NBO [national best offer], for a sell order”¹. IEX, meanwhile, defines it as “one (1) MPV [minimum price variation] less aggressive than the primary quote (i.e., the NBB for buy orders and NBO for sell orders) while resting, and available for execution against opposing orders to its discretionary price (i.e., from the resting price to the primary quote)”².

Huh?

Translated, this means that suppose the best bid is $10.10 and the minimum price increment is one cent. On MEMX, a primary pegged buy order without an offset rests at $10.10. On IEX, the exchange prices it at $10.09, one tick below the best bid, and may exercise discretion to trade at $10.10.

We hadn’t yet been trading this order type, in part because of the discrepant definitions. In just two weeks, Nathan had to carefully analyze the exchange specifications, implement the attribute in OCaml and FIX (a standard protocol for market data), then run extensive tests to verify their revisions. This sort of sprint from a cold start is typical of TDOE projects, which often involve deep dives into something new and arcane to urgently unblock trading.

Reconciling holidays in ETF baskets

Exchange-traded funds (ETFs) trade like individual stocks, but each represents a basket of underlying securities. If some of those components cannot trade, creating or redeeming the ETF may be delayed. Agreeing to a trade that cannot settle on time is expensive.

When we place an ETF order with the fund’s issuer, we need to know which days the order can be submitted, traded, and settled. Calculating a fund closure is non-trivial because many factors feed into it. The complexity comes from the holiday calendars of each market involved in the basket and from each issuer’s rules for observing these.

Let’s take a look at an ETF tracking an emerging market index. A single share of EEM US has 1,191 constituents. These underlying products are listed across the globe on exchanges from South Korea, where there’s an annual three-day Lunar New Year market holiday thru Budapest abiding by Whit Monday. It’s possible for market holidays themselves to change with local policy. In this case, EEM has products on five continents, meaning at any given time, a subset of the constituents’ exchanges will be closed because it is outside market hours or a holiday.

EEM US — iShares MSCI Emerging Markets ETF
├── Taiwan Semiconductor (2330 TT)
│   └── TWSE → ["Lunar New Year", "Peace Memorial Day", "Dragon Boat Festival", ...]
├── Samsung Electronics (005930 KS)
│   └── KRX  → ["Lunar New Year", "Independence Movement Day", "Chuseok", ...]
└── ... 1,189 more holdings

Real ETF and constituents; abbreviated for illustration. Note the list of holidays associated with each constituent.

Chris Johnson on the ETF desk, collaborating with our London office, built a tool to consolidate closure calculations. A UI displays day-by-day over the next several weeks whether a fund is open for placement, trading, and settlement, and users can click into those days to see which rules applied. Once an ETF is highlighted, it enables the desk to drill down into fund-specific rules and an analysis of its components to decide on next steps. Getting this right involved carefully understanding the existing solutions and syncing with colleagues overseas.

The desk plans to use the tool to help decide whether to take on an order. Chris built it in Webs, a widely used internal platform combining the flexibility of spreadsheets with the rigor of strongly typed functional programming. Webs can have a steep learning curve but is one of the tools that interns learn in their initial two-week bootcamp. What’s nice about it is that, like in Excel, rules are end-user editable, so new cases are easy to handle without modifying the code.

Looking forward to next summer…

If you’re interested in doing work like this, consider applying! You can find more details about our internships here: Jane Street Internships. Applications for our 2027 Summer internship are now open! Apply for: New York, Hong Kong, London.