Building a Reliable Order Placement Workflow

Order placement looks simple from the outside: a strategy decides to buy or sell, the application sends a request, and the broker processes it.

In real trading software, that is only one part of the workflow. A reliable order system must validate the request, apply risk rules, submit it correctly, record the response and continue tracking the order until its state is understood.

This matters because communication can fail at inconvenient points. An application may lose its connection after sending a request, receive a rejection, or restart while an order is still active.

Start With an Order Intent

Before an order reaches a broker, the system should have a clear representation of what it intends to do.

An order intent may contain:

• Strategy identifier
• Instrument
• Buy or sell direction
• Quantity
• Order type
• Price parameters where applicable
• Product or account information
• Risk context
• Unique internal identifier

The exact fields depend on the trading system and broker.

The important point is that the application should know what it intended to submit before it sends the request.

Validate the Order Before Submission

Validation prevents obviously incorrect requests from reaching the broker.

Instrument Validation

The instrument should exist and be tradable according to the application's available reference data.

The system should avoid relying on manually typed symbols when a controlled instrument mapping is available.

Quantity Validation

The requested quantity should be checked against the application's configured rules and the relevant market or broker constraints.

Price Validation

For order types that require a price, the value should be checked for correct format and valid constraints.

Account and Permission Checks

The application should verify that the selected account and trading permissions are appropriate for the requested action.

Apply Risk Approval

Validation asks whether an order is structurally acceptable. Risk approval asks whether the order is allowed by the application's trading rules.

Examples may include:

• Maximum position size
• Maximum order quantity
• Strategy-level exposure limits
• Account-level exposure limits
• Daily loss controls configured by the business
• Instrument restrictions
• Duplicate-order checks

These controls should be explicit rather than hidden inside unrelated code.

Risk Checks Are Not Profit Controls

A risk check does not make a strategy profitable. It is a control designed to restrict certain actions according to defined rules.

Trading software, regardless of its workflow quality, cannot guarantee profits or eliminate market risk.

Generate a Unique Order Reference

Each order intent should have a unique internal identifier.

For example:

`STRATEGY-A-20260820-000125`

The actual format can be different, but the purpose is the same: allow the application to identify one intended action throughout its lifecycle.

This becomes particularly useful when the application needs to investigate a timeout or reconcile broker state.

Submit the Order

After validation and risk approval, the system can submit the order through the supported broker API.

The submission layer should record important information such as:

• Internal order identifier
• Submission time
• Broker request identifier when available
• Instrument
• Side
• Quantity
• Order type
• Initial response
• Error information where applicable

Sensitive authentication information should not be written into ordinary logs.

Understand the Acknowledgement

One of the most common mistakes is assuming that a successful API response means the order is fully complete.

An acknowledgement may only indicate that the broker accepted the request for further processing.

Depending on the broker and order type, the order may later be:

• Rejected
• Pending
• Partially filled
• Filled
• Cancelled
• Modified
• In another broker-defined state

The application should track the lifecycle using the statuses actually provided by the broker.

Track Order Status

Order tracking can happen through polling, streaming events or a combination of both.

A streaming event may provide a quick update, while a later status query can help confirm current broker state.

The application should store status changes with timestamps and relevant identifiers.

Why Status History Helps

Suppose a user asks why an order was not filled. A status history can show:

1. Order intent created.
2. Validation passed.
3. Risk checks passed.
4. Broker submission attempted.
5. Broker acknowledgement received.
6. Order remained pending.
7. Later status changed or the order was cancelled.

Without this history, troubleshooting becomes guesswork.

Handle Timeouts Carefully

A timeout is one of the most dangerous situations for order logic.

Imagine the application sends an order request. The network connection times out before the response reaches the application.

There are two possibilities:

• The broker did not receive the order.
• The broker received and processed the order, but the response was lost.

Blindly submitting the order again can therefore create a duplicate.

Reconcile Before Retrying

A safer pattern is:

1. Record the original order intent.
2. Detect the timeout.
3. Query or reconcile broker state using available identifiers.
4. Determine whether the original order exists.
5. Only create another submission if the system has sufficient evidence that another order is required.

The exact mechanism depends on broker API capabilities.

Handle Partial Fills

Some trading systems support partial fills, where only part of the requested quantity is executed.

For example, an order for 1,000 units may have an executed quantity of 400 while 600 remains pending.

The application should distinguish between:

• Requested quantity
• Executed quantity
• Remaining quantity
• Average execution price where available
• Current order status

This is especially important when strategy logic reacts to position changes.

Reconciliation Is Essential

Local application state and broker state can diverge after failures.

Reconciliation compares the two and identifies differences.

A reconciliation process may check:

• Open orders
• Order statuses
• Executed quantities
• Open positions
• Strategy-owned orders where identifiers allow mapping

This process is useful during startup and after significant connection failures.

Logging and Auditability

Reliable order software needs useful operational records.

Logs should help answer:

• What did the strategy request?
• Which validation rules passed or failed?
• When was the order submitted?
• What response was received?
• What happened afterwards?
• What was the final known state?

Logs should be detailed enough for troubleshooting without exposing secrets.

Common Order Workflow Mistakes

Sending Before Validation

An application should not depend entirely on broker rejection to identify invalid orders.

No Duplicate Protection

Repeated strategy evaluations or retries can create duplicate submissions.

Treating Timeouts as Rejections

A timeout means the response was not received. It does not automatically prove the broker rejected the order.

Ignoring Final State

Recording only the initial acknowledgement makes it difficult to know what actually happened.

No Restart Reconciliation

A process restart should not erase knowledge of active orders and positions.

A Practical Workflow

A strong order workflow can be structured as:

1. Create order intent.
2. Validate instrument and parameters.
3. Apply strategy and account risk rules.
4. Check for duplicates.
5. Submit to the broker.
6. Record acknowledgement or error.
7. Track status updates.
8. Reconcile uncertain states.
9. Record final outcome.
10. Update strategy and portfolio state.

The exact implementation varies by broker and business requirements, but the principle is consistent: order submission is a lifecycle, not a single API call.

Where Suyotech Fits

Suyotech Solutions develops custom trading software and broker integrations where order validation, risk controls, status tracking and reconciliation are considered as part of the overall system design.

Conclusion

A reliable order placement workflow should protect the system from more than invalid parameters. It should also handle acknowledgements, timeouts, partial fills, connection failures and differences between local and broker state.

These engineering controls do not guarantee trading performance or profits. They help make the software more predictable and easier to operate.

If you are planning a custom trading application or broker integration, contact Suyotech Solutions to discuss the required order workflow.