The key to getting more institutions onchain: Rethinking KYC

“Know Your Customer” (KYC) checks are often seen as an obstacle to bringing traditional finance onchain and to growing DeFi overall.

For anyone unfamiliar, these checks are a necessary part of financial institutions’ obligations under the Bank Secrecy Act (BSA) to combat money laundering and terrorist financing. The process requires coordination among issuers, verifiers, and regulators with different incentives, timelines, and legal requirements.

For banks, broker-dealers, and other BSA-covered institutions bringing tokenized products onchain, the challenge is reaching more customers and accessing liquidity, while meeting compliance requirements that can add time and complexity. Onboarding a new customer, for example, often means repeating identity checks that were already completed somewhere else. Fortunately, new KYC tools designed specifically for blockchains may help make verification more reusable than methods we’ve inherited from traditional finance.

The starting point is understanding who an institution needs to identify. In traditional finance, institutions transact through networks of identified intermediaries, and each institution satisfies its own KYC obligations. The same principle applies onchain in that the bank’s customer-identification obligations apply to its own customers and not to every participant in the underlying settlement infrastructure.

Customer identification rules focus on who opens an account with the bank. On that reading, someone does not become the bank’s customer simply by transacting with one of its customers or by trading against a liquidity pool the bank supplies. A bank can satisfy its BSA obligations through an appropriate compliance program covering its own customers and transactions, regardless of which blockchain network or protocol settles them .

The U.S. Department of the Treasury is currently thinking through how financial institutions can use these new technologies and methods to satisfy AML/CFT program requirements, including for CIP/KYC. Given the passage of the GENIUS Act, regulators are now tasked with understanding and pursuing innovative methods and standards for meeting these modern AML/CFT objectives more effectively.

Below we take a look at the legal and practical conditions for reusable KYC, then explore how tools like zero-knowledge proofs, verifiable credentials, nontransferable tokens, and blockchain analytics could help. Finally, we look ahead to “Know Your Agent”: identifying AI agents, whom they represent, and what they’re authorized to do.

Adapting KYC for an onchain world

Traditional KYC happens institution by institution. Each verifies a customer’s identity at onboarding through its Customer Identification Program (CIP), keeps its own records, and conducts ongoing Customer Due Diligence (CDD). That record lives with the institution, which becomes a trusted intermediary. Customers have to repeat this process at each new institution, even when assets move between people and businesses whose identities have already been checked.

Blockchain transactions add another layer of complexity. Assets move across chains, protocols, and wallets, often without an intermediary performing KYC. A wallet might have originated from a BSA-obligated exchange, a DeFi protocol, or a consumer app. Each of these services has its own risk and liability frameworks, which may vary by jurisdiction. Some intermediaries have no KYC obligations at all. Even where KYC is required, there is no standardized regulatory framework to carry the result from one institution to the next. Institutions often repeat verification of the same user, adding cost and delays.

As former SEC Commissioner Peirce recently noted , “the approach to ferreting out illicit finance […] has been the same: collect more and more data. The approach is not working particularly well, and technology has outpaced our legacy approach, so it is time for a change.”

Financial institutions, blockchain developers, and regulators are now creating new methods for meeting KYC and AML/CFT goals. One approach is letting institutions reuse identity checks completed by others. For that to work, institutions need clear rules about whose checks they can trust and who is responsible for compliance.

Reusability and the ecosystem of trust

Users want to do KYC once and have it work everywhere, known interchangeably as reusable KYC , reliance KYC , federated KYC, or hosted KYC .

Customers repeat verification offchain as well. Someone opening accounts at two banks will need to complete KYC at each, but most customers do not form these relationships often. In crypto, however, users often onboard to new products, and there’s no trusted intermediary to carry the KYC through the life of a transaction.

Institutions do not want to avoid KYC; they want to avoid redundant KYC. Every time a user wants to interact with a new exchange or application, the KYC process starts from scratch, which is expensive for the platform, creates friction for the user, and is increasingly unreliable as deepfake tools proliferate. Banks and other BSA-covered entities have become burdened by identity verification methods that are costly, privacy-invasive, and ineffective at deterring illicit finance.

Institutions do not want to avoid KYC; they want to avoid redundant KYC.

