DISPATCH ·

RegTech procurement evaluation toolkit (Phase 4 per-pillar artefact)

Twenty-eighth dispatch. Second per-pillar Phase 4 evaluation toolkit extending the RFP scoring framework. Operationally-actionable artefact for Chapter XIII RegTech and compliance reporting procurement covering five distinct vendor components (trade surveillance, transaction reporting, comms surveillance, regulatory horizon scanning, chain analytics) plus Travel Rule infrastructure adjacent to KYC. The toolkit provides per-component procurement-stage questionnaire templates (38 specific RFP questions across components), reference customer questions tuned for RegTech operational realities (18 questions), demo evaluation rubric with rule library and alert quality tests (14 tests with pass/fail criteria), integration testing protocol covering the multi-system integration RegTech requires (12 pre-signature tests), and decision documentation template structured for multi-component procurement.

tags · phase-4 · regtech · evaluation-toolkit · operational-artefact

Why this dispatch exists

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

RegTech procurement is the most structurally complex per-pillar procurement in the corpus because the chapter spans five distinct vendor components that operators frequently procure from separate vendors: trade surveillance (covering market abuse detection under MAR, MiCAR Title VI, FCA SUP 17, ASIC Market Integrity Rules, FINRA Rule 5310), transaction reporting (covering MiFIR Article 26 for CFD plus EMIR REFIT plus jurisdiction-specific reporting), comms surveillance (covering FCA SYSC 10A, MiFID II Article 16, SEC 17a-4, FINRA Rule 3110/4530), regulatory horizon scanning (covering multi-jurisdiction regulatory change intelligence), and chain analytics (covering blockchain-native attack vectors for crypto-touching operations). Plus Travel Rule infrastructure adjacent to KYC for archetypes with regulated crypto-asset transfer flow.

The RegTech post-MiCAR dispatch covered the vendor positioning shifts since MiCAR full force in December 2024. The 2026 procurement-relevant question is multi-component vendor selection with per-component evaluation criteria; this toolkit provides the operationally-actionable framework. Operators apply the toolkit directly during RegTech procurement processes; the toolkit is the third concrete artefact in the Phase 4 sub-series.

RegTech procurement scope recap

The RegTech procurement scope spans five distinct vendor components that operators typically procure separately:

Trade surveillance. Market abuse detection covering insider dealing, market manipulation, layering, spoofing, wash trading, and cross-venue manipulation. Phase 2 vendors include Nasdaq SMARTS (STRONG PICK at tier-1 across all 8 archetypes per the refreshed cross-archetype matrix), Eventus Validus (SOLID at mid-market with crypto-asset strength), NICE Actimize Xceed (SOLID at enterprise scale).

Transaction reporting. Post-trade submissions to regulators including MiFIR Article 26, EMIR REFIT, ASIC, MAS, SFTR, SEC CAT. Phase 2 vendors include Cappitech (STRONG PICK for CFD broker MiFIR, now S&P Global), Kaizen Reporting (SOLID accuracy testing layer), MarketAxess Trax (SOLID ARM/APA for fixed income). Drops out for pure CASP procurement because MiCAR Title VI surveillance plus Travel Rule recordkeeping replaces MiFIR.

Comms surveillance. Chat, voice, email recording, retention, and market abuse scanning. Phase 2 vendors include Behavox (SOLID universal, STRONG PICK for institutional Archetype H), Smarsh (SOLID universal, Gartner MQ Leader 2025).

Regulatory horizon scanning. Multi-jurisdiction regulatory change intelligence. Phase 2 vendors include CUBE (SOLID universal across all 8 archetypes), Corlytics (SOLID universal with ClauseMatch policy mapping integration).

Chain analytics (crypto-touching specific). Blockchain-native attack vector surveillance. Vendors include Chainalysis Reactor and KYT, Elliptic Lens, TRM Labs. Not a Phase 2 chapter category but procurement-relevant adjacent to RegTech for crypto-touching archetypes.

The toolkit below structures procurement-stage evaluation across the five components plus Travel Rule infrastructure where the operator’s archetype requires it.

Procurement-stage questionnaire template

The questionnaire template includes 38 specific RFP questions structured by component plus framework dimension. Operators send the questionnaire to each shortlisted vendor as part of the formal RFP process.

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-component pricing, per-user pricing (where applicable), 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 TAM availability, SLAs, 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.

