DeFi, Smart Contracts and Decentralised Crime

Decentralised finance is difficult for a bank because decentralised can describe very different arrangements. One protocol may consist mainly of smart contracts that users interact with from self-hosted wallets. Another may have a development company, administrators, governance token holders, fee recipients, front-end operators and emergency controls. A third may sit between those models. For financial-crime work, the marketing label is less important than what the arrangement actually does, who can influence it, what value moves through it and which parties the bank can identify.

A practical definition is: DeFi uses blockchain-based smart contracts to perform financial functions such as exchange, lending, borrowing, liquidity provision or asset transfer, often without a conventional intermediary controlling every transaction. That does not mean every DeFi arrangement is legally unregulated, technically uncontrollable or anonymous. It also does not make every user high risk.

FATF’s 21 July 2026 targeted report on DeFi emphasises a functional, risk-based analysis, including whether people or entities exercise control or sufficient influence over an arrangement. FATF’s seventh targeted update, published on 16 July 2026, also highlights continuing risks around DeFi, stablecoins, unhosted-wallet activity, offshore VASPs and virtual-asset-enabled fraud. Those are global-standard observations. Whether a particular operator, service or person is legally regulated still depends on national implementation and the facts.

For a bank, DeFi matters even if the bank offers no crypto custody or trading. Customers can fund exchanges from bank accounts, withdraw digital assets to self-hosted wallets, use decentralised exchanges or lending protocols, bridge value to another chain and later return funds through an exchange. Fraud victims can be persuaded to buy digital assets and interact with malicious contracts. Criminal proceeds can also move through these same infrastructures. The bank may see only the fiat entry or exit, while an investigation has to reconstruct what happened in between.

The control objective is therefore not “block DeFi.” It is to distinguish understandable activity from activity whose source, destination, ownership, purpose, network relationships or legal context create concern.

DeFi activity creates a chain of value movements from bank funding through wallets, protocols and possible off-ramps, with different evidence available at each point.

The core mental model: actor, contract, protocol and value path

A useful DeFi analysis keeps four objects separate.

The actor is the person or entity making a decision: the bank customer, developer, governance participant, liquidity provider, exchange customer, fraudster, scam victim or another participant. The bank may know some actors through KYC. Others may initially be represented only by blockchain addresses or service attributions.

The smart contract is software deployed to a blockchain address. It can receive inputs, execute predefined logic, transfer tokens, call other contracts or update state. A smart contract does not have intentions in the human sense. Investigators should ask who invoked it, what function was called, what assets moved and who can change or administer relevant code or parameters.

The protocol is the broader arrangement built from one or more contracts, interfaces, developers, governance structures and economic incentives. A decentralised exchange may contain routers, pools, factories, governance components and a website or application. Looking only at one contract address can therefore miss the service context.

The value path is the economic journey. A customer might convert fiat to a stablecoin through an exchange, withdraw to a wallet, swap the stablecoin for another token through a DEX, bridge it to another chain, deposit it into a lending protocol and later return value to an exchange. Each step creates evidence, but the meaning depends on the customer and the risk question.

This model prevents a common error: attributing every transaction touching a protocol to the protocol itself. A pool may contain assets from thousands of unrelated users. A router may forward swaps for many users. A bridge may pool assets while corresponding value is issued elsewhere. Shared infrastructure needs functional interpretation before a risk conclusion is made.

DeFi is not the same as anonymity

Public blockchains are often pseudonymous rather than fully anonymous. Addresses do not normally display a legal name, but transaction history can be visible. That visibility can reveal relationships that would be difficult to see in cash. At the same time, the ledger does not automatically reveal who controls every address, and privacy techniques, cross-chain activity and service aggregation can complicate attribution.

A user may connect a self-hosted wallet directly to a protocol without a conventional account-opening process. That does not make the transaction invisible. Wallet addresses, contract interactions, token transfers and subsequent movements may remain observable.

The bank’s job is to combine on-chain and off-chain facts. KYC records, customer statements, source-of-funds evidence, exchange records, device information, bank account history, Travel Rule data from regulated counterparties and lawful external information can turn an apparently anonymous path into a much clearer evidential picture.

What investigators need to understand about smart contracts

Financial-crime investigators do not need to become software auditors, but they need enough technical literacy to interpret evidence correctly.

A smart-contract transaction can contain a function call rather than a simple payment. The user may approve a token for a router, execute a swap, provide liquidity, borrow against collateral, repay a loan, claim rewards or interact with a bridge. One top-level transaction can trigger several internal calls and token-transfer events. Recording only the destination contract address may miss the economic action.

Token approvals are a good example. An approval can allow a contract to transfer tokens later, while the approval itself may move no value. If an investigator records the approval as a payment, the narrative is wrong. Conversely, a later transfer executed by a contract may depend on a prior approval. Systems should preserve both transaction-level and event-level information where relevant.

Upgradeable contracts also matter. Some arrangements use proxy patterns in which the visible address stays the same while underlying logic changes. Administrative keys, multisignature arrangements or governance votes may control upgrades, pauses or fee settings. Those facts are relevant both to operational risk and to the functional question of control or influence.

Technical evidence supports legal analysis; it does not replace it. The legal status of a service depends on the applicable framework and approved interpretation.

Decentralised exchanges and liquidity pools

A decentralised exchange allows users to exchange digital assets through smart contracts rather than placing an order with a conventional centralised exchange operator. Many DEXs use automated market-maker models in which liquidity providers supply assets to pools and users trade against them according to protocol rules.

For financial-crime monitoring, a swap contains several layers. The wallet initiating the swap is an actor. The router or pool is infrastructure. The asset received may later move elsewhere. A system that labels the pool as the customer’s beneficial counterparty can obscure who actually benefited from the activity.

