DISPATCH ·

Risk management procurement evaluation toolkit (Phase 4 per-pillar artefact)

Thirty-third dispatch. Seventh per-pillar Phase 4 evaluation toolkit. Operationally-actionable artefact for Chapter IX risk management procurement covering the broker-ID segmentation procurement filter for hybrid Archetype C, the four crypto-asset risk dimensions for CASP-touching archetypes, the three procurement paths (bundled-with-platform / specialist / in-house), and the pre-trade controls plus post-trade analytics evaluation framework. Risk management vendors integrate at the platform layer making integration testing particularly engineering-heavy; the toolkit covers the concrete RFP filter language operators should send to vendors plus the integration testing protocol that surfaces capability gaps before contract signature.

tags · phase-4 · risk-management · broker-id-segmentation · evaluation-toolkit · operational-artefact

Why this dispatch exists

This is the thirty-third dispatch and the eighth in the Phase 4 operationally-actionable artefact sub-series. The earlier Phase 4 dispatches covered the RFP scoring framework opener, KYC, RegTech, broker CRM, LP procurement, payments procurement, and brokerage hosting evaluation toolkits. This dispatch covers the seventh per-pillar evaluation toolkit: risk management procurement.

Risk management procurement is distinct from other Phase 4 toolkit coverage because the risk vendor integrates at the platform layer rather than at the operations layer. Pre-trade controls must intercept order flow before execution; post-trade analytics must consume execution data plus LP exposure data plus client position data in real-time. The integration depth makes risk management one of the most engineering-heavy procurements in the corpus.

The risk management deep dive surfaced three concrete procurement filters that this toolkit operationalises: the broker-ID segmentation RFP test for hybrid Archetype C with explicit demonstration on the operator’s specific MT5 instance configuration before contract signature; the four crypto-asset risk dimensions (market risk on inventory, counterparty risk on LPs and CEXes, operational risk on custody, conduct risk on the venue) that CASP-touching archetypes should evaluate against vendors separately; and the three procurement paths (bundled-with-platform for lean and lower-mid-market, specialist risk-aggregation platforms for mid-market and tier-1, in-house risk management for tier-1 with explicit risk engineering capability).

This toolkit provides operationally-actionable artefacts that operators apply directly during risk management procurement.

Risk management procurement scope recap

The risk management procurement scope spans six risk dimensions:

Pre-trade controls. Leverage policy enforcement per regulatory regime and per client classification; margin call logic with liquidation behaviour configuration; ESMA negative balance protection at position level or aggregate level. Universal procurement requirement.

Post-trade analytics. Exposure aggregation across instruments and counterparties; VaR calculation methodology with operator calibration; P&L attribution across A-book / B-book hybrid execution paths; execution quality reporting (RTS 27 / equivalent). Universal procurement requirement.

Market risk on inventory (CASP-specific). Volatility calibration for crypto-asset inventory positions; stress-test scenarios for crypto-asset market dynamics; cross-venue inventory aggregation. Procurement-relevant for CASP-touching archetypes (B, D, E, H with FSRA Virtual Asset Framework).

Counterparty risk on LPs and CEXes (CASP-specific). Counterparty exposure aggregation; counterparty rating updates; post-Genesis-Trading 2023 stress-test scenarios. Procurement-relevant for CASP-touching archetypes.

Operational risk on custody (CASP-specific). Key compromise scenarios; sub-custodian failure scenarios; smart contract exploit scenarios for DeFi-adjacent products. Procurement-relevant for CASPs running custody operations.

Conduct risk on the venue (CASP-specific). Wash trading detection; market manipulation by venue clients; layering and spoofing detection. Interface with trade surveillance vendor (separate procurement covered in RegTech toolkit). Procurement-relevant for CASPs operating trading platforms.

The toolkit below covers pre-trade controls and post-trade analytics for all archetypes; CASP-specific dimensions extend the questionnaire for crypto-touching archetypes.

Procurement-stage questionnaire template

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

