Home/Components/Notifications

Trading notifications for broker clients — one gateway, ten channels

Clients disengage outside the terminal, and the events that matter most — a margin warning, a stop-out, a completed withdrawal — happen when nobody is watching the screen. One gateway takes the trading event stream and delivers it on the channel each client reads.

Notifications are usually built the wrong way round. A broker adds a Telegram bot, a year later adds SMS, and ends up with two systems that each subscribe to the trading server, keep their own idea of who wants what, and fail silently in their own way.

The gateway inverts that. Events are produced once, by the trading environment, and delivery is a separate concern behind a common interface. A channel formats and sends; it does not know what a margin call is. Every new channel inherits the preferences, priority rules, fallbacks and delivery log that already exist.

ComponentNotification Gateway

One event stream from the trading environment: fills and closures, margin warnings and stop-outs, deposit and withdrawal state changes, price alerts, security events and campaign updates. Each event carries a type, a priority and a client.

Routing is driven by three things. Per-client preferences, held per event type, so a client can take fills in Telegram, security codes by SMS and nothing about campaigns. Priority, which sets the pattern: critical events fan out to every connected channel, transactional events go to the preferred one, marketing respects opt-ins and quiet hours. And fallback chains, which move a message on when a channel does not deliver. Every attempt is logged.

What it solves
  • Reaches clients outside the terminal, where disengagement happens
  • Margin warnings seen in time, and fewer stop-out disputes
  • Routine support questions answered before they are asked
  • One integration per channel, not one system per channel

Channels · clientsMessengers

Messengers carry the full notification set and have close to total open rates. Which to run is a question about the client base, not the technology.

Telegram

A personal bot under the broker's brand. Clients link an account with a one-tap deep link, then receive trade confirmations, margin warnings, money-operation statuses, price alerts and campaign updates where they already are.

Viber

A branded bot with the same one-tap linking and notification set, for markets where Viber is the default — Central and Eastern Europe, the CIS, Greece and the Balkans.

WhatsApp

Official WhatsApp Business Cloud API: a verified branded sender, pre-approved templates and opt-in from the client area. Replies open a service conversation support can take over — and it leads across Latin America, MENA, Asia and Africa.

What it solves
  • Regional coverage without asking clients to adopt an unfamiliar app
  • A verified business sender that unofficial channels cannot match
  • Templates keep outbound messaging disciplined and reviewable

Channels · devicesPush and SMS

These three reach the device rather than an account — the coverage floor under everything else.

Web push

Browser notifications tied to the web terminal. One permission prompt, after which alerts, margin warnings and trade events arrive on the desktop with the tab closed — no phone number, no messenger account, no per-message cost.

Mobile push

Push infrastructure for the broker's own mobile app over FCM and APNs: device registration, per-event templates, localisation and deep links into a screen. Lock-screen delivery is the fastest attention channel available.

SMS

Aggregator-backed transactional SMS, over Twilio, Vonage or local routes, for events that cannot fail to arrive: margin calls, stop-outs, withdrawal confirmations and security codes. It holds a standing place at the end of every fallback chain.

What it solves
  • Zero-friction coverage of every terminal user, no signup step
  • Free delivery on web push, and a one-click route back into the terminal
  • A last-resort channel that arrives when the others have failed

Channels · regionsLINE and Zalo

In some markets a broker that writes only by email and SMS reads as foreign.

LINE

A LINE Official Account with Messaging API delivery: account linking, the full notification set, and rich formats — buttons and carousels — for campaigns. The default messenger of Japan, Thailand and Taiwan.

Zalo

A Zalo Official Account for Vietnam, one of the largest retail FX audiences in Asia: account linking, transactional notifications and campaign messaging.

What it solves
  • The channel local clients read in Japan, Thailand, Taiwan and Vietnam
  • Rich campaign formats that work as a high-engagement marketing surface

Channels · community and deskDiscord and Slack

These two are not aimed at a client in the terminal: one reaches a community, the other the desk.

Discord

Two modes: direct messages from the broker's bot, with the account linked by a one-time code, and automated posting into the community server — leaderboards, campaign announcements, market broadcasts. Prop and crypto audiences live there.

Slack — for the broker's own desk

Platform events routed into the firm's own channels by type and severity: exposure breaches, toxic-flow flags, large money movements, challenge breaches, feed failovers, system-health incidents. The desk hears about a risk event from an alert, not from a dashboard.

What it solves
  • Prop and crypto audiences reached where they already are
  • Faster incident response — the right team channel is notified at the threshold

How it ships. The gateway runs as a service beside the trading server, with an operations console for event templates, routing and priority rules, opt-in states and the delivery log, and a preferences screen in the client area.

What has to be right

A notification system is judged on the messages it fails to deliver and the ones it should never have sent.

Priority is a routing decision, not a label. A margin call and a bonus campaign cannot share a delivery path. Critical events fan out across every linked channel and ignore quiet hours; everything else respects preferences and opt-ins. Get that separation wrong and you produce missed stop-outs, or clients who mute the bot.

Fallbacks need a real failure signal. Falling back to SMS is correct only when the first channel genuinely did not deliver — not when a provider merely accepted the message for later. Channels report their own delivery semantics, and the chain advances on that.

Questions

Which channels should a broker switch on first?

Web push and one messenger. Web push covers every terminal user with no signup step and no per-message cost; a messenger reaches the client when the terminal is closed. Which messenger depends on where your clients are — Telegram in the CIS, WhatsApp in LatAm and MENA, LINE in Japan and Thailand, Zalo in Vietnam.

How does a client link a trading account to a messenger?

From the client area or the terminal, with a deep link carrying a single-use token. The client taps it, the messenger opens on the broker's bot, and the gateway binds that messenger identity to the trading account. Where deep links are unavailable a one-time code does the same.

Does a client get every alert on every channel they have linked?

Only when it is critical. Priority decides the pattern: margin warnings, stop-outs and security events fan out to every connected channel, transactional events follow the preferred channel with a fallback if delivery fails, and marketing goes only to channels the client opted into.

Can we prove a margin call alert was delivered?

Yes. Every message is written to a delivery log with its event, channel, timestamp and the provider's delivery receipt where the channel returns one. Stop-out disputes come down to whether the client was warned, and a per-message record answers that with evidence.

Talk to the people who wrote it

No sales script — a technical call about your client base, the channels worth running and the events you should be sending.

Book a technical call