Skip to main content
Commerce Security Authority
Category: Payment Ecosystem

Virtual Assets

Also known as: Digital Assets, Virtual Currency
Simply put

A virtual asset is a digital representation of value that can be bought, sold, owned, transferred, or traded electronically. Common examples include cryptocurrencies, non-fungible tokens (NFTs), and gaming tokens. These assets can be used for purposes such as payment or investment.

Formal definition

A virtual asset is a digital representation of value that can be digitally traded or transferred and used for payment or investment purposes. Examples include cryptocurrencies, non-fungible tokens (NFTs), and gaming tokens; related regulatory usage sometimes references digital assets that are issued and transferred using distributed ledger or blockchain technology. Businesses that facilitate activities involving virtual assets, such as cryptocurrency transactions, are commonly termed Virtual Asset Service Providers (VASPs). Note that terminology such as 'virtual asset,' 'digital asset,' and 'virtual currency' is defined differently across jurisdictions and regulators, so readers should confirm the applicable definition against the relevant authority.

Why it matters

Virtual assets sit at the intersection of payments, investment, and financial crime risk, which is why they draw sustained attention from regulators, financial institutions, and compliance teams. Because a virtual asset is a digital representation of value that can be bought, sold, owned, transferred, or traded electronically, it can move quickly and across borders in ways that differ from traditional card and bank rails. This creates both legitimate use cases, such as payment or investment, and exposure to fraud, laundering, and sanctions evasion that organizations must be prepared to identify and manage.

A central challenge is definitional inconsistency. Terminology such as 'virtual asset,' 'digital asset,' and 'virtual currency' is defined differently across jurisdictions and regulators, and some regulatory usage specifically references assets that are issued and transferred using distributed ledger or blockchain technology. As a result, whether a given token, cryptocurrency, NFT, or gaming token falls within a particular rule set depends on the applicable authority rather than on the label alone. Teams should confirm the controlling definition against the relevant regulator before assuming an obligation applies or does not apply.

The rise of Virtual Asset Service Providers (VASPs), which facilitate activities involving virtual assets such as cryptocurrency transactions, further shapes the compliance landscape. Where a business intermediates the buying, selling, transferring, or exchange of virtual assets, it may be treated as a VASP and become subject to obligations that vary by jurisdiction. Understanding whether an activity involves virtual assets, and whether an entity acts as a VASP, helps organizations scope their regulatory, fraud, and monitoring responsibilities accurately.

Who it's relevant to

Compliance and Financial Crime Officers
Because the definitions of virtual asset, digital asset, and virtual currency vary by jurisdiction and regulator, compliance teams must determine which authority's definition applies before scoping obligations. This is especially important when assessing whether a business qualifies as a Virtual Asset Service Provider (VASP) and therefore may be subject to jurisdiction-specific requirements.
Virtual Asset Service Providers (VASPs)
Entities and businesses that facilitate activities involving virtual assets, such as cryptocurrency transactions, need to understand how their services are classified. Whether a given activity or asset falls within a regulatory regime depends on the applicable authority's definition, which should be confirmed against the relevant regulator.
Fraud and Risk Analysts
Analysts monitoring payment and investment flows should recognize that virtual assets, including cryptocurrencies, NFTs, and gaming tokens, can be transferred electronically and may be used for payment or investment. Understanding how these assets move helps inform monitoring approaches, though the appropriate controls depend on the specific asset type and the entity's role.
Payment and Product Teams
Teams evaluating whether to support virtual assets for payment or investment purposes need to account for the differing definitions across jurisdictions and the potential VASP classification that facilitating such activity may trigger. Confirming the applicable regulatory definition early helps clarify scope before a product decision is finalized.

Inside Virtual Assets

Cryptocurrencies
Decentralized digital assets, such as those recorded on public blockchains, that may be accepted as a payment method or exchanged for fiat currency. When merchants or payment flows convert between virtual assets and card-based payments, the connected environments may bring cardholder data into scope for PCI DSS, which readers should confirm against the current published standard.
Stablecoins
Virtual assets designed to maintain a relatively stable value by referencing an external asset such as a fiat currency. They function as a distinct category from more volatile cryptocurrencies, though the exact regulatory and value-stability characteristics depend on issuer, jurisdiction, and design.
Tokenized value versus payment tokenization
Virtual assets may involve tokens representing value or ownership on a distributed ledger. This is conceptually separate from payment tokenization under PCI DSS, in which a token substitutes for a Primary Account Number (PAN) to reduce or transform cardholder data. The two uses of the word token should not be conflated, as their effect on PCI DSS scope depends on implementation and validation rather than the label.
On/off ramps and fiat conversion points
Services that convert virtual assets to or from fiat currency, often using card payments. These conversion points are where cardholder data (PAN, cardholder name, expiration date, service code) and sensitive authentication data may be handled, and where PCI DSS obligations can apply to the card-processing portion of the flow.
Custody and wallet controls
Mechanisms for holding private keys and controlling access to virtual assets, including custodial and non-custodial models. These access controls are distinct from PCI DSS controls that protect cardholder data, though similar principles such as strong access management and key protection may apply.

Common questions

Answers to the questions practitioners most commonly ask about Virtual Assets.