Liquidity provision adds complexity. A user can deposit assets into a common pool and later withdraw a proportional claim. The withdrawn assets may not be the same blockchain units originally supplied. Pooling can therefore weaken naive source tracing. The investigator should follow the customer’s position: deposit, representation of the liquidity position, material changes, fees or rewards where relevant and withdrawal.

Criminals can use DEXs to convert stolen or illicit assets without opening a conventional account at the protocol. Legitimate traders and investors also use them. Stronger indicators come from the surrounding pattern: direct proximity to theft or scam proceeds, rapid conversion and chain hopping, interaction with sanctioned or illicit services, implausible customer explanations, or urgent movement toward an off-ramp.

Lending, borrowing and collateral protocols

DeFi lending protocols allow users to supply assets, earn returns, borrow against collateral and repay or liquidate positions through smart contracts. A large wallet inflow after closing a lending position may represent returned collateral rather than third-party income. A liquidation may be an automatic protocol outcome rather than suspicious activity.

At the same time, lending can be part of a laundering chain. Illicit assets may be supplied as collateral, borrowed against, converted, bridged or later withdrawn. Source-of-funds analysis should therefore look through the immediate transaction to the collateral and earlier funding where the risk question requires it.

The control principle is consistent: understand the economic function before assigning meaning to the flow.

Cross-chain bridges

Bridges connect value across blockchain networks. One design may lock an asset on one chain and cause corresponding value to be issued on another. Another may use liquidity pools or messaging systems. The investigative consequence is the same: the value path can cross a point where a single-chain trace stops.

A bank needs a bridge correlation record containing source chain, source transaction, source asset and amount, bridge, destination chain, destination asset, destination wallet where observable, time relationship and correlation confidence. Vendor tools may automate the linkage, but the case should preserve the underlying identifiers and the reason for the correlation.

Bridges can be used legitimately for access to different applications or liquidity. They can also be attractive in laundering because they fragment the trace and move assets into ecosystems with different analytics coverage. The presence of a bridge is therefore context, not proof.

Simple “number of hops” rules are weak. One bridge can materially change investigative context, while several harmless contract calls can create many technical hops without changing beneficial ownership. Function matters more than hop count.

Protocol governance and the meaning of decentralisation

FATF’s virtual-asset guidance and 2026 DeFi work encourage a functional analysis rather than acceptance of a self-description. For a bank assessing a customer or counterparty, useful governance evidence can include who developed the protocol, who owns the front end, who controls administrative keys, who can pause or upgrade contracts, who sets fees, who controls treasury assets and who receives material revenues.

No single factor creates a universal legal answer. Governance tokens also require care. Holding a small number of tokens does not automatically mean a user controls a protocol. Concentrated voting power, delegated votes, foundations, companies and informal influence can all matter.

Where legal classification is material, investigators should preserve the facts and route the question to the appropriate legal or compliance owner rather than make an unsupported legal conclusion from technical indicators.

How decentralised-finance crime appears

“Decentralised crime” is not a separate predicate offence. It is a convenient description for criminal activity that uses smart contracts or decentralised protocols as part of the movement, conversion, concealment or exploitation of value.

The underlying offence may be fraud, theft, ransomware, sanctions evasion, corruption, trafficking or another crime. DeFi is part of the financial trail.

Common patterns include rapid conversion after theft or fraud, chain hopping, attempts to use shared pools to complicate tracing, movement of exploit proceeds, sanctions exposure and scam victim activity. Each needs context.

If stolen assets are swapped through a DEX minutes after a theft, the important evidence is the link to the theft, timing, conversion sequence and onward movement. If a customer merely used a pool that also has unrelated high-risk users, shared infrastructure weakens direct counterparty inference. If a scam victim sent assets to a malicious contract, fraud teams may need to protect the customer while AML teams analyse the receiving network.

A blockchain analytics risk label is not itself a legal designation, and protocol use is not itself evidence of criminal intent.

Where DeFi risk appears in the bank lifecycle

At onboarding, corporate or institutional customers may develop protocols, operate interfaces, provide analytics, manage digital-asset funds or provide liquidity professionally. The bank should understand the business model, legal entities, products, geographies, expected counterparties, regulatory status where applicable, source of capital and expected use of accounts.

At payment initiation, retail and corporate customers may make payments to exchanges or brokers that provide access to DeFi. The bank should distinguish what it knows from what it infers. A fiat payment to an exchange does not prove that the customer later used a DEX.

At off-ramping, value may return from an exchange after complex on-chain activity. If a customer claims the proceeds came from DeFi trading or yield, the bank may need wallet evidence, transaction hashes, exchange statements, accounting or tax records, or other documentation consistent with the value received.

At investigation or law-enforcement contact, new information may link a customer wallet to stolen assets, sanctioned addresses or another case. This can trigger a lookback. The lookback must distinguish what the bank knew when the historical transaction occurred from what was discovered later.

A DeFi alert should move from signal to protocol interpretation, source and destination analysis, customer context, legal scoping and a documented disposition rather than jump from a risk label directly to an adverse decision.

Risk assessment: assess the arrangement, not the buzzword

A useful DeFi risk assessment considers customer, protocol, transaction and jurisdiction together.

For the customer, examine expected activity, sophistication, business purpose, source of wealth or funds, prior virtual-asset use and whether the observed pattern fits the relationship. A professional market maker should not be assessed using the same expectations as a first-time retail customer who suddenly moves most savings into unfamiliar wallets.

For the protocol, consider function, known governance or control, regulatory touchpoints, sanctions or illicit-finance exposure, transparency and whether recognised regulated entities interact with it. Popularity is not proof of low risk, and obscurity is not proof of criminality.

For the transaction, consider asset type, value, velocity, source exposure, destination exposure, use of bridges or pools, rapid pass-through behaviour and whether the customer can explain the sequence. FATF’s March 2026 stablecoin work is relevant because stablecoins are widely used legitimately but can also be attractive to illicit actors because of liquidity and transferability.

