Data residency
Enterprise hubs can select the geographic region where their hub’s participant data is stored and processed. Fanzava’s architecture is designed so that each hub’s substantive data lives entirely within its selected region — only a small, pseudonymised global identity record exists outside it.
Available regions
Section titled “Available regions”| Region | Coverage |
|---|---|
| Australia (Sydney) | Default for AU/NZ hubs |
| United States (Iowa) | Default for US/CA hubs |
| European Union (Belgium) | Meets EU data residency requirements |
For hubs on Free, Starter, and Pro plans, data is stored in the Australia region by default. Region selection is an Enterprise feature.
Additional regions are evaluated based on customer demand. Contact your account manager if you have a regulatory requirement the current regions don’t satisfy.
How data residency works
Section titled “How data residency works”Fanzava uses a two-database pointer architecture to keep regional data fully isolated while still supporting platform-wide functions like billing and global identity:
- Global Identity Database — stores only pseudonymised user identifiers (UUIDs) and a region pointer. It contains no participant PII, no tipping data, no leaderboard scores, no hub content.
- Regional Tenant Database — stores all substantive hub data: participant profiles, tips, scores, group memberships, branding, analytics. Each region has its own.
When a request arrives, the Worker middleware looks up the user’s region pointer in the Global Identity Database, then routes the request to the corresponding Regional Tenant Database. The lookup adds approximately 50ms to the cold-start request path and is cached at the edge for subsequent requests in the same session.
The practical consequence: your hub’s substantive data never leaves your selected region. Only the pseudonymised UUID-to-region mapping exists globally.
Selecting your region
Section titled “Selecting your region”Data residency is set at hub creation time:
- During hub setup (or during Enterprise onboarding), select your preferred region
- Fanzava provisions your hub’s database and storage in that region
Changing residency after data exists requires a migration — contact your account manager to arrange this.
What data is covered
Section titled “What data is covered”The following data is stored exclusively in your selected region:
- Participant profiles, credentials, and authentication history
- Tips, bracket picks, and scoring data
- Leaderboards and group memberships
- Hub branding, settings, and configuration
- Analytics events and email send logs
- Audit logs
Platform-level data held globally is limited to:
- Pseudonymised user identifiers (UUIDs only — no email, no name, no PII)
- Region pointers (which user lives in which region)
- Billing and invoicing metadata (processed by Stripe under their own residency model)
- Platform-wide configuration (pricing rules, feature flags, etc.)
This separation is what makes the regional residency promise hold.
Encryption and key management
Section titled “Encryption and key management”All data at rest is encrypted with AES-256, and all traffic in transit uses TLS 1.3.
For EU-region hubs, Fanzava uses regional key management — encryption keys are generated, stored, and rotated within the EU. Decryption of EU hub data therefore cannot occur outside the EU, even by Fanzava’s own engineering. This is one of the controls supporting Schrems II compliance.
For AU and US-region hubs, encryption keys are managed within Cloudflare’s standard key management infrastructure, which itself maintains regional controls.
Group-scoped operations
Section titled “Group-scoped operations”When data residency is set on a hub, all of its groups, group leaderboards, group analytics, and group prizes inherit the same residency. There is no mechanism for one group within a hub to be stored in a different region than the hub itself. This keeps cross-group leaderboards and inter-group rivalries within a single regional database.
Regulatory compliance
Section titled “Regulatory compliance”GDPR and Schrems II
Section titled “GDPR and Schrems II”Hubs with the EU region selected satisfy GDPR Article 44 (transfers to third countries) without requiring additional Standard Contractual Clauses for data at rest. Combined with regional key management, this addresses the post-Schrems II concern about authorities outside the EU being able to compel access to EU residents’ data — the keys to decrypt that data exist only within the EU.
For hubs in other regions where EU residents are participants, Fanzava’s Data Processing Agreement includes EU Standard Contractual Clauses by default. See DPA & GDPR for detail.
UK GDPR
Section titled “UK GDPR”UK GDPR is a legally distinct framework following Brexit. Fanzava’s residency controls apply equally to UK data subjects, and the UK Government’s adequacy decision regarding the EU means UK residents’ data stored in the EU region is covered.
Australian Privacy Act
Section titled “Australian Privacy Act”Hubs with the Australia region selected satisfy Australian Privacy Act requirements for data localisation. The Notifiable Data Breaches scheme applies — see DPA & GDPR.
Sub-processors
Section titled “Sub-processors”Fanzava’s regional sub-processors operate within the residency model: regional storage providers (Neon PostgreSQL for transactional data, Cloudflare R2 for object storage, Cloudflare KV and Durable Objects for edge state) honour the region selected at hub creation. The full sub-processor list is published at fanzava.com/legal/sub-processors.