import { apiHost, consoleHost } from '../../../../lib/docs-env';

The platform runs in two independent regions: US and EU. Each has its
own database, object storage, console, and public API endpoint.
Customer data does not cross the boundary.

## US vs EU

You pick a region at organization creation and the choice is sticky.

- **US region.** Console <code>{consoleHost('us')}</code>,
  API <code>{apiHost('us')}</code>.
- **EU region.** Console <code>{consoleHost('eu')}</code>,
  API <code>{apiHost('eu')}</code>.

The databases are isolated and API keys are region-scoped (see
[API key rejected](/developers/faq/api-key-rejected)). If you need data in both,
create two organizations — one per region.

## What is region-scoped

Everything that holds customer data is region-scoped: applicant
verifications and applicant data, organizations and members, API keys,
audit log, workflow templates, webhook endpoints, wallet, transactions,
and subscription state.

Every database query carries a tenant scope and a region assertion. A
query that would cross regions fails at the client boundary, not at
the database. This is enforced by code, not by policy.

## Cross-region rules

There is no replication between regions. An EU verification is invisible
to a US API key; an EU webhook endpoint never receives US events; EU
wallet funding is processed within the EU region.

Some operational data is global by design: identity records used for
sign-in (the auth service stores only email, password hash, and MFA
factors — no tenant data), the marketing site, and the documentation.

## Where checks run

Some checks are region-restricted by contract and regulation; an EU
verification's checks run only on EU-approved infrastructure. When you
edit a workflow template, only the checks approved for the
organization's region appear.

## Biometric data

When a workflow template's `id_verification` check uses an
active-liveness biometric mode, the applicant's face scan is biometric
data, a special category that the platform pins even more tightly than
ordinary verification data.

- **Streaming stays in-region.** An EU organization's liveness video
  streams only to the EU region (Ireland); a US organization's streams
  only to the US region. The stream never crosses the regional
  boundary.
- **Only the reference image is stored.** The platform keeps the single
  reference frame needed to match the face against the document; it does
  not store the raw video. The reference image lives in the same
  region's encrypted object storage as the document images and is
  encrypted at rest.
- **Erasure covers everything.** A deletion — whether under the
  retention schedule or a subject erasure request — removes the
  stored image, its encrypted storage reference, and the encrypted
  identity data extracted from the document.

The selfie biometric mode (`selfie`) captures a still image rather than
a stream, and it is stored and erased the same way as the liveness
reference image.

## Moving an organization between regions

The platform does not move an organization between regions. The
boundary exists precisely so customer data cannot leave its declared
jurisdiction without an explicit data export. If you need to migrate,
create a new organization in the target region and re-import business
configuration via API; applicant PII stays in the source region and
expires per its retention policy. Talk to support first.

## More on compliance

See [organization compliance](/guides/organizations/compliance) for
the service agreement, the data processing addendum, and the
sub-processor list.