For the jurisdiction, consider the bank’s legal entity, applicable AML/CFT and sanctions framework, whether relevant service providers are licensed or registered where required, and whether offshore services operate outside effective supervision. These factors guide control intensity; they should not produce automatic rejection without policy basis.

Detection and monitoring design

A bank cannot detect DeFi risk with one keyword rule. Mature monitoring combines conventional banking data with virtual-asset intelligence.

Banking data provides account ownership, payments, counterparties, channel, device, customer profile and communications. VASP data can provide account and transfer information. Blockchain data provides hashes, wallet addresses, contract addresses, token transfers and smart-contract events. Analytics adds labels, service categories, clusters, exploit or scam exposure and risk scores.

The monitoring layer should preserve these sources separately. A vendor classification such as “DEX,” “bridge” or “high-risk service” should not overwrite the raw address and transaction hash. Investigators need both the interpretation and the underlying evidence.

Useful scenarios can include high-risk direct provenance, rapid movement inconsistent with customer purpose, repeated bridge and swap sequences after unusual exchange funding, deposits linked to recent theft or scam proceeds, or customer claims of investment returns that cannot be reconciled with observed wallet history. Thresholds should reflect customer and product context rather than treat every smart-contract interaction equally.

A bank-grade DeFi control architecture joins banking events, blockchain and protocol data, risk enrichment, deterministic legal checks, behavioural analytics and an auditable case workflow.

Sanctions and DeFi

Sanctions require a separate decision layer because legal consequences can differ from ordinary AML suspicion. OFAC’s virtual-currency guidance is U.S.-specific. EU, UK, Australian and other frameworks have their own sanctions authorities, ownership or control tests, licensing rules and reporting expectations.

If an analytics provider identifies an address associated with a sanctioned person or service, the bank should preserve the list source, relevant identifier, query time, address, transaction path and attribution confidence. Sanctions specialists then determine the required action under the applicable legal framework. An analytics proximity score should never be converted automatically into a legal conclusion.

Smart contracts make this especially important. A designated address may have interacted with a widely used protocol that also serves many unrelated users. The fact that a contract once received funds from a designated address does not automatically make every protocol user sanctioned.

Travel Rule information and DeFi are different controls

FATF’s Travel Rule applies to transfers involving VASPs under the FATF framework as implemented locally. The EU’s Regulation 2023/1113 and EBA guidance create specific requirements for EU PSPs and CASPs, including procedures involving self-hosted addresses. Those are jurisdiction-specific legal rules.

A direct wallet-to-smart-contract interaction may not carry the same identity information that a regulated CASP-to-CASP transfer can exchange. Blockchain analytics does not substitute for required originator and beneficiary information, and missing Travel Rule data does not automatically prove criminality.

The strongest investigations often combine both. Exchange records or Travel Rule data can help identify a customer-controlled withdrawal address; blockchain tracing can then explain protocol activity; later exchange information can help close the evidential loop.

Investigation: reconstruct function, not just flow

A good DeFi investigation answers six questions.

First, what triggered the review? It may be a bank payment, blockchain alert, fraud report, sanctions match, law-enforcement request or unusual source-of-funds claim.

Second, which wallet or transaction is confidently linked to the customer? Record the evidence and confidence for that link.

Third, what did the contracts actually do? Identify swaps, deposits, withdrawals, loans, repayments, bridge transfers or other functions rather than calling everything a transfer.

Fourth, where did the assets come from and where did they go? Trace relevant sources and destinations using an appropriate time and materiality window.

Fifth, which risk indicators survive contextual review? Remove false signals caused by shared infrastructure, pooled wallets, protocol routing or outdated labels. Strengthen signals supported by direct illicit-source exposure, corroborated attribution or an implausible customer story.

Sixth, what decision follows under policy and applicable law? The outcome may be closure, enhanced monitoring, request for information, fraud protection, AML escalation, sanctions escalation, suspicious-activity reporting where legally required, relationship restriction or another controlled action.

Evidence quality and point-in-time reconstruction

DeFi investigations can change when new information arrives. An address may be attributed to an exploit months later. Governance can change. A sanctions designation can be added or removed. Analytics providers can revise labels.

The case system should preserve point-in-time evidence: transaction hashes, wallet and contract addresses, chain and asset identifiers, amounts, timestamps, analytics provider, label and confidence, query time, relevant list version, customer evidence and policy version used for the decision.

Screenshots alone are weak for important cases because they lose structured identifiers and are difficult to reprocess. Machine-readable trace data or reproducible query references should be retained where policy permits.

This protects both bank and customer. If a historical wallet is later labelled high risk, the bank can perform a new lookback without pretending the original investigator had information that did not exist at the time.

The evidential timeline for a DeFi case links fiat funding, wallet ownership, smart-contract actions, bridge correlations, off-ramp events and later intelligence without rewriting the past.

Alert, case, reporting and customer outcomes

Not every DeFi alert should become an investigation, and not every investigation should become a suspicious-activity report. Triage should remove technical noise such as a router being misclassified as the customer’s beneficial counterparty. Higher-risk cases then move into investigation with a defined question and evidence plan.

If suspicion is formed under the applicable jurisdiction’s legal standard, the case follows the relevant reporting process. Filing names, thresholds, timing and confidentiality rules differ by country, so a global chapter should teach evidence discipline without inventing one universal SAR or STR deadline.

Fraud cases require coordination. If the customer appears to be a victim of a DeFi investment scam, fraud teams may attempt recovery or protective action while AML teams assess receiving wallets and possible laundering networks. A joined case view prevents the bank from treating the same customer as a victim in one system and an unexplained high-risk actor in another without reconciliation.

Customer communication should be proportionate. A customer may genuinely say “I provided liquidity” or “I bridged the token” while a bank agent sees unfamiliar addresses. RFIs should target unresolved facts. If the issue is source of funds, ask for evidence showing acquisition and realisation. If the issue is wallet control, request approved proof appropriate to the risk. If the issue is suspected fraud, do not demand technical details a victim could not reasonably know.

