Digital assets, stablecoins, and wallet risk

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.

Inside the mechanism. Separate the token, network, wallet address, custody arrangement, exchange, issuer, and service activity. Each can create different evidence and dependencies. A blockchain transfer record does not establish the legal identity of every party or the availability of off-chain redemption. Preserve asset and network identifiers so similar tickers or wrapped representations are not treated as the same exposure.

A concrete example. Holding a token, operating an exchange, providing custody, and transmitting value are different activities. The service model determines which facts and responsibilities matter. The case identifies 2,415 eligible records from a source population of 3,500. The required workflow completes for 2,343, but 35 completed records miss the illustrative internal target. Another 72 remain incomplete. Communication evidence covers 2,320 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.

When the assumption fails. The product treats every digital-asset activity as the same legal and operational role. Map the actual service, parties, jurisdictions, obligations, and assets under control. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

Holding a token, operating an exchange, providing custody, and transmitting value are different activities. The service model determines which facts and responsibilities matter.

Asset and service boundary: reference condition figure preview

01Reference conditionAsset and service boundary

Asset and service boundary: failure and stress figure preview

02Failure and stressAsset and service boundary

Asset and service boundary: controlled response figure preview

03Controlled responseAsset and service boundary

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.

Inside the mechanism. On-chain observations can establish certain transfers and relationships, but attribution and clustering add assumptions. Record provider, method, confidence, time, and the distinction between direct exposure and a multi-hop path. Shared infrastructure can connect unrelated users. A graph should support a scoped investigation; it should not turn uncertain address attribution into an unsupported statement about a person’s intent.

A concrete example. An address can be connected to a subject through evidence of different quality and age. Graph proximity alone does not establish legal identity or intent. The daily source population is 14,200 items, but 284 are outside the completed monitoring run. The included population creates 473 hits and 388 unique cases. With 78 cases already open and capacity for 385, the queue closes at 81. Coverage, duplicate work, and staffing are separate causes; reducing one number does not prove that the overall control improved.

When the assumption fails. An indirect path becomes a definitive customer label without a source or date. Retain attribution provenance, path type, timing, and the limits of the analysis. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

An address can be connected to a subject through evidence of different quality and age. Graph proximity alone does not establish legal identity or intent.

Blockchain attribution evidence: reference condition figure preview

01Reference conditionBlockchain attribution evidence

Blockchain attribution evidence: failure and stress figure preview

02Failure and stressBlockchain attribution evidence

Blockchain attribution evidence: controlled response figure preview

03Controlled responseBlockchain attribution evidence

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.

Inside the mechanism. Apply the relevant sanctions analysis to the actual service and activity. Screening an address is one input, not a universal compliance conclusion. Customer identity, ownership, jurisdiction, transaction purpose, and available authority can matter. Keep the disposition and the technical transfer state separate. A blocked or pending operational state needs a controlled process for any later release or other action.

A concrete example. A relevant address or party match is one part of the review. The actual service, transaction, subject, and applicable restriction determine the required handling. The matcher returns 297 candidates from 28,400 records. It identifies 70 of 76 known fictional identity matches and misses 6. After scoped suppressions and stale-evidence returns, review demand is 239. The example keeps identity resolution, control availability, and the final legal disposition separate.

When the assumption fails. A vendor risk score replaces identity resolution and legal scope analysis. Keep vendor signals, factual findings, and authorized disposition in separate records. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

A relevant address or party match is one part of the review. The actual service, transaction, subject, and applicable restriction determine the required handling.

Sanctions in the activity context: reference condition figure preview

01Reference conditionSanctions in the activity context

Sanctions in the activity context: failure and stress figure preview

02Failure and stressSanctions in the activity context

Sanctions in the activity context: controlled response figure preview

03Controlled responseSanctions in the activity context

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.

Inside the mechanism. A stablecoin balance can have issuer, reserve, redemption, custody, market-liquidity, and operational risks. A quoted market price near one unit does not prove immediate redemption capacity in the required currency. Stress access to the custodian and redemption channel as well as price. Avoid counting the same token balance as independent protection against failure of the party needed to redeem it.

A concrete example. A displayed token quantity does not itself prove that fiat can be obtained at the expected time and value. The redemption path depends on several entities and conditions. The case has $2,850,000 of exposure. Its stated one-year PD and LGD imply $20,520.00 of expected loss, while the cover analysis leaves $1,260,000.00 of stress exposure. Monthly cash coverage is 0.90×. These are separate measures: one describes an average under probability assumptions, one describes available cover, and one describes a period’s funding capacity.

When the assumption fails. A custodian or conversion route fails while the customer expects immediate cash. Stress usable access, counterparty concentration, timing, and conversion assumptions. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

A displayed token quantity does not itself prove that fiat can be obtained at the expected time and value. The redemption path depends on several entities and conditions.

Stablecoin redemption dependencies: reference condition figure preview

01Reference conditionStablecoin redemption dependencies

Stablecoin redemption dependencies: failure and stress figure preview

02Failure and stressStablecoin redemption dependencies

Stablecoin redemption dependencies: controlled response figure preview

03Controlled responseStablecoin redemption dependencies

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.

Inside the mechanism. Key authority, signing policy, destination controls, and transfer reconciliation form one operating chain. Separate proposal, approval, signing, broadcast, confirmation, and accounting recognition. A broadcast timeout does not prove that no transfer occurred. Protect against repeated signing of a new transaction for the same business intent without checking the original outcome. Recovery planning must account for the actual custody and authority model.

A concrete example. A transfer instruction depends on signing authority, policy approval, submission, and final observation. Recovery options differ when a transfer cannot be reversed by the application. 95 intended requests generate 100 processing attempts under this retry assumption. Capacity is 130 attempts per interval, and the critical path consumes 150 ms of a 700 ms budget. The request-based SLO view observes 100 bad requests against an illustrative allowance of 100. These measurements must be connected to the financial effect and control evidence before declaring recovery.

When the assumption fails. A signing service repeats an instruction after an ambiguous network response. Separate authorization, signing, submission, observation, and reconciliation under stable identifiers. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

A transfer instruction depends on signing authority, policy approval, submission, and final observation. Recovery options differ when a transfer cannot be reversed by the application.