Unit 05 · Chapter 5 · 10 min read

Digital assets, stablecoins, and wallet risk

Separate blockchain evidence, legal identity, and financial exposure.

A wallet address is visible to everyone. Its owner may not be. A token can settle quickly on a network while the customer’s legal claim, redemption right, and compliance status remain separate questions.

Separate the asset and the service

A digital asset, its issuer, the blockchain network, the custodian, and the exchange are different components. Each introduces distinct risk. A token’s transferability does not establish a right to redeem it for bank money.

Map who controls keys, who owes the customer, what redemption terms apply, and where records of ownership exist. A custodial balance is a claim against a service provider as well as a representation of assets held. A self-hosted wallet changes control and recovery assumptions. The relevant legal and compliance duties depend on the actual activity and jurisdiction.

Separate the asset and the service Separate the asset and the service — the flow Follow the sequence. Determine what the customer can enforce. Asset Identify the token and its terms Service Identify custody exchange or transfer roles Claim Determine what the customer can enforce — Follow the sequence. Determine what the customer can enforce. Chapter sources · Open image

Separate the asset and the service Separate the asset and the service — the distinction These concepts answer different questions. Read each definition in the context of the section. On-chain balance Network record of token holdings Redemption claim Right under the issuer or service terms — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Separate the asset and the service Asset-service map Fictional teaching record. Not implied by wallet balance. Asset-service map Illustrative data; not a real customer record or a prescribed policy. Token illustrative stablecoin Specific asset Custodian service provider Controls keys in this example Redemption terms-dependent Not implied by wallet balance Technical transfer and legal rights differ — Fictional teaching record. Not implied by wallet balance. Chapter sources · Open image

Separate the asset and the service Separate the asset and the service — control and failure modes Technical transfer and legal rights differ. The branches show why alternative designs fail. Control design Map asset service and customer claim separately. Technical transfer and legal rights differ. Failure mode 1 Assume every token is cash. Redemption and value can differ. avoid Failure mode 2 Treat wallet balance as deposit insurance. That requires a separate legal basis. avoid Failure mode 3 Ignore custody. Key control changes operational risk. avoid — Technical transfer and legal rights differ. The branches show why alternative designs fail. Chapter sources · Open image

Use blockchain evidence with limits

A transaction hash can establish a network event under the chain’s rules. Address attribution connects an address to an entity through evidence that may vary in strength. A labeled cluster can be useful without being certain.

Store chain, asset, address, transaction reference, block context, attribution source, and confidence. Do not merge addresses across chains merely because their text looks similar. Reorganizations, bridges, custodial omnibus wallets, and internal exchange transfers can complicate interpretation. Preserve the distinction between directly observed transfers and inferred ownership relationships.

A blockchain address is an identifier within a technical system. It is not automatically a verified person, a legal entity, or a complete account relationship. Attribution can depend on public records, provider analysis, customer evidence, and assumptions that change over time. Preserve the source and date of an attribution so a reviewer can assess what was known at the original decision.

Graph proximity also needs interpretation. Direct interaction, indirect exposure, pooled services, and technical routing can produce different meanings. A risk score that compresses them into one number may be useful for triage but should not erase the underlying path. The legal and operational decision needs the activity, the parties where established, and the relevant restriction or concern.

Use blockchain evidence with limits Use blockchain evidence with limits — the flow Follow the sequence. Separate direct evidence from inference. Observe Record chain-specific transactions Attribute Attach sourced entity labels Interpret Separate direct evidence from inference — Follow the sequence. Separate direct evidence from inference. Chapter sources · Open image

Use blockchain evidence with limits Use blockchain evidence with limits — the distinction These concepts answer different questions. Read each definition in the context of the section. On-chain event Observed transfer in a network record Entity attribution Evidence linking an address to a real-world actor — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Use blockchain evidence with limits Wallet evidence Fictional teaching record. Not a proven owner identity. Wallet evidence Illustrative data; not a real customer record or a prescribed policy. Transaction chain-specific hash Observed event Address label vendor estimate Attributed identity Confidence limited Not a proven owner identity Public data still requires interpretation — Fictional teaching record. Not a proven owner identity. Chapter sources · Open image

Use blockchain evidence with limits Use blockchain evidence with limits — control and failure modes Public data still requires interpretation. The branches show why alternative designs fail. Control design Retain chain context and attribution confidence. Public data still requires interpretation. Failure mode 1 Treat vendor labels as certain identity. Attribution can be wrong or incomplete. avoid Failure mode 2 Merge same-looking addresses across chains. Network context matters. avoid Failure mode 3 Call every cluster one legal person. Clustering is an inference. avoid — Public data still requires interpretation. The branches show why alternative designs fail. Chapter sources · Open image

Apply sanctions to the activity

OFAC’s virtual-currency guidance explains that sanctions obligations apply to relevant virtual-currency activity as they do to other activity within scope. Technical novelty does not remove the need to assess parties, location, and applicable restrictions.

A wallet screen is one input. Combine it with customer and transaction context, list freshness, attribution quality, and the legal rule. Define how a relevant finding affects custody, transfers, reporting, and any permitted release. The ability to send a token technically does not mean the transfer is legally permitted.

Apply sanctions to the activity Apply sanctions to the activity — the flow Follow the sequence. Enforce the required transfer or custody action. Screen Evaluate relevant wallet and party evidence Assess Apply the actual sanctions scope Control Enforce the required transfer or custody action — Follow the sequence. Enforce the required transfer or custody action. Chapter sources · Open image