Adverse decisions should be based on policy and evidence, not simply on DeFi use. A bank’s commercial risk appetite should also be distinguished from an allegation that activity is illegal.

Roles, governance and change

Business teams own the customer proposition. Financial-crime policy defines risk appetite and escalation. Sanctions teams own sanctions interpretation. Fraud teams own victim and scam controls. Technology teams provide blockchain, payment and case data. Analytics governance challenges vendor scoring. Legal teams advise where classification or jurisdiction is uncertain. Internal audit independently tests whether the control works.

DeFi also needs a rapid-change mechanism. New chains, bridges and protocols appear quickly. A bank should be able to add new service classifications, high-risk intelligence or sanctioned addresses through a controlled process without bypassing validation, testing and auditability.

Management information should go beyond alert volume. Useful measures include unsupported-chain exposure, ageing cases, false-positive drivers, alerts caused only by shared infrastructure, time to incorporate new intelligence, vendor-label disagreements, RFI response rates, cross-chain coverage gaps, customer impact and QA findings.

DeFi governance joins business ownership, financial-crime policy, sanctions and fraud specialists, analytics governance, technology and independent assurance around one traceable decision record.

Failure modes to avoid

The first failure is treating all DeFi as high risk. That creates false positives and weakens real risk detection.

The second is treating infrastructure as a person. Routers, pools and bridges need functional interpretation before counterparty conclusions are made.

The third is over-relying on vendor scores. Scores support prioritisation; they are not legal findings or complete investigations.

The fourth is losing cross-chain continuity. A trace that stops at the bridge can miss the most important part of the path.

The fifth is confusing technical exploits with laundering. The exploit explains how assets were stolen; the bank investigation focuses on provenance, movement, beneficiaries and attempts to convert or conceal proceeds.

The sixth is ignoring the customer story. Transaction graphs without business or personal context can mislead, while unsupported explanations should not close a material concern.

The seventh is failing to preserve time. Current labels, current sanctions lists and current governance should not be projected backward without evidence.

What good looks like

A strong DeFi control accepts that decentralised-finance evidence is different from conventional correspondent banking. The bank knows which customers and products create material exposure. It can link fiat activity to known VASPs and, where justified, to customer-controlled wallets. Its analytics distinguish raw facts from inferred labels. It can interpret common contract actions and follow material cross-chain movement. It separates AML suspicion from sanctions legal decisions and preserves point-in-time evidence.

Investigators understand when shared infrastructure weakens a signal and when direct illicit-source exposure strengthens it. Business analysts translate those needs into data, workflow and audit requirements. Testers challenge the control with clean, suspicious, ambiguous and failure-mode cases.

The objective is not perfect visibility. It is a defensible control that can explain what the bank knew, what it inferred, what remained uncertain, why it made a decision and how the evidence can be reconstructed later.

Operational deep dive: reading DeFi transactions without misclassifying them

The base chapter separated actor, contract, protocol and value path. This deep dive turns that model into investigation practice. The aim is not to teach smart-contract development. It is to help banking teams understand the economic action, the evidence quality and the uncertainty that remains.

Start with the economic question

A transaction hash is not a conclusion. Before opening an explorer or analytics tool, state the question in ordinary language: Did the customer swap assets? Supply liquidity? Bridge value? Is the incoming fiat credit consistent with assets previously held? Did known exploit proceeds enter the customer’s wallet?

Then read the record in layers. The top-level transaction shows initiating and destination addresses, chain, timestamp and status. Token events show which assets moved. Contract-call data shows which function was invoked. Internal calls can reveal downstream execution. Analytics may add router, pool, bridge, service or risk attributions. These layers answer different questions and should remain distinguishable in the case.

A common error is to treat the destination contract as the beneficiary. If the destination is a DEX router, the router is infrastructure. The economic action may simply be a swap in which purchased assets return to the user. A case that says “customer paid DEX X” when the customer exchanged token A for token B is misleading.

Approvals are not payments

Many token interactions require the user to grant a contract permission to move tokens. An approval changes spending authority and may move no value. Investigators should record it where it explains a later transfer but should not count it as a payment.

This distinction matters in fraud. A victim can approve a malicious contract and later lose assets without a new conventional payment instruction. Fraud teams ask whether the customer understood the permission and whether protective controls could have detected the harmful sequence. AML teams ask where the assets went, who benefited and how receiving wallets relate to other illicit activity.

A bank data model should therefore distinguish transfers, approvals, swaps, liquidity deposits and withdrawals, lending deposits, borrowing, repayment, liquidation and bridge events rather than collapse everything into crypto_transfer.

DEX routing and shared infrastructure

A user may interact directly with a pool, through a router or through an aggregator that selects routes across venues. One user action can generate several contract calls and token movements. For investigation, the relevant unit is often the economic transaction, while raw events remain available for drill-down.

Routing can also create false exposure. A pool may contain assets from wallets associated with illicit activity, but a customer using that pool did not necessarily transact directly with those actors. Risk scoring should distinguish direct exposure from commingled shared infrastructure and document how the analytics provider treats pools and routers.

Liquidity positions and source of funds

Liquidity pools complicate source-of-funds analysis because users contribute assets to a common pool and later withdraw a proportional claim. The withdrawn assets may not be the same blockchain units originally deposited.

A defensible review follows the customer’s position rather than claiming exact token identity. Record the deposit, assets and value, the representation of the liquidity position, material changes, fees or rewards where relevant, and the withdrawal. For professional customers, accounting records can corroborate wallet and protocol positions. For retail customers, the evidence can be simpler but should still support large claimed returns.

Lending positions

DeFi lending can create balances resembling deposits, collateral and debt. Investigators should determine whether the customer supplied assets, borrowed, repaid, received collateral back or was liquidated. A large wallet inflow after closing a position may be return of collateral, not third-party income.

