AML Compliance for RWA Tokenization: KYC, Wallet Screening, and Secondary-Market Transfers

"Securities, however represented, remain securities... economic reality trumps labels." That line from SEC Chair Paul Atkins, delivered in a November 2025 speech, became the backbone of the joint staff Statement on Tokenized Securities issued on January 28, 2026 — the most detailed regulatory signal to date that putting an asset on a blockchain changes its format, not its obligations. The market this guidance addresses is no longer small: according to CoinGecko's RWA Report 2026, the market capitalization of tokenized real-world assets grew 256.7% in fifteen months, from $5.42 billion at the start of 2025 to $19.32 billion by the end of March 2026, and industry trackers put freely tradable on-chain RWA value above $33 billion by mid-2026.

Here is the compliance problem hiding inside those numbers. An RWA token can represent ownership, a claim, an entitlement, or economic exposure tied to an off-chain asset — a building, a loan portfolio, a fund interest. Everything that makes the holder legitimate lives off-chain: identity records, legal rights, investor eligibility, the documentation of the underlying asset. But the transfer itself happens on-chain, between blockchain addresses. In practical terms, this means the blockchain will happily execute a transfer to any technically valid address, whether or not the person behind that address has passed any check or has any legal right to hold the asset. After issuance, the token can move to a new wallet, a new investor, a different custodian, or an external platform — and each of those moves can quietly break the chain of verification the issuer built at launch.

That is the question this article works through: how can an RWA platform preserve the link between a verified holder, an approved wallet, a token transfer, and the related payment throughout the asset lifecycle?

Define the Compliance Perimeter Before Building AML Controls

There is no single AML regime that covers "RWA Tokens" as a category, because the label covers very different legal constructions. Under the same three letters you can find a tokenized security, a debt claim, a fund interest, a direct ownership interest, a right to redemption, a claim against an issuer or SPV, contractual exposure to real estate, commodities, or private credit — or a token connected to a physical asset without any direct legal ownership at all. The classification is not academic. Depending on what the token actually is and how the structure operates, it can determine licensing or registration requirements, the depth of customer due diligence, investor eligibility rules, transfer restrictions, custody requirements, which trading venues are permitted, recordkeeping standards, whether the Travel Rule applies, and what has to be reported to regulators. The SEC staff statement made the same point for U.S. securities: the token format does not create a new legal category, and if the tokenized instrument grants different rights than its traditional counterpart, it may even constitute a separate class of security with its own disclosure obligations.

(Source: SEC Divisions of Corporation Finance, Investment Management, and Trading and Markets, Statement on Tokenized Securities, January 28, 2026)

The working principle for a compliance team is this: the use of blockchain does not determine the regulatory or AML perimeter by itself. The rights represented by the token, the activities performed, the participants involved, and the jurisdiction do.

What the RWA Token Actually Represents

Before anyone designs an onboarding flow or a screening rule, the team needs answers to a short list of questions:

• What legal or economic right does the token represent?
• Who issued that right?
• Is the holder recorded only on-chain, or also in an off-chain register?
• Does token ownership equal legal ownership?
• Can the token be freely transferred?
• Does the issuer need to approve a new holder?
• Is redemption available only to verified holders?
• Are specific investor categories or jurisdictions restricted?

The answers define what a "compliant transfer" even means for this specific token. And they expose a structural requirement that is easy to miss: the blockchain record, the issuer's register, the custodian's records, and the legal documentation must all describe a compatible ownership model. If the smart contract says the token moves freely while the offering documents say the issuer must approve every new holder, the platform has a compliance gap baked into its architecture before the first transfer ever happens.

Which Participant Performs the Regulated Activity

