Executive Summary

Stablecoin compliance for banks extends existing AML, sanctions, payment-transparency, and audit controls into transactions that settle on public blockchains. The precise requirements depend on what the bank does with the asset: using a third-party stablecoin for payments or treasury creates a different compliance perimeter from providing safekeeping or issuing a stablecoin. Across these models, banks need to connect KYC/KYB with wallet attribution, AML/KYT screening, Travel Rule information, transaction policies, approvals, and records that explain why each transfer proceeded.

This guide covers those requirements through three operational pillars: AML/KYT, the Travel Rule, and audit readiness. It addresses compliance, risk, treasury, and operations teams evaluating stablecoin payments, custody, treasury activity, or issuance, with particular attention to how existing banking controls translate into wallet-based workflows. That translation matters because blockchain infrastructure adds new transaction data and faster settlement while leaving the institution responsible for the policies, providers, and decisions governing the activity.

The 2026 Regulatory Landscape for Bank Stablecoin Activity

Stablecoin compliance starts with defining the bank's role because regulation attaches different obligations to issuance, safekeeping, payments, and other activities. A bank using an externally issued stablecoin does not automatically assume an issuer's reserve obligations, while a bank providing safekeeping must address key management and custody controls alongside financial-crime requirements. Establishing that perimeter first keeps the compliance program aligned with the service the bank actually provides.

Key Takeaway: Stablecoin activity does not create one universal compliance model for banks. The bank's role determines which issuer, custody, AML/KYT, Travel Rule, governance, and reporting requirements apply.

Bank Role and Regulatory Scope

U.S. regulation illustrates why role definition matters. The GENIUS Act establishes a federal framework for payment stablecoin issuance and restricts issuance to permitted payment stablecoin issuers, which must maintain eligible reserves on at least a one-to-one basis, establish redemption procedures, publish reserve information, and comply with applicable BSA requirements. Those obligations follow the issuer role rather than every institution that happens to hold or transfer a stablecoin.

Banks can also participate in stablecoin activity without becoming issuers. The OCC has reaffirmed that national banks and federal savings associations may provide crypto-asset custody and engage in certain stablecoin activities for permissible payments, provided they manage the activity safely and in accordance with applicable law. It has also confirmed that permissible crypto custody and execution functions may involve third-party providers when the bank applies appropriate third-party risk management.

The European Union applies a different regulatory structure. MiCA sets requirements for issuers of asset-referenced tokens and e-money tokens, while the Transfer of Funds Regulation governs information accompanying covered crypto-asset transfers. A bank operating across several jurisdictions therefore needs to map the legal role, asset, transaction type, and counterparties before configuring the controls behind the flow.

How Stablecoin Compliance Differs from Traditional Crypto and Fiat AML

Existing bank AML controls provide the foundation for stablecoin compliance, but wallet-based transactions introduce information that conventional account monitoring does not capture on its own. Customer due diligence identifies the person or business behind the relationship; blockchain activity adds addresses, transaction histories, asset movements, and exposure to external wallets. The compliance process needs to connect those two views rather than treat the blockchain as a separate payment environment.

U.S. banking agencies make that continuity explicit for crypto-asset safekeeping. Existing BSA/AML, CFT, OFAC, and Travel Rule requirements continue to apply, including identity verification, customer due diligence, ongoing monitoring, suspicious-activity reporting, and sanctions controls. At the same time, the agencies recognize that distributed-ledger design can make compliance more complex when identifying information sits outside the transaction itself.

FATF also points to risks around peer-to-peer transfers through unhosted wallets and cross-chain activity, where regulated intermediaries may have less visibility into the parties or transaction history involved. Those characteristics explain why stablecoin compliance programs extend beyond account-level monitoring into wallet attribution and blockchain analytics.

Pillar 1: AML/KYT - Screening Customers and Transactions

AML/KYT connects customer identity to the onchain activity surrounding a stablecoin transaction. KYC and KYB establish who the institution serves, while KYT adds information about the addresses, transaction history, counterparties, and risk exposure involved in moving the asset. The bank then needs policies that translate those signals into decisions before and after funds move.

Key Takeaway: KYC/KYB and KYT solve different parts of the same compliance problem. Banks need enough customer and wallet context to distinguish activity that can proceed automatically from transactions that require further review.

KYC and KYB

