ERC-4337 Account Abstraction and AML: How Smart Wallets Change Transaction Screening

A compliance system receives an Ethereum TXID. The top-level from address belongs to a Bundler — an infrastructure operator that submits transactions to the network. The top-level to address is EntryPoint — a shared contract that coordinates smart-wallet execution. Gas is paid through a Paymaster — a separate entity sponsoring the transaction fee. Inside the bundle are UserOperations from several unrelated smart accounts. One customer's operation approves a token, swaps it through a DEX, and transfers the output asset to an external address. The screening system checks only the Bundler and EntryPoint — and misses the actual smart account, the swap, and the final destination entirely.

ERC-4337 does not hide blockchain activity. But it changes where the meaningful AML data sits.

In the ERC-4337 model, a UserOperation is not a normal Ethereum transaction. It is a higher-layer pseudo-transaction object. Bundlers collect one or more UserOperations and submit them to EntryPoint in a single blockchain transaction. The UserOperation.sender field identifies the smart account — the programmable wallet that holds the customer's assets and executes their instructions. The callData field describes what the smart account should do. A Paymaster can sponsor gas. A Factory may deploy the account during the same flow. One operation may execute multiple calls. The smart account determines its own signature and validation logic — there is no requirement for a standard EOA private-key signature.

This article explains which address represents which role in an ERC-4337 transaction, what a compliance team should actually screen, how to reconstruct batched and sponsored operations, what data an ERC-4337-aware KYT system must retain, and which alerts create noise when infrastructure and customer activity are confused. For a broader overview of how blockchain addresses are attributed to wallets and entities, see our article on how blockchain addresses are attributed to wallets and entities.

One User Action Can Contain Six Different On-Chain Roles

1. Smart Account / UserOperation Sender. This is the account on behalf of which the UserOperation is executed. It can hold assets, approve tokens, call contracts, send native assets, execute several calls, and use custom validation rules. For AML purposes, this is the primary address that needs to be linked to a customer or case. A smart account should not be assumed to have one private-key owner — validation may use passkeys, multisig, recovery logic, modules, or other custom schemes. ERC-4337 deliberately leaves signature interpretation to the account implementation.

2. EntryPoint. A shared contract that validates UserOperations, calls smart accounts, coordinates Paymasters, executes bundled operations, and settles gas. EntryPoint is infrastructure. Interaction with it does not mean all users are counterparties of one another.

3. Bundler. The Bundler receives UserOperations, simulates them, groups them into a bundle, sends the ordinary blockchain transaction to EntryPoint, and pays the top-level gas before reimbursement. Therefore the top-level transaction from may identify the Bundler — not the customer or smart account.

4. Paymaster. The Paymaster may sponsor gas. It can be a wallet provider, an application, a merchant, a promotional service, a token-based gas service, or another sponsoring entity. Paymaster involvement does not, by itself, show who owns the transferred assets or who receives them.

5. Factory. The Factory may deploy a new smart account during its first UserOperation. The account address may be calculated before deployment, and code may only appear during execution. A compliance system must not classify an undeployed sender as invalid or unrelated solely because there was no contract code before the transaction. ERC-4337 supports smart-account creation through Factory and deterministic deployment data included in the UserOperation.

6. Execution Targets. These are the actual recipients, token contracts, DEX routers, bridges, merchants, protocols, treasury contracts, or other smart accounts. They determine what economically happened after validation.

Additional roles that may appear — though they should not dominate the analysis — include Aggregators (which can validate signatures across multiple UserOperations), validator modules (which determine whether an operation is authorized), executor modules (which may execute actions on behalf of modular smart accounts), hooks (which may perform pre- or post-execution checks), and session keys (which may have limited permissions, targets, or validity periods). These features change authorization analysis, but the article's focus remains on transaction screening, not wallet architecture.

Three Assumptions from Traditional Transaction Screening No Longer Hold