Repeated verification can mean sharing sensitive personal information with more institutions. Even when presented digitally, a government ID can compromise a customer’s safety and increase the risk of targeted fraud, stalking, identity theft, and other unauthorized uses of that information. A mobile ID typically discloses a customer’s full legal name, residential address, date of birth, and photograph, all in one disclosure.

These “honeypots” of sensitive personally identifiable information (or PII) are tempting to financial criminal actors, and the stakes are high if any of this information is intercepted, mishandled, or held onto longer than necessary by the bank. As Coin Center has pointed out , the current system forces individuals to “repeatedly surrender their sensitive personal information to centralized databases at tremendous personal risk.” To avoid these unwarranted vulnerabilities, privacy advocates have urged regulators to consider alternative ways to digitally verify a customer’s identity beyond simply government-issued identification records.

A useful analog in traditional financial markets is SWIFT’s KYC Registry (although the name is something of a misnomer; it focuses on bank-to-bank relationships and is more accurately a KYB registry). Banks already use SWIFT, a global messaging network, to communicate cross-border payment instructions. And when SWIFT launched its KYC Registry in 2014, it extended that infrastructure to compliance: Banks upload their documentation once and share it with any counterparty that needs it. The registry now spans nearly 8,000 institutions across 200+ countries and works because the relationships are institution-to-institution and the counterparties are known.

Crypto has no equivalent centralized registry. If Coinbase has already verified a user to bank-grade standards, can that verification be inherited? If Robinhood’s KYC’ed users want to access an onchain credit protocol, can the compliance work that Robinhood already did travel with them?

This is known as “whitelisted liquidity.” Access to pools of pre-verified users is, in practice, a form of compliance distribution, but is not a legal requirement. An institution’s own obligations are the same whether its customers trade in a gated pool or a permissionless one. And for tokenized securities, gating a pool and setting standards for who may trade in it can itself carry regulatory obligations under the SEC’s recent innovation exemption. Issuers are already seeking introductions to global exchanges specifically to leverage their compliance frameworks, but the commercial structure is still being developed.

Outsourcing versus reliance

New solutions tailored to crypto can minimize harmful data collection and produce auditable, verifiable alternatives to the same old “box-checking” KYC. In fact, there are a growing number of examples of reliance KYC being used in the crypto space.

KYC reliance can also be described as an “ecosystem of trust,” where a larger KYC provider (or group of providers) with enough scale creates their own trust network, similar to the concept of “single sign-on.” Examples include providers such as Sumsub ID, World ID, MoonPay, and Stripe through Privy. Basic verification might run from $1 to $2 per initial verification charged to the originating platform, and then any secondary platforms only have to go through a partial KYC process (such as a liveness check), which reduces their cost per customer.

One recent example is the Fireblocks Open Transaction Layer (OTL), which is an open protocol stack that standardizes identity, compliance, and messaging across participants in onchain finance. Notably, KYC is done by existing regulated entities in the network, not by OTL itself. OTL creates a shared protocol so when one of those institutions has verified a user, that status can be recognized by other participants without re-verification.

A similar concept is Privado ID (formerly Polygon ID, which spun out from Polygon Labs in 2024 and recently merged with Disco.xyz), which makes existing KYC portable . Issuers, including government institutions, banks, and KYC providers, generate verifiable credentials. The user requests, collects, and stores this credential in their identity wallet. Verifiers can then query the user’s wallet for the appropriate credentials, whether offchain or onchain .

SpruceID offers another solution built around identity standards. Trusted sources, such as the DMV or a state licensing agency, issue verifiable digital credentials that users store on their phones. These tools make it easier to reuse verified information, but institutions still need to understand their legal responsibilities when using another provider’s work.

Institutions can use outside providers for KYC, but the legal treatment depends on the provider and the arrangement. Under the BSA’s customer-identification rules , “reliance” is a specific legal provision that applies only when relying on another regulated financial institution . Using a provider that does not qualify, such as an identity-verification vendor or credit bureau, is treated as outsourcing. In that case, the institution remains responsible for meeting its CIP requirements.

