Revolut and Bitcoin Suisse: three questions about trust
Revolut’s Swiss licence application, reported data disclosure and Bitcoin Suisse’s reorganisation raise separate questions about status, authority and access.
The brief
Revolut announced a Swiss banking licence application and a planned investment exceeding CHF150 million over five years. Separately, reporting on a customer-data disclosure described a fraudulent request sent from a legitimate government email address. Bitcoin Suisse announced an international reorganisation affecting Swiss roles.
The useful distinction is between regulatory status, authority to make a request and control over an operating process. A licence application is not approval; a genuine-looking address does not establish that a particular request is authorised; an operating location alone does not explain access. Our proposed response is to document those three questions separately and test a fictional sensitive-data request before release.
The full record
Three September stories are easy to group under the word trust. Doing so without separating their claims loses the practical lesson. Revolut’s proposed Swiss expansion concerns regulatory status and customer service. A reported fraudulent request concerns the authority to obtain information. Bitcoin Suisse’s reorganisation concerns where work is performed and how responsibilities are arranged.
First question: what is the institution’s current status?
On 16 September, Revolut announced that it had applied for a Swiss banking licence and planned to invest more than CHF150 million over five years. It reported more than 1.3 million Swiss customers. The announcement explicitly says the application remains subject to approval and its outcome is open; existing Swiss customers are served by Revolut Bank UAB in Lithuania.
Our take: a client-facing explanation should distinguish the current provider from a proposed future arrangement. Identify what changes only if approval is obtained, and avoid letting an expansion headline imply that a licence has already been granted. Keep the date and the source of the status statement visible.
Second question: is this particular request authorised?
On 14 September, Investing.com, reporting on Financial Times coverage, said Revolut had contacted 680 customers after information was supplied in response to a fraudulent request from a legitimate government email address. The report said Revolut blocked the address and notified regulators and affected customers. The figure is the reported overall customer count, not a count of Swiss customers.
We have not independently examined the incident or the request. The report supports a narrower operational question than whether a whole platform was compromised: how should the recipient establish the authority and scope of a request before releasing information?
Our take: treat the sender’s address, the claimed role and the requested disclosure as separate checks. In a fictional exercise, ask the receiving team to identify the approved route for handling that type of request, the evidence needed and the person responsible for the decision. Verify through independently established contact information when the process calls for confirmation. Do not use the contact route contained only in the suspect request as its own proof.
The record should explain the request, the basis for the decision and exactly what was released or withheld. This is a proposed process test, not a reconstruction of Revolut’s controls or a substitute for the applicable legal process.
Third question: who can act when operations move?
Reuters reported on 11 September that Bitcoin Suisse planned cuts affecting up to 60 of its 120 Swiss positions as software and back-office work moved towards international hubs. The announcement described a consultation running to 20 September. The upper figure was the announced scope, not evidence in this source that 60 departures had occurred.
Our take: an operating change should prompt a map of responsibilities and access. For one fictional client instruction, identify who receives it, which team acts and which person confirms the outcome. Recheck that the authorised colleague can retrieve the record after the handoff. These questions do not imply that overseas work is inherently unsafe or that domestic hosting alone provides a complete answer.
Turn the three questions into one usable record
For a sensitive request, retain the relevant institutional status, the requester’s verified authority, the scope of the approved action and the result. State uncertainty before acting rather than replacing it with a familiar logo, email domain or geographic label.
This is the practical contribution of formal communication: connect an attributable request to an authorised decision and a retrievable outcome. A technology’s security properties matter, but they do not by themselves decide whether the recipient should comply with the request in front of them. Our September SRA alert register shows related impersonation patterns in legal services; it is a separate dataset and does not include the Revolut incident.
Sources were checked on 30 September 2026. The Revolut expansion item uses its own announcement. The incident item relies on attributed published reporting; we have not independently established the affected population or examined systems. Bitcoin Suisse figures describe the announced reorganisation, not a verified final headcount reduction. Our practical exercises are editorial analysis, not findings about the named firms’ controls.