Data residency

Fanzava runs in regional cells. A cell is a complete stack in one place: its own Worker deployment, its own PostgreSQL database, its own queues and its own background jobs. A hub’s rows live in exactly one cell, and every request for that hub is routed to it.

Enterprise

Choosing which region your hub sits in is an Enterprise capability. Every other hub is assigned a region by Fanzava at sign-up.

Live regions

Region	Status	Database location	Serves
Australia	Live	Sydney (ap-southeast-2)	AU, NZ, and every hub whose region has no cell of its own
European Union	Live	Frankfurt (eu-central-1)	Hubs on the EU region
United States	Built, not yet provisioned	us-east-1	Not serving hubs yet

Australia is the home region. It serves every hub that has not been placed somewhere else, including hubs on the United States, United Kingdom, France and Tokyo region tags, because none of those has a live cell today.

!

Warning

Picking a region that has no live cell tags your hub and moves its email, not its rows. Until the United States cell is provisioned, a hub on a US region is served from Sydney. If your requirement is that participant data sits outside Australia, the European Union is the only region that satisfies it today.

The EU region is named Europe West (Belgium) in the region catalogue and its database runs in Frankfurt. Both are inside the EU, which is the boundary the residency commitment is written against.

Regions and email zones are not the same list

Fanzava sends mail from five residency zones: Australia, United States, European Union, United Kingdom and France. All five are provisioned with verified DKIM and MAIL FROM records, and a hub’s zone decides which one sends its mail.

Only three of those five are cells, and only two of the three are live. So a hub on the United Kingdom region has its mail sent from London today while its rows are in Sydney. That is a real email residency improvement and it is not data residency. Where the two need to agree, choose the European Union region.

How a request reaches the right cell

There is one public API hostname, api.fanzava.com, and one set of hub hostnames. There are no regional endpoints for a client, an SDK or a mobile build to hold, because a client holding the wrong one would be refused rather than merely slowed.

1. A request arrives at the edge on your hub’s hostname.
2. The edge resolves the hostname to a hub and reads which cell holds it.
3. The request is forwarded to that cell over an internal service binding, keeping your hub’s own URL.
4. The cell serves the request from its own database.

A hub whose cell cannot be determined is refused. It is never served from a guess, because a query against the wrong cell returns an empty hub rather than an error.

What sits in your cell, and what does not

Everything substantive about your hub is in your hub’s cell:

• Participant accounts, profiles, and authentication records
• Tips, bracket picks, margins, scores and leaderboards
• Groups, rivalries, prizes and banter board content
• Branding, settings, sender domains and competition configuration
• Analytics events, email send logs and the audit log
• Bounce and complaint records for mail your hub sends (one exception for European Union hubs, covered under Bounces and complaints)
• Billing records for the hub

Two small indexes are held centrally in the home region so that hostnames and payments can be routed before any hub database is opened:

Index	Holds	Does not hold
Hub directory	Hub id, subdomain, custom hostnames, which cell, status	Any participant data, any hub content
Payment reference	Payment provider customer and subscription ids mapped to a hub id	Card data, invoices, any participant data

Neither index contains participant personal data of any kind. Their whole job is to answer “which cell” without opening a database to ask.

Caches

Fanzava keeps short-lived caches in Cloudflare Workers KV for hostname routing, feature flags and read models such as leaderboards. Workers KV replicates globally and is not bound to a region, so nothing written to it names or contacts a participant:

• Leaderboards are cached as rankings against account ids. Names and photos are looked up from your cell’s database each time a leaderboard is shown.
• Member exports and import error reports are stored in your cell’s object storage, not in the cache.
• Where a cache key has to be derived from an email address, it is a hash of the address, never the address itself.

Account and session ids, and the hashed email keys above, do appear in cache entries. They are pseudonymised personal data: they carry no name, contact detail or content, and can only be linked to a person through your cell’s database, which Fanzava holds. Because Workers KV is global, these identifiers are processed outside your hub’s region, under the Standard Contractual Clauses in Fanzava’s Data Processing Agreement.

Database connections go through Cloudflare Hyperdrive with its query cache switched off in every region, so query results are never cached outside the database.

Platform sports reference data (sports, leagues, teams, seasons and fixtures) is published read-only from the home region to every cell, so a European hub picks its sport and scores its round from data held in Frankfurt.

