Digital-Asset Software for Swiss Asset Managers: Compliance and Architecture (2026)

The short answer

A Swiss asset manager considering digital assets should first define its authorised activity, then choose technology that preserves the boundaries between investment decisions, custody, execution and client money. Start with an appropriate custody partner, reliable portfolio records and evidence of controls. A polished portal or integrated financial platform cannot supply missing authorisation, make an unsuitable custodian suitable, or turn software balances into legally segregated client assets.

For many firms, the sensible starting point is a specialist portfolio-management system connected to external custodians—not a full banking stack. FINMA’s January 2026 custody guidance makes the safekeeping question particularly important: assess who holds the assets, under which supervision and insolvency framework, before designing how clients see or instruct them.

1. Start with the activity, not the interface

“Swiss regulated” is not a sufficiently precise procurement requirement. FINMA distinguishes types of authorisation with different supervisory intensity. A technology brief should name the legal entity, activities, client groups, instruments and countries involved. The fact that several functions appear in one application does not merge the permissions needed for those functions.

Portfolio managers commercially manage client assets under powers of attorney and require FINMA authorisation. Generally, an authorised supervisory organisation (SO) handles ongoing supervision; FINMA notes an exception for certain domestic group companies. The licence entails organisational and financial requirements and continuing controls. It is not, by itself, a permission to take deposits, issue cards or operate a crypto exchange. See FINMA’s portfolio-manager explanation.

Banks fall under a separate banking authorisation framework. A bank’s role as custodian or account provider must be distinguished from a manager’s investment mandate. Do not describe a software provider, a payment integration or an IBAN display as a licensed bank. FINMA’s banking and securities-firm overview identifies separate licence categories and legislation.

Managers of collective assets are a distinct FinIA category, not simply individual portfolio managers with a different interface. FINMA’s asset-management overview separates institution authorisation from product approval and identifies collective-asset managers under Article 24 FinIA. Thresholds, exemptions and fund structure matter; this article is not a classification opinion for a particular fund.

SRO-affiliated AMLA intermediaries operate under an AML supervision route. SRO recognition and membership must not be described as a banking licence or a FINMA portfolio-manager authorisation. An SO and an SRO have different functions, even when related organisations perform both. FINMA’s AML supervision explanation describes indirect AML monitoring of individual portfolio managers via SOs.

2. Custody and segregation in 2026

In Guidance 01/2026, section 3.2, FINMA explains safekeeping under Article 24(1) FinIO for individual portfolio management. Managed assets are to be held segregated per client with specified Swiss institutions or institutions under equivalent supervision. For cryptobased assets, FINMA emphasises prudentially supervised custodians, adequate technical infrastructure and expertise, and segregability in bankruptcy. Foreign arrangements also require equivalent supervision and equivalent bankruptcy protection.

The guidance describes narrow exceptions for certain existing custody arrangements: either equivalent foreign prudential supervision without equivalent bankruptcy protection, or Swiss SRO-supervised custody with bankruptcy protection but without prudential supervision. It requires, cumulatively, demonstrable comprehensive risk information, information about suitable alternative custodians and documented written client consent. These conditions are not a blanket approval for new arrangements or a generic “client consent fixes custody” rule.

For direct crypto investments in Swiss collective assets, section 3.3 explains the Swiss custodian-bank framework and conditions for delegation. Do not apply the individual-mandate exception indiscriminately to funds. Legal structure and activity determine the analysis.

In practical due diligence, request the custody agreement, asset-allocation model, insolvency analysis, subcustodian chain and withdrawal controls. Check the correct entity and licence category against FINMA’s public institution lists; listing alone does not establish the suitability of every service or overseas affiliate. A database field labelled “segregated” cannot replace legal and operational evidence.

3. An architecture that preserves boundaries

