Data residency and regions

In short

Data residency is the question in which country or region is our data stored and processed? Many regulators and data protection laws care about the answer, and so do many boards.

SpeculaPro answers it in one of two ways:

You host it yourself. The data is wherever you run SpeculaPro: your data centre, your private cloud. Nothing on this page changes anything for you. A self-hosted installation is a single installation and has no regions to think about.
It is hosted for you, in more than one region. Then your workspace is pinned to one region. Everything about it (customers, transactions, alerts, cases, reports, the audit log, the backups) is stored and processed in that region, and no other region will serve it.

Which regions exist is decided by whoever operates the service. This documentation names none, because the software doesn’t: a region is a name the operator gives an installation.

Three words

Word	In plain language
Region	A place where the service runs, with a short key such as `gh` and a name people see, such as “Ghana (Accra)”. The operator chooses both
Cell	The complete, independent installation that serves one region: its own database, its own message queue, its own cache, its own analytics store and its own copy of the application. Region and cell are two names for the same thing seen from outside and from inside
Directory	A small look-up service that sits outside every region. It answers one question: which region is this workspace in?

Picture a bank with branches in several countries. Each branch has its own vault, its own staff and its own ledgers, and can open in the morning whether or not the other branches do. That is a cell. At head office there is a receptionist with a list that says only “Acme Pay: Accra branch”. That is the directory. The receptionist can point you to the right door and knows nothing else about you.

                 ┌──────────────────────────┐
   you type      │        Directory         │   knows: workspace "acme" → region gh
   "acme"   ───► │  (slug → region, only)   │           region gh → its address
                 └────────────┬─────────────┘
                              │ "go to the gh region"
              ┌───────────────┴────────────────┐
              ▼                                ▼
   ┌─────────────────────┐          ┌─────────────────────┐
   │   Region gh (cell)  │          │   Region eu (cell)  │
   │  database, queue,   │          │  database, queue,   │
   │  cache, analytics,  │          │  cache, analytics,  │
   │  application        │          │  application        │
   │  acme's data: HERE  │          │  nothing of acme    │
   └─────────────────────┘          └─────────────────────┘

(gh and eu are examples.)

What stays in your region

Everything SpeculaPro holds about your workspace:

customers, accounts, counterparties and transactions;
alerts, cases, comments, reports and their attachments’ titles;
people’s accounts, passwords, two-factor enrolments, recovery codes, passkeys and sessions;
settings, rules, lists, API keys and webhook endpoints;
the audit log;
the analytics copy and the fast counters rules use;
the backups, which the operator keeps in the same region.

Messages that leave SpeculaPro for you leave from your region too: webhooks to your systems and email, SMS or WhatsApp notifications to your people are sent by your region’s cell and by no other.

A cell also refuses a workspace that is pinned somewhere else. If a copy of your workspace ever sat in the wrong region’s database (a backup restored in the wrong place, for example), that region would not let anyone sign in to it, would not accept its API keys and would not send its webhooks.

What the directory knows about you

Two things, and nothing else:

The directory stores	Example
Your workspace’s slug and the region it is in	`acme-pay` → `gh`
Each region’s key, name, address and whether it is serving	`gh`, “Ghana (Accra)”, its web address, `active`

It holds no names of people, no email addresses, no customer data, no transactions and no passwords. It also keeps a log of changes to its own list (which region registered or moved which slug), again slugs and regions only.

A workspace slug is usually a version of your institution’s name, so the directory does know that an institution with that slug is a customer and which region it is in. Anyone who types your slug into the sign-in page is told the same.

The look-up is built so it can’t be used to list customers: a slug that doesn’t exist gets an answer of exactly the same shape, pointing at a region, and the look-up is limited to a number of tries a minute from one address.

What you see

Signing in

There are two ways in, and both end at the same sign-in page:

Your region’s own address. You sign in as usual. Under the heading the page shows Region: Ghana (Accra), and, where the operator set one, a link Not your region? Find your workspace.
The global address. The page asks only for your workspace, with the heading Find your workspace and the line Enter your workspace and we’ll take you to the region where it is hosted. Your data stays in that region. Select Continue and you are taken to your region’s sign-in page with the workspace filled in. Your email and password are typed only there.

If your region is unavailable, the global page says so (The … region is unavailable right now. Try again shortly, or check the status page.) instead of sending you to a page that won’t load.

Keep your region’s own address bookmarked. It works even when the global address doesn’t.

In Settings

Settings → Workspace shows Data region with the region’s name and key, and the note Where this workspace’s data is stored and processed. It doesn’t leave this region; moving it is done by SpeculaPro at your request. You can’t change it yourself.

On a single installation neither the region line on the sign-in page nor Data region appears.

In your integrations

API keys created in a region carry its key: spk_gh_…. A system that sends a key to the wrong region is told so, with the address to use instead. See Regions for integrators.

Moving to another region

A workspace can be moved, for example because your regulator’s rules changed or a region closer to you opened. Three things to know before you ask:

You ask; the operator does it. There is no button. A move is a planned operation carried out by the people who run the service, recorded in both regions’ audit logs.
There is downtime. First your workspace is read-only for a while: people can look, but nothing can be changed and your systems’ data is refused with “try again shortly”. Then it is unavailable while the copy is carried over and checked. Then it is live in the new region.
The old copy is deleted once the new one is proven identical, so your data is in one region again, not two.

After a move, everyone signs in again, and your systems must be pointed at the new region’s address. Passkeys made at the old region’s address stop working there: people sign in with their password and authenticator code, then add new ones. If the AI assistant was on, it arrives switched off and must be switched on again in the new region. The operator’s tool refuses to copy your workspace while any of your data is still being processed, and rebuilds your rules’ running counts in the new region before it goes live, so rules over long periods normally see the same history as before. If the operator skips that rebuild to shorten the downtime, those rules see only new activity until their period has passed; ask which they plan to do. What is and isn’t carried across is listed, exactly, in Moving a workspace between regions.

If a region fails

Each region recovers inside itself: a standby in the same region takes over. There is no automatic switch to another region, on purpose. Failing a region over to another country would move your data out of the region you chose, which is the thing residency exists to prevent.

So if a whole region were lost, the service would be restored in the same region or jurisdiction, or, only with your written agreement and where your regulator allows it, in another. Ask your operator which applies to your region and have it written into your contract.

Limits

Regions are the operator’s. The software enforces whatever regions the operator sets up. It can’t tell you which country a region’s servers are in; your contract does.
The directory knows your slug. If the existence of your relationship is itself confidential, choose a slug that doesn’t name you.
Residency is not encryption. Personal data is also encrypted in the database; see Data protection. The two protect against different things.
Self-hosted installations have one region: yours. Nothing here needs configuring.