DISPATCH ·

Broker CRM procurement evaluation toolkit (Phase 4 per-pillar artefact)

Twenty-ninth dispatch. Third per-pillar Phase 4 evaluation toolkit. Operationally-actionable artefact for Chapter IV broker CRM procurement covering the multi-tenant configuration patterns identified in the hybrid archetype dispatch as the second-most-consequential procurement choice, the CRM-to-platform integration tightness lock-in axis, the four client cabinet design dimensions, and the four CASP-specific CRM requirements. The toolkit provides procurement-stage questionnaire template (33 specific RFP questions), reference customer questions (16 questions tuned for CRM operational realities), demo evaluation rubric (12 demo tests covering multi-tenant testing, platform integration verification, multi-language depth, and CASP-specific extensions with pass/fail criteria), integration testing protocol (10 pre-signature tests), and decision documentation template.

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

Why this dispatch exists

This is the twenty-ninth dispatch and the fourth in the Phase 4 operationally-actionable artefact sub-series opened by the RFP scoring framework dispatch and continued in the KYC evaluation toolkit dispatch and RegTech evaluation toolkit dispatch. This dispatch covers the third per-pillar evaluation toolkit: broker CRM procurement.

Broker CRM procurement is the operational backbone procurement that constrains many downstream procurement decisions. The broker CRM deep dive covered three multi-tenant configuration patterns that the hybrid archetype dispatch identified as the second-most-consequential procurement choice for hybrid operators, the CRM-to-platform integration tightness lock-in axis that affects platform swapability for all eight archetypes, the four client cabinet design dimensions (localisation, multi-currency wallets, KYC handoff design, payment flow integration depth), and the four CASP-specific CRM requirements that most CFD broker CRMs do not handle natively without configuration or third-party integration.

The 2026 procurement-relevant question is concrete multi-tenant testing, platform integration verification, multi-language depth validation, and CASP-specific extension demonstration at procurement-stage rather than at post-signature integration testing. This toolkit provides operationally-actionable artefacts that operators apply directly during broker CRM procurement.

Broker CRM procurement scope recap

The broker CRM procurement scope spans:

Primary CRM tenant for operator entity. Single-tenant CRM deployment for pure CFD broker operations (Archetypes A, B, F, G) or single-entity components of multi-entity operations. Universal procurement requirement.

Multi-tenant configuration for hybrid and dual-licensed operators. Multi-tenant CRM supporting per-entity logical separation with parent organisation visibility layer. Critical for hybrid Archetype C and EU dual-licensed Archetype E.

CRM-to-platform integration. Native integration with operator’s trading platform (MT5, cTrader, Match-Trader, B2BX for CASP). Universal procurement requirement across all archetypes.

Client cabinet customisation. Multi-language depth, multi-currency wallet structure, KYC handoff design, payment flow integration. Universal with per-archetype intensity (APAC and LATAM operators face higher multi-language depth requirements; CASP operators face wallet attribution requirements).

Institutional CRM (Archetype H specific). Salesforce Financial Services Cloud or specialist institutional broker CRM rather than retail-oriented broker CRMs. The ADGM FSRA institutional dispatch covered the structural distinction.

The toolkit below covers retail and mass-market broker CRM procurement (Archetypes A through G); institutional Archetype H CRM procurement follows a structurally different evaluation framework that future Phase 4 artefacts will cover separately.

Procurement-stage questionnaire template

The questionnaire template includes 33 specific RFP questions structured by dimension.

Universal dimensions (5 questions per the Phase 4 opener)

  1. Provide your pricing structure for the operator’s expected scale envelope including base pricing per active account, per-tenant pricing for multi-tenant configurations, optional module pricing (IB modules, KYC integration, analytics integration), integration costs, and ongoing support costs.
  2. List your relevant certifications (ISO 27001, SOC 2 Type II, jurisdiction-specific certifications) with current status.
  3. Describe your customer support structure including dedicated technical account management availability, support response SLAs, and operator-side escalation paths.
  4. Provide your most recent financial position disclosure including parent company disclosure framework if applicable.
  5. Describe your product roadmap visibility for the operator’s 3-5 year procurement horizon including specific feature commitments and regulatory readiness investments.

