Order Execution

Understand the topic

An order is an instruction, while a fill is a result. Keeping that distinction clear is the starting point for explaining a trading platform. A customer can submit a valid instruction that remains unfilled, triggers a later action, executes in several pieces or is rejected under an account or instrument rule. A useful reference therefore needs more than a list of order names. It should explain the condition being requested, the information that determines the outcome and the records needed to reconstruct what happened.

The first four pages cover market, limit, stop and stop-limit orders. Each has a different relationship between immediacy, price conditions and execution uncertainty. The examples use synthetic prices to make those trade-offs visible without suggesting a trading strategy. They also distinguish common educational definitions from the exact rules of a particular venue or platform. A bid-based, ask-based or last-trade trigger can produce different outcomes, so a screenshot of one chart is not always sufficient evidence that an order should have activated.

Order lifetime and fill policy form a second layer. An instruction can specify how long it remains active, whether partial execution is acceptable and what should happen to a remaining quantity. The IOC, FOK and GTC reference separates these questions instead of treating the labels as interchangeable. The partial-fill worksheet then follows quantity and weighted price across several executions. It explains why an order identifier, a deal identifier and a position identifier should not be collapsed into one field in a support report or integration.

The price references connect the instructions to the resulting execution. Bid-ask spread measures a difference between quoted sides of a market. Slippage compares a declared reference price with actual fills. They are related costs of interacting with a market, but they are not the same measure and should not be added without checking the chosen baseline. The examples define signs, quantity units and timestamps so that a reviewer can reproduce the arithmetic and avoid counting one price difference twice.

The final diagnostic sheet addresses rejected orders. It directs the reviewer to the exact rejection response, symbol specification, account state and sequence of events before drawing a conclusion. These references can support broker training, customer explanations and platform acceptance testing. They do not establish that FxTrusts supports every order instruction on every connected platform, and they do not guarantee execution, price protection or a particular latency. Confirm available instructions and their semantics in the selected deployment, keep the source records, and use the broader platform and FIX resources when evaluating an implementation.