Businesses should verify customers at onboarding and before transaction approval, then keep that identity tied to the account across future activity. Crypto changes the payment rail, not the need for accountability. Strong verification helps reduce anonymous abuse, supports AML obligations, and gives teams a defensible basis for risk decisions when higher value or repeat transactions appear.
When a business accepts cryptocurrency, customer verification should follow the same accountability standard used for other payment methods, but it should be anchored to onboarding and transaction approval rather than the payment rail itself. The practical issue is not whether the payment settles on-chain, it is whether the business can reliably tie activity to a verified customer, apply risk-based review, and preserve evidence for AML and fraud decisions.
Verify the customer, not the coin transfer
Crypto payments often feel different operationally because settlement can be fast, irreversible, and pseudonymous. That does not remove the need to know who the customer is. Businesses should verify identity before allowing higher-risk activity, then keep that verified record attached to the customer account so repeat payments, refund requests, chargeback-like disputes, and suspicious patterns can be assessed consistently.
The key distinction is between payment execution and customer accountability. A wallet address may tell you where funds came from, but it does not by itself establish who controls the account, whether the source of funds is legitimate, or whether the transaction should be accepted under your policies. That is why verification belongs in the customer lifecycle, not as an afterthought when crypto arrives.
For teams building the control set, OWASP ASVS is a useful reference for thinking about identity proofing, authentication, and access decisions around the customer record. Where businesses operate across jurisdictions, the customer due diligence side is also shaped by FATF Recommendations, which frame KYC, beneficial ownership, and virtual asset controls as part of a defensible AML program.
Use risk-based verification tiers
Not every crypto payment needs the same level of scrutiny. A low-value, one-off purchase from an already verified customer may justify a lighter review than a large transfer, a new account, a refund to a different destination, or a pattern of repeated high-value activity. Good practice is to vary the friction by value, velocity, jurisdiction, wallet history, and product risk, while keeping the decision rules consistent enough to explain later.
This is where businesses often get into trouble: they either over-apply manual checks and create unnecessary friction, or they under-verify because the payment method appears “self-authenticating.” A defensible model links the customer to a stable internal account, flags exceptions, and requires extra review when the transaction profile changes materially. That makes the process auditable and easier to defend if AML or fraud questions arise later.
If your verification flow depends on external identity assurance, the European digital identity direction is moving toward stronger reusable identity frameworks through eIDAS 2.0. For businesses that authenticate users digitally, NIST SP 800-63 Digital Identity Guidelines remains a solid benchmark for assurance thinking, especially when fraud risk is high enough to justify stronger proofing or phishing-resistant authentication.
Keep the verification record tied to the customer lifecycle
Verification is only useful if it survives account changes, payment method changes, and repeated activity over time. Businesses should preserve the verified identity, the verification date, any risk flags, and the reason for escalation so they can compare new transactions against prior behavior. That matters when a customer changes wallet addresses, returns later after a long gap, or starts moving materially larger amounts.
Operationally, the best outcome is a single customer record with clear evidence of who was verified, when they were verified, and under what conditions the business accepted the transaction. That gives compliance, fraud, and support teams a common basis for decisions instead of forcing each review to start from zero. It also helps when a business must demonstrate that it did more than simply accept an anonymous crypto transfer.
From a control perspective, the closest discipline is not “crypto-specific payments” so much as identity and account governance. If the customer record is weak, the payment method becomes a convenient abuse channel. If the customer record is strong, crypto can be handled as another rail with appropriate monitoring, rather than as a special exception that bypasses accountability.
Risk and Threat Considerations
Crypto acceptance can attract anonymous abuse, stolen-account activity, sanctions exposure, and layered laundering attempts if verification is treated as optional or applied only after funds arrive. The business risk is not just loss of funds, it is weak attribution, poor case handling, and an inability to justify why a transaction was accepted or rejected.
Failure mechanism: Attackers and abusive users exploit weak onboarding, reused accounts, or inconsistent review thresholds to move value through accounts that were never properly tied to a real customer, or to switch wallets after initial verification and avoid pattern detection.
Impact: The business may process higher-risk payments without a defensible customer trail, increasing AML exposure, fraud loss, refund disputes, and the chance that suspicious activity is missed until after settlement.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-63, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V6 — Authentication | Customer verification depends on strong authentication and account binding. |
| V8 — Authorization | Crypto acceptance needs risk-based approval and transaction gating. | |
| V16 — Security Logging and Error Handling | Verification decisions must be auditable for AML and fraud review. | |
| Recommendation — Use V6 to require stronger identity proofing and authentication before approving higher-risk crypto activity. Use V8 to enforce transaction approval rules that vary by value, velocity, and customer risk. Use V16 to log verification evidence, exceptions, and approval decisions for later review. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Provides assurance levels and identity proofing guidance for verified customer accounts. |
| Recommendation — Align proofing and authentication strength to the transaction risk using NIST 800-63 assurance concepts. | ||
| CIS Controls v8 | CIS-5 — Account Management | Customer verification must persist as an accountable account record over time. |
| Recommendation — Apply CIS-5 to keep customer identity, status, and exceptions tied to the account lifecycle. | ||
| NIST SP 800-53 Rev 5 | IA-8 — Identification and Authentication (Non-Organizational Users) | Customers are external users whose identity must be established and bound to activity. |
| AU-2 — Event Logging | Verification and approval decisions need traceable records for AML and fraud review. | |
| Recommendation — Use IA-8 to require verified identification for customer accounts before approving higher-risk payments. Use AU-2 to record verification events, risk escalations, and approval outcomes. | ||
Practitioner Guidance
What to prioritise: Verify the customer before granting meaningful payment latitude, then make the account record the source of truth for later review. If a wallet changes, a transaction spikes in value, or the customer returns after a long dormant period, treat that as a verification checkpoint rather than a routine payment event.
What to verify: Teams should be able to show who was verified, what evidence supported the decision, and what exception logic was applied for higher-risk transactions. If you cannot explain why a crypto payment was accepted in one case and escalated in another, the verification model is too ad hoc to be reliable.
Practitioner takeaway: The safest approach is to treat cryptocurrency as a payment rail, not as a substitute for customer identity, because the control objective remains accountability across the full customer lifecycle.
Related resources from NHI Mgmt Group
- What should businesses do when they need both customer verification and secure communications recordkeeping under RICA?
- How should security teams handle risks from AI browser extensions?
- How should teams handle secrets that have no obvious owner?
- How should organisations handle identity verification across customer channels?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