Similarly, the Financial Action Task Force (FATF), the international body that sets AML/CFT standards, recommends that countries may permit financial institutions to rely on third parties for certain customer due diligence measures if three conditions are met:

The third party is itself subject to AML/KYC regulation and supervision and has those compliance measures in place;

The relying institution has immediate access to the underlying KYC data on request; and

The relying institution retains ultimate legal liability for the compliance outcome.

This doesn’t always neatly map to crypto. First, the “immediate access” requirement means the underlying PII has to be producible on demand to a regulator or law enforcement. This is in direct tension with the privacy-preserving design of most onchain KYC solutions.

Separately, many crypto platforms are not “regulated institutions” for purposes of the federal AML/CIP reliance rule, even where they are registered money services businesses or state-chartered trust companies with their own AML obligations. This means they can’t be counterparties in a formal reliance relationship (although this is evolving as more crypto firms become licensed).

This is one of the hurdles Treasury will have to resolve when considering more flexible, crypto-native CIP methods. Decentralized methods may be more cost-effective and efficient, and may better protect user privacy and guard against cybersecurity breaches, but law enforcement will still need to have a trusted source, somewhere, for the truth (i.e., who the customer is and what entity can produce documentary evidence to further an investigation or prove attribution in court).

In addition to AML program requirements, financial institutions also have to consider their obligations under the Funds Transfer Rule, widely referred to as the “Travel Rule.” Any financial institution or virtual asset service provider (VASP), which in the U.S. would include BSA-covered institutions that transfer funds above a certain threshold (typically $3,000, although other jurisdictions set a lower threshold amount), must collect and transmit identifying information about both the sender and the recipient to the next institution in the chain. In traditional finance this is straightforward because banks already hold KYC data and have established messaging rails such as SWIFT to pass it through. In crypto, the blockchain transaction and the KYC information travel separately.

Many established providers offer crypto-specific Travel Rule compliance solutions. Examples include the industry-led Travel Rule Universal Solution Technology (TRUST), originally launched by an industry coalition including Coinbase, and similar products from Notabene and Sumsub.

In the U.S., Travel Rule messaging is only required between financial institutions. Financial institutions and VASPs are not expected to send this data to parties that are neither financial institutions nor VASPs, such as self-hosted wallets.

Financial institutions should not lose sleep over Travel Rule compliance when interacting with non-intermediary blockchain technology such as DeFi and self-hosted wallets. A bank or crypto exchange may still ask customers for this information for transactions to and from self-hosted wallets or outside of BSA-covered institutions. It may do so as part of its own risk-based AML/CFT program, but the Travel Rule does not require this.

Financial institutions should not lose sleep over Travel Rule compliance when interacting with non-intermediary blockchain technology such as DeFi and self-hosted wallets.

That said, non-U.S. jurisdictions have considered and may take a different position with respect to threshold amounts for triggering the rule and whether VASPs must collect data from non-VASP entities or persons. Jurisdictions are still working out how to apply KYC, AML, and Travel Rule requirements onchain.

The good news is that new, affirmative legislation is unnecessary in the U.S. Existing laws and frameworks can be adapted through interpretive guidance, rulemaking, or innovation exemptions. Congress has already endorsed the basic allocation of responsibility described above. The GENIUS Act places AML and sanctions obligations on the permitted stablecoin issuer, the identifiable entity at the application layer, and not on the permissionless networks its stablecoins circulate on. Regulators have also recognized the role new technologies can play in compliance. In its April 2026 proposal, FinCEN identified “machine learning, generative artificial intelligence (GenAI), digital identity, blockchain monitoring and analytics, or application programming interfaces (APIs)” as relevant innovative approaches to meeting regulatory obligations.

New, affirmative legislation is unnecessary in the U.S. Existing laws and frameworks can be adapted through interpretive guidance, rulemaking, or innovation exemptions.

In the same proposal, FinCEN expressed support for financial institutions’ adoption of emerging tech, stating that institutions that “responsibly experiment with innovative technologies in their AML/CFT programs will not incur any additional risk of being subject to a significant supervisory AML/CFT action or AML/CFT enforcement action solely based on the use of innovative technologies.” To give institutions more certainty about how this applies in practice, the crypto industry has urged FinCEN and supervisory banking agencies to concretely confirm through rules or written guidance when forms of digital identity can be used to meet AML program requirements, including for CIP/KYC.

