Most white-label platform contracts look reasonable on paper. The pricing fits the budget. The demo was smooth. The vendor answered every question during the sales process.

Then the broker goes live, and the first real test arrives. A trader segment needs a new instrument. A compliance update requires a leverage adjustment. The broker wants to push a promotional banner before the weekend. They raise a support ticket. The vendor says allow three to five business days. That is when the "fully customisable white-label solution" starts to look like a rental agreement with a landlord in the loop for everything.

The problem is not that white-label platforms are inherently limiting. The problem is that most evaluation processes are not built to surface those limits before signing. Standard checklists cover instrument lists, platform aesthetics, and pricing structures. They do not ask the questions that predict whether the platform will work for the broker at month six, or month eighteen, or when entering a new market.

These are the fifteen questions that do. The goal is simple: identify the right trading platform for brokers before signing the contract, not after discovering its limitations in production.

Before the Questions: What You Are Actually Evaluating

The goal of a white-label platform evaluation is not to find the most feature-rich option. It is to find the option that gives the broker the most operational control with the least friction, at a cost that makes sense for the business.

That means evaluating three things in parallel: what the platform can do out of the box, what the broker can change themselves after go-live, and what requires the vendor every time.

The third category is where most brokers get caught. Whether to build or buy brokerage software at all is a separate decision — and for most brokers, buying is right. But buying the wrong white-label platform creates a dependency structure that mimics the worst of building without any of the ownership benefits. This checklist is designed to identify that risk before the contract is signed.

Vendor Basics

1. How long has this platform been in live production with real brokers

A white label platform that has been deployed in live production with multiple brokers across different markets offers a very different level of maturity than one that has been available for two years but is only used by a handful of clients. Real world trading volumes, execution demands, and support incidents expose challenges that controlled testing environments simply cannot replicate.

Ask for a list of live deployments. Ask how long those deployments have been running. Ask what the platform looked like twelve months ago and what changed. Vendors who have iterated the product based on live broker feedback have solved problems that newer entrants have not encountered yet.

This is not about dismissing newer vendors. It is about calibrating your risk. If the platform is relatively new to production, ask what the vendor's escalation process looks like when something breaks and how quickly they can deploy fixes.

2. What does your infrastructure run on, and what are your uptime guarantees?

Infrastructure is the layer brokers cannot see and traders do not think about until it fails. When it fails, the broker absorbs the damage — not the vendor.

Ask specifically: What cloud provider is the platform hosted on? What redundancy architecture is in place? What uptime Service Level Agreements (SLAs) does the vendor guarantee, what compensation applies if those SLAs are missed, and what is their incident history over the past 12 months?

AWS, Azure, and GCP with multi-region architecture and proper failover design are reasonable baselines for a platform handling real trading volumes. Vague answers about "enterprise-grade infrastructure" are not.

3. Who are your current broker clients, and can I speak to any of them?

A vendor willing to provide references from live clients is a vendor with live clients who are satisfied enough to take a call. Vendors who deflect this question with NDAs or redirect to case studies are telling you something.

The reference call itself matters less than whether it exists. If the vendor can facilitate it, do the call. Ask the reference broker one question above all others: what is the one thing you wish you had tested before signing?

Configuration and Broker Control

4. What changes can I make to the platform after go-live without raising a vendor support ticket?

This question separates configuration depth from surface-level customisation. Get a specific list. Then ask the vendor to demonstrate each one in the back-office interface.

What a broker should be able to do without vendor involvement:

• Add, remove, or reconfigure instruments in the live symbol list
• Adjust leverage presets by instrument category or account type
• Push announcements and banners to the trader-facing platform
• Toggle features on or off by account tier
• Manage session defaults, onboarding flows, and layout preferences
• Change leverage and instrument settings independently in demo versus live

If the demonstration shows a proper back-office interface where the broker controls these settings directly, the platform has real configuration depth. If the vendor says "we can do that for you," the broker will be paying for that sentence on a recurring basis.

The practical difference between those two answers is the difference between a platform the broker operates and one the broker depends on.

5. How are live and demo environments managed?

