Zero-History Wallet Risk: How to Screen Wallets With No Transaction History

Zero-history wallet risk is the blind spot that appears when a wallet has no prior on-chain record, so standard screening tools return little or no evidence-based risk signal. The response is contextual and behavioral analysis that extends assessment beyond history, applied before funds move.
Most wallet screening tools are built around transaction history. They score wallets by analyzing prior fund flows, counterparty relationships, and behavioral patterns built up over time. This works well for wallets with an established record. It provides no coverage for wallets that have never transacted before. Zero-history wallets are common in legitimate use: new users, fresh operational wallets, and newly onboarded counterparties all start with no history. They are also common in threat activity, where fresh wallets are created to avoid detection by history-based tools. The inability to distinguish between the two creates a structural gap in most compliance and security programmes. This page covers what zero-history wallet risk is, why it matters, what signals are available when history is absent, and how pre-broadcast analysis is designed to extend coverage to the unscreened wallet population.
Reviewed for technical accuracy by Web3Firewall · Last updated: 23 March 2026
Web3Firewall provides risk intelligence and analysis tools. It does not provide legal, regulatory, or investment advice. Nothing on this page constitutes legal or compliance advice. Risk signals and screening outputs are indicators designed to support human and automated decision-making within configured workflows, not legal or regulatory determinations.
Book a Demo

What is zero-history wallet risk?

Zero-history wallet risk refers to the compliance and security exposure that arises when a wallet address has no prior transaction record for screening tools to evaluate. Because most wallet screening relies on historical transaction data and known-bad address lists, a newly created wallet returns no risk signals, creating a gap where threat actors can operate undetected until they accumulate enough history to appear in risk datasets. Zero-history wallet risk is not a specific attack type; it is a structural gap in coverage that affects any compliance or security programme relying solely on history-based screening.

Why do zero-history wallets create a screening gap?

Wallet risk screening typically works by ingesting a wallet address and retrieving its transaction history, then analyzing that history for risk signals: connections to high-risk counterparties, mixer use, structuring patterns, behavioral anomalies, and so on. The more transaction history available, the richer the risk picture.
When a wallet has no prior transactions, this entire analytical layer produces nothing. There is no history to traverse, no counterparty graph to build, no behavioral baseline to establish, and no prior labels to retrieve. The wallet address exists on-chain but is, from a screening perspective, entirely opaque.
This creates three specific problems for compliance and security programmes:
The false clean result problem
A zero-history wallet passed through a standard screening system does not return a low-risk result based on positive evidence of legitimate behavior. It returns a clean result because there is nothing to evaluate. That is a fundamentally different thing, but most screening interfaces present both outcomes identically. Compliance teams that treat a clean result from a zero-history wallet as equivalent to a clean result from a well-understood counterparty are operating on incomplete information.
The first-transaction exposure problem
The first transaction a wallet ever makes is the moment of maximum exposure for history-based screening. There is no data yet. If that first transaction is a large-value transfer, an interaction with a sensitive smart contract, or part of a coordinated attack, the screening system sees nothing to flag. Pre-broadcast analysis of the transaction itself, rather than the wallet's history, is the only analytical layer available at this point.
The deliberately clean slate problem
Threat actors understand that new wallets return clean screening results. Creating fresh wallets for each operation is a known evasion technique precisely because it resets the risk score to zero. Any programme relying solely on accumulated history-based signals is structurally unable to detect threats operating from fresh infrastructure.

How do threat actors use zero-history wallets?

Zero-history wallets appear frequently in financial crime and blockchain security incidents, typically in three distinct operational roles.
Fresh attack infrastructure
Exploit attackers, ransomware operators, and fund laundering operations routinely create new wallets for each campaign or transaction cluster. Using a fresh wallet resets the screening signal to zero and avoids any risk score accumulated from prior activity. Attack infrastructure created hours or days before an exploit is designed to be invisible to history-based detection.
Fund layering and extraction wallets
After an initial exploit or theft, funds are often moved through a sequence of newly created wallets before reaching a mixer, exchange, or final destination. Each hop through a zero-history wallet is a step where standard screening sees nothing until the wallet has been active long enough to accumulate detectable patterns. By then, the funds have typically moved again.
Address poisoning origination
Address poisoning attacks, in which an attacker sends a dust transaction from a lookalike address to insert it into a victim's transaction history, typically originate from newly created zero-history wallets. The attack wallet has no prior record, so a screening check on it returns nothing. Zero-history detection can surface the pattern at the point of the dust transaction itself, before the poisoned address is copied and used.
Onboarding fraud
In exchange and payment platform contexts, fraudulent accounts are often funded from newly created wallets with no prior history. The absence of history is not conclusive evidence of fraud, but it is a risk signal that warrants heightened scrutiny, particularly when combined with other contextual indicators such as immediate high-value activity, unusual asset choices, or rapid fund movement after initial deposit.

