DISPATCH ·

Broker analytics + market signals procurement evaluation toolkit (Phase 4 per-pillar artefact)

Thirty-seventh dispatch. Eleventh per-pillar Phase 4 evaluation toolkit. Operationalises the broker analytics deep dive's three structurally distinct vendor layers (trader-facing widgets, institutional data feeds, CASP-specific analytics), the 2-4-parallel-products procurement pattern by scale tier, the FXStreet post-ATFX procurement reframing, the localisation depth as procurement filter for multi-language operators, and the CASP analytics structural separation from CFD broker analytics.

tags · phase-4 · broker-analytics · evaluation-toolkit · operational-artefact

Why this dispatch exists

This is the thirty-seventh dispatch and the twelfth in the Phase 4 operationally-actionable artefact sub-series. The broker analytics deep dive covered the three structurally distinct vendor layers (trader-facing widgets, institutional data feeds, CASP-specific analytics), the 2-4-parallel-products pattern by scale tier (lean 2 products; lower-mid 3-4; upper-mid 4-5; tier-1 5-8), the FXStreet ATFX acquisition reframing the vendor from independent FX news provider to broker-affiliated content source, and the CASP analytics structural separation from CFD broker analytics.

This toolkit operationalises the procurement-stage RFP filters operators apply during analytics vendor procurement, recognising that operators procure multiple analytics vendors in parallel rather than as a single primary procurement.

Broker analytics procurement scope recap

The procurement scope spans:

Trader-facing widgets. Trading Central, Autochartist, FXStreet (post-ATFX), Investing.com, Myfxbook integration. Universal across CFD-touching archetypes (A-G); typically 2 vendors procured in parallel at mid-market.

Institutional data feeds. Acuity, Newsquawk, Refinitiv (LSEG), Bloomberg Terminal. Procurement-relevant at mid-market with institutional client segments; STRONG PICK for institutional Archetype H from Day 1.

Engagement analytics. Solitics, Myfxbook integration. Distinct from market signals; covers client behaviour and retention analytics.

CASP-specific analytics. CoinGecko Terminal, Glassnode, Messari Pro, Kaiko, Chainalysis Market Intel. Structurally separate vendor set from CFD broker analytics for crypto-touching archetypes.

Procurement-stage questionnaire (30 RFP questions)

Universal (5)

  1. Provide pricing structure including per-seat pricing, content licensing fees, integration costs.
  2. List certifications including ISO 27001, SOC 2 Type II.
  3. Describe customer support including TAM availability and SLAs.
  4. Provide financial position disclosure.
  5. Describe product roadmap including content expansion and regulatory readiness.

Trader-facing widget dimensions (7)

  1. (Trading Central / Autochartist / FXStreet) Describe content quality methodology including signal accuracy verification, update frequency, and operator-side accuracy reporting.
  2. Describe multi-language localisation depth including specific languages with native translation vs machine-translated coverage.
  3. (FXStreet specifically post-ATFX) Describe positioning post-acquisition including editorial independence framework, ATFX-affiliation disclosure to operator’s clients, and operator-side procurement reframing.
  4. Describe platform integration tightness including specific platform compatibility (MT4/MT5/cTrader/Match-Trader) and operator-side branding integration.
  5. Describe per-seat pricing structure including operator-side per-trader cost calculation and bundling discount methodology.
  6. Describe API and data feed integration architecture.
  7. Provide reference operators in operator’s archetype with deployment scale.

Institutional data feed dimensions (6)

  1. Describe institutional content depth including economic calendar accuracy, news intelligence depth, and sentiment analytics methodology.
  2. Describe Bloomberg Terminal pricing structure if applicable including per-terminal annual pricing (typically EUR 24,000-30,000 per terminal) and operator-side terminal allocation.
  3. Describe institutional client distribution rights including specific client tiers eligible for content distribution.
  4. Describe operator-side analytics integration including proprietary analytics extension capability.
  5. Describe regulatory framework alignment including FCA RTS 27 best execution data integration if applicable.
  6. Provide tier-1 institutional reference operators.

CASP-specific dimensions (5, crypto-touching)

  1. (CASP-touching archetypes) Describe crypto-asset content depth including specific token coverage, on-chain analytics methodology (if Glassnode-equivalent), and institutional crypto signals quality.
  2. Describe CASP-aligned pricing structure and institutional-versus-retail client distribution.
  3. Describe CASP-specific regulatory positioning including MiCAR-aligned content if relevant.
  4. Describe integration with operator’s CASP venue and risk management framework.
  5. Provide CASP reference operators with deployment characteristics.

Engagement analytics dimensions (4)

  1. (Solitics / engagement analytics) Describe client behaviour analytics methodology including retention scoring, churn prediction, and operator-side retention campaign integration.
  2. Describe operator-side internal team dashboard including specific KPIs surfaced and multi-language dashboard support.
  3. Describe integration with operator’s CRM including client lifecycle analytics handoff.
  4. Provide reference operators with engagement analytics deployment.