Even with clearer guidance, not every KYC determination can be reduced to a binary cryptographic proof. Such proofs may help confirm a birth date, citizenship, the result of a sanctions check, or possession of a credential. But more complex, judgment-intensive AML inquiries may still require traditional diligence.

Verifiable credentials could support or replace particular components of CIP/KYC rather than eliminate risk-based customer due diligence altogether. Treasury’s current rules already allow non-documentary verification methods and leave the mix of methods to the bank’s risk-based judgment. The September 2026 interagency FAQs expressly recognize that qualifying verifiable digital credentials can be used within a bank’s CIP, though they do not approve every decentralized identifier or credential design.

FinCEN and the relevant banking agencies could build on this guidance under existing authority. Options include interpretive guidance or additional FAQs, targeted exemptions, pilot programs followed by regulatory approval, standards for credential issuers, or amended regulations. These approaches could allow traditional financial institutions and other qualified public or private entities to issue verified credentials under common standards, reducing the need for each bank to independently reconstruct the same identity file.

Until then, financial institutions can already adopt tools that meet current requirements. The following approaches show how this could work.

The solutions

Institutions could benefit from a trusted, compliant backend that makes identity reusable across onchain applications. A trusted provider could verify a customer’s identity and issue a digitally signed credential recording the result. The customer could then present that credential to other applications, which could check who issued it and whether it meets their own verification requirements.

This isn’t a new concept. It goes back at least to the idea of the soulbound token Vitalik Buterin outlined in 2022, where a nontransferable token is issued to a person’s wallet. Related work includes W3C’s work on decentralized identifiers (DIDs) and verifiable credentials (VCs), which is not specific to crypto.

In practice, a trusted issuer, such as an “approved” or regulated KYC provider, a bank, or potentially a government, could verify a user’s identity and issue a credential. That credential could be stored in the user’s wallet and selectively disclosed to any application that requires it.

Likewise, zero-knowledge proofs allow users to prove they are KYC’ed without revealing their PII, adding privacy to this process. With these, users could reuse the credential where it meets the receiving institution’s CIP requirements, potentially reducing repeated checks.

Verification also needs to be composable, meaning applications can incorporate it into their own compliance checks. More specifically, to be most effective, issuers and platforms should be able to embed that logic in the token contracts and application-level smart contracts they control. This would allow them to apply their compliance requirements without bolting them on or pushing them down into the base layer network.

Approaches

Other viable tools for satisfying the necessary aspects of financial institutions’ risk-based AML program requirements are “Know Your Wallet” (KYW), “Know Your Asset” (KYA), and “Know Your Transaction” (KYT). These methods are already used by many exchanges and money transmitters as part of their overall AML program.

Know Your Wallet

Know Your Wallet connects identity checks to the blockchain address a customer uses, helping institutions establish who controls it and which assets or services that customer is eligible to access. KYW can combine:

Identity binding , linking a real-world identity to a wallet address, usually through a KYC check at onboarding;

Liveness and uniqueness , confirming the identity is real, human, and not duplicated across wallets, including a periodic refresh of the linkage to ensure that this is the same real-world identity linked to the same wallet address; and

Eligibility/permissions , meaning a wallet, once confirmed, has specific permissions (Is it accredited/qualified? Is it in a permissible jurisdiction? Is it flagged to hold certain asset types?). This is the compliance eligibility layer.

Crypto KYC largely follows the traditional playbook. Companies like Onfido, Veriff, Trulioo, Socure, Incode, ID.me, Persona, Sumsub, and Sardine offer identity binding and document verification, liveness detection, and AML screening. These identity checks generally take place offchain and do not, by themselves, establish which blockchain address a person controls. Linking the verified identity to an address is an additional step (although Sumsub has started to expand into wallet-based KYC by allowing users to link their wallet addresses).

Onchain applications can use nontransferable tokens to record verification results, zero-knowledge proofs to limit disclosure of personal information, and proof-of-personhood systems to help verify that each user is a unique human. These approaches can work together.