KYC and KYB remain the starting point because blockchain analytics cannot replace verified identity, beneficial ownership, or an understanding of the customer relationship. Stablecoin activity adds a requirement to connect that customer record with the wallets and expected transaction patterns associated with the service. That connection gives later KYT alerts enough context to support a compliance decision.

A risk-based process should connect four elements:

• Customer or business identity. Verify the person or entity and relevant beneficial owners through the institution's existing KYC or KYB procedures.

• Expected activity. Establish the purpose of the relationship, expected transaction behavior, relevant geographies, and other factors that inform the customer risk profile.

• Wallet attribution. Associate relevant blockchain addresses with customers or counterparties when the operating model requires that relationship to be established.

• Ongoing review. Reassess the customer and associated activity when behavior, counterparties, geography, or other material risk indicators change.

Wallet attribution gives transaction monitoring a bridge between an external blockchain address and an internal customer record. Without that connection, teams can screen a transfer while still lacking the context needed to understand whether it fits the customer's expected activity. KYT adds that transaction-level layer.

KYT and Blockchain Analytics

KYT evaluates the onchain context around the funds and addresses involved in a stablecoin transfer. Depending on the provider and configuration, blockchain analytics can support source-of-funds analysis, destination screening, exposure assessment, and ongoing monitoring of wallet activity. FATF's focus on unhosted-wallet and cross-chain risks reinforces the need to look beyond the immediate sender and recipient when the institution's risk framework calls for broader analysis.

The analytics result still needs an institutional decision behind it. Risk scores and address labels do not determine a bank's risk appetite, escalation thresholds, or treatment of indirect exposure. Those rules need to reflect the bank's customers, products, corridors, transaction sizes, and regulatory obligations, particularly as transaction volume increases.

Utila for Banking Compliance: Utila integrates Chainalysis for real-time KYT data within wallet workflows, TRM Labs for risk insights on incoming and outgoing transactions, and Elliptic for source-of-funds and destination-wallet screening. Screening results can feed transaction policies before funds proceed.

That placement matters because identifying risk after settlement gives the bank fewer options than evaluating it before transaction authorization. Sanctions screening makes the same distinction particularly clear.

Sanctions Screening

Sanctions controls for stablecoin activity need to cover customers, counterparties, and relevant wallet exposure rather than depend solely on an exact address match. OFAC confirms that digital currency transactions carry the same sanctions obligations as transactions in fiat currency, while its published digital currency addresses do not represent an exhaustive list of addresses associated with blocked persons. OFAC guidance specifically points to blockchain analytics and historical lookbacks as tools that can identify links beyond listed addresses.

That creates three distinct screening points:

• Customer and counterparty screening. Screen relevant parties against applicable sanctions lists during onboarding and as information changes.

• Pre-transaction screening. Evaluate outgoing destinations and relevant wallet exposure before authorization when the bank's policy requires a block or escalation.

• Ongoing screening. Reassess customers and historical activity when sanctions lists, wallet attribution, or other risk information changes.

An effective sanctions process connects the screening result to a defined transaction outcome. A match or material exposure may require a block, hold, investigation, or escalation depending on the applicable sanctions regime and the institution's procedures. Transaction monitoring then extends that logic beyond individual sanctions signals into patterns of behavior.

Transaction Monitoring

Transaction monitoring needs to evaluate behavior in context rather than measure coverage by the number of alerts generated. Rules that ignore the institution's customer base, product, geography, and risk appetite can generate large volumes of low-value alerts while missing combinations of activity that only become meaningful when viewed together. Stablecoin monitoring therefore benefits from combining direct transaction signals with broader customer and wallet behavior.

That distinction becomes more important as payment volume grows. A customer may trigger no material concern through a single transfer while showing a different risk profile when onboarding information, rapid movement across several wallets, counterparties, geographies, and previous alerts are considered together. Compliance teams need the underlying context quickly enough to decide whether the transaction follows policy or requires human review.

Automation can support that model when the bank defines the rules first. Low-risk activity can proceed under approved policy, while higher-risk cases route to the appropriate reviewer with the relevant customer, wallet, screening, and transaction information attached. That approach keeps human judgment concentrated on exceptions rather than turning every onchain transfer into a manual compliance event.

AML/KYT Control Gaps

