What Happens in the Two Seconds After a Signal Posts

A provider presses send. Somewhere under two seconds later, orders exist at your broker.

Here is what fills that gap, in order, because the interesting thing about the pipeline is not that it is fast. It is which steps are worth spending time on.

Receiving the message

We hold a live connection to Telegram rather than polling for new messages. The moment a message lands in a channel you follow, it is handed to us. There is no interval to wait out.

The message goes onto a queue. A queue in the middle of a latency-sensitive path looks like a strange choice until you consider what happens without one: a provider posting five signals in ten seconds, each one triggering concurrent work on the same account, racing each other through sizing and placement. The queue makes the ordering defined. It costs almost nothing and removes a whole class of problem.

Parsing

The message is text written by a person for other people. GOLD BUY 2408-2418 SL 2395 TP1 2450 TP2 2480. Or Buy gold now around 2410, stop below 2395, targets as usual. Or a paragraph with the numbers scattered through it.

A language model fine-tuned on real signal messages extracts the structure: direction, symbol, entry or entry zone, stop, targets. Fine-tuned rather than general-purpose, because this is a narrow task with a large body of examples and a specialised model is both more accurate on it and considerably faster. A general fallback model sits behind it for anything unusual.

You can see the result. The signal view shows your original message annotated with the numbers the parser matched, so you can check what it read rather than trusting it.

Parsing is the largest single component of the elapsed time. It is worth it. The alternative is pattern matching against templates, which works on tidy messages and silently mishandles the rest.

Sanitizing

Now the part that has no business being fast and is not.

The parser has read the numbers. It has not decided whether the numbers make sense. Providers make typos, and a typo in a price is not a cosmetic error. A missing decimal turns 1.1850 into 1.0850, which is not a stop, it is a catastrophe with a decimal point.

So before anything reaches the broker, every value is checked against references we trust. Live market price is the strongest reference. Existing positions and orders on the account are next. Values in the signal that cross-validate each other come after that, and your own configured defaults last.

Each number gets scored on several questions. Is it within a sane multiple of the live market price. How far is it from the trusted references in pip terms. Is it consistent with the other numbers in this same message.

Score badly enough on any one of those, or moderately badly across several, and the value is treated as an error rather than an instruction. Depending on which value it was, the signal is rejected or the bad number is replaced from a trusted source.

This is the step I would look at hardest if I were evaluating any copier, including this one. It is also the one nobody puts on a feature list, because "we check the provider's numbers before trusting them" is not an exciting sentence. It is the difference between a tool that executes what you meant and one that executes what was typed.

There is a fixed rule underneath all of it that no configuration can override: we will not place a market order on an alert with no stop loss. Refused on the server, every time.

Routing

One signal can become several trades.

If you have three accounts assigned to the channel it came from, the router produces three separate executions, each carrying its own account, its own settings and its own sizing. They are independent from here on. One failing does not affect the others.

Sizing

For each account, volume is solved from your risk rules, that signal's own stop distance, and your account currency.

The currency conversion matters and is easy to get wrong. A dollar account trading a yen pair needs the yen pip value converted at the live rate before the volume calculation means anything.

If the signal is a layered entry, this happens per layer. Each layer gets its share of the intended risk rather than the whole of it.

Placing

Layer 1 goes in as a market order and fills immediately.

The limit orders for the deeper layers go in as well, and they are staggered rather than sent all at once. Brokers rate-limit. Firing thirty limit orders in a single burst invites partial placement and rejections, which leaves you with an entry structure full of holes. Small batches with a short pause between them complete reliably in about the same total time and without the failures.

Where the time actually goes

Roughly: parsing dominates, sanitizing is second, and everything after that is small. Routing, sizing and the arithmetic are sub-millisecond work. Placement is dominated by the round trip to the broker, which is not ours to optimise.

Which leads to the honest conclusion. Almost all of the remaining latency sits in the two steps where a machine is reading a human's message and checking whether it is sane, and those are the last two steps I would want to make faster by making them dumber.

The competitive claim people expect here is milliseconds off the entry. It is the wrong thing to optimise. Going from two seconds to one buys you a pip on a fast instrument. Failing to catch a misplaced decimal costs you a position. The gap between a copier that works and one that loses money has never been latency; it is whether the thing that arrives at your broker is the trade the provider actually described.

Related: what slippage really costs a signal follower, and how TTMT watches a trade after it's placed.

Start a free 7-day trial at telegramtometatrader.com.