Multi-tenant configuration dimensions (6 questions)

  1. Describe your multi-tenant configuration capability including supported patterns (one CRM with two record types; two CRMs with integration layer; one CRM tenant per entity with shared parent). Indicate which patterns your product supports natively versus through configuration or custom development.
  2. (For Pattern 3 native support) Describe the parent organisation visibility layer including data segregation enforcement at database level, parent-side analytics across entities, and per-entity logical isolation.
  3. Describe data segregation enforcement methodology including database-level separation, row-level security, encryption per tenant, and audit trail per tenant.
  4. Describe per-tenant configuration capability including per-tenant branding, per-tenant workflow customisation, per-tenant integration configuration, and per-tenant compliance configuration.
  5. (Hybrid Archetype C specific) Describe per-broker-ID segmentation capability within a single tenant including separable IB attribution per broker-ID group and separate compliance configuration per group.
  6. Provide reference customers running multi-tenant deployments at the operator’s expected scale including specific deployment patterns and operational tenure.

CRM-to-platform integration dimensions (5 questions)

  1. List your native platform integrations including MT4, MT5, cTrader, Match-Trader, B2BX, Sirix, Quadcode platforms. For each platform indicate integration depth (data flow, order flow, client lifecycle integration).
  2. Describe your loose-coupling integration capability for cross-vendor platform combinations (e.g. operator’s CRM with non-bundled platform).
  3. Describe your integration testing methodology including operator-side test environment provision, integration regression testing across platform version upgrades, and operator-side certification process for new platform integrations.
  4. Describe your API architecture for operator-side custom integration including authentication, rate limiting, webhook patterns, and operator-side integration timeline estimates.
  5. Describe your platform-bundled procurement positioning including dual lock-in implications and operator-side switching cost mitigation.

Client cabinet design dimensions (8 questions)

  1. List your supported languages including native translation depth versus machine-translation coverage. Provide specific language list including European languages, Asian languages (Mandarin simplified and traditional, Cantonese, Japanese, Korean), Middle Eastern languages (Arabic, Farsi), Indian subcontinent languages (Hindi, Urdu, Bengali, Tamil), and LATAM languages (Spanish and Brazilian Portuguese distinct).
  2. (LATAM-relevant) Describe your distinct Spanish and Brazilian Portuguese tracks including separate content translation, locale-specific number and date formatting, and regional cultural localisation depth.
  3. (APAC-relevant) Describe your RTL (right-to-left) layout support for Arabic and locale-appropriate display for Asian languages.
  4. Describe your multi-currency wallet structure including supported wallet currencies (USD, EUR, GBP, regional currencies), per-currency segregation, FX conversion at deposit and withdrawal events, and tax reporting per wallet.
  5. Describe your KYC handoff design including native KYC integration (which Phase 2 KYC vendors), API-based integration architecture, and operator-built integration support.
  6. Describe your payment flow integration depth including native PSP integrations, payment flow UX (single-step versus multi-step with verification of payee per the payments dispatch), and reconciliation flow between PSP statements and client balances.
  7. Describe your client cabinet UX customisation capability including branding, layout, widget placement, dashboard configuration per user role, and custom workflow definition.
  8. Describe your client mobile experience including native iOS and Android applications, mobile web experience, and per-platform feature parity.

CASP-specific dimensions (5 questions)

  1. (Crypto-touching archetypes) Describe your wallet address management at client record level including supported chains, verification method (Travel Rule integration, signature verification), verification date tracking, and ongoing wallet activity monitoring.
  2. Describe your transaction history with blockchain hash references as first-class transaction type or metadata extension. Explain data model implications for reporting and tax handling.
  3. Describe your supported asset configuration per client jurisdiction including granularity (per-token, per-token-pair, per-asset-class), programmatic update capability, and audit trail completeness.
  4. Describe your fiat-crypto conversion history for tax reporting including conversion rate sources, timestamp accuracy, and tax-jurisdiction-specific calculation capability.
  5. (CASP under MiCAR) Describe your MiCAR-aligned product positioning including supervised reporting hooks, custody integration architecture, and Travel Rule integration layer.