Universal dimensions (5 questions per the Phase 4 opener)

  1. Provide your pricing structure including base pricing, per-broker-ID pricing if applicable, optional module pricing (specialist crypto-asset risk modules, RTS 27 reporting modules), integration costs, and ongoing support costs.
  2. List your relevant certifications including ISO 27001, SOC 2 Type II, jurisdiction-specific certifications.
  3. Describe your customer support structure including dedicated TAM availability and operator-side escalation paths.
  4. Provide your most recent financial position disclosure.
  5. Describe your product roadmap including specific feature commitments and regulatory readiness investments.

Pre-trade controls dimensions (7 questions)

  1. Describe your leverage policy enforcement architecture including per-regulatory-regime configurability (ESMA 1:30 majors retail, DMCC 1:200-500, FCA, ASIC 1:30, MAS 1:20, FSA 1:25, Korea 1:10), per-client-classification differentiation (retail vs professional vs eligible counterparty), and dynamic policy update mechanism.
  2. Describe your margin call logic including initial margin, maintenance margin, and stop-out margin enforcement with explicit liquidation behaviour configuration under fast-market conditions.
  3. Describe your liquidation methodology including next-available-price liquidation, multi-LP-segmented liquidation, and queue-against-incoming-margin-top-up behaviour.
  4. Describe your ESMA negative balance protection implementation including position-by-position enforcement versus account-aggregate enforcement and operator-side choice support.
  5. Describe your platform integration architecture including MT4 server plug-in, MT5 server plug-in, cTrader plug-in, Match-Trader plug-in, native CASP venue integration, and pre-trade control execution latency.
  6. Describe your pre-trade controls bypass framework including emergency bypass capability, audit trail completeness during bypass, and operator-side override workflows.
  7. Provide pre-trade controls performance metrics at operator’s expected order volume including order processing latency, control execution latency, and operator-side performance impact.

Post-trade analytics dimensions (6 questions)

  1. Describe your exposure aggregation architecture including cross-instrument aggregation, cross-counterparty aggregation, and per-broker-ID-group aggregation if hybrid procurement.
  2. Describe your VaR calculation methodology including specific methodology (historical simulation, Monte Carlo, parametric), operator calibration capability (historical window configuration, confidence interval configuration), and stress-test scenario definition framework.
  3. Describe your P&L attribution architecture across A-book versus B-book hybrid execution paths including execution path attribution, spread attribution, slippage attribution, and consolidated P&L reporting.
  4. Describe your execution quality reporting including FCA RTS 27 best execution reports, ESMA equivalent disclosures, and operator-side report generation workflow.
  5. Describe your real-time risk dashboard including operator-side risk team workflow integration, alert generation, and escalation path framework.
  6. Describe your historical risk data warehouse including operator-side data access, regulator examination support, and operator-side analytics integration.

Hybrid broker-ID segmentation dimensions (4 questions)

  1. (Hybrid Archetype C specific) Describe your broker-ID-level segmentation architecture including separable exposure reporting per broker-ID group, separate VaR limits per group, and separate pre-trade controls per group.
  2. Demonstrate broker-ID-level segmentation on operator’s specific MT5 instance configuration before contract signature. Provide concrete demonstration of separable exposure reports for broker-IDs 1-100 (prop firm) versus broker-IDs 101-500 (broker) with separate VaR limits and separate pre-trade controls per group.
  3. Describe your cross-group aggregation framework including operator-level monitoring overlay across broker-ID groups and per-group reporting isolation.
  4. Provide hybrid operator reference customers with broker-ID segmentation deployment scale and operational characteristics.

