Most platform evaluations look the same. A shortlist of three or four vendors, a comparison table built around instrument coverage, a round of demos, a pricing conversation, and a decision. Six months later, the broker is dealing with a problem they did not ask about in the evaluation — a configuration limit they hit, a mobile experience that traders complain about, a routing setup that locked them into one execution provider.

The demos all looked fine. That was never the test.

The real test of a multi-asset trading platform is what happens after go-live, when the broker needs the platform to flex around their operations rather than the other way round. Most evaluations do not measure that. This is how to.

Why the Standard Evaluation Misses the Point

The standard platform evaluation rewards what is easy to demo and easy to compare. Instrument lists. Charting features. UI polish. Headline pricing. These things matter, but they are also the things every serious vendor has solved. Comparing platforms on them is like comparing commodities.

What separates a platform that works from a platform that creates drag is harder to see in a sales cycle. It is the depth of broker-side configuration. The consistency of the trader experience across devices. The flexibility of the integration layer. The amount of work the broker has to do, and pay for, in the months and years after the contract is signed.

This is not a build-versus-buy debate. For most brokers, buying is the right call — the question of whether to build or buy brokerage software at all is a separate one, and the answer for most is to buy the infrastructure and own the configuration. The question this article addresses is narrower and more practical: given that buying is the right move, how does a broker evaluate which platform to buy?

Six criteria. They do not show up in standard vendor pitches, but they are what predict satisfaction post-launch.

1. Instrument Flexibility

Every vendor will hand over an instrument list. FX, CFDs, indices, commodities, crypto, equities, sometimes more. The list itself rarely settles anything. Most platforms cover the major asset classes.

The better question is what happens when the broker wants to add an instrument that is not on the default list. How long does it take? Who controls the change? Whether the broker can do it through a back-office interface or has to file a vendor support ticket and wait.

This matters because instrument expansion is a normal part of broker growth. New markets bring new symbol demands. Trader feedback surfaces gaps. Competitive pressure forces the broker to add a product category quickly. If every one of those moves requires vendor involvement, the broker is not running their own product — they are renting it on the vendor's timeline.

A platform with real instrument flexibility lets the broker manage their symbol list directly. They can group instruments, set leverage by category, configure live and demo separately, and push changes without waiting on engineering on either side. That is what flexibility looks like in production. Anything less is a list. It is also why brokers evaluating white-label platforms need to pressure-test scalability — not just whether the platform handles current volume, but whether the broker can extend it themselves without starting a project.

2. User Experience Under Real Conditions

A demo is a controlled environment. The presenter clicks through a planned flow on a strong connection, usually on a single device, usually with cherry-picked instruments and quiet market conditions. Most platforms look good in that environment.

Real trader behaviour is different. Traders open the platform on a phone while standing in a queue. They switch from mobile to desktop mid-session. They open ten charts at once. They place orders during high-volatility moves. They use one-click execution because they do not have time for a confirmation dialog. The platform either holds up under that or it does not. The way to test for this is to stop watching the vendor demo and start using the platform yourself. Ask for trial access across all the devices traders will actually use. Run through a normal trading session on a phone, then continue it on a laptop. Place orders during a busy market window. Watch what happens to charts when you load a heavy multi-symbol layout.

What to look for: consistent execution speed across devices, session continuity when switching, no feature gaps between web and desktop, fast chart rendering on mobile, and order entry that does not require multiple taps for routine actions. Desktop execution tools like one-click trading and in-chart trading matter more than they look — they remove friction that compounds across thousands of sessions, and they are one of the clearest signals that a platform was built for traders who trade seriously, not traders who trade occasionally.

3. Configuration Depth

This is where the gap between vendors widens most. Configuration is not branding. Logo placement and colour schemes are the floor, not the ceiling. Real configuration depth means the broker can change how the platform behaves operationally without filing a ticket and waiting on the vendor.

The questions to ask: Can the broker change leverage presets by account type, by region, by instrument category — directly, through a back-office interface? Can they push announcements and banners to specific trader segments without a code change? Can they toggle features on and off for different account tiers? Can they manage live and demo as separate environments with different defaults? Can they adjust layout defaults, symbol watchlists, and welcome flows for newly onboarded traders?

If the answer to most of these is "yes, but we will do it for you," the broker has surface-level customisation and a permanent vendor dependency. If the answer is "yes, and here is the back-office tool you use," the broker has operational control. The practical difference between those two answers is the difference between a platform the broker operates and a platform the broker depends on. The difference is invisible in a sales cycle and obvious six months in.

Brokers underestimate how much this matters until they hit the first situation where they need a small change urgently and cannot make it themselves. By the time that happens, the contract is signed.

4. Cross-Device Consistency

Most vendors will say their platform is multi-device. That word does almost no work in this evaluation. The question is whether the experience is genuinely unified or whether each device is its own product with its own gaps.

Genuinely unified means: a trader can start an order on desktop, see the same chart layout on mobile, switch to web in the office, and have the same watchlists, the same open positions, the same feature set available on every surface. It means session continuity is real. It means a setting changed on one device shows up on the others. It means mobile is not a stripped-down version of the platform but a full execution environment with the same data feeds and the same chart capability.

