Smart Contract AML Screening: How to Assess DEXs, Bridges, and DeFi Protocols

A crypto business plans to add DEX routing to its product. The protocol is well known — it has a website, multiple security audits, substantial TVL, and a recognizable brand. The compliance team screens the protocol's main contract address and finds no sanctions match. The integration proceeds. Six months later, a customer deposit routed through the protocol triggers a compliance alert. The monitoring system identifies that the transaction passed through a liquidity pool whose address was flagged — not for the pool itself, but because a separate router contract in the same protocol had received funds from an address designated by OFAC 2 weeks earlier. The compliance team discovers that the protocol's actual infrastructure includes a router, a factory, dozens of dynamically created pool contracts, a proxy with an upgradeable implementation, a treasury, a fee collector, and bridge gateways on three additional chains — none of which were part of the original review.

A protocol is not one address. And a clean code audit is not an AML approval.

Smart contract AML Due Diligence must answer four different questions. First, what protocol or arrangement is the business interacting with? Second, which contracts and entities actually participate in the flow? Third, what AML, sanctions, and financial-crime risk does this infrastructure create? Fourth, how will risk be monitored after integration?

The FATF distinguishes between underlying smart-contract code and the broader DeFi arrangement — which includes governance structures, persons with control or sufficient influence, and operational components. For VASPs interacting with DeFi, the FATF recommends conducting a product risk assessment and applying proportionate risk-mitigation measures. For a broader overview of how DeFi creates AML exposure for crypto businesses, see our article on broader AML risks created by DeFi activity.

What Smart Contract AML Screening Is — and What It Is Not

AML Screening vs. Smart Contract Security Audit

A security audit evaluates code vulnerabilities, access-control errors, reentrancy, oracle risks, upgrade logic, token approvals, potential exploit paths, and whether deployed code matches the reviewed version. Smart contract AML screening evaluates protocol and contract attribution, sanctions designation, links to sanctioned entities or restricted jurisdictions, exploit or laundering exposure, source and destination of funds, protocol usage patterns, governance and actual control, embedded AML safeguards, ability to cooperate with regulated businesses and authorities, and ongoing changes in risk.

A technically secure protocol can have unacceptable sanctions or laundering exposure. A protocol with a clean AML history can contain technical vulnerabilities. Both reviews may influence the business decision, but they do not replace each other. The FATF's 2026 Guidance also treats cybersecurity audits and ongoing monitoring of suspicious trends as complementary rather than substitutable controls.

Contract Address vs. Protocol vs. DeFi Arrangement

A contract address is a specific deployed code endpoint on a given blockchain. A protocol is a set of smart contracts and rules performing a function — swap, lending, bridging, liquidity provision, staking, or asset management. A DeFi arrangement is the broader operational context: smart contracts, developers, governance, front end, admin or upgrade controls, foundations or legal entities, fee recipients, liquidity providers, service providers, and persons with control or sufficient influence. One protocol may have dozens or hundreds of contracts. One contract may be a proxy, router, factory, pool, or implementation. A protocol may be deployed on multiple networks. The marketing brand does not always match the technical contract set. Screening only the homepage URL or the token contract is not protocol Due Diligence.

Two Different Questions Smart Contract Screening Must Answer

– Should the business integrate with this protocol? This question arises when the business plans to add DEX or aggregator routing, use a bridge for customer transfers, direct treasury or customer funds into a DeFi protocol, add staking, lending, or yield functionality, support a token whose issuance depends on protocol contracts, work with a DeFi platform as an institutional counterparty, or route orders or liquidity through external smart contracts. The review must cover full contract architecture, governance, controllers, legal and regulatory status, AML safeguards, sanctions and adverse information, incident history, expected transaction flow, operational and escalation contacts, and ongoing monitoring arrangements. This is relationship-level due diligence.

– What does this transaction's contract interaction mean? This question arises when a customer deposit passed through a DEX, funds arrived from a bridge, a wallet interacted with a liquidity pool, a withdrawal goes to a protocol contract, the monitoring system detected protocol exposure, or an analyst is reviewing source of funds. The review evaluates the function of the specific interaction, direction of funds, amount, timing, protocol role, direct or indirect exposure, assets before and after the interaction, customer explanation, and the wider transaction path. This is transaction-level risk review.

Approving a protocol for integration does not make every user transaction through it low-risk. Finding one risky transaction does not automatically make the entire protocol illicit.

Map the Full Protocol Surface Before Running Checks

Due Diligence begins not with a risk score, but with identifying what needs to be checked.