Phase 4 framework alignment (4 questions)

  1. How does your product align with the multi-tenant configuration patterns covered in the broker CRM deep dive? Which pattern do you support natively?
  2. How does your product handle the CRM-to-platform integration tightness lock-in axis? Specifically: dual lock-in versus independent swappability positioning.
  3. How does your product address the four CASP-specific CRM requirements (wallet address management, blockchain hash transaction history, asset configuration per jurisdiction, fiat-crypto conversion history)?
  4. Describe your contract terms including pricing escalation methodology, data portability provisions on termination, switching cost mitigation, and post-acquisition framework positioning if applicable.

Reference customer questions

The 16 reference customer questions structure operator-side diligence:

Operational reality (6 questions)

  1. How long has your operation been using this vendor and at what deployment scale including specific multi-tenant configuration if relevant?
  2. Did the vendor’s RFP-stage capability disclosure match the operational reality you experienced post-deployment? Specifically: were there multi-tenant configuration gaps, platform integration gaps, or client cabinet customisation gaps?
  3. What was your integration timeline from contract signature to production deployment? Did it match the vendor’s pre-contract estimate?
  4. How does the vendor’s product perform at your production scale including data segregation enforcement, multi-tenant query performance, and concurrent user handling?
  5. (For multi-tenant deployments) How clean is the per-tenant logical separation in your operational reality? Specifically: have you encountered cross-tenant data leakage incidents or audit trail gaps?
  6. How frequently do you encounter operational issues requiring vendor support intervention? What is the typical resolution time?

Procurement specifics (5 questions)

  1. How did the vendor handle the procurement decision process? Were they responsive to RFP iterations including multi-tenant pattern selection questions?
  2. What pricing did you actually pay versus the pricing positioning during procurement? Were there per-tenant pricing escalations or unexpected module costs?
  3. (For platform-bundled procurement) Did the dual lock-in between CRM and platform produce switching costs you would prefer to avoid in retrospect?
  4. (For cross-vendor configurations) How did the loose-coupling integration hold up across platform version upgrades?
  5. Has the vendor’s roadmap delivery matched the roadmap visibility provided during procurement?

Operational quality (5 questions)

  1. (For multi-language deployments) How accurate is the vendor’s translation depth for your specific client geography? Specifically: are non-English languages native quality or machine-translated equivalent?
  2. (For CASP deployments) How accurate is the vendor’s wallet attribution layer in your operational reality? Specifically: have you encountered wallet verification failures or chain coverage gaps?
  3. (For multi-currency deployments) How clean is the vendor’s FX conversion at deposit and withdrawal events? Specifically: are conversion rates competitive and tax reporting compliant?
  4. How responsive is the vendor’s product to regulatory developments including EU AMLR transition, MiCAR Title VI implementation, or other relevant shifts?
  5. Would you procure this vendor again for the same components 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: Multi-tenant configuration with two test entities under shared parent.

Pass criteria: vendor demonstrates two distinct entity tenants with logical separation at database level plus parent organisation visibility layer with explicit data segregation enforcement. Fail criteria: multi-tenant only at metadata level; cross-tenant data leakage; parent visibility absent.

Demo Test 2: Per-tenant configuration testing.

Pass criteria: vendor demonstrates per-tenant branding, per-tenant workflow customisation, and per-tenant integration configuration without cross-tenant interference. Fail criteria: per-tenant configuration limited; configuration changes affect other tenants; configuration not demonstrated.

Demo Test 3: Platform integration with operator-specified platform.

Pass criteria: vendor demonstrates native integration with operator-specified platform (MT5, cTrader, Match-Trader, etc.) including client lifecycle integration (deposit, withdrawal, trade activity, KYC handoff). Fail criteria: platform integration limited; client lifecycle gaps; integration requires custom development.

Demo Test 4: Cross-vendor platform integration testing.

