Truefold — Data Residency & International Transfers
Version 1.0 — Effective 2026-08-27 · Published at truefold.ai/legal/residency · Forms part of the Truefold Merchant DPA
Last updated: 2026-08-28
This statement records where Truefold stores and processes merchant data, and the legal basis for each cross-border transfer. Truefold is operated by Auke Vos, an individual established in Mexico; the service's infrastructure runs in the United States and, for pinned datasets, the European Union. Contact: privacy@truefold.ai.
1. Where data lives
The primary Customer Data store — per-merchant BigQuery datasets — is region-pinned. Each merchant's synced data lands in a dedicated dataset in a dedicated Google Cloud project, and the dataset's location is fixed at creation:
| Merchant | Dataset location | Notes |
|---|---|---|
| Default | United States (US multi-region) | |
| EU-established merchants (on request or detected at onboarding) | European Union (EU multi-region) | The dataset — and therefore the persistent Customer Data — never leaves the EU. BigQuery does not relocate data out of its configured region. |
A dataset's region cannot be changed after creation; an existing merchant switching residency requires a re-sync into a new dataset in the target region, which Truefold performs on request (source platforms retain the history to re-backfill from).
The control plane — application database and authentication (Supabase), backend API and sync engine (Railway), and web frontend (Vercel) — is hosted in the United States for all merchants regardless of dataset region. The control plane holds merchant account data, the semantic model (metadata), redacted logs, and query results in transit; the persistent Customer Data store is only the region-pinned BigQuery dataset. AI model inference (Vertex AI) is served from the United States.
Minimisation shrinks what crosses borders at all. Before any record is persisted, direct identifiers are dropped and customer emails are replaced with a store-keyed one-way hash (see the Data Use Disclosure). What resides in — and transits between — these regions is the minimised dataset, not raw customer identity data; full raw API responses exist only transiently in memory during synchronisation.
2. The transfer map
| # | Transfer | From → To | Mechanism |
|---|---|---|---|
| 1 | Merchant (EEA) → Truefold | EEA → Mexico (operator) / US (infrastructure) | SCCs Module Two, incorporated into the Merchant DPA (§ 12), governed by Irish law. Mexico holds no EU adequacy decision, so the SCCs — not adequacy — are the basis. |
| 2 | Merchant (UK) → Truefold | UK → Mexico / US | SCCs + UK International Data Transfer Addendum (DPA § 12.3) |
| 3 | Merchant (Switzerland) → Truefold | CH → Mexico / US | SCCs with Swiss FADP adaptations (DPA § 12.3) |
| 4 | Truefold → sub-processors | Mexico/EU → US | Each provider's DPA incorporating SCCs Module Three; EU-US Data Privacy Framework certification where the provider holds it (see the Sub-processor Register) |
| 5 | Merchant (US, CA, MX, other non-EEA) → Truefold | — → Mexico / US | No GDPR transfer mechanism required; the Merchant DPA's protections apply contractually to all merchants equally. For Mexican merchants, Truefold acts as encargado under the LFPDPPP and the DPA constitutes the required processing mandate. |
3. Why the operator's location matters — and why it is contained
Truefold's operator is established in Mexico. Two facts bound what that means for merchant data:
- No merchant data is stored in Mexico. All storage is in US/EU cloud regions listed above. The operator's access is remote administrative access to those systems, from Mexico, under the safeguards in DPA Annex II.
- Mexico's own regime applies on top, not instead. As a Mexican persona física processing personal data in the course of business, the operator is directly subject to the LFPDPPP (as reformed in 2025), including its processor (encargado) duties, security-measure and breach-notification provisions — obligations that run alongside, and do not dilute, the contractual GDPR commitments in the DPA.
For EEA/UK/Swiss merchants, the transfer to a Mexico-based processor is therefore lawful through the SCCs (transfers 1–3 above), backed by the technical measures in DPA Annex II — minimisation at ingestion, pseudonymised identifiers, region-pinned storage, and encryption in transit and at rest — which serve as the supplementary measures supporting the transfer-impact assessment.
4. Government access requests
Truefold has never received a government or law-enforcement request for merchant data. If one is received, Truefold will — unless legally barred — notify the affected merchant promptly, challenge overbroad or unlawful requests, and disclose only the minimum legally compelled, consistent with Clause 15 of the SCCs. Hosting providers' own transparency commitments (Google, Supabase's underlying cloud, Vercel, Railway) apply to data held on their systems.
5. Keeping this accurate
The residency guarantees above depend on cloud configuration — per-merchant dataset region pinning, the control-plane region, and each sub-processor's data processing agreement and Data Privacy Framework status. Truefold verifies these internally on a periodic basis, and before any new sub-processor or region change goes live it is reflected here and in the Sub-processor Register with the advance notice required by DPA § 6.
Change log
| Date | Change |
|---|---|
| 2026-08-27 | Initial statement (v1.0). Region-pinning decision recorded: US default, EU pin for EU merchants. |
| 2026-08-28 | Control-plane regions (Supabase, Railway, Vercel) verified US in each provider console. |