The approach uses nontransferable, non-sellable tokens, often called soulbound tokens, which are permanently attached to a specific wallet address. In a KYW system, a provider could verify a user’s identity offchain and then issue a token to their wallet as a record of that verification. One solution, Quadrata, generates a soulbound token to check for attributes like country and age.

These tokens can make it easier to verify audit records, but nontransferability alone does not prevent another person from taking control of the wallet. For instance, if someone’s wallet is transferred, the token may no longer identify the person controlling it. Systems also need mechanisms for credential expiration and revocation. Those capabilities depend on the implementation; Quadrata, for example, supports issuer-controlled revocation.

A related approach embeds compliance conditions in asset tokens. DTCC’s ComposerX , a tokenization platform for financial institutions, uses the Compliance Aware Token Framework (CATF) to enforce regulatory and transaction rules as transactions execute. This allows asset transfers to depend on compliance conditions being met.

Other startups, such as Burrata, aimed to issue identity tokens as well, and while this was technically viable, they were “ unable to find product market fit” and shut down.

Zero-knowledge proofs address another facet of the problem, allowing a user to prove a claim about their identity without revealing the underlying data. There are a number of solutions that issue a ZK proof from an ID scan.

Self.xyz offers privacy-preserving “pre-KYC,” where users scan their physical passport and generate a zero-knowledge proof of the passport data, proving attributes such as someone being over 18 and not on a sanctions list. It is useful as a gating layer before formal KYC, saving time by screening out bots or sanctioned wallets.

Aztec, a privacy-focused Layer-2 blockchain on Ethereum, acquired zkPassport, which has a similar approach of scanning one’s passport to generate a ZK proof.

Opacity Labs takes a different angle with Zero-Knowledge Transport Layer Security (zkTLS); their Verified Data Network (VDN) enables a verifiable attestation of any web2 fact (e.g., account ownership or transaction history) that is then portable onchain, without disclosing the underlying data.

Finally, proof-of-personhood takes a different approach. Rather than verifying who someone is, one simply verifies that the wallet is controlled by a unique, living human.

World ID proves unique personhood via biometrics (iris scans) captured by its proprietary hardware, the Orb. The Orb captures an iris image, which is then encrypted, sent to the user’s phone, and subsequently deleted from the Orb. The resulting hash is then compared against all other stored hashes to confirm unique verification. The user’s World App generates a key pair, and when a user wants to prove they’re a unique human, they generate a ZK proof to do so.

When coupled with identity binding (to prove the identity of the unique human), personhood checks are a powerful tool to combat deepfakes and could help reduce impersonation in certain situations, for example, opening a bank account. World’s Zoom partnership brings this solution to market by referencing a user’s video feed against their World ID and, if matched, adds a “verified human” badge to their Zoom profile. Another solution is Human Passport, which started as a system for protecting Gitcoin grants. It offers a modular stack for identity verification as well as Sybil defense.

Note that proof of personhood addresses issues like Sybil attacks and deepfakes rather than any regulatory identity requirements and must still be coupled with other KYC approaches to be a complete solution.

These approaches focus on the person behind a wallet. The asset itself raises another set of compliance questions, including where it came from and what restrictions apply to who can hold or transfer it.

Know Your Asset

Where KYW asks who is holding this asset, KYA asks what this asset is permitted to do, and with whom.

Generally, AML laws paint in broad strokes. The BSA is not concerned with the type of asset involved, which usually only implicates market regulator assessments for appropriate treatment: Is it a security, a commodity, and so on? But KYA can be a very important method for FIs assessing risks across a variety of different compliance rules. KYA points to origin, meaning how the asset was created or originated and who created it, including verification of its compliance characteristics both at issuance and throughout its lifecycle.

The most straightforward implementation is to build transfer restrictions into the token contract at issuance. RWA tokenization platforms such as Securitize embed compliance at the token level. When they issue BlackRock’s BUIDL or Apollo’s ACRED, the token contract itself enforces that transfers can only occur between allowlisted wallets. The asset doesn’t rely on an external gating layer; the token contract enforces specified transfer restrictions. This means the contract rejects transfers that fail its eligibility checks. Ondo’s OUSG and Superstate’s USTB follow a similar pattern: Transfer hooks check an onchain allowlist on every transaction, and both the sender and receiver must be verified before settlement occurs.

