Order Management System

For basic trading, your broker's platform (IG, Saxo, Trading 212, etc.) serves as your OMS - it handles orders, tracks positions, and maintains records. A separate OMS becomes valuable when you need: automation (strategies that place orders), multi-broker trading, advanced execution algorithms, or custom risk controls. Start with broker tools, add a custom OMS as your needs grow.

If detected before submission (by OMS validation), the order is rejected with an error message. If sent to exchange with wrong details: wrong symbol means you buy/sell the wrong stock, wrong quantity means over/under exposure, wrong price might result in no fill (limit too far) or poor fill (market order). Always double-check before confirming. Use OMS validation to catch errors automatically.

Common rejection reasons: insufficient margin (need more funds), price outside the exchange's price bands (price too far from the last trade), invalid quantity (e.g. not a whole number of contracts, or below the minimum dealing size), market closed (tried to place during non-trading hours), symbol suspended (instrument temporarily not tradeable). Check the rejection message for the specific reason. Address the issue and retry.

Check order status in your broker platform or OMS. Status 'Complete' or 'Filled' means fully executed. 'Partially Filled' means some quantity filled. You'll also see the fill price and time. Position will update to reflect new holding. Good brokers also send notifications (app push, SMS) on fills. Don't rely on memory - always verify status.

Modifying changes order parameters (price, quantity) while keeping it active. Useful when market moved and you want to adjust your limit price. Cancelling removes the order entirely - it won't execute. Use cancel when you no longer want the trade at all. Some orders can't be modified (market orders in progress), and you can only modify pending orders, not filled ones.

GTC (Good Till Cancelled) orders stay active until filled or cancelled (often up to a year). Place a GTC order with your trigger/limit price and details. When the market price reaches the level, the order activates. For an OCO-style exit, place two GTC orders - one target (sell if the price rises to X) and one stop (sell if the price falls to Y). Remember to cancel the other manually if one triggers, as a plain GTC has no built-in OCO linkage (though many UK platforms offer OCO directly).

High volatility means larger price swings and potential slippage. Strategies: Use limit orders instead of market to control price, but accept they might not fill. Use smaller position sizes (normal market impact is amplified). Avoid immediate order placement after major news - wait for initial volatility to settle. Have wider stops to avoid being stopped out by noise. Consider using TWAP to spread execution. Most importantly, be prepared for worse fills than normal.

Daily process: Export positions from each broker (API or manual download). Import into central spreadsheet or database. Aggregate by symbol to get net position across brokers. Compare with your OMS records. Investigate discrepancies. For automation: use each broker's API to fetch positions, aggregate in code, compare with OMS, generate exception report. Consider using portfolio management tools that aggregate across brokers automatically.

Corporate actions change position quantity and/or cost basis. Split: quantity multiplies, cost per share divides. A 2:1 split doubles shares and halves cost. Scrip (bonus) issue: additional shares added at no cost, average cost decreases. Dividend: No position change, but P&L affected. Your OMS should either auto-adjust based on corporate action calendar, or alert you to make manual adjustments. Verify against broker records after any corporate action - they're the source of truth.

A stop (market) order triggers a market order when the stop price is hit - you definitely exit, but at whatever price is available (it may slip in fast markets). A stop-limit order triggers a limit order - you control the maximum slippage, but might not exit if the price moves too fast. Use a stop (market) when exit is critical (protecting against a big loss) and you accept slippage. Use a stop-limit when you're willing to risk not filling to avoid a bad price. For volatile shares or important stops, a stop (market) - or a guaranteed stop - is usually safer.

Smart Order Routing (SOR) selects the optimal execution venue based on price, liquidity and costs. Implementation: maintain connections to multiple UK broker APIs. Before order submission, query the order book/last price from each broker's feed. Compare the best bid/ask across venues. Factor in: commission differences, venue preference (LSE vs Cboe Europe and other MTFs), execution probability. Route to the best venue. For partial fills, consider continuing on the same venue or re-routing the remainder. Build an abstraction layer so the core OMS doesn't change when adding or removing brokers. Monitor execution quality to calibrate routing decisions.

High-throughput architecture: Horizontal scaling - multiple order gateway instances behind load balancer. In-memory processing - validation, risk checks in memory (Redis/Aerospike), not database. Async processing - log to queue (Kafka), persist asynchronously. Connection pooling - maintain persistent connections to brokers. Batch where possible - combine multiple orders in single API call if broker supports. Measure and optimize - profile every component, eliminate bottlenecks. Typical stack: Rust/C++ for latency-critical paths, Kafka for event streaming, Redis for real-time state, TimescaleDB for historical data.

Integration architecture: Pre-trade integration - OMS calls risk system before every order. Risk system evaluates position limits, margin, portfolio impact, returns approve/reject with reason. Must be synchronous and fast (<5ms). Real-time integration - risk system subscribes to all fill events from OMS, maintains shadow positions, monitors against limits, can send 'reduce position' or 'kill' commands back to OMS. Post-trade - risk system receives end-of-day positions, performs reconciliation, calculates VaR/Greeks for overnight risk. Use message queue (Kafka) for loose coupling but ensure critical paths are synchronous for real-time control.

UK requirements for algorithmic trading (MiFID II / RTS 6, enforced by the FCA): Notification - the firm must notify the FCA and each trading venue that it engages in algorithmic trading (there is no per-algorithm 'exchange approval' as in some markets, but venues require conformance testing). Algorithm inventory and flagging - maintain a documented inventory of algorithms and tag orders with algorithm, investment-decision and execution identifiers (RTS 24). Order-to-trade ratio monitoring - venues monitor excessive messaging. Audit trail - complete, time-sequenced records of all orders, modifications and decisions, retained at least 5 years. Kill switch - a mandatory ability to halt all trading and cancel open orders immediately. Pre- and post-trade risk controls - position/notional limits, price and fat-finger checks, throttles. Annual self-assessment and validation of the algo-trading arrangements. Capacity planning - ensure the system handles peak load. Implement all of these in the OMS and keep documentation for FCA queries.

Idempotency ensures same request produces same result regardless of how many times sent. Implementation: Client assigns unique idempotency key to each order request. OMS stores key with order record. On receiving request, OMS checks if key exists. If exists, return existing order status (don't create new order). If not, process normally and store key. Key storage should be fast (Redis) with TTL (24 hours typical). For crash recovery, ensure key is stored before order submission. Handle edge cases: order created but not submitted (network failure) - use transaction or two-phase approach. Test with deliberately duplicated requests to verify behavior.