Pass criteria: vendor demonstrates loose-coupling integration with cross-vendor platform combinations relevant to the operator’s procurement consideration. Fail criteria: cross-vendor integration not supported; integration requires significant custom development; loose-coupling positioning shallow.

Demo Test 5: Multi-language depth with operator-specified language set.

Pass criteria: vendor demonstrates native translation depth for operator’s specific languages including UI translation completeness, content translation quality, and locale-specific formatting (numbers, dates, currency). Fail criteria: language coverage gaps; translation quality machine-translated equivalent for non-English; RTL layout absent for Arabic if relevant.

Demo Test 6: Multi-currency wallet structure testing.

Pass criteria: vendor demonstrates per-currency wallet segregation, FX conversion at deposit and withdrawal events, and tax reporting per wallet with concrete examples. Fail criteria: wallet structure single-currency only; FX conversion limited; tax reporting absent.

Demo Test 7: KYC handoff design walkthrough.

Pass criteria: vendor demonstrates KYC integration with operator-specified KYC vendor including end-to-end onboarding flow, ongoing screening alert handling, and case management integration. Fail criteria: KYC integration shallow; specific KYC vendor not supported; case management absent.

Demo Test 8: Payment flow integration with operator-specified PSP set.

Pass criteria: vendor demonstrates PSP integration including deposit flow, withdrawal flow with verification of payee handling, and reconciliation between PSP statements and client balances. Fail criteria: PSP integration limited; verification of payee not handled; reconciliation gaps.

Demo Test 9: CASP wallet attribution demonstration (crypto-touching).

Pass criteria: vendor demonstrates wallet address management including chain support, verification method, ongoing wallet activity monitoring, and Travel Rule integration. Fail criteria: wallet attribution shallow; chain coverage gaps; ongoing monitoring absent.

Demo Test 10: CASP transaction history with blockchain hash demonstration.

Pass criteria: vendor demonstrates blockchain transaction handling as first-class transaction type with full audit trail and reporting integration. Fail criteria: blockchain transactions metadata extension only; audit trail incomplete; reporting integration absent.

Demo Test 11: CASP supported asset configuration per jurisdiction demonstration.

Pass criteria: vendor demonstrates per-jurisdiction asset configuration with granularity at token level and programmatic update capability. Fail criteria: per-jurisdiction configuration coarse; programmatic update not supported.

Demo Test 12: Client cabinet UX walkthrough with operator branding application.

Pass criteria: vendor demonstrates branding customisation, layout customisation, widget placement, and dashboard configuration per user role with operator-provided branding assets. Fail criteria: UX customisation limited; per-role dashboard absent; branding gaps in mobile experience.

Integration testing protocol

The 10-test protocol structures operator-side pre-signature integration testing:

  1. Sandbox environment access and complete API documentation review. Operator integration team verifies API documentation completeness against operator integration requirements.
  2. Platform integration end-to-end testing. Test client lifecycle integration from operator’s specific platform through vendor CRM API to operator’s downstream systems.
  3. KYC integration testing with operator-specific KYC vendor. Test verification flow integration including ongoing screening alert handling and case management coordination.
  4. PSP integration testing with operator-specific PSP set. Test deposit and withdrawal flow including verification of payee handling and reconciliation workflow.
  5. Multi-tenant deployment testing (if multi-tenant procurement). Test per-tenant logical separation, parent organisation visibility, and cross-tenant query isolation.
  6. Multi-language client cabinet testing. Test operator’s specific language set including UI translation completeness, content translation quality, and locale-specific formatting.
  7. Multi-currency wallet testing. Test per-currency wallet operations including FX conversion at deposit and withdrawal events and tax reporting accuracy.
  8. CASP-specific testing (crypto-touching). Test wallet attribution, blockchain transaction handling, per-jurisdiction asset configuration, and fiat-crypto conversion history reporting.
  9. Performance and load testing at operator’s expected production volume. Test vendor performance including concurrent user handling, multi-tenant query performance, and peak load handling.
  10. Disaster recovery and incident response testing. Test vendor incident notification, regulatory cooperation, and operator-side communication during simulated incident.

