NYDFS crypto custody guidance makes the relationship behind a wallet balance worth examining. A product team evaluating custody needs to connect the customer agreement with the entity holding the assets, the wallets and the records that identify each customer’s interest. A reassuring custody label leaves those questions unanswered.
Start with the current guidance and the right entity
DFS issued its updated custody guidance on September 30, 2025, replacing the 2023 version. It addresses BitLicensees and New York limited purpose trust companies that custody virtual currency. Its central expectations concern segregation, limited use, sub-custody and disclosure.
The DFS licensing overview distinguishes a BitLicense from a trust charter, including the latter’s fiduciary powers. Read the agreement’s legal entity name before matching an authorization to the service. Our BitLicense versus trust charter explainer explains that distinction; the license directory is the separate lookup resource.
What the custody structure needs to establish
The guidance expects separation of customer and corporate assets, identifiable customer interests and reconciliation. It contemplates individual wallets and customer-only omnibus arrangements. Safekeeping should preserve customers’ beneficial ownership rather than establish ordinary debt owed by the custodian.
New sub-custody arrangements require prior DFS approval. The letter addresses agreements, controls, eligible sub-custodians, customer disclosure and specifically approved segregation exceptions. Read the complete current letter for its qualifications.
Those expectations do not establish that a particular provider has met them. The review still needs evidence about the actual arrangement.
Work through an omnibus-wallet example
Consider a hypothetical product displaying balances for customers A and B. Its custody provider uses one customer-only blockchain wallet, while its internal records allocate the respective interests. A reviewer should be able to follow a deposit from a transaction reference to the relevant customer record and then compare the resulting totals with the wallet activity.
The useful question is how that explanation holds together when activity becomes less tidy. What record follows a withdrawal that has been requested but is still awaiting execution? How is an internal transfer between customer accounts represented when no blockchain transfer occurs? Which record explains a correction to an earlier allocation?
These are proposed review questions, not a list of transaction formats mandated by the letter. Their purpose is to test whether the description of the arrangement is usable. A provider may have a sound explanation that uses different terminology or records. Ask for the mapping instead of assuming the names must match your own system.
A wallet address alone cannot answer the allocation questions in this hypothetical. An internal balance screen alone does not show how the on-chain holdings relate to it. The review needs the connection between the two. Keep the example small enough to trace completely before moving to aggregated reports.
Draw the sub-custody chain
A second hypothetical adds another custodian. The customer signs with company X, but company Y performs part of the safekeeping. Draw those as separate entities and write the function of each beside its name. Avoid treating a shared brand, integration or commercial relationship as a substitute for that description.
Then assemble the documents that explain the chain. The proposed service agreement should be identifiable, the customer-facing terms should describe the relevant arrangement, and the reviewer should know which evidence answers an approval or authorization question. Record where evidence remains unavailable; a missing document is not permission to infer its contents.
This exercise also helps expose a scope mismatch. A technical demonstration might show that X can send an instruction to Y. That says little by itself about ownership language, the permitted uses of customer assets or how responsibilities are allocated in the contract. Keep the technical result and the contractual review as separate evidence in the assessment.
Compare the agreement with the product screen
Read the custody terms alongside the interface a customer actually sees. If the screen uses one entity’s brand and the agreement names another entity, the explanation should make that relationship intelligible. If a product combines safekeeping with another activity, identify which terms govern the activity being offered rather than extending a custody conclusion across the entire product.
A practical review note can record the entity and service, the agreement version, the custody chain, the records supporting customer allocations and the questions still awaiting evidence. That is an editorial recommendation for organizing a review, not a prescribed DFS form or a certification of compliance.
Preserve the actual document versions. A later reviewer should be able to distinguish a change in the provider’s terms from a change in the description your team wrote about them. For unresolved ownership or insolvency questions, obtain advice on the actual arrangement; neither a product label nor this general explanation determines an individual customer’s legal outcome.
