Founders building crypto or payment products usually ask the licensing question too early and the perimeter question too late. Before "which licence do we need?" comes a more basic one: does what we are building fall inside financial-market regulation at all? In Switzerland, the answer depends on activities, not on labels — not on what you call the product, and not on the fact that a blockchain is involved.
That principle cuts both ways. It means there is no separate "crypto law" to comply with or escape; Switzerland folded distributed-ledger technology into its existing financial-market framework. And it means the same product idea can land inside or outside the perimeter depending on design details that look, to an engineer, like implementation choices.
The question is activity, not technology
FINMA and Swiss legislation approach token businesses the way they approach any financial business: what are you actually doing with other people's money and assets? Taking custody of client assets, exchanging value, transmitting payments, issuing instruments that promise future returns — these activities have triggered regulation for decades. Doing them with tokens instead of bank balances changes the engineering, not the analysis.
The practical consequence: the perimeter analysis starts from a plain description of the money and asset flows in your product. Who holds what, for whom, at which moment, and who can move it? A diagram of those flows answers more regulatory questions than any whitepaper.
Custody: whose assets are they?
The single most consequential design question is what happens to client crypto assets in your hands. Broadly, two worlds exist. In one, assets are held ready for the client at all times — individually attributable, kept apart from your own, retrievable by the client. In the other, client assets sit on your balance sheet in a way that makes clients your creditors, exposed to your insolvency.
The second world is where the heaviest regulation lives, because it is functionally deposit-taking — the core of what banking law protects against. Many products drift there unintentionally: pooling client assets for efficiency, lending them out to generate yield, or holding fiat balances "temporarily" between transactions. Each of these features is a perimeter decision, whether or not it was made as one.
Token categories are concepts, not labels
Swiss practice distinguishes, conceptually, between payment tokens (intended to function as a means of payment), utility tokens (providing access to a service or application) and asset tokens (representing claims or membership rights, functionally akin to securities). The categories matter because different rules attach: payment-type activity pulls in anti-money-laundering obligations; asset tokens pull toward securities and prospectus rules; a genuinely pure utility token may sit outside financial regulation altogether.
Two cautions. First, hybrids are the norm, not the exception — a token can be several things at once, and then several regimes apply at once. Second, the classification follows the token's function and the rights actually attached to it, not the terminology in your documentation. Calling something a utility token does not make it one, and regulators read the code and the terms, not the marketing.
Exchange, brokerage and payment services
Even without touching custody or issuance, service activities can pull you inside the perimeter. Exchanging crypto against fiat or against other tokens, brokering such exchanges, operating a trading venue, and transmitting money or value on behalf of others are all activities the framework knows well — most immediately through anti-money-laundering regulation, which typically requires affiliation with a self-regulatory organisation or direct supervision, and at larger scale through licensing regimes of their own.
The common surprise is how little "product" it takes. A wallet feature that lets users send assets to third parties, a checkout that briefly holds fiat before forwarding it — these can be enough to make you a financial intermediary in the regulatory sense, with everything that follows.
Why product design decides
Put together, the perimeter is decided by design details: who controls the keys, whether assets are pooled or segregated, whether users can pay third parties or only you, whether fiat passes through your accounts, what rights a token actually confers. Change one of these and the analysis can change with it — which is why perimeter questions belong in the product-design phase, not in a memo written after launch.
Whether a specific product falls inside the perimeter genuinely depends on its facts; honest advisers say so rather than promising categories in advance. What can always be done early is the structured version of the exercise: describe the flows precisely, map each activity against the framework, and identify which design choices are load-bearing. That work is systematic — and a good part of it is exactly the structured reading and mapping that systems handle well, with a lawyer challenging the analysis and answering for the conclusion. If you are designing such a product, the right time to talk is before the architecture hardens.