A typical RWA structure involves more parties than most crypto products: the asset owner or originator, the issuer, an SPV, the tokenization platform, placement or distribution partners, a custodian, a broker, a transfer agent, a trading venue or marketplace, external VASPs or CASPs, and a smart-contract administrator. Regulatory obligations do not attach to the label a company gives itself. They attach to what each party actually does: who onboards investors, who holds customer assets, who manages wallets, who accepts or transmits funds, who arranges trading, who executes token transfers, who controls redemption, who manages the allowlist, and who can pause or reject operations. A tokenization platform that never touches customer funds sits in a very different position than one that also runs the marketplace and controls the settlement wallets.

Do Not Assume the Travel Rule Applies to Every RWA Transfer

The Travel Rule question deserves its own short answer: it depends, and it has to be assessed separately for each model. Applicability can turn on the token's legal classification, the status of the sender and recipient, whether a VASP, CASP, or another obliged entity is involved in the transfer, the nature of the transfer itself, and the jurisdiction. A transfer between two self-hosted wallets, a transfer between regulated intermediaries, and an internal movement inside a controlled platform can each carry different requirements and different allocations of responsibility. What a platform should not do is adopt either extreme — assuming the rule applies to every RWA transfer, or assuming tokenized securities are always outside it.

Assign Responsibility Across the RWA Infrastructure

The multi-party nature of RWA structures creates a specific failure mode: everyone assumes someone else already ran the check. The issuer assumes the platform verified the investor. The platform assumes the custodian confirmed wallet ownership. The custodian assumes the marketplace screened the counterparty. Each party holds a piece of the picture, and the gap between the pieces is exactly where illicit activity slips through. A useful starting point is to map what each participant typically sees and controls:

In an RWA tokenization structure, eight participants typically hold a distinct piece of the compliance picture — the issuer or SPV, the tokenization platform, the KYC/KYB provider, the custodian, the marketplace, the transfer agent, the smart-contract administrator, and the compliance team:

The table is not a legal allocation of duties — that depends on the business model, the contracts, the licenses held, the asset structure, the jurisdiction, and the functions each party actually performs. What the table does is force the conversation that has to happen before launch. The participants need to agree, in writing, on who performs KYC and KYB, who verifies the issuer, SPV, and related parties, who confirms wallet ownership, who runs wallet screening, who manages the allowlist, who controls secondary transfers, who reviews the payment transaction, who receives alerts, who makes the approve, hold, or reject decision, who files regulatory reports, who retains the supporting records, and what data flows between providers.

In practical terms, the last three items are where most arrangements fall apart. A provider can run a flawless screening check, but if nobody is contractually responsible for acting on the result, the check is decoration. Outsourcing a verification or screening function does not remove the need to define who owns the final compliance decision.

Build AML Controls Before the Token Is Issued

The pre-issuance phase moves from the structure outward: first the parties who build and operate the deal, then the investors who buy into it, and finally the specific wallets that will receive the token.

Issuer, SPV, and Related-Party Due Diligence

Before any investor sees the offering, the structure itself needs due diligence. That means verifying the issuer, the SPV, parent or controlling entities, beneficial owners, directors, authorized representatives, the asset originator or seller, material intermediaries, the custodian, and distribution partners.

For each of these, the review looks at legal existence and operating status, ownership structure, ultimate beneficial owners, sanctions and PEP exposure, adverse information, jurisdiction, the nature of the business, the source of funds used to establish or fund the structure, connections between the issuer, the asset seller, and the investors, and whether the ownership chain is complex or opaque in a way that lacks a business rationale. An SPV whose ownership trail dead-ends in a jurisdiction with no accessible corporate registry is a finding, not a formality.

One distinction keeps these reviews honest. Asset due diligence establishes the characteristics, ownership, and condition of the underlying asset — is the building real, is the loan performing. AML due diligence evaluates the people, companies, ownership structures, funds, and counterparties around the deal. They answer different questions, and neither substitutes for the other. Wallet screening, in particular, cannot confirm that a property exists, who legally owns a physical asset, what it is worth, or whether an invoice is authentic — those belong to legal and financial due diligence.