Conversely, suspicious assets can be used as collateral and borrowed against. Source-of-funds analysis may need to look through the borrowed asset to the collateral and earlier funding. Liquidations can be automatic protocol outcomes and should not be treated as suspicious without separate evidence.

Bridge correlation

A bridge can break a single-chain trace, so cross-chain correlation should be an explicit control. A useful record contains source chain, source transaction, wallet, asset, amount, bridge, timestamp, destination chain, destination transaction or mint event where available, destination asset and wallet, and correlation confidence.

Confidence matters because some bridges batch, net or pool transfers. If a provider supplies the cross-chain link, the case should preserve provider and query time rather than present the relationship as an immutable ledger fact. Once value reaches the destination chain, tracing should continue there when material.

Historical interpretation and new intelligence

Protocols change. Contract logic, governance, administrators and risk labels can change over time. Historical analysis should use the configuration and evidence relevant to the transaction date where material.

If a protocol is compromised in 2026, ordinary customer use in 2024 should not automatically be reclassified as suspicious. If an address is later identified as part of an exploit, a lookback may be appropriate, but the case should distinguish the new intelligence from what the original investigator knew.

Incident intelligence should also have provenance. Law-enforcement notices, sanctions authorities, official protocol disclosures and vetted analytics should be distinguishable from unverified social-media claims. The bank should record who validated a new attribution and when monitoring or lookback rules were activated.

Stablecoins in DeFi

Stablecoins commonly act as settlement and liquidity instruments across DEXs, lending protocols and bridges. FATF’s March 2026 report highlights both their legitimate role and their attractiveness to illicit actors because of liquidity and transferability. Stablecoin use itself is not suspicious.

Some issuers may have technical capabilities to freeze or restrict addresses. Whether such capabilities exist, whether they were used and what legal authority applies are separate questions from the bank’s AML assessment. Investigators should record observable facts and route legal or sanctions questions appropriately.

Evidence hierarchy

Not all evidence deserves equal weight. A transaction hash and contract event are primary technical evidence. An official sanctions listing or law-enforcement notice is strong external evidence for the fact it establishes. An analytics attribution can be valuable but remains an analytical conclusion whose provider, confidence and query time should be retained. Customer explanations should be tested against objective records where the risk is material.

A strong narrative might say: “Exchange records support the customer-wallet link. The wallet called a recognised bridge contract. The destination leg is correlated by the bridge event and provider X. Provider X attributes the later recipient to an exchange with high confidence. Customer exchange records are consistent with that attribution.” That is stronger than “blockchain tool shows funds went through DeFi.”

Ambiguous labels and negative evidence

Different providers can classify the same address differently. A bank should preserve external labels while mapping them to an internal taxonomy with confidence and effective date. A provider change can then be assessed for future monitoring or lookback without rewriting historical cases.

Investigators should also look for evidence that weakens concern. A long-held liquidity position with documented original funding and matching withdrawal can support a customer explanation. A supposed mixer exposure that turns out to be a shared exchange wallet may remove the original concern. The purpose of investigation is to reach a defensible conclusion, not to accumulate reasons to escalate.

Practical close

When a DeFi investigation is complete, another investigator should be able to reproduce the economic story. They should know which wallet was linked to the customer, which protocol functions were used, where value entered and exited, which conclusions came from raw blockchain facts, which came from analytics or customer evidence, and where uncertainty remains.

That standard prevents two weak extremes: treating every smart-contract interaction as suspicious, or assuming decentralised infrastructure makes meaningful investigation impossible.

Advanced practice: control design, calibration and assurance for DeFi exposure

DeFi controls become credible only when they survive real operating conditions: new protocols, changing labels, vendor outages, sanctions updates, customer complaints and conflicting evidence. Advanced practice therefore focuses on building a control that remains explainable as the environment changes.

Design around decisions

A weak implementation begins with a list of blockchain indicators and turns each into an alert. A stronger design begins with the bank decisions that must be made: permit or review activity, request evidence, escalate to AML or sanctions, protect a likely scam victim, restrict a relationship, or perform a lookback.

Each decision needs defined inputs, minimum evidence, owner, exception route and audit record. A high-risk DeFi flag is not enough. The workflow should show which fact changed the outcome.

For example, direct receipt of recently stolen assets above a materiality threshold may require specialist review. Relevant inputs include customer-wallet linkage, incident attribution, directness of exposure, amount, timing and intervening services. The result is a prioritised case, not an automatic conclusion that the customer committed the theft.

Keep legal checks and behavioural analytics separate

Sanctions and other deterministic legal controls can require authoritative lists and approved legal logic. Behavioural AML monitoring is different: it combines context and indicators to identify activity that may require investigation. These should not be hidden inside one composite score.

A case can expose separate facts such as authoritative sanctions match: none, direct exploit exposure: high, rapid chain hopping: present, customer profile mismatch: material and analytics score: 82/100. The investigator can then see what drives the concern.

This separation also supports testing. Deterministic controls can be tested against known entries, effective dates and legal rules. Behavioural scenarios can be tested with suspicious, clean and ambiguous patterns for sensitivity, precision and customer impact.

Maintain an internal service taxonomy

Analytics providers classify virtual-asset services differently. The bank should maintain an internal taxonomy for policy and reporting while preserving the original vendor label.

Useful categories include centralised VASPs or CASPs, self-hosted wallets, DEX routers, liquidity pools, lending protocols, bridges, staking arrangements, mixers or privacy services where separately identified, stablecoin issuers, custody services and unknown contracts.

Taxonomy changes need governance. If a service previously classified as generic DeFi is later split into bridge and DEX components, scenarios may need regression testing and an impact assessment. Historical cases should not silently change because the current label changed.

Expose score components and avoid double counting

A DeFi risk score is useful only if investigators can see its ingredients: source and destination exposure, service type, chain, asset, customer profile, velocity, bridge use, proximity to known illicit services and attribution confidence.