What signals can be used to assess zero-history wallet risk?

Request a demo
When a wallet has no prior transaction record, standard history-based signals are unavailable. Risk assessment must draw on signals that exist at or before the time of the first transaction. Several categories of contextual signal remain available.

First transaction value

The value of the first transaction from or to a zero-history wallet relative to typical new wallet behavior. A wallet that immediately transacts at high value on its first interaction is behaviorally atypical for a genuinely new legitimate wallet and may warrant closer scrutiny.

Funding source characteristics

If a zero-history wallet has received an inbound transaction before being screened, the characteristics of that funding transaction are available as risk signals: the risk profile of the sending address, the asset type, the value, and the routing path used to fund the wallet.

Creation timing

The age of the wallet relative to the transaction being assessed. A wallet created hours before a large transaction, or created in a cluster with other newly created wallets at the same time, is contextually different from a wallet that has existed for months with no activity.

Transaction velocity in early interactions

The number of transactions a wallet executes in its first hours or days of activity. Legitimate new wallets typically show gradual activity buildup. A wallet that executes many transactions rapidly from creation is exhibiting a behavioral pattern that may be inconsistent with typical new user activity.

Asset type and protocol interaction

The specific asset being transferred and the smart contracts or protocols being interacted with. A zero-history wallet interacting immediately with high-risk protocols, mixers, or bridges on its first transaction is a stronger risk signal than one making a simple token transfer.

Pre-broadcast execution path

Simulation of the transaction's full execution path before submission can reveal unexpected behaviors even when wallet history is absent. Unusual approval grants, unexpected token routing, interaction with flagged contracts, and economically anomalous state changes are all detectable at simulation time regardless of wallet age.

Coordinated new wallet activity

A wallet created at the same time as multiple other wallets with no history, particularly if those wallets are interacting with each other or with the same protocol, may suggest coordinated infrastructure rather than independent new user activity.

Counterparty risk at first contact

Even when the wallet itself has no history, its first counterparty may. If a zero-history wallet's first transaction involves a counterparty with an elevated risk profile, that counterparty signal is available as a contextual risk indicator.

Self-hosted wallet classification

Confirmation or strong indication that a wallet is self-hosted rather than exchange-hosted is relevant contextual information for risk assessment, particularly under EU AML/CFT rules and related supervisory guidance for in-scope transfers.

How does pre-broadcast analysis help with zero-history wallet risk?

Request a demo
The principle
When wallet history is absent, the transaction itself becomes the primary source of risk signal. Pre-broadcast simulation evaluates that transaction before it executes, surfacing risk indicators that are independent of prior history.
Why this matters
A wallet's history tells you what it has done. Pre-broadcast simulation tells you what this specific transaction is about to do. For zero-history wallets, simulation is often the only analytical layer available at decision time.

Execution path analysis independent of wallet history

Transaction simulation can evaluate the full execution path of a transaction, including all contract calls, token movements, state changes, and approval grants, before the transaction reaches the network. This analysis is available regardless of whether the sending or receiving wallet has any prior transaction history. Unexpected behaviors in the execution path may be detectable from the transaction itself.

First-transaction anomaly detection

Certain execution patterns are inconsistent with what legitimate first transactions typically look like. A zero-history wallet's first transaction that immediately routes through a mixer, grants a large token approval to an unfamiliar contract, or sends to an address with an elevated risk profile may be flagged at simulation time based on the transaction's own characteristics.

Funding source traceability

If a zero-history wallet has received funds prior to the transaction being assessed, pre-broadcast analysis may incorporate the characteristics of those funding transactions, including the risk profile of the sending address, the asset type, and any patterns in the funding path that suggest elevated risk.

