Purpose of order error records

Order error records help confirm which order encountered an exception, when it happened, which user or system submitted it, which processing stage failed, why the order was rejected or failed, whether the error came from Finger Manager, a trading system, or an external institution, and whether manual handling is required.

With these records, trading operations, risk, and technical teams can troubleshoot order issues faster.

Possible error scenarios

Order error records can cover scenarios such as incomplete order parameters, incorrect product code, closed market, non-tradable product, outside trading hours, invalid price format, invalid quantity format, minimum trading unit mismatch, abnormal account status, insufficient balance or buying power, risk-check failure, insufficient permission, duplicate order, API request exception, FIX message exception, routing failure, LP or broker rejection, external trading-system timeout, execution-report parsing failure, and internal system processing exception.

Actual error types depend on the institution's trading architecture and connected systems.

Recorded information

An order error record can include error time, Order ID, Client Order ID, User ID, Account ID, Organization ID, product or Ticker, buy or sell side, order type, quantity, price, source system, order channel, error stage, Error Code, Error Message, external return code, Request ID, FIX Session, handling status, and other technical information.

These fields help technical teams reconstruct how the order moved through the system.

Error stages

Order errors can happen at different stages: order submission, parameter validation, risk check, order routing, broker or LP, exchange or execution system, and execution report.

Validation Error means the order was rejected before entering the trading flow because of parameter issues. Risk Rejected means the order did not pass risk-control rules. Routing Failed means the system could not send the order to the target channel. Execution Rejected means the order reached an external trading system but was rejected by a broker, LP, or other execution party.

Error Code

Each error type can map to a specific Error Code.

Examples include INVALID_SYMBOL for invalid product code, MARKET_CLOSED for a closed market, INSUFFICIENT_BUYING_POWER for insufficient buying power, RISK_REJECTED for risk-rule failure, INVALID_ORDER_QTY for invalid quantity, ROUTING_FAILED for routing failure, BROKER_REJECTED for external broker rejection, and TIMEOUT for external system response timeout.

The exact Error Codes depend on the institution's current system configuration and connected-system responses.

External system errors

Finger Manager can connect with brokers, LPs, exchanges, OMS platforms, and other trading systems.

Some order errors may therefore come from external trading systems rather than Finger Manager itself.

For example: Finger Trader -> Finger Manager -> FIX -> Broker -> Broker Reject. In this case, Finger Manager can record the broker's reject code and error message to help the institution confirm the error source.

FIX order errors

For orders transmitted through FIX, troubleshooting can use FIX-related information.

Records may include ClOrdID, OrigClOrdID, ExecID, MsgType, OrdStatus, ExecType, Session ID, Reject Reason, and Text.

These fields help technical teams reconcile order issues with brokers, LPs, or other counterparties.

Error query

Institutions can query order errors by time range, Order ID, Client Order ID, User ID, Account ID, Ticker, market, Error Code, error type, source system, broker or LP, and order status.

For example, administrators can query all Risk Rejected orders in the past 24 hours, or all order rejection records returned by a broker in the past hour.

Examples

Example one: a user submits a US stock order. Order ID = ORD-20260828-100821, Ticker = AAPL, Side = BUY, Quantity = 1,000. The system returns Status = Rejected, Error Code = INSUFFICIENT_BUYING_POWER, Error Message = Insufficient available buying power. This means the order was rejected because the account did not have enough available buying power.

Example two: Order ID = ORD-20260828-100932, Status = Rejected, Source = External Broker, Error Code = BROKER_REJECTED, External Code = 10017, Message = Order rejected by execution venue. This means the order was sent to the external execution system but rejected by the external trading party.

Troubleshooting

After discovering an order error, teams should first review Order ID and error time, then check Error Code and Error Message, confirm the error stage, inspect order parameters, inspect market and product status, inspect account and risk status, inspect order routing, inspect API or FIX logs, inspect broker or LP return information, and use Request ID or FIX ID for deeper tracking when needed.

By combining order error records, API logs, and system logs, institutions can reconstruct abnormal order processing more completely.

Difference from order history

Order history mainly shows what happened to an order, such as submitted, filled, cancelled, rejected, or current status.

Order error records mainly explain why an order became abnormal, including error code, error source, failure stage, external return information, and technical troubleshooting information.

Therefore, order history is suitable for business query, while order error records are more suitable for technical, trading operations, and risk investigation.

Notes

Order error records are mainly used for order exception tracking and technical troubleshooting.

Institutions can analyze order issues together with order history, API logs, FIX logs, system errors, risk-control records, and external broker or LP reports.

For errors from external trading systems, the final error definition and handling result should follow the actual return information from the relevant broker, LP, exchange, or execution system.