DISPATCH ·

KYC + AML procurement evaluation toolkit (Phase 4 per-pillar artefact)

Twenty-seventh dispatch. First per-pillar Phase 4 evaluation toolkit extending the RFP scoring framework opener. Operationally-actionable artefact for Chapter III KYC and AML procurement covering the procurement-stage questionnaire template (32 specific RFP questions structured by framework dimension), reference customer questions (16 questions for reference diligence), demo evaluation rubric (12 demo tests with pass/fail criteria), integration testing protocol (10 tests before contract signature), and decision documentation template. Operators apply directly during KYC vendor procurement processes; the toolkit is the second concrete artefact in the Phase 4 operationally-actionable sub-series.

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

Why this dispatch exists

This is the twenty-seventh dispatch and the second in the Phase 4 operationally-actionable artefact sub-series opened by the RFP scoring framework dispatch. The opener established the foundational three-layer framework with universal scoring dimensions, per-pillar weighted criteria, and per-archetype customisation. This dispatch extends the framework with the first per-pillar evaluation toolkit covering KYC and AML procurement specifically.

KYC procurement is the strongest candidate for the first per-pillar evaluation toolkit because it carries the broadest cross-archetype relevance: all eight operator archetypes covered in the synthesis sub-series procure KYC vendors at some scale. The KYC pre-consolidation dispatch closed the per-pillar deep-dive sub-series at fourteen dispatches with the two-vendor procurement pattern (primary KYC for onboarding plus separate vendor for ongoing screening) as the operational baseline. The 2026 H2 M&A activity in the KYC segment makes procurement decisions made in 2026 H1 procurement-relevant at higher stakes than usual; operators benefit from a toolkit that supports concrete vendor evaluation rather than category-level positioning assessment.

This dispatch provides five operationally-actionable artefacts that operators apply directly during KYC procurement: the procurement-stage questionnaire template with 32 specific RFP questions, reference customer questions covering 16 specific diligence questions, demo evaluation rubric with 12 demo tests and pass/fail criteria, integration testing protocol with 10 pre-signature tests, and the decision documentation template structuring how operators record the procurement decision for supervisory examination support.

KYC procurement scope recap

The KYC procurement scope spans:

Primary KYC vendor for onboarding. Identity verification, address verification, document verification, biometric liveness check at the onboarding flow level. Universal procurement requirement across all eight archetypes.

Separate vendor for ongoing screening. Ongoing PEP screening, sanctions screening, adverse media monitoring post-onboarding. Universal procurement requirement codified by the August 2025 CySEC sanctions regime as a distinct supervisory expectation.

Travel Rule infrastructure (CASP-specific). EU TFR compliance for crypto-asset transfer flow. Critical for archetypes with regulated CASP activity (CASP under MiCAR, EU dual-licensed, DMCC plus VARA, ADGM with FSRA Virtual Asset Framework if in scope).

KYB plus UBO verification (institutional-specific). Institutional client onboarding requires materially different verification depth. Critical for ADGM FSRA institutional broker Archetype H.

Manual case management infrastructure. Operator-side case management for ambiguous KYC and ongoing screening cases. Typically operator-built rather than vendor-procured but integrates with vendor APIs.

The toolkit below covers primary KYC vendor evaluation; the secondary ongoing screening vendor procurement follows the same toolkit structure with screening-specific dimension emphasis.

Procurement-stage questionnaire template

The questionnaire template includes 32 specific RFP questions structured by framework dimension. Operators send the questionnaire to vendors as part of the formal RFP process; vendor responses inform the dimension scoring.

Universal dimensions (5 questions)

U1 (Pricing transparency):

  1. Provide your pricing structure for the operator’s expected verification volume range (50,000 / 200,000 / 500,000 / 1,000,000 verifications per year). Include base pricing, per-verification pricing, optional module pricing, integration costs, and ongoing support costs.

U2 (Regulatory positioning and certifications): 2. List your relevant certifications including ISO 27001 (year obtained, current status), SOC 2 Type II (year obtained, current status), and jurisdiction-specific certifications relevant to the operator’s procurement context. Provide certificate copies on request. 3. Describe your active regulator engagement positioning including any direct regulator deployments, regulator advisory positions, and recent regulatory communications.

U3 (Customer support quality): 4. Describe your customer support structure including dedicated technical account management availability, support response SLAs, escalation paths, and operator-specific support customisation.

U4 (Vendor financial stability): 5. Provide your most recent financial position disclosure including (if private) recent capital raises and customer concentration metrics; (if public-company subsidiary) parent company disclosure framework; (if private with stable operations) sustained operating history evidence.

Per-pillar dimensions (27 questions across 6 dimensions)

