Crypto custody & trading infrastructure

The assessment looks at who can control, transfer or restore access to customer assets. Key possession is relevant, but multi-signature arrangements, recovery powers and provider dependencies also matter. Describing software as non-custodial is not sufficient if the operator can exercise effective control.

Customer repayment claims and the treatment of held assets can raise banking questions. The analysis depends on the custody structure, segregation and any use of the assets. We examine both contracts and operational mechanics before identifying a licensing route.

Some custody models may fall within AML supervision without requiring a separate prudential license. That conclusion depends on the facts and applicable requirements. We review the customer relationship and asset arrangements first rather than assume that SRO affiliation covers every custody model.

Swiss law provides for segregation in qualifying circumstances, but the outcome depends on the holding structure and statutory conditions. Clear allocation, records and availability are important. We review whether the legal and operational arrangements support the treatment promised to customers.

Contracts, wallet arrangements, customer ledgers and reconciliation should tell the same story about ownership and allocation. Provider chains and foreign insolvency rules may also matter. A statement in the terms that assets are segregated is not enough without supporting arrangements.

The question is whether the customer retains rights to identifiable assets or instead has a repayment claim against the provider, taking account of the applicable rules. Pooling, reuse and settlement arrangements can affect the answer. We trace the full asset lifecycle.

It can. Staking introduces questions about availability, lock-up periods, penalties, provider control and the customer’s rights. Those features need review alongside custody and insolvency treatment. Existing terms and permissions should be checked before a staking feature is introduced.

A qualifying financial intermediary needs the applicable customer-identification, beneficial-owner, risk-assessment, monitoring and reporting controls. Transfers introduce additional information and wallet-verification questions. The procedures should reflect the custody model, customers and the roles of any external providers.

The answer follows the applicable authorization and supervisory route. Management, access to records, key responsibilities and oversight must support the stated organization. Outsourcing technology abroad does not remove the need to establish who can operate, supervise and recover the service.

A reform may change the relevant license or transition requirements once enacted and effective. We assess the current position and monitor adopted changes affecting the model. Existing SRO affiliation or a past classification should not be treated as permanent approval of every future feature.

It is a regulated form of financial-market infrastructure for multilateral trading in DLT securities, with features defined by Swiss law. Retail participation, central custody or clearing and settlement can be relevant to the category. The platform’s matching and post-trade functions must be analyzed together.

The instruments, admission of participants and trading mechanics determine the regime. DLT infrastructure rules concern DLT securities, while trading other tokens may raise different questions. A platform’s commercial name does not establish whether it is an exchange, a broker or a DLT trading facility.

Yes. FINMA announced its first DLT trading-facility license for BX Digital in March 2025. That confirms the route is operational, but each applicant must meet the requirements for its own model. Another platform’s authorization is not a template approval for different functions.

The license category concerns eligible DLT securities. The legal rights represented by each instrument, admission criteria and applicable restrictions need review. Tokenization alone does not establish eligibility, and a platform should define its instrument policy before approaching issuers and participants.

The framework can accommodate participants beyond supervised financial institutions, subject to the applicable requirements and the facility’s authorized model. Participant admission, conduct, information and risk controls need to reflect that choice. Retail access should be designed into the application rather than added later.

Swiss law provides a small-DLT-facility framework with specified thresholds and regulatory relief. Qualification depends on the relevant criteria and the actual business. Relief does not remove the need for authorization, sound operations and a credible plan to monitor the thresholds.

The work includes the Swiss entity and organization, financial resources, trading rules, participant access, risk controls and operational resilience. Custody and settlement arrangements must be explained where relevant. Suitable audit and technical expertise should be involved alongside the legal application work.

The timetable depends on platform readiness, governance, specialist reviews and the authority’s assessment. A technically complex or changing model needs more preparation than a settled design. We identify dependencies and authority questions early, but cannot guarantee an approval date.

No. The analysis depends on the assets traded and the services performed. Brokerage, bilateral execution or other venue structures may follow different rules. We compare viable routes and make clear which functions each route would permit.

They can be considered within one project, but each function affects the regulatory and operational design. We identify customer rights, finality, asset allocation and dependencies between providers. A custody review alone does not settle the requirements for a new trading or settlement function.

No. Our work covers the legal and regulatory implications of the architecture, contracts and application. Security assurance and technical validation require appropriate specialists. We can coordinate the questions and documentation between those workstreams within the agreed scope.