AML/KYT controls lose effectiveness when customer information, blockchain analytics, and transaction policies operate in separate workflows. Screening an address without customer context can produce a technically accurate risk signal that gives an analyst little basis for deciding what to do with it. Running the same screening only after settlement weakens the institution's ability to prevent an out-of-policy transfer.

Static controls create a second gap because wallet and counterparty risk can change after onboarding. Effective monitoring needs to incorporate new risk information and connect it to the same policies that govern execution. Once the bank can establish who participates in a transfer and whether the transaction meets its risk requirements, the Travel Rule adds the information exchange required between regulated counterparties.

Solution

Utila for Banks

Digital asset & stablecoin infrastructure for financial institutions.

View Solution page

Pillar 2: Travel Rule - Accounting for Originator and Beneficiary Data

The Travel Rule governs originator and beneficiary information for qualifying transfers, while blockchain settlement creates a practical separation between the movement of the asset and the exchange of customer information. Banks therefore need to determine when the rule applies, what information must accompany the transaction, how that information reaches the counterparty, and how exceptions affect execution. The requirements become particularly important across jurisdictions and when self-hosted wallets enter the flow.

Key Takeaway: Stablecoins do not require banks to put personal information on a public blockchain. Travel Rule implementation uses a separate messaging layer, but the compliance data still needs a reliable connection to the underlying transaction and the institution on the other side.

Travel Rule Requirements

Banks already handle comparable originator and beneficiary information across conventional payment systems, so the underlying compliance concept does not begin with digital assets. In the United States, FinCEN's Funds Travel Rule requires specified information to accompany covered transmittals of $3,000 or more. U.S. banking agencies also expressly identify the Travel Rule among the requirements relevant to crypto-asset safekeeping.

Blockchain transfers change the delivery mechanism rather than the purpose of the information. The EU Transfer of Funds Regulation explicitly allows the required originator and beneficiary information to travel separately from the crypto-asset transaction, provided the information reaches the relevant provider in the required timeframe. That separation protects sensitive customer information from unnecessary publication on a public ledger while preserving the regulatory record around the transfer.

The bank still needs to link the two records reliably. Transaction identifiers, customer information, wallet addresses, and the Travel Rule message should support a traceable relationship between the payment and the information exchanged about it. Jurisdiction then determines which workflow applies.

Jurisdictional Thresholds

Travel Rule implementation differs materially across jurisdictions, particularly around thresholds and self-hosted wallets. A global stablecoin payment program therefore needs jurisdiction-aware logic rather than one threshold applied to every corridor. The examples below show why transaction routing and compliance configuration need to account for local rules.

Thresholds determine part of the workflow, but they do not solve the information exchange itself. The bank also needs a messaging mechanism that can reach the counterparty institution securely. That makes interoperability a practical selection criterion for Travel Rule infrastructure.

Travel Rule Protocols

Travel Rule protocols provide the communication layer through which regulated institutions exchange originator and beneficiary information. Several protocols and networks have developed different architectures, while IVMS101 provides a common data model used across multiple implementations. Banks should evaluate reach, interoperability, security, and counterparty coverage rather than assume that adopting one protocol guarantees communication with every institution.

A common data standard helps, but counterparty reach still determines whether information can move in practice. Travel Rule implementation therefore extends beyond an internal database or compliance rule; it depends on communication with another institution. The workflow also needs a defined outcome when that institution cannot receive the expected message.

Self-Hosted Wallets

Self-hosted wallets require a separate decision path because a regulated counterparty may not exist on the other side of the transaction. The EU, for example, requires CASPs to collect relevant originator and beneficiary information for transfers involving self-hosted addresses and, above €1,000, take measures to assess whether the client owns or controls the address. Hong Kong similarly requires information collection for transfers involving unhosted wallets and rejects sole reliance on a customer declaration as proof of control.

Those requirements show why wallet attribution and Travel Rule controls need to interact. A blockchain address can identify the technical destination without establishing who controls it, while customer information alone cannot prove that a particular address belongs to the customer. The institution needs procedures appropriate to the jurisdiction and risk level for connecting those records.

FATF continues to identify peer-to-peer stablecoin transfers through unhosted wallets as an area of illicit-finance risk because they can occur without a regulated intermediary applying CDD and transaction monitoring. That does not make every self-hosted-wallet transfer high risk, but it does support differentiated controls rather than treating hosted and self-hosted counterparties identically.

Product

Wallet-as-a-Service

