Securities-Lending Trading Interface

The project started life as a v0.dev export. Someone had described the screens to a generator and got back something that looked like a trading application: the right boxes in roughly the right places, none of the behaviour underneath. My job was to turn that into something a desk could run trades through.

Securities lending is unforgiving about detail. A borrow and a loan look almost identical on screen and mean opposite things. Quantities move in round lots, so a trade for 150 shares is not a small mistake, it is an invalid trade. Everything is scoped to a DTC participant number, and picking the wrong one silently puts your trade against the wrong account. Most of the work was encoding rules like these into the interface so the screen refuses what the business would refuse.

The deal book

The central screen is a deal book: live borrows and loans, filtered by security and DTC, with proposals you can accept, counter, cancel, or rescind. Borrows sit on the left and loans on the right – a layout that came directly from watching how the desk already thought about the book, not from a design document.

Securities search hits a cached list rather than the API on every keystroke. Traders search constantly, and the round trip was slow enough to be felt.

Multiple windows

Traders work across several monitors, so the deal book opens in its own popup window. That turned the selected DTC into shared state across windows rather than component state – change it in one, every window follows, and it survives a reload through local storage. This was the part that took longest and looks like nothing in a screenshot.

Rewriting the authentication

I built token-based auth against an /auth/token endpoint in November, and replaced it with session cookies in January. The first approach was a reasonable reading of the requirements; the security review disagreed, and cookies were the right call for a financial application. The migration surfaced a reload loop that took a day to pin down – a redirect that re-triggered the check it was waiting on. Worth recording because it is the honest shape of the work: some of it is building the thing twice because the second version is correct.

The API client is generated from the backend’s OpenAPI schema, so a change on their side becomes a type error on mine instead of a runtime surprise in front of a trader.

Scope

I was one of four engineers and worked on the frontend, focusing on the deal book, the returns and recall flows, and the trading dashboard.