DISPATCH ·

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

Thirty-first dispatch. Fifth per-pillar Phase 4 evaluation toolkit. Operationally-actionable artefact for Chapter VI payments procurement covering the multi-PSP procurement norm (4-12 PSPs depending on geographic coverage), distinct banking partner procurement separate from PSP procurement, per-merchant PSP underwriting variability, SEPA Instant verification of payee UX complexity, stablecoin rails as regulated infrastructure decision under MiCAR Title III/IV, and per-jurisdiction rail coverage. The toolkit provides procurement-stage questionnaire (36 questions structured per payments component), reference customer questions (16 questions covering operational reality including chargeback rates and PSP underwriting decisions), demo evaluation rubric (12 tests with live transaction testing and reconciliation flow), integration testing protocol (10 pre-signature tests), and decision documentation template.

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

Why this dispatch exists

This is the thirty-first dispatch and the sixth in the Phase 4 operationally-actionable artefact sub-series. The earlier Phase 4 dispatches covered the RFP scoring framework opener, KYC evaluation toolkit, RegTech evaluation toolkit, broker CRM evaluation toolkit, and LP procurement evaluation toolkit. This dispatch covers the fifth per-pillar evaluation toolkit: payments procurement.

Payments procurement is structurally distinct from the four prior toolkits because the procurement decision is operator-specific rather than product-specific. PSP underwriting varies by merchant category code, leverage profile, jurisdiction, and operator-specific risk characteristics; the same PSP can decline one operator’s procurement and accept another. The payments and EU banking regime dispatch covered the three regulatory developments shaping 2026 EU payments (SEPA Instant mandate completion, MiCAR Title III/IV stablecoin issuer regime, PSD3 in flight), the CFD broker fiat banking reality post-2023 derisking, the CASP fiat banking reality with the Bank Frick concentration as the single largest CASP procurement risk, and the stablecoin rails for institutional flow as regulated infrastructure rather than operational workaround.

The 2026 procurement-relevant question for payments is multi-component procurement: banking partner procurement (typically 1-4 banking partners depending on operator scale), PSP procurement (typically 4-12 PSPs depending on geographic coverage), stablecoin rail procurement (regulated EU stablecoin issuers under MiCAR), and per-jurisdiction rail-specific procurement (Pix Brazil, SPEI Mexico, PayNow Singapore, FPS Hong Kong, Zengin Japan, PayID Australia, etc.). This toolkit provides operationally-actionable artefacts for each procurement layer.

Payments procurement scope recap

The payments procurement scope spans:

Banking partner procurement. Specialist banking partners for CFD broker operational accounts (Bank Frick, BCB Group, Clear Junction, Bank of Valletta, Sygnum) plus CASP-friendly banking partners (Bank Frick primary plus Sygnum plus BCB Group plus Clear Junction). Universal procurement requirement; concentration risk warrants secondary banking diligence per the payments + EU banking dispatch.

PSP procurement (CFD-touching). Specialist FX and CFD PSPs (Praxis Cashier, Praxis Tech), broker-stack-bundled PSPs (B2BinPay, Match-Trade payments, Quadcode payments, Leverate PSP partnerships), consumer-payments brand families (NETELLER, Skrill under Paysafe). Universal procurement requirement; typically 4-12 PSPs depending on geographic coverage.

Stablecoin rail procurement (institutional flow). USDC through Circle EMI France (lowest-friction EU procurement path), EURC through Circle EMI, USDT under continuing regulatory ambiguity, Banking Circle plus Schuman plus smaller regulated EUR stablecoins. Procurement-relevant from initial operations for CASP and institutional archetypes; Year-2-or-later for retail CFD broker operations.

Per-jurisdiction rail procurement. Brazil Pix (Pix Cobranca + Pix Saque + Pix Automatico) for LATAM Archetype G with material Brazilian client mix; Mexico SPEI plus OXXO for LATAM Mexican coverage; Singapore PayNow plus GIRO for APAC Archetype F Singapore operations; Hong Kong FPS for APAC HK operations; Japan Zengin plus PayPay plus Konbini for APAC Japan operations; Australia PayID plus BPay for APAC Australia operations; Korea KFTC for APAC Korea operations.