Build any application on top of our secure multi-chain wallet infrastructure.

View Product page

Travel Rule Implementation Gaps

Travel Rule problems often appear between systems rather than inside the rule itself. A bank may hold complete customer information but still lack a compatible route to the beneficiary institution, receive incomplete data from a counterparty, or need to determine what evidence supports control of a self-hosted wallet. Each case requires an operational decision before the compliance record can close.

The FCA provides a useful example of that responsibility model. UK firms remain responsible for Travel Rule compliance when they use third-party suppliers, and they must apply risk-based procedures when counterparties cannot receive or provide the required information. Technology can carry the message, but the institution still owns the decision about whether the transfer should proceed.

Those decisions also become part of the evidence a bank may later need to reproduce. AML/KYT shows why the transaction passed financial-crime controls, while Travel Rule records show what information accompanied the payment and how counterparty exceptions were handled. Audit readiness connects those records to the transaction itself.

Pillar 3: Audit Readiness - Reserves, Records, and Examiner Documentation

Audit readiness requires the bank to reconstruct how a stablecoin transaction moved through customer controls, screening, policy, authorization, signing, settlement, and reconciliation. A blockchain transaction hash provides useful ledger evidence but does not explain why the institution permitted the transaction or which internal controls governed it. The bank therefore needs records that preserve both the onchain event and the decision process around it.

Key Takeaway: Audit evidence needs to connect blockchain transactions to internal controls, people, systems, and third parties. Banks issuing stablecoins also need reserve and financial-reporting evidence that does not apply in the same form to institutions merely using an externally issued asset.

Reserve Backing and Attestations

Reserve requirements matter when a bank participates in stablecoin issuance because the institution then needs to evidence the relationship between outstanding tokens and the assets backing them. Under the GENIUS Act, permitted U.S. payment stablecoin issuers must maintain eligible reserves on at least a one-to-one basis, publish reserve composition monthly, maintain redemption procedures, and restrict reuse of reserve assets. Eligible reserves include cash, demand deposits, and specified short-dated U.S. government obligations, among other permitted assets.

The Act also adds financial assurance requirements around those reserves. Monthly reserve reports undergo examination by a registered public accounting firm with executive certification, while permitted issuers with more than $50 billion in consolidated outstanding issuance face an annual audited financial-statement requirement when the statutory conditions apply. These controls connect token liabilities to treasury records, reserve management, financial reporting, and governance rather than leaving reserve assurance solely within the token system.

MiCA applies its own reserve, segregation, custody, and audit requirements to asset-referenced token issuers in the EU. Banks considering issuance therefore need to treat reserve governance as a jurisdiction-specific financial control problem alongside the transaction controls discussed above.

Audit Trails and Record Retention

Audit trails need to preserve the information that an onchain transaction cannot explain. A transaction hash can establish that assets moved, but it does not show which customer record applied, what KYT result the bank received, which policy approved the transfer, who authorized it, or how an exception was resolved. Those records need a consistent connection to the underlying transaction.

That connection should continue through reconciliation. Wallet balances and blockchain movements need to map to the bank's relevant customer, treasury, accounting, and operational records so reviewers can identify breaks rather than reconstruct them manually. Record-retention periods then follow the legal and regulatory requirements applicable to the institution and activity; for example, Canada's financial-entity rules require relevant virtual-currency transfer records to be retained for at least five years.

Utila for Banking Compliance: Utila records transactions, policy decisions, approvals, signing events, and administrative changes in timestamped audit logs, with data export for compliance, accounting, and reconciliation.

The audit scope also needs to extend behind the transaction record when the bank provides crypto-asset safekeeping. U.S. banking agencies specifically call for audit coverage of key generation, storage and deletion, transfer and settlement controls, relevant IT systems, staff expertise, and third-party risk management.

Examiner-Readiness Checklist

An examiner-ready record should let reviewers follow a transaction through the bank's actual control framework without assembling evidence from several disconnected systems after the fact. The required documentation will vary by activity and regulator, but the review should connect policy design to what happened during execution. That makes the checklist useful as a test of the operating model rather than simply a document inventory.

• Scope and responsibility. Document whether the bank provides payments, treasury, safekeeping, issuance, or another stablecoin service and identify the controls attached to each activity.

• Customer and wallet evidence. Connect KYC/KYB records, beneficial ownership, wallet attribution, counterparty information, and relevant due-diligence updates.