Are virtual assets the same as cardholder data under PCI DSS?
No. Virtual assets, such as cryptocurrencies or blockchain-based tokens, are not cardholder data as defined by PCI DSS. Cardholder data refers specifically to elements like the PAN, cardholder name, expiration date, and service code, while sensitive authentication data includes full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks. PCI DSS governs the protection of payment card data within the cardholder data environment; it does not by itself define controls for virtual assets. Where a payment flow converts card payments into virtual assets, the card-side processing may bring PCI DSS obligations into scope, but the virtual asset itself is a separate concept. Confirm applicable scope against the current published standard rather than assuming coverage.
Does using blockchain or virtual assets automatically make a payment system more secure or fraud-proof?
No. The use of blockchain or virtual assets does not by itself make a system more secure or eliminate fraud. Different technologies address different risks, and no single control prevents fraud. Fraud types such as account takeover, first-party fraud, and synthetic identity fraud can still affect systems that involve virtual assets. Any card-related processing connected to a virtual asset flow must still meet applicable PCI DSS requirements, and detection and authentication controls carry their own limitations and trade-offs. Security depends on implementation, validation, and operational controls, not on the underlying technology label.
If our platform converts card payments into virtual assets, is our card processing in PCI DSS scope?
The card-side of such a flow may be in scope for PCI DSS to the extent that your systems store, process, or transmit cardholder data or sensitive authentication data, or can affect the security of that environment. The virtual asset leg is governed by other frameworks and applicable regulations, not PCI DSS. Scope determination depends on your specific architecture, data flows, and how card data is handled before conversion. Work with a qualified assessor and confirm requirements against the current published standard, since requirement numbering and wording differ between versions.
How should we handle sensitive authentication data in a system that also processes virtual assets?
The rules for sensitive authentication data do not change because virtual assets are involved. Sensitive authentication data, including full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks, must not be stored after authorization, even when encrypted. This obligation applies to any component that touches that data, regardless of whether the downstream flow involves a virtual asset. Keep card authorization systems logically and operationally separated from virtual asset handling where feasible, and confirm your storage practices against the current PCI DSS requirements.
Can tokenization used for virtual assets be treated the same as tokenization for card data in reducing PCI DSS scope?
Not necessarily. Tokenization, encryption, truncation, masking, and hashing transform or reduce data differently, and their effect on PCI DSS scope depends on implementation and validation, not on the term used. A token representing a virtual asset is a distinct concept from a payment token that substitutes for a PAN. Only tokenization that removes cardholder data from an environment, and that is validated accordingly, may reduce PCI DSS scope for that environment. Assess each tokenization mechanism on its actual behavior and validate it rather than relying on the label.
How should authentication controls be applied where card payments intersect with virtual asset transactions?
Apply authentication controls according to the risk they address at each point in the flow. EMV chip authentication, 3-D Secure, strong customer authentication, and multi-factor authentication address different risks and are not interchangeable, and none eliminates fraud on its own. For the card acceptance leg, use the authentication controls appropriate to card-present or card-not-present processing as required by applicable card brand and network rules, which vary by region and change over time. Access controls for systems handling virtual assets are governed by separate frameworks. Layer controls rather than relying on any single mechanism.

Common misconceptions

Accepting cryptocurrency removes a merchant from PCI DSS scope.
PCI DSS applies where cardholder data and sensitive authentication data are stored, processed, or transmitted. If a merchant still accepts card payments, or uses card-funded on/off ramps to buy or sell virtual assets, those card flows can remain in scope. Scope depends on the actual data flows and validation, not on whether virtual assets are involved.
The tokens used in virtual assets are the same as PCI DSS payment tokens.
A blockchain token representing value is not the same as a payment token that substitutes for a PAN. Payment tokenization is one method of reducing or transforming cardholder data, distinct from encryption, truncation, masking, and hashing, and its effect on PCI DSS scope depends on implementation and validation.
Blockchain immutability and cryptography eliminate fraud in virtual asset transactions.
Cryptographic controls may help reduce certain risks but do not eliminate fraud. Card-funded purchases of virtual assets can still involve card-not-present fraud, account takeover, or first-party (friendly) fraud, and chargeback and liability rules for the associated card transactions are governed by card brand and network rules that vary by region and change over time.

Best practices

Map all data flows where card payments fund or cash out virtual assets, and treat the card-processing components as potentially in PCI DSS scope until scope is confirmed and validated.
Distinguish clearly in documentation and system design between blockchain value tokens and PCI DSS payment tokens to avoid conflating unrelated controls.
Ensure sensitive authentication data (full track data, CAV2/CVC2/CVV2/CID, PINs and PIN blocks) is not stored after authorization in any card-funded on/off ramp, even when encrypted, and apply defined controls to any retained cardholder data.
Apply layered authentication and fraud controls at card-funded conversion points, recognizing that EMV chip authentication, 3-D Secure, strong customer authentication, and multi-factor authentication address different risks and that detection controls involve false-positive and false-negative trade-offs.
Confirm applicable requirements against the current published PCI DSS rather than assuming fixed requirement numbers, and identify where other standards or non-PCI regulatory obligations may govern virtual asset custody or conversion.
Monitor for card-not-present fraud, account takeover, and first-party fraud on card-funded virtual asset purchases, and verify chargeback and liability handling against current card brand and network rules for the relevant regions.