Exchange, Custody, and Trading Authority Architecture for Digital Asset Funds | CV5 Capital

Digital asset funds operate in an environment that has no close parallel in traditional fund management. Markets run continuously. Assets move on chain with finality in minutes or seconds, and a single private key or API credential can authorise a transfer that is irreversible. Funds interact with multiple centralised exchanges, OTC counterparties, custodians, wallet layers, and settlement pathways simultaneously, each with its own permission model and risk profile.

In this environment, operational resilience is determined less by the quality of a fund's investment thesis and more by the rigour of its authority architecture: who can do what, from where, under which approvals, and with what evidence trail.

Most high profile fund failures and operational incidents in the digital asset space have not been caused by poor investment decisions. They have been caused by authority and control failures: excessive permissions, blurred ownership boundaries, undocumented access, and governance that existed on paper but not in practice. Launch stage shortcuts made under time pressure have a pattern of creating long term governance, audit, and fundraising problems that are far more expensive to remediate than to prevent.

For allocators and institutional investors, the diligence focus has shifted accordingly. Operational due diligence teams increasingly evaluate a fund's control design, not just its return profile. The authority architecture, meaning the documented, enforceable framework governing how exchange accounts, custody arrangements, trading permissions, and asset movements are governed, has become a board level and investor confidence issue, not merely an operational detail.

Defining the Authority Architecture

Authority architecture refers to the structured framework that determines how decisions are made, actions are executed, and oversight is maintained across every layer of a fund's operating model. It is not a single document or policy. It is the alignment of five distinct layers of authority, which often diverge unless intentionally designed to work together.

Legal authority defines who is legally entitled to act on behalf of the fund entity. This is established through constitutional documents, board resolutions, investment management agreements, and delegated authority schedules. Legal authority sets the boundaries within which all other layers must operate.

Operational authority defines who can practically execute actions within the fund's day to day operations. This includes the individuals or teams authorised to place trades, initiate transfers, manage exchange accounts, and interact with service providers. Operational authority should flow directly from, and be bounded by, legal authority.

Technical permissions define who can execute actions at the system level: API keys, wallet signer roles, exchange account credentials, policy engine configurations, and custodian portal access. Technical permissions are where authority architecture is either enforced or undermined. If the system allows an individual to perform an action that exceeds their authorised role, the governance framework has a gap regardless of what the policy documents say.

Governance authority defines who can approve policy, set limits, authorise exceptions, and amend the framework itself. This typically sits with the fund board or operator, with defined delegations to the investment manager and compliance function.

Oversight and monitoring rights define who can view activity, reconcile records, and challenge actions. This includes the administrator, auditor, compliance function, and in some structures, the fund board or operator. Oversight rights should be independent of execution authority, ensuring that those who act and those who monitor are not the same individuals.

A robust authority architecture ensures these five layers are documented, aligned, and technically enforced. Where they diverge, whether through informal practices, undocumented access, or system configurations that exceed policy, the fund's operational integrity is compromised.

The Core Components of a Fund's Authority Architecture

A digital asset fund's operating stack involves multiple entities and systems, each requiring clear authority boundaries. The following components should be addressed in any authority architecture design.