Investor and Business Onboarding

For individual investors, onboarding covers identity verification, document validation, biometric or liveness checks, sanctions screening, PEP screening, jurisdiction and residency confirmation, customer risk classification, and — where a risk-based trigger or a regulatory requirement applies — source of funds or source of wealth.

For corporate investors, the work runs through KYB: registration and operating status, ownership structure, UBO verification, directors, authorized representatives, business activity, sanctions and PEP exposure, and jurisdictional risk. The representative who signs the subscription documents is not the same compliance object as the company itself, and the company is not the same object as its beneficial owners; each layer gets checked.

RWA offerings add one more layer that often causes confusion: investor eligibility. Accreditation, qualified investor status, or professional investor classification can be verified in the same onboarding flow as KYC and KYB — but eligibility is a securities-law concept, not an AML control.

Link the Verified Participant to an Approved Wallet

Onboarding produces a verified person or company. It does not produce a verified wallet — that is a separate step, and it has to happen before minting or the initial transfer.

For each address an investor provides, the platform needs to establish: who controls the wallet; whether it is self-hosted or custodial; how control was confirmed; if custodial, whether the account actually belongs to this specific customer; whether the address was used before; whether it is linked to other customers or entities; whether it carries high-risk exposure; whether the platform's rules permit this wallet type at all; and whether the address needs to be added to an allowlist.

Four points are worth stating bluntly, because each one is a common shortcut:

• A verified identity and a wallet address are different compliance objects. Confirming one does not confirm the other.
• Passing KYC does not make any address the customer submits safe to use.
• A clean wallet screening result does not confirm the identity of the wallet's owner.
• An approved wallet does not stay low-risk forever. Exposure changes as the address transacts.

This is the point where identity verification and on-chain analysis have to work as one system — the same logic that governs how KYC and KYT work together in crypto compliance. And before the token actually moves, the receiving address goes through crypto wallet screening to check its transaction history and counterparty exposure, so that the first entry in the holder register starts from a documented, clean baseline.

Secondary-Market Transfers Are the Main AML Control Breakpoint

Everything up to this point describes controls the platform runs while it still holds all the cards. The moment the token starts moving, the picture changes. This is the central problem of RWA compliance: initial KYC identifies the first holder, but it does not automatically control every wallet, counterparty, payment, or secondary-market transfer that follows.

Consider what can happen after issuance. An existing investor moves the token to another wallet they claim is theirs. The token is sold to a new buyer. A company shifts its holding from one custodian to another. A trade routes through a marketplace or trading venue. The token is sent to an external platform. A transfer targets a wallet nobody has verified. The payment and the token settle in two separate transactions on different rails. A holder sells the token entirely outside the original platform. Each scenario carries a different risk profile and requires a different level of verification and review — and international standard-setters have flagged the same blind spot: the Financial Stability Board noted in October 2025 that secondary-market monitoring remains one of the underdeveloped areas in digital asset oversight, and FATF's June 2025 Targeted Update found jurisdictions still struggling to identify who actually conducts virtual asset activity once assets leave regulated perimeters.

Transfer to Another Wallet of the Same Holder

The most innocent-looking scenario is also a frequent gap. An investor emails support: "I'm moving my tokens to my new hardware wallet, here's the address." The temptation is to treat this as a non-event — same person, same holding, new address.

It is not a non-event. The new wallet is an unverified address until proven otherwise. The platform needs to confirm wallet ownership or control, determine whether the address is self-hosted or custodial, run wallet screening on it, update the customer-to-wallet mapping, check for connected addresses, retain evidence of the approval, and decide whether the change warrants a repeat or enhanced review.

In practical terms, this does not mean re-running full KYC every time a customer rotates wallets — if the customer's identity data is current, that would be friction without benefit. What it does mean is that the link between the verified holder and the new address must be positively confirmed and documented, not assumed. One caveat matters here: a blockchain signature from the new address proves technical control of the key. It does not always prove legal ownership — it cannot tell you whether the person is acting on their own behalf, or who actually owns a custodial account the address belongs to.

