Trading Operations

An operations platform cannot depend on a language model being available. If the LLM is down, the trading company still has to send RFQs — so a design where the workflow waits on an API is a design that stops the business for reasons the business cannot see or fix.

All three AI touchpoints route through one call layer with a defined fallback ladder: try Anthropic, retry on Groq with JSON mode forced, and if both fail, degrade to a pre-filled manual form so the eighteen-step cycle continues. Every output is validated against a Pydantic schema before it reaches a user or a document, retrying up to three times. Token usage and confidence are logged for cost and quality tracking.

The result is that the AI is a labour saving on a process that already works without it. That is the only version of this a business can actually run on.

Import/export trading is not linear, and a system that only models the clean path quietly produces wrong numbers. Partial receipts, partial payments, several delivery challans and several invoices against one order are normal here, not exceptional.

They are all first-class flows, and the backend enforces the rules rather than trusting the interface: over-receipt is rejected, GST invoicing is blocked before delivery is confirmed, payment is blocked before CRV where the customer requires it, and vendor purchase orders are priced from the winning vendor quote rather than from the company's own selling price.

Several of those guards exist because live end-to-end testing found the gap. That is the argument for running a real order through the whole cycle before handover rather than testing the steps in isolation.

The requirement is roughly 100 to 150 concurrent users across three companies that constantly need consistent reads of shared reference data. Microservices would have bought independent scaling nobody needed and paid for it in distributed transactions across exactly the data where a trading business cannot tolerate drift.

So: one PostgreSQL database with native ACID, one deployable, and company scoping enforced server-side through a company header plus capability RBAC rather than through separate services. Adversarial testing verified fifteen of fifteen isolation and RBAC scenarios — cross-company reads return 404, a forged company header returns 403, role-action mismatches return 403.

An early version of quote extraction sent the model the document's storage key instead of the document. It returned plausible output — which is the failure mode that matters, because plausible output from a model that never saw the input is indistinguishable from working software until somebody checks a number against the source.

The fix was to pass the document text into the prompt along with the enquiry line context, so part numbers have something to match against. Live verification then extracted two vendor quotes at 0.97 to 0.99 confidence, with correct EUR and PKR totals and lead times normalised — '6 weeks' resolved to 42 days.

The lesson generalises past this project: with an LLM feature, 'it returned something' is not evidence that it read anything.