Bounces and complaints

Amazon SES reports a bounce or a complaint to the region that sent the mail, and that report is processed in the cell that holds the hub. A bounce on mail sent from Frankfurt is recorded in the European Union cell. Bounces from the United Kingdom, France and United States zones are recorded in Sydney, because that is where those hubs’ rows are held today.

One thing leaves the cell, by design: the recipient address is added to the SES suppression list in every zone, so a bounced or complaining address is not mailed again from any region. That list holds the address and the reason, not the message. Routing the report needs no lookup, because each zone’s reports arrive on their own address and that address names the cell.

For a period after the European Union cell went live on 9 September 2026, bounce and complaint reports for its hubs were processed in Sydney rather than Frankfurt. The records written in that period (the suppressed address, the reason, and the delivery event) are held in the home region. They will be copied to the European Union cell, and whether the Sydney copies are deleted is with our Data Protection Officer. Ask support if your hub is affected and you need the outcome for your records.

Selecting a region

Region choice is not offered during self-serve sign-up. New hubs are assigned the nearest serviceable zone from the country the hub was created in, and hubs created from an unrecognised location are assigned Australia.

Enterprise hubs set their region in Admin → Settings → Data residency, or during Enterprise onboarding.

!

Warning

The first region you set locks. After that, the region cannot be changed self-serve and a change is an assisted migration: Fanzava moves the data, on a ticket, at an arranged time. There is no automated cross-region data movement. Set the region before you invite participants.

A hub using a static sending-domain setup cannot change zone by itself even before the lock, because each zone needs its own MAIL FROM subdomain with its own MX record published at your DNS provider. Contact support and the zone change and the DNS change are done together.

Deletion and data subject requests

A deletion or access request is searched in every live cell, not only the one your hub sits in, because the person making the request may be a member of hubs in more than one region.

Each cell records the search it performed: what it was asked, and what it found. That per-cell record is the one a European controller or regulator is shown, and it is separate from the staff action record held in the home region.

If a cell cannot be reached, the response says so. A result that lists one region is never presented as a complete search of all of them.

Group-scoped operations

Groups, group leaderboards, group analytics and group prizes inherit the hub’s region. One group within a hub cannot sit in a different region from the hub, which is what keeps cross-group leaderboards and inter-group rivalries inside a single database.

Regulatory position

GDPR

A hub on the European Union region holds its participant records in the EU, which addresses Article 44 for that storage without relying on Standard Contractual Clauses. The pseudonymised identifiers held in the global cache layer (see Caches) are the exception, and rely on the Standard Contractual Clauses in Fanzava’s Data Processing Agreement.

For hubs in other regions with EU participants, Fanzava’s Data Processing Agreement includes the EU Standard Contractual Clauses by default. See DPA and GDPR.

UK GDPR

UK GDPR is a distinct framework. Fanzava’s residency controls apply equally to UK data subjects, and the UK adequacy decision regarding the EU means UK residents’ data held in the EU region is covered. For a hub that needs its data inside Europe, select the European Union region rather than the United Kingdom one: the United Kingdom region is an email zone today, not a cell.

Australian Privacy Act

A hub on the Australia region holds its data in Sydney. The Notifiable Data Breaches scheme applies. See DPA and GDPR.

Encryption

All data at rest is encrypted with AES-256 and all traffic in transit uses TLS 1.3. Keys are managed by the underlying provider’s key management service in the region the data sits in. See Data protection.

Fanzava does not currently offer customer-managed encryption keys or a contractual commitment that decryption is technically impossible outside a given region. If your procurement process requires either, raise it with your account manager before signing rather than after.

Sub-processors

Each cell’s transactional database (Neon PostgreSQL) and object storage (Cloudflare R2) are provisioned in the cell’s region, and the European Union cell’s object storage is created under Cloudflare’s EU jurisdiction. Durable Objects are created with a location hint for the cell’s region, which is a placement preference rather than a jurisdictional guarantee. Workers KV is global and holds no participant names or contact details (see Caches). Amazon SES sends from the region matching the hub’s email zone. The full list is published on the Fanzava sub-processors page.

i

Note

Data residency governs where data is stored and processed at rest. Traffic may transit other regions in delivery, and requests are accepted at the Cloudflare edge nearest the visitor before being forwarded to the hub’s cell. All of it is encrypted in transit.