Featured Answer: A compliance-ready bank crypto payment integration requires controls across six domains: customer due diligence and AML, wallet and blockchain screening, sanctions, Travel Rule data exchange, MiCA authorisation perimeter, and third-party vendor risk. Each domain has distinct evidence requirements. The most common gap is not missing controls. It is missing proof that those controls have been tested.
EXECUTIVE SUMMARY
Most banks treat compliance as a sign-off after the vendor is chosen and the architecture is agreed. That sequencing is a mistake. Compliance controls need to be upstream of vendor selection, built into the RFP criteria, and validated before go-live. This article organises the compliance requirements for a bank crypto payment integration into six control domains. Each comes with the specific questions a CCO or financial crime lead should be asking, and the evidence they should be demanding from vendors and internal build teams. Last updated: May 2026
Checklist at a glance:
Before a bank goes live with a crypto payment integration, compliance should validate six control domains: AML/CDD, wallet and blockchain screening, sanctions, Travel Rule, MiCA/licensing perimeter, and third-party vendor risk.
Who This Checklist Is For
This framework is designed for Chief Compliance Officers, Heads of Financial Crime, Third-Party Risk Leads, and Fintech Integration Teams. It translates regulatory expectations into operational checkpoints, ensuring compliance is baked into procurement rather than bolted on post-go-live.
Why the Sequencing Problem Matters
Only 11 of 28 jurisdictions assessed by the FSB in October 2025 had finalised rules for crypto-asset service providers. Only five had done the same for stablecoins. The FSB called it clearly: implementation is incomplete, uneven, and inconsistent. That creates regulatory arbitrage across the corridors banks are now building on. Note: The FSB counts the EU and its member states as a single jurisdiction in this denominator.
This matters for a CCO. When a bank integrates a crypto payment vendor, it cannot assume the vendor's regulatory status in the destination corridor matches its home market. It cannot assume the vendor's compliance tooling fits the bank's risk appetite. And it cannot assume that a claim of compliance comes with documented evidence.
Three things go wrong when compliance enters the process too late. KYT ends up in the wrong place. A payment screened after it has been signed and broadcast on-chain is not a control. It is an incident report. Travel Rule data exchange gets scoped as post-launch, then becomes a go-live blocker. And vendor controls get assumed rather than evidenced. Assumption is not a control.
Regulatory Baseline Requirements
Before mapping vendor controls, align the integration with four core regulatory pillars:
FATF Recommendation 16: Requires originator and beneficiary data to accompany qualifying crypto transfers between VASPs and financial institutions.
U.S. BSA/AML obligations for banks and MSB obligations for vendors, exchangers, or administrators where applicable.
EU MiCA CASP Rules: Vendors and sub-processors handling EU client flows must hold CASP authorisation or operate under the transitional regime.
OFAC Sanctions Obligations: For U.S.-touching flows, the control objective is to prevent, block, or reject prohibited transactions before execution. Real-time pre-signing screening is a defensible implementation standard.
The six-domain framework below fixes that sequencing. It belongs in the vendor RFP, not the go-live checklist.
The Six Control Domains
Each domain has a clear scope, a key question to ask before vendor selection, and an evidence requirement to validate before go-live.
*Control domain framework: six compliance domains for bank crypto payment integrations. Each domain requires documented evidence from vendors and internal build teams, not assertion.
Domain 1: Customer Due Diligence and AML
Enhanced CDD applies to crypto-native counterparties. Their risk profile differs from standard corporate clients. Transaction monitoring built for fiat wire flows will miss on-chain patterns. These include rapid address cycling and high-frequency low-value transfers. The key question: has the TM system been tuned for the specific on-chain flows this integration will generate? Vendor default thresholds are not enough.
Domain 2: Wallet and Blockchain Screening
KYT must run before the payment is signed and broadcast. Post-broadcast screening is not a compliance control. It is a remediation problem. The bank needs an architecture diagram from the vendor. It should show exactly where KYT sits in the payment flow. Alert disposition must be reviewed and auditable.
Domain 3: Sanctions Screening
Real-time screening against OFAC SDN, the EU consolidated list, and blockchain-specific address lists is the baseline. The key variable is update frequency. A list that refreshes daily creates a window of exposure. The bank needs the vendor's update schedule in writing. Automated blocking logic must be tested against known sanctioned addresses before go-live.
Domain 4: Travel Rule
The EU implements Travel Rule obligations for crypto-asset transfers through Regulation (EU) 2023/1113. IVMS 101 is a widely adopted data model for structuring originator and beneficiary information between VASPs; it is not itself the EU regulation. As of FATF's June 2025 update, 99 jurisdictions have passed or are developing Travel Rule rules. But implementation is still uneven. The bank needs a written policy for the sunrise issue: what happens when a compliant VASP transacts with a counterparty in a non-compliant jurisdiction? IVMS 101 bilateral setup must be done before go-live.
Domain 5: MiCA Authorisation Perimeter
Banks should verify MiCA authorisation or transitional-regime status for each vendor or sub-processor performing in-scope crypto-asset services for EU clients. Pure technology or infrastructure sub-processors should still be mapped under outsourcing and third-party risk controls. The transitional period closes on 1 July 2026. After that, full MiCA authorisation is required. No further grace period applies.
Domain 6: Third-Party Vendor Risk
Most crypto payment vendors sub-outsource compliance tooling, KYT, liquidity, and custody to specialist providers. Each layer in that chain is a risk surface the bank inherits. The third-party risk review must cover the full sub-outsourcing chain. Incident notification SLAs, exit provisions, and service continuity must all be assessed. The review must be refreshed periodically. A one-time onboarding check is not a live control.
Stablecoin-Specific Controls
Because stablecoins introduce unique operational risks, add these controls to your compliance checklist:
Approved stablecoin list and issuer due diligence: Maintain a whitelist of stablecoins with transparent reserve attestations, regular audits, and clear redemption mechanics.
Reserve, redemption, depeg, and liquidity risk monitoring: Track issuer reserve reports, redemption windows, and on-chain liquidity depth per corridor.
Chain and bridge restrictions: Limit transactions to approved blockchains and vetted cross-chain bridges; document risk assessments for each.
Freeze/blacklist mechanics and escalation: Confirm the stablecoin issuer supports address freezing and define internal escalation paths for sanctioned addresses.
Fiat off-ramp and settlement reconciliation controls: Map the full path from stablecoin conversion to fiat credit, with daily reconciliation between on-chain events and GL entries.
Asset/corridor approval governance: Require formal sign-off for each new stablecoin, blockchain, or fiat corridor before production use.
Control Governance Matrix (RACI)
Compliance ownership cannot be ambiguous. Map each domain to explicit accountability before go-live:
Domain | Responsible | Accountable | Consulted | Informed |
AML/KYT | Financial Crime Ops | CCO / MLRO | Engineering, Vendor Risk | Audit, Board Risk Committee |
Sanctions | Compliance Tech | CCO | Legal, Treasury | Operations, Front Office |
Travel Rule | Payments Ops | Head of Compliance | Vendor Integration Lead | Legal, Reg Reporting |
MiCA/CASP | EU Compliance Lead | CCO | Legal, Product | Audit, Executive Committee |
Vendor Risk | Third-Party Risk | CRO / CCO | Procurement, Security | Vendor Management Office |
Evidence the Vendor Should Be Able to Provide
The difference between assertion and evidence is where weak vendors get separated from strong ones. The table below maps each domain to the minimum evidence a CCO should request, and the red flags that signal a gap.
Domain | Minimum evidence to request | Red flag if absent |
AML and CDD | TM tuning documentation; aggregate SAR/STR governance metrics, typology summaries, alert-to-escalation statistics; CDD policy for crypto counterparties | Vendor cannot produce governance metrics or describes TM thresholds as industry default |
Wallet and KYT | KYT architecture diagram showing node placement; alert disposition log; KYT provider audit certification | KYT runs post-broadcast, or vendor cannot evidence alert review process |
Sanctions | List update frequency log; automated blocking configuration; test results for known sanctioned addresses | Batch screening only, or update lag greater than 24 hours for OFAC SDN list |
Travel Rule | IVMS 101 message log samples; bilateral counterparty setup records; policy for sunrise-issue jurisdictions | Travel Rule scoped as post-launch, or no documented policy for non-compliant counterparty jurisdictions |
MiCA Authorisation | CASP authorisation certificate or grandfathering registration; sub-processor list with MiCA status; geo-scope confirmation | Vendor cannot confirm sub-processor MiCA status, or relies on reverse solicitation for EU clients |
Third-Party Risk | Most recent third-party risk assessment; sub-outsourcing register; incident notification SLA; exit provisions | Third-party risk review not refreshed within 12 months; no sub-outsourcing register available |
Two principles apply across all domains. Evidence must be dated. A SOC 2 report from 2022 does not confirm current controls. And evidence must be specific to this integration, not the vendor's general compliance posture.
Regulatory and Law-Enforcement RFI Handling
Vendors should evidence intake channels, response SLAs, escalation ownership, data-retention procedures, and audit logs for requests involving wallet ownership, Travel Rule data, sanctions hits, and transaction history. Define these expectations in the vendor contract before go-live.
Corridor Licensing Matrix
Map each payment corridor to its licensing perimeter:
Home Jurisdiction | Destination Jurisdiction | Activity Performed | Licence/ Registration Basis | Relying Entity | Sub-Processor Status | Evidence Source |
[Example: UK] | [Example: Singapore] | Stablecoin conversion + fiat settlement | UK FCA registration + Singapore MAS guidance | Primary vendor | KYT provider: third-party | Vendor MiCA cert + MAS correspondence |
*Update this matrix quarterly and require vendors to notify you of licensing changes within 30 days.
Live Compliance Operations & AI-Augmented Monitoring
A pre-go-live checklist is necessary but insufficient. Banks must transition to continuous control monitoring with real-time KPIs and AI-driven validation.
Example operating thresholds may include:
KYT Alert Resolution SLA: <5 minutes for high-risk flags; automated queue routing for low-confidence hits.
Sanctions Screening Latency: Real-time pre-signing checks; continuous post-transaction monitoring with update sync <15 minutes.
Travel Rule Message Success Rate: >98% bilateral IVMS 101 delivery; automated fallback for non-compliant corridors.
AI-Driven Anomaly Detection: Machine learning models trained on on-chain behavior patterns to flag structuring, rapid address cycling, or sanctions evasion before traditional KYT triggers. All AI-driven alert triage must retain human-in-the-loop oversight for final escalation, with model performance reviewed quarterly for drift and false-positive calibration.
Vendor Compliance Drift Score: Automated tracking of vendor API uptime, sub-processor changes, and regulatory action alerts. A drift score >15% triggers immediate contract review.
Cryptographically Auditable Evidence Layer
Traditional compliance evidence (PDFs, spreadsheets, email approvals) is vulnerable to alteration and audit disputes. Forward-looking banks are implementing verifiable compliance logs:
Hashed audit trails for KYT decisions, sanctions matches, and Travel Rule submissions.
Immutable timestamping stored in secure, append-only ledgers or verifiable credential systems.
Machine-readable evidence formats that integrate directly with regulator reporting portals, reducing manual audit preparation and proving control integrity without relying on vendor assertion.
Where Most Bank Builds Fall Short
Four patterns appear consistently in bank crypto builds that reach compliance review too late.
Travel Rule treated as post-launch. IVMS 101 bilateral setup takes time. Banks that scope it after go-live find it becomes a blocker, sometimes by weeks.
KYT thresholds left at vendor default. Default settings are built for the vendor's average client, not the bank's risk appetite. The compliance function must review, document, and sign off on thresholds before go-live.
MiCA sub-processor status not checked. Banks review the primary vendor and stop there. Sub-processors handling KYT, custody, or liquidity may not share the same MiCA status. This is a common gap for vendors that have expanded through acquisitions.
Third-party risk reviewed once and not refreshed. Vendor postures change. Staff turnover, sub-processor swaps, and regulatory action elsewhere all affect risk. A review that is not refreshed at least annually is not a live control.
The compliance framework is not there to block the build. It is there to make the build defensible. A crypto payment integration that goes live without documented evidence across these six domains has not been approved. It has been assumed.
For a deeper look at vendor evaluation before procurement, see RFP Checklist for Stablecoin and Crypto Payment API Vendors. For detail on exception handling and reconciliation after go-live, see [CM-33: Reconciliation, Refunds, and Exception Handling for Crypto Payment Integrations]. For detailed wallet governance and MPC control requirements, see [CM-36: Security and Wallet Governance for Bank Crypto Payment Flows].
Frequently Asked Questions
Q: What evidence should a bank request from a crypto payment integration vendor?
A: Aggregate SAR/STR governance metrics, typology summaries, alert-to-escalation statistics, KYT architecture diagrams, sanctions list update logs, IVMS 101 message log samples, MiCA authorisation certificates, and third-party risk assessments. Evidence must be dated and specific to the integration, not the vendor's general compliance posture.
Q: What AML controls are needed for stablecoin payments?
A: Enhanced CDD for crypto-native counterparties, transaction monitoring tuned for on-chain flow patterns, pre-signing KYT screening, real-time sanctions screening against OFAC SDN and blockchain-specific address lists, and stablecoin-specific controls including issuer due diligence, depeg monitoring, and freeze-mechanism escalation paths.
Q: How should banks assess MiCA status for crypto payment vendors?
A: Verify MiCA authorisation or transitional-regime status for each vendor or sub-processor performing in-scope crypto-asset services for EU clients. Pure technology or infrastructure sub-processors should be mapped under outsourcing and third-party risk controls. Require documentation of authorisation certificates and geo-scope confirmation.
Q: What third-party risk controls apply to crypto payment vendors?
A: Full sub-outsourcing chain mapping, incident notification SLAs, exit provisions, service continuity assessments, and periodic review refreshes. Maintain a live dependency register and require vendors to disclose sub-outsourcing changes within 30 days.
References:
FSB: Thematic Peer Review on the FSB Global Regulatory Framework for Crypto-Asset Activities (October 16, 2025). Source for 11 of 28 jurisdictions with finalised CASP frameworks, 5 of 28 with finalised stablecoin frameworks, and the uneven implementation finding. https://www.fsb.org/2025/10/thematic-review-on-fsb-global-regulatory-framework-for-crypto-asset-activities/
ESMA: Markets in Crypto-Assets Regulation (MiCA) overview. Source for CASP authorisation requirements, transitional regime deadlines, and supervisory convergence expectations. https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/markets-crypto-assets-regulation-mica
FATF: Sixth Targeted Update on Implementation of FATF Standards on Virtual Assets and VASPs (June 2025). Source for 99 jurisdictions implementing Travel Rule legislation and sunrise issue framing. https://www.fatf-gafi.org/en/publications/Fatfrecommendations/targeted-update-virtual-assets-vasps-2025.html
FATF: Best Practices on Travel Rule Supervision (June 2025). Source for sunrise issue definition and IVMS 101 data exchange guidance. https://www.fatf-gafi.org/content/dam/fatf-gafi/recommendations/Best-Practices-Travel-Rule-Supervision.pdf
Elliptic: FSB Thematic Review 2025 Analysis (November 2025). Source for detailed breakdown of FSB findings including CASP framework status per jurisdiction and regulatory reporting gap data. https://www.elliptic.co/blog/fsb-thematic-review-2025
OFAC: Sanctions Compliance Guidance for the Virtual Currency Industry. Source for risk-based controls, blockchain analytics, and pre-execution screening expectations. https://home.treasury.gov/policy-issues/financial-sanctions/recent-actions/20211015
FinCEN: Guidance on Requests for Information and Suspicious Activity Report Confidentiality. Source for SAR confidentiality rules and permitted sharing exceptions. https://www.fincen.gov/resources/statutes-regulations/guidance/suspicious-activity-report-confidentiality
