Order Management System

For basic trading, your broker's platform (Tiger Brokers, moomoo, POEMS, 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 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 circuit limits (price too far from last trade), invalid quantity (not multiple of lot size), market closed (tried to place during non-trading hours), symbol suspended (stock temporarily not tradeable). Check the rejection message for 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.

Good-Till-Cancelled (GTC) and Good-Till-Date (GTD) conditional orders stay active until filled, cancelled or the set date. Place the order with a trigger price and the order details; when the market hits the trigger, the order activates. For an OCO-style exit, place two conditional orders - one target (sell if price rises to X) and one stop (sell if price falls to Y) - and remember to cancel the other manually if one triggers, unless your broker supports built-in OCO linkage.

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. 2:1 split doubles shares, halves cost. Bonus: Additional shares added at zero 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.

SL-M (Stop Loss Market) triggers a market order when stop price is hit - you definitely exit, but at whatever price is available (might slip in fast markets). SL-L (Stop Loss Limit) triggers a limit order - you control maximum slippage, but might not exit if price moves too fast. Use SL-M when exit is critical (protecting against big loss) and you accept slippage. Use SL-L when you're willing to risk not filling to avoid bad price. For volatile stocks or important stop losses, SL-M is usually safer.

Smart Order Routing (SOR) selects optimal execution venue based on price, liquidity, and costs. Implementation: Maintain connections to multiple broker APIs. Before order submission, query order book/LTP from each broker's feed. Compare best bid/ask across venues. Factor in: commission differences, venue/route preference, execution probability. Route to best venue. For partial fills, consider continuing on same venue or re-routing remainder. Build abstraction layer so core OMS doesn't change when adding/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.

SGX and MAS expectations for algorithmic trading: Pre-trade risk controls - mandatory limits (price, quantity, value, position) enforced before orders reach the market. Member due diligence and testing - algorithms and systems must be tested and controlled by the trading member before production use. Client/account identification - orders tagged to the correct CDP / trading account. DMA controls - direct or sponsored access must run through registered member access with appropriate identifiers. Order-to-trade ratio - SGX monitors excessive order activity relative to trades. Audit trail - complete logs of algo decisions and orders, retained per MAS rules (at least 5 years). Kill switch - the ability to halt automated trading immediately. Access security - strong authentication for system access. Periodic review and audit of algorithmic systems, plus capacity planning for peak load. Build these into the OMS and keep documentation for regulatory 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.