Architecture and data handling
What crosses which boundary, what is persisted, and what is not. The alternative to this page is a questionnaire and three weeks.
The proxy model
Your customer authorizes an app you registered — not one we registered. Records move from their system to the destination through Ngentix, which acts as a proxy on behalf of your app. Ngentix is not the app; it is the thing carrying the records.
That distinction decides whose name appears on the consent screen, and it is why the registration is yours to own.
What is persisted, and what is not
The last row is the one a security reviewer is checking for. Payloads are in flight only: they are read from the source, mapped, written to the destination, and not kept.
| Data | Stored | Where |
|---|---|---|
| Credentials and tokens | Yes — encrypted | The deployment you run on |
| Field mappings and confidence scores | Yes | The deployment you run on |
| Flow definitions | Yes | The deployment you run on |
| The audit record | Yes | The deployment you run on |
| Record payloads | No — passed through, never retained | — |
Shared versus licensed
On shared infrastructure, records pass through an environment Ngentix operates. On a licensed deployment they pass through an environment you operate, inside your own perimeter — which is what makes residency a fact you can show an auditor rather than a preference you negotiated.
The engine, the mappings and the confidence line behave identically in both. What changes is whose account the records cross and who operates the thing that moves them.
Where flows run
On shared infrastructure, flows run in the United States. That is the whole answer today: there is one region, records are processed there, and if your obligations require them to stay somewhere else, the shared platform is not the right fit yet.
On a licensed deployment the question does not arise in the same way — the deployment sits in your own account, in the region you put it, so residency is whatever you have already decided it is.