Trade surveillance dimensions (8 questions)

  1. Describe your rule library calibration for the operator’s specific regulatory framework (MAR for CySEC, MiCAR Title VI for CASP, FCA SUP 17 for FCA, ASIC Market Integrity Rules for Archetype F). Provide specific rule examples and rule maintenance methodology.
  2. Provide your regulator deployment list (specific regulators using your product) and broker client base size in the operator’s archetype.
  3. Describe your false positive rate (legitimate trades flagged) and false negative rate (manipulation missed) against published industry benchmarks.
  4. Describe your alert prioritisation methodology including alert volume per analyst per day at the operator’s expected trade volume.
  5. Describe your crypto-asset surveillance capability (relevant for crypto-touching archetypes) including chain analytics integration and cross-venue manipulation detection.
  6. Describe your hybrid operator broker-ID-level segmentation capability (relevant for hybrid Archetype C) including separable exposure reporting per broker-ID group.
  7. Describe your alert investigation tooling including analyst workflows, case management integration, and audit trail completeness.
  8. Provide reference customers in the operator’s archetype with deployment scale and operational tenure information.

Transaction reporting dimensions (6 questions)

  1. (CFD-touching archetypes only) Describe your MiFIR Article 26 coverage including reporting accuracy methodology, ESMA technical standards alignment, and error correction workflow.
  2. (CFD-touching archetypes only) Describe your EMIR REFIT coverage including counterparty data quality validation and reconciliation workflows.
  3. Describe your jurisdiction-specific reporting coverage (ASIC, MAS, SFTR, SEC CAT, jurisdiction-specific LATAM frameworks) relevant to the operator’s archetype.
  4. Describe your accuracy testing positioning (if positioning as Kaizen-style accuracy testing layer) including testing methodology, error detection rate, and operator-side feedback integration.
  5. Describe your reporting SLA framework including submission deadlines, resubmission handling, and regulator-side communication during submission issues.
  6. Describe your integration with operator-side data sources including platform integration, CRM integration, and reconciliation workflow.

Comms surveillance dimensions (6 questions)

  1. List your channel coverage including email, mobile messaging (WhatsApp Business, Signal, personal device WhatsApp), collaboration platforms (Microsoft Teams, Slack, Zoom Chat), voice (recorded calls, Bloomberg Chat, Bloomberg voice), and emerging channels.
  2. Describe your detection methodology including AI/NLP capability, lexicon-based detection, and behavioural pattern detection.
  3. Describe your defence against off-channel comms (personal device exposure, designated employee monitoring) including operator-side policy enforcement integration.
  4. Describe your false positive rate and false negative rate against published industry benchmarks.
  5. Describe your multi-language capability including specific languages with native detection depth versus machine-translated detection.
  6. Describe your archive retention capability including jurisdiction-specific retention requirements (FCA SYSC 10A, MiFID II Article 16, SEC 17a-4, FINRA Rule 3110/4530) and operator-side data access.

Regulatory horizon scanning dimensions (5 questions)

  1. List your regulatory taxonomy coverage including specific frameworks (MiFID II, MiCAR, MiFIR, EMIR REFIT, FCA SUP/SYSC, CySEC, DMCC, VARA, ASIC, MAS, SFC, FSA, KFSC, Brazil CVM, Mexico CNBV, ADGM FSRA).
  2. Describe your update cadence including new regulation detection latency, ESMA technical standards integration, and rule library refresh methodology.
  3. Describe your operator-side integration including policy mapping capability (if ClauseMatch-style positioning), obligation tracking, and audit trail completeness.
  4. Describe your multi-jurisdiction capability including cross-jurisdiction obligation comparison and impact assessment workflows.
  5. Describe your enforcement action analytics including data sources, analytics methodology, and operator-relevant insight delivery.

Chain analytics dimensions (crypto-touching specific, 4 questions)

  1. (Crypto-touching archetypes only) List your blockchain coverage including specific chains (Bitcoin, Ethereum, Solana, etc.), DeFi protocol coverage, and bridge analytics.
  2. Describe your KYT (know your transaction) capability including counterparty risk scoring, mixer detection, and sanctioned address detection.
  3. Describe your investigation tooling including transaction flow visualisation, entity attribution, and case management integration.
  4. Describe your regulatory data source quality including specific data providers and update cadence.