Institutional fiat infrastructure (Archetype H specific). SWIFT plus correspondent banking with tier-1 banks (HSBC, Standard Chartered, First Abu Dhabi Bank, Emirates NBD) replaces retail PSP infrastructure. Card acquiring and retail PSP infrastructure largely irrelevant for institutional broker operations.

The toolkit below covers banking partner procurement, PSP procurement, and stablecoin rail procurement with separate evaluation criteria; per-jurisdiction rail procurement follows the PSP procurement framework with archetype-specific questions.

Procurement-stage questionnaire template

The questionnaire template includes 36 specific RFP questions structured by component plus framework dimension.

Universal dimensions (5 questions per the Phase 4 opener)

  1. Provide your pricing structure including base pricing, per-transaction pricing, FX conversion margins, settlement fees, chargeback handling fees, and any per-volume rebate arrangements.
  2. List your regulatory authorisations and certifications including specific licenses (PSP licenses, EMI licenses, payment institution licenses), jurisdiction-specific certifications, and PCI DSS compliance status.
  3. Describe your customer support structure including dedicated relationship management, support response SLAs, escalation paths, and operational issue handling.
  4. Provide your most recent financial position disclosure including parent company disclosure framework if applicable.
  5. Describe your product roadmap including new rail additions, technology investments, and regulatory readiness commitments for SEPA Instant mandate, MiCAR Title III/IV, PSD3 transition.

Banking partner dimensions (8 questions)

  1. (Banking partner procurement) Confirm your acceptance of the operator’s merchant category code (CFD broker MCC 6211, CASP MCC categories) and the operator’s specific operational profile.
  2. List your jurisdiction-specific accounts available including EUR, GBP, USD, AED, CHF account currencies and the underwriting requirements per account type.
  3. Describe your operational account features including SEPA plus SEPA Instant integration, SWIFT correspondent banking, multi-currency wallet, and intraday liquidity management.
  4. Describe your CASP-specific positioning if applicable including specific authorisation framework alignment, supervisory positioning, and CASP merchant acceptance criteria.
  5. Describe your account application process including specific information requirements, review timeline (typically 4-12 weeks for specialist banks), and operator-side preparation guidance.
  6. Describe your ongoing relationship management including dedicated relationship manager assignment, periodic relationship review cadence, and operator-side communication during regulatory developments.
  7. List your reference operators in the operator’s specific archetype with account tenure and operational profile.
  8. Describe your concentration risk mitigation including operator-side secondary banking diligence support and operator-side migration support if concentration risk materialises.

PSP procurement dimensions (10 questions)

  1. (PSP procurement) Confirm your underwriting decision for the operator’s specific MCC, leverage profile, jurisdiction combination. Provide explicit underwriting positioning rather than category-level vendor positioning.
  2. List your supported rails including card acquiring (Visa, Mastercard, regional cards), bank transfer rails (SEPA, SEPA Instant, wire), regional rails (Pix, SPEI, FPS, PayNow, PayID), and stablecoin rails if applicable.
  3. Describe your geographic coverage including specific countries with underwriting acceptance, country-specific approval rates, and country-specific limitations.
  4. Describe your chargeback handling framework including chargeback ratio thresholds, monitored program implications, operator-side chargeback dispute support, and chargeback fee structure.
  5. Describe your FX conversion margins for multi-currency operations including specific currency pair margins, FX rate sources, and operator-side FX rate transparency.
  6. Describe your settlement schedule including settlement frequency, settlement currency options, and operator-side settlement integration.
  7. Describe your reconciliation flow with operator’s CRM including data formats, API integration, exception handling, and operator-side reconciliation support.
  8. Describe your verification of payee implementation for SEPA Instant including operator-side UX integration, exception handling, and IBAN-name matching workflow.
  9. Describe your KYC integration including merchant-side KYC requirements and PSP-side merchant onboarding KYC.
  10. Provide reference operators in the operator’s specific archetype with PSP relationship tenure and operational characteristics.