Banks should avoid double counting. A provider’s overall score may already include sanctions or mixer exposure. Adding the same factors again internally can exaggerate risk. Model documentation should identify overlapping inputs.

Indirect exposure also needs context. One hop from a known exploit through a private wallet can be more meaningful than one hop through a large exchange hot wallet. Graph distance alone is not a universal risk measure.

Make chain coverage measurable

“Supports crypto” is not a control statement. Coverage should be defined by chain, asset, event type and feature.

A coverage register can show whether the bank can parse native transfers, major token standards, smart-contract calls, DEX swaps, bridge events and service labels on each supported chain, together with data freshness and latency. If a chain is unsupported or only partly supported, the system should say coverage unavailable, not no risk found.

Material product exposure to unsupported chains should result in an explicit risk decision: restricted activity, manual review, alternate data or accepted residual risk.

Govern analytics vendors

Blockchain analytics providers are important third parties. Banks should understand their attribution process, chain coverage, update frequency, correction process, resilience and model limitations.

Due diligence should ask how labels are established, how confidence is represented, how false attributions are corrected, how historical results can be reconstructed and how cross-chain links are generated. Ongoing monitoring should detect unexplained changes in scores, labels or coverage.

A sudden drop in high-risk alerts might reflect improved customer behaviour, but it could also indicate a failed data feed. Control monitoring needs to distinguish those explanations.

Calibrate scenarios from a risk hypothesis

“Rapid bridge use can indicate layering when combined with illicit-source exposure and inconsistent customer purpose” is a testable hypothesis. “Bridge equals high risk” is not.

Calibration samples should include clean DeFi users, fraud victims, professional traders, long-term investors, corporate Web3 customers and different protocol types. Testing only previously escalated cases creates circular logic.

Thresholds should be segmented where behaviour differs materially. A professional digital-asset business may legitimately conduct high-volume activity, while a first-time retail customer moving most savings through several unfamiliar services after a scam contact presents a different risk profile.

If thresholds are raised to reduce alert volume, governance should record which risk is no longer captured and who accepted that residual exposure.

Join fraud and AML without confusing them

DeFi scams demonstrate why fraud and AML cannot work in isolation. A customer may be manipulated into buying stablecoins and sending them into a malicious contract. Fraud systems may detect behavioural change or coercion. AML systems may identify receiving wallets and onward laundering. Customer-service records may contain the scam narrative.

A joined case view improves both protection and intelligence, while confidentiality rules around suspicious-activity reporting still need to be respected. The design should also avoid penalising victims. A customer should not automatically receive a severe AML risk rating merely because scam proceeds left their wallet and reached a criminal network.

Design for analytics outages

If a blockchain-enrichment service fails, service unavailable must never become no exposure.

Retrospective monitoring may queue events for later enrichment. Time-sensitive products may use approved fallback controls such as cached high-risk identifiers, deterministic sanctions data, internal VASP classifications or transaction limits. The fallback depends on law, product and risk appetite.

Recovery testing should prove that queued events are replayed without loss or duplication and that point-in-time evidence is preserved when labels change during the outage.

Handle urgent intelligence through controlled change

New exploits, designations and high-risk addresses can become relevant within hours. Banks need a fast but controlled intelligence path: validate the source, assess exposure, approve a temporary rule or list entry, run monitoring or lookback, review results and then retire or formalise the change.

Emergency changes still need evidence: source, approver, effective time, systems affected, validation performed and rollback path.

QA and management information

Case QA should test reasoning, not formatting. Reviewers should ask whether the investigator identified the correct economic action, established wallet linkage adequately, interpreted shared infrastructure correctly, preserved uncertainty and applied the right legal or policy route.

Management information should cover unsupported-chain volume, enrichment failures, label freshness, alert precision, alerts driven only by shared infrastructure, cross-chain trace completion, ageing cases, QA defects, customer impact and time to incorporate new authoritative intelligence.

The key management question is not “How many DeFi alerts did we close?” It is “Can we explain which DeFi risks matter to this bank, whether our controls see them and what evidence shows the controls are effective?”

Advanced-practice takeaway

A sustainable DeFi control distinguishes unsupported data from low risk, direct exposure from shared infrastructure, vendor inference from authoritative fact, victim behaviour from laundering behaviour and AML suspicion from sanctions obligation. That precision is what allows a bank to manage a rapidly changing decentralised-finance environment without either ignoring risk or treating every DeFi user as suspicious.

Practice close: turn DeFi risk into buildable banking controls

This section converts the chapter into delivery artefacts for business analysts, architects, developers, testers, investigators and control owners. The aim is to know what a bank system must capture, decide, retain and prove.

Minimum case data

A DeFi case should preserve enough data to reconstruct both the bank event and the blockchain event. A strong minimum includes customer identifier, relevant bank payment or exchange event, wallet address and ownership confidence, chain, transaction hash, asset and token contract where relevant, amount, timestamp, smart-contract address, interpreted protocol function, service classification, source and destination exposure, analytics provider, label confidence, query time, applicable sanctions source where relevant, customer evidence, decision, approver and policy version.

The key principle is provenance. Raw blockchain facts should not be overwritten by enrichment. A transaction hash remains the raw identifier even if a provider later changes the address label.

BA requirements that are actually testable

Wallet evidence: When a decision relies on customer control of a wallet, the workflow must record evidence type, source, date, confidence and reviewer. It must not display verified owner where evidence supports only a probable link.

Protocol interpretation: When a transaction calls a recognised DeFi contract, the case must show the raw contract address and interpreted action such as swap, liquidity deposit, lending event or bridge transfer. If interpretation is unavailable, the state must be unclassified, not low risk.

Cross-chain continuity: When a bridge event is detected, the system must preserve source-chain identifiers and, where available, destination-chain identifiers plus correlation confidence. An unresolved destination leg must remain visible where onward tracing is required.

Point-in-time evidence: Every external risk label used in a decision must carry provider, query time and confidence or evidence basis. A later query must not silently replace the historical value in the original case.

