Deployment Models & Data Tiers

Two independent choices shape how the IDV Platform runs for a Company: where it is hosted (deployment model) and how much data it keeps (data tier). Both use the same API, so integrations do not change when a choice changes.

Deployment models

Model	Description	Best for
SaaS (Innovatrics-managed)	Hosted and operated by Innovatrics. No infrastructure to run; scales automatically. Upgraded to every new release by Innovatrics. Many Companies share the infrastructure, each in its own isolated tenant.	Fast time-to-market; teams that do not want to operate biometric infrastructure.
Self-hosted	Installed into the Company's own Kubernetes cluster (on-premises or private cloud) from a versioned release package, with one install command and one configuration file. Same product, same API, Company-managed operations and upgrade schedule. The installation serves only the Company that runs it.	Banking, telco, insurance, government — where data residency, sovereignty, or internal policy requires control over where personal data is processed.

Both models are GDPR-compliant and expose an identical API surface.

Self-hosted installation

A self-hosted installation is delivered as a versioned Helm chart together with the container images of the release. Innovatrics publishes both to a private registry; the chart pins every image by version, so an installation runs exactly the set of components that was tested together.

What the Company provides

The platform's data stores are referenced, not installed, so they stay under the Company's backup, encryption and access policies:

Prerequisite	Used for
Kubernetes cluster (1.29 or later)	Runs every platform component. A CNI that enforces network policies is recommended — see Isolation inside the cluster.
PostgreSQL	Customer and Digital Identity records (one database per tenant), configuration, identity provider and workflow state. TLS with the Company's own CA is supported.
Redis	Session state and caching.
S3-compatible object storage	Captured images and documents. Stores that do not support batch deletes are supported too.
Secret store	Database credentials, licences and internal keys, synchronized through the External Secrets Operator. Secrets are never written into the configuration file — the installation refuses literal passwords, tokens and keys there.
Licence files	The licences for the biometric engines, issued by Innovatrics.
Outbound HTTPS to the usage-reporting service	Required for usage reporting, directly or through an HTTP proxy.

What the installation does

Checks before it changes anything. Every install and upgrade first validates the configuration and lists every problem at once — missing values, missing secret-store entries or licences, inconsistent settings — each naming the setting to fix. It then connects to the database and checks that the licences are present, before any platform object is created or changed, so a misconfigured install stops cleanly instead of failing half-way.
Installs in the right order. Databases, schema migrations, the identity provider and seed data are set up in dependency order within one command; a failed setup step fails the release with its log kept for diagnosis.
Exposes only what must be public. The API gateway (the single entry point for every API call), the identity provider, the real-time channel of the hosted capture UI, the hosted capture UI and the dashboard (each of the two can be switched off). All other components, including the biometric engines and data stores, are reachable only inside the cluster.

Private registries and air-gapped sites

Every image the installation runs — the platform's own and third-party components such as the identity provider, the workflow engine or the vector database — can be pulled from a single registry mirror under the Company's control. The images keep their pinned versions and digests in the mirror, and the installation reports any image still pointing at a public registry, so a site without internet access for image pulls can be installed without editing individual images.

Isolation inside the cluster

With network-policy enforcement in the cluster, the internal biometric and search components accept connections only from the platform services that call them. The internal debugging interface of the document search component is switched off.

Monitoring

One telemetry endpoint. Point the installation at one OpenTelemetry (OTLP) endpoint, and traces, metrics and — optionally — logs of every component are exported to it. Retention, dashboards and SIEM forwarding stay in the Company's own observability stack. Without an endpoint nothing is exported.
Ready-made alert rules. For clusters running the Prometheus Operator, the installation can create the scrape targets and a set of alert rules: unreachable or restarting components, biometric licence expiry, 1:N watchlist updates that could not be applied, and erasures that could not be completed.

Upgrades

Each release is a new chart version. Database migrations are forward-only: rolling back the chart restores the previous components but not the previous database schema, so take a database snapshot before every upgrade. Release notes in What's New list the Action required items for each version.

Data tiers

The data tier determines whether verification data is kept after a session ends. It maps directly to the commercial model.

Tier	What it does	Billing model
Session-based (no storage)	Runs the verification and returns the result. No Customer or Digital Identity records are kept; no images are retained beyond the session.	Priced per session.
Stored	Persists Customer and Digital Identity records, captured images, and audit history. Unlocks the back office, record management, and fraud tooling.	Priced per stored user.

On top of the Stored tier, Companies can add:

Add-on	What it adds
1:N Biometric Identification	Facial duplicity check against watchlists — detect duplicate accounts, catch repeat fraudsters, recognize returning customers. Requires the Stored tier. Without this add-on, the face template kept for 1:1 face comparison is stored for that purpose only and is not added to any searchable face index.
Palm verification	Palm enrolment during onboarding and 1:1 palm authentication as a second biometric modality — see Palm Verification. Requires the Stored tier.

Both add-ons are enabled per tenant by Innovatrics as part of the plan; when an add-on is off, its workflow steps, Trust Factors and back-office tabs are not shown.

What each tier enables

Capability	Session-based	Stored	Stored + 1:N
Document & face verification, liveness, fraud checks	✅	✅	✅
Result returned to the integrator	✅	✅	✅
Customer & Digital Identity records	—	✅	✅
Back office (review, CRM, audit)	—	✅	✅
Document duplicity check (name / DOB / number)	—	✅	✅
Palm enrolment & authentication (add-on)	—	✅	✅
Facial duplicity check & watchlists (1:N)	—	—	✅

Usage reporting

Usage is metered by the Innovatrics Transaction Counting System in both deployment models — per session on the session-based tier, per stored record on the Stored tier. The reports contain operation counts only, never personal data; self-hosted deployments can choose a count-only or an offline mode. See Usage Reporting.

Session-based keeps no personal data after the session — the lightest privacy footprint.
Stored retains data for the lifetime of the Customer relationship; the Company controls erasure through anonymization.
Erasure and backups. Anonymization removes the person's data from the live databases, the object storage and the biometric search indexes; object-storage and document-index deletes that fail temporarily are retried until they are confirmed. Existing backups are not edited: they are used only for disaster recovery and the erased data ages out of them with the backup retention period. Every anonymization is also recorded in a separate, write-protected erasure log, which is re-applied after a restore — data of a person who asked to be erased does not come back into the live system with an older backup. On a self-hosted installation the erasure log is enabled by configuring a dedicated storage bucket for it.
Transport is always encrypted; captured media is encrypted in transit and, on the Stored tier, at rest.