Data protection
Who else touches this, and what they can see
These are the companies, and the people hosting relays, involved in running Verus. This page names every one, says exactly what each one is in a position to see, and says where the data physically sits. It is the list a data protection agreement would point at, and it is kept current because a stale one is worse than none.
The short version, which the rest of the page then evidences: none of them can read a message. Content is encrypted on the device before it reaches anything on this list, and the keys exist only on the devices in the conversation. That is not a contractual promise about behaviour, it is a property of the design, and you can check the shape of it yourself at api.verusapp.co.uk/v1/deployment.
The sub-processors
Current as of 12 October 2026. If one is added or removed, this page changes on the same day.
Oracle Cloud London, United Kingdom
The Verus service, and everything it stores; also a call relay
- What it can see
- Addresses, public keys, encrypted envelopes and encrypted attachments, on disk on one server. It has no key for any of it, and there is no column recording who sent anything. As a relay, the same as the others: two IP addresses and an encrypted call passing through.
- Why it is here
- Somebody has to run the machine.
IONOS Stuttgart, Germany, and London, United Kingdom
Live standby copies of the service; also a call relay
- What it can see
- A continuous copy of exactly what the Oracle server holds, so either standby can take over if Oracle fails: the same sealed data, with no key for any of it. As a relay, the same as the others.
- Why it is here
- So Verus keeps working if a whole provider or data centre goes down.
SiteGround London, United Kingdom, on Google Cloud infrastructure
This website, and mail to our published addresses
- What it can see
- Only what you type into this website: an early access email address and a day, or a contact enquiry. It also handles inbound mail to our published addresses. It touches nothing belonging to the messaging service.
- Why it is here
- The website and the service are separate systems on separate infrastructure, on purpose.
Apple Apple Push Notification service, global
Waking a closed app
- What it can see
- That a device should wake. The push carries no title, no body, no sender and no count. The honest cost: a wake token is a stable device identifier issued by Apple, and Apple learns each time that device is woken. Recorded as T-15 rather than buried.
- Why it is here
- On iOS there is no other way to reach a closed app.
Google Firebase Cloud Messaging, global
Waking a closed app on Android
- What it can see
- That a device should wake, and when. The wake carries no title, no body, no sender and no count. The same honest cost as Apple's: the Firebase token is a stable device identifier issued by Google, and Google learns each time that device is woken. Only if notifications are turned on.
- Why it is here
- So a new message reaches an Android lock screen without the app running a service of its own in the background.
Google Language model downloads and SDK telemetry, global
On-device translation (ML Kit)
- What it can see
- Which language models a device downloads, and ML Kit's own telemetry: device and app version, performance and an installation identifier. Never the message text: translation runs on the phone. On Android for every language; on iPhone only for Hungarian and Hebrew (since 11 October 2026), which Apple's translation does not offer.
- Why it is here
- So a message can be read in your own language without the words ever being sent anywhere to be translated.
Vultr New York and Seattle (US), Toronto (Canada), São Paulo (Brazil), Johannesburg (South Africa), Singapore, Sydney (Australia), Tokyo (Japan) and Seoul (South Korea)
Call relays, outside the United Kingdom
- What it can see
- For a call relayed through it, which is the normal route: the IP addresses of the two devices and the call's audio, which is encrypted end to end and passes straight through. Nothing is stored, and the relay holds no key for the call.
- Why it is here
- A call passes through a relay so that neither person learns where the other is. One near the caller keeps it clear.
Amazon Web Services Virginia and Oregon (US), Montreal (Canada), São Paulo (Brazil), Cape Town (South Africa), Singapore, Sydney (Australia), Tokyo (Japan) and Seoul (South Korea); the earlier server in Stockholm, Sweden
Call relays outside the United Kingdom, and the earlier Verus server
- What it can see
- As a relay, the same as Vultr's: two IP addresses and an encrypted call passing through, nothing stored. The earlier server has been switched off since 2 October 2026 and still holds the sealed data it held that morning, with no key for any of it.
- Why it is here
- A second provider in every country outside the United Kingdom, so one provider failing does not take a country off the map.
Verus Relay hosts United Kingdom
Community call relays
- What it can see
- The same as the other relays. Hosts are approved through the Verus Relay programme and run software that stores nothing from a call.
- Why it is here
- So the network does not depend on a single cloud provider.
ipinfo.io United States
Placing each relay on the map
- What it can see
- The public IP address of each Verus relay, to work out the country and city it is in. It never sees a user's address, a message or a call.
- Why it is here
- So the app can pick the nearest relay and the relay list can say where each one is.
VPlatform api.vplatform.io
Minting a VCode for a verified introduction
- What it can see
- A title and a lifetime. Nothing about the person being introduced: the address travels inside the code rather than to VPlatform.
- Why it is here
- A VCode is a real credential minted by the platform that issues them, rather than a square we drew.
Public blockchain and price services mempool.space, Blockscout, PublicNode and TronGrid for the chains; CoinGecko and Coinbase for prices, and LATOKEN for the VSolidus price
Reading the public Bitcoin, Ethereum and Tron chains, and today's coin prices (VSolidus included), for crypto payments
- What it can see
- Requests from our server, never from you: our own receiving addresses, and transaction ids that are already public. Nothing about the buyer, and no Verus address.
- Why it is here
- A payment is matched by reading the chain it was made on, and no key is held that could move a coin.
Anthropic United States
Ask Verus, the assistant on this website
- What it can see
- The questions typed into Ask Verus and its answers, sent from our website host with no IP address and no identifier. Nothing from the Verus app or the service: Ask Verus is not connected to either. Deleted by Anthropic within 30 days unless flagged for breaking its usage policy, and never used to train its models.
- Why it is here
- So the assistant on this website can answer questions about Verus in plain English.
Contracting entity names are not printed here on purpose. Each of these companies contracts through a different legal entity depending on the customer's country, and a guess on this page that disagreed with an invoice would be worse than sending you to the invoice. Ask and we will send you the actual agreements.
Confrmo is not on that list, and here is why
Identity verification runs through Confrmo, so a reasonable reviewer expects to find it above. It is absent because a subprocessor is somebody we hand your data to, and we do not hand Confrmo anything.
Nothing about you is sent to it. When you choose to verify, your device opens Confrmo and you deal with Confrmo directly. Verus asks it to start a session and receives an answer. Your face and your identity document are shown to Confrmo and never to Verus.
Confrmo is a separate company, and that is the point. Confrmo Ltd, company number 17203914, builds Verus and runs the identity service, and Verus Communications Ltd operates the messaging service. They are under common ownership and we would rather say so than have you find it out. An attestation is worth something precisely because the company checking who you are is not the company carrying your messages.
Confrmo is its own controller for what you show it, and it publishes its own privacy policy covering that. What is not in doubt is the data flow, which is described in the privacy policy and visible in the app.
Where the data actually is
The distinction that is easy to get wrong, so it is drawn plainly: the messaging service runs in the United Kingdom, with live copies in Germany, and this website runs in the United Kingdom. They are different systems on different infrastructure, and a single sentence claiming one country for both would be false about one of them.
| What | Where | Detail |
|---|---|---|
| Messages, attachments, addresses and keys | United Kingdom, with live copies in Germany | Oracle Cloud in London, copied continuously to IONOS in Stuttgart and London so a standby can take over. Encrypted before it arrives and deleted on collection. Until 2 October 2026 this was AWS in Sweden. |
| Early access list and contact enquiries | United Kingdom | This website, on SiteGround. Nothing here is connected to a Verus address. |
| Identity verification | Confrmo | Your face and your document are shown to Confrmo and never to Verus, which is told the answer and nothing else. |
| Calls | Nearest relay | As the normal route, the encrypted call passes through a relay near the caller, in the UK, US, Canada, Brazil, South Africa, Singapore, Australia, Japan or South Korea. The relay sees the two IP addresses and stores nothing. Only when both people have chosen to be verified to each other, or belong to the same Verus team, can a call connect directly between the two devices. |
| Wake notifications | Apple and Google, global | A signal with no content in it: Apple for iPhone and Mac, Firebase Cloud Messaging for Android when notifications are on. |
Transfers out of the UK and the EU
Message data is held in the United Kingdom and copied continuously to Germany, in the European Union, so a standby there can take over. Website data does not leave the United Kingdom. Calls are the exception that crosses borders. A call travels through the nearest relay as the normal route, which may be outside the UK and the EU, carrying the encrypted call and the two devices' IP addresses and storing nothing. The other thing that crosses is a wake notification, to Apple for iPhone and Mac or to Google for Android, which carries no content at all: it says a device should wake up and nothing else.
The United Kingdom and the European Union each recognise the other as providing adequate protection, so the standby copy in Germany under a UK controller does not need additional transfer safeguards. Apple is covered by its own data protection terms, which we will provide on request along with the rest of the agreements. The call relays outside the UK run on Vultr and Amazon Web Services, whose data processing agreements include the standard contractual clauses and apply to that traffic.
If that is not where you want it
A dedicated or sovereign deployment runs the same software wherever you need it to run, under your keys, on infrastructure you control, at which point this page describes our deployment and not yours. That is set out under deployment.
Not yet
There is no data protection agreement yet
Said here rather than discovered by you halfway through a procurement. This page is the sub-processor list and the residency statement a DPA would refer to, and the agreement itself is being drafted properly rather than assembled from a template by people who are not lawyers.
If you need one to proceed, say so and it moves to the front of the queue: a buyer waiting on a document is the fastest way to make it exist. The security page sets out the rest of what is and is not certified, including that there is no ISO 27001 certificate of our own, no SOC 2 report and no third party penetration test.