A score answers which platform is best in general. It cannot answer whether a platform meets your requirements, because the weighting is ours and the requirements are yours. These twelve briefs invert that. Each one is a real buying situation with requirements that are testable against a custody arrangement rather than against a brand.
They are published before any platform has been evaluated against them, which is the only order in which a test means anything. Two of the twelve are briefs that multi-institution custody fails, including the model our publisher operates. A test nobody fails measures nothing.
Three possible answers
- fits
- Meets every hard requirement, with evidence on the record
- fails
- Fails at least one hard requirement, or hits a disqualifier
- insufficient
- The requirement is answerable in principle, but the provider has not published what a buyer would need to see. Not a pass and not a failure: an absence.
Most answers in this category should be the third one. Providers publish what sells, not what a buyer needs to verify, and recording that gap honestly is more useful than guessing.
Brief 1
Family office moving off an exchange
A family office holds bitcoin on a trading venue and wants professional custody without adding operational work internally.
Hard requirements
- Client bitcoin is segregated from the provider's own assets and from other clients' assets
- More than one party must authorise any movement of funds
- Insurance, if claimed, names what it covers and what it excludes, with a limit and an as-of date
- Independent examination of custody operations, such as a SOC 2 Type II report, available to the client
Automatic disqualifiers
- Bitcoin stays in a trading account at the same entity that operates the exchange
- Any single employee can move client funds without a second approval
Evidence needed
Custody agreement showing segregation, written authorisation procedure, insurance certificate or policy summary with limits and exclusions, most recent examination report.
Brief 2
RIA that must use a qualified custodian
A registered investment adviser holds client bitcoin and must satisfy the SEC custody rule for advisers, Advisers Act Rule 206(4)-2.
Hard requirements
- The custodian is a bank, broker-dealer, futures commission merchant or an entity the adviser has a documented basis to treat as a qualified custodian
- Client assets are segregated from the custodian's proprietary assets and identifiable to each client
- Independent verification of holdings on a stated cadence
- The custody agreement prohibits lending, pledging or transferring client assets without the client's consent
Automatic disqualifiers
- The provider holds client assets in commingled accounts with no per-client identification
- The provider describes itself as a custodian but cannot point to a charter, licence or basis a compliance officer could rely on
Evidence needed
Charter or licence documentation, the custody agreement's segregation and rehypothecation clauses, the verification report, and any regulatory relief the arrangement relies on. The SEC staff's September 2025 no-action letter on state-chartered trust companies is relevant here and the conditions it sets should be checked rather than assumed.
Brief 3
Company treasury with board reporting duties
A company holds bitcoin on its balance sheet and the board requires oversight of who can move it and a record of what happened.
Hard requirements
- A complete authorisation trail showing who approved each movement and when
- Bitcoin held separately from operating accounts
- Balance and transaction reporting the finance team can pull on demand
- Approval thresholds configurable to the company's own delegation of authority
Automatic disqualifiers
- A single employee of the company or the provider can move funds alone
- No exportable record of approvals
Evidence needed
Custody agreement, a sample authorisation log, the reporting interface or API, and written confirmation that approval rules are enforced by the arrangement rather than by internal policy alone.
Brief 4
Buyer insists on personally holding a key
The buyer wants institutional help but will not accept an arrangement where they hold no key. They want a key that cannot be bypassed.
Hard requirements
- The buyer holds at least one key in a quorum where their signature is required, or can veto
- Funds cannot move without the buyer's key or the buyer's documented consent
- Documentation showing which keys exist, who holds them, and the signing threshold
- The buyer can verify their key's role independently, without trusting a dashboard
Automatic disqualifiers
- Every key sits with institutions and the buyer holds none
- The provider can move funds using internal approvals only
Evidence needed
Key distribution documentation, the signing policy, and a demonstration that a transaction cannot complete without the buyer's participation.
Publisher disclosure. Multi-institution custody fails this brief by design, including Onramp's. The holder holds no key. If this requirement is genuine, collaborative custody or self-managed multisig is the category to shop in.
Brief 5
Buyer refuses to manage any hardware
The buyer will not store a device, will not write down a seed phrase, and will not be responsible for anything physical.
Hard requirements
- No hardware device required of the buyer at setup or for ongoing access
- No seed phrase or backup material held by the buyer
- Access through software the buyer already uses, with account recovery that does not depend on the buyer's own key material
- A documented path for the buyer's heirs that also requires no hardware
Automatic disqualifiers
- Setup requires the buyer to initialise or hold a hardware wallet
- Recovery depends on a seed phrase the buyer is expected to have kept
Evidence needed
Onboarding documentation, the recovery procedure, and written confirmation that no backup material is the buyer's responsibility.
Brief 6
Inheritance for a non-technical spouse
The holder wants a spouse with no bitcoin experience to be able to reach the funds after their death without hiring an expert.
Hard requirements
- A written procedure the surviving spouse can follow without understanding keys, wallets or the blockchain
- A named human or institution the spouse can contact, with a stated response commitment
- A path that does not require probate, or a clear statement that probate is required
- The procedure is testable while the holder is alive
Automatic disqualifiers
- Recovery requires the spouse to handle key material or run software
- The only instructions are written for a technical reader
Evidence needed
The inheritance documentation as the spouse would receive it, the beneficiary mechanism, and evidence that someone has walked the procedure end to end.
Brief 7
Trust or entity ownership
Bitcoin belongs to a trust, LLC or corporation, and the arrangement has to recognise the entity rather than an individual.
Hard requirements
- The account is titled to the entity, with entity documentation accepted at onboarding
- Authorisation follows the entity's governance, including multiple trustees or officers where required
- Trustee or officer changes can be processed without moving the bitcoin
- Reporting suitable for the entity's accountant or auditor
Automatic disqualifiers
- Only individual accounts are available
- A single trustee can move funds where the governing document requires two
Evidence needed
Account agreement showing entity titling, the authorisation matrix, and the documented process for changing an authorised person.
Brief 8
Same-day access
The buyer needs to be able to move bitcoin out on the same business day, because the position backs an operational need.
Hard requirements
- A published time from request to broadcast, measured in hours
- No holding period before a withdrawal becomes eligible
- A documented path when the primary approver is unavailable
- Any limit or velocity cap stated up front
Automatic disqualifiers
- Settlement takes more than one business day as a matter of policy
- Withdrawals are discretionary or require a support ticket with no stated turnaround
Evidence needed
Service commitment in writing, the withdrawal procedure including the out-of-hours path, and any published record of actual times.
Brief 9
Holding under $100,000
The buyer holds less than $100,000 in bitcoin and wants better than an exchange account without paying institutional prices.
Hard requirements
- Minimum account size at or below the buyer's balance
- All-in annual cost stated as a number the buyer can compute before signing
- No fee that scales in a way that makes a small balance uneconomic
Automatic disqualifiers
- A minimum that excludes the buyer
- Pricing available only on application, with no published figure
Evidence needed
Published fee schedule and minimums, plus a worked example at the buyer's balance.
Brief 10
Holding over $10M
The buyer holds more than $10M and needs the arrangement to survive scrutiny from a board, an auditor and an insurer.
Hard requirements
- Insurance terms disclosed: carrier, limit, whether the limit is per client or an aggregate, and what is excluded
- No shared key material or shared signing infrastructure across clients, or a clear explanation of what is shared
- Named operational contact with a response commitment
- Independent examination of custody operations within the last twelve months
Automatic disqualifiers
- Insurance described only as a headline number with no terms
- No independent examination available to the client
Evidence needed
Policy summary with limits and exclusions, architecture documentation covering key isolation, the most recent examination report, and the support agreement.
Brief 11
Business that needs an API
A business needs programmatic custody: balances, transfers and approvals inside its own systems.
Hard requirements
- Documented API covering balances, transfers and approval state
- Approval policy enforced server side, not by the calling application
- Audit log retrievable through the API
- Published rate limits and a sandbox
Automatic disqualifiers
- Transfers only through a web interface
- API keys that can move funds with no second factor or policy check
Evidence needed
Public API documentation, the policy engine description, sandbox access, and a sample audit log.
Brief 12
Buyer needs assets other than bitcoin
The buyer wants one custody relationship covering bitcoin plus stablecoins or other assets, with one set of controls and one report.
Hard requirements
- Bitcoin and at least one other asset class under the same arrangement
- One set of authorisation rules across assets
- Consolidated reporting
Automatic disqualifiers
- Bitcoin only
- Other assets supported through an unrelated third party with separate controls
Evidence needed
Supported asset list, the authorisation model across assets, and a sample consolidated statement.
Publisher disclosure. Bitcoin-only providers fail this brief, including Onramp. That is a deliberate product choice on their part and a genuine disqualification for this buyer.