• Transaction decision trail. Preserve AML/KYT results, sanctions checks, Travel Rule data where applicable, policy decisions, approvals, signing events, exceptions, and final transaction identifiers.

• Reconciliation and reporting. Connect onchain balances and transfers with the relevant customer, treasury, accounting, and reporting records and document how breaks are resolved.

• Infrastructure and third parties. Maintain evidence covering key management, access controls, policy configuration, technology providers, contingency arrangements, and ongoing third-party oversight.

The checklist becomes materially more useful when the infrastructure generates these records during the transaction rather than forcing operations teams to reconstruct them later. That requirement also exposes gaps between otherwise capable systems when screening, signing, approvals, and reporting produce separate records with no common transaction context. The final audit question concerns whether the institution can demonstrate one continuous decision path.

Audit and Reconciliation Gaps

Audit gaps usually emerge when the institution can prove that a transaction happened but cannot reproduce the controls behind it. Fragmented logs may show a KYT alert in one system, an approval in another, and a blockchain transaction somewhere else without a reliable way to establish which policy version connected them. Reconciliation gaps create a similar problem when onchain movements do not map cleanly to internal books and customer records.

Third-party use does not remove that responsibility. U.S. banking agencies permit banks to use sub-custodians and other technology providers, but they expect due diligence around key management, controls, recordkeeping, contingency planning, and the risks of the outsourced activity. They also state that the bank remains responsible for activities performed by a sub-custodian within the relevant arrangement.

That makes infrastructure design part of the compliance program rather than a separate technical decision. The bank can source specialist technology without recreating every capability internally, but it still needs to determine who owns policy, where controls execute, and how evidence returns to the institution.

How Banks Should Approach Stablecoin Compliance Infrastructure

Banks do not need to build every component of a stablecoin compliance stack internally, and regulatory guidance explicitly contemplates the use of third-party technology and service providers. Specialist functions such as blockchain analytics and Travel Rule messaging also depend on external data or counterparty networks that an individual bank cannot reproduce through internal workflow logic alone. The bank's responsibility lies in selecting those providers appropriately and determining how their outputs affect its own transactions.

Key Takeaway: Banks can source specialist compliance and wallet technology while retaining ownership of risk appetite, policy, exceptions, and oversight. The infrastructure needs to connect those decisions to transaction execution and preserve the resulting evidence.

A practical architecture separates responsibilities without fragmenting the transaction:

• Policy ownership. The bank defines risk appetite, approval requirements, escalation thresholds, permitted counterparties, and the conditions under which a transaction can proceed.

• Specialist services. Blockchain analytics providers supply onchain risk intelligence, while Travel Rule networks provide the counterparty communication needed to exchange regulated information.

• Transaction enforcement. Wallet and policy infrastructure applies the bank's approved controls before signing so screening results and governance rules can affect whether funds move.

• Evidence and oversight. The institution retains transaction records, monitors its providers, and preserves enough information to demonstrate how third-party inputs affected each decision.

This model also addresses a recurring problem in stablecoin compliance operations: adding another vendor does not help if each tool creates a separate dashboard that operations teams must reconcile manually. Screening, Travel Rule information, policy controls, and approvals carry more operational value when they feed the transaction workflow and share a common transaction record. The institution can then change a provider or adapt a rule without losing the governance framework around the payment.

The same architecture supports more targeted automation. Compliance teams can define the policy and escalation logic before execution, allowing routine transactions to follow approved controls while reserving human review for cases that require judgment. That placement gives the compliance function authority over transaction design without requiring an analyst to approve every payment individually.

Utila for Banking Compliance: Utila combines MPC wallet infrastructure with transaction policies, approval workflows, AML/KYT integrations, Travel Rule support, and audit logging. Banks can select specialist providers while applying their own governance rules to the resulting stablecoin workflows.

Utila supports banks running stablecoin pay-ins, payouts, and treasury operations through MPC wallets where no single party holds a complete private key, with policy controls applied before transaction execution. Integrations with Chainalysis, TRM Labs, and Elliptic bring AML/KYT screening into the wallet workflow, while Travel Rule support, approval workflows, and timestamped audit logs connect compliance decisions to the movement of funds. 

Book a demo to see how Utila can support your bank's stablecoin compliance and operating model.

Utila - Digital Asset Infrastructure