Transfer to a New Buyer or Institutional Counterparty

When the token changes hands, the buyer is a new customer, full stop. Before the transfer executes, the platform verifies the identity of a new individual buyer, or runs KYB on a new corporate buyer including UBOs, directors, and authorized representatives; screens for sanctions and PEP status; confirms jurisdiction and investor eligibility; assesses the receiving wallet and its control; checks the transfer restrictions that apply to this specific token; identifies any custodian, broker, venue, or intermediary in the chain; and — where risk triggers warrant it — reviews the source of the settlement funds.

Two principles anchor this section, and they are mirror images of each other. First: screening the receiving wallet does not replace KYC or KYB of the new holder. A wallet with a clean history tells you nothing about who is behind it. Second: a completed KYC check does not remove the need to assess the receiving wallet and the related payment. A fully verified buyer can still direct the token to a compromised address or pay with tainted funds. The wallet and the person are separate risk objects, and a secondary trade requires both to clear.

Off-Platform and Permissionless Transfers

The hardest scenario is the one the platform never sees coming. If the token's contract allows free transfers, or if the holder finds a technical route around the platform, several gaps open at once: the new holder may never pass onboarding; the issuer may not know who the new holder is; the token may land on an external marketplace or an unsupported custodian; a receiving address may be technically reachable but prohibited by compliance policy; the token may end up with a restricted investor or in a prohibited jurisdiction; the payment may settle entirely outside controlled infrastructure; and the off-chain holder register may quietly stop matching on-chain balances — which, for a tokenized security, means the legal record of ownership and the blockchain no longer agree.

The available controls form a spectrum, and different structures use different combinations: wallet allowlists, transfer approval mechanisms, restrictions on unsupported addresses, pause functions, compliance administrator roles, smart-contract events that notify the compliance team, off-chain holder register updates, manual review, transfer rejection, and escalation.

A word of calibration, because this section attracts absolutist claims. Permissionless transfers are not inherently illegal, not every RWA token needs a whitelist, a smart-contract restriction does not solve the identity problem, and an external wallet is not automatically high-risk. The point is narrower: whatever transfer model the token uses, the platform must know which scenarios its controls cover, which they do not, and how the uncovered ones get detected and reviewed.

Connect the Holder, Wallet, Token, and Payment

When a compliance analyst reviews an RWA transfer, the question is never just "is this wallet risky?" It is "does this transfer make sense given who these parties are, what they hold, and how the trade is being paid for?" Answering that requires context, and the context has to exist before the alert fires.

Maintain a Reliable Holder-to-Wallet Record

For every investor or business participant, the platform should maintain a connected record: the internal customer or entity ID, the verified identity, company and UBO data, the customer risk rating, approved wallets, wallet ownership evidence, custodial accounts, RWA token holdings, acquisition history, token transfers, settlement wallets, sanctions and PEP results, wallet screening results, related alerts, previous restrictions, transfer approvals, and the escalation and review history.

Two situations make this record genuinely hard to maintain, and both are routine in RWA markets. First, one customer uses several wallets — a trading wallet, a cold-storage wallet, a custodial account — and each needs its own ownership evidence and mapping. Second, one custodial wallet holds assets belonging to several customers, which means the on-chain balance of that address tells you nothing about any individual holder's position.

This is why the raw blockchain is never enough. An address by itself does not reveal who the legal holder is, whether the sender acts in their own name or represents a company, whether the holder ever passed onboarding, who owns a custodial balance, or whether this particular holder is permitted to hold this particular token. Attribution techniques can group addresses into clusters and label services, but for RWA purposes the bar is higher: the platform must provably connect an approved address to a verified investor, corporate holder, or custodial account — not merely to an on-chain entity.