Fund entity and board or operator. The board (or operator, depending on the fund's domicile and structure) holds ultimate governance authority. It approves the operating model, authority matrix, venue and custodian selection criteria, and material policy changes. It should receive periodic reporting on access reviews, exceptions, and incidents. The board should not be involved in day to day execution but must have confidence that actual practice matches approved policy.

Investment manager or adviser. The manager operates under delegated authority defined in the investment management agreement. This delegation should specify the scope of trading authority, the types of instruments and venues permitted, concentration and exposure limits, and any restrictions on asset movement. The manager's authority to trade should be clearly distinguished from authority to move assets off exchange or out of custody.

Custodians. The custodian's role, authority, and obligations should be defined in a formal custody agreement. Key considerations include signer roles and approval thresholds, transaction limits, address whitelisting controls, and the custodian's right to reject or delay transactions that fall outside agreed parameters.

Wallet infrastructure and policy engines. Where funds use wallet infrastructure with policy layers (such as those offered by institutional custody technology providers), the policy configuration itself becomes part of the authority architecture. Transaction rules, approval workflows, whitelists, and spending limits should reflect the fund's governance framework and be subject to change control.

Centralised exchanges. Exchange accounts require clear ownership, role based access, and segregation of trading permissions from withdrawal permissions. The fund entity, not the investment manager or any individual, should be the account holder. Access roles should follow the principle of least privilege, and changes to permissions or whitelisted addresses should require documented approval.

OTC counterparties and settlement agents. OTC relationships introduce bilateral counterparty risk and settlement workflows that may involve pre funding or post trade delivery. Authority to onboard new OTC counterparties, agree settlement terms, and authorise asset movements for settlement purposes should be defined and subject to governance approval.

Administrator and NAV provider. The administrator requires read only access to exchange accounts, custodian records, and wallet data to produce independent NAV calculations and reconciliations. The administrator should not have execution authority, but its access must be sufficient to verify completeness and accuracy of the fund's position data.

Banking rails and fiat settlement. Authority over fiat accounts, including the ability to initiate wire transfers, approve payments, and manage banking relationships, should be subject to the same multi party approval and segregation of duties principles applied to digital asset movements.

Compliance, AML, and risk oversight. The compliance function requires monitoring access across venues, custodians, and wallets, with the authority to escalate concerns, restrict activity, and invoke incident response procedures. Compliance authority should be independent of the investment team and should not be subordinated to trading priorities.

Exchange Account Architecture

Exchange account setup is one of the most common areas where launch stage shortcuts create persistent governance problems. Several practical considerations apply.

Account ownership should sit clearly with the fund entity, not with the investment manager, a principal of the manager, or any individual. Accounts held in individual names or under a manager entity rather than the fund create legal ambiguity around asset ownership, complicate audit verification, and raise immediate red flags in any institutional due diligence process.

Role based access should follow the principle of least privilege. Individuals should have only the permissions required for their specific function. A portfolio manager needs trading permissions; they should not need withdrawal authority, API key management rights, or the ability to modify account settings. Operations staff who manage settlements may need transfer permissions but should not have trading authority.

Trading permissions and withdrawal permissions should be treated as separate, independently controlled authorities. This is one of the most important control design decisions in a digital asset fund, and it is discussed in detail in the following section.

API key governance is frequently neglected at launch and becomes a material control gap as the fund scales. Every API key should be inventoried, scoped to the minimum permissions required, restricted by IP address where the platform supports it, rotated on a defined schedule, and subject to revocation procedures when staff depart or roles change. Undocumented API key sprawl is a common audit finding and a legitimate allocator concern.

Sub account structures, where supported by the exchange, can provide useful segregation between strategies, between trading and treasury functions, or between assets under different management mandates. The governance framework should document the purpose of each sub account and the access rights associated with it.

Changes to permissions, whitelisted withdrawal addresses, or account configurations should require documented approval through a defined change control process. Emergency access and break glass procedures should exist for scenarios where normal approval workflows are unavailable, but these procedures should be documented, tested, and subject to post event review.

The statement "the PM has the login" is not a fund grade control framework. It may be pragmatic at the earliest stage of a fund's life, but it creates concentrated risk, eliminates segregation of duties, and will not withstand institutional due diligence scrutiny.

Custody and Wallet Authority Design

Custody and wallet architecture should implement the fund's authority framework at the technical level, translating governance decisions into enforceable controls.

Signer roles and approval thresholds. Custody arrangements should define who can sign transactions, what approval thresholds apply for different transaction types and sizes, and how signer roles are assigned, modified, and revoked. Multi party approval requirements should be the default for material transactions, with the specific threshold calibrated to the fund's risk appetite and operational requirements.

Policy based transaction controls. Where the custody infrastructure supports policy engines, funds should implement rules governing permitted destination addresses, transaction amount limits (per transaction and within defined time periods), permitted asset types, and time based restrictions. These policies should be documented and subject to change control.

Address whitelisting and change control. Whitelisted addresses should be approved through a defined process, documented with their purpose and ownership, and subject to periodic review. Adding or modifying whitelisted addresses should require multi party approval and should be logged.

Separation of wallet functions. Funds should maintain clear separation between wallets used for different purposes: long term custody (cold storage), active trading (exchange or hot wallets), settlement (for OTC and counterparty transactions), and treasury or operational accounts. The governance framework should define the rules for moving assets between these categories, including approval requirements and size limits.

Delegated operations roles vs investment team roles. The individuals who execute operational tasks (such as processing approved withdrawals or managing wallet infrastructure) should, where practicable, be separate from the investment team. This segregation of duties is a core control principle and becomes increasingly important as the fund scales.

Emergency freeze and escalation mechanisms. The fund should have documented procedures for freezing activity in the event of a suspected security breach, unauthorised access, or other incident. These procedures should define who can invoke a freeze, through what mechanism, and what escalation and communication protocols apply.

Trading Authority vs Asset Movement Authority

This distinction is one of the most critical and most frequently mishandled control design decisions in digital asset fund operations.

Trading authority is the permission to place orders, execute trades, and manage positions on an exchange or with a counterparty. Asset movement authority is the permission to withdraw, transfer, or move assets from one venue, wallet, or counterparty to another.

These two authorities serve different purposes, carry different risk profiles, and should be governed by different approval frameworks. Conflating them, which is common in early stage fund setups, creates a control environment where an individual authorised to trade can also move assets off the exchange entirely, without independent oversight.

Consider a practical scenario. A fund's portfolio manager is given full administrative access to an exchange account to facilitate rapid trading in a volatile market. That same access allows the PM to create withdrawal addresses, whitelist external wallets, and transfer assets off the exchange with no second party approval. The fund's offering memorandum describes multi party controls over asset movements. The actual system configuration provides single party access. This gap between disclosed controls and operational reality is precisely what allocator ODD processes are designed to detect.

The preferred approach is to structure exchange and custody permissions so that trading authority and asset movement authority are independently controlled:

Trading authority should permit order placement, position management, and strategy execution within defined parameters. Asset movement authority should require multi party approval, operate within whitelisted address constraints, and be subject to documented approval workflows.

Some exchanges and custody platforms support this separation natively through granular role based access controls. Where native platform controls are insufficient, compensating controls such as independent operations review, post trade reconciliation, and daily exception reporting should be implemented.

For allocators, the presence or absence of this separation is a high signal indicator of operational maturity. Funds that can demonstrate clear, enforceable segregation of trading and movement authority are better positioned in ODD outcomes.

‍

Authority Matrices and Delegated Powers

An authority matrix is the operational document that translates a fund's governance framework into a structured map of who can do what, under what approvals, and with what evidence trail. It should be maintained as a living document, reviewed periodically, and updated when roles, venues, or policies change.

A well constructed authority matrix maps each material action to the authorised role, the approval threshold, the system or location where the control is enforced, the evidence retained, the escalation path for exceptions, and the review frequency.

The authority matrix should align with the fund's board resolutions, investment management agreement, custody and exchange terms, offering memorandum disclosures, and internal policies and standard operating procedures. Where any of these documents are inconsistent with the matrix or with actual system configurations, the fund has a governance gap that should be remediated.

Governance and Board Oversight

Fund directors and operators, particularly in offshore structures such as Cayman Islands exempted limited partnerships or segregated portfolio companies, carry governance responsibilities that extend to the fund's operational control environment. While directors should not be involved in day to day execution, they should have visibility into, and approval authority over, the framework within which execution occurs.

At a governance level, boards and operators should typically expect to see and approve the following:

A documented operating model and asset flow map showing how assets move between custody, exchanges, counterparties, and banking rails. The authority matrix and delegated powers schedule described above. Venue and custodian approval criteria, including the due diligence standards applied before a new exchange, custodian, or counterparty is onboarded. Periodic access and permission review reports confirming that system level permissions remain aligned with approved authority. Incident reporting and exception logs, including any instances where emergency procedures were invoked or policy limits were breached. Concentration limits by venue and custodian, ensuring that no single counterparty or platform represents a disproportionate share of fund assets without board awareness. Policy update notifications when new blockchains, asset types, venues, or products are added to the fund's operating scope. Evidence that actual practice matches approved policy, which may take the form of compliance attestations, internal audit findings, or administrator confirmations.

This governance layer is not about creating bureaucracy. It is about ensuring that the board has the information it needs to discharge its oversight responsibilities and that allocators can see a credible governance chain from board level approval to system level enforcement.

Administrator, Audit, and Reconciliation Implications

Authority architecture has direct consequences for the fund's ability to produce accurate, auditable financial records.

Administrators require comprehensive, timely data to calculate NAV independently. This means read only access to exchange accounts, custodian portals, and wallet data. If the authority architecture does not provide the administrator with sufficient access, or if wallet and venue mapping is incomplete, the administrator cannot verify the completeness of the fund's position data.

Reconciliation is the process of matching on chain and off chain records across multiple wallets, exchanges, and counterparties. The complexity of this process is directly affected by the fund's authority architecture. Funds with clear wallet purpose documentation, well defined asset flow maps, and consistent venue structures produce cleaner reconciliations. Funds with undocumented wallets, informal transfer practices, and inconsistent venue setups create persistent reconciliation breaks.

Audit readiness depends on the availability of evidence. Every material action, from trade execution to asset movement to whitelist changes, should generate a contemporaneous record that can be produced during the audit process. If the authority architecture does not require evidence retention at each control point, the fund will face audit friction that could have been prevented.

Weak authority design is one of the most common root causes of downstream administration and audit problems. Investing in control architecture at launch pays dividends in reduced operational friction throughout the fund's lifecycle.

The Allocator and ODD Lens

Sophisticated allocators and operational due diligence teams evaluate a fund's authority architecture with increasing specificity. The following areas are commonly assessed.

Allocator and ODD Diligence Checklist: Exchange, Custody, and Trading Controls

Diligence Area Key Questions

Account ownershipIs the fund entity the named holder on all exchange and custody accounts?

Are there any accounts in manager or individual names?

Role based access

Does the fund implement least privilege access?

Are trading and withdrawal permissions independently controlled?

Authority matrixDoes a documented authority matrix exist?

Does it align with board resolutions, the IMA, and offering disclosures?

API key governanceAre API keys inventoried, scoped, IP restricted, and rotated?

What is the revocation process for departing staff?

Whitelist controlsHow are whitelisted addresses approved, documented, and reviewed? Who can add or modify entries?

Custody signer structureWhat approval thresholds apply for custody transactions?

Are multi party controls enforced at the system level?

Segregation of dutiesAre execution, approval, and oversight roles held by different individuals?

Where is the segregation enforced?

Venue concentrationWhat percentage of fund assets is held at any single exchange or custodian?

Are concentration limits in place?

Incident responseDoes a documented incident response protocol exist?

Has it been tested?

What escalation and notification procedures apply?

Access recertificationHow frequently are permissions reviewed? Is there a formal recertification process?

When was the last review conducted?

Administrator access

Does the administrator have independent read only access to all venues and custodians?

Are there any gaps in data coverage?

Policy and governance alignment

Does the fund's actual control environment match what is described in offering documents and policies?

Allocators will typically request copies of the authority matrix, access review reports, sample approval workflows, and asset flow diagrams. They may also request evidence of recent access recertification and incident response testing.

Red flags that trigger allocator concern include disclosures that describe controls which are not operationally enforced, excessive reliance on individual trust rather than system level controls, inability to produce documentation of the authority framework, and reluctance to discuss control design with specificity.

Seeders may negotiate enhanced governance rights, including board observer seats, access to periodic control reports, approval rights over new venue onboarding, and notification requirements for material changes to the authority framework.

Common Failure Modes and Red Flags

Several weak points recur across digital asset fund setups. Managers and allocators should be alert to the following patterns:

Blurred ownership or control boundaries between the fund entity and the investment manager, particularly where exchange or custody accounts are held in the manager's name rather than the fund's.

Shared credentials or informal access practices where multiple individuals use a single login or know a shared password, eliminating individual accountability.

Excessive administrative rights retained by traders, where portfolio managers hold withdrawal, whitelist, or account configuration permissions beyond what their role requires.

No functional distinction between trading permissions and withdrawal or transfer permissions, creating single party control over asset movement.

Undocumented API key sprawl, where keys are created for integration or testing purposes, granted broad permissions, and never inventoried, rotated, or revoked.

No change control process for whitelists, policies, or permissions, allowing modifications to be made informally without documented approval.

No periodic access recertification, meaning permissions granted at launch are never reviewed or adjusted as roles and staffing change.

Emergency procedures that exist only verbally or informally, with no documented protocol, no testing, and no post event review mechanism.

An authority matrix that is inconsistent with actual system configurations, meaning the documented framework does not reflect how controls are actually enforced.

Offering disclosures that overstate the controls in place, creating a gap between what investors are told and what operationally exists.

Addition of new venues, blockchains, or asset types without updating the governance framework, authority matrix, or board approvals.

Best Practices for a Scalable Fund Authority Architecture

Building a fund authority architecture that can scale from launch to growth requires balancing proportionality with core control integrity. The following framework applies across fund sizes and stages.

Start with a documented target state architecture. Even at launch, the fund should have a clear view of its intended operating model, including the roles, systems, and controls that will govern exchange, custody, and trading activity. This target state may be implemented incrementally, but it should exist as a documented reference.

Implement minimum viable controls at launch without compromising core safeguards. Not every control needs to be fully automated or independently audited from day one. But certain controls, including multi party approval for material asset movements, segregation of trading and withdrawal authority, and documented access permissions, should be in place before the fund accepts investor capital.

Formalise role separation early. Even in small teams where individuals wear multiple hats, the authority matrix should define roles clearly and implement compensating controls where full segregation is not yet possible.

Use policy controls and logging wherever the infrastructure supports it. Automated controls are more reliable than manual ones, and contemporaneous logs are more credible than retrospective documentation. Where custody or exchange platforms support policy engines, approval workflows, and activity logging, these features should be configured and used.

Align legal documents and board resolutions with system realities. The authority matrix, the investment management agreement, the board resolutions, the custody terms, and the offering memorandum should all describe the same control environment. Where any of these are inconsistent, the fund has a governance gap.

Review permissions on a defined cadence. Quarterly access recertification is a reasonable starting point. Additional reviews should be triggered by staff departures, role changes, or the onboarding of new venues or strategies.

Test incident and recovery workflows. Documented procedures that have never been tested provide limited assurance. Periodic testing, even at a tabletop level, builds operational readiness and identifies gaps before they matter.

Track exceptions and remediation actions. Every deviation from the approved authority framework should be logged, assessed, and remediated. Exception tracking provides the board and allocators with evidence that the fund's control environment is actively managed.

Design for allocator transparency and future audits. Controls that are difficult to evidence or explain will create friction in due diligence and audit processes. Building transparency into the architecture from the outset reduces the cost and disruption of these processes over time.

Plan for growth. The authority architecture should accommodate additional staff, venues, strategies, and jurisdictions without requiring a fundamental redesign. Scalability does not mean complexity. It means building a framework that can extend without breaking.

Conclusion

A digital asset fund's authority architecture is foundational to its operational integrity, governance credibility, and institutional fundraising prospects. It determines whether the fund's control environment is robust enough to withstand regulatory scrutiny, allocator due diligence, and the operational demands of 24/7 digital asset markets.

Good authority architecture does not impede trading agility. It provides the structured framework within which agility can operate safely. Funds that invest in documented, enforceable, and transparent authority design are better positioned to attract institutional capital, retain allocator confidence, and scale operations without accumulating governance debt.

The design decisions made at launch, particularly around exchange account ownership, custody governance, role based access, and the separation of trading and asset movement authority, establish the foundation on which everything else is built. Getting these decisions right from the start is significantly more efficient than remediating them under the pressure of an allocator DDQ or an audit finding.

CV5 Capital's Cayman Islands fund platform supports digital asset, traditional, and hybrid strategies with institutional authority architecture, custody governance, and operational infrastructure designed for allocator readiness from launch. Managers evaluating how to structure their exchange, custody, and trading control environment within a regulated platform can learn more at cv5capital.io.

‍

Frequently Asked Questions

What is authority architecture in a digital asset fund?

Authority architecture is the structured framework that defines who can perform specific actions within a fund's operations, under what approvals, through which systems, and with what evidence trail. It encompasses legal authority (who is legally entitled to act), operational authority (who can practically execute), technical permissions (system level access and credentials), governance authority (who sets policy and approves changes), and oversight rights (who can view, reconcile, and challenge actions).

Why should trading authority and asset movement authority be separated?

Trading authority permits order placement and position management on an exchange. Asset movement authority permits withdrawals, transfers, and movement of assets between venues or wallets. These carry fundamentally different risk profiles: a trade adjusts portfolio exposure within the exchange, while an asset movement sends assets off the exchange with potential finality. Separating these authorities ensures that no single individual can both trade and unilaterally move assets, reducing the risk of unauthorised transfers and strengthening allocator confidence.

What is an authority matrix and why do allocators request it?

An authority matrix is a governance document that maps every material action (such as opening an exchange account, approving a withdrawal, or modifying a whitelist) to the authorised role, approval threshold, system of control, evidence retained, and escalation path. Allocators request it because it provides a structured view of whether the fund's control environment is documented, enforceable, and aligned with disclosures.

What are the most common authority architecture failures in digital asset funds?

Common failures include exchange accounts held in individual or manager names rather than the fund entity, shared credentials without individual accountability, traders retaining broad administrative and withdrawal rights, undocumented API key sprawl, no change control for whitelists or policy modifications, no periodic access recertification, and authority matrices that do not match actual system configurations.

How should fund boards or operators oversee the authority architecture?

Boards and operators should approve the authority matrix and operating model at launch, receive periodic access review and exception reports, approve the onboarding of new venues and custodians, review incident response protocols and testing results, and confirm that actual practice aligns with approved policy. Boards should not be involved in day to day execution but should have sufficient visibility to discharge their governance responsibilities.

What role does the administrator play in authority architecture?

The administrator requires independent, read only access to exchange accounts, custodian records, and wallet data to calculate NAV, perform reconciliations, and verify the completeness of position data. The administrator's access should be independent of the execution team, and any gaps in data coverage should be documented and addressed. Weak administrator access is a common cause of reconciliation friction and audit complications.

How do emerging managers implement authority architecture with limited resources?

Emerging managers should implement minimum viable controls at launch, focusing on core safeguards: multi party approval for material asset movements, segregation of trading and withdrawal authority, documented access permissions, and a basic authority matrix. Where full role segregation is not possible due to team size, compensating controls such as independent post trade review, daily reconciliation, and documented exception tracking should be used. The framework should be designed to scale as the team grows.

What do seeders typically ask for regarding authority architecture?

Seeders may negotiate enhanced governance visibility, including board observer rights, access to periodic control and access review reports, approval rights over new venue or custodian onboarding, notification requirements for material changes to the authority framework, and concentration limits by venue or custodian. These provisions are typically documented in side letters or the seeding agreement.

For more information, contact us: info@cv5capital.io

‍