1. "Transaction From" identifies the customer. In ERC-4337, the top-level transaction may show the Bundler as from, EntryPoint as to, several UserOperations inside the calldata, and several unrelated smart accounts inside one transaction. Screening only transaction.from screens infrastructure. Customer mapping should use the relevant UserOperation sender. The final flow should be reconstructed from execution calls and events. Both the bundle transaction hash and the UserOperation hash should be retained. One blockchain transaction may belong to multiple customer records. Bundler attribution is still useful — the Bundler matters when the business operates its own Bundler, when a Bundler is sanctioned or restricted, when operational abuse or censorship is investigated, or when sponsorship and infrastructure relationships require review. But it is not automatically the source of customer assets.
2. The gas payer is the source of funds. In a sponsored operation, the Paymaster covers gas, the smart account may hold no ETH, the transferred asset may be USDC, USDT, or another token, the token may have arrived from an unrelated wallet, and the Paymaster may only facilitate user experience. Four things must be separated: gas provenance, transferred-asset provenance, transaction beneficiary, and economic counterparty. Source of funds review follows the assets relevant to the business decision — not only the ETH used for execution. For more on how to verify the source of specific crypto assets, see our article on how to verify the source of specific crypto assets.
3. One transaction represents one action. One UserOperation may approve a token, swap through a DEX, bridge an asset, transfer the output, pay a fee, call several contracts, and update wallet permissions. One EntryPoint transaction may include several UserOperations from different smart accounts. Screening should distinguish the bundle, the individual UserOperation, the individual execution call, the asset transfer, the final recipient, and the protocol interaction. A single success result at the bundle or UserOperation level does not explain which internal calls succeeded, what assets moved, or which destinations received value. For more on the broader AML risks created by DeFi contract interactions, see our DeFi AML guide.

Screen the Economic Execution, Not Only the Envelope Transaction

Transaction screening should reconstruct five layers.

Layer 1 — identify the relevant UserOperation. Record the blockchain transaction hash, UserOperation hash, position in the bundle, EntryPoint version and address, smart-account sender, nonce, success or failure, and customer or case mapping. If the business does not have a direct UserOperation parser, it should confirm whether its node, indexer, or analytics provider exposes equivalent data.

Layer 2 — identify how the account was authorized. Where available and relevant, determine the account implementation, validator or signer model, whether the account is multisig or modular, whether a session or delegated key was used, authorization changes, first deployment, and recovery or upgrade events. Blockchain analysis may not reveal the real-world signer identity — authorization data should be combined with customer records where the business operates or onboards the wallet. For more on what self-hosted wallet control verification can actually prove, see our ownership verification guide.

Layer 3 — decode the actual calls. Identify the called contract, function, ETH value, token approvals, token transfers, swaps, bridge interactions, NFT movement, account-module changes, and batches and subcalls. Do not treat EntryPoint as the economic destination when it only routes execution.

Layer 4 — follow the assets. For each material asset, identify the source balance, token contract, amount, map transfer events, identify recipients, account for fees, distinguish approvals from movement, and continue tracing after swaps or bridges where required. For native assets, internal call traces may be necessary. For tokens, event logs may be more informative than top-level transaction fields.

Layer 5 — apply role-specific risk. Assess separately: the smart account (wallet history, sanctions, fraud or exploit exposure, customer relationship, behavioral risk); the execution target (recipient or protocol attribution, sanctions status, smart-contract role, direct and indirect exposure); the Paymaster (known sponsor, service relationship, sanctions or illicit attribution, unusual sponsorship pattern, customer-network concentration); factory and modules (known wallet implementation, malicious or compromised deployment infrastructure, upgrade or module risk, repeated use across linked accounts); and the bundler (infrastructure attribution, operational relationship, sanctions or service risk where relevant, shared-use context).

Address and transaction screening are only part of the workflow — the integration layer must first extract the relevant smart account, transfers, and counterparties from the ERC-4337 execution. AMLBot's crypto wallet and transaction risk screening supports address- and transaction-level checks, but the business must ensure that the correct addresses are extracted from the UserOperation before screening is applied. Where execution targets include DEXs, bridges, or external DeFi protocols requiring relationship-level assessment, see our article on AML due diligence for smart contracts and protocols.

Four Smart-Wallet Scenarios That Need Different AML Interpretation