Stablecoin rail dimensions (6 questions)

  1. (Stablecoin rail procurement) Describe your regulatory positioning including specific authorisation status (EMI under MiCAR, traditional banking license, payment institution license).
  2. List your supported stablecoins including USDC under Circle EMI, EURC under Circle EMI, USDT positioning, Banking Circle stablecoin, Schuman stablecoin, and other regulated EUR stablecoins.
  3. Describe your fiat on/off ramp infrastructure including specific currencies supported, settlement timing, and operator-side integration architecture.
  4. Describe your Circle Mint or equivalent institutional access including API integration, settlement API, and operator-side reconciliation support.
  5. Describe your operator-side risk framework including stablecoin issuer counterparty risk, redemption risk management, and operator-side mitigation framework.
  6. Describe your post-Tether-regulatory-evolution positioning including USDT exposure handling for operators with material existing USDT flow.

Per-jurisdiction rail dimensions (4 questions)

  1. (Per-jurisdiction rail procurement, archetype-specific) Describe your specific rail integration for operator’s required jurisdictions including Pix (Brazil), SPEI (Mexico), PayNow (Singapore), FPS (Hong Kong), Zengin (Japan), PayID (Australia), Korea KFTC.
  2. Describe your local PSP partnerships within each jurisdiction including specific local PSPs aggregated and operator-side transparency about underlying PSP relationships.
  3. Describe your jurisdiction-specific compliance handling including local tax disclosure, local reporting requirements, and operator-side compliance support.
  4. Describe your operator-side multi-jurisdiction reconciliation including consolidated reporting across jurisdictions and operator-side multi-currency reconciliation workflow.

Phase 4 framework alignment (3 questions)

  1. How does your product address the banking concentration risk procurement implication from the payments dispatch? Specifically: operator-side secondary banking support if your relationship is primary.
  2. How does your product align with SEPA Instant mandate compliance including verification of payee UX implementation and operator-side client cabinet integration support?
  3. How does your product align with stablecoin rail procurement as regulated infrastructure rather than operational workaround? Specifically: regulatory framework documentation and operator-side risk mitigation framework.

Reference customer questions

Reference customer diligence for payments procurement requires understanding both PSP underwriting decisions and operational reality including chargeback rates and operator-side reconciliation experience. The 16 questions structure operator-side reference conversations:

Operational reality (6 questions)

  1. How long has your operation been using this PSP/banking partner and at what transaction volume?
  2. What is your actual approval rate (legitimate transactions accepted) across your client geography versus the PSP’s pre-contract positioning?
  3. What is your actual chargeback rate at production volume and how does the PSP handle chargeback monitoring and dispute support?
  4. How transparent is the PSP’s FX conversion margin in operational reality? Did pricing match the pre-contract positioning?
  5. How responsive is the PSP’s customer support to operational issues? Are dedicated relationship management arrangements honoured?
  6. (Banking partner) How responsive is the banking partner to regulatory developments? Specifically: SEPA Instant mandate implementation, EU AMLR transition, MiCAR-adjacent banking expectations.

Procurement specifics (5 questions)

  1. How did the PSP/banking partner handle the underwriting decision process? Were they responsive to operator-side procurement-stage questions?
  2. What contract terms did you actually achieve versus the PSP/banking partner’s positioning? Specifically: pricing, FX margins, chargeback fees, termination provisions.
  3. (Banking partner) How rigorous was the banking partner’s compliance review during application? What is the ongoing compliance review cadence?
  4. Have you encountered situations where the PSP/banking partner’s regulatory positioning was inadequate for your operational context?
  5. How transparent is the PSP/banking partner about their financial position and operational continuity during ongoing operational relationship?

Operational quality (5 questions)

  1. (Per-jurisdiction rails) How clean is the rail integration in operational reality? Specifically: Pix integration, SPEI integration, PayNow integration, FPS integration depending on operator’s geography.
  2. How accurate is the reconciliation flow between PSP statements and operator’s CRM? Have you encountered persistent reconciliation discrepancies?
  3. (SEPA Instant) How clean is the verification of payee UX integration? Specifically: client cabinet UX during withdrawal flow.
  4. (Stablecoin rails) How responsive is the stablecoin rail provider to regulatory developments? Specifically: how did they handle Circle EMI France authorisation, MiCAR Title III/IV implementation, USDT regulatory ambiguity.
  5. Would you procure this PSP/banking partner again given the same procurement decision context? Why or why not?

Demo evaluation rubric

