# Platform and Order Execution Basics Operate a demo terminal and reconcile intended versus actual execution. Use this workbook alongside the course. Write your answers before opening the solutions. Practical work is self-reviewed; scored knowledge checks are in the Academy. ## 1. Terminal setup ### Instrument specifications Confirm the account identity before interacting with orders. Demo and funded accounts can look similar. Record the server, account label and connection status; a familiar layout is not evidence that the intended account is selected. ### Chart and account time Inspect the instrument specification for quantity units, minimum increment, trading hours and quote currency. A symbol suffix may indicate a different contract. Do not reuse a size merely because two symbols both contain the word gold. ### Demo versus live Display bid, ask and timestamps where available. A candle may represent only one price stream and may be delayed. Before practising execution, distinguish the visible chart price from the price relevant to the proposed order direction. ### Data freshness Save a simple layout with orders, positions and history visible. Analysis panels should not obscure order state. Practise finding each field while no position is open so that a later error is easier to diagnose. ### Worked example A learner switches servers and sees the same chart template. The account label now identifies a different account. The correct action is to verify identity before any order; the saved template says nothing about which account will receive it. ### Independent exercise Create a pre-order checklist containing account, instrument, quantity units, connection and quote timestamp. Explain why checking only the chart is insufficient. My inputs and assumptions: My calculation or decision: Evidence that would change my conclusion: ## 2. Order mechanics ### Market orders A market order prioritizes execution under the venue's rules, not a guaranteed price. It may fill across several prices. The quoted price seen before submission can differ from the fill because the market and available quantity change. ### Limit orders A limit order specifies a price constraint but may not fill. A touched chart price does not establish that the order reached the front of the queue or that sufficient executable quantity existed at the appropriate side. ### Stop triggers A stop typically activates another order when a defined trigger condition occurs. Trigger source and resulting order type depend on the venue or provider. Distinguish a stop trigger from a guaranteed exit and inspect the applicable rules. ### Modification and cancellation Time-in-force controls how long an order remains eligible. Cancellation and replacement are requests with acknowledgements, not instantaneous assumptions. Until a cancellation is confirmed, the original order may still execute. ### Worked example A limit order is submitted, then a cancel request is sent. An execution arrives before the cancel acknowledgement. The position exists and must be reconciled; the intention to cancel does not erase a valid intervening fill. ### Independent exercise Draw the possible states for submitted, acknowledged, partially filled, filled, cancel requested and cancelled. Include a fill arriving while cancellation is pending. My inputs and assumptions: My calculation or decision: Evidence that would change my conclusion: ## 3. Execution review ### Partial fills Review the order acknowledgement and final execution rather than inferring success from a button animation. Capture identifiers, requested size, filled size and remaining size. A rejected or partially filled order needs a different response from a complete fill. ### Slippage Positions aggregate exposure; order history describes instructions; deal or execution history records fills. Their counts need not match. One order can generate several executions, and several orders can contribute to one net position. ### Rejected orders Compare intended and actual price, quantity and timestamp. Slippage needs a specified reference price. A difference may reflect market movement, quote-side mismatch or delayed observation, so preserve the benchmark rather than assuming every difference is an error. ### Trade-history reconciliation Reconcile the resulting position and protection orders after each practice sequence. If state is uncertain, inspect the authoritative account state before sending another order. Repeating a click can duplicate exposure rather than repair the first request. ### Worked example An order requests five units and fills three. The remaining two are still working. Showing a three-unit position does not prove the order is finished; another fill could increase exposure unless the remainder is cancelled and acknowledged. ### Independent exercise Write the correct reconciliation for requested five, filled three, remaining two. State what must be checked before placing a replacement order. My inputs and assumptions: My calculation or decision: Evidence that would change my conclusion: ## 4. Failure and recovery drills ### Rejected order response A rejected order should produce a reason that can be investigated: invalid size, unavailable market, insufficient funds or another documented condition. Do not automatically increase size, remove protection or switch accounts to bypass a rejection. ### Lost connection with an open position A lost connection affects observation and control but does not necessarily close positions. Orders may remain active on the server. After reconnecting, retrieve current state and reconcile it against the last known state before acting. ### Duplicate-submit prevention Duplicate-submit prevention uses a clear pending state and, where supported, stable client identifiers. The interface should acknowledge a request without inviting repeated clicks. A retry policy must account for a request that succeeded but whose reply was lost. ### Verify server state after reconnecting Recovery begins with the authoritative account state, not a cached local display. Compare open positions, working orders and recent fills. Escalate unresolved discrepancies through the provider's official support or documented recovery process. ### Worked example An execution succeeds, but the response is lost during a connection failure. Retrying the same trade as a new request could create a second position. The missing response is uncertainty about state, not proof of failure. ### Independent exercise Write a recovery sequence for that incident with no assumption that the account is flat. Include what information must be retrieved first. My inputs and assumptions: My calculation or decision: Evidence that would change my conclusion: ## Course project Record market, limit and stop-order exercises with cancelled and rejected examples. ### Self-review rubric - Concepts and reasoning: 25% - Calculations, data and evidence: 30% - Process and risk controls: 25% - Limitations and communication: 20% Record one correction and one next practice task. This rubric is not automatically graded. ## Worked solutions ### Exercise 1 The chart can remain visually identical across accounts or stale connections. The checklist ties a proposed order to the intended account and instrument, then checks whether current information and connectivity are adequate. ### Exercise 2 Submission can lead to rejection or acknowledgement. An acknowledged order can partially or fully fill. A cancel request can end the remaining quantity only when confirmed; fills may arrive during the pending interval and must update the position. ### Exercise 3 Record three units of exposure and two units of working quantity. Check order status and any cancel acknowledgement, then calculate only the genuinely missing quantity. A new five-unit order could create excessive exposure. ### Exercise 4 Stop new submissions, reconnect through the normal channel, retrieve open positions, working orders and recent executions, match identifiers, and only then decide whether any action remains necessary. Preserve the incident record. ## Further reading - https://www.metatrader5.com/en/terminal/help/trading - https://www.cmegroup.com/education/courses/introduction-to-futures