Policy-driven controls for unscreened wallets

When configured appropriately, policy controls can be set to apply heightened scrutiny to transactions involving zero-history wallets above configurable value thresholds, routing them for manual review or requiring additional verification before submission. This applies a proportionate additional control layer to the population of wallets where standard screening has limited coverage.

How does zero-history wallet risk affect Travel Rule compliance?

The Travel Rule requires CASPs and VASPs to collect originator and beneficiary information for in-scope crypto-asset transfers, and to apply risk-based handling measures for transfers involving self-hosted wallets. Zero-history wallets create a specific operational challenge within this framework.
In the EU, Regulation (EU) 2023/1113 and related EBA guidance require CASPs to apply risk-based controls and handling measures for in-scope transfers, including those involving self-hosted wallets. When the counterparty wallet in a transfer has no prior transaction history, the risk assessment component of that process has less historical data to work with.
This does not reduce the obligation; it changes the tools available for meeting it. Risk assessment for zero-history self-hosted wallets may rely more heavily on the contextual and transaction-level signals described in Section 4, and on pre-broadcast simulation of the specific transaction, rather than on accumulated behavioral history.
For organisations subject to Travel Rule obligations, zero-history wallet risk is an operational consideration in designing the risk-assessment component of self-hosted wallet controls. The obligation to apply risk-based controls arises from applicable AML/CFT frameworks across the full transaction population, not from a separately codified requirement specific to zero-history wallets.

How does zero-history wallet risk relate to other wallet risk concepts?

Concept

Definition

Relationship to zero-history wallet risk

Zero-history wallet risk
Screening gap when a wallet has no prior transaction record
Core topic: the structural blind spot in history-based screening
Unhosted wallet risk
Risk associated with wallets not held by a regulated custodian
Zero-history is a subset: many unhosted wallets have transaction histories; zero-history is the specific case where history is absent
Wallet risk scoring
Methodology for assigning a risk score to a wallet based on its characteristics
Challenged by zero-history: standard scoring relies on history; contextual and simulation-based signals may substitute where available
Behavioral analysis
Detection of anomalous patterns relative to established baselines
Partially applicable: some behavioral signals are available at first transaction; full baseline analysis develops over time
Address poisoning
Attack using dust transactions to insert lookalike addresses into history
Intersection: poisoning attacks often originate from zero-history wallets; zero-history detection can be an early signal for poisoning attempts
On-chain AML
Application of AML controls to blockchain transaction data
Zero-history wallet risk is a specific gap within on-chain AML coverage; addressed through contextual signals and simulation rather than history
KYC / identity verification
Off-chain identity verification at onboarding
Complementary: KYC establishes who a user is; zero-history wallet risk assessment addresses what their wallet is about to do

What regulations make zero-history wallet controls relevant?

For many crypto businesses, AML/CFT obligations require risk-based controls across the full transaction population, including transactions involving wallets with no prior history. Zero-history wallet risk is an operational challenge within those existing frameworks, not a separately codified regulatory category. Firms should assess their precise requirements with qualified legal counsel.
Item 1
FATF Risk-Based Approach
FATF guidance requires VASPs to implement a risk-based approach to AML/CFT controls covering all customers and transactions, not only those with established transaction histories. FATF guidance and subsequent updates, including the June 2025 update to Recommendation 16, shape how national and regional regimes implement information requirements and risk-based controls for virtual asset activity, including for new and unhosted wallet counterparties.
Item 2
EU Transfer of Funds Regulation
Regulation (EU) 2023/1113 extends originator-and-beneficiary information requirements to in-scope crypto-asset transfers and is supported by EBA guidance on the information that must accompany transfers and how firms should handle missing or incomplete information. Under the EU framework, CASPs must apply risk-based controls and handling measures for in-scope transfers involving self-hosted wallets, as set out in the Regulation and supervisory guidance. Newly created wallets with no prior history fall within the scope of those controls where the underlying transfer is in scope.
Item 3
EU MiCA
Regulation (EU) 2023/1114 creates CASP authorisation requirements and obligations including transfer service controls. MiCA and EU AML/CFT frameworks are separate regimes that often rely on overlapping monitoring, governance, and control infrastructure. MiCA entered into force in June 2023, with the main CASP regime applying from 30 December 2024, subject in some Member States to transitional arrangements.
Item 4
FinCEN / BSA (US)
FinCEN's guidance clarifies how existing Bank Secrecy Act obligations apply to certain virtual currency business models, including AML programme, recordkeeping, and SAR obligations for covered money services businesses. Risk-based AML programmes are expected to address the full customer and transaction population. The 2019 FinCEN guidance explicitly noted it did not create new requirements but applied existing BSA rules to covered entities.
Item 5
FCA (UK)
In the UK, certain cryptoasset businesses must register under the Money Laundering Regulations and are supervised by the FCA for AML/CTF compliance. Registered firms are expected to maintain systems and controls appropriate to their money-laundering and terrorist-financing risks across their full transaction population, including transactions involving wallets with no established history.
DORA (the Digital Operational Resilience Act, applying from 17 January 2025) is not an AML/CFT regime, but increases the importance of resilient monitoring and alerting infrastructure for regulated entities, including CASPs under MiCA, across all transaction types.