Payments procurement demos involve live transaction testing against PSP sandbox environments, reconciliation flow demonstration, and chargeback simulation. The 12-test rubric structures operator-side demo evaluation:

Demo Test 1: Live transaction testing in PSP sandbox.

Pass criteria: PSP demonstrates deposit flow, withdrawal flow, and refund flow from operator-provided test environment with explicit transaction-level visibility. Fail criteria: sandbox not available; transaction visibility limited; flow gaps in deposit/withdrawal/refund cycle.

Demo Test 2: Multi-rail transaction testing.

Pass criteria: PSP demonstrates transaction handling across operator’s required rail set including card acquiring, bank transfer, and regional rails relevant to operator’s geography. Fail criteria: multi-rail coverage limited; specific rails not demonstrated; rail-specific limitations not disclosed.

Demo Test 3: Multi-currency transaction testing.

Pass criteria: PSP demonstrates multi-currency transaction handling including FX conversion with explicit margin transparency and operator-side reconciliation flow. Fail criteria: multi-currency support limited; FX margin opacity; reconciliation gaps.

Demo Test 4: Reconciliation flow demonstration.

Pass criteria: PSP demonstrates reconciliation flow between PSP statements and operator’s CRM including data formats, exception handling, and operator-side reconciliation tooling integration. Fail criteria: reconciliation flow shallow; exception handling absent; operator-side integration not demonstrated.

Demo Test 5: SEPA Instant verification of payee demonstration.

Pass criteria: PSP demonstrates verification of payee implementation including operator-side client cabinet UX integration, IBAN-name matching, and exception handling. Fail criteria: verification of payee not implemented; UX integration absent; exception handling shallow.

Demo Test 6: Chargeback simulation testing.

Pass criteria: PSP demonstrates chargeback handling workflow including chargeback notification, operator-side dispute submission, chargeback ratio monitoring, and monitored program threshold disclosure. Fail criteria: chargeback workflow opaque; dispute submission absent; monitoring thresholds undisclosed.

Demo Test 7: Per-jurisdiction rail demonstration (jurisdiction-specific).

Pass criteria: PSP demonstrates jurisdiction-specific rail integration relevant to operator’s geography (Pix demo for LATAM, PayNow demo for Singapore, FPS demo for Hong Kong, etc.) including rail-specific UX flow. Fail criteria: jurisdiction-specific rail not demonstrated; local PSP partnership opacity.

Demo Test 8: KYC integration demonstration.

Pass criteria: PSP demonstrates KYC integration including PSP-side merchant onboarding KYC and merchant-side client KYC integration with operator’s primary KYC vendor. Fail criteria: KYC integration shallow; primary KYC vendor not supported; merchant-side KYC workflow absent.

Demo Test 9: Settlement and reporting demonstration.

Pass criteria: PSP demonstrates settlement schedule, settlement currency options, operator-side reporting access, and audit trail completeness. Fail criteria: settlement schedule inflexible; reporting access limited; audit trail incomplete.

Demo Test 10: Stablecoin rail demonstration (crypto-touching).

Pass criteria: Stablecoin rail provider demonstrates fiat on/off ramp, Circle Mint API integration (or equivalent), settlement timing, and operator-side reconciliation support. Fail criteria: stablecoin rail capability shallow; institutional API not demonstrated; reconciliation absent.

Demo Test 11: Banking partner application walkthrough.

Pass criteria: Banking partner demonstrates application process including specific information requirements, compliance review timeline, and operator-side preparation guidance. Fail criteria: application process opaque; timeline estimate absent; preparation guidance shallow.

Demo Test 12: Disaster recovery and incident response demonstration.

Pass criteria: PSP/banking partner demonstrates incident response framework including outage notification timing, operator-side communication, and backup rail activation. Fail criteria: incident response framework absent; outage notification timing inadequate; backup rail capability not demonstrated.

Integration testing protocol

