What a demo account is

What is actually simulated 

The word simulation is doing precise work here, and it covers exactly one thing: the fill. A demo account is normally fed the provider's own quote stream, so the prices on the chart are the prices the live desk is showing, and the instrument specifications behind them, the contract sizes, the tick sizes and the quoted hours, are read from the same specification file. What is invented is the transaction. When an order is sent, a simulation engine reads the quote at that moment, applies whatever fill rules the provider has coded, and returns a fill. No counterparty agreed to it, no liquidity was consumed, and no money moved.

Everything downstream of that invented fill is arithmetic, and the arithmetic is real. A position's profit and loss are computed by the formula established earlier in this module: the difference between the closing and opening prices, multiplied by the units the contract covers, with the sign reversed for a short. Margin is held against the position as a percentage of its face value, and the account is closed out on the same rule when the balance can no longer support what is open. Financing on positions carried past the daily cut is commonly applied as well, and where a provider charges a commission the simulator commonly deducts it. Losses in that arithmetic are calculated on the full face value rather than on the amount held against it, so they are not limited to the sum deposited, in a simulation exactly as in a live account.

What a demo reproduces faithfully 

Because the quote stream and the specification file are shared, a demo reproduces every mechanical fact about an instrument without distortion. The units one lot covers on a given symbol, what a one point move is worth on it, when it opens and closes, which order types the platform accepts and what each of them does when it triggers are identical objects in both accounts. The platform behaves identically for the same reason: a demo is not a different application, it is the same application signed in to a different account.

Two consequences follow, and they are worth stating plainly because they are the part of a demo that transfers. A calculation performed in a demo about a contract size, or about the value of a move, returns the same answer as the same calculation on a funded account, since neither of those numbers was ever simulated. And a platform mechanic worked out in a demo, where a trailing stop is configured, what a partial close leaves behind, how a pending order behaves when it expires, carries across exactly, because nothing about it was simulated in the first place.

What a simulation cannot reproduce 

Three things are missing from a demo, and none of them is an implementation detail that a better simulator would eventually fix. They are missing because the transaction did not happen.

• The order is not in the market. A live order is filled against resting interest of a finite size, so an order large relative to what is resting can exhaust the quantity available at the best price and complete at successively worse ones, and a fast market can move between the instruction leaving the platform and the fill being obtained. A simulated order consumes nothing and competes with nobody, so no simulator can report what an order would have done to the price it received.
• The fill is constructed rather than obtained. Slippage in both directions, requotes, partial fills, rejections and the gap that opens across a weekend are things that happen to an order in a market. A simulator can model some of them, and providers differ in how much of that behaviour they choose to model, but a modelled rejection is a rule somebody wrote rather than a market's refusal.
• The money is not money. A demo balance is a number that exists in one system and can be spent on nothing. A live balance was earned somewhere else and can be spent on something else. The arithmetic that moves the two is the same arithmetic; the objects being moved are not the same kind of thing, and no setting in a simulator makes them so.

The third of those is where practitioners disagree, and the disagreement is worth reporting rather than resolving. One conventional position holds that a long demo period is the responsible sequence, on the grounds that platform mistakes are expensive and a simulator is the one place they cost nothing. Another holds that the absence of consequence is precisely what makes an extended demo record unrepresentative of the account it is meant to prepare for, and that a demo period is conventionally kept short and strictly mechanical for that reason. Both positions are held by experienced traders, neither is settled by evidence this page can cite, and the two do not reconcile into a duration.

What a demo period establishes, in mechanical terms 

Stripped of what it cannot do, the list of what a demo period does establish is short, specific and entirely mechanical. Every item on it is a question with a checkable answer rather than a judgement, which is why the list can be written down at all.

• Whether the order ticket does what the person filling it in believes it does. An order sent for a size, a direction or a type other than the one intended is the commonest platform error there is, and in a simulation it shows up immediately and costs nothing to discover.
• What a symbol's contract specification actually says, and what a one point move on it works out to, read from the platform's own specification window rather than from memory or from a general rule that does not hold across asset classes.
• How the platform reports an open position: where the running profit and loss, the margin held and the free balance are displayed, and what changes on screen at the moment a stop or a limit is triggered.
• What a close-out looks like on that platform, encountered on a simulated balance rather than on a funded one, given that the rule and the arithmetic behind it are the same in both.

A journal kept through a demo period records the same fields as one kept afterwards: instrument, direction, size, the price on screen when the order was sent, the fill that came back, and the reason written down at the time rather than reconstructed later. Its value is that the record outlives the memory of the record. What it cannot do is measure a method, and the reason is the one already given: the fills inside it were computed rather than obtained.

Why a demo record says nothing about a live one 

That deserves its own statement, because it is the conclusion about demo accounts most often drawn backwards, and it runs in both directions. A profitable run on a demo is not evidence that the same decisions would have produced a profit on a funded account. A losing run on a demo is not evidence that they would have produced a loss. The reason is not caution and it is not a legal formula. It is that the two records are records of different processes: one is a sequence of fills obtained from a market, the other a sequence of fills produced by a rule, and nothing in either sequence lets one be recovered from the other.

Two further mechanisms compound it. A demo balance is set by the provider rather than by a deposit, so the size traded against it need bear no relation to any size a funded account would carry, and a profit or loss expressed as a percentage of that balance is a percentage of a number nobody chose. And a period of days or weeks contains whatever conditions those particular days contained, which is a fact about the calendar rather than about the decisions taken inside it. A demo record is a faithful record of one thing, the simulator's behaviour under a set of instructions, and it is offered here as nothing else.

Where the specifics live 

Everything above is structure, and structure is common to every simulated account. The specifics are not. A YAL demo runs on MetaTrader 5, the same platforms as a funded account, and what it includes is set out on the demo account page. How the quote stream a simulation is fed by is put together is covered in the quote feeds guide, and per instrument specifications sit on the markets pages.