Crypto-asset risk dimensions (CASP-touching specific, 7 questions)

  1. (CASP-touching archetypes) Describe your market risk on inventory framework including volatility calibration methodology for crypto-asset positions, stress-test scenarios for crypto-asset market dynamics, and cross-venue inventory aggregation.
  2. Describe your counterparty risk on LPs and CEXes framework including counterparty exposure aggregation, counterparty rating updates, and post-Genesis-Trading 2023 stress-test scenarios.
  3. Describe your operational risk on custody framework including key compromise scenarios, sub-custodian failure scenarios, and smart contract exploit scenarios for DeFi-adjacent products if applicable.
  4. Describe your conduct risk on the trading venue framework including wash trading detection, market manipulation by clients, and layering plus spoofing detection.
  5. Describe your interface with trade surveillance vendor (separate procurement) including data exchange architecture, alert handover framework, and operator-side case management coordination.
  6. Describe your CASP-specific reporting including MiCAR-aligned outputs, supervisory reporting hooks, and operator-side audit trail completeness.
  7. Provide CASP reference customers with deployment scale across the four crypto-asset risk dimensions and operational characteristics.

Phase 4 framework alignment (5 questions)

  1. How does your product align with the three procurement paths (bundled-with-platform / specialist / in-house) covered in the risk management deep dive? At what operator scale tier is your product procurement-appropriate?
  2. How does your product handle the operator’s specific archetype customisation including per-archetype risk dimension intensity from the RFP scoring framework opener?
  3. Describe your scale-tier graduation framework if applicable including operator-side migration support from bundled to specialist procurement and operator-side transition timeline.
  4. Describe your contract terms including pricing escalation methodology, contract length, data portability provisions on termination, and operator-side switching cost mitigation.
  5. Describe your post-acquisition framework positioning if applicable including parent company integration impact and operator-side procurement implications.

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 trade volume scale?
  2. Did the vendor’s RFP-stage capability disclosure match the operational reality you experienced post-deployment? Specifically: were there pre-trade controls gaps, post-trade analytics gaps, or broker-ID segmentation gaps?
  3. What is your actual pre-trade control execution latency in production versus the vendor’s pre-contract estimate?
  4. How does the vendor’s product perform under fast-market conditions including liquidation behaviour, exposure aggregation accuracy, and operator-side risk team workflow?
  5. (Hybrid operators) How clean is the vendor’s broker-ID-level segmentation in operational reality? Have you encountered cross-group exposure leakage or operator-level reporting gaps?
  6. (CASP operators) How accurate is the vendor’s crypto-asset risk coverage including market risk on inventory, counterparty risk, and operational risk on custody?

Procurement specifics (5 questions)

  1. How did the vendor handle the procurement decision process? Were they responsive to RFP iterations including broker-ID segmentation testing and crypto-asset risk dimension testing?
  2. What pricing did you actually pay versus the pricing positioning during procurement?
  3. (Bundled-with-platform procurement) Did the bundled risk product handle your operational scale or did you encounter graduation friction at specific scale milestones?
  4. (Specialist procurement) How did the specialist platform integrate with your specific trading platform? Were integration gaps surfaced in production?
  5. Has the vendor’s roadmap delivery matched the roadmap visibility provided during procurement?

Operational quality (5 questions)

  1. How responsive is the vendor’s product to regulatory developments including MiCAR Title VI implementation, FCA SYSC operational resilience requirements, or jurisdiction-specific regulatory shifts?
  2. (Specialist procurement) How accurate is the vendor’s specialist crypto-asset risk module if procured? Specifically: post-Genesis-Trading 2023 counterparty risk handling.
  3. How responsive is the vendor’s customer support to operational risk incidents? Specifically: incident notification timing during market stress events.
  4. (Hybrid operators) How did the vendor handle the broker-ID segmentation requirement in operational reality versus the demo-stage demonstration?
  5. Would you procure this vendor again given the same procurement decision context? Why or why not?

Demo evaluation rubric

Risk management demos require live platform integration testing and operator-specific scenario demonstration. The 12-test rubric structures operator-side demo evaluation:

Demo Test 1: Pre-trade leverage policy enforcement testing.

Pass criteria: vendor demonstrates per-regulatory-regime leverage enforcement (ESMA 1:30, DMCC 1:200-500, etc.) on operator-provided test trade sequence with explicit policy hit detection. Fail criteria: leverage policy hardcoded; per-regulatory-regime configuration limited; policy hit detection not demonstrated.

Demo Test 2: Margin call logic demonstration with operator-provided fast-market scenario.