Sanctions separation: A sanctions outcome must record the authoritative list or approved sanctions source and decision logic separately from a general blockchain risk score.

Outage behaviour: If an enrichment service is unavailable, the event must stay pending or follow the approved fallback. It must never become no exposure solely because the service failed.

Acceptance criteria

Acceptance criteria should prove meaning, not only screen behaviour.

A DEX swap test should show the router as infrastructure and the customer action as a swap. A liquidity-pool test should prove the system does not treat every pool participant as the customer’s direct counterparty. A bridge test should show both chain legs where data is available and retain correlation confidence. A lending test should distinguish collateral return from third-party income. A sanctions test should route an authoritative match to sanctions workflow even when the behavioural AML score is otherwise low.

Negative tests are equally important. A legitimate long-term DeFi investor with well-supported source of funds should be capable of passing review. A customer interacting with shared infrastructure that has distant illicit exposure should not automatically inherit the highest risk classification. An unknown contract should remain unknown rather than be treated as safe.

Five useful test families

Clean normal activity: Exchange funding, withdrawal to a known wallet, DEX swap or protocol position, normal holding period and return to the same regulated exchange with evidence consistent with the customer profile.

Direct illicit-source activity: A customer wallet receives value directly from an address linked to a known theft or scam and rapidly swaps or bridges it.

Shared-infrastructure ambiguity: The customer uses a high-volume pool or router also used by unrelated high-risk wallets. Expected outcome: contextual review, not automatic contamination.

Victim behaviour: A customer with unusual behavioural signals buys crypto and sends it to a scam-linked wallet or contract. Fraud protection should be visible while AML teams analyse the receiving network.

Data failure: A chain is unsupported, bridge correlation is unavailable, an analytics API fails or a provider label changes. The system must surface uncertainty instead of hiding it.

Data-lineage and replay tests

A reviewer should be able to select any case decision and trace important fields to their sources. The displayed protocol name should trace to the classification record and raw contract address. The wallet label should trace to the analytics response and timestamp. The customer-wallet link should point to evidence. The final decision should reference the policy version in force.

Historical replay is especially important. If a provider changes an address from unknown to exploit proceeds, the old case should retain its original result while the lookback process creates a new assessment using the new intelligence.

Mobile and investigator usability

DeFi cases can become visually dense. On narrow screens, the case should prioritise the decision story: customer, trigger, wallet linkage, key source exposure, key destination exposure, protocol action, cross-chain continuation and disposition. Detailed graph exploration can sit behind a deeper view.

Long hexadecimal addresses must wrap or copy cleanly without horizontal overflow. Chain and asset names should appear alongside identifiers. Risk labels must not depend on colour alone. Diagrams and evidence timelines need readable text at mobile widths.

Investigator prompts

A useful case template asks:

  1. What bank event triggered the review?
  2. What evidence links the wallet to the customer?
  3. What economic DeFi action occurred?
  4. Which facts are raw blockchain evidence and which are analytics inference?
  5. Is concerning exposure direct, indirect through a private wallet, or through shared infrastructure?
  6. Did value cross a bridge, and is the destination resolved?
  7. What does the customer explanation resolve and what remains unsupported?
  8. Is there a fraud-victim dimension?
  9. Is there a separate sanctions trigger under the applicable framework?
  10. What action follows, who owns it and what evidence must be retained?

These questions are more useful than simply asking whether the customer “used DeFi.”

QA defects to reject

Reject cases that describe a DEX router as the beneficial owner of swapped funds without evidence. Reject conclusions based only on a vendor score. Reject bridge cases that stop at the source chain when destination tracing is available and material. Reject source-of-funds conclusions that ignore collateral or liquidity-position mechanics. Reject current sanctions or risk labels pasted into historical cases without preserving the original decision-time state.

Also reject overly technical narratives that never answer the banking question. A case can contain dozens of hashes and still fail if it does not explain why the activity is acceptable or concerning.

Control-owner review

Control owners should periodically sample DeFi alerts and ask whether scenarios still reflect the bank’s real exposure. New chains, protocol types and products can change the answer quickly. Review should consider alert yield, missed-event analysis, unsupported-chain volume, customer complaints, fraud outcomes, new FATF or supervisory guidance, sanctions changes and provider coverage.

Changes should remain traceable through requirements, design, test evidence and approval. Urgent authoritative intelligence can use a controlled emergency-change route, while unverified social-media claims should not become production logic.

Final learner check

A learner should be able to explain that DeFi is a functional category rather than a legal conclusion; smart contracts are infrastructure needing economic interpretation; pools and routers can weaken naive counterparty analysis; bridges require cross-chain correlation; blockchain analytics is powerful but inferential; sanctions decisions need authoritative legal logic; scam victims can look unusual without being launderers; and bank controls need point-in-time evidence and clear data lineage.

If those principles appear in requirements, scenarios, case workflow and QA evidence, the bank has moved beyond simply “screening crypto” and built a control capable of handling decentralised-finance activity defensibly.

Masterclass: a cross-chain DeFi investigation from bank payment to off-ramp

This case is fictional but realistic. It is designed to show how a bank should reason through DeFi activity without treating protocol use as wrongdoing and without letting technical complexity hide a material financial-crime concern.

The trigger

A long-standing retail customer receives a credit equivalent to about six months of salary from a regulated virtual-asset exchange. The customer has previously made small exchange payments but has never received a credit of this size. The transaction-monitoring system creates an alert because the amount is unusual for the profile and the payment reference indicates a crypto-asset withdrawal.

The first-line analyst contacts the customer under the bank’s normal source-of-funds process. The customer says the money came from “DeFi trading and liquidity rewards” accumulated over eight months. They provide an exchange statement showing that assets were deposited to the exchange shortly before the fiat withdrawal. They also provide one wallet address and several transaction hashes.

