Getting live order, position and balance data out of XM 360

XM 360 sits on top of MetaTrader 4 and 5, the engine Trading Point Group has run for the broker for more than 15 years. That single fact decides most of the integration: the account state a third party usually wants — cash balance, open positions, pending orders, the deal and order history, and the copy-trading book — all live in an MT-shaped session rather than a plain web portal. Reaching it cleanly is the job described here.

No bank-style open-banking scheme applies here — a CFD broker is not an account-servicing payment institution, so there is no AIS consent rail to ride. The dependable basis is the account holder authorizing us to read their own XM 360 data, and the work is mapping the authenticated MetaTrader traffic into a clean, queryable interface. That is the route we would take.

What the account actually holds

These are the surfaces the app exposes to a logged-in trader, named the way XM 360 presents them.

Three ways in, and which one we'd run

Authorized protocol analysis of the MT session

The app authenticates against an XM MetaTrader gateway and then reads account state over the MT protocol. We capture that handshake under the account holder's authorization, document the login, token and keepalive flow, and rebuild the read calls — positions, orders, history — as a stable interface. This reaches the most data and survives front-end redesigns, because it follows the protocol, not the screen. Effort is moderate; durability is good as long as the MT server contract holds.

User-consented account access

Where a client wants a turnkey connector for their own users, the integration authenticates with credentials the user supplies and consents to, then pulls the same domains on their behalf. This is quick to stand up and maps directly onto how a trader already logs in. We scope it to read-only unless a client explicitly needs order placement.

Native MT statement export

MetaTrader can export an account statement of closed deals and balances to HTML or XLSX. As a fallback it is reliable for historical reconciliation, but it is a file, not a feed — no live positions, no streaming. We wire it as a backfill source behind the protocol route.

For XM 360 the protocol route is the one we'd build the connector on: it is the only path that returns live positions and a complete history together, and it degrades gracefully because MT session semantics change far less often than an app's UI. The consented-credential route layers on top for per-user deployments, and statement export covers historical gaps. Access — a consenting live or demo account, the entity details — is arranged with you during onboarding.

What lands at the end

Each deliverable is tied to the surfaces above, not a generic checklist.

• An OpenAPI/Swagger spec covering account, positions, orders, history and copy-trading endpoints as we model them.
• A protocol and auth-flow report: the MT login handshake, token issuance, session keepalive and reconnect behaviour, written from the captured session.
• Runnable source — Python and Node.js — for the core reads: balance, open positions, deal history paging, and the copy-trading book.
• Automated tests against recorded fixtures so the parser stays honest when XM ships an app or server update.
• Interface documentation with the symbol/field mappings and the live-versus-demo account flag.
• Data-retention and minimization guidance shaped to the GDPR posture below.

On the wire

Illustrative shape of the read flow, confirmed against the live session during the build — field names follow MetaTrader conventions:

# 1. Authenticate the MT session (entity-specific gateway)
POST https://{entity-mt-gateway}/session/login
  { "login": 5xxxxxxx, "server": "XMGlobal-MT5 4", "secret": "***" }
-> { "token": "…", "accountMode": "live", "currency": "USD" }

# 2. Read live state
GET /account/positions      Authorization: Bearer <token>
-> [ { "ticket": 184523991, "symbol": "EURUSD", "side": "buy",
       "volume": 0.50, "openPrice": 1.0842, "profit": -12.40,
       "swap": -0.31, "openTime": "2026-06-24T08:11:03Z" } ]

# 3. Page the closed history; cursor on deal id
GET /history/deals?from=2026-01-01&to=2026-06-25&after=<dealId>
-> { "deals": [ … ], "nextAfter": 184530077 }

# Reconnect: re-issue login on keepalive timeout, resume from nextAfter
# accountMode is carried onto every record so demo never mixes with live

Consent and the jurisdiction question

XM books clients across several regulated entities, so the rules that apply depend on where the account sits. The European entity is Trading Point of Financial Instruments Ltd in Cyprus, under CySEC licence 120/10 per XM's own regulation page, which puts the data handling under GDPR; other accounts route through XM Global and regional licences. We confirm the entity before any data moves and apply that jurisdiction's expectations.