MiCA compliance checklist for CASPs

This checklist covers the core operational requirements most CASPs need to address. It is a practical reference, not legal advice — firms should assess their specific obligations with qualified legal counsel.
Authorisation
  • Identify your home member state NCA and submit a MiCA CASP authorisation application
  • Demonstrate adequate financial resources and governance arrangements
  • Complete fit and proper assessment for all qualifying management personnel
  • Confirm passporting arrangements for any member states beyond your home state
  • If operating under a transitional grandfathering period, confirm the exact window applicable in your jurisdiction and the conditions under which it applies
Disclosure and conduct
  • Implement client-facing disclosures covering fees, conflicts of interest, and custody arrangements
  • Publish compliant white papers for any crypto-assets you issue
  • Establish complaint handling procedures meeting MiCA standards
  • Segregate client assets from firm assets with documented custody arrangements
Market integrity
  • Implement transaction monitoring systems capable of detecting market abuse patterns (wash trading, spoofing, layering, pump-and-dump)
  • Establish procedures for reporting suspected market abuse to your NCA
  • Maintain records supporting each market abuse report and each AML/CFT suspicious activity filing, as applicable
Travel Rule and AML/CFT
  • Implement TFR originator and beneficiary data collection for all crypto-asset transfers (no minimum threshold)
  • Apply risk-based controls and verification measures for transfers involving self-hosted (unhosted) wallets, in line with the EU framework and applicable supervisory guidance
  • Maintain real-time sanctions screening against applicable sanctions lists as required under AML/CFT obligations
  • Establish suspicious activity reporting procedures aligned with your AML/CFT obligations
Operational resilience
  • Implement ICT systems, business continuity plans, and incident management processes meeting MiCA standards
  • Establish NCA incident reporting procedures for significant operational and security incidents
  • Assess DORA obligations (applying from 17 January 2025) — including incident classification, reporting timelines, and threat-led penetration testing requirements
Ongoing compliance
  • Monitor ESMA, EBA, and European Commission publications for new RTS, ITS, and supervisory guidance
  • Review grandfathering status periodically if operating under a transitional arrangement
  • Maintain audit-ready records for all monitoring decisions, alerts, and transaction verdicts

MiCA vs MiFID II: what is the difference?

Request a demo
MiCA and MiFID II are complementary frameworks that cover different categories of asset — they do not overlap for any single asset.
MiFID II covers financial instruments. Some crypto-assets already qualify as financial instruments under MiFID II — tokenised securities are the most common example. For those assets, MiFID II continues to apply and MiCA does not.
MiCA covers crypto-assets that do not qualify as financial instruments under MiFID II. If a crypto-asset does not qualify as a financial instrument under MiFID II, it will often fall within MiCA's scope, subject to MiCA's own exclusions and the asset's specific characteristics. This includes utility tokens, asset-referenced tokens, e-money tokens, and the services built around them.
The practical question for firms is asset classification: does this crypto-asset qualify as a financial instrument? If yes, MiFID II applies. If no, it will often fall within MiCA — subject to MiCA's exclusions. For multi-product firms operating across both tokenised securities and crypto-asset services, operating under both frameworks simultaneously is a common operational reality — though it is a practical consequence of the product mix rather than a universal legal requirement.

