Trading Accounts

MT5, cTrader, Match-Trader, VertexFX, Leverate and Piptrex ship as bridges, and more than one can run at the same time — which is the case worth designing for, because a desk that offers two platforms is otherwise running two of everything. The client record holds accounts across all of them at once, so a client with an MT5 account and a cTrader account is one relationship rather than two, and the desk answers questions about both from the same screen.

By rule, evaluated when the account is created. The product being opened, the client’s country, their KYC state, the account type and whether an introducing partner is attached all feed the decision, and the first matching rule wins. This matters more than it sounds: the group carries spread, commission and swap terms, so an account in the wrong group is mispriced rather than just misfiled, and it will usually be a client who notices first. Changing a group later is possible and leaves an approval trail.

Yes, within whatever limits you set. From the portal or the app a client can request an account on a product available to them, name it so they can tell it apart from the others, and fund it from their wallet. The checks run before anything is created: KYC state, jurisdiction rules, and any cap on how many accounts of a type one client may hold. Where your desk would rather approve each one, that is a setting rather than a different product, and the request simply queues for an operator instead.

As a request with checks behind it rather than as a message to somebody. The client asks from the portal; the request tests their KYC state, the leverage cap for their jurisdiction and whether they currently hold open positions; and approval is a recorded action by an operator entitled to make it. Increases can require a higher approval level than decreases, which is usually how a desk wants it. The change lands on the platform without anyone opening a terminal, and the whole thing is on the trail afterwards.

It is, because the two behave differently the moment a client tries to withdraw. Credit and bonuses are tracked apart from balance with their own release conditions — a volume requirement, a time period, whatever your promotion specifies — and their own expiry. The withdrawable figure is calculated from that rather than assumed, so a withdrawal request that would take out unreleased credit is stopped with a reason the client can read. Promotions that do not work this way tend to produce complaints that are expensive to answer.

Inactivity rules you set: after so long without a login or a trade an account is flagged, then restricted, then archived, with the client notified at the points you choose. History is retained rather than deleted, so the account can still be produced for a query or an audit years later, and reporting can exclude dormant accounts so growth figures reflect accounts somebody is actually using. It also keeps the platform itself tidy, which matters on terminals where licence costs scale with account count.