Phase 4 framework alignment (3)

  1. How does your product align with the 2-4-parallel-products procurement pattern by scale tier?
  2. How does your product handle operator’s specific archetype customisation?
  3. Describe contract terms including pricing escalation, contract length, data portability.

Reference customer questions (14)

Operational reality (6)

  1. How long has your operation been using this vendor and at what scale?
  2. Did capability disclosure match operational reality? Specifically: content quality, localisation depth, platform integration.
  3. How accurate is content in operational reality? Specifically: signal accuracy, calendar accuracy, news timing.
  4. (FXStreet) How did ATFX acquisition affect content positioning in operational reality?
  5. (Institutional feeds) How accurate is institutional content depth versus pre-contract positioning?
  6. How responsive is vendor’s product to regulatory developments?

Procurement specifics (4)

  1. How did vendor handle procurement decision process?
  2. What contract terms did you achieve versus positioning?
  3. (Multi-vendor procurement) How did vendor integrate alongside operator’s other parallel analytics vendors?
  4. Has roadmap delivery matched procurement-stage visibility?

Operational quality (4)

  1. (For multi-language deployments) How accurate is localisation depth for specific languages?
  2. (For institutional procurement) How responsive is institutional support during market stress events?
  3. (For CASP procurement) How accurate is crypto-asset content depth?
  4. Would you procure this vendor again given the same procurement decision context?

Demo evaluation rubric (10 tests)

Test 1: Content quality demonstration with operator-provided test scenarios.

Pass: vendor demonstrates content accuracy against operator-provided historical events with explicit accuracy verification. Fail: content accuracy shallow; verification absent.

Test 2: Multi-language localisation demonstration.

Pass: vendor demonstrates native translation depth for operator’s specific language set. Fail: language coverage gaps; translation quality machine-translated equivalent.

Test 3: Platform integration demonstration with operator’s specific platform set.

Pass: vendor demonstrates native integration with operator-specified platform including widget rendering and branding integration. Fail: integration shallow; specific platforms not supported.

Test 4: FXStreet ATFX-affiliation positioning demonstration.

Pass: FXStreet demonstrates current editorial framework post-ATFX including affiliation disclosure and operator-side procurement reframing support. Fail: positioning opaque; affiliation disclosure absent.

Test 5: Institutional content depth demonstration.

Pass: institutional vendor demonstrates content depth including economic calendar accuracy, news intelligence, and sentiment analytics. Fail: institutional depth shallow.

Test 6: Bloomberg Terminal walkthrough.

Pass: Bloomberg demonstrates terminal capability including operator-relevant news flows, market data, and analytics. Fail: terminal capability not demonstrated.

Test 7: CASP-specific content demonstration (crypto-touching).

Pass: vendor demonstrates crypto-asset content depth including specific token coverage and on-chain analytics if applicable. Fail: crypto-asset content shallow.

Test 8: Engagement analytics demonstration.

Pass: engagement analytics vendor demonstrates client behaviour scoring, retention campaign integration, and operator-side dashboard. Fail: engagement analytics shallow.

Test 9: Integration with operator’s CRM walkthrough.

Pass: vendor demonstrates integration with operator-specified CRM. Fail: CRM integration gaps.

Test 10: Multi-vendor coexistence demonstration.

Pass: vendor demonstrates coexistence with operator’s other parallel analytics vendors. Fail: coexistence framework absent.

Integration testing protocol (8 pre-signature tests)

  1. Sandbox access and API documentation review.
  2. Platform integration testing with operator-specified platforms.
  3. Multi-language client cabinet integration.
  4. Multi-vendor coexistence testing with operator’s parallel analytics vendors.
  5. CRM integration testing.
  6. (Institutional procurement) Internal team workflow integration with operator’s analytics team.
  7. (CASP procurement) Integration with operator’s CASP venue and risk management framework.
  8. End-to-end production simulation.

Integration testing typically 3-6 weeks for analytics vendor deployments.

Decision documentation template (8 sections)

  1. Procurement context including 2-4-parallel-products scale tier rationale and procurement scope per vendor layer.
  2. Vendor shortlist per layer including initial screening criteria.
  3. RFP evaluation per vendor with multi-vendor coexistence scoring.
  4. Reference customer diligence including FXStreet post-ATFX reframing documentation if applicable.
  5. Demo evaluation per vendor with multi-vendor coexistence demonstration documentation.
  6. Integration testing per vendor with multi-vendor coexistence testing documentation.
  7. Procurement decision per vendor with scale-tier rationale per the 2-4-parallel-products pattern.
  8. Ongoing monitoring with vendor M&A and content positioning shifts as procurement decision review triggers.

Phase 4 corpus state

  • 25 Phase 3 + 12 Phase 4 = 37 dispatches.