Managing digital assets at scale?

Schedule a 15-minute walkthrough of Utila’s wallet and stablecoin infrastructure.

Book a Demo

Frequently Asked Questions

Stablecoin compliance requirements change with the bank's activity, jurisdiction, counterparties, and role in the transaction. The three-pillar framework provides a consistent way to organize the control environment without assuming that every stablecoin use case carries the same obligations. The answers below address the implementation questions that follow most directly from that distinction.

What does stablecoin compliance for banks require?

Banks generally need to extend existing AML, sanctions, customer due-diligence, transaction-monitoring, and payment controls into stablecoin activity. Depending on the service, that can include wallet attribution, blockchain analytics, Travel Rule information, key management, transaction policies, approval controls, recordkeeping, and third-party oversight. Banks that issue stablecoins also need to address issuer-specific reserve, redemption, disclosure, and prudential requirements under the applicable regime.

Does a bank need KYT if it already performs KYC and AML?

KYC identifies and evaluates the customer, while KYT adds information about the blockchain addresses and transaction history involved in stablecoin activity. A verified customer can still send to or receive from an address carrying sanctions, illicit-finance, or other risk exposure that the customer record alone does not reveal. Banks therefore need a method for bringing relevant onchain information into their existing AML decision process.

Does the Travel Rule apply to every stablecoin transfer?

No single global threshold or scope applies to every stablecoin transfer. The United States, European Union, United Kingdom, Canada, Hong Kong, and other jurisdictions apply different rules around covered transfers, required information, self-hosted wallets, and missing data. Institutions should determine the applicable rule by jurisdiction and transaction type before configuring the corresponding workflow.

Can a bank outsource stablecoin compliance to a technology provider?

Banks can use third parties for compliance technology and specialist services, but regulatory responsibility remains with the bank. U.S. banking agencies explicitly state that third-party use does not reduce the institution's obligation to operate safely and comply with applicable laws, while the FCA applies the same principle to cryptoasset AML and Travel Rule providers. The bank therefore needs due diligence, ongoing oversight, access to relevant data, and control over the policies that determine how provider outputs affect transactions.

What should a stablecoin audit trail contain?

A useful audit trail should connect the blockchain transaction to the customer or counterparty, relevant wallets, screening results, Travel Rule data where applicable, policy decisions, approvals, signing events, exceptions, settlement status, and internal reconciliation. Banks providing safekeeping should also preserve evidence around cryptographic key controls and relevant third-party arrangements. That combination allows reviewers to reconstruct the institution's decision rather than merely confirm that a blockchain transaction occurred.

What changes when a bank issues its own stablecoin?

Issuance adds obligations tied to the stablecoin itself rather than only the movement or safekeeping of the asset. In the United States, permitted payment stablecoin issuers face statutory requirements covering eligible reserves, redemption, reserve disclosures, financial assurance, BSA compliance, and sanctions controls under the GENIUS Act. Banks evaluating issuance therefore need to connect token operations and wallet governance with treasury, finance, compliance, and reporting controls.

What penalties can apply?

There is no single penalty schedule covering every form of stablecoin non-compliance because enforcement depends on the obligation breached and the institution's role. BSA/AML, sanctions, Travel Rule, safety-and-soundness, and stablecoin-issuer requirements carry their own enforcement frameworks, while the GENIUS Act also establishes specific penalties for certain prohibited issuer activity. Banks should therefore map enforcement exposure to each regulated activity rather than assign one generic “stablecoin penalty.”

Are all stablecoins regulated the same way?

Stablecoin treatment depends on the asset, issuer, jurisdiction, and activity performed by the bank. The GENIUS Act governs U.S. payment stablecoin issuance, while MiCA distinguishes categories including asset-referenced and e-money tokens in the EU. A bank also needs to consider the rules attached to its own service, such as payments or safekeeping, independently of the requirements governing the issuer.

How should banks handle self-hosted wallets?

Banks should apply the requirements of the relevant jurisdiction and their own risk-based procedures rather than use one universal rule for self-hosted wallets. Some regimes require additional measures to establish ownership or control above specified thresholds, while FATF identifies peer-to-peer activity through unhosted wallets as an area requiring appropriate risk mitigation. The bank's workflow should connect wallet attribution, customer information, transaction monitoring, and Travel Rule requirements before determining whether the transfer can proceed.