Apply sanctions to the activity Apply sanctions to the activity — the distinction These concepts answer different questions. Read each definition in the context of the section. Technically possible Network permits a transaction Legally permitted Applicable restrictions allow the activity — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Apply sanctions to the activity Digital transfer review Fictional teaching record. Pending approved disposition. Digital transfer review Illustrative data; not a real customer record or a prescribed policy. Wallet result potential relevant match Candidate evidence Customer context under review Additional facts Transfer not released Pending approved disposition Technology does not replace sanctions analysis — Fictional teaching record. Pending approved disposition. Chapter sources · Open image

Apply sanctions to the activity Apply sanctions to the activity — control and failure modes Technology does not replace sanctions analysis. The branches show why alternative designs fail. Control design Apply the legal rule beyond the wallet score. Technology does not replace sanctions analysis. Failure mode 1 Approve because the chain accepts it. Network validity is not legal authorization. avoid Failure mode 2 Ignore off-chain customer identity. It can be central to the duty. avoid Failure mode 3 Use stale attribution without qualification. Evidence quality can change. avoid — Technology does not replace sanctions analysis. The branches show why alternative designs fail. Chapter sources · Open image

Stress stablecoin and custody exposure

A stable value target is a design objective, not a guarantee. Reserve quality, redemption terms, market liquidity, issuer condition, custody, and network operations can affect outcomes. A token may trade below its target when holders cannot redeem quickly.

Model the customer obligation separately from the assets intended to support it. Test delayed redemption, price movement, lost key access, and partner failure. Record whether the firm promises a fixed fiat amount or a quantity of tokens. Those promises produce different exposure when the market price changes.

A stable price target does not remove custody, liquidity, redemption, or counterparty risk. The customer may see one token balance while the platform depends on an issuer, a custodian, a chain, and a conversion route. A disruption in one dependency can prevent the customer from obtaining the expected fiat value even if the displayed token quantity is unchanged. Stress the actual path from asset holding to usable funds, including timing, fees, concentration, and the conditions under which each intermediary performs.

Stress stablecoin and custody exposure Stress stablecoin and custody exposure — the flow Follow the sequence. Model price liquidity and custody failures. Promise Identify fiat or token obligation Backing Assess assets and redemption access Stress Model price liquidity and custody failures — Follow the sequence. Model price liquidity and custody failures. Chapter sources · Open image

Stress stablecoin and custody exposure Stress stablecoin and custody exposure — the distinction These concepts answer different questions. Read each definition in the context of the section. Fiat obligation Customer is owed a fixed currency amount Token obligation Customer is owed a defined token quantity — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Stress stablecoin and custody exposure Depeg example Fictional teaching record. Illustrative asset value 970 USD. Depeg example Illustrative data; not a real customer record or a prescribed policy. Customer promise 1000 USD Fixed fiat obligation Held tokens 1000 units Asset quantity Market price 0.97 USD Illustrative asset value 970 USD A stable target does not guarantee immediate cash — Fictional teaching record. Illustrative asset value 970 USD. Chapter sources · Open image

Stress stablecoin and custody exposure Stress stablecoin and custody exposure — control and failure modes A stable target does not guarantee immediate cash. The branches show why alternative designs fail. Control design Match liabilities to stressed asset value and access. A stable target does not guarantee immediate cash. Failure mode 1 Assume one token always equals one dollar. Market and redemption conditions can differ. avoid Failure mode 2 Ignore key custody. Assets may be inaccessible. avoid Failure mode 3 Use reserve headlines without terms. Eligibility and access matter. avoid — A stable target does not guarantee immediate cash. The branches show why alternative designs fail. Chapter sources · Open image

Build operational controls for keys and transfers

Key custody needs access control, approval, recovery, and incident procedures. Transfers need destination validation, amount controls, and an auditable authorization path. A cryptographic signature proves that a key signed; it does not prove the business approval was valid.

Separate transaction preparation from high-impact approval and signing where appropriate. Test recovery using controlled procedures and protect backup material. Monitor destination changes and reconcile on-chain movements with the customer ledger. A secure signing service can still execute a wrong business instruction if upstream authority is weak.

Build operational controls for keys and transfers Build operational controls for keys and transfers — the flow Follow the sequence. Record network and ledger evidence. Prepare Validate destination amount and business authority Approve Use the required separation of duties Sign and reconcile Record network and ledger evidence — Follow the sequence. Record network and ledger evidence. Chapter sources · Open image

Build operational controls for keys and transfers Build operational controls for keys and transfers — the distinction These concepts answer different questions. Read each definition in the context of the section. Valid signature Key authorized a network message Valid business action Approved instruction under the product controls — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Build operational controls for keys and transfers Transfer control Fictional teaching record. Audit trail to the ledger. Transfer control Illustrative data; not a real customer record or a prescribed policy. Prepared by operator A Instruction creation Approved by operator B Independent authority Signed transaction linked reference Audit trail to the ledger Cryptography does not validate the commercial purpose — Fictional teaching record. Audit trail to the ledger. Chapter sources · Open image

Build operational controls for keys and transfers Build operational controls for keys and transfers — control and failure modes Cryptography does not validate the commercial purpose. The branches show why alternative designs fail. Control design Bind signing to approved business instructions. Cryptography does not validate the commercial purpose. Failure mode 1 Let one uncontrolled script prepare and sign. Authority concentration increases risk. avoid Failure mode 2 Store recovery keys in ordinary logs. That exposes critical secrets. avoid Failure mode 3 Skip ledger reconciliation. Network transfers must match customer obligations. avoid — Cryptography does not validate the commercial purpose. The branches show why alternative designs fail. Chapter sources · Open image

Chapter connections

This chapter builds on Trade, corridors, and restricted activity. Use the glossary for terminology and risk mathematics for formulas and worked calculations.

Sources

Reviewed 2026-09-17