The integration testing protocol typically takes 4-6 weeks for mid-market deployments. Operators should budget appropriately and treat the protocol as final pre-signature procurement diligence.

Decision documentation template

The decision documentation template structures the operator-side record:

Section 1: Procurement context

  • Operator regulatory positioning and archetype identification
  • Procurement scope (single-tenant versus multi-tenant; platform-bundled versus cross-vendor; CASP requirements relevance)
  • Procurement timing and decision process
  • Procurement team and roles

Section 2: Vendor shortlist

  • List of vendors evaluated
  • Initial screening criteria including multi-tenant capability filter
  • RFP distribution and response timing
  • Vendors disqualified at initial screening with reasoning

Section 3: RFP evaluation

  • Universal dimensions scoring per vendor
  • Multi-tenant configuration scoring (critical for hybrid C and EU dual-licensed E)
  • Platform integration scoring with operator’s specific platform set
  • Client cabinet design dimension scoring
  • CASP-specific scoring (if applicable)
  • Per-archetype customisation applied
  • Disqualification thresholds applied

Section 4: Reference customer diligence

  • Reference customer list per shortlisted vendor
  • Reference customer questions asked
  • Reference customer responses summarised
  • Multi-tenant operational reality documentation (if multi-tenant procurement)
  • Reference diligence-driven scoring adjustments

Section 5: Demo evaluation

  • Demo dates and participants per shortlisted vendor
  • Demo evaluation rubric results across 12 tests
  • Pass and fail criteria documentation per dimension
  • Demo-driven scoring adjustments

Section 6: Integration testing

  • Integration testing dates and scope per shortlisted vendor
  • Integration testing protocol results across 10 tests
  • Multi-tenant testing documentation if applicable
  • CASP-specific testing documentation if applicable
  • Capability gaps identified with vendor remediation commitments

Section 7: Procurement decision

  • Final vendor ranking with weighted total scoring
  • Selected vendor with explicit decision rationale including multi-tenant pattern selection rationale
  • Platform integration tightness positioning rationale (dual lock-in versus independent swappability)
  • Disqualified vendors with explicit disqualification reasoning
  • Contract terms summary including per-tenant pricing structure if multi-tenant

Section 8: Ongoing monitoring

  • Operator-side vendor performance monitoring framework
  • KPI definitions and measurement methodology
  • Multi-tenant performance monitoring if applicable
  • CASP-specific monitoring if applicable
  • Vendor review cycle (quarterly business review, annual relationship review)
  • Procurement decision review triggers (vendor M&A, regulatory shifts, capability gaps, multi-tenant performance deterioration)

What comes next in Phase 4

This dispatch provides the third per-pillar evaluation toolkit. Future Phase 4 artefacts will extend coverage:

  • Additional per-pillar evaluation toolkits. LP procurement, broker analytics, copy trading, IB management, payments, and other pillar-specific toolkits following the same structure.
  • Per-archetype RFP templates. Complete RFP templates customised per archetype combining the universal dimensions plus relevant per-pillar dimensions plus per-archetype customisation into operationally-actionable RFP documents.
  • Vendor evidence library. Aggregated evidence on specific vendors against the framework dimensions sourced from public information and operator ground-truth contributions.
  • Institutional CRM evaluation toolkit (Archetype H specific). The retail and mass-market broker CRM toolkit above does not extend to institutional Archetype H procurement which requires structurally different vendor evaluation (Salesforce Financial Services Cloud, specialist institutional broker CRM). Future Phase 4 artefact will cover institutional CRM procurement separately.

Phase 4 corpus state after this dispatch:

  • 25 Phase 3 synthesis dispatches
  • 4 Phase 4 operationally-actionable artefacts (RFP scoring framework opener, KYC toolkit, RegTech toolkit, this broker CRM toolkit)
  • TOTAL: 29 dispatches

The Phase 4 forward roadmap will continue to be shaped by which artefacts produce the most operator-actionable value rather than by additional synthesis coverage.

If you operate a broker stack with active CRM 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.