At this point, the explanation is plausible. DeFi profit is not inherently suspicious. The question is whether the evidence supports the claimed source.

Establishing wallet ownership

The investigator first links the disclosed wallet to the customer. The customer’s historic exchange records show earlier withdrawals to the same address, and the current exchange deposit also came from that address. Under bank policy, the combination is sufficient for the investigation; a cryptographic signing challenge is not required in this case.

That distinction is recorded explicitly. The case says the wallet is “strongly linked to the customer through exchange records,” not “provably owned forever by the customer.” Wallet-control evidence can change and wallets can be shared or compromised.

Reconstructing the position

The wallet history shows that the customer originally bought stablecoins through the regulated exchange eight months earlier. The stablecoins were withdrawn to the disclosed wallet and deposited into a well-known lending protocol. Two weeks later, some of the position was withdrawn and used to provide liquidity in a DEX pool. The customer’s story is therefore partly corroborated.

The analytics tool initially assigns a moderately high risk score because the DEX pool has indirect exposure to illicit wallets. The investigator does not treat that score as a conclusion. The pool is shared infrastructure with high transaction volume, and the customer’s interaction is a normal liquidity deposit rather than a direct transfer to the illicit wallets. That component of the risk is downgraded in the case rationale.

The fact that changes the case

Further tracing shows that three months after the original investment, the customer received a large stablecoin transfer from an address linked with high confidence to proceeds from a public DeFi exploit. The transfer reached the customer wallet directly, without an exchange or pooled service in between. It arrived less than a day after the stolen funds were first dispersed.

The amount is material and later became part of the customer’s liquidity position. This is different from the earlier indirect pool exposure. The investigator now has a direct provenance concern.

The bank verifies the attribution against two sources: the analytics provider’s incident label and a public incident disclosure identifying the relevant exploit addresses. The case records the attribution source and query date.

The bridge sequence

Shortly after receiving the direct transfer, the customer moved most of it through a cross-chain bridge. The source-chain event can be correlated to a destination-chain wallet controlled by the customer based on the bridge event and subsequent exchange records. On the destination chain, the assets were swapped twice and deposited into another lending protocol.

The sequence is not automatically laundering. A legitimate user can bridge and swap assets for yield or market access. However, in this case the timing, direct exploit provenance and rapid movement materially increase concern. The investigator now needs to understand why the customer received those assets in the first place.

The customer explanation

A targeted request for information asks the customer to explain the direct transfer and provide any evidence showing the sender or economic purpose. The customer responds that the transfer was “payment from a DeFi community member” for consulting on a token project, but cannot provide an invoice, contract, message history or identity for the payer.

The customer also states that they did not know the funds were connected to an exploit. That may be true. Knowledge is relevant to some legal conclusions, but the bank’s AML decision does not require the investigator to prove criminal intent beyond doubt. The task is to decide whether the activity is sufficiently suspicious under the applicable law and policy to escalate or report.

The bank therefore separates two questions. First, is the customer’s explanation adequately supported? No. Second, does the available evidence prove the customer participated in the exploit? No. The case should not overstate the conclusion.

Fraud, sanctions and AML checks

The exploit addresses are checked against the bank’s applicable sanctions sources. No authoritative sanctions designation is identified for the relevant transaction path at the decision time. The sanctions workflow records “no sanctions trigger identified under the applicable lists and policy,” rather than relying on the AML risk score.

Fraud teams check whether the customer appears to have been scammed. There is no evidence of coercion, remote-access manipulation or victim reporting. That does not rule out fraud, but it means the case remains primarily an AML source-of-funds and proceeds-tracing concern.

Case disposition

The investigator writes a concise evidence-led narrative:

The customer’s original DeFi activity is broadly consistent with the declared investment history. Indirect exposure arising from shared DEX liquidity is not treated as evidence of wrongdoing. A later material direct transfer, however, is linked with high confidence to recently stolen exploit proceeds. The customer moved that value across chains soon afterward and cannot provide credible evidence of the sender or consulting relationship claimed as the economic basis for the payment. The activity is therefore escalated under the bank’s suspicious-activity procedure.

The bank’s local reporting officer decides whether a report is required under the jurisdiction’s legal standard. That decision is recorded separately from the investigator’s recommendation. Relationship-management actions are considered under risk appetite and customer-treatment policy rather than being automatically tied to the reporting decision.

What the architecture needed to make this possible

The case worked because several controls joined up. The bank could link fiat exchange activity to customer-wallet evidence. Its analytics platform could interpret DEX and lending activity rather than simply display raw transfers. Cross-chain correlation preserved the bridge path. Incident intelligence had a controlled provenance. The workflow kept sanctions and AML decisions separate. The case system stored the point-in-time analytics result and customer evidence.

If any one of those components had been missing, the outcome could have been worse. Treating all DEX exposure as high risk might have caused an early false escalation and obscured the genuinely important direct transfer. Stopping the trace at the bridge would have hidden the later lending position. Accepting the customer’s generic “DeFi profits” explanation without wallet evidence would have missed the exploit link. Treating the analytics score as a sanctions finding would have created a legal error.

The training lesson

The strongest DeFi investigations are not the ones with the most complicated graphs. They are the ones that identify the few facts that change the decision. In this case those facts were wallet linkage, direct exploit provenance, timing, cross-chain continuity and the absence of credible evidence for the claimed payment purpose.

Everything else was context. Knowing that difference is what turns blockchain analytics from a visual tool into a defensible banking control.

References and further reading

These sources were used for the chapter’s global-standard, regulatory and bank-control context. Jurisdiction-specific obligations still need to be applied through the bank’s current legal and compliance interpretation.

Global standards and current DeFi risk

United States examples

European Union example

Additional supervisory material

The chapter deliberately treats FATF as a global standard setter and the U.S., EU and Australian materials as jurisdiction-specific examples. It does not present a single country’s licensing, Travel Rule, sanctions or suspicious-activity-reporting rule as globally universal.