Travel Rule dimensions (crypto-touching specific, 4 questions)

  1. (Crypto-touching archetypes only) Describe your Travel Rule infrastructure capability including bundled module versus integration with specialist Travel Rule vendor.
  2. List your Travel Rule counterparty VASP network including specific counterparties on your network, geographic coverage, and counterparty network growth roadmap.
  3. Describe your EU TFR compliance capability including originator-side and beneficiary-side support against the 1,000 EUR threshold structure plus recordkeeping-on-all-transfers requirement.
  4. Describe your integration with primary KYC vendor including the bundled-versus-separate procurement positioning.

Reference customer questions

Reference customer diligence for RegTech procurement requires deeper conversation than KYC procurement because RegTech operational realities (alert quality, regulator engagement during examinations, multi-system integration depth) are difficult to assess from RFP responses alone. The 18 specific questions structure operator-side reference conversations:

RegTech operational reality (8 questions)

  1. How long has your operation been using this vendor across which RegTech components (trade surveillance, transaction reporting, comms surveillance, etc.)?
  2. Did the vendor’s rule library calibration match your specific regulatory framework requirements at procurement-stage versus at operational reality?
  3. What is your actual alert volume per analyst per day at production trade volume? Does the alert volume match the vendor’s pre-contract estimate?
  4. How accurate is the vendor’s alert detection in your operational reality? Specifically: have you encountered market abuse events that the vendor’s product did not detect, or persistent false positive patterns that consume analyst capacity?
  5. How responsive is the vendor’s product to regulatory developments? Specifically: how did the vendor handle MiCAR Title VI implementation, EU TFR mandate, or other relevant regulatory shifts?
  6. How does the vendor’s product perform during regulator examinations? Specifically: has the vendor’s product produced supervisor-ready outputs or required operator-side adjustment?
  7. (For transaction reporting) What is your MiFIR reporting error rate post-vendor deployment? Has the vendor’s product reduced or increased reporting accuracy versus pre-vendor state?
  8. (For comms surveillance) Has the vendor’s product detected off-channel comms exposure in your operational reality? Specifically: WhatsApp Business, Signal, personal device exposure detection.

Procurement specifics (5 questions)

  1. How did the vendor handle the procurement decision process? Were they responsive to RFP iterations and procurement-stage questions?
  2. What pricing did you actually pay versus the pricing positioning during procurement? Were there ongoing escalation or unexpected costs across components?
  3. (If multi-component) Did the vendor’s product integrate cleanly across components or did integration gaps surface between trade surveillance, transaction reporting, and comms surveillance?
  4. Did the vendor honour contract terms during operational reality including SLAs, data portability, and termination protections?
  5. How transparent is the vendor about their financial position and roadmap during ongoing operational relationship?

Multi-system integration (5 questions)

  1. How did the vendor’s product integrate with your trading platform (MT5, cTrader, Match-Trader, etc.)? Were integration gaps surface in production?
  2. How did the vendor’s product integrate with your CRM? Specifically: alert handling, case management, audit trail completeness.
  3. (For comms surveillance) How did the vendor’s product integrate with your specific channel set including any operator-specific channels (Bloomberg Chat, internal collaboration platforms)?
  4. (For transaction reporting) How did the vendor’s product integrate with your platform data sources and your back-office systems?
  5. Would you procure this vendor again for the same components given the same procurement decision context? Why or why not?

Demo evaluation rubric

RegTech product demos should test actual capability against operator-provided scenarios rather than vendor-curated demonstrations. The 14-test rubric structures operator-side demo evaluation:

Demo Test 1: Rule library demonstration with operator-provided regulatory framework scope.

Pass criteria: vendor demonstrates rule library coverage for operator’s specific framework (MAR, MiCAR Title VI, FCA SUP 17, etc.) with explicit rule mapping and rule maintenance methodology. Fail criteria: rule library coverage shallow; framework-specific rules not demonstrated; rule maintenance methodology absent.

Demo Test 2: Alert quality demonstration with operator-provided test market abuse scenarios.

Pass criteria: vendor detects operator-provided test scenarios (e.g. wash trading pattern, layering pattern, cross-venue manipulation) with explicit detection signal explanation. Fail criteria: test scenarios not detected; detection signals not explained; alert quality below operator expectations.

