Execution: Trader Workflow
One team blotter.
Ingest orders. Execute across venues.
A shared blotter for the whole desk. Receive orders from PMs or internal systems, route across venues, and see every execution in one view. Built for teams that run multi-strategy flow.
The case for automation
Automated flow frees traders
for the trades that matter.
The economic logic behind workflow automation in fixed-income trading is straightforward: if a large portion of ticket volume can be handled systematically, the desk can concentrate its attention and expertise on the block trades where human judgement genuinely adds value. The efficiency gains compound, in time, in error reduction, and in best-execution quality on the tickets that most need it.
The problem
Orders arrive in six formats.
The desk manages four separate UIs.
The real cost of fragmented execution shows up on the desk every day. Orders arrive from PMs as chat messages, spreadsheet drops, OMS stagings, and emailed lists, each in a different format, each requiring manual re-entry. Traders manage four venue UIs simultaneously, with status scattered across four separate blotters. PMs monitor fills by contacting the desk directly. Middle office reconciles it all at end of day. Every hand-off is a rekey, every rekey is a potential error, and none of it is visible to the people who need it. A unified team blotter resolves this: one queue, one execution view, one source of truth.
The desk, operating as a team.
Four capabilities that turn individual trader workflows into a coordinated team operation.
Blotter ingest
Orders arrive from any upstream source, OMS feed, API drop, spreadsheet paste, or direct PM entry, and land normalised in one shared queue. Every want is captured once, ready to work.
OMS · API · NORMALISED
Unified execution view
Every open order, every venue touched, every fill, in one view across the desk. Traders see what colleagues are working; PMs see their own flow without chasing.
SHARED · REAL-TIME
Delegated trader actions
Orders can be claimed, reassigned, or worked jointly. Actions are attributed, who routed what, who amended what, when, so the audit trail remains clean regardless of execution volume.
ATTRIBUTED
PM read-through
PMs see live progress on their own orders without contacting the desk. Allocations push back through the OMS feed in near-real-time, the front-to-middle hand-off is continuous.
PM VIEW · ALLOCATIONS
BUY 5,000,000 USD XYZ 4.875% 31
One ticket, one record
A single ticket spanning every venue touched.
A multi-venue order on the team blotter resolves to a single parent ticket with child fills attributed to the venues that worked them. Compliance, middle office, and the PM all see the same record, reconciled automatically.
The sample ticket opposite shows an anonymised parent record from the production blotter, with fills aggregated across a CLOB and two RFQ counterparties on a single corporate-bond order.
How it integrates
OMS feed or API, fills land back in near-real-time.
The team blotter integrates with your existing OMS over a staged-order feed, or directly via the EMS Client API for automated flows. Incoming orders inherit PM identity, compliance tags, and allocation templates from the upstream system.
Fills and allocations flow back through the same channel in near-real-time, updated continuously through the trading day.
Can the desk run without an OMS? +
Yes. PM accounts have native blotter access, they can stage orders directly, see fills, and receive allocations without an OMS layer in between.
How are trader actions audited? +
Every claim, reassignment, amendment, and routing decision is attributed to a named user with timestamp. The audit log is queryable in real time and exports under the same MiFID II framework as the routing trail.
What about chat-based wants from PMs? +
PMs can drop wants via the integrated message channel; traders accept them into the blotter with one action. The original message is linked to the order for full provenance.