Every provider will show you a dashboard, list their integrations and quote a number. That process tells you almost nothing, because the things that determine whether the relationship works are contractual and structural, not visual.
Here is what to ask, and what the answers tell you.
1. Who owns the data, and can you get it out?
The single most important question, and the one least often asked before signing.
Your trader records, transaction history and performance data are the asset you build over years. If leaving a provider means losing them, you are not a customer — you are locked in.
Ask specifically: can I export trader records, transactions and performance history at any point, in a usable format, including at the end of the contract? Get it in the agreement, not in an email.
2. Multi-tenant, or a fork per client?
This is technical and it has a direct commercial consequence.
If a provider spins up a separate copy of the codebase for each client, your instance begins drifting the day it is created. Fixes built for other clients may not reach you. New features require porting. Over time you end up on a version nobody actively maintains, and the provider quietly stops improving it.
On a genuinely multi-tenant platform with isolated data, every improvement reaches every tenant. Ask directly which architecture they use, and ask how a feature released last month reached existing clients.
3. Revenue share or flat fee?
Both models exist in this market and the choice has consequences beyond price.
| Flat fee | Revenue share |
|---|---|
| Higher upfront, predictable forever. | Lower upfront, scales with your success. |
| Provider has no interest in your trader outcomes. | Provider’s revenue is tied to your fee volume. |
| Costs stay flat as you grow. | Costs grow with you, permanently. |
Run the arithmetic at your target volume rather than your launch volume. Revenue share is cheaper to start with and more expensive to succeed with, and the crossover usually arrives sooner than founders expect.
There is also an alignment question worth sitting with. A provider taking a percentage of challenge fees has a financial stake in how your programme performs. That is not automatically bad, but you should decide consciously whether you want your infrastructure supplier holding a position in your unit economics.
4. What happens to custom development?
You will eventually pay for something built specifically for you. Three questions:
- Who owns the resulting code?
- Can the provider resell it to your competitors?
- If you leave, can you take it?
All the common answers are defensible. What is not defensible is discovering the answer after you paid, or worse, seeing a feature you commissioned appear in a competitor’s product. Get it explicit in the contract.
5. Who is liable when it breaks?
It will break at some point. Every platform does. What matters is what the contract says.
Read the liability clause and the disclaimer carefully. Most providers exclude liability for what happens at the execution layer — that sits with the terminal and the broker — and cap their total exposure at some multiple of what you paid. That is normal and reasonable.
What you want to check is whether the exclusions are so broad that the provider bears no responsibility even for failures in their own systems. A provider whose risk engine wrongly closes a position should not be able to disclaim that.
6. What does support actually cover?
"Support included" means different things. Pin it down:
- Do they support your team, your traders, or both? (It should be your team — the traders are your customers and your brand.)
- What response times, and are they contractual or aspirational?
- Is integration work included, or quoted separately?
- Are updates included in the licence?
- Do you get a named contact, or a shared inbox?
7. Can you migrate in — and out?
If you already operate, migration is the highest-risk part of switching providers, because it depends on what your current provider will export and in what format.
Agree the migration plan before giving notice to your existing vendor. A provider who scopes migration properly before you commit is showing you how they will behave later. One who says "we will figure it out" is telling you something too.
8. Do they use their own product?
A provider who operates a firm on their own platform encounters the problems their clients encounter, at the same time, with their own money on the line. It is not a guarantee of quality, but it changes the incentives around fixing things.
Ask whether anyone runs a live operation on the platform, and what it taught them.
The demo
One practical note. Nobody demonstrates live integrations, because that would require maintaining active licences with every data and terminal provider simultaneously. A demo shows the platform and the workflow, not live connections — that is normal and not a red flag.
What you should expect is that your own rules can be configured during the call. If a provider cannot set up your programme in front of you, ask why.
The summary
Feature grids converge. Every serious provider in this market has a challenge engine, a payout system and a KYC integration. The differences that will matter to you in year two are all in the contract: data ownership, architecture, commercial model, IP terms, liability and exit.
Ask those eight questions of every provider you shortlist. The answers will separate them far more clearly than any feature list.
Scoping your own launch?
We map your programmes, rules, integrations and payment rails on a thirty-minute call, then send a closed quote. No revenue share, no percentage of your traders.