What a Trading Platform Is Actually Connected To

The terminal is a client, and the account is not inside it

The software on your machine is not where your account lives. It is a client: it signs in to a server the broker runs, and everything on the screen is a copy of what that server most recently sent it. Positions, orders, balance and history are the server’s record, and the terminal’s job is to display them and to pass instructions back.

Almost everything confusing about a trading platform follows from that division. A problem is a problem of the terminal, a problem of the server, or a problem of the link between them, and the three have different symptoms and different fixes. Knowing which one you are looking at is most of the work.

A login is three things, not two

An account number and a password are not enough to sign in. The third part is the server, because the same number can exist on more than one of a broker’s servers and mean a different account there, or no account at all. Brokers commonly run several — demo on one, live accounts on another, and sometimes separate servers for different entities or regions — so an account opened under one entity cannot be reached from a terminal pointed at another.

The server is not permanent either. Servers are consolidated, renamed and moved, and a terminal holding a cached old address goes on failing to connect while the credentials themselves are perfectly good. This is why a failed login is not evidence that a password is wrong, and why the first thing a support desk asks for is the server rather than the number.

The build on your machine is only half the software

The build running on your machine and the version running on the broker’s server are numbered independently and updated on their own schedules. Behaviour you observe is a property of that pair rather than of the platform in the abstract, which is why two people on a platform with the same name can be describing genuinely different software.

A mismatch is sometimes loud: a server can refuse a login from a terminal older than it will accept and offer an update instead. The quiet case is worse — the terminal connects, and something behaves differently. How an order type is handled, what a programming interface exposes, which settings exist at all. It is also why written instructions and screenshots go stale without anyone noticing, since the menu being described may simply not be in the build the reader has. Record the build before anything else when reporting a fault.

A connection has more than two states

Platforms report the link in more detail than an on-or-off flag, and the distinctions matter. A connection can be absent. It can be refused, because the credentials are not valid on that server — a different fault from the network being unavailable, and one that points somewhere else entirely. Or it can be established and no longer receiving updates.

That last one is the awkward case. The last price stays on the screen, so a stalled feed looks exactly like a market that has stopped moving. Nothing about the prices can tell you which you are looking at, because in both cases nothing is changing. The platform’s own connection indicator is what answers it, and it is worth knowing where that indicator sits before there is a reason to need it.

What a dark terminal does not stop

When the terminal goes quiet — closed, asleep or disconnected — the division above decides what carries on. Instructions that already reached the server are the server’s to manage: resting entry orders, and the stop and limit levels attached to open positions, go on being managed while nothing is watching.

What does not carry on is everything that was still local. An instruction that had not been sent is simply not sent. Software attached to a chart cannot act on prices it never received, so its silence during a disconnection is not a decision. Which of the two categories a given instruction falls into is a documented property of the platform and of the account, not something to be inferred from a screen — a level drawn on a chart is not by itself evidence that the server has been told about it.

A session ending is not a connection dropping

Web terminals, client portals and programming interfaces apply a session timeout: a limit on how long a signed-in session stays valid without activity. When it expires the session ends and the next action requires signing in again. It is an authentication lifetime, not a trading event — nothing on the server changes, positions stay open, and orders already accepted stay live.

It is worth separating from a lost connection, because the two look similar and mean different things. The consequences of a timeout are on the input side. A page left open can be showing figures that were true when it loaded and are not now. A key or token that has expired will have its requests refused until it is renewed. Work typed into a form can be lost when the session behind it has already ended.

What to have written down before you ask anyone

Every question above is answered by a specific pair — this terminal, that server — rather than by the platform as a category. So what is worth capturing at the moment something looks wrong is whatever identifies the pair: the server name, the build number, the time with its zone, and whatever the platform’s own log recorded, which is usually the only place a silent refusal appears at all.

The list is short and it is boring, and it is the difference between a question somebody can answer and a question that turns into an exchange of guesses. It has a second use as well: it tells you which of the three layers to ask about — your machine, the link, or the server — and those three are frequently not the same organisation’s responsibility.