Payments integration testing protocol structures operator-side pre-signature testing across PSP integration plus banking partner integration:

  1. PSP sandbox integration testing. Test PSP API integration including authentication, transaction submission, transaction status checking, refund processing, and webhook handling.
  2. Multi-currency transaction testing at production volume. Test multi-currency transaction handling at operator’s expected production volume including FX conversion accuracy and reconciliation completeness.
  3. CRM integration testing. Test PSP integration with operator’s CRM including transaction flow, balance updates, exception handling, and operator-side workflow integration.
  4. Reconciliation testing at production scale. Test reconciliation flow at expected production transaction volume including PSP statement processing, CRM transaction matching, and exception resolution workflow.
  5. SEPA Instant verification of payee integration testing. Test verification of payee UX integration end-to-end from client cabinet through PSP API with exception handling validation.
  6. Per-jurisdiction rail integration testing. Test jurisdiction-specific rail integration relevant to operator’s geography including end-to-end transaction flow and reconciliation validation.
  7. KYC integration testing. Test KYC integration with operator’s primary KYC vendor including merchant-side KYC handoff and PSP-side merchant onboarding KYC workflow.
  8. Disaster recovery testing. Test backup rail activation, PSP failover scenarios, and operator-side incident response coordination.
  9. Banking partner application preparation. For banking partner procurement, prepare application materials including operator information requirements, compliance documentation, and supervisory reference materials.
  10. Stablecoin rail integration testing (crypto-touching). Test Circle Mint API integration (or equivalent) including fiat on/off ramp transaction flow, settlement timing validation, and operator-side reconciliation testing.

Integration testing typically takes 4-8 weeks for PSP integration; banking partner application typically takes 4-12 weeks for specialist banks (Bank Frick, BCB Group, etc.) with the application timeline separate from integration testing because banking application precedes operational integration.

Decision documentation template

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

Section 1: Procurement context

  • Operator regulatory positioning and archetype identification
  • Payments procurement scope (banking partner count, PSP count per geography, stablecoin rail relevance, per-jurisdiction rail requirements)
  • Procurement timing and decision process
  • Procurement team and roles

Section 2: Vendor shortlist per component

  • Banking partner shortlist with operator-side credit assessment
  • PSP shortlist per jurisdiction with operator-side underwriting positioning evaluation
  • Stablecoin rail shortlist (if crypto-touching)
  • Initial screening criteria per component

Section 3: RFP evaluation per component

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

Section 4: Reference customer diligence

  • Reference customer list per shortlisted vendor per component
  • Reference responses summarised
  • Chargeback rate and operational reality documentation
  • Reference diligence-driven scoring adjustments

Section 5: Demo evaluation

  • Demo dates and participants per shortlisted vendor
  • Demo evaluation rubric results across 12 tests
  • Live transaction testing documentation
  • Demo-driven scoring adjustments

Section 6: Integration testing

  • Integration testing dates and scope per shortlisted vendor
  • Banking partner application timing if applicable
  • Capability gaps identified with vendor remediation commitments

Section 7: Procurement decision per component

  • Banking partner selection with concentration risk mitigation framework
  • PSP selection per jurisdiction with rationale
  • Stablecoin rail selection if applicable
  • Contract terms summary per vendor

Section 8: Ongoing monitoring

  • Banking partner relationship monitoring including concentration risk evaluation
  • PSP performance monitoring including approval rate, chargeback rate, settlement reliability
  • Stablecoin rail issuer regulatory positioning monitoring
  • Vendor review cycle per component
  • Procurement decision review triggers (regulatory shifts, banking partner concentration, PSP underwriting deterioration, stablecoin issuer regulatory changes)

What comes next in Phase 4

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

  • Additional per-pillar evaluation toolkits. Broker analytics, copy trading, IB management, brokerage hosting, trading platform, prop firm tech, alt-WL platforms, crypto exchange WL, risk management, turnkey suites toolkits.
  • Per-archetype RFP templates. Complete RFP templates customised per archetype combining the universal dimensions plus relevant per-pillar dimensions plus per-archetype customisation.
  • Vendor evidence library. Aggregated evidence on specific vendors against framework dimensions.
  • Institutional procurement toolkit (Archetype H specific). Institutional fiat infrastructure procurement (SWIFT plus correspondent banking) follows structurally different framework that future Phase 4 artefact will cover.

Phase 4 corpus state after this dispatch:

  • 25 Phase 3 synthesis dispatches
  • 6 Phase 4 operationally-actionable artefacts
  • TOTAL: 31 dispatches

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