Design four distinguishable layers: the investment system for mandates and restrictions; the custody and execution partners for assets and orders; the records layer for reconciliation and evidence; and the client portal for access and communication. A shared login may simplify the experience, but permissions and legal responsibilities should remain separate.

For example, a read-only portal can show custodian-reported holdings alongside traditional securities. It should identify data sources, timestamps, valuation currency and settlement status. A blockchain transfer identifier is useful evidence, but is not an investment valuation or proof of the client’s legal entitlement. Reconcile units, prices and fees against the custodian’s records rather than treating an API response as final accounting truth.

If the portal accepts instructions, introduce a separate approval path: validate the mandate, eligible instrument, destination, limits and required authorisers before sending an order. Separate investment authority from withdrawal authority. Use least-privilege service credentials; a reporting integration should not obtain signing or transfer permissions simply because the provider supports them.

Direct token holdings, fund units and exchange-traded products require different records and risk explanations. Specify the supported instruments, valuation policy, forks and corporate-action treatment before development. These are editorial design recommendations, not universal statutory prescriptions or a claim that one architecture fits every licensed manager.

4. Monitoring, records and supervision

Client onboarding is more than collecting a passport image. Identify which regulated entity performs which due-diligence task, who owns the client relationship and who escalates suspicious activity. FINMA describes AMLA due-diligence and disclosure duties; a vendor’s “AML module” describes tooling, not a transfer of responsibility or proof that the firm has complied.

Monitoring should join client information, mandates, positions, orders and relevant transfer activity. Define who investigates alerts, how decisions are recorded and how unresolved cases restrict further activity. If blockchain analytics is used, retain its provenance and acknowledge the limits of attribution. Do not treat every high-risk score as evidence of wrongdoing, or every low score as clearance.

Keep a coherent audit trail of instructions, approvals, executions, reconciliations, overrides, disclosures and changes in access. Define retention and access rules with legal advice rather than imposing a single duration across every record type. The useful test is whether a reviewer can reconstruct why a transaction was permitted and what information was available at the time.

FINMA’s portfolio-manager page stresses continuing licensing conditions, effective controls and notification of relevant changes. Technology should make oversight possible through exportable records and documented responsibilities. Our licensing requirements page provides related site context; use the linked official sources and current professional advice to validate specifics.

5. Outsourcing and cybersecurity: retain control of the outcome

Delegating hosting, development or monitoring does not eliminate counterparty dependency. FINMA’s custody guidance explicitly highlights dependency on third-party infrastructure and careful selection. Extend that operational question to the software supply chain: map hosting, identity services, custodians, analytics, subcontractors and administrators.

Before signing, examine access rights for the firm and its auditors, data locations, subcontractor changes, incident notification, recovery arrangements and exit assistance. The applicable outsourcing requirements depend on the institution and activity; bank-specific circulars should not be presented as automatically binding on every independent portfolio manager.

As practical safeguards, segregate production from testing, keep client secrets out of logs, require strong authentication for privileged access and review rights regularly. Test credential revocation, backup restoration and failed-provider scenarios. An incident plan should name who can suspend instructions, contact custody partners and preserve evidence—not merely list the vendor’s support address.

Source access may help investigation and continuity, but only if the firm can build, maintain and secure the system. Assess dependency inventories, patch responsibilities, documentation, key-person risk and recovery tests. Neither proprietary delivery nor open source guarantees security; contractual promises are not a substitute for evidence.

6. Specialist systems or a broader financial platform?

A specialist portfolio-management system is often the closer functional fit when the main needs are mandates, investment restrictions, multi-custodian consolidation, portfolio accounting and reporting. Require a realistic demonstration with mixed assets, missing prices and reconciliation breaks. A broad platform may offer useful orchestration but require extra work to achieve investment-specific controls.

One limited example is SAMFCore’s vendor-described modular platform. Its scope includes fiat accounts, payments, cards, crypto and digital-asset wallet/exchange workflows, individual and business onboarding, AML and back-office functions. The API documentation overview describes bank-account/IBAN workflows and integrations. An integrated multi-currency customer portal may be relevant to a separately authorised fintech business; those capabilities do not establish suitability for a Swiss portfolio manager.

