Systems and Platforms on a Trading Desk

Walk onto a trading floor and you see screens, terminals, and a hum of activity. What you cannot immediately see is the technology architecture underneath — dozens of interconnected systems, each serving a specific purpose, exchanging data through a network of interfaces. Understanding this architecture is essential for anyone working in a markets business, whether in front office, risk, operations, or technology.

The systems on a trading desk can be grouped into three broad layers: front office, middle office, and back office. Each layer has distinct functions, distinct users, and distinct data flows.

Bloomberg Terminal. Bloomberg is the financial data and analytics platform used by virtually every markets professional globally. On a trading desk, Bloomberg serves several functions: it provides real-time market data (prices, yields, spreads), news feeds, financial analysis tools (the famous Bloomberg functions — SWPM for swaps pricing, YAS for bond analytics, OVML for options), and messaging via Bloomberg IB Chat. Bloomberg also provides an execution venue through BLOOMBERG MTF, and its data underpins many bank pricing models and valuations. The annual cost per terminal is approximately $25,000, making it the most expensive single subscription in a markets business.

Electronic trading platforms. Different asset classes have different electronic execution platforms. In rates, major platforms include Tradeweb and Bloomberg's own e-trading system. In FX, platforms such as FXall, 360T, and EBS handle electronic execution. In credit, MarketAxess dominates electronic bond trading. In equities, dark pools, lit order books on exchanges, and algorithmic execution platforms are all used. Each of these platforms feeds execution data back into the bank's order management and trade capture systems.

Order Management Systems (OMS). An OMS is the system through which orders are managed, executed, and allocated. For equity trading, platforms like Fidessa (now ION Trading) or Bloomberg AIM are widely used. The OMS captures the order, routes it to the appropriate execution venue, and records the fill. For derivatives, the OMS may be part of a broader trading system or a separate module within the bank's primary platform.

In-house trading systems and pricing engines. Many banks build proprietary trading systems on top of commercial platforms. A rates trading desk might have a custom pricing engine that pulls yield curve data from Bloomberg, applies the bank's own calibrated models, and produces a live price for any given swap structure. These systems are often maintained by the bank's quantitative research and technology teams, and represent a significant competitive advantage.

The middle office sits between the trading desk and the back office. Its primary role is independent risk management — computing and monitoring the risks in the trading book, separate from the traders who are taking those risks.

MUREX. MUREX MX.3 is one of the most widely used integrated trading and risk management platforms in global banking. It handles trade capture, pricing, risk calculation (Greeks, VaR, sensitivities), P&L computation, and some settlement workflows, all within a single integrated system. MUREX is particularly dominant in rates, credit, and cross-asset derivatives. A typical MUREX implementation at a major bank runs tens of thousands of trades and processes nightly risk batches that produce the next morning's risk and P&L reports. Implementation is expensive and complex — major MUREX programmes can run to hundreds of millions of pounds and take several years.

Calypso. Calypso Technology (now part of Broadridge) serves a similar function to MUREX, with particular strength in collateral management and securities finance. Many banks run both MUREX and Calypso across different business lines, which creates integration challenges — trades booked in MUREX must be reflected in the Calypso collateral management module, for example.

Risk systems. In addition to MUREX and Calypso, banks typically run dedicated risk management systems for market risk calculations. These compute Value at Risk (VaR), Stressed VaR, Expected Shortfall, and sensitivities across the entire trading book. Some banks use vendor systems such as Openlink Findur or Numerix; others have built proprietary risk platforms. The risk system feeds the daily risk reports reviewed by traders, risk managers, senior management, and regulators.

Margin systems. Calculating and managing margin calls — both for CCPs and bilateral counterparties — requires dedicated margin management systems. ACADIA (now part of AcadiaSoft) is widely used for bilateral margin. For CCP margin, the CCP's own systems publish daily margin requirements, which the bank's internal systems must reconcile and process.

The back office handles the settlement, confirmation, reconciliation, and regulatory reporting of trades after they are booked. This layer interacts most directly with the external financial market infrastructure — custodians, CCPs, and correspondent banks.

Settlement systems. Back office settlement systems generate the SWIFT messages and settlement instructions sent to custodians and correspondent banks. In many banks, the settlement workflow runs through the same MUREX or Calypso platform used in the middle office, with the settlement module generating instructions automatically from the trade booking. In others, a separate settlement system such as Broadridge's BPS (Brokerage Processing Services) handles settlement.

SWIFT connectivity. SWIFT connectivity is essential for communicating with the global banking system. Banks connect to the SWIFT network through their own SWIFT bureau or a shared service provider. SWIFT messages — MT202 for cash payments, MT54x for securities settlements — are generated by the settlement system and routed through the SWIFT interface to correspondent banks and custodians.

Reconciliation platforms. Dedicated reconciliation systems such as SmartStream TLM or Broadridge Gloss handle the automated matching and reconciliation of internal records against external statements. These systems ingest SWIFT MT940/950 nostro statements, CSD statements, and CCP reports, and match them against the bank's internal position records. Breaks are flagged automatically and routed to the appropriate team for investigation.

Straight-through processing (STP) — the automated flow of a trade from execution through confirmation, clearing, and settlement without manual intervention — is the holy grail of trading operations. STP rates measure what percentage of trades flow through this entire process without requiring a human to intervene and fix something.

Low STP rates indicate a fragmented system architecture: interfaces that break, data formats that do not match, validation rules that reject trades, or static data (counterparty SSIs, product definitions) that is incomplete. High STP rates — typically 90%+ for vanilla products — reduce operational cost, reduce operational risk, and enable faster settlement.

The critical enabler of high STP rates is clean, consistent static data. If a counterparty's settlement instructions (SSIs) are out of date in the settlement system, every trade with that counterparty will require manual intervention. If a product definition in the trade capture system does not match the CCP's acceptance criteria, every trade in that product will be rejected. Static data management — maintaining the reference data that drives automated processing — is one of the least glamorous but most important functions in a markets technology team.