Building AI tools for institutional trading

This blog post is me eating my words.

My views on the role of AI in institutional trading have changed a lot recently. When we raised our Series A back in February, our plan was to explore AI applications for the buy-side trading function, but at the time I was skeptical about LLMs playing a significant role. I wrote:

Another interesting observation is that many VCs seemed to be a little disappointed that our expansion plan was not to build an LLM-wrapper. This is again in stark contrast to the buy-side traders we deal with, most of whom agree with us that there are more suitable machine learning techniques for building quant models to automate and assist with trading workflows, and that it probably doesn’t make sense to convert numerical trading data into language and back.

Immediately after closing that round, we kicked off a design partnership where we recruited ~20 large asset managers to work closely with us. At the outset, we did not have a specific end product in mind, and the idea was just to build a much deeper understanding of their pain points and to facilitate information sharing among the group. We have since spent a great deal of time meeting with their trading teams, sitting on their desks to observe their workflows, and identifying challenges to help them navigate.

In going through this partnership, my views have completely swung to the other end of the spectrum. I’ve written about some of this journey so far: where I think LLMs fit into institutional trading and how the buy-side trader’s role might evolve. Today I come full circle and describe what we are currently working on… an LLM-wrapper for the buy-side trading function. I did go into this initiative with an open mind, and this is simply where our conversations have led. We have been impressed by the tooling at our design partners who are most ahead of the curve, which in turn has inspired us to build our own internal AI harness which I’ll describe below. Our use cases overlap with those of our clients, and it seems that many of our design partners could benefit from us packaging up our internal functionality for their use.

What hasn’t changed is the view that LLMs are not the right tool for directly crunching numbers, nor that they should necessarily play a role in the critical trading path. Rather, these are powerful productivity/dev tools that make it dramatically easier to automate both one-time and repeatable workflows. Several months after initially going down this rabbit hole, the honeymoon phase isn’t over. If anything, my enthusiasm continues to grow, and at this point, I can’t imagine taking on a serious project without leaning heavily on this toolset.

What we have built for ourselves

Over the past few months, we have been building out our internal agentic infrastructure. Given that we are a heavily regulated financial institution, we took quite a conservative stance from a governance perspective and were very thoughtful about where we hosted our setup and where our data would go. We also wanted to avoid vendor lock-in, and so we tried to set it up in a modular way: we leaned heavily on established open-source libraries, and built such that any individual component can be ripped out and replaced as needed.

How it’s built

• Agent: LangGraph and LangChain’s create_agent, with langchain-aws for Bedrock and langchain-mcp-adapters to load our MCP servers (Model Context Protocol, a standard way for AI applications to discover and call tools). We initially started on OpenClaw to get going quickly, but we soon moved to LangGraph to get tool permissions, identity, and memory handled in our own code.
• Models: models are accessed via AWS Bedrock. We like the premise of Bedrock, where frontier models from Anthropic, OpenAI, and others are hosted directly within AWS’s four walls, and queries/data are processed internally within AWS instead of being transmitted to the model providers. It provides an extra layer of comfort/protection against the model providers leaking your data (by training on it or due to a security breach).
• Tools: each data source is its own MCP server, running in its own container on AWS:
  • db: read-only SQL against our order database, with row caps and timeouts.
  • tca: execution analysis and the x-ray, built on Polars.
  • market-context: unusual-move scoring, market/sector/country decomposition, SEC filings, and calendars, on Massive market data.
  • news and web-research: headlines, search, and page text via the Brave Search API.
• Slack: Bolt for Python in Socket Mode.
• Email: AWS SES into S3, with an adapter that checks DKIM and a sender allowlist before the agent sees anything.
• Web portal: Next.js and React, with Better Auth for portal sign-in.
• Files: a sandbox container, using openpyxl, pypdf, python-docx, and reportlab to read and write spreadsheets, PDFs, and Word documents.
• Charts: Vega-Lite specs produced by tools, rendered in the browser for the portal and as PNGs (vega + resvg) for Slack and email.
• Memory and projects: a small Postgres-backed service.
• Infrastructure: AWS with CloudFormation, Docker Compose on EC2, and an allowlist proxy (Squid) for all outbound traffic. Logs and metrics go through OpenTelemetry to CloudWatch.

