Where is my data hosted?

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 console.us.checktiv.com, API api.us.checktiv.com.
• EU region. Console console.eu.checktiv.com, API api.eu.checktiv.com.

The databases are isolated and API keys are region-scoped (see 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.

Credit history

The credit_history check runs on US-region organizations. An EU-region organization does not see the Credit history check row in the workflow editor at all, rather than a switch it cannot turn on, so a workflow template that could not run the check cannot be authored either.

Two separate questions decide whether a given credit report is ordered, and neither one answers the other:

• The region question asks whether an organization’s region may run the check at all. It is a per-region allowlist rather than a single shared switch, so enabling one region never enables the other by accident.
• The applicant question asks whether a report can be ordered for one person, from where they live. Reports can be ordered for applicants in the United States and Canada. So a US-region organization can have an applicant the check cannot run for, and an applicant in a covered country can belong to an organization whose region does not run the check. Both gates are evaluated; neither stands in for the other.

The EU region is excluded because two questions are open, not because the answer to them is no, and both have to be settled before it changes:

1. A written confirmation covering whether a credit report can be ordered for an EU-region organization and where that report would be fulfilled and stored.
2. An order observed from the EU region proving it in practice.

The second half of the first question is the residency one, and it is why an answer to orderability alone would not be enough: a report that can be ordered but is fulfilled outside the region would move applicant data across the boundary this page says it never crosses.

If your applicants are in the United States or Canada and you need this check now, the supported route is the one described under US vs EU: create a second organization in the US region and run those verifications there. Your EU organization keeps its data in the EU region and is unaffected.

For what the check collects and what it costs, see Credit history.

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 for the service agreement, the data processing addendum, and the sub-processor list.