Screen Identity and Blockchain Exposure Separately

RWA screening runs on two distinct levels, and conflating them is one of the most common design errors.

Identity and entity screening covers the people and organizations: the individual, the company, its UBOs, directors, and authorized representatives, the custodian, the broker, the marketplace, and any institutional counterparty — checked against sanctions lists, PEP databases, adverse information, and jurisdictional risk.

Blockchain screening covers the addresses and flows: the sending wallet, the receiving wallet, the payment wallet, transaction history, direct and indirect sanctions exposure, and connections to scams, hacks, stolen funds, mixers, darknet markets, and other high-risk counterparties.

The two levels answer different questions, and both must clear. A clean identity does not guarantee a clean wallet — a verified investor can control an address with mixer exposure. And wallet exposure does not by itself prove wrongdoing by the holder — an address two hops removed from a hack may reflect an ordinary exchange interaction. In practical terms, a risk score is an input to human review, not a verdict; treating a screening result as automatic proof of money laundering produces both false accusations and false comfort.

Monitor the Payment Leg as Well as the Token Transfer

Here is a structural feature of RWA secondary trades that generic transaction monitoring misses entirely: the token transfer and the payment for it are usually two different transactions. The RWA token moves in one on-chain transfer; the payment moves in another — often in a stablecoin or a different crypto asset, sometimes through different wallets, different platforms, or even different chains.

A complete review therefore reconciles the whole trade: the seller, the buyer, the beneficial holder, the RWA token and quantity, the token sending wallet, the token receiving wallet, the settlement asset, the payment sending wallet, the payment receiving wallet, the amount, the timing, the venue, the custodian, the transfer approval, and the settlement status.

The reason this matters is that risk can hide on either leg. The wallet receiving the token can look perfectly clean — while the stablecoins used to pay for it trace back to a high-risk source. The reverse happens too: the settlement funds raise no alerts, but the token itself is heading to an unverified or sanctions-linked address. Watching only one leg means seeing half the trade.

Certain events should trigger a fresh look rather than a routine pass: a secondary transfer, the addition of a new wallet, a change in a wallet's risk profile, a sanctions list update, an unusual transfer sequence, rapid purchase and resale, a rapid mint-transfer-redemption loop, a new custodian, an external marketplace entering the chain, an unexpected payment source, and redemption or repayment events.

Use Smart-Contract Controls Without Treating Code as Compliance

Permissioned token contracts are one of the genuinely useful innovations in the RWA space — and one of the most over-credited. The distinction to hold onto: a smart contract can execute compliance restrictions, but it cannot perform due diligence or make an AML decision.

Controls a Smart Contract Can Enforce

Depending on the token structure, the contract layer can support wallet allowlisting, address blocking, transfer approval requirements, restrictions on unsupported wallets, investor-category flags, jurisdictional flags, holding limits, transfer limits, pause functions, role-based minting, role-based burning, compliance events emitted for the monitoring stack, and audit logs.

These are real controls with real value: they make the approved policy self-executing at the transfer level, which is more than traditional securities infrastructure can say. Some structures also provide for administrative transfer or token cancellation, though whether those powers can actually be used depends on the legal documentation, contractual rights, and applicable law — they are not a standard feature to assume.

Decisions That Still Require Off-Chain Review

Now the other side of the ledger. A smart contract cannot determine a person's real identity, a company's beneficial ownership, the authenticity of documents, the source of funds, the source of wealth, the business rationale behind a trade, the legal ownership of the underlying asset, whether a wallet's risk exposure is a false positive, whether enhanced due diligence is required, whether suspicious activity should be reported, whether a transfer restriction has a legal basis, or whether a new holder satisfies regulatory eligibility requirements.

Every one of those is a judgment that consumes off-chain information the contract cannot see. The allowlist entry is the output of that judgment, not a substitute for it. Code can enforce an approved compliance status, but it cannot determine whether that status should be granted.

