- A digital asset initiative is a business decision first and a technology project second.
- Six questions, answered in writing, make approvals faster and shorten vendor conversations.
- If you cannot answer one of them yet, that is where the first piece of work should go.
A digital asset initiative usually begins with a good reason: a board request, client demand, a competitor's announcement or a vendor's pitch. It often then stalls in review, because the questions that risk, compliance and finance ask first are the ones the project team has not answered. The six questions below are the ones we would settle in writing before choosing a vendor or drafting a specification.
What problem are we solving, and for whom?
Write the answer in one sentence. “Offer clients access to digital assets” is a direction, not a problem. “Let our wealth clients hold a small allocation without leaving our platform” is a problem with a client, a product and a boundary. The same discipline applies to defensive cases, such as keeping clients who would otherwise move assets elsewhere, and to internal cases, such as settling with counterparties in stablecoins.
If the answer needs more than two sentences, there are probably two initiatives. Separate them, because they will have different owners, risks and approval paths.
Which assets and activities are in scope?
“Digital assets” covers instruments with very different risk and regulatory profiles. Holding a stablecoin for settlement is not the same as offering clients exposure to a volatile asset, and neither is the same as tokenizing a deposit or a security. For each of the following, state whether it is in scope, out of scope or deferred.
- Stablecoins used for payments and settlement
- Tokenized deposits and other tokenized instruments
- Direct exposure to assets such as bitcoin and ether, for clients or for the balance sheet
- Custody and safekeeping
- Trading, execution and market access
Each item raises its own questions with regulators and supervisors. An explicit scope statement stops the initiative from growing during approvals, and gives your supervisor a clear picture of what you are and are not doing.
Who is accountable, and who approves?
Name an executive sponsor, a risk owner and a compliance owner. Name the committee with authority to approve the initiative and any later change to its scope. Initiatives without a clear approval path tend to circulate between committees, each of which sees only one aspect. Agree in advance what each approver needs to see, and put it in the plan.
Build, partner or wait?
Most institutions will partner for at least part of the stack, particularly custody and technology. That is a sound choice, and it should still be a decision rather than a default. Write down the criteria you will use. We usually start with these.
- Control over the client experience and client data
- Time to market, against the cost of building and maintaining
- Where regulatory responsibility sits for each activity
- Concentration risk and dependence on a single provider
- How you would exit, and what exit would cost
Waiting is also a legitimate answer, provided it is chosen deliberately and revisited on a set date. An explicit “not yet, review in six months against these triggers” is a better outcome than an initiative that drifts.
What controls must exist before the first client or the first dollar?
Define launch readiness before the build starts, not at the end. At a minimum, agree what must be in place for custody and segregation of assets, authorization of transactions, reconciliation, vendor oversight, incident response, client disclosures, and reporting to management and the board. Risk, compliance and internal audit should see this list early. It is far cheaper to design controls into a product than to retrofit them after a review.
What would make us stop?
Agree limits and exit criteria at the start: maximum exposure, maximum volumes during a pilot, the supervisory feedback that would pause the work, and what happens if a key vendor fails or exits. Stop criteria protect the institution, and they make approval easier, because the committee is approving a bounded pilot rather than an open commitment.
Putting the answers together
Taken together, the answers form a short decision paper: a problem statement, a scope, an owner, a sourcing approach, a launch-readiness list and a set of limits. That is usually two to four pages, and it is the document that lets a committee say yes.
This article is general information and reflects our own approach. It is not legal, regulatory or investment advice.