How your order is routed

What actually leaves the device 

A trading platform does not send a picture of the ticket. It sends a message. When the ticket is submitted the terminal assembles a small, strictly formatted instruction carrying the instrument, the direction, the quantity, the order type, any price condition attached to it, and an identifier that will follow the instruction for the rest of its life. That message is what travels. The window on the screen stays where it is and waits to be told what happened to it.

Before the message goes anywhere the terminal checks what it can check without asking anyone: that the quantity sits within the instrument's permitted range and matches its permitted step, that a price condition is on the correct side of the current quote, that the instrument is currently open for trading. An instruction that fails one of those checks never leaves the device at all. That is why some rejections appear instantly while others take as long as a fill would have taken. The instant ones were decided locally. The slow ones travelled.

Routing is the name for everything that happens after that. It is not a component, and it is not a choice made per order by the client. It is a path: the set of systems the instruction passes through, the order in which it passes through them, and the place where it is finally matched against a price. The path is fixed by how the broker has assembled its execution architecture, and it is the same path for a small instruction as for a large one, even though what happens at the far end of it is not.

The stages, in order 

Stripped of the vendor specific names each firm gives its own components, the path has six stages. Every retail CFD instruction passes through all six, whether the broker's execution model sends it outward to a liquidity provider or matches it against the firm's own book.

1. Submission. The terminal validates locally, assembles the message and sends it over the client's own internet connection to the broker's gateway.
2. Reception and validation. The gateway authenticates the account, repeats the checks the terminal already performed, and adds the ones only the broker can perform: whether the account holds sufficient margin for the position the instruction would open, whether an instrument or account limit is breached, whether the account is permitted the instruction at all.
3. Routing decision. The instruction is directed to wherever it will be matched. Which destination that is depends on the execution model, on the instrument and on the size, which the previous lesson treated in full.
4. Matching. A counterparty commits a price against the instruction, either a liquidity provider accepting it or the firm's own book taking the other side. Where the quantity exceeds the size available at the best price, this stage produces several parts rather than one.
5. Confirmation. The venue that matched the instruction reports back the price, the quantity, the time and a reference. The broker records the deal against the account, and the position and the margin held against it change at this moment rather than at submission.
6. Reporting. The confirmation travels back over the client's connection, and the terminal updates its ticket, its position list and its log.

The fourth and fifth stages are worth holding apart, because platforms present them as one event. A fill is the moment a counterparty committed to a price. A confirmation is a message about that moment, sent afterwards, over a connection that takes time. They are the same event seen from the two ends of a wire. In the interval between them the position already exists, the margin is already committed, and nothing on the screen says so. Every complaint that a platform showed a stale position for an instant is a description of that interval rather than a fault in the platform.

The sixth stage is the one clients experience as the whole thing. It is also the only one that has to happen twice over the slowest leg of the path, once outward and once back, which is the subject of the next section.

Where the time goes 

Latency is the general word for the delay between an instruction and its effect, and it is not one quantity. Along the path above it accumulates from four separate sources, each with a different cause, and each yielding to a different remedy or to none.

• Propagation. A signal travels through fibre at a finite speed, so distance costs time. This is the only one of the four that is a physical constant rather than an engineering choice, and no amount of money spent on equipment reduces it.
• Transmission and switching. Every router, switch and firewall on the route reads the message and forwards it, and each of those steps takes a measurable interval. A path across a domestic internet connection contains many more of them than a cross connect inside a data centre.
• Queueing. At each system the instruction waits behind whatever arrived before it. This is the component that varies most, because it depends on how busy a system is at the instant the instruction reaches it rather than on how the system is built. It is longest precisely when the market is busiest, which is when the greatest number of instructions arrive at once.
• Decision. Wherever a system makes a judgement rather than passing a message onward, it spends time doing so: the margin and limit checks at the gateway, a provider's own risk check, and in some arrangements a last look window in which a matched instruction can still be declined.

The proportions matter more than the total, and on a typical retail path the proportions are lopsided. Most of the interval is spent outside the broker's infrastructure altogether, on the client's own connection into it. That is not a technicality. It is the reason two clients on the same platform and the same account terms, submitting the same instruction at the same instant from different cities on different connections, record different intervals between the press and the confirmation, without anything differing at the broker's end at all.

