Anchorage Digital integration: where asset accounting breaks
A typical picture: some digital assets are in exchange accounts, some in hot and hardware wallets, with keys held by two or three people. Digital asset accounting is done in spreadsheets or an internal panel updated manually.
While there are few transactions, the picture reconciles; as volume grows, reconciling asset operations becomes days of work.
This breaks predictably: balances in the spreadsheet and on-chain diverge because fees and internal transfers are not recorded at the moment of the operation. Withdrawal of funds depends on one person — if they go on vacation or lose access, account movement stops.
An audit asks to confirm title to assets and the path of each operation, but all you can present is an export and correspondence.
Regulated crypto custody changes the foundation. Assets are placed in custodial storage with a licensed provider — Anchorage Digital — in segregated accounts with legally enforced segregation by clients and funds.
Keys are not stored by employees, access is granted by roles, and an operation passes through a signature policy and limits.
For accounting, this provides the main thing: operations come from a single source with an identifier, status, and confirmation, rather than being assembled from five interfaces.
Reconciliation is built on provider events, discrepancies are visible the next day, not a quarter later. Next, we break down what such an integration consists of and where its bottlenecks are.
What regulated custody provides: control, speed, reporting
Moving custody to a regulated custodian changes not only who is responsible for assets.
Reconciliation stops being a separate procedure: balances by account and network come from a single source, and a discrepancy is visible when it appears, not at the end of the reporting period.
When integrated with Anchorage Digital, this is no longer an export from someone else's interface but a continuous stream of portfolio state data.
The most noticeable reduction is in the share of manual operations. Transaction signing moves into roles and policies: amount limits, allowed address lists, mandatory second confirmation for large withdrawals.
The operator no longer moves data between interfaces or reconciles it manually — they confirm or reject, and the system does the rest.
A separate class of failures related to key loss is closed. There is no single copy on one device, no person who "remembers the password," no situation where access is lost along with an employee departure or equipment failure. Recovery is described by procedure and access separation, not by the hope of finding a backup.
Digital asset reporting stops being assembled manually. Every movement is recorded with history and purpose, and a statement can be given to an auditor or regulator without reconstructing it from network logs.
The effect of custodial storage is measured by three numbers: asset reconciliation time, share of operations with manual entry, and number of access incidents.
Options for connecting to custodial storage
The connection scheme is chosen at one fork: who holds the keys and over what volume of assets the provider gets authority. After that it is a configuration question — which addresses go on the whitelist, what delay is set on withdrawal, who is the second signer on a transaction.
| Option | When it fits | Limitations |
|---|---|---|
| Full transfer of assets to the custodian | A regulated custody perimeter and audit reporting are needed, transactions are infrequent | Every movement goes through the provider's policy: withdrawal delay, address whitelist, mandatory second signer |
| Hybrid model | Part of the reserve in a cold perimeter, part in operational circulation for frequent payouts | Two accounting perimeters: we build reconciliation of balances and limits between them ourselves, otherwise balance discrepancies |
| Custodian only as a settlement counterparty | Keys remain with the team, the provider is needed for trades and storage during the transaction | The custodian is not responsible for assets outside its perimeter, key risk is entirely ours |
| Joint signing (multisig) | Need so that neither party can withdraw funds alone | Arbitrary signature threshold schemes are not always supported, signer composition is agreed in advance |
Regulated custody and settlement are covered by Anchorage Digital, but the asset access model is set on the provider's side, not in our code — this is the main limitation of a custodian.
Hybrid asset storage
In practice, the scheme looks like this: the main reserve is with the custodian, the operational buffer is in our own multisig with a limit per transaction.
Withdrawal policies, address whitelist, and signature threshold are tested in a test perimeter with real payout scenarios before launch. This arrangement separates risks: large amounts under policy, current operations without approval delay.
Integration stages: audit, design, connection, verification
Connection to Anchorage Digital follows a fixed order: first we describe what we own and who manages what, then we design data exchange, and only after that do we touch working assets.
Access is not granted before responsibility is fixed, so each step has a verifiable result that can be presented to internal audit.
- Asset storage audit — inventory of wallets, networks, and asset types, reconciliation of balances with the accounting ledger, decision for each flow: goes into regulated custody or remains in the hot perimeter.
- Roles and confirmations scheme — who initiates a transfer, who confirms, where a second signature is required, how limits are set. The output is an access matrix agreed by security and finance.
- Integration design — connection method, data exchange format with the accounting system, discrepancy analysis, and behavior when an external service is unavailable.
- Assembly in a test perimeter — isolated environment and scenarios: deposit, outgoing transfer, rejected signature, resynchronization after a failure.
- Test operation — a minimal transfer with real assets with the full confirmation route and reconciliation of balances, statements, and logs.
- Handover to production — operator training, access issuance on a least-privilege basis, escalation procedures, and support for the first operations.
The output includes the role matrix, procedures, and operation logs: internal audit uses them, and a new employee can join the work without rebuilding the scheme.
Configurations, access policies, and handover procedures
Integration with Anchorage Digital is considered complete not when the first transfer has gone through, but when your team manages access and operation confirmation without us.
Therefore the entire perimeter is fixed in configurations and procedures that remain with the client: they can be reread, handed over to a new administrator, and presented to an auditor.
- Asset access policies — initiator, confirmer, and observer roles, limits per operation and daily turnover, whitelist of recipient addresses.
- Payout confirmation procedure — how many signatures are required, who is in the quorum, how to act if one participant is unavailable, and how to arrange an urgent withdrawal.
- Funds flow scheme — the path of a request from creation to deposit, points where the operation stops, and the list of events sent to your accounting system.
- Custody documentation — key material isolation levels, metadata backup, rotation procedure for control panel access.
- Access recovery procedure — scenarios for loss of a confirmation device, departure of an employee with a role, and account lockout, with recovery time and owner for each.
- Operator instructions and audit log — guides for standard actions, cancellation of an erroneous request, export of operation history for reconciliation and reporting.
Handover comes with a walkthrough: we go through each scenario in the test perimeter so administrators see system behavior, not just a description. After that, you change policies yourselves — we remain on support, but not as the only holders of access.
Case study: moving custody and payouts to an external custodian
The client is a digital asset payout service: a daily stream of transactions plus large settlements with partners.
Keys were on their own servers, signatures were collected manually — an on-duty engineer confirmed every payout, and balance reconciliation was done by exporting from the internal database and reviewing in spreadsheets.
The cost of this scheme consisted of three parts.
More than forty manual asset operations passed per day, reconciliation consumed up to six hours of working time, and a failure in the signing queue left a payout in an indeterminate status: support could not tell the client whether the transaction had gone through or not.
We moved custody and settlement to an external custodian Anchorage Digital — keys remained in the perimeter of the regulated custodian, and an integration layer appeared on the service side.
Signing rules (limits, allowed recipient list, separate initiator and confirmer roles) were transferred into the custodian's policies, and operation statuses began arriving as event notifications and immediately entering the accounting system.
- manual asset operations: from 40+ per day to 3 — only settlements above the policy limit;
- reconciliation: from 6 hours to 15 minutes, discrepancies are caught by operation identifier;
- stuck payouts: the class is closed — confirmation is idempotent, resending does not create a second transaction;
- share of signatures involving an engineer: from 100% to 5%.
The changes took several weeks in stages: first routing new deposits to custodial addresses, then moving regular payouts, and finally historical balances.
This order left the ability to roll back to the previous perimeter at any step while the share of operations through the custodian grew.
How does custodial storage differ from self-custody?
The difference is who physically holds the private key and who is responsible for the assets. In self-custody, keys live in your infrastructure: you build the access separation scheme, backup, rotation, and operation audit yourself.
Full control over disposal is paid for by the fact that all responsibility for assets is yours, including errors by your own employees.
The custodial model moves key storage into the provider's secure perimeter.
Anchorage Digital holds keys in an isolated environment, transaction signing happens inside it, and you retain the role of disposer: you set the rules — which addresses are allowed, who and in what composition confirms a transfer, which limits apply.
Regulatory requirements are covered differently: the custodian has a license, reporting, and mandatory segregation of client assets from its own, and some checks are replaced by its documents rather than your internal department.
In operation speed, the models diverge at the start and on changes. Self-custody is faster when you need to urgently change the signing policy: it is your infrastructure, with no external approvals.
A custodian takes longer to connect — verification of disposers, role setup, allowed address lists — but after that operations proceed under procedure without manual actions.
The key difference is the consequences of key compromise. In self-custody, a key leak or loss of a share in a multisig scheme means irreversible loss: a signed transaction cannot be rolled back, and recovery is possible only if a backup was stored separately and verified.
In the custodial model, this risk shifts: compromise of a disposer account and an error in the signing policy remain, but loss of the key itself is no longer your scenario; the provider is responsible for its safekeeping and recovery.
Practical conclusion: the choice is not between "secure" and "insecure," but where you transfer responsibility. If you need regulated asset turnover and external reporting, a custodian removes part of the load.
If full control is more important and there are no external requirements, self-custody remains workable, but it requires its own security function and backup discipline.
Technical concerns before connecting to a custodian
Before connecting to a custodian, engineers and business leads have the same questions: what happens to already issued assets, who gets access when the responsible person changes, and how balances of external custody reconcile with internal accounting. Below are short answers to those most often heard in technical sessions before launch.
How does asset migration work?
In stages. First an inventory of addresses, signers, and balances, then a trial transfer of a small share of the volume and reconciliation of the result. Only after the amounts match is the remainder transferred, and old keys remain in quarantine — in case of rollback.
What happens to access when the responsible person changes?
Rights are tied to roles and a signing policy with a threshold, not to a specific person. When the responsible person changes, the mandate is reissued, access keys are rotated, and the approval log and operation history are fully preserved.
How is data reconciled between the custodian and our accounting?
Daily: an export of operations and balances is matched against internal ledgers by transaction identifiers and addresses. Discrepancies enter a review queue with an owner and deadline, rather than being corrected manually in the balance.
Is it realistic to connect Anchorage Digital to internal systems?
Yes. The software interface covers transfer creation, statuses, and balances; events arrive as subscription notifications. We verify notification signatures and process the events themselves idempotently by identifier — repeated delivery does not duplicate entries.
Let's discuss the task: where connection begins
A conversation about connecting to Anchorage Digital is productive when answers about the current storage scheme are gathered in advance. Below is what to prepare for discussion and how the work is structured further.
- Breakdown of the current scheme: where private keys are stored, who has signing authority, and how roles are divided between employees and services.
- List of assets and networks: which coins and tokens you service, on which networks, whether staking and delegation are needed.
- Funds movement processes: how deposits, withdrawals, and internal transfers work, who initiates and confirms operations.
- Compliance requirements: jurisdictions, counterparty restrictions, reporting rules, and who is responsible for checks.
- Transaction accounting: how movements reach accounting, which exports and formats are needed on output.
- External integrations: which of your services should see balances and operations, whether you have a software interface on your side.
- Environments and access: whether separate perimeters are needed for testing and production, which roles are agreed.
After the review, we return with an estimate of the scope of work: what we do with the team, what depends on your side and on the provider's checks.
Then we prepare a custody implementation plan — stages, dependencies between them, and points where you decide to move to the next step. Preparation for connection runs in parallel with setting up accounting and access so that launch does not stall on uncoordinated details.