1. Sponsored stablecoin payment. A customer smart account holds USDC. A merchant or wallet-provider Paymaster pays gas. A Bundler submits the operation. The smart account transfers USDC to a merchant. Correct interpretation: review the customer smart account, USDC transaction history, merchant destination, amount and purpose, and Paymaster as sponsor. Do not conclude that the Paymaster supplied the USDC, the Bundler paid the merchant, or EntryPoint is the transaction counterparty. Possible alerts: one Paymaster sponsors thousands of unrelated users (expected infrastructure); one smart account receives fraud-linked USDC and immediately makes sponsored payments (customer-level risk); one Paymaster selectively sponsors linked high-risk smart accounts (possible network-level signal).
2. Batched approval, swap, and withdrawal. One UserOperation approves a token, swaps through a DEX router, and sends the output asset to an external address. Correct interpretation: capture the input asset, approval target, DEX and pools, output asset, actual output amount, final address, complete call sequence, and direct and indirect risk exposure. Do not make a final decision based only on the router address, the first called contract, the top-level transaction amount, or the input asset. Possible alerts: output sent to a sanctioned address; swap routes through a high-risk protocol; amount and destination do not match customer purpose; same batch changes wallet permissions before transferring funds.
3. First transaction from a counterfactual smart account. The smart-account address is known in advance, the account contract is not yet deployed, assets may already be associated with the address, the first UserOperation contains Factory data, and the Factory deploys the account during execution. Correct interpretation: capture the predicted sender, Factory, initialization data, deployed account implementation, first validator or owner configuration where available, pre-existing asset history, and first execution targets. Do not automatically treat no code before execution as an invalid wallet, the Factory as the asset owner, deployment and transfer as unrelated events, or a newly deployed account as having no history. Possible alerts: same factory is legitimate and used by millions of accounts (shared infrastructure); unusual custom factory deploys many accounts receiving funds from one fraud cluster; first operation immediately transfers pre-funded assets to a high-risk recipient; wallet implementation differs from expected product configuration.
4. Session key or delegated execution. The primary wallet owner grants a limited permission. A session key can call a specified contract or spend within a limit. An automated service or application initiates the operation. The main owner does not sign every action. Correct interpretation: distinguish the smart account, the principal customer, the delegated key or module, permitted targets and limits, actual execution, and the service initiating the action. Possible alerts: delegated key exceeds expected limits; new executor module installed before high-risk transfers; session permission remains active longer than expected; activity continues after the customer relationship or authority ends; many customer accounts use the same delegated execution service.

Build an ERC-4337-Aware KYT Record and Alert Model

1. Minimum Data Record. For each relevant smart-wallet operation, retain four categories of data.
2. Blockchain Envelope: network, chain ID, blockchain transaction hash, block, timestamp, top-level sender, EntryPoint, and transaction success.
3. UserOperation: UserOperation hash, smart-account sender, bundle position, nonce, Factory, Paymaster, Aggregator where relevant, UserOperation success, and deployment status.
4. Economic Execution: calls, function types, token contracts, source assets, output assets, amounts, recipients, swaps, bridges, fees, internal transfers, and approvals.
5. Compliance Context: customer ID, wallet relationship, KYC/KYB record, transaction purpose, source-of-funds case, risk results, alerts, reviewer, decision, and limitations.

6. Alerts that Matter. Useful alerts may include a high-risk smart account, a high-risk final recipient, a sanctioned target inside a batch, token output sent to an unexpected address, a newly deployed account funded by a risky source, an unusual Factory or module, a Paymaster sponsoring linked high-risk accounts, repeated account creation followed by rapid dispersal, a permission or executor change before a material transfer, a customer smart account suddenly using unrelated Paymaster infrastructure, batch behavior inconsistent with the customer profile, a failed UserOperation followed by successful modified execution, or cross-chain continuation after a smart-wallet call.
7. Avoid Noisy Alerts. Do not create automatic high-risk alerts merely because EntryPoint appears repeatedly, a Bundler interacts with many users, a known Paymaster sponsors large volume, an account is newly deployed, a transaction contains several calls, a smart wallet uses passkeys or multisig, the gas payer differs from the asset sender, or a UserOperation has no ordinary EOA signature. Bundler simulation and ERC-7562 validation rules help ensure that UserOperations can execute safely and do not abuse the ERC-4337 mempool — they are operational and security controls, not AML or sanctions decisions.
8. Continuous Monitoring Must Follow the Smart Account. Place on monitoring: the customer smart account, relevant linked smart accounts, material recipients, Paymaster or Factory only where a business relationship or risk justifies it, new modules or upgrade events where available, and transaction behavior over time. Risk may change when the account receives new funds, sanctions or entity attribution changes, validator or executor configuration changes, a session key is added, the account upgrades, destination patterns change, or the smart account begins using new protocols or chains.

Conclusion

A customer action may begin as a UserOperation rather than an ordinary transaction. A Bundler may appear as the blockchain transaction sender. EntryPoint is execution infrastructure. A Paymaster may sponsor gas. A Factory may create the smart account. One operation may contain several economic actions. Custom validation may replace the familiar EOA-signature model. None of this removes the need to identify the customer, the assets, the counterparties, and the risk.

The main AML questions remain the same: who is the customer, which smart account is connected with them, what assets moved, where they came from, where they went, which protocols and counterparties were involved, whether the behavior matches the customer and product, and what limitations remain in the analysis.

In ERC-4337, the visible blockchain transaction is the delivery envelope. Effective transaction screening has to open that envelope, isolate the relevant UserOperation, and follow the smart account's actual execution and asset flow.

FAQ