Read as a proportion, the block says something a duration would hide. Every improvement a broker can make applies to the middle portion, and the middle portion is the smaller one. A firm can shorten what it controls, and it controls the part between its gateway and the counterparty. It cannot shorten the leg between a phone on a mobile network and the building its servers stand in, and neither can anybody else.

Why the address of a machine matters 

Signals in fibre travel at roughly two thirds of the speed of light in vacuum. That sets a floor under the time any message can take between two points, the floor scales linearly with distance, and no engineering removes it. It is the one quantity in this lesson that is settled physics rather than a design decision, which is why infrastructure has an address at all.

Two consequences follow from that arithmetic. The first is that matching systems are placed physically close to the venues where liquidity is quoted, frequently inside the same facility, so that the leg which repeats for every instruction and every quote update is as short as the building allows. Housing equipment in the same facility as the systems it communicates with is called colocation, and it is bought for exactly one property: the distance.

The second consequence runs in the opposite direction, from the market back toward the client. Quotes arrive from providers over the same physics that instructions travel out on, so a book assembled from quotes that took longer to arrive is a book describing an earlier moment. Shortening that leg does not make a price better in any sense a client can bank. It makes the price on the screen a more recent description of the same market, which is a different claim and a smaller one.

YAL's execution infrastructure runs at Equinix LD4 in London, with under 1 ms to its liquidity sources, and the firm states an average execution speed of 19 ms. Where that infrastructure sits, and what it does and does not determine, is treated on its own later in this module.

What the platform shows, stage by stage 

The platforms YAL runs, MetaTrader 5, both expose the sequence, and both do it in the same three places under different names: a live view of working instructions and open positions, a historical record of completed ones, and a log carrying every message the terminal sent and received with a timestamp against it. The log is the part most readers never open and the only part that shows the path rather than its result.

On MetaTrader 5 an instruction acquires a ticket number once the server has accepted it. Until it is matched it sits among the working orders. Once a counterparty has committed a price, the execution is recorded as a separate object, a deal, carrying its own price, volume and time, and the exposure it produced appears as a position in its own list. That three object structure, an order then a deal then a position, is the platform keeping the instruction, the execution and the resulting exposure as three separate records instead of one, which is why an instruction filled in several parts produces one order, several deals and a single position. The terminal's journal carries the underlying messages, including the server's response when an instruction is not accepted.

An execution is reported as a notification stating the price and the quantity that were filled, working orders and open positions are held in separate tabs, and the history records each execution against its own timestamp. On the platform an instruction completed in parts records the parts, and the position's entry price is the weighted average of them rather than a price at which any single part was executed.

What neither platform shows is the middle of the path. The routing decision, the identity of the venue that matched the instruction, and the time spent at each hop are not fields in a retail terminal. What a client can read directly is a submission timestamp and an execution timestamp, and the interval between the two. What that interval does and does not evidence, and what a firm's own published measurements are measuring instead, is the subject of the next lesson.

Where practitioners disagree 

Whether the interval matters at all to a retail position is genuinely contested. One position holds that at the horizon over which most retail positions are held, a difference of milliseconds is smaller than the distance between the bid and the ask and smaller still than the movement of the market during the holding period, so it is immaterial to the result and attention spent on it is attention taken from the things that are not. The other holds that latency does not arrive uniformly: it matters exactly when the market is moving fastest, which is when a stop is triggered and when a scheduled release lands, and an average measured across a calm session conceals the sessions in which it was doing something. Both are describing the same distribution from different ends, which is why the argument does not resolve.

The second disagreement is about how a routing rule ought to rank its destinations. One tradition ranks by response time, on the argument that an instruction declined after a delay has to be worked again against a market that has moved in the meantime, so certainty of completion is worth more than a fractionally better quote. Another ranks by price, on the argument that the price improvement is measurable on every instruction while the delay is usually not measurable at all. No public standard settles the ranking, a firm's rule is a commercial arrangement rather than a published one, and the two rules produce different results in different conditions rather than one being correct.

The third disagreement is about which measurement is the honest one. A client can measure the whole round trip, terminal to terminal, and that figure includes the connection the broker does not control and cannot improve. A firm can measure from the arrival of an instruction at its gateway to the confirmation leaving it, and that figure excludes the part of the delay a client actually experiences. Each side can reasonably say the other is publishing a number that flatters it. Both are true measurements of different things, and reading either one as the other is the most common way a comparison between firms goes wrong.