Pass criteria: vendor demonstrates margin call enforcement under operator-provided fast-market scenario including liquidation behaviour, multi-LP-segmented liquidation, and audit trail completeness. Fail criteria: liquidation behaviour shallow; fast-market handling absent; audit trail incomplete.

Demo Test 3: ESMA negative balance protection demonstration.

Pass criteria: vendor demonstrates negative balance protection enforcement at operator’s chosen level (position vs aggregate) with explicit operator-side choice configuration. Fail criteria: negative balance protection hardcoded at single level; operator-side choice absent.

Demo Test 4: Hybrid broker-ID segmentation demonstration.

Pass criteria: vendor demonstrates separable exposure reports for operator-provided broker-ID groups (e.g. broker-IDs 1-100 prop firm vs 101-500 broker) with separate VaR limits and separate pre-trade controls per group. Fail criteria: broker-ID segmentation not demonstrated; aggregated reporting only; segmentation requires custom development.

Demo Test 5: Multi-LP exposure aggregation demonstration.

Pass criteria: vendor demonstrates exposure aggregation across operator-provided multi-LP test configuration including cross-LP reconciliation and operator-level consolidated reporting. Fail criteria: multi-LP aggregation shallow; cross-LP reconciliation absent.

Demo Test 6: VaR methodology demonstration with operator-provided historical data.

Pass criteria: vendor demonstrates VaR calculation methodology with operator-provided historical data including operator calibration capability and stress-test scenario application. Fail criteria: VaR methodology opaque; operator calibration absent; stress-test framework limited.

Demo Test 7: P&L attribution across A-book/B-book demonstration.

Pass criteria: vendor demonstrates P&L attribution across operator-provided A-book and B-book test execution paths with explicit attribution methodology. Fail criteria: P&L attribution shallow; execution path attribution absent.

Demo Test 8: Execution quality reporting demonstration.

Pass criteria: vendor demonstrates RTS 27 best execution reports generation with operator-provided test execution data and supervisor-ready output. Fail criteria: RTS 27 reporting absent; supervisor-ready output limited.

Demo Test 9: Real-time risk dashboard walkthrough.

Pass criteria: vendor demonstrates real-time risk dashboard including operator-side risk team workflow integration, alert generation, and escalation path framework. Fail criteria: dashboard shallow; workflow integration absent; alert generation limited.

Demo Test 10: Market risk on inventory demonstration (CASP-touching).

Pass criteria: vendor demonstrates crypto-asset inventory risk calculation with explicit volatility calibration and stress-test scenarios. Fail criteria: crypto-asset risk coverage shallow; volatility calibration default; stress-test framework limited.

Demo Test 11: Counterparty risk demonstration (CASP-touching).

Pass criteria: vendor demonstrates counterparty exposure aggregation across operator-provided crypto LP and CEX test configuration with explicit post-Genesis-Trading 2023 stress-test scenarios. Fail criteria: counterparty risk framework shallow; post-Genesis-Trading scenarios absent.

Demo Test 12: Integration with operator-specific trading platform demonstration.

Pass criteria: vendor demonstrates platform integration with operator’s specific platform (MT4, MT5, cTrader, Match-Trader, B2BX) including pre-trade controls execution latency at operator-relevant order volume. Fail criteria: platform integration shallow; execution latency not demonstrated; operator-specific platform not supported.

Integration testing protocol