1. Canonical contracts and functional components. The business should build a verified inventory: primary protocol contracts, routers, factory contracts, liquidity pools, vaults, staking contracts, escrow contracts, fee collectors, treasury addresses, wrapped-token contracts, bridge gateways, relayer or settlement contracts, emergency or pause modules, and frontend-controlled addresses where relevant. For each component, record the blockchain, address, function, deployment date, official source confirmation, relationship with other contracts, and whether customer funds can pass through or remain inside it. Sources of confirmation include official protocol documentation, verified block-explorer pages, official repositories, governance proposals, deployment records, and direct confirmation from the protocol team.
2. Once the inventory is assembled, identified contract, treasury, and operational addresses should be screened for risk exposure. AMLBot's crypto wallet and address screening supports on-demand checks across major blockchains — though a single address check does not automatically assemble the full contract inventory or determine governance structure.
3. Proxies, implementations, and upgrade paths. Proxy architecture matters for AML due diligence because the user interacts with a proxy address while the actual logic lives in a separate implementation contract. The implementation can be changed. Upgrade authority may belong to a multisig, governance mechanism, or admin key. A new implementation address may not exist at the time of the initial review. Fees or funds may be redirected to different contracts after an upgrade. The review should establish whether the contract is upgradeable, where the implementation is, who can change it, whether a timelock exists, how upgrade notices are published, which contracts can be replaced, and whether a compliance re-review is required after each upgrade.
4. Multi-chain deployments and external dependencies. The review should confirm which chains the protocol operates on, whether governance and functionality are identical on each chain, whether separate contract sets exist, whether bridges or messaging protocols are used, where locked assets are stored, who issues wrapped or synthetic assets, which validators, relayers, or oracles participate, whether third-party DEXs, routers, or liquidity sources are involved, and where transaction visibility may break. Approval of an Ethereum deployment does not automatically extend to deployments on Arbitrum, Solana, BNB Chain, or any other network. For more on how cross-chain fund flows are reconstructed across bridge boundaries, see our article on how cross-chain fund flows are reconstructed.

Build the Protocol's AML Due Diligence Profile

1. Sanctions and restricted-party exposure. Check direct sanctions designation of contract addresses, whether the protocol, operator, foundation, developers, or controllers appear on sanctions lists, treasury and fee-recipient addresses, designated front-end or service components, links to sanctioned jurisdictions, direct and indirect wallet exposure, previous regulatory or enforcement notices, and the protocol's ability to restrict access where required. Sanctions may apply to a specific contract, to associated persons or entities, or to the protocol's brand or service — and each creates different consequences. Not every sanctions match requires identical response. The review should confirm the exact address, chain, designation scope, and applicable jurisdiction.
2. Governance, control, and operational structure. Determine who has the ability to change protocol parameters, deploy new contracts, upgrade implementations, modify fees, pause operations, approve new assets or pools, change routing logic, interact with treasury, or influence decision-making. The sources of control may include admin keys, multisig, governance token voting, foundation, legal entity, development team, front-end operator, or external protocol dependency. These overlap but are not identical — technical automation, governance power, operational control, and legal responsibility are separate dimensions. Do not accept a marketing claim of "fully decentralized" without analyzing actual control. The FATF notes that a DeFi arrangement may fall within standards if an identifiable person has control or sufficient influence, considering the ability to change protocol parameters, admin functions, front-end control, and other practical powers.
3. AML controls and cooperation capability. Assess whether the protocol or its access layer has wallet screening, sanctions screening, blocked-address controls, restricted front-end access, geolocation controls, embedded KYC/CDD where applicable, permissioned pools or verified-user segments, transaction monitoring, risk-based transaction rejection, incident response processes, compliance or law-enforcement contacts, documented governance structure, and a process for responding to lawful requests. The absence of embedded KYC does not automatically make a protocol unacceptable. The presence of front-end screening does not mean the underlying contracts are inaccessible directly. Controls must be evaluated with consideration of the architecture and the actual business interaction. The regulated business retains its own AML obligations regardless.
4. Security and incident history as an AML input. Without conducting a technical audit, check for previous hacks and exploits, compromised admin keys, oracle manipulation, unauthorized upgrades, bridge validator compromise, emergency pauses, stolen-fund flows through the protocol, response speed, whether affected contracts were replaced, whether stolen funds remain linked to current infrastructure, and communication and cooperation during incidents. This is AML-relevant because an exploit can instantly transform previously ordinary contracts into a source of stolen funds, compromised admin infrastructure can redirect fund destinations, old exploit clusters may continue to affect risk scores, and incident response demonstrates operational maturity and cooperation capability. For an example of how exploit-linked funds move through DeFi infrastructure, see our investigation of the $13.5M Aperture Finance / SwapNet exploit.

How the Risk Assessment Changes by Protocol Type

