For finance and treasury leaders, evaluating a digital asset platform means checking whether its documented custody model, transaction controls, integrations, reporting, and operating responsibilities fit the institution’s requirements. Begin with the intended use case, then compare evidence against a consistent checklist. A feature description alone does not establish control effectiveness, service availability, or suitability.

Define the treasury use case before assessing technology

Write down which activities the institution is evaluating, such as holding assets, making transfers, or supporting operational payments. Map who initiates, approves, executes, records, and reconciles each workflow. The goal is to define requirements, not to assume that digital assets belong in every treasury.

Translate those needs into specific questions. Which assets and networks would the institution require? Which entities and jurisdictions would use the service? Which systems must exchange information with it? These answers depend on the institution and the proposed service. Confirm them in current provider documentation and applicable service terms rather than inferring support from a general product description.

Separate required capabilities from preferences. A requirement might be that a transfer follows an internal approval process; a preference might concern how that process is displayed. For each item, record the intended outcome, evidence needed to verify it, and the internal owner responsible for the decision. This distinction helps reviewers avoid treating a convenient interface as a substitute for a control.

Also define what success means operationally. For example, identify the records needed to reconcile transactions and the teams that must be able to retrieve them. Avoid specifying a platform feature before confirming the underlying task it must support. This makes it easier to assess whether a documented capability addresses a real workflow or simply appears in a product description.

Digital asset platform custody and transaction controls

Clarify what “custody” means in the proposed arrangement. In a 2025 interagency statement concerning banking organizations covered by that statement, crypto-asset safekeeping is defined as holding an asset on a customer’s behalf. That specific definition does not resolve every platform’s legal or operational arrangement. Ask who controls keys or other signing authority, who can authorize transactions, and what role the institution retains. Compare the provider’s documentation with the proposed service terms rather than relying on a product label.

Map the transaction lifecycle from initiation through recording and reconciliation. Ask who can create, approve, sign, submit, or cancel a transaction; whether permissions can be assigned separately by role; and who can change those permissions. Determine what approval workflow applies, how exceptions are handled, and what transaction limits or other controls can be configured. Ask what record shows which action occurred and under whose authorization.

Treat these points as questions to verify, not assumptions that a platform has particular controls. Request current control descriptions and, where appropriate, a demonstration. Confirm that settings shown in a demonstration apply to the institution’s proposed service and appear in relevant documentation. A demonstration of a general interface is not evidence that a specific configuration or control is available under the intended service.

Request documented procedures for incidents, recovery, and changes to control settings. Establish which party is responsible for each action, what information or approval the institution must provide, and what limitations apply. If provider materials do not explain recovery or incident responsibilities, record the issue as unresolved and request clarification. Do not infer that recovery is available, automatic, or within the provider’s control unless the applicable documentation supports that conclusion.

Test integrations, records, and treasury reporting needs

List the systems the institution expects to connect, such as accounting, treasury-management, or reporting systems. For each connection, ask what data is exchanged, how it is delivered, and which party maintains the integration. Verify the specific scope in current technical documentation; a general reference to “integration” does not establish support for a particular system or workflow.

Define the records needed to reconcile activity. Ask which transaction details, statuses, timestamps, and identifiers are provided; how corrections or exceptions appear; and whether the institution can export or otherwise access required records. Confirm how data access, retention, and reporting limitations are documented. If a report omits a field needed for internal reconciliation, identify the resulting manual process or unresolved gap rather than assuming another report will supply it.

Separate three questions: does a record exist, can the institution retrieve it in the needed format, and does it support the institution’s reconciliation and audit process? Request documentation or a demonstration for the proposed service configuration, then compare what is shown with the institution’s recordkeeping requirements. Record any difference between the product’s reported data and the information the treasury team needs to complete its process.

Where multiple services are involved, identify which one produces each record and who is responsible for resolving discrepancies. Keep the question tied to the actual integration and service terms under review; do not assume that a platform, bank, custodian, or other provider supplies records outside its documented scope. If responsibilities are unclear, capture that as a due-diligence question before operational reliance.

Build a due-diligence evidence checklist

Collect evidence by topic, owner, date, and status. Request current documentation covering:

  • Service scope: the services the institution would receive and responsibilities that remain with it.
  • Custody and authorization: the arrangement for key control, signing, approvals, permissions, and control changes.
  • Security and operations: documented control descriptions, relevant independent assurance materials, incident procedures, and stated recovery limitations.
  • Integrations and records: supported connections, data fields, access methods, reporting scope, and retention terms.
  • Availability and supported assets: the jurisdictions, assets, and networks relevant to the institution, verified in current provider materials and applicable service terms.
  • Fees and contract terms: current, applicable documents for the proposed service, rather than estimates inferred from general descriptions.
  • Compliance responsibilities: the institution’s and provider’s respective roles for the relevant service and jurisdiction.

For compliance questions, distinguish general standards from confirmed obligations. FATF standards for virtual asset service providers include preventive measures such as customer due diligence, recordkeeping, suspicious-transaction reporting, and handling originator and beneficiary information for applicable transfers. FATF sets international standards; exact legal duties, thresholds, licensing, data handling, and permitted services depend on implementation in each jurisdiction. This general description does not confirm a provider’s status or determine the institution’s obligations. Verify those questions using authoritative records and qualified, jurisdiction-specific advice.

For each evidence item, record its date, scope, and the service or configuration it covers. If a document does not address the proposed arrangement, classify the point as unresolved rather than treating adjacent documentation as proof. Request clarification about the responsible party and the applicable terms. Keep an evidence trail that lets reviewers see what was checked, what remains uncertain, and who owns follow-up.

Compare requirements without turning the review into a vendor ranking

Use the same criteria for every platform considered. Mark each item as documented, demonstrated, or unresolved, and link the assessment to the evidence reviewed. “Documented” means materials describe the capability; it does not by itself establish effectiveness in the institution’s operating environment. “Demonstrated” should refer to a workflow or configuration shown for the service being assessed, not merely a generic presentation.

For each gap, record its operational consequence, a proposed mitigation for internal review, and the person responsible for follow-up. Distinguish a missing capability from a missing explanation: either may prevent the institution from completing its assessment, but they require different next steps. Escalate unresolved legal, tax, security, recovery, and compliance questions to qualified specialists rather than attempting to settle them through a feature comparison.

The final assessment should show how each requirement maps to evidence and where evidence is incomplete. It can identify essential controls, preferences, and open questions without ranking vendors or recommending a provider. A platform’s listed features are inputs to that review, not a conclusion that the service fits the institution’s needs.

Sources and references