Example use cases

Two popular internal use cases so far are:

1. The order x-ray. We built an execution analysis engine, an order review table, and an “x-ray” view of a single order: its fills plotted against the market, limit prices and amendments, and its benchmarks. “What happened on this order?” comes up all the time on our team. Now you ask the agent in Slack or the portal, it finds the order, and its answer links straight into the x-ray.

2. Querying our trading data in plain English. Asking questions of our database — which orders, which symbols, which strategies, over what period — without writing SQL or a one-off script.

The use cases I expect to grow next are reports and alerts. We already have a lot of both in our trading platform, and this new infrastructure makes it that much easier to build new ones:

• Market context: a tool that measures how unusual a stock’s move or volume has been relative to its own history, splits the move into market, sector, and in some cases country effects, and pulls in relevant filings and headlines. We use it for single-stock questions and for briefings over a watchlist.
• Alerts: watchlist rules for unusual moves, abnormal volume, gaps, and new filings, delivered by Slack DM. The alert itself is deterministic code, and the LLM can answer follow-up questions and gather additional context.

I also want to use it for monitors, guardrails, and safety checks around our regulatory and finance functions. As a broker-dealer, we have a long list of recurring obligations and reconciliations. We have automated many of them over the years, and these tools make it much easier to build on that.

Adapting it for the buy-side desk

We are now prototyping and deploying versions of this with our first beta testers. If they have a robust existing setup, we can plug into their infrastructure via MCP, or if not, we can provide the full off-the-shelf environment. In each case, we set up an isolated instance, segregated from our internal environment and from all other clients.

The most complicated data to connect

Market data, especially real-time. We are currently using and exploring Massive, Databento, and Alpha Vantage for various historical, real-time, static, and derived data uses. The exchanges’ rules around approved usage and redistribution are complicated, and even if you already pay for real-time data via one channel, that doesn’t necessarily mean you are authorized to consume it via another.

Bloomberg. Every institutional trader uses Bloomberg, and it is one of the first things people ask about, particularly access to IB chats and permissioned data like IOIs. Bloomberg is expensive, locked down, and difficult to connect to. A Terminal subscription does not cover feeding data into a hosted AI application, and Bloomberg has many different APIs with varying costs and terms of use.

Broker research. Research is more important to the investment function than the trading function, but it is still in scope for many of our design partners. It can arrive by email, through various third-party vendor portals, or through a broker’s direct web portal. Attitudes on the sell side about what is allowed in terms of internal sharing and AI use vary widely, and many banks seem to be really tightening the screws, pushing asset managers to re-paper with costly new usage agreements.

Why work with us

Much of what I have described here isn’t so hard to replicate, and a good engineer with a coding agent could build a version of it (and we may well open-source significant portions of this). The hardest parts are the infosec requirements, the architecture, the compliance and regulatory questions, and the data licensing. We are working through all of that carefully, and bundling the data connections, skills, and use cases into a polished set of functionality that a trading desk can use off the shelf. The result is a strong starting point that doesn’t ask much of a desk’s internal tech team, works across the whole desk, and gives the firm peace of mind about how it is set up. Our team has a great deal of experience building and analyzing high performance trading algorithms, and this expertise makes us well-suited to identifying the most promising use cases and coming up with solutions.

What’s next

We are now working hand in hand with each design partner to tackle their specific use cases one by one. One of the YC mantras is to do things that don’t scale, and that is the phase we are in: deep, personal focus on each beta tester, building tools around their workflows so we can iterate and learn as quickly as possible. As we go, I plan to write more about the most compelling skills, tools, data connectors, and use cases.

If you are a buy-side trader and would like to learn more, please feel free to get in touch!