The unresolved question in KYA is provenance : Verifying not just what a token is, but where it came from. A token issued by a regulated platform with clean KYA has a clear origin story. But as tokens move across bridges, get wrapped, or serve as collateral in DeFi protocols, that provenance trail degrades. Issuance can provide a clear starting record; maintaining and interpreting that record across subsequent activity remains an open problem, and one that connects directly to the Know Your Transaction methods below.

However, this is more of an operational problem rather than a liability trap. The Office of Foreign Assets Control (OFAC), the financial intelligence and enforcement agency of the U.S. Department of the Treasury, does not treat an institution as inheriting the sanctions status of every address an asset has passed through. Blockchain analytics distinguish direct exposure (an asset received directly from a designated address) from attenuated, multi-hop exposure. Institutions manage the latter with risk thresholds, quarantine, and suspicious activity reporting, not by refusing assets that have moved through permissionless infrastructure.

Know Your Transaction

KYT helps institutions assess the risks above by tracking the relationships between different wallets and mapping the flow of an asset across these wallets.

Transaction monitoring is an essential tool financial institutions use to observe customer behaviors and identify suspicious activity that may require reporting. For a specific asset, KYT could include mapping its transaction history across its entire lifecycle, showing which wallets and protocols it has touched. In effect, KYT focuses the scrutiny on the transactions themselves, rather than or in addition to focusing on the person or entity making the transaction. This is particularly useful for meeting ongoing CDD and EDD requirements.

Blockchain analytics, such as Chainalysis, Elliptic, and TRM, among others, can track relationships between different wallets and trace funds through and across blockchains and protocols. Coupled with the use of onchain and offchain data and newly developing AI tools, the technology offered by these firms assists financial institutions in meeting BSA and sanctions compliance obligations for blockchain transactional activity.

Examples of AI tools used for these purposes are Eunice.ai, which tackles risk monitoring and disclosure with their asset classification framework; Didit, which provides screening and transaction monitoring to enable real-time risk analysis on a per-wallet basis; and Sardine , which performs initial screening as well as daily ongoing transaction monitoring.

In addition to KYW, KYA, and KYT, some blockchains and protocols offer built-in compliance controls. We discuss those below.

Blockchain-level solutions

Both permissioned and permissionless blockchains increasingly offer more tools to control access and protect privacy. These can block transactions until certain conditions are met and keep sensitive information confidential while allowing regulatory oversight.

The BSA and sanctions laws do not require permissioned validators, identification of every network participant, or access controls across the network. Institutions remain responsible for their own customers and transactions, whichever network they use. They can choose among the designs below based on business and product needs, provided they meet those compliance obligations.

The BSA and sanctions laws do not require permissioned validators, identification of every network participant, or access controls across the network.

For example, on Canton, a public permissioned network, compliance and smart contract logic are deeply interwoven. This is due to its sub-transaction privacy model: Transaction details are only revealed to specific parties with a “need to know.” As another example, Circle’s Arc has a validator model where the validator set is permissioned, but the chain itself is public. Validators are identified participants who have gone through KYC/KYB. On a permissionless network, by contrast, the protocol chooses the validator for each transaction. Processing the transaction does not make that validator a counterparty to the institution or its customer.

Some permissionless protocols also offer features enabling access to permissioned pools or baking in gateways or rules for institutional users to control access. Solana offers a way for RWA issuers to enforce KYC/AML compliance at the token level through token extensions, specifically “transfer hooks.” Every transfer triggers a check against an onchain allowlist and checks that both the sender and receiver are on the allowlist. If either isn’t verified, the transfer fails at the token level, enforced onchain while the network remains permissionless. The allowlist itself is typically generated in the traditional offchain way.

Uniswap’s v4, a permissionless protocol, has its own “hooks,” which enable custom logic that can be attached to specific points in the swap lifecycle. This allows the creation of permissioned pools. The tokens themselves remain permissionless; it’s the pool that is gated. A gated pool deployed by a third party does not make the protocol permissioned; the party that deploys the pool and sets its access rules is the one that takes on any resulting obligations. Hyperliquid has begun to test features allowing HIP-3 deployers to restrict trading to approved addresses only.

