Why this dispatch exists
This is the thirty-fourth dispatch and the ninth in the Phase 4 operationally-actionable artefact sub-series. The earlier Phase 4 dispatches covered the RFP scoring framework opener plus seven per-pillar toolkits (KYC, RegTech, broker CRM, LP procurement, payments procurement, brokerage hosting, risk management). This dispatch covers the eighth per-pillar evaluation toolkit: trading platform procurement.
Trading platform procurement is the most consequential procurement decision in the corpus because the platform choice constrains every downstream procurement: the CRM is influenced by the platform (B2Core with B2BX, Match-Trader CRM with Match-Trader); LP integration is constrained by the platform (FIX-API depth varies by platform); the risk management vendor must integrate at the platform layer per the risk management toolkit; analytics widgets must be compatible with the platform; copy trading vendors depend on the platform per the architectural archetypes in the copy trading deep dive.
The trading platform deep dive covered the MT4-to-MT5 default flip (2022: “MT4 by default, MT5 by exception” → 2026: “MT5 by default, MT4 by exception”), cTrader institutional-leaning positioning with Spotware Store published pricing as the chapter benchmark, Match-Trader broker-friendly positioning with crypto-CFD strength and Match-Trader CRM multi-tenant integration, Sirix and other bundled platform options, TradingView-powered emerging category as Year-2-or-later addition to existing MT5 or cTrader procurement, and per-archetype platform fit covering A through H.
This toolkit operationalises the procurement-stage RFP filters that operators apply during trading platform procurement.
Trading platform procurement scope recap
The trading platform procurement scope spans four distinct categories:
MetaTrader (MT4/MT5). Default procurement across all CFD-touching archetypes (A-G). The platform that dominates retail CFD broker deployments. Procurement-relevant question is MT5 (default for new procurement) versus MT4 (explicit justification required).
Alternative white-label platforms (cTrader, Match-Trader, Sirix, others). Secondary platform procurement alongside MT5 as differentiated client experience layer. The alt-WL platforms deep dive covered per-jurisdiction extension; the alt-WL-as-second-platform pattern surfaced across all four archetype dispatches.
TradingView-powered deployments. Year-2-or-later addition to existing MT5 or cTrader procurement. Procurement-relevant for operators wanting differentiated client experience without primary platform replacement.
Institutional execution platforms. Integral, Currenex, FXall for ADGM Archetype H institutional broker procurement. Distinct procurement framework from retail and mass-market platform procurement covered separately for institutional operators.
The toolkit below covers MT4/MT5, cTrader, Match-Trader, and Sirix procurement as primary scope; TradingView-powered procurement and institutional execution platform procurement follow abbreviated evaluation frameworks at the end.
Procurement-stage questionnaire template
The questionnaire template includes 34 specific RFP questions structured by platform category plus framework dimension.
Universal dimensions (5 questions per the Phase 4 opener)
- Provide your pricing structure including licensing fees, per-user pricing if applicable, optional module pricing, integration costs, and ongoing support costs.
- List your relevant certifications including ISO 27001, SOC 2 Type II, jurisdiction-specific certifications.
- Describe your customer support structure including dedicated TAM availability, support response SLAs, escalation paths.
- Provide your most recent financial position disclosure.
- Describe your product roadmap including specific feature commitments, technology investments, and regulatory readiness commitments.
MetaTrader procurement dimensions (6 questions)
- (MT4/MT5 procurement) Confirm your MT5 versus MT4 default positioning. For operators selecting MT4, document explicit justification including specific EA compatibility requirements, regional preference rationale, and legacy ecosystem requirements.
- Describe your MetaQuotes licensing positioning including current licensing terms, MetaQuotes-side licensing commitment, and operator-side migration support if licensing changes.
- Describe your MT5 platform configuration including specific platform version, plugin compatibility (server-side and client-side plugins), and operator-side customisation envelope.
- Describe your MT4 maintenance positioning for operators with substantial MT4 installed base including operational support continuity, parallel MT4/MT5 operation support, and operator-side migration timeline support.
- Describe your MT5 multi-asset capability including FX, CFDs on stocks, indices, commodities, options, futures, and crypto-asset trading native support.
- Provide reference operators in similar archetype with MT4 versus MT5 deployment patterns and operational tenure.
cTrader procurement dimensions (5 questions)
- (cTrader procurement) Describe your Spotware Store pricing structure including specific Pro Trader pricing, cBot subscription tiers, and operator-side per-trader cost calculation.
- Describe your cTrader Copy native integration including configurable network scope (closed versus open), Spotware Store pricing alignment, and operator-side integration support.
- Describe your cTrader multi-asset coverage including FX, CFDs on stocks, indices, commodities, and crypto-asset trading.
- Describe your institutional execution mechanics including central limit order book matching, level-2 market depth display, FIX API support, and operator-side execution transparency.
- Provide tier-1 CySEC reference deployments and other archetype reference operators with cTrader operational tenure.
Match-Trader procurement dimensions (5 questions)
- (Match-Trader procurement) Describe your Match-Trader CRM integration tightness including specific feature integration, multi-tenant configuration support (per the broker CRM toolkit), and operator-side procurement consolidation.
- Describe your crypto-CFD strength including specific crypto-CFD product configuration, broker-friendly margin and leverage policy support, and per-jurisdiction crypto-CFD enforcement.
- Describe your hybrid operator broker-ID separation capability including separable broker-ID groups within a single MT5 instance, per-group risk management configuration, and per-group reporting isolation.
- Describe your bundled risk management and IB modules including module sufficiency at lean scale, specialist procurement path at mid-market, and operator-side scale-tier graduation support.
- Provide reference operators with Match-Trader platform deployment scale and operational characteristics.
Sirix and bundled platform dimensions (3 questions)
- (Sirix procurement) Describe your Leverate stack lock-in implications including dual lock-in between Sirix platform and LXSuite CRM, operator-side stack replacement implications, and operator-side flexibility limitations.
- Describe your Sirix platform features including AI-driven retention features, broker-side configuration capability, and operator-side customisation envelope.
- Provide reference operators with Sirix platform deployment scale and operational tenure within the Leverate stack.
Multi-asset depth dimensions (4 questions)
- Provide multi-asset depth across operator’s specific instrument set including FX majors, FX minors, indices, commodities, single-stock CFDs, options, futures, crypto-asset CFD (with regulatory positioning), and ETFs if applicable.
- Describe your corporate action handling for single-stock CFDs including dividend handling, stock split handling, and short-availability handling.
- Describe your options trading capability if applicable including Greeks display, options chains, expiry handling, and operator-side risk management integration.
- Describe your crypto-CFD versus crypto-venue regulatory separation including per-archetype regulatory positioning (crypto-CFD inside CFD platform versus VARA or CASP-supervised crypto venue separate procurement).
Customisation envelope dimensions (3 questions)
- Describe your branding customisation depth including logo placement, colour scheme configuration, custom domain hosting, and client cabinet branding integration.
- Describe your UX customisation depth including custom widget placement, custom dashboard configuration per user role, custom workflow definitions, and operator-side UX engineering support.
- Describe your integration customisation including CRM integration (native versus API versus manual), KYC integration, PSP integration, analytics integration, and copy trading integration.
Phase 4 framework alignment (3 questions)
- How does your product address the per-archetype platform fit covered in the trading platform deep dive? Specifically: how does your product support the operator’s specific archetype context?
- How does your product handle the alt-WL-as-second-platform pattern surfaced across archetype dispatches? Specifically: integration with operator’s primary MT5 deployment if applicable.
- Describe your contract terms including pricing escalation methodology, contract length, data portability provisions on termination, and operator-side switching cost mitigation.
Reference customer questions
The 16 reference customer questions structure operator-side diligence:
Operational reality (6 questions)
- How long has your operation been using this platform and at what client account scale?
- Did the platform’s RFP-stage capability disclosure match the operational reality you experienced post-deployment? Specifically: were there multi-asset depth gaps, customisation envelope limits, or integration gaps?
- How does the platform perform at production scale including order processing latency, market data feed quality, and platform stability under peak load?
- (For MT4/MT5 deployments) How clean is the platform vendor’s parallel MT4/MT5 operation if applicable? Have you encountered MetaQuotes licensing changes during the operational relationship?
- (For cTrader deployments) How accurate is the Spotware Store pricing positioning in operational reality? Are operator-side per-trader cost calculations aligned with pre-contract estimates?
- (For Match-Trader deployments) How clean is the Match-Trader CRM integration tightness in operational reality? Have you encountered cross-vendor integration gaps?
Procurement specifics (5 questions)
- How did the platform vendor handle the procurement decision process? Were they responsive to RFP iterations including multi-asset depth testing and customisation envelope testing?
- What contract terms did you actually achieve versus the vendor’s positioning? Specifically: pricing escalation, contract length, data portability provisions.
- (For bundled platform procurement) How did the dual lock-in between platform and CRM affect operational flexibility in retrospect?
- (For cross-vendor configurations) How did the loose-coupling integration hold up across platform version upgrades?
- Has the platform vendor’s roadmap delivery matched the roadmap visibility provided during procurement?
Operational quality (5 questions)
- (For Multi-asset deployments) How accurate is the platform’s multi-asset coverage in operational reality? Specifically: corporate action handling, options trading mechanics, crypto-CFD enforcement.
- (For per-jurisdiction operations) How clean is the platform’s per-jurisdiction leverage cap configurability? Specifically for APAC and DMCC operators.
- (For copy trading native deployments) How accurate is the cTrader Copy or Match-Trader Copy native integration in operational reality?
- How responsive is the platform vendor to regulatory developments including MiFID II updates, MiCAR Title VI implementation, or jurisdiction-specific regulatory shifts?
- Would you procure this platform again given the same procurement decision context? Why or why not?
Demo evaluation rubric
The 12-test rubric structures operator-side demo evaluation:
Demo Test 1: Live order execution testing with operator-provided test trade sequence.
Pass criteria: platform demonstrates order placement, modification, cancellation, and execution flow including explicit execution latency metrics and audit trail completeness. Fail criteria: order flow gaps; execution latency opaque; audit trail incomplete.
Demo Test 2: Multi-asset depth testing with operator-specified instrument set.
Pass criteria: platform demonstrates depth across operator’s specific instrument set including specific instrument support, spread characteristics, and operator-side risk management integration. Fail criteria: instrument coverage gaps; spread characteristics opaque; risk management integration not demonstrated.
Demo Test 3: Per-jurisdiction leverage cap configurability testing.
Pass criteria: platform demonstrates per-regulatory-regime leverage configuration including ESMA 1:30, DMCC 1:200-500, FCA, ASIC 1:30, MAS 1:20, FSA 1:25 depending on operator’s jurisdiction set. Fail criteria: leverage configuration hardcoded; per-regulatory-regime support limited.
Demo Test 4: Multi-language client cabinet testing with operator-specified language set.
Pass criteria: platform demonstrates native translation depth for operator’s specific languages including UI translation completeness, content translation quality, and locale-specific formatting. Fail criteria: language coverage gaps; translation quality machine-translated equivalent for non-English; RTL layout absent for Arabic if relevant.
Demo Test 5: cTrader Copy native integration demonstration (cTrader procurement).
Pass criteria: cTrader demonstrates copy trading native integration including configurable network scope, Spotware Store pricing alignment, and operator-side integration. Fail criteria: copy trading integration shallow; pricing alignment opaque; operator-side integration limited.
Demo Test 6: Match-Trader CRM integration tightness demonstration (Match-Trader procurement).
Pass criteria: Match-Trader demonstrates CRM integration tightness including multi-tenant configuration support, hybrid broker-ID separation capability, and operator-side procurement consolidation. Fail criteria: CRM integration loose; multi-tenant support limited; broker-ID separation absent.
Demo Test 7: Customisation envelope demonstration with operator-provided branding assets.
Pass criteria: platform demonstrates branding customisation, layout customisation, widget placement, and dashboard configuration per user role with operator-provided assets. Fail criteria: UX customisation limited; per-role dashboard absent; branding gaps in mobile experience.
Demo Test 8: Integration with operator’s downstream procurement walkthrough.
Pass criteria: platform demonstrates integration with operator’s specific CRM, LP set, risk management vendor, and analytics widget set with explicit integration depth. Fail criteria: integration gaps surfaced; specific vendor compatibility absent.
Demo Test 9: TradingView-powered deployment demonstration (if TradingView-powered procurement).
Pass criteria: platform demonstrates TradingView-powered deployment including charting interface integration, trade execution integration, and operator-side branding application. Fail criteria: TradingView integration shallow; trade execution gaps; operator-side branding limited.
Demo Test 10: Crypto-CFD versus crypto-venue regulatory separation demonstration (crypto-touching).
Pass criteria: platform demonstrates crypto-CFD enforcement within CFD platform per operator’s regulatory positioning, with explicit separation from CASP-supervised crypto venue procurement. Fail criteria: regulatory separation absent; crypto-CFD enforcement weak; per-jurisdiction enforcement limited.
Demo Test 11: Performance testing at operator’s expected production volume.
Pass criteria: platform demonstrates order processing latency, market data feed quality, and platform stability at operator’s expected production trade volume. Fail criteria: latency degrades under load; market data feed gaps; stability not demonstrated.
Demo Test 12: Disaster recovery and incident response demonstration.
Pass criteria: platform demonstrates incident response framework including outage notification timing, operator-side communication, and backup operations. Fail criteria: incident response opaque; notification timing inadequate; backup operations absent.
Integration testing protocol
Trading platform integration testing protocol structures operator-side pre-go-live testing:
- Platform deployment testing. Test platform deployment in operator’s specific environment including server installation, network configuration, and platform configuration.
- Multi-asset configuration testing. Test multi-asset configuration including operator’s specific instrument set, spread configuration, and risk parameters.
- CRM integration testing. Test platform integration with operator’s CRM including client lifecycle integration, deposit/withdrawal flow, and KYC handoff.
- LP integration testing. Test platform integration with operator’s LP set including FIX-API connectivity, market data feed integration, and order routing flow.
- Risk management integration testing. Test platform integration with operator’s risk management vendor including pre-trade controls execution, post-trade analytics flow, and operator-side risk team workflow.
- Analytics integration testing. Test platform integration with operator’s analytics widget set (Trading Central, Autochartist, etc.) including widget rendering and client cabinet integration.
- Copy trading integration testing. Test platform integration with operator’s copy trading vendor including signal provider integration, follower flow, and operator-side compliance integration.
- Multi-language client cabinet testing. Test operator’s specific language set including UI translation, content translation, and locale-specific formatting.
- Per-jurisdiction leverage configuration testing. Test per-regulatory-regime leverage enforcement across operator’s specific jurisdiction set.
- Performance and load testing at production volume. Test platform performance including order processing latency, market data feed quality, and platform stability under peak load.
- Mobile client cabinet testing. Test mobile experience across iOS, Android, and mobile web platforms.
- End-to-end production simulation. Simulate full production trading day including pre-market, market opening, intraday trading, and end-of-day reconciliation.
Integration testing typically takes 8-16 weeks for trading platform deployments because the platform integration depth touches every downstream procurement. Operators should treat integration testing as the critical path for go-live.
Decision documentation template
Section 1: Procurement context
- Operator regulatory positioning and archetype identification
- Trading platform procurement scope (primary platform + secondary alt-WL if applicable + TradingView-powered if applicable)
- MT5 versus MT4 default rationale
- Procurement timing and decision process
Section 2: Vendor shortlist
- List of platforms evaluated per category
- Initial screening criteria including per-archetype platform fit
- RFP distribution and response timing
- Platforms disqualified at initial screening with reasoning
Section 3: RFP evaluation
- Universal dimensions scoring per platform
- Platform-specific dimensions scoring
- Per-archetype customisation applied
- Disqualification thresholds applied
Section 4: Reference customer diligence
- Reference operator list per shortlisted platform
- Reference responses summarised
- Multi-asset depth operational reality documentation
- Customisation envelope operational reality documentation
- Reference diligence-driven scoring adjustments
Section 5: Demo evaluation
- Demo dates and participants per shortlisted platform
- Demo evaluation rubric results across 12 tests
- Multi-asset depth demonstration documentation
- Per-jurisdiction leverage configuration demonstration documentation
- Demo-driven scoring adjustments
Section 6: Integration testing
- Integration testing dates and scope per shortlisted platform
- Engineering work timeline including specific milestones
- Multi-downstream integration testing documentation (CRM + LP + risk + analytics + copy trading)
- Capability gaps identified with platform vendor remediation commitments
Section 7: Procurement decision
- Final platform ranking with weighted total scoring
- Selected primary platform with explicit decision rationale
- Selected secondary platform if applicable with rationale
- TradingView-powered procurement decision if applicable
- Contract terms summary including specific contract length and termination provisions
Section 8: Ongoing monitoring
- Operator-side platform performance monitoring framework
- KPI definitions including order processing latency, market data feed quality, platform stability
- Platform vendor relationship review cycle
- Procurement decision review triggers (platform vendor M&A, MetaQuotes licensing changes, regulatory shifts, scale-tier graduation milestones, capability gaps)
What comes next in Phase 4
Future Phase 4 artefacts will extend coverage:
- Additional per-pillar evaluation toolkits. Broker analytics, copy trading, IB management, prop firm tech, alt-WL platforms, crypto exchange WL, turnkey suites toolkits.
- Per-archetype RFP templates.
- Vendor evidence library.
- Institutional procurement toolkit (Archetype H specific).
Phase 4 corpus state after this dispatch:
- 25 Phase 3 synthesis dispatches
- 9 Phase 4 operationally-actionable artefacts
- TOTAL: 34 dispatches
If you operate a broker stack with active trading platform procurement consideration and the toolkit above does not match your procurement process reality, that is the editorial signal we are looking for. The corpus improves through ground-truth from operators.