Why institutional onchain finance needs a clearer connection between identity, wallets, and transaction authority
On October 28, 2026, DTCC announced the launch of its Tokenization Service, enabling eligible users to convert DTC-custodied securities entitlements between traditional and tokenized forms. The service launched with connectivity to the Canton Network and DTCC’s private Besu network, marking another concrete step toward operational tokenized markets. DTCC’s launch announcement
The immediate appeal is asset mobility: securities that can move more efficiently and become easier to deploy across financial workflows.
But faster movement raises a separate question.
When a wallet submits a valid transaction, what establishes that the person or system behind it is entitled to move those assets on behalf of an institution?
This is not an assessment of DTCC’s controls. It is a broader design question for institutional onchain finance. Moving an asset, identifying its owner, and authorizing its use are connected tasks—but they are not interchangeable.
The next phase of tokenization should make those connections explicit.
A verified institution is only the beginning
Consider a hypothetical fund preparing to post tokenized securities as collateral.
The fund has completed business verification. Its account is active. An operations employee prepares an instruction from a wallet associated with the fund.
Everything may look ready. Yet several questions remain.
Does the wallet represent this fund, another vehicle managed by the same firm, or a custody arrangement serving multiple clients? Is the employee permitted to initiate the instruction, approve it, or both? Does that permission cover this asset, destination, and amount?
A business verification result does not, by itself, answer all of them.
For this workflow, the important distinction is between establishing the institution’s identity and establishing the authority behind a particular action. A fund can remain a valid customer while an employee changes roles, a mandate expires, or an account’s permitted activities are restricted.
The design objective should therefore be more precise than attaching a “verified” label to a wallet.
It should connect an identifiable institutional relationship to a current, bounded permission.
A valid signature is not the whole approval
Digital signatures provide essential cryptographic evidence. NIST’s Digital Signature Standard describes their role in detecting unauthorized changes to signed data and authenticating the signatory. That evidence is foundational, but it does not independently establish the business meaning of an instruction. NIST Digital Signature Standard
In the fund example, a successfully verified signature does not automatically establish that the transaction received the required internal approval.
The signing process could be technically correct while the instruction exceeds an operational limit or falls outside the employee’s assigned responsibilities.
This does not make signatures inadequate. It means they need to sit within an authorization process.
That process might use custody controls, approval workflows, smart-account rules, or a combination of mechanisms. The implementation can vary. The question should remain consistent: what evidence connects this signed instruction to a valid institutional decision?
Adding more signatures can strengthen a control, but the number alone is not the complete answer. The institution still needs to define whose approval counts, in what capacity, and for which actions.
Permission should describe the action
“Authorized user” is a useful starting label, but an incomplete transaction policy.
The hypothetical employee might be allowed to prepare collateral instructions without approving withdrawals. A supervisor might approve transactions within a defined limit but require another approver above it.
A permission to transfer assets should not silently become permission to pledge them, redeem them, or change the account’s security settings.
This action-specific approach has an established foundation in access-control design. NIST’s guidance on attribute-based access control evaluates the subject, the resource, the requested operation, and relevant environmental conditions against a policy. NIST’s ABAC guidance
Applied to our example, a useful authorization request would identify the institution and account, the asset and amount, the intended operation, the destination, and the approval conditions.
These are proposed design considerations, not a universal regulatory checklist.
Their value is that they make ambiguity visible before execution. If approval was granted for one destination, changing that destination should trigger a fresh decision rather than inherit the earlier approval.
Authorization needs a lifecycle, not just a checkbox
Now suppose the employee prepares the collateral instruction in the morning, but their permissions are withdrawn before it is executed.
A system that checked access only at login could miss the change. Equally, a transaction approved yesterday may need reassessment if its amount or receiving account changes today.
For this hypothetical workflow, the authorization design should specify when permissions are evaluated, how long an approval remains usable, and which changes invalidate it.
It should also address the interval between approval and execution. An approved instruction should be bound to its relevant transaction details so that it cannot be repurposed for a materially different action.
Failure handling matters just as much. If the system cannot establish whether a permission is still valid, it needs a defined response: pause, reject, or route the instruction for review under an approved exception process.
Revocation is not a time machine. Withdrawing a permission should prevent inappropriate future use, but it does not automatically reverse a transaction that has already completed.
Recovery requires its own operational and legal arrangements.
Better evidence does not require universal disclosure
Making authority more explicit does not mean distributing the fund’s entire corporate file to every participant in a transaction.
Different parties need different evidence.
An execution service may need confirmation that an instruction satisfies an approved mandate. A compliance team may need access to underlying records. An auditor may need to reconstruct which policy and approvals supported the decision.
Those needs should not collapse into one universally visible data package.
Verifiable credentials can help express claims in a machine-verifiable form. However, the W3C data model distinguishes verifying a credential from deciding whether to rely on it: the verifier still applies its own policies to the issuer, subject, and claims. W3C Verifiable Credentials Data Model
For the fund, this suggests an important separation. Evidence that an organization exists should come from an appropriate source. Evidence that someone may act for it should come from an authority entitled to grant that permission.
A trusted source for one claim is not automatically trusted for every claim.
Where suitable credential formats and proof systems are available, selective disclosure or zero-knowledge proofs can limit what a verifier learns. They do not create a corporate mandate, correct an inaccurate source record, or replace required due diligence.
An audit trail should explain why the action was allowed
A transaction record can show that an asset moved. The institution also needs to understand why its systems permitted that movement.
For the hypothetical collateral workflow, a useful decision record would connect the executed instruction to the relevant account relationship, authorization evidence, policy version, and approval outcome.
It should also distinguish an ordinary approval from an exception.
This is more informative than a historical “KYC passed” flag. It allows a reviewer to investigate whether the transaction matched the permission that was actually granted.
The record does not have to place sensitive evidence on a public ledger. A more appropriate design may retain protected evidence offchain while maintaining reliable references between the decision and the transaction.
Retention, access, and disclosure should follow the applicable requirements and the institution’s governance arrangements.
The objective is not to make every participant’s information visible. It is to make the decision explainable to the parties entitled to review it.
Where privacy-preserving identity fits
zkMe’s published design philosophy emphasizes privacy-preserving credentials, zero-knowledge processing, and selective disclosure. These principles are relevant to how institutions establish necessary facts without unnecessarily circulating the underlying information. zkMe’s design philosophy
In an institutional transaction architecture, identity evidence can support an authorization decision. It should not be confused with the entire authorization system.
The institution must still establish mandates, assign responsibilities, define transaction policies, and connect those policies to execution controls. Custody, asset eligibility, transaction risk, and legal enforceability remain separate considerations.
The opportunity is to make identity evidence a dependable input to those controls—not a substitute for them.
For builders, a practical starting point is to follow one transaction from request to completion. Identify every place where the workflow assumes that a wallet, employee, or service is entitled to act. Then ask what supports that assumption, when it expires, and how it can be withdrawn.
Tokenization can reduce the friction of moving assets. Institutional confidence depends on reducing ambiguity around the movement.
The goal is not simply a faster transaction.
It is a transaction whose authority is clear before execution—and whose approval can be explained afterward.