Trade Request
Structured trade requests from advisors, a trader queue with a pre-approval checklist, an asset-location engine that turns each request into an execution plan, and a drift monitor that compares every account with its model portfolio.
Overview
Structured trade requests from advisors, a trader queue with a pre-approval checklist, an asset-location engine that turns each request into an execution plan, and a drift monitor that compares every account with its model portfolio.
The problem
Trade requests arrived by chat and email with missing details. Traders re-keyed them into spreadsheets, chased follow-up questions, and had no single record of who approved what and when.
What I built
- A request form that adapts to the request type and will not submit an incomplete request.
- A searchable trading queue with the status, advisor and submitter of every request.
- A pre-approval checklist and an audit trail on every request, so each approval shows what was checked and who decided.
- An asset-location engine that places cash and fixed income in the account where each is taxed least.
- A drift monitor that compares every account with its model portfolio, can rank accounts by unrealized gain so the cheapest fixes come first, and lets a trader mark known exceptions.
- A compliance PDF for every request, and a firm-wide compliance report: what was asked, what was approved and by whom.
- Domain types shared between client and server, so a renamed field fails the build on both sides.
In the app
Key decisions
Structured requests only
Free-text requests were the root problem. Each request type has its own required fields and validation.
The engine is a pure function
Asset location takes holdings and a model and returns a plan. With no database access it is simple to test against fixtures.
Approval before execution
Nothing is traded from a request directly. A trader approves a plan, and the approval is part of the record.
One deployable unit
Express serves the built React app, which keeps hosting simple and inexpensive.
Architecture
React · Vite · Express · Postgres · TypeScript · Zod
The demo
The demo runs the production app’s code on a fictional firm. The data warehouse, the model provider’s feeds and Slack are replaced by stand-ins that answer in their real formats inside the container, and every Slack message and email lands in an in-app Outbox instead of being sent. A nightly reset restores the data and replays two weeks of drift checks, so the history always looks current.
See it running
Sign in as any demo user. Nothing you do leaves the demo, and it resets every night.