Regions and data residency
Personal data stays in the country it came from. That is a property of how the platform is built rather than a policy applied on top of it, and it is the constraint that shapes most of what follows.
Two kinds of plane
Section titled “Two kinds of plane”The platform runs as one control plane with a data plane per market.
The control plane sits in Singapore. It holds identity, tenancy, the scope catalogue, configuration and the schema registry. It holds no personal data.
A regional data plane holds the personal data, policy data and claim data for the tenants of one market. Markets with a residency rule that requires it are deployed in country. Markets whose rules allow it are served from a regional deployment.
The practical consequence for an integration is that a tenant’s records live in that tenant’s market, and a call that reads them is answered there.
What may move, and what may not
Section titled “What may move, and what may not”Every data element carries a class, and the class decides whether it can leave the plane it was written to.
| Class | What it is | Where it may go |
|---|---|---|
| Personal-resident | Anything identifying a natural person: name, national ID, phone, address, certificate number | Stays in its own market’s data plane |
| Regional-aggregate | Totals scoped to one market, such as monthly claim volume by line | Stays in its own market’s data plane unless anonymised and exported deliberately |
| Anonymised signal | A pattern with the identifiers removed, such as a claim-shape fingerprint | May reach the cross-region signal layer, with per-carrier consent |
| Cross-region aggregate | Suite-wide totals with no per-record provenance | May reach the control plane |
Four rules govern the movement itself:
Anonymisation happens before the data moves. The pipeline runs in the data plane that holds the source records, never in the destination. Data does not leave in order to be anonymised somewhere else.
Consent is recorded, per carrier. No carrier’s data reaches the signal layer without that carrier’s recorded consent, and the consent record lives in that carrier’s own regional data plane.
Only what is needed crosses. Aggregates are computed in the source plane, so what moves is the answer rather than the records it was computed from.
Personal data is never written across a region. It is written to its own market’s data plane and to nowhere else, including the control plane.
Why it is built this way
Section titled “Why it is built this way”The markets the platform operates in do not agree with each other on residency, and they will not converge. Vietnam and Indonesia require personal data to stay in country. Singapore and the Philippines allow more latitude and ask for contractual rigour instead.
A platform that assumes one region and adds residency later has to be rebuilt to get it, because residency is a question about where every write lands rather than a setting to switch on. Building it in at the start is the cheaper path, and it is the reason a new market is a deployment rather than a redesign.
Which regulation applies in a given market, and what it obliges a particular deployment to do, is a question for that market’s counsel and for the contract. This page describes the architecture, not a compliance opinion.