Access rests on the account holder's authorization to read their own records — scoped, logged, and revocable. We pull only the domains a project needs, keep consent records, work read-only by default, and sign an NDA where a client requires it. Credentials are never stored in clear, and retention windows match what the downstream use actually justifies.

Things we handle in the build

• Multiple entities, multiple servers: an XM account resolves to a specific MT server cluster depending on the booking entity. We detect the entity at login and route reads to the right gateway, so a Cyprus account and an XM Global account are both handled without the caller caring.
• Session keepalives and reconnects: MT sessions drop on idle. We design the read loop around the keepalive interval, with reconnect-and-resume on the history cursor, so a long backfill does not lose its place or silently stall.
• Live versus demo parity: XM 360 offers a no-time-limit demo alongside live accounts, and they share record shapes. We pull both through the same code path but stamp an account-mode flag on every record so virtual and real funds never blend downstream.
• App-update drift: when XM ships a new app or server build, field sets can shift. We keep a re-validation pass on the recorded fixtures so a change surfaces as a failing test rather than a silent data gap.

Freshness and reliability

Positions and balances are live values — they only mean anything if read close to real time, so the connector streams or short-polls rather than caching. History is append-only and pages cleanly, which makes backfill cheap and idempotent. Watchlists and copy-trading allocations change rarely and can be refreshed on a slower cadence. We document the expected staleness for each domain so downstream systems do not treat a five-minute-old margin figure as current.

What we checked

We read the XM 360 Play Store listing for the feature set and the MetaTrader backing, XM's regulation page for the entity and licence structure, and the broker's MT WebTrader to confirm the session model. Reviewed June 2026.

• XM 360 on Google Play
• XM — licences and regulation
• XM MT4 WebTrader

Mapped by the OpenBanking Studio integration desk, June 2026.

Comparable apps a unified feed would touch

Same category, similar data shapes — useful context for anyone aggregating broker accounts. Listed neutrally, not ranked.

• Exness — holds per-account balances, positions and Social Trading copy records across MetaTrader and its own stack.
• IC Markets — runs MT4, MT5 and cTrader, with order, deal and copy-module history per account.
• eToro — keeps portfolio, position and CopyTrader relationship data behind its social-trading login.
• Octa (formerly OctaFX) — stores trade history and copy-trading subscriptions across MT4/MT5 and its app.
• Vantage Markets — holds CFD positions, balances and copy-trading allocations per client.
• AvaTrade — keeps account, order and AvaSocial copy data behind its trading login.
• Pepperstone — exposes MT4/MT5/cTrader account, trade and signal data per user.
• CMC Markets — holds CFD positions, orders and statements in its Next Generation platform.

Interface

Screens from the app listing, for reference on the surfaces above.

Questions an integrator asks

Which records can come from a live XM 360 account versus a demo one?

Both behave the same to the integration. A live account returns real balances, open positions, pending orders and the full deal history; a demo account returns the identical shapes against virtual funds. We carry an account-mode flag through every record so live and practice data never get mixed downstream.

Does XM 360 running on MetaTrader change how the integration is built?

It shapes it directly. XM 360 sits on the MetaTrader 4 and 5 stack that Trading Point Group has run for years, so the session handshake, the symbol catalogue and the deal/order history follow MT conventions. We model the auth and the read flow against that traffic rather than against a generic web session.

XM operates under several regulators — which one governs the data handling?

It depends on the entity the account sits with. The European book is Trading Point of Financial Instruments Ltd in Cyprus, under CySEC licence 120/10 per the XM regulation page, so GDPR applies; other accounts route through XM Global and regional entities. We confirm the entity first and apply that jurisdiction's data-handling rules, with the account holder's own authorization as the basis for access.

Can copy-trading and strategy-manager relationships be pulled, not just my own trades?

Yes. The XM Copy Trading surface holds the strategies an account follows, the allocation per strategy and the resulting copied trades. We map those alongside the account's own orders so a unified feed shows self-directed and copied activity as distinct, labelled streams.

The connector built around the MT session above lands in one to two weeks. Source-code delivery starts at $300: you receive the runnable Python and Node source, the OpenAPI spec, the tests and the docs, and you pay only after delivery once it works for you. Prefer not to host it — call our pay-per-call API instead, with no upfront fee and billing only on the calls you make. Tell us the app and what you need from its data — start the conversation here and we handle access and compliance with you from there.