Operational Review of an RWA Transfer

Pulling the threads together, here is how a compliance team works through an RWA transfer in practice.

1. Classify the transfer. Establish what is actually happening: a transfer between wallets of the same holder, a transfer to a new buyer, an institutional custody transfer, a marketplace trade, an off-platform transfer, a redemption, a repayment, or an administrative transfer. The classification sets the depth of everything that follows.
2. Identify the participants. Map the sender, the current legal or beneficial holder, the buyer, the receiving holder, the custodian, the broker, the marketplace, and any other intermediaries in the chain.
3. Verify wallet ownership or control. Confirm the link between each relevant wallet and its claimed participant. A previously unknown wallet is never assumed to belong to an existing customer.
4. Screen the token and payment wallets. Check the sending token wallet, the receiving token wallet, the payment sender, the payment receiver, the relevant transaction exposure, and any sanctions or high-risk connections.
5. Check holder and transfer restrictions. Confirm KYC/KYB status, UBO data, sanctions and PEP status, jurisdiction, investor eligibility, token-specific transfer restrictions, and any approvals the transfer requires.
6. Review the payment leg. Reconcile the payment amount, the settlement asset, the payment source, the payment wallets, the timing, the declared buyer and seller, and the economic rationale of the trade.
7. Make and document the decision. The realistic outcomes: approve, hold pending information, request additional documents, require a different wallet, reject, restrict, or escalate. Where the decision is hold, rejection, or escalation, it feeds into the standard high-risk transaction review and escalation workflow rather than an improvised process.
8. Update records and monitoring. Add the approved wallet, retain the ownership evidence, update the holder register, store the screening results, record the rationale, configure ongoing monitoring for the new address, and preserve the link between the token transfer and the payment transaction so the trade can be reconstructed later.

Common AML Gaps in RWA Tokenization

The failures below are specific to the RWA token lifecycle — they recur across platforms regardless of asset class:

• KYC is performed only before primary issuance and never revisited.
• The issuer and SPV are verified without analyzing UBOs and related parties.
• Investor eligibility is mistakenly used as a substitute for KYC.
• The verified investor is never linked to a specific wallet.
• A new wallet is accepted without proof of control.
• An approved wallet is never screened again.
• A corporate holder is checked without its directors, representatives, or UBOs.
• A custodial wallet is treated as belonging to one customer without confirming account ownership.
• The token transfer is reviewed, but the payment transaction is not.
• A stablecoin payment is automatically treated as low-risk.
• Off-platform transfers never enter the monitoring workflow.
• On-chain balances are not reconciled against off-chain holder records.
• A smart-contract allowlist is used as a replacement for ongoing AML review.
• A marketplace or custodian is assumed safe because it holds a license.
• Asset provenance is confused with blockchain source-of-funds analysis.
• The issuer, platform, and custodian never defined who owns an alert.
• A provider runs the screening, but nobody is responsible for the final decision.
• Transfer approvals and risk decisions are not preserved in an auditable record.

Most of these gaps share a root cause: a control that was designed for the moment of issuance, applied to a market where the asset keeps moving.

RWA AML Compliance Must Continue After Issuance

Tokenization moves the representation of an asset and the execution of its transfers on-chain. It does not move the things compliance actually depends on: identity, legal ownership, investor eligibility, and the judgment calls behind every approval remain largely off-chain. Initial KYC creates a starting point of control — nothing more. Every new wallet and every new holder can change the risk context; every secondary-market transfer is a separate compliance event; and a token movement can never be evaluated in isolation from the payment that settles it. Smart-contract controls, identity verification, wallet screening, and transaction monitoring only work as connected layers, each covering what the others cannot see. The central AML challenge in RWA tokenization is not verifying the first investor. It is preserving a reliable link between the eligible holder, the approved wallet, the token transfer, and the related payment throughout the asset lifecycle.

FAQ