KYC1 (Document verification depth): 6. For each of the document types the operator’s client geography includes (specify the operator’s geographic scope), describe your native verification support including document recognition accuracy, fraud detection capability, and recent document update support timing. 7. For Arabic-script documents (Emirates ID, GCC national ID variants, other Arabic-script identification), describe your native processing depth. 8. For Asian-script documents (Hong Kong ID Card, Singapore NRIC, Japan My Number system, Korea RRN), describe your native processing depth. 9. For LATAM documents (Brazil CPF plus RG plus CNH, Mexico CURP plus RFC plus INE, Argentina DNI), describe your native processing depth. 10. For institutional KYB documents (corporate ownership structures, multi-jurisdiction corporate registries), describe your support depth.

KYC2 (Biometric liveness check robustness): 11. Describe your biometric liveness check methodology including the specific liveness signals you detect (eye blinks, head movement, depth detection, behavioural patterns). 12. Describe your defence against deepfake attacks (DeepFaceLab generated content, GAN-generated synthetic faces, AI-generated identity documents). 13. Describe your defence against synthetic identity attacks (composite identities constructed from real components, identity reuse across multiple onboardings). 14. Provide your false positive rate (legitimate clients rejected) and false negative rate (fraudulent clients accepted) against published industry benchmarks.

KYC3 (Ongoing screening data set coverage): 15. List your PEP screening data sources including primary data providers, geographic coverage depth, update frequency, and adverse media integration. 16. List your sanctions screening data sources including OFAC, UN, EU, UK, jurisdiction-specific (UAE Cabinet Resolution, Singapore MAS list, Hong Kong list, ASIC list, Korea FIU list, LATAM jurisdiction lists). 17. Describe your ongoing screening operational flow including alert generation frequency, alert prioritisation methodology, and operator-side alert review integration.

KYC4 (Manual case management integration): 18. Describe your manual case management integration including API endpoints for ambiguous case flagging, case prioritisation methodology, operator-side case review tooling integration, and audit trail completeness.

KYC5 (Travel Rule integration - CASP-specific): 19. (If CASP-relevant) Describe your Travel Rule infrastructure capability including bundled Travel Rule module versus integration with specialist Travel Rule vendor. 20. (If bundled) List your Travel Rule counterparty VASP network coverage including specific counterparties on your network and counterparty network growth roadmap. 21. (If bundled) Describe your originator-side and beneficiary-side compliance capability against the EU TFR 1,000 EUR threshold structure and recordkeeping-on-all-transfers requirement.

KYC6 (KYB plus UBO verification - institutional-specific): 22. (If institutional-relevant) Describe your KYB verification depth including corporate ownership structure verification methodology, multi-jurisdiction corporate registry integration, ultimate beneficial owner identification accuracy, and complex ownership structure support. 23. (If institutional-relevant) Describe your source-of-funds verification capability at institutional scale including transaction history verification, professional client classification documentation, and ongoing institutional client monitoring.

Additional questions (4 questions covering integration and operational specifics)

  1. Describe your API architecture including authentication methodology, rate limiting, webhook patterns, retry mechanisms, and operator-side integration timeline for typical mid-market deployments.
  2. Describe your data residency options for the operator’s regulatory jurisdiction including specific data centre locations, data flow disclosure, and sub-processor disclosure under GDPR Article 28 (or jurisdiction equivalent).
  3. Describe your incident response framework including security incident notification timing, regulatory notification cooperation, and operator-side communication during incident response.
  4. List your reference customers in the operator’s specific archetype (CySEC CFD broker, DMCC plus VARA, hybrid, CASP under MiCAR, etc.) with explicit deployment scale and operational tenure information.

Phase 4 framework alignment (5 questions)

  1. How does your product align with the universal scoring dimensions in the Phase 4 framework (pricing transparency, regulatory positioning, customer support, vendor financial stability, product roadmap visibility)?
  2. How does your product align with the per-pillar KYC scoring dimensions (KYC1 through KYC6) at the operator’s specific archetype?
  3. What is your product roadmap visibility for the operator’s 3-5 year procurement horizon including specific feature commitments, regulatory readiness investments, and consolidation positioning?
  4. Describe your contract terms including pricing escalation methodology, contract length, termination provisions, data portability on termination, and operator-side switching cost mitigation.
  5. Describe your post-acquisition framework positioning (if applicable) including whether the vendor is acquired, planning acquisition, or operating standalone, and what the procurement implications are for the operator’s 3-5 year procurement horizon.

Reference customer questions

Reference customer diligence is the second-most-consequential procurement-stage activity after the formal RFP response. The 16 specific questions below structure operator-side reference customer conversations:

Operational reality (6 questions)

  1. How long has your operation been using this vendor and at what deployment scale?
  2. Did the vendor’s RFP-stage capability disclosure match the operational reality you experienced post-deployment? Specifically: were there capability gaps that surfaced after contract signature?
  3. What was your integration timeline from contract signature to production deployment? Did it match the vendor’s pre-contract estimate?
  4. How frequently do you encounter operational issues requiring vendor support intervention? What is the typical resolution time?
  5. How responsive is the vendor’s customer support to operational issues? Are dedicated technical account management arrangements honoured in practice?
  6. Has the vendor’s roadmap delivery matched the roadmap visibility provided during procurement? Specifically: which features were promised but not delivered, or delivered late?

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?
  3. Did the vendor honour contract terms during operational reality including SLAs, data portability provisions, and termination protections?
  4. How transparent is the vendor about their financial position and roadmap during ongoing operational relationship?
  5. Have you encountered situations where the vendor’s regulatory positioning was inadequate for your specific operational context? How did the vendor address the gap?

Operational quality (5 questions)

  1. How accurate is the vendor’s document verification capability in your operational reality? Specifically: false positive rate and false negative rate in production.
  2. How accurate is the vendor’s biometric liveness check in your operational reality? Have you encountered deepfake or synthetic identity attacks that the vendor’s product did not detect?
  3. How accurate is the vendor’s ongoing screening capability? Have you encountered PEP or sanctions cases that the vendor’s product missed or false-positived?
  4. How responsive is the vendor to regulatory developments? Specifically: how did the vendor handle the EU AMLR transition, MiCAR Travel Rule requirements, or other relevant regulatory shifts?
  5. Would you procure this vendor again given the same procurement decision context? Why or why not?

Demo evaluation rubric

Product demos during the procurement process should test the vendor’s actual capability rather than the vendor’s positioning materials. The 12-test rubric below structures the operator-side demo evaluation:

Demo Test 1: Live identity verification with a real operator-provided test identity.

Pass criteria: vendor processes operator-provided test identity completing identity verification in under 90 seconds with explicit fraud detection signals displayed. Fail criteria: processing exceeds 180 seconds; or fraud detection signals not displayed; or operator-provided test identity cannot be processed.

Demo Test 2: Document verification with operator-provided jurisdiction-specific documents.

Pass criteria: vendor processes all five operator-provided documents (one per relevant jurisdiction) with explicit verification confidence scores and document-specific fraud detection signals. Fail criteria: any document fails verification without explicit fraud signal explanation; verification confidence scores not provided; jurisdiction-specific document features not detected.

Demo Test 3: Biometric liveness check against operator-provided test scenarios.

Pass criteria: vendor processes static photo (should fail liveness), video recording (should fail liveness), and live test subject (should pass liveness) with explicit liveness signal explanations. Fail criteria: vendor accepts static photo as live; or accepts video recording as live; or cannot explain liveness signal detection methodology.

Demo Test 4: PEP screening against operator-provided test PEP records.

Pass criteria: vendor returns explicit PEP matches against operator-provided test PEP records including specific source data references and match confidence scoring. Fail criteria: PEP matches not returned; match confidence scoring not provided; source data references not provided.

Demo Test 5: Sanctions screening against operator-provided test sanctioned entities.

Pass criteria: vendor returns explicit sanctions matches against operator-provided test sanctioned entities including specific sanction source references and match confidence scoring. Fail criteria: sanctions matches not returned; jurisdiction-specific sanction sources not referenced; source data integration not demonstrated.

Demo Test 6: Adverse media screening against operator-provided test adverse media subjects.

Pass criteria: vendor returns explicit adverse media matches with source data and contextual information. Fail criteria: adverse media not returned; source data quality inadequate; contextual information missing.

Demo Test 7: API integration walkthrough with vendor sandbox environment.

Pass criteria: vendor sandbox environment available; API documentation comprehensive; integration completes within 30-minute walkthrough. Fail criteria: sandbox environment not available; API documentation gaps; integration cannot complete during walkthrough.

Demo Test 8: Manual case management workflow with operator-provided ambiguous case.

Pass criteria: vendor demonstrates ambiguous case flagging, prioritisation, operator-side review tooling integration, and audit trail completeness. Fail criteria: manual case management not demonstrated; operator-side integration not shown; audit trail incomplete.

Demo Test 9: Wallet attribution capability (CASP-specific).

Pass criteria: vendor demonstrates wallet ownership verification methodology, Travel Rule attestation integration, and ongoing wallet activity monitoring. Fail criteria: wallet attribution not demonstrated; Travel Rule integration not shown; ongoing wallet monitoring not demonstrated.

