Trade Document Intelligence
Trade-confirmation field extraction and an SOP retrieval assistant for back-office operations.
13 fields per confirmation · 8 SOPs indexed
The problem
Middle-office operators spend a lot of their day on two repetitive tasks: pulling structured fields out of broker trade-confirmation tickets, and looking up the right SOP for an exception (failed settlement, NAV break, pricing override). Both are great candidates for automation — but most teams jump straight to an LLM for a job that simpler tools can do first. This is the boring-first version: deterministic extraction over confirmations, classical retrieval over the SOP library, with a clean upgrade path to an LLM where it actually earns its cost.
Who this is for
Fund operations / middle-office engineers, AI builders embedded with finance teams, anyone evaluating where deterministic tooling vs LLMs should sit in a back-office workflow.
Architecture
- Trade-confirmation parser
- POST /api/documents/extract — regex field extraction over broker trade confirmations (broker, account, trade/settlement date, side, quantity, ticker, price, gross, commission, net, currency).
- SOP retrieval assistant
- POST /api/documents/ask — TF-IDF over the firm's SOP corpus (settlement fails, NAV reconciliation, corporate actions, cash sweeps, pricing exceptions, month-end close, wire authorization, account onboarding).
- Sample corpus
- Three representative trade confirmations and eight SOPs ship with the demo so anyone can hit /extract and /ask without uploading data.
- FastAPI + Next.js
- Backend on port 13001, frontend at ops.djkimlab.com/documents.
Request / data flow
- 01Operator pastes (or uploads) a trade confirmation → /extract returns the 13 structured fields plus an extraction-coverage summary.
- 02Operator asks a free-text question — e.g. 'how do we handle a failed settlement above 1M?' → /ask ranks SOPs by TF-IDF cosine and returns the top match with grounding text.
- 03Both endpoints are deterministic and explainable — every field maps to a regex, every answer points at a specific SOP id.
Key decisions
Regex extraction before LLM extraction.
whyTrade confirmations from a given broker have a fixed shape. A regex parser ships in a day, runs in microseconds, costs nothing, and never hallucinates a CUSIP. The LLM upgrade earns its place only when broker formats fan out beyond what rules can cover.
TF-IDF retrieval before vector embeddings.
whyEight SOPs is the wrong corpus size for embeddings. TF-IDF gets near-perfect ranking with one file and zero infra. Vector store enters the picture when the SOP library crosses ~100 docs.
Ship the deterministic version first.
whyForward-deployed work lives or dies on whether the business team trusts the output today. Deterministic tools are auditable on day one; LLM components get layered in where they're worth the additional review burden.
Stack
If I rebuilt it
- ›Layer an LLM extractor as a fallback when the regex parser's coverage drops below a threshold.
- ›Expand the SOP corpus and switch retrieval to hybrid (BM25 + embeddings) once it crosses ~100 documents.
- ›Add an evaluation harness: per-broker extraction coverage and SOP retrieval precision@1 tracked over time.