Demo environments are often overlooked as a powerful acquisition tool. For many prospective traders, the demo account is their first experience with the platform. If it is poorly configured with the wrong instruments, unrealistic leverage, or a complicated onboarding process, it can negatively impact conversion before the trader even makes their first deposit.

Ask whether live and demo environments are managed independently. The broker should be able to configure different instrument lists, leverage settings, account defaults, and feature states for each. They should be able to test changes in demo before pushing them live. If live and demo environments share a single configuration layer, the broker has less room to manage acquisition without risking the live trading environment.

6. Can I localise the platform for different markets, and how?

Brokers expanding into new regions typically need to adjust more than the language. Different markets have different instrument preferences, different leverage norms, different compliance environments, and sometimes different UX expectations. A platform that localises language but requires vendor involvement for anything else creates friction at exactly the moment when speed matters most.

Ask what localisation actually includes. Language packs are table stakes. What about region-specific instrument sets, different leverage configurations by geography, currency display preferences, and the ability to adjust these settings without opening a development project?

Expansion into new markets is where operational responsiveness becomes visible to clients. Brokers who can respond quickly to local market conditions look like they know what they are doing. Brokers waiting on vendor timelines look like they do not.

Trader-Facing Experience

7. Is the platform genuinely consistent across desktop, web, mobile app, and mobile web — or is one of these clearly the lead product?

Every vendor will say their platform is multi-device. That phrase does almost no work in an evaluation. The question is what "multi-device" means in practice.

A genuinely unified experience means a trader can start a session on desktop, continue it on mobile, and have the same watchlists, the same open positions, and the same feature set available on every surface. Session continuity is real. A layout change made on one device carries across to the others. Mobile is a full execution environment, not a stripped-down companion app.

In practice, most platforms have a lead product and the rest are approximations. The desktop version is strongest. The web version is close. The mobile app has gaps. Traders notice, especially traders in markets where mobile is the primary device.

Ask for trial access across all four surfaces. Run a real trading session. Place orders. Load heavy chart layouts on the phone. See what does not transfer.

8. What desktop execution tools does the platform offer, and how do they work?

Traders who trade seriously use execution shortcuts — not because they are impatient but because they are paying attention to the market and do not want the platform in the way. One-click trading and in-chart trading are the two most impactful here. One-click removes the confirmation dialog from routine orders. In-chart trading lets traders place and manage orders directly from the chart without switching context.

These features remove friction that compounds across thousands of sessions. They also reduce execution errors that generate support tickets and complaints. A platform that has built these tools well has thought about how traders actually behave, not just how they behave in a demo. Ask to see these features working, then test them yourself. The demo environment is the right place for this.

9. How does the platform handle high-volatility periods?

Smooth execution in a calm market is the minimum bar. The question is what happens when volatility spikes and order flow increases — during major economic releases, market open and close windows, or unexpected news events. Those are the moments that drive trader complaints and broker support load simultaneously.

Ask vendors directly: what is your platform's performance history during high-volatility periods? What does order execution look like under load? What is the plan when something goes wrong at a bad moment?

Vendors with good answers to this question tend to have invested in execution infrastructure and have data to back it up. Vendors who redirect to general uptime statistics are not answering the question.

Integration and Connectivity

10. What OMS providers do you connect to, and how is the integration structured?

OMS flexibility is one of the most underweighted criteria in a platform evaluation. Brokers often sign a white-label agreement with a platform that connects cleanly to one OMS provider, then find themselves locked into that execution relationship because switching means re-integrating the front end.

Ask specifically: what OMS providers does the platform support today? Does the platform support both FIX and REST connectivity? Can the broker add a second OMS provider without rebuilding the integration?

Multi OMS architecture gives brokers greater flexibility in routing trades. If the execution provider changes due to pricing, service quality, or regulatory requirements, brokers can switch providers without replacing the trading platform they have already configured and branded.

11. What does the integration ecosystem look like for analytics, signals, and payments?

A trading platform without an integration ecosystem is an island. Traders expect charting through TradingView. They want market signals and analysis tools to stay engaged during quieter periods. They expect deposits and withdrawals to work without friction.