Morpho, a decentralized lending platform, lets users and market participants set up their own compliance controls. The protocol itself does not perform KYC or identity verification. In Morpho Blue, its variable rate credit protocol, compliance can be enforced at the asset level when markets use permissioned or whitelisted tokens (such as kycUSDC) as collateral, ensuring that only verified users interact with that specific market.

With Morpho Midnight, an intents-based fixed rate credit protocol, and Morpho Vaults V2, permissioning can be applied with greater flexibility and capital efficiency. Morpho Vaults V2 allows independent curators to implement custom permissioning gates as entry/exit conditions to restrict lender profiles, enabling capital to be allocated to borrowers with specific compliance profiles across the network. This modular design allows institutions that prefer to transact only with verified counterparties to do so through permissioned markets and vaults, while preserving liquidity efficiency across the broader protocol ecosystem. That is a product and risk-appetite choice: an institution’s own compliance obligations do not depend on whether the other participants in a shared market have been verified.

Crosschain compliance propagation

Permissioning governs who can participate in a particular market or vault. When assets move between blockchains, issuers and applications face another challenge: Sharing relevant compliance information so they can apply consistent rules across networks.

LayerZero, for example, allows for the crosschain propagation of “compliance state” so that the compliance logic doesn’t have to be rebuilt and maintained separately on each chain. Their Omnichain Fungible Token (OFT) standard supports custom logic hooks, so issuers can embed KYC/allowlist checks that must go through on both the source and destination chain before the transfer settles.

LayerZero V2 introduced configurable Decentralized Verifier Networks (DVNs), the entities that validate crosschain messages. A DVN could be configured to enforce compliance checks; for example, whether or not KYC has been performed on a user or wallet owner, screening addresses and other data against sanctions lists, or determining whether Travel Rule metadata is attached before a message is considered valid.

Chainlink also provides a way to link offchain verification with onchain enforcement needs by routing data from various KYC providers onto the blockchain, via Chainlink’s Automated Compliance Engine (ACE). This also functions as a reusable KYC through the concept of a CrossChain Identifier (CCID) , which links a user’s wallets across blockchains: Credentials are verified/attached once and then can be accessed multiple times.

The bigger picture

These tools address different parts of onchain compliance. Putting them into practice means connecting them with existing compliance programs and finding ways to bring tokenized products to customers.

Partnering with exchanges that have established compliance programs may be the simplest near-term way for institutions to reach more customers. But that is not a compliance requirement. Issuers can also build controls into the tokens themselves, as BUIDL, OUSG, and USDC do in different ways, allowing assets to move on public blockchains subject to those controls.

The next opportunity is to make compliance checks easier to reuse across DeFi. That means enabling an institution or application to assess verified information from another provider against its own requirements. Building this will likely depend on shared protocol standards, compliance-focused software providers, and distribution through incumbents who already hold KYC’ed user bases.

What’s next? Know Your Agent

Reusable credentials can help establish who a customer is. When an AI agent transacts onchain, manages a vault, or makes payments for a customer, institutions also need to establish who authorized the agent and what it is allowed to do. Know Your Agent extends the discussion to the software acting on a customer’s behalf and the limits of its authority.

Just as humans need credit scores to get loans, agents will need cryptographically signed credentials to transact. This is the emerging Know Your Agent framework: The equivalent of KYC for agents. Without a robust Know Your Agent framework, the answer to the question of who is liable is the untenable and uncomfortable “nobody and everybody.”

Just as humans need credit scores to get loans, agents will need cryptographically signed credentials to transact.

Know Your Agent frameworks require a new kind of credential, one that attests what an agent is authorized to do, on whose behalf, and within what constraints. Each agent must be identifiable and registerable (to a human or business), carry a reputation, and have its constraints validated before it can interact with regulated financial rails. Some solutions work onchain, others offchain, but they increasingly use the same cryptographic primitives, including RFC 9421 signatures and W3C Verifiable Credentials.

Onchain