MiCA vs prior national crypto regulation

Feature

Prior national regimes

MiCA

Geographic scope
Single member state
All 27 EU member states
Passporting
Not available
Full EU passport on single authorisation
Travel Rule / TFR
Varied by jurisdiction
Uniform — no de minimis threshold
Market abuse rules
Rarely applied to crypto
Explicitly extended to crypto-asset markets
Stablecoin regulation
Minimal or absent
Detailed ART and EMT framework
Operational resilience
Inconsistent requirements
Mandatory — reinforced by DORA from 17 Jan 2025
Enforcement
National only
NCA enforcement with ESMA coordination
Consumer protection
Varied
Standardised across the EU
Technical standards
None
Ongoing ESMA, EBA, and Commission RTS/ITS
The single most significant practical change for firms already registered under a national regime is the passporting benefit — but it comes at the cost of meeting a more demanding compliance standard. Firms previously operating under lighter-touch national registration now face authorisation requirements, capital thresholds, and ongoing monitoring obligations that are substantially more demanding. The continuing publication of ESMA and EBA technical standards means MiCA compliance is also a moving target — not a one-time implementation exercise.

Use cases by team

Request a demo
MiCA compliance requirements land differently across the organisation. Here is how different teams are affected and what capabilities they need.

Compliance and legal teams

Lead the MiCA authorisation process, maintain ongoing regulatory reporting, and manage NCA relationships. Need transaction monitoring infrastructure that produces auditable records, supports suspicious activity reporting, and generates evidence needed for regulatory examinations and supervisory review.

Exchange operations (CEX)

Implement TFR originator data collection for all transfers, apply risk-based controls for self-hosted wallet transfers, monitor order flow for market abuse patterns, and integrate wallet risk scoring into deposit and withdrawal workflows. Link text: How Web3Firewall supports crypto exchange compliance Link: /cexs

Custodians

Maintain segregated client asset records, apply TFR controls and risk-based checks for self-hosted wallet transfers, and monitor custodied wallet portfolios for changes in risk profile that trigger reporting obligations. Link text: How Web3Firewall supports custodian compliance Link: /custodians

Stablecoin and token issuers

Meet ART and EMT authorisation requirements, publish compliant white papers, maintain reserve monitoring, and implement transaction monitoring for token transfers to meet TFR and market abuse obligations under MiCA. Link text: How Web3Firewall supports stablecoin issuers Link: /stablecoin-issuers

Infrastructure providers

Support downstream CASP clients in meeting MiCA compliance obligations by integrating wallet risk scoring, transaction monitoring, and screening capabilities into the infrastructure layer — reducing the compliance build burden for clients. Link text: How Web3Firewall supports infrastructure providers Link: /infrastructureproviders

MSSPs

Deliver managed MiCA compliance monitoring as a service. Use Web3Firewall's API to power TFR support, wallet screening, market abuse alerting, and regulatory reporting workflows for multiple CASP clients from a single integration. Link text: How Web3Firewall supports MSSPs Link: /mssps

Why Web3Firewall for MiCA compliance

Request a demo
MiCA compliance is an operational challenge, not a documentation one. The regulation's transaction monitoring, market abuse detection, Travel Rule, and incident reporting requirements all demand live, continuous capability — not annual audits or static policy documents.
Every transaction processed through Web3Firewall receives a real-time verdict: allow, deny, or require approval. This means CASPs are not just generating records for auditors — they are actively enforcing compliance policies at the transaction level, in real time, before funds move.
Web3Firewall is a Web3 security and compliance platform — often described as a SIEM for blockchain. It runs on transactions routed through the platform in near real time, feeds into an automated verdict system, and integrates with compliance workflows designed to support — not replace — the controls organisations need to align with frameworks such as MiCA, NIST, and OWASP. No software product alone satisfies MiCA, DORA, or TFR obligations in full; Web3Firewall provides the operational infrastructure that supports compliance workflows within a broader programme.

Travel Rule and TFR support

Wallet screening and risk scoring for every transfer — including the risk-based controls and verification measures needed for self-hosted wallet transfers under Regulation (EU) 2023/1113. Provides a structured, auditable risk assessment signal designed to support EU Travel Rule compliance workflows efficiently at scale.

Real-time transaction monitoring