When not to use it: if the mandate is simply portfolio reporting over external custody, adopting payment, card or exchange functions may introduce unnecessary scope. Do not select a broader platform to imply new permissions or replace a required custody partner. SAMFCore itself grants no banking, payment, custody or card-issuing licence.

As published on the vendor’s licensing page, annual usage starts at CHF 80,000 per year, perpetual usage at CHF 325,000 one-time, and perpetual usage with full source code at CHF 620,000. These are software terms, not project-cost estimates: third-party services, approvals, implementation and operations require separate assessment. Source-code access and perpetual usage do not transfer underlying IP automatically; the signed agreement defines rights.

Source access is not unique to this example. SDK.finance describes annual and lifetime source-code licensing, a code-audit stage and ongoing maintenance responsibilities. Velmie describes cloud, on-premise and source-code delivery. This is not a ranking: compare actual contractual rights, staffing and integration fit rather than assuming “source code” has the same meaning across providers.

7. A practical decision matrix

Use this as a procurement gate, not a regulatory certification. Resolve the legal perimeter before enabling transactions; then demand evidence for the intended operating model.

Run acceptance tests with hypothetical cases, clearly labelled as tests: a stale custodian feed, a duplicate instruction, a revoked user and a failed withdrawal approval. Record the result, owner and remediation. These are suggested scenarios, not claimed vendor deployments or quantified performance benchmarks.

Frequently asked questions

Sources and review notes

All primary references below were reviewed on 11 October 2026. FINMA guidance explains supervisory expectations and is not a personalised legal opinion. Vendor pages support only vendor-stated scope or commercial terms, not independently verified security, fitness or regulatory approval. Online documentation and terms may change after this review.

1. FINMA — Types of authorisation — Different authorisation categories and supervisory intensity. Reviewed on 11 October 2026.
2. FINMA — Portfolio managers and trustees — Licensing, ongoing SO supervision and changes affecting authorisation. Reviewed on 11 October 2026.
3. FINMA — Banks and securities firms — Separate licence categories and applicable banking legislation. Reviewed on 11 October 2026.
4. FINMA — Asset management — Collective-asset institutions, products and authorisation requirements. Reviewed on 11 October 2026.
5. FINMA — Self-regulatory organisations — Recognition of SROs and their AML supervision role. Reviewed on 11 October 2026.
6. FINMA — Authorised institutions — Public authorisation lists; these do not warrant software or investments. Reviewed on 11 October 2026.
7. FINMA Guidance 01/2026 — Custody of cryptobased assets — 12 January 2026 guidance, especially section 3.2 on individual portfolio management and section 3.3 on collective assets. Reviewed on 11 October 2026.
8. FINMA — Combating money laundering — AMLA due diligence and disclosure requirements; distinct supervision routes. Reviewed on 11 October 2026.
9. SAMFCore — Platform overview — Vendor-stated financial-services orchestration scope; not a suitability assessment. Reviewed on 11 October 2026.
10. SAMFCore — Licensing — Vendor-published prices, perpetual usage rights, source-code access and IP distinction. Reviewed on 11 October 2026.
11. SAMFCore — API integrations — Vendor-stated account, IBAN, payment, digital-asset and compliance integration workflows. Reviewed on 11 October 2026.
12. SDK.finance — Acquiring source code — Vendor-stated annual and lifetime source-code licences, code audit and team responsibilities. Reviewed on 11 October 2026.
13. Velmie — Delivery — Vendor-stated cloud, on-premise and source-code delivery options. Reviewed on 11 October 2026.
14. SAMFCore — Swiss AMF AG Impressum — Identifies Swiss AMF AG as the platform operator. Reviewed on 11 October 2026.