Ask what integrations are available out of the box, not just what the vendor can build on request. Ready to use integrations with analytics providers, signal tools, social trading or strategy following networks, and payment processors allow brokers to extend the platform without the time and cost of custom development for every new addition.

Pre-built also means tested. Integrations that exist in production with other brokers are more reliable than promises about what can be done.

12. What APIs do you expose for custom development, and what is the documentation like?

Even brokers who buy rather than build will want to extend at some point. Custom reporting, proprietary analytics, third-party tool connections, internal system integrations. The question is how open the platform is to that.

Ask for API documentation before signing. Evaluate the documentation quality as a proxy for the vendor's engineering culture. Well-documented APIs with clear versioning suggest a team that builds for external developers as well as internal ones. Thin or outdated documentation suggests the opposite.

Ask also about versioning and deprecation policy. If the vendor makes breaking API changes, how much notice does the broker get and what migration support is provided?

Commercial Structure and Total Cost

13. What is included in the platform fee, and what triggers additional charges?

White-label pricing structures vary significantly, and the headline fee rarely tells the full story. Some vendors charge per seat. Some charge per OMS connection. Some charge separately for the mobile app, the back-office portal, or specific integration modules. Some charge for configuration changes above a certain frequency.

Get a written breakdown of what is included and what triggers additional charges. Then think through the scenarios most likely to apply to your business: launching in a new market, adding an integration, scaling trader accounts, making frequent configuration changes. Run those scenarios against the pricing model before signing, not after.

The hidden cost audit framework for brokerage technology is worth applying here specifically — change tax, integration tax, and incident tax accumulate in ways that are rarely visible in the initial proposal.

14. What does the onboarding and implementation process look like, and who owns each stage?

A white-label deployment has a go-live date. What happens between contract signing and that date matters more than most brokers account for. A poorly structured implementation adds weeks or months to the timeline and creates pressure that gets absorbed by the broker's internal team.

Ask for a written implementation plan. Who does what? What does the vendor provide and what does the broker configure? What are the milestones and who is accountable for each one? What has caused delays in past implementations, and how were they resolved?

Implementations that run over timeline are common enough in this space to be worth interrogating directly. A vendor who cannot give a clear answer is either inexperienced or evasive.

15. What does the ongoing support structure look like post-launch?

The vendor relationship does not end at go-live. In some ways it is only beginning. How the vendor responds to incidents, feature requests, and routine operational questions determines how much friction the broker carries every month for the duration of the contract.

Ask: what is the SLA for support tickets by priority? What communication channel does urgent support go through? Who is the named contact for the broker's account? What is the escalation path for critical incidents?

A vendor who has invested in post-launch support structure is a vendor who expects to have a long relationship with their clients. A vendor whose support model is vague or whose answers depend entirely on the sales rep in the room is one whose post-launch attention may follow a similar pattern.

A Note on the Evaluation Process Itself

These fifteen questions are designed for the later stages of an evaluation — once the broker has already narrowed the field to credible vendors. The earlier stages, covered in more depth in how to evaluate a multi-asset trading platform beyond the demo, focus on instrument flexibility, UX consistency, and configuration depth as primary filters. The two frameworks work together. Use the six-criteria evaluation to build the shortlist. Use these fifteen questions to stress-test the finalists before signing. The goal in both cases is the same: move the evaluation away from what looks good in a controlled demo and toward what works in production, under real conditions, with a broker who needs to move quickly and without a support ticket every time.

Where AQX Trader Fits in This Checklist

AQX Trader is a white label multi asset trading platform built for brokers and financial institutions. It delivers a consistent trading experience across desktop, web, mobile app, and mobile web, while providing brokers with a powerful content management system that enables direct control over instrument management, leverage settings, environment configuration, and feature management without relying on engineering support.

The platform supports multi-OMS architecture via FIX and REST and integrates with TradingView, Acuity Signals, FXStreet, Centroid Solutions, TransactCloud, and Pelican Network. Live and demo environments are managed independently. Desktop execution tools including one-click trading and in-chart trading are available on the trader-facing side. Brokers evaluating the platform can request demo access to test the full experience across all four device surfaces before making any commitment.

Built for brokers, designed for traders.