What it usually means in practice: the desktop platform is the strongest, the web version is competent, and the mobile app has noticeably fewer features. Traders pick up on this fast. Mobile is increasingly the primary surface for retail traders, especially in newer markets, and a weak mobile experience leaks retention. The pattern is well-documented — traders who encounter a broken session handoff or a missing feature on mobile do not raise a support ticket, they reduce their usage frequency, and the habit fades.

The test is simple. Ask for trial access across all surfaces. Use them. Compare them directly. If the mobile app is missing features the desktop has, and the broker's traders are predominantly mobile, the platform is wrong for that broker regardless of what the desktop looks like.

5. Integration Readiness

Brokers do not run a platform in isolation. The platform sits in the middle of a stack — execution, liquidity, signals, analytics, payment processing, social features, CRM, risk management. Every one of those touchpoints is either an integration the platform already supports or a custom development project the broker has to pay for.

Two things determine how well a platform handles this.

The first is protocol flexibility. Does the platform support both FIX and REST? Does it offer multi-OMS architecture, or is it locked to a single execution provider? Multi-OMS connectivity is harder to find than vendors imply, and it is the single most important integration question for brokers who expect to grow. FIX/REST openness gives the broker freedom to switch execution relationships or run multiple OMS providers in parallel. If the execution relationship changes, the broker should not have to replace the front end.

The second is the existing ecosystem. A platform that already integrates with the providers brokers actually use — TradingView for charting, recognised signals providers, payment networks, social or strategy-following systems, third-party CRM tools — saves months of work and material cost. A platform with no ecosystem is a platform where every integration is a custom build, which means every integration is slow, expensive, and dependent on vendor engineering bandwidth.

Ask the vendor to list their existing integrations, not their roadmap. The roadmap is marketing. The list is the product.

6. Post-Launch Operational Effort

The last criterion is the one most evaluations skip entirely. How much work does the broker carry after go-live. Some of this is configuration depth in another form. If routine changes need vendor support, the broker is paying — in time, in money, or both — for every adjustment. Some of it is reliability: how often the platform requires intervention, how stable updates are, how the vendor handles incidents. Some of it is operational tooling: whether the back office gives the broker visibility into trader activity, account status, and platform performance without requiring custom reporting builds.

These costs do not show up in the initial contract. They accumulate in the months after signing, and they are larger than most brokers anticipate. The hidden operational drag that follows post-launch — change requests, integration maintenance, support overhead, and the engineering time that gets pulled into platform upkeep — is rarely budgeted for and almost never visible during a vendor sales process.

The right question to ask vendors directly: walk through the last three months of operational changes a current client has made. Who did the work? How long did each change take? What required vendor involvement and what did the broker do themselves.

Most vendors will not answer this cleanly. The ones that can are the ones worth shortlisting.

Common Red Flags

A few patterns predict problems with high reliability: The vendor demos exclusively on desktop and gets vague about mobile capability. The broker is being shown the platform's strongest surface.

The vendor cannot list specific configuration changes the broker can make themselves post-launch. Either the configuration depth is not there, or the vendor does not understand their own product well enough to know.

The vendor describes the integration with a major OMS or signals provider as "available" rather than "live with current clients." Available usually means a roadmap. Live means proven.

The pricing structure penalises change. Per-change fees, per-instrument fees, or vendor-side configuration fees built into ongoing support. This signals that the vendor expects to do most of the operational work, which is exactly the dynamic the broker is trying to avoid.

The vendor cannot produce a current client willing to talk about post-launch experience. The pre-sale process tells the broker very little. A reference call with a live client tells them most of what they need to know.

What the Evaluation Should Produce

By the end of a serious evaluation, the broker should be able to answer five questions clearly:

1. How will the broker add new instruments six months from now, and who will do the work.
2. What will the trader experience look like on the broker's lowest-priority device, not its highest.
3. Which routine operational changes will the broker make through a back-office tool, and which will require vendor support.
4. What does the integration path look like for the three external systems most relevant to the broker — execution, signals, payments.
5. How much engineering capacity will the broker need to allocate to platform maintenance over the next twelve months.

If the answers to any of these are vague or vendor-dependent, the evaluation is not finished.

Where AQX Trader Fits

AQX Trader is a white-label multi-asset trading platform built specifically against this evaluation pattern. Configuration depth is exposed to the broker directly through a CMS-style back office — symbol management, leverage presets, layout defaults, announcements, feature toggles, and separate control over live and demo environments, all without engineering involvement on either side.

The platform runs across desktop, web, mobile app, and mobile web with feature parity and session continuity as defaults rather than upgrades. Desktop adds execution tools such as one-click trading and in-chart trading for traders running active strategies.

The integration layer supports multi-OMS architecture with FIX and REST connectivity, plus live integrations with TradingView, FXStreet, Acuity Signals, Centroid, TransactCloud, and Pelican Network. AWS-backed infrastructure handles the underlying scale.

The platform is available for evaluation across all surfaces before commitment.

Practical Summary

The mistake most brokers make is evaluating platforms on what is easiest to compare. Instrument lists. UI screenshots. Headline pricing. These criteria favour vendors who optimise for the sales cycle rather than the production environment.

The brokers who end up satisfied with their platform six months in are the ones who are evaluated for configuration depth, real cross-device consistency, integration readiness, and post-launch operational effort. Those criteria are harder to test for in a demo, which is precisely why they are worth testing for.

The vendor's job is to sell. The broker's job is to know what they are buying.

See how AQX Trader holds up across all six criteria. Request a demo.