Demo Test 3: False positive demonstration with operator-provided legitimate trading scenarios.

Pass criteria: vendor demonstrates appropriate handling of operator-provided legitimate scenarios that may appear suspicious without false-positive alert generation. Fail criteria: legitimate scenarios false-positive flagged; false positive handling absent.

Demo Test 4: Crypto-asset surveillance demonstration (crypto-touching).

Pass criteria: vendor demonstrates crypto-asset surveillance including chain analytics integration, cross-venue manipulation detection, and crypto-specific attack vector detection. Fail criteria: crypto-asset capability shallow; chain analytics integration not demonstrated; crypto-specific attack vectors not addressed.

Demo Test 5: Broker-ID segmentation demonstration (hybrid Archetype C specific).

Pass criteria: vendor demonstrates separable exposure reporting per broker-ID group with separate VaR limits and pre-trade controls per group. Fail criteria: broker-ID segmentation not demonstrated; aggregated reporting only; segmentation requires custom development.

Demo Test 6: MiFIR reporting demonstration with operator-provided trade data (CFD-touching).

Pass criteria: vendor demonstrates MiFIR Article 26 report generation from operator-provided trade data with explicit accuracy validation. Fail criteria: MiFIR coverage shallow; accuracy validation absent; ESMA technical standards alignment not demonstrated.

Demo Test 7: Accuracy testing demonstration (Kaizen-style positioning).

Pass criteria: vendor demonstrates accuracy testing methodology against operator-provided MiFIR reports with explicit error detection. Fail criteria: accuracy testing capability shallow; error detection rate below industry benchmarks.

Demo Test 8: Comms surveillance channel coverage with operator-provided test scenarios.

Pass criteria: vendor demonstrates comms capture across operator-provided channels (email, WhatsApp Business, Microsoft Teams, Bloomberg Chat, voice) with explicit detection methodology. Fail criteria: channel coverage gaps; specific channels not captured; detection methodology absent.

Demo Test 9: Off-channel comms demonstration.

Pass criteria: vendor demonstrates personal device exposure detection, designated employee monitoring integration, and operator-side policy enforcement support. Fail criteria: off-channel capability shallow; personal device exposure not addressed; policy enforcement integration absent.

Demo Test 10: Multi-language detection demonstration.

Pass criteria: vendor demonstrates native detection in operator’s specific language set (English, Mandarin, Japanese, Arabic, Portuguese, etc.) versus machine-translated detection. Fail criteria: multi-language capability shallow; native detection limited to English; specific language depth absent.

Demo Test 11: Regulatory horizon scanning demonstration.

Pass criteria: vendor demonstrates regulatory taxonomy coverage for operator’s specific jurisdiction set with update cadence demonstration and operator-side policy mapping integration. Fail criteria: taxonomy coverage shallow; update cadence inadequate; policy mapping not demonstrated.

Demo Test 12: Chain analytics demonstration (crypto-touching).

Pass criteria: vendor demonstrates blockchain coverage, KYT capability, and investigation tooling with operator-provided test transaction sequence. Fail criteria: blockchain coverage shallow; KYT inadequate; investigation tooling absent.

Demo Test 13: Travel Rule infrastructure demonstration (crypto-touching).

Pass criteria: vendor demonstrates Travel Rule infrastructure including counterparty VASP network coverage and EU TFR compliance capability. Fail criteria: Travel Rule capability shallow; counterparty network gaps; EU TFR compliance not addressed.

Demo Test 14: Integration walkthrough across components.

Pass criteria: vendor demonstrates integration across multiple components (trade surveillance plus transaction reporting plus comms surveillance) with consolidated reporting and operator-side workflows. Fail criteria: component integration gaps; consolidated reporting absent; operator-side workflows shallow.

Integration testing protocol