Demo Test 10: KYB plus UBO verification (institutional-specific).

Pass criteria: vendor demonstrates KYB verification depth including corporate ownership structure verification, multi-jurisdiction corporate registry integration, and UBO identification accuracy. Fail criteria: KYB capability shallow or absent; UBO identification not demonstrated; multi-jurisdiction registry integration not shown.

Demo Test 11: Reporting and analytics walkthrough.

Pass criteria: vendor demonstrates operator-side reporting including verification volume metrics, false positive rate, false negative rate, PEP match volume, sanctions match volume, and audit trail accessibility. Fail criteria: reporting capability shallow; metrics not surfaced; audit trail not accessible to operator.

Demo Test 12: Regulatory response capability.

Pass criteria: vendor demonstrates rapid response capability for regulatory inquiries including data retrieval timing, regulator-side communication framework, and operator-side coordination during regulator engagement. Fail criteria: regulatory response capability not demonstrated; data retrieval timing inadequate; regulator-side framework absent.

Integration testing protocol

Integration testing before contract signature reveals capability gaps that the RFP response and demo evaluation may not surface. The 10-test protocol structures operator-side pre-signature integration testing:

  1. Sandbox environment access and complete API documentation review. Operator integration team should access vendor sandbox and verify API documentation completeness against operator integration requirements.
  2. End-to-end identity verification integration with operator-side workflows. Test verification flow from operator client cabinet through vendor API to operator CRM integration with explicit fraud signal handling.
  3. Document verification integration with operator-side document storage and audit trail. Verify document handling meets operator data residency, encryption, and audit trail requirements.
  4. Biometric liveness check integration with operator client cabinet UX. Verify liveness check works correctly across desktop browser, mobile browser, native iOS app, and native Android app.
  5. PEP and sanctions screening integration with operator ongoing monitoring workflows. Verify ongoing screening integration handles alert generation, prioritisation, operator-side review, and disposition tracking.
  6. Manual case management integration with operator compliance ops team workflows. Test ambiguous case flagging end-to-end including operator compliance ops tooling integration.
  7. Reporting and analytics integration with operator BI infrastructure. Verify reporting data export, API access patterns, and operator-side analytics integration.
  8. Regulatory response simulation. Simulate regulator inquiry scenario testing data retrieval timing, regulator communication framework, and operator-side coordination.
  9. Performance and load testing at operator’s expected production volume. Test vendor performance at operator’s expected verification volume including peak load handling.
  10. Disaster recovery and incident response testing. Test vendor incident notification, regulatory notification cooperation, and operator-side communication during simulated incident.

The integration testing protocol typically takes 3-5 weeks for mid-market deployments. Operators should budget appropriately and treat the protocol as the final pre-signature procurement diligence rather than as post-signature integration work.

Decision documentation template

Procurement decision documentation supports supervisory examination of the procurement process. The decision documentation template structures the operator-side record:

Section 1: Procurement context

  • Operator regulatory positioning and archetype identification
  • Procurement scope (primary KYC, ongoing screening, Travel Rule, KYB-specific)
  • Procurement timing and decision process
  • Procurement team and roles

Section 2: Vendor shortlist

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

Section 3: RFP evaluation

  • Universal dimensions scoring per vendor
  • Per-pillar dimensions scoring per vendor
  • Per-archetype customisation applied
  • Disqualification thresholds applied with specific dimension failures noted

Section 4: Reference customer diligence

  • Reference customer list per shortlisted vendor
  • Reference customer questions asked
  • Reference customer responses summarised
  • Reference diligence-driven scoring adjustments

Section 5: Demo evaluation

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

Section 6: Integration testing

  • Integration testing dates and scope per shortlisted vendor
  • Integration testing protocol results
  • Capability gaps identified with vendor remediation commitments
  • Integration testing-driven final scoring

Section 7: Procurement decision

  • Final vendor ranking with weighted total scoring
  • Selected vendor with explicit decision rationale
  • Disqualified vendors with explicit disqualification reasoning
  • Contract terms summary including pricing, length, SLAs, termination provisions

Section 8: Ongoing monitoring

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

The decision documentation should be completed before contract signature and updated annually during the vendor relationship. Supervisory examination support requires that the documentation be available on supervisor request rather than constructed reactively.

What comes next in Phase 4

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

  • Additional per-pillar evaluation toolkits. RegTech procurement, broker CRM procurement, LP procurement, 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.

Phase 4 corpus state after this dispatch:

  • 25 Phase 3 synthesis dispatches
  • 2 Phase 4 operationally-actionable artefacts (RFP scoring framework opener plus this KYC toolkit)
  • TOTAL: 27 dispatches

The Phase 4 forward roadmap will 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 KYC 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.