ERC-8004, deployed to Ethereum mainnet in January 2026, is one of the first significant blockchain standards for agent identity and attracted more than 30,000 registrations in its first week. It provides a shared onchain system for registering agents, tracking their reputations, and recording independent checks of their work. Each agent has an ERC-721 token minted, which resolves to the agent’s registration file. The onchain history is resistant to tampering and accessible to other applications, reducing dependence on any single platform.

Self.xyz now has Self Agent ID , which builds on this standard. Self Agent ID, an onchain identity registry, binds AI agent identities to Self human proofs. Each agent has a nontransferable NFT backed by a passport verification, giving applications a reusable way to check that a real person is behind the agent.

Benefits of onchain Know Your Agent approaches include immutability and credible neutrality, as well as composability.

Offchain

Many approaches use offchain credentials and signed messages to identify agents and define their permissions, even when payments happen onchain. The examples below address different parts of agent activity, including proving authorization, enforcing spending limits, and protecting the keys used to sign transactions:

Google’s Agent Payments Protocol (AP2) uses signed “mandates” to record a user’s instructions, including spending limits and purchase conditions. These provide verifiable evidence of what an agent is authorized to do.

Catena Labs’ Agent Commerce Kit provides tools for agent identity, authorization, and payments. Its proposed ACK v2 uses signed grants that specify who authorized an agent and what it can do. Each request includes the grant and a standard HTTP message signature, defined in RFC 9421.

Skyfire’s KYAPay lets agents identify themselves, show who they represent, and make payments using signed digital credentials called JSON Web Tokens (JWTs). Skyfire also works with Experian’s Agent Trust framework to connect agents with verified consumers and devices.

Circle’s Agent Wallets focus on custody and spending controls. Signing-key shares remain hidden from the agent, while users retain custody. Agents can transact autonomously within spending limits and recipient restrictions set by the user.

Anchorage Agentic Banking gives each agent credentials tied to a specific user and organization, with permission to spend from designated budgets. Transactions are logged under the agent’s identity, and its access can be revoked.

Mastercard’s Agent Pay registers agents and connects their payments to consumer consent and tokenized payment credentials. Its partnership with Cloudflare uses signed web requests to help merchants authenticate agents visiting their sites.

Visa’s Intelligent Commerce replaces card details with digital payment tokens that confirm an agent has permission to act for a consumer. Consumers set spending limits and conditions for purchases.

Zero Hash’s Agentic Finance Suite screens agents and the people or businesses behind them before allowing transactions. It also lets users delegate permissions and control what each agent can do.

Ledger is building tools that connect agents to secure hardware and the humans who authorize them. Its roadmap combines agent identity, hardware-enforced spending rules, and human approval for sensitive actions.

Delegating financial activity to agents adds questions about authorization and control, bringing the discussion back to how institutions apply compliance checks within the products and services they provide.

***

Bringing finance onchain opens up opportunities to improve how compliance works. Reusable credentials could reduce repeated identity checks, transaction monitoring can help institutions identify suspicious activity, and controls embedded in tokens and applications can enforce specific eligibility requirements. Together, these tools could help institutions reach more customers while meeting their KYC and AML/CFT obligations.

Financial institutions can build the controls they need into the products and services they provide on public networks. The next step is to make those controls easier to connect and reuse across products, protocols, and blockchains. That would give institutions a clearer path to launching new products on public blockchains, with fewer repeated checks for the customers using them.

***

Acknowledgements: Thank you to Tim Sullivan, Steph Zinn, Sonal Chokshi, David Sverdlov, Miles Jennings, Kate Dellolio, Mina Kim, Guy Wuollet, and Liz Harkavy.

***

The views expressed here are those of the individual AH Capital Management, L.L.C. (“a16z”) personnel quoted and are not the views of a16z or its affiliates. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by a16z. While taken from sources believed to be reliable, a16z has not independently verified such information and makes no representations about the current or enduring accuracy of the information or its appropriateness for a given situation. In addition, this content may include third-party advertisements; a16z has not reviewed such advertisements and does not endorse any advertising content contained therein.

This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by a16z. (An offering to invest in an a16z fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Andreessen Horowitz (excluding investments for which the issuer has not provided permission for a16z to disclose publicly as well as unannounced investments in publicly traded digital assets) is available at https://a16z.com/investments/ .

Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://a16z.com/disclosures for additional important information.