RegTech integration testing is materially more complex than KYC integration testing because RegTech integrates with multiple operator-side systems including the trading platform, the CRM, comms infrastructure, and back-office systems. The 12-test protocol structures operator-side pre-signature integration testing:

  1. Trading platform integration testing. Test vendor product integration with operator’s specific platform (MT5, cTrader, Match-Trader, B2BX, etc.) including data feed integration, order flow capture, and execution data quality.
  2. CRM integration testing. Test vendor product integration with operator’s CRM including alert handling, case management, audit trail completeness, and operator-side workflow integration.
  3. Comms infrastructure integration testing. Test vendor product integration with operator’s specific channel set including email systems (Microsoft 365, Google Workspace), mobile messaging integration, Bloomberg integration, and collaboration platforms.
  4. Back-office integration testing. Test vendor product integration with operator’s transaction reporting flow including platform data sources, reconciliation systems, and regulator-side submission infrastructure.
  5. Cross-component integration testing. Test integration across multiple RegTech components if multi-component vendor procurement (trade surveillance plus transaction reporting plus comms surveillance integration).
  6. KYC vendor integration testing. Test integration with operator’s KYC vendor including alert handover, ongoing screening integration, and case management coordination.
  7. Performance testing at production volume. Test vendor performance at operator’s expected production volume including peak load handling, alert generation latency, and system stability.
  8. Multi-jurisdiction configuration testing. Test per-jurisdiction configuration if operator has multi-jurisdiction operations including jurisdiction-specific rule library application and reporting framework alignment.
  9. Audit trail testing. Test audit trail completeness across all components with operator-side data access verification and regulator-readiness simulation.
  10. Disaster recovery testing. Test vendor incident response framework including notification timing, regulatory cooperation, and operator-side communication.
  11. Data residency testing. Test data residency configuration if operator has jurisdiction-specific data residency requirements (CySEC EU residency, DMCC UAE, FSA Japan, etc.).
  12. End-to-end regulator examination simulation. Simulate regulator examination scenario testing data retrieval, regulator-side communication framework, and operator-side coordination during examination.

The integration testing protocol typically takes 5-8 weeks for mid-market RegTech deployments because the multi-system integration is meaningfully more complex than single-vendor procurement. Operators should budget appropriately.

Decision documentation template

The decision documentation template extends the Phase 4 KYC toolkit template structure with RegTech-specific multi-component sections:

Section 1: Procurement context

  • Operator regulatory positioning and archetype identification
  • Procurement scope per component (trade surveillance, transaction reporting, comms surveillance, regulatory horizon scanning, chain analytics, Travel Rule)
  • Multi-component versus single-component procurement decision
  • Procurement timing and decision process
  • Procurement team and roles

Section 2: Vendor shortlist per component

  • List of vendors evaluated per component
  • Initial screening criteria
  • RFP distribution and response timing per component
  • Vendors disqualified at initial screening with reasoning

Section 3: RFP evaluation per component

  • Universal dimensions scoring per vendor per component
  • Per-component dimensions scoring
  • Per-archetype customisation applied
  • Disqualification thresholds applied per component

Section 4: Reference customer diligence

  • Reference customer list per shortlisted vendor per component
  • Reference customer responses summarised
  • Multi-component integration reality from reference customers
  • Reference diligence-driven scoring adjustments

Section 5: Demo evaluation

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

Section 6: Integration testing

  • Integration testing dates and scope per component
  • Integration testing protocol results across 12 tests
  • Multi-system integration gaps identified with vendor remediation commitments
  • Cross-component integration testing if multi-component procurement

Section 7: Procurement decision per component

  • Final vendor ranking per component with weighted total scoring
  • Selected vendor per component with explicit decision rationale
  • Cross-component vendor relationships if multi-component procurement
  • Contract terms summary per component

Section 8: Ongoing monitoring

  • Operator-side vendor performance monitoring framework per component
  • KPI definitions including alert quality metrics, reporting accuracy metrics, comms surveillance coverage metrics
  • Vendor review cycle per component
  • Cross-component coordination if multi-component procurement
  • Procurement decision review triggers (vendor M&A, regulatory shifts, capability gaps, multi-component integration deterioration)

What comes next in Phase 4

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

  • Additional per-pillar evaluation toolkits. Broker CRM procurement, LP procurement, broker analytics, copy trading, and other pillar-specific toolkits following the same structure.
  • Per-archetype RFP templates. Complete RFP templates customised per archetype combining 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.

Phase 4 corpus state after this dispatch:

  • 25 Phase 3 synthesis dispatches
  • 3 Phase 4 operationally-actionable artefacts (RFP scoring framework opener, KYC toolkit, this RegTech toolkit)
  • TOTAL: 28 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. Operator ground-truth feedback on the toolkit application during real procurement processes will inform which subsequent artefacts produce the most value.

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