DEXs and DEX aggregators. For a DEX, check router and factory contracts, liquidity pool creation model, permissionless token listing, supported assets, route construction, use of external liquidity sources, fee-recipient addresses, direct interaction versus aggregator routing, sanctioned or high-risk pools, ability to restrict front-end access, whether a single swap routes through several protocols, and whether outputs can be linked to user inputs. For an aggregator, additionally consider that one transaction may be divided across several DEXs, the protocol set may change dynamically, an approved aggregator may route through an unassessed venue, and routing policy and venue allowlists may be more important than any single router address. DEX use is not automatically suspicious — risk is determined by source, destination, route, assets, timing, exposure, and behavior.

Cross-chain bridges. For a bridge, check source- and destination-chain contracts, lock/mint/burn/release mechanism, validators, relayers, oracles, or messaging layer, wrapped-token issuer, custody or liquidity model, supported chains, sanctioned or unsupported destinations, route correlation capability, emergency pause, admin and upgrade authority, exploit history, ability to identify or reconstruct both sides of a transfer, and whether funds emerge at fresh addresses without prior history. A contract on the destination chain cannot be assessed in isolation from the source-side deposit.

Lending, liquidity, vault, and staking protocols. Evaluate deposit and withdrawal contracts, collateral and borrowed assets, receipt or LP tokens, vault strategies, external protocols used by the strategy, liquidation flows, reward and fee addresses, commingling level, whether withdrawal assets can differ from deposited assets, whether the vault can move funds across protocols or chains, governance ability to alter strategy, and source-of-funds limitations after pool interaction. A pool interaction may combine funds from many users — LP or vault withdrawal does not return literally the same tokens that were deposited. Protocol exposure requires context, not mechanical contamination logic.

How to Interpret Contract Exposure Without Creating False Positives

1. Infrastructure exposure vs. fund provenance. Five different conclusions must be distinguished: a wallet interacted with a protocol contract; specific funds came through the protocol; the protocol processed funds from a high-risk actor; the reviewed funds are linked to that actor; and the protocol itself is designated or controlled by a restricted person. A contract may serve thousands of unrelated users. A high-risk actor may have used the same router. This does not mean every subsequent user received funds from that actor. However, direct pool exit, timing, amounts, and linked events can create stronger exposure. The analyst must understand the function of the transaction, not only the category of the counterparty. For more on why smart contract exposure requires matching on-chain evidence with customer context, see our article on why smart contract exposure requires source-of-funds context.
2. Direct, indirect, and protocol-level risk. Direct transaction exposure means funds were sent to or received from a flagged contract or address. Indirect exposure means the connection passes through intermediate addresses or contracts. Protocol-level risk relates to governance, designation, functionality, incident history, or broader protocol usage — not a single fund path. Assessment should consider hop distance, function of the intermediate contract, amount and percentage, timing, direction, frequency, asset transformations, user behavior, whether the interaction was optional or infrastructure-driven, and confidence in entity attribution.
3. Routers, pools, and aggregators distort simple attribution. A router may pass funds through several pools. An aggregator may split a transaction. A factory creates contracts but does not necessarily hold user funds. A pool commingles liquidity. A vault may route assets through external strategies. A bridge gateway may aggregate users. A fee contract receives a small portion of activity but is not the destination of the main sum. Screening responses should, where possible, show entity attribution, contract type, transaction direction, source and destination exposure, relevant volume, hop distance, named protocol relationships, and confidence limitations.

A Pre-Integration AML Due Diligence Workflow

Step 1 — Define the intended relationship. Document what the business will actually do through this protocol: which customers or accounts get access, which assets are involved, expected volumes, supported chains, whether customer funds enter smart contracts, whether the business controls routing, whether the protocol acts as counterparty, infrastructure, or liquidity source, what failure or restriction would do to customer funds, and where the AML control points are.

Step 2 — Verify the protocol and contract inventory. Collect legal and operating names, official website and documentation, relevant entities, governance structure, contact information, all material contract addresses, supported chains, proxy and implementation relationships, treasuries and fee recipients, bridge and external dependencies, and the latest contract versions. Document the source of each address.

Step 3 — Run AML and sanctions screening. Perform address screening, sanctions screening, entity attribution, source and destination exposure review, historical activity review, exploit-linked exposure review, cross-chain review, adverse information and enforcement review, and treasury and controller checks. Do not rely on a one-time screenshot risk score — save the detailed result and timestamp.

Step 4 — Assess governance, controls, and cooperation. Obtain or verify legal and regulatory status, persons with control or sufficient influence, admin and upgrade rights, front-end controls, sanctions and AML framework, security audits, incident response, law-enforcement contact, process for contract changes, handling of blocked or high-risk activity, information-sharing capability, and previous partner or regulator issues.

