What we run, and what that involves.

Yes. Most engagements start inside an environment that is already running, and the work is scoped around it rather than against it. We read what is there — platforms, providers, databases, integrations, infrastructure — and connect to the interfaces those systems already expose. Replacing the stack is one possible outcome of that review, not the price of entry.

Yes. CRM, MetaTrader services, risk tooling, infrastructure, integrations, custom engineering and technical support are separate services and can be engaged individually. A brokerage that only wants its MT5 estate administered, or only a dealer tool built, is a complete engagement on its own. Taking more of it later does not require starting again.

Yes — a brokerage CRM and back office you deploy and run: lead and client management, onboarding and KYC workflow, trading accounts, deposits and withdrawals, IB and affiliate operations, communication history, workflows, user roles and reporting, with a client area on the same record. The point of it is that verification results, payments, trading activity and desk actions land on one record per client rather than in four systems that disagree. CRM has the full scope.

Yes, and it is a different product rather than the brokerage CRM with different labels. It is built around how a prop firm actually operates: challenge purchase, trader onboarding, account creation, evaluation against your rules, breach handling, phase progression, funded accounts and payouts — on one record per trader, with the trader-facing area, payments and integrations attached to it. Prop CRM covers the lifecycle in detail.

No. This is worth being blunt about: there is no all-or-nothing step. Start with the one system that is costing you time — the trade servers, the client record, the reconciliation nobody wants to do — and leave the rest where it is. If it works, the next piece is a separate decision made later, with the first one already running.

MT4, MT5 and cTrader are the platforms we deploy, administer and operate directly. DXtrade, Match-Trader, TradeLocker and TraderEvolution can be integrated where the platform exposes an interface to work against, which is assessed per environment rather than assumed. Custom and in-house trading systems are handled the same way: if there is a documented interface, it can be connected. Trading infrastructure and MetaTrader services set out what each involves.

Yes — live and demo deployment, migration from an existing host or provider, configuration of accounts, groups and symbols, access-server architecture, monitoring, backup and disaster recovery, and ongoing administration after go-live. A migration is planned against the current environment first, with a rehearsal and a rollback position. We do not promise a migration without downtime; we plan the window, agree it with you, and keep it as short as the environment allows.

Yes. An environment that is already live can be reviewed, documented and taken over for ongoing administration without redeploying it. The review covers server configuration, groups and symbols, access architecture, backup state, monitoring coverage and whatever has drifted since it was built. Anything that needs changing comes out of that review as a plan rather than as a condition of engagement.

Yes. That means a production environment and a disaster-recovery environment in a region you choose, with replication, scheduled backup, restore testing, monitoring across both and a documented failover procedure that is rehearsed rather than assumed. We do not publish recovery-time or recovery-point figures as a headline — those depend on your data volume, your platforms and where the environments sit, and they are agreed per engagement. Infrastructure covers the architecture.

Yes, where it is configured to. Exposure, long and short positions, net book, symbol and account risk, P&L and dealing activity are read from the trading environment through the platform's own manager interface — the MetaTrader Manager API — rather than from a nightly export. This is your own trading data: it is not exchange market data and it is not a price feed. Risk sets out what is read and what rules can act on it.

Yes, through the providers' own APIs. Deposit and withdrawal flows, settlement and failure handling, routing rules by method, currency and region, and reconciliation against the provider's own record. Verification vendors write their result to the client record, so onboarding state is one value across the business, and more than one vendor can run by region or as a fallback. Integrations has the connection model.

Yes. We work on the bridge, gateway and liquidity connectivity you already have — symbol and routing configuration, per-group rules, A/B and demo routing, session monitoring and failover — and on the alerting that tells you when a feed stops behaving. Bridge & liquidity describes the scope.

Yes. We have integration and connectivity experience with FXCubic and can work on configuration, routing and the operational side of running it. To be precise about what that is: it is engineering and operations experience with the technology, not a partnership, reseller arrangement or certification of any kind.

The same answer, on the same terms. We have integration and connectivity experience with PrimeXM and can work on configuration and operations around it. That is experience with the technology — not a partnership and not an official status.

Yes, where the provider and the bridge expose the connectivity required — typically a FIX session and the credentials and symbol mapping that go with it. Your commercial relationship with the LP stays yours: Brokerexa is not a liquidity provider, does not hold a book and does not intermediate pricing. We connect, configure, monitor and support the link.

Yes. REST and webhook integrations, platform manager interfaces, provider APIs and your own internal systems, each as a defined contract: what is read, what is written, what arrives as an event and what happens when it fails. Retries, ordering and reconciliation are handled by the layer rather than by whoever wrote the script, which is what keeps the sixth integration from costing what the first five did.

Microsoft SQL Server, MySQL and PostgreSQL on the data side. On the infrastructure side: dedicated hardware, a virtualised estate, private infrastructure and data-centre environments, or cloud where that is the right answer — AWS and Azure among them. Which one you use is a decision about your business, not a constraint we impose.

Yes. Production and disaster-recovery environments, data-centre placement, network and firewall architecture, private networking, connectivity, backup and replication, failover architecture and monitoring. The architecture follows the brokerage rather than the other way around — the deployment model is chosen for how you actually operate. Infrastructure has the detail.

Yes — that is usually the point. Deployment is the short part; the engagement is the years after it. Ongoing administration, monitoring, backup verification, failover rehearsal, configuration changes and the technical support that goes with them are a continuing service, not a hand-over document.

Yes. Dealer tools, treasury tools, internal dashboards, reporting systems, client and trader portals, CRM modules, Manager API applications, back-office automation, API services and the integrations between them. It is written by the team that also runs the platform underneath, so the requirement does not have to be translated for someone who has never seen a group configuration. Custom technology has examples.

Yes — trading algorithms, execution logic, dealer automation and operational automation, written against your platform's own interfaces and run in your environment. Your logic, your rules, your infrastructure. What we do not do is make claims about how any of it will perform: the engineering is ours, the strategy and its results are yours. Algo & automation covers it.

Yes, for brokerage and prop environments specifically: brokerage websites, prop firm websites and challenge storefronts, client portals and trader portals — with the integrations behind them, so a balance shown in the portal and a balance on the record are the same number. This is technology work attached to your operation, not a general web-design service.

Ticket portal and email intake, triaged by severity, with named engineers who know your configuration rather than a rota reading a runbook. Incidents are tracked, the escalation path is defined with an owner at each step, and a dedicated Slack or Microsoft Teams channel is opened where the engagement warrants it. Coverage hours are agreed per engagement — we do not advertise blanket round-the-clock support. Technical support sets out intake, escalation and reviews.

Yes, and often that is the better arrangement. We can take the parts your team does not want to carry — trade-server administration, disaster recovery, an integration nobody has time for — and leave the rest with them. Working alongside an internal IT, development or operations team is a normal shape for an engagement, not an exception to it.

A technical review of what exists. Current environment and where it is hosted, platforms and versions, providers and integrations, infrastructure and network, databases, dependencies between systems, and what the business actually needs the result to do. That review produces the scope, the sequence and the risks, and it happens before anyone commits to a deployment date.

Request a technical discussion. The first conversation is an engineering one: what you are running now, what needs to be deployed, migrated, integrated or built, and which single piece is worth doing first. You will leave it with a technical next step rather than a proposal document. Still have a technical question