Risk management integration testing is engineering-heavy because the risk vendor sits in the same data plane as the operator’s trading platform. The 12-test protocol structures operator-side pre-signature testing:

  1. Platform integration testing. Test vendor risk product integration with operator’s specific platform including pre-trade controls execution, order flow capture, and execution data integration.
  2. Pre-trade controls integration testing. Test pre-trade controls enforcement at operator’s expected order volume including order processing latency and control execution latency.
  3. Multi-LP integration testing. Test risk vendor integration with operator’s specific LP set including cross-LP exposure aggregation and reconciliation workflows.
  4. CRM integration testing. Test risk vendor integration with operator’s CRM including client-level risk reporting, alert handling, and case management coordination.
  5. Broker-ID segmentation integration testing (hybrid operators). Test broker-ID-level segmentation on operator’s specific MT5 instance configuration including separable exposure reports, separate VaR limits, and separate pre-trade controls per group.
  6. CASP crypto-asset risk integration testing (crypto-touching). Test crypto-asset risk coverage including inventory risk, counterparty risk, operational risk on custody, and conduct risk interface with trade surveillance vendor.
  7. Real-time dashboard integration testing. Test risk vendor real-time dashboard integration with operator-side risk team workflow including alert generation, escalation path, and operator-side analytics integration.
  8. Performance testing at production volume. Test risk vendor performance at operator’s expected production trade volume including pre-trade controls latency under peak load and exposure aggregation latency.
  9. Fast-market scenario testing. Test risk vendor behaviour under operator-provided fast-market scenarios including liquidation behaviour, margin call handling, and operator-side risk team coordination.
  10. Regulatory examination simulation. Simulate regulator examination scenario testing data retrieval, regulator-side communication framework, and operator-side coordination during examination.
  11. Disaster recovery testing. Test risk vendor incident response framework including notification timing, regulatory cooperation, and operator-side communication.
  12. End-to-end production simulation. Simulate full production trading scenarios including pre-market preparation, market opening, intraday risk management, and end-of-day reconciliation.

Integration testing typically takes 6-10 weeks for mid-market risk management deployments because the platform integration depth is meaningfully more complex than application-layer vendor procurement. Operators should staff the engineering work appropriately.

Decision documentation template

The decision documentation template structures the operator-side risk management procurement record:

Section 1: Procurement context

  • Operator regulatory positioning and archetype identification
  • Risk management procurement scope (pre-trade + post-trade + CASP dimensions if applicable + hybrid broker-ID segmentation if applicable)
  • Procurement path selection rationale (bundled-with-platform / specialist / in-house) based on operator scale tier
  • Procurement timing and decision process

Section 2: Vendor shortlist

  • List of vendors evaluated per procurement path
  • Initial screening criteria including platform integration support filter
  • RFP distribution and response timing
  • Vendors disqualified at initial screening with reasoning

Section 3: RFP evaluation

  • Universal dimensions scoring per vendor
  • Per-dimension scoring (pre-trade, post-trade, hybrid broker-ID segmentation if applicable, crypto-asset risk if applicable)
  • Per-archetype customisation applied including weight multipliers per the Phase 4 opener
  • Disqualification thresholds applied with specific dimension failures noted

Section 4: Reference customer diligence

  • Reference customer list per shortlisted vendor including operators at similar scale and archetype
  • Reference customer responses summarised
  • Pre-trade controls operational reality documentation
  • Hybrid broker-ID segmentation operational reality documentation if applicable
  • CASP crypto-asset risk operational reality documentation if applicable
  • Reference diligence-driven scoring adjustments

Section 5: Demo evaluation

  • Demo dates and participants per shortlisted vendor
  • Demo evaluation rubric results across 12 tests
  • Broker-ID segmentation demonstration documentation if applicable (concrete demonstration on operator’s specific MT5 configuration)
  • CASP crypto-asset risk dimension demonstration if applicable
  • Demo-driven scoring adjustments

Section 6: Integration testing

  • Integration testing dates and scope per shortlisted vendor
  • Platform integration testing documentation
  • Engineering work timeline including specific milestones
  • 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 procurement path rationale
  • Disqualified vendors with explicit disqualification reasoning
  • Contract terms summary including specific procurement path implications

Section 8: Ongoing monitoring

  • Operator-side vendor performance monitoring framework
  • KPI definitions including pre-trade controls latency, exposure aggregation accuracy, alert quality
  • Hybrid broker-ID segmentation monitoring if applicable
  • CASP crypto-asset risk monitoring if applicable
  • Vendor review cycle (quarterly business review, annual relationship review)
  • Procurement decision review triggers (vendor M&A, 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, trading platform, 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
  • 8 Phase 4 operationally-actionable artefacts
  • TOTAL: 33 dispatches

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