When evaluating Anchorage digital asset custody, an institution should verify controls and evidence for the exact service arrangement under review—not infer capabilities from the provider name or a general service description. Assess key governance, access, transaction authorization, resilience, monitoring, and incident response against the institution’s own treasury procedures. Record the evidence scope and unresolved questions; this process does not rank providers or determine whether a service is suitable.

Frame the custody risk before assessing controls

Begin by defining what the assessment covers. List the assets and entities in scope, the users and systems involved, the transaction types under review, and the operational dependencies that could affect custody workflows. Separate asset safeguarding from the institution’s own treasury authorization, accounting, and liquidity processes. Establish which controls are assigned to the institution, which to the provider, and which depend on another party or internal process. Verify that division for the specific arrangement rather than assuming a standard allocation.

A digital token can be understood as a digital ledger record about an asset and its owner, with programmable rules governing use or transfer. That technical record does not by itself establish legal title, enforceability, or the quality of the represented asset. Keep questions about the represented asset and its legal status separate from the assessment of keys and transaction controls; unresolved legal questions may require qualified advice. (source )

Create a register of assumptions and unknowns before requesting evidence. For each control, note whether it is documented, demonstrated, or still unverified. For example, key creation, transaction approval, recovery, and reconciliation might each require different materials or demonstrations. Treat an unverified control as an open question—not as a confirmed feature, but also not automatically as proof of failure. A public description should not be assumed to represent the institution’s configuration.

Anchorage digital asset custody: verify key governance and access

Request materials that apply to the exact service and explain the lifecycle of relevant cryptographic keying material. Key management covers protection and lifecycle functions such as generation, storage, distribution, use, recovery, revocation, and destruction. That general lifecycle is a checklist for inquiry; it does not establish how a particular provider performs any step. Ask for policies, procedures, responsibility assignments, and evidence that makes the described process applicable to the institution’s arrangement. (source )

Map who can initiate, approve, or carry out each sensitive action. Ask how privileged access is granted, reviewed, changed, and removed; what authentication requirements apply; and whether access changes require separate approval. Compare the documented roles with the institution’s responsibility assignments. Where access or key operations are shared or delegated, identify each party and the handoffs between them. If materials leave a responsibility unclear, record that as a gap rather than inferring a control from terms such as “institutional” or “custody.”

Also establish who is responsible for retaining and protecting any recovery material. In a self-custody model, the user controls and is responsible for the private keys and recovery material needed to access the user’s crypto assets. This describes that model only; it does not show how a third-party service divides key or recovery responsibilities. Verify the specific arrangement and document which party controls each relevant key and recovery step. (source )

Ask for evidence that supports the access-control description, not just a summary of intended policy. Determine what records show who received access, when it changed, and who reviewed it. If an access review is described, establish its scope and period, and note any exceptions or limitations. The aim is to understand how the defined roles operate in the proposed arrangement without assuming that a policy statement proves implementation.

Test transaction authorization and treasury workflows

Trace a representative transaction from initiation through authorization, execution, and reconciliation. Use written procedures or a demonstration that shows who acts at each stage, what records are generated, and how exceptions are handled. This workflow review identifies evidence to request; it does not establish that a particular feature is available in Anchorage custody or any other service.

Compare the documented workflow with the institution’s internal treasury policy. Check whether approval thresholds, separation of duties, address controls, and procedures for exceptional or urgent transactions are defined and supported by evidence. If a control depends on a configuration or manual action, request evidence for that specific step. Record any mismatch, missing record, or unsupported assumption. A requirement in internal policy should not be described as a provider capability unless evidence confirms how it works in the arrangement under review.

Treat reconciliation as a distinct stage. Specify what information the institution expects to compare, who performs the comparison, how often the procedure applies under the institution’s own policy, and how discrepancies are escalated. Distinguish transaction execution from the institution’s accounting and control responsibilities. Evidence that one transaction stage occurred does not, on its own, establish that the whole workflow was complete or that it met internal requirements.

For the workflow record, capture the source of each piece of evidence and the exact step it supports. A procedure may describe an intended process, while a demonstration may show a particular configuration; neither should be treated as broader proof than its scope permits. Record deviations and exceptions in the same review log so that the institution can distinguish a documented process from an assumption about normal operations.

Evaluate resilience, monitoring, and incident response

Request current, relevant evidence on continuity planning, recovery objectives, testing, and material dependencies. Check which functions and services the documents cover, the period addressed, and any stated limitations or exceptions. A statement that a continuity plan exists is not equivalent to evidence of its scope, testing, or applicability to the institution’s arrangement. If materials do not substantiate a recovery outcome, state the outcome as an open due-diligence question rather than a promise.

For monitoring, ask how suspicious activity and control failures are identified, who reviews alerts, and how escalation and communication take place. Request the procedures that define responsibilities and notification paths. For incident response, clarify decision authority, the roles of the institution and provider, and what records would be available for later review. Keep the checks separate: monitoring concerns identification and escalation; incident response concerns coordinated decisions and follow-up. Do not infer response effectiveness from the existence of a written plan alone.

If the institution is a virtual asset service provider subject to FATF standards, those standards expect applicable preventive measures that include customer due diligence, record keeping, suspicious-transaction reporting, and handling originator and beneficiary information for applicable transfers. Exact duties, thresholds, and implementation depend on the relevant jurisdiction. This conditional point does not establish that a specific institution or custody arrangement has a particular obligation. Verify any applicable requirements against current authoritative sources and qualified advice. (source )

Turn evidence into a decision record and control gaps

For every control, record the evidence source, date or period covered, service and configuration in scope, and any exceptions or limitations. Add the unanswered question and the person or team responsible for follow-up. A useful status can distinguish evidence reviewed, evidence requested but not received, evidence that does not cover the arrangement, and a documented control shortfall. Missing evidence leaves a control unverified; it is not automatically proof that the control failed.

Classify unresolved items by operational consequence and the evidence needed next. One item may require a written procedure, another a clarification of role ownership, a workflow demonstration, or a current assurance document that identifies its scope and limitations. Keep evidence gaps distinct from confirmed deviations. Do not turn the review into a vendor score or a generalized conclusion about security unsupported by the materials.

Route unresolved legal, regulatory, insurance, and jurisdiction-specific questions to qualified advisers and current authoritative sources. The final record should identify the institution’s requirements, what evidence was reviewed, which controls that evidence supports, and what remains unresolved. That provides a traceable basis for a treasury decision without implying that a provider name, general service description, or incomplete document set establishes the controls in practice.

Sources and references