Continuous monitoring of transaction flows, wallet interactions, and on-chain behavior. Automated alerting when patterns consistent with market abuse, money laundering, or suspicious activity are detected — with complete audit trails supporting NCA reporting.

Wallet risk scoring for self-hosted wallets

The TFR requires risk-based controls for self-hosted wallet transfers. Web3Firewall's wallet risk scoring provides a structured, auditable risk assessment for any blockchain address — integrating directly into deposit and withdrawal workflows.

Programmable compliance policy engine

Define compliance policies aligned with your regulatory obligations in a no-code interface or via API. Policies can be jurisdiction-aware, asset-specific, or threshold-driven. The enforcement layer updates as ESMA and EBA technical standards evolve.

Incident detection and reporting support

MiCA requires CASPs to detect and report significant operational and security incidents. Web3Firewall's behavioral monitoring surfaces anomalous activity early — giving compliance teams the lead time needed to assess materiality, document the incident, and meet NCA reporting deadlines.

Audit-ready evidence trails

Every decision, alert, and transaction verdict is logged with execution details, risk signals, verdict, and supporting evidence. Compliance teams have a complete, auditable record for NCA examinations, suspicious activity reporting, and internal governance reviews.

Get MiCA-ready with Web3Firewall

Try the sandbox to see wallet screening and transaction monitoring in action, or book a 30-minute demo to discuss how Web3Firewall supports your MiCA compliance programme.
Try the sandbox
Book a demo

Frequently Asked Questions

What is Web3 incident response?

Web3 incident response is the set of processes and tools used to detect, investigate, and contain security incidents affecting blockchain infrastructure — including smart contract exploits, wallet compromises, bridge attacks, and unauthorised token movements. It differs from traditional IT incident response because blockchain transactions are irreversible and assets move at machine speed across decentralised networks.

How is Web3 incident response different from traditional IR?

In traditional IT, incident responders can contain a breach by isolating systems, revoking access, or rolling back changes. In Web3, confirmed transactions cannot be reversed. This makes pre-exploit detection and automated enforcement — identifying attacker reconnaissance and staging activity before funds move — far more valuable than post-incident forensics alone.

What does a Web3 security incident look like?

Crypto exchanges are required under AML and VASP regulations in most jurisdictions to monitor transactions and identify suspicious activity. Wallet risk scoring automates a large part of that process — flagging high-risk deposits and withdrawals for review without requiring manual analysis of every transaction.

What is the difference between wallet risk scoring and blockchain analytics?

Blockchain analytics is a broad category covering any analysis of on-chain data. Wallet risk scoring is a specific, structured output: an actionable risk signal attached to a wallet address. Scoring is designed to integrate into operational workflows — transaction monitoring, onboarding checks, compliance queues — rather than being used purely for investigation or research.

Can wallet risk scoring detect new or unknown threats?

Yes. Behavioural analysis can identify suspicious patterns even when a wallet has no prior labels or flags. By comparing a wallet's behaviour to known patterns of money laundering, scam activity, or protocol exploitation, risk engines can surface novel threats before they appear in external watchlists.

What regulations require wallet risk monitoring?

Key frameworks include FATF Recommendation 16 (the Travel Rule), the EU's MiCA regulation, FinCEN guidance for US-based VASPs, and the UK FCA's requirements for registered crypto asset firms. All require some form of transaction monitoring and suspicious activity reporting — for which wallet risk scoring provides the operational foundation.

How often are wallet risk scores updated?

In a well-designed system, scores update on a near-real-time basis as new transactions are confirmed on-chain. A wallet that clears an onboarding check can see its score change significantly after a single new transaction — which is why ongoing monitoring matters, not just point-in-time checks at onboarding.

What blockchains does wallet risk scoring cover?

Most enterprise-grade scoring systems cover Bitcoin, Ethereum, and their Layer 2 networks, plus leading altcoins and EVM-compatible chains. Coverage varies by provider. Web3Firewall supports multi-chain scoring across the most widely used blockchain networks from a single API integration.
HomeAbout UsCareerProductPartnership
CEXsCustodiansInfrastructure ProvidersMSSPsStablecoin and Token Providers
Docs Blogs Privacy Policy Terms and Conditions
© All rights reserved. Web3Firewall. Privacy |  Terms and Conditions