
EN 18031-3 is the part of the EN 18031 standards family focused on fraud protection for radio equipment that enables the transfer of money, monetary value, or virtual currency. It supports RED Article 3(3)(f), which requires that certain connected products incorporate features to protect against fraud.
For many manufacturers, the first practical question is not whether the standard applies in principle. It is whether their product actually falls within the scope of Part 3. The answer depends on what the product enables users to do with money or value and that question is less straightforward than it appears.
This blog focuses on what counts as monetary value and virtual currency under EN 18031-3, which products need a closer look, and what manufacturers should be reviewing and documenting before launch.
Start your free EN 18031 assessment.
EN 18031-3:2024 is titled Common security requirements for radio equipment, Part 3: Internet connected radio equipment handling virtual currency or monetary value. It covers radio equipment that can communicate over the internet and enables the holder or user to transfer money, monetary value, or virtual currency.
Where EN 18031-1 focuses on network protection and EN 18031-2 focuses on personal data and privacy, EN 18031-3 focuses on the financial and value-transfer functions of connected products. It is the narrowest of the three parts in terms of the product categories it targets, but the scope question is frequently underestimated by teams who assume Part 3 only applies to payment terminals and digital wallets.
For the full picture of how Part 3 fits within the EN 18031 family, see the EN 18031 overview.
Article 3(3)(f) requires that radio equipment enabling the transfer of money, monetary value, or virtual currency must support certain features ensuring protection from fraud. Delegated Regulation (EU) 2022/30 activated this requirement, and it has applied since 1 August 2025.
EN 18031-3 provides the technical route manufacturers can use to support conformity with that requirement. In practical terms it matters when teams need to show that the product's value-transfer functions are designed with controls in place that reduce the risk of fraud, unauthorized transactions, and financial abuse.
For more on how RED cybersecurity requirements affect connected device manufacturers more broadly, see RED cybersecurity requirements.
This is the scoping question that catches most teams off guard. EN 18031-3 applies when the product enables the transfer of money, monetary value, or virtual currency. Understanding what each of these covers determines whether Part 3 is relevant to a given product.
Money in this context means legal tender transferred through the product. The clearest examples are products that initiate or process payments in conventional currency, such as connected payment terminals, point-of-sale devices with radio connectivity, or smart devices with integrated payment functions.
Monetary value is broader than money and this is where many teams underestimate their scope. Monetary value refers to stored or transferable value that can be exchanged for goods, services, or currency, even if it is not legal tender itself.
In practice this can include:
stored credit or prepaid balance held in a product or linked account
loyalty points, rewards credits, or voucher balances that carry real-world value
gift card balances accessible through a connected product
in-app credits or tokens that can be exchanged for real goods or services
subscription credits or usage allowances with monetary equivalents
The key question is not whether the value looks like money in the traditional sense. It is whether the value can be transferred, exchanged, or redeemed in a way that represents a meaningful financial risk if abused or fraudulently accessed. Products that manage loyalty schemes, prepaid balances, or transferable in-app credits may fall within scope even if they were not designed primarily as payment products.
Virtual currency has a specific definition in the context of this regulation. It refers to a digital representation of value that is not issued or guaranteed by a central bank or public authority, is not necessarily attached to a legally established currency, and does not possess the legal status of currency or money, but is accepted as a means of exchange and can be transferred, stored, and traded electronically.
In practice this covers:
cryptocurrencies such as Bitcoin, Ethereum, and similar assets
blockchain-based tokens that function as a means of exchange
platform-specific digital currencies that can be transferred between users
NFTs or digital assets with transferable monetary value in established markets
A connected radio product that enables users to send, receive, store, or manage any of these falls within the scope of EN 18031-3. This is increasingly relevant as connected products integrate with crypto wallets, blockchain platforms, or digital asset services.
EN 18031-3 is narrower than Parts 1 and 2 but broader than most teams assume. A closer review is usually needed when the product:
processes payments or initiates financial transactions
holds or transfers stored credit, prepaid balance, or loyalty value
integrates with a digital wallet or payment service
enables peer-to-peer value transfer between users
supports in-app purchases where credits have real-world monetary equivalents
connects to a cryptocurrency wallet or blockchain-based service
manages subscription balances or usage credits with financial value
The common thread is not the product category. It is the function. A smart speaker, a wearable, or a connected home device can all fall within EN 18031-3 scope if they enable value transfer of the types described above, regardless of what the product is primarily designed to do.
A useful EN 18031-3 review starts with understanding what value-transfer functions the product enables and where the fraud risk sits in the connected ecosystem.
Teams should look at:
what money, monetary value, or virtual currency the product processes or enables access to
where those functions sit across device, app, backend, and third-party payment services
how authentication and access control protect value-transfer functions
what happens if an unauthorized party gains access to the product or account
how transactions are authorized, logged, and verified
whether the product depends on third-party payment processors or digital asset services
how the product handles failed, disputed, or suspicious transactions
what update and change-management controls are in place for payment-related functions
As with Parts 1 and 2, the device-only review is rarely sufficient. For most connected products with value-transfer functions, the fraud risk does not sit only in the hardware. It sits in the account layer, the payment backend, the API connections to financial services, and the authentication flows that protect access to those functions.
Manufacturers generally need documentation that connects the product's value-transfer functions to the relevant requirements and the fraud-protection controls that address them. Typical documentation may include:
product scope and value-transfer architecture
identification of the money, monetary value, or virtual currency the product handles
data flow mapping across device, app, backend, and payment or financial services
authentication and access-control documentation for value-transfer functions
transaction authorization and verification documentation
fraud detection and response documentation where relevant
update and change-management documentation for payment-related functions
third-party financial service provider documentation where relevant
requirement mapping linking the product's fraud-protection controls to EN 18031-3 requirements
technical file materials tied to Article 3(3)(f)
For a deeper look at how to structure this evidence, see EN 18031 requirements and evidence checklist.
The most common problem with EN 18031-3 is scope denial. Teams assume Part 3 does not apply because the product is not a payment terminal. Once the value-transfer functions are mapped properly, the picture often looks different. Teams frequently get stuck when:
loyalty points and stored credits are not recognized as monetary value
in-app currencies with real-world exchange value are treated as out of scope
virtual currency integrations are handled by a third-party SDK and not included in the compliance review
authentication controls for payment functions are assessed separately from the product compliance review
fraud protection documentation exists in a commercial or legal context but is not structured for the technical file
the product connects to a payment backend operated by a partner and responsibility for that layer is assumed to sit elsewhere
That last point is significant. Even where a third party operates the payment infrastructure, the manufacturer of the connected radio product is responsible for ensuring the product-level controls that support conformity with Article 3(3)(f) are in place and documented.
A strong review should leave the team with:
confirmation that EN 18031-3 is relevant and a clear statement of why
a defined scope covering all value-transfer functions across the connected system
a view of where fraud risk sits in the product ecosystem
mapped requirements linked to the product's fraud-protection controls
identified gaps in authentication, transaction security, or documentation
a structured starting point for technical file preparation
Cyberexpert helps teams work through this, from confirming whether EN 18031-3 applies and why, to mapping value-transfer functions and building the structured evidence needed for the technical file.
Start your free EN 18031 assessment.
Related Articles