Step 5 — Test the expected transaction flow. Before launch, model or test the customer entry point, smart contracts called, internal routes, fee destinations, asset conversions, bridge source and destination, wallet addresses visible to monitoring, where screening occurs, when a transaction can be held or rejected, which data is saved, what creates an alert, and what happens if contracts change. Use realistic flows, not only architecture diagrams. For businesses embedding screening checks into swap, deposit, withdrawal, or routing workflows, AMLBot's AML API integration supports programmatic risk assessment at the transaction level. For broader guidance on where API checks belong in crypto product flows, see our article on where AML API checks belong in crypto product workflows.

Step 6 — Make and document the decision. Possible outcomes include approve under standard monitoring, approve with restricted chains or functions, approve with transaction limits, approve only selected contracts or pools, require enhanced monitoring, require periodic re-review, require protocol notification before upgrades, delay pending additional information, reject integration, or escalate to legal or senior compliance. Document the scope of the approved relationship, addresses reviewed, sources used, risks identified, mitigating controls, responsible owner, monitoring requirements, review date, and conditions that invalidate approval.

Ongoing Monitoring After a Protocol Is Approved

1. Contract and governance changes that should trigger re-review include new contract deployment, proxy upgrade, new implementation, additional chain, new bridge or messaging provider, changes in multisig signers, change of admin keys, governance concentration, new fee recipient, new vault strategy, new routing venue, front-end operator change, and legal entity or jurisdiction change. The business should determine which changes update records automatically, which require targeted re-screening, which require full re-approval, and which temporarily restrict functionality.
2. Risk intelligence and incident changes that require re-screening include new sanctions designation, newly attributed illicit cluster, hack or exploit, compromised key, emergency pause, stablecoin freeze, regulator warning, law-enforcement request, unusual increase in high-risk flows, and the protocol being used in an emerging laundering typology.
3. Actual transaction behavior should be compared with the approved use case: expected versus actual chains, expected versus actual contracts, transaction volume, customer types, asset mix, bridge routes, repeated high-risk pool use, rapid routing through multiple protocols, unusual source or destination exposure, alerts by customer, contract, and protocol, and concentration around a particular route or address.

What to Do When a Contract or Protocol Is Flagged

A flagged contract requires confirmation, not automatic blocking. First, confirm the exact contract address, blockchain, protocol attribution, contract function, whether the alert involves a direct designation or indirect exposure, whether the alert relates to the protocol, to user funds, or to an associated entity, and the confidence of attribution. Second, identify whether this is an approved protocol, whether the contract is used in business infrastructure, whether it is a customer transaction, whether the address is official or spoofed, whether it is a deprecated contract, and whether it is in the approved inventory. Third, reconstruct the transaction context — direction of funds, source and destination, amount, timing, internal contract calls, pools or routers involved, cross-chain events, connected customer, and broader transaction path. Fourth, review the protocol-level context — governance and controller changes, new incidents, sanctions events, new exploit attribution, contract upgrades, official protocol communication, and effect on other customers or transactions. Fifth, apply proportionate interim controls — hold the affected transaction, disable a specific route, restrict one contract or chain, require manual approval, pause new protocol interactions, request additional information, or escalate. Sixth, document the original screening result, attribution data, transaction path, protocol inventory, supporting sources, reviewer reasoning, action taken, final outcome, and follow-up date.

What the Protocol Due Diligence File Should Contain

The due diligence file should include: protocol and entity names, intended business use, legal and regulatory status, governance and control assessment, decentralization claim and supporting evidence, official contacts, complete contract inventory, chains and versions, proxy and implementation relationships, treasuries and fee recipients, third-party protocols and bridges, sanctions and adverse-information results, wallet and transaction screening results, exploit and incident history, AML and security controls, expected transaction-flow diagram, risk assessment, mitigating controls, approval decision, approved and excluded contracts, monitoring rules, escalation contacts, review triggers, next review date, and version history.

The file must make clear what was approved. Writing "Protocol X — approved" is insufficient if the review covered only one Ethereum contract and the product later routed funds through new contracts on several chains.

Conclusion

Smart contract security audit and AML screening answer different questions. Protocol due diligence must cover contracts, governance, controllers, transaction flows, and external dependencies. DEX, bridge, and liquidity protocol create different types of exposure. Interaction with neutral infrastructure is not automatic illicit activity. A one-time address check is insufficient for an ongoing relationship. Approval should be limited to specific chains, contracts, functions, and controls. Contract upgrades, sanctions designations, incidents, and attribution changes should trigger re-review. The correct compliance question is not simply whether one contract address is low-risk. It is whether the full protocol relationship is understood, monitored, and compatible with the business's AML framework.