On-Premises KYC Software

On-premises KYC software is identity verification deployed inside a firm’s own or a dedicated environment, rather than consumed as a shared service the provider hosts and operates. The checks are the same — document authentication, biometric capture, liveness and face matching, age and address verification — but the software and, above all, the identity data it handles run in an environment the firm controls rather than in a multi-tenant platform shared with other customers.

For a regulated firm this is rarely a technical footnote, because of what KYC handles. Onboarding gathers some of the most sensitive personal data a platform holds: images of identity documents, a photograph or short video of a face, and the biometric comparison drawn from them. Where that material is processed and stored, how isolated it is, and who runs the environment holding it are questions a regulated firm with data-residency obligations cannot answer with a default.

This article sets out, at a decision-making level, what on-premises KYC software is, why firms consider it, what it requires in return, how the deployment models compare, and where the boundaries lie. It is written for teams that select and govern identity technology rather than those implementing it.

What On-Premises KYC Software Is

On-premises KYC software describes a deployment model, not a different kind of verification. Reading a document, confirming it is authentic, capturing a live face and comparing it to the document behave the same way wherever they run. What changes is where they run, and who controls the environment and the identity data inside it.

Three arrangements are worth separating. A hosted, multi-tenant service is run entirely by the provider, with several customers’ data in one shared platform. A dedicated, single-tenant deployment gives one firm its own isolated instance and storage, whether the provider or the firm operates it. An on-premises deployment places the software and its data inside the firm’s own infrastructure. The distinction that matters is isolation and control: how separate one firm’s identity data is from anyone else’s, and who holds the keys to the environment that stores it.

One characteristic of KYC shapes the rest. Unlike screening, which depends on reference lists that change daily, identity verification leans on a pipeline kept current in other ways — liveness and face-matching models retrained as attack methods evolve, recognition of reissued document versions, and the trust chains used to validate the chip in an electronic document. Some checks also reach an external source at the moment of verification. On-premises therefore rarely means fully disconnected; it describes where the firm’s identity data is held and where verification runs, not a claim that the pipeline needs nothing from outside.

Why Firms Consider a Dedicated or On-Premises Deployment

The clearest driver is data residency. Identity documents and biometric captures are personal data, and some firms are required — by regulation, internal policy or a client mandate — to keep it within a defined jurisdiction or inside their own environment. A deployment that holds the data in a controlled location answers that directly, where a shared service operating across regions may not.

The nature of the data sharpens the point. Biometric data used to identify a person is treated as a particularly sensitive category of personal data under UK and EU data-protection rules, and identity documents carry rich detail that is attractive to attackers and costly to lose. A single-tenant or on-premises arrangement keeps that material out of a shared platform and under the firm’s direct oversight — easier to evidence to a supervisor than a multi-tenant service is.

Third-party and technology risk is the next reason. Operational-resilience expectations push regulated firms to govern their reliance on technology providers and to record where data is held and how a provider is overseen. A dedicated or on-premises deployment reshapes that dependency: it reduces exposure to a shared platform while placing more of the environment, and its resilience arrangements, inside the firm’s own control.

What On-Premises Deployment Requires in Return

Control comes at the cost of ownership. In a hosted service the provider keeps the platform patched, the infrastructure running and the verification pipeline current. Inside a dedicated or on-premises environment, more of that becomes the firm’s own: running and patching the environment, managing availability and recovery, and resourcing the people who keep it healthy.

The verification pipeline deserves particular attention, because a KYC check is only as good as the models and reference material behind it. Liveness detection has to be maintained against new presentation and injection methods; document recognition has to keep pace with reissued versions; and the trust chains behind electronic-document checks have to stay current. A deployment that isolates the environment must still get those updates into it reliably — the responsibility for meeting them moves toward the firm, not away.

Retention is the other side of holding the data. Once identity documents and biometric captures sit inside the firm’s environment, decisions about how long to keep them, how to minimise what is stored and how to dispose of it become the firm’s to make and to evidence. A controlled location makes those decisions possible; it does not make them automatically. None of this argues against on-premises deployment — it sets the honest price of it.

How the Deployment Models Compare for Identity Data

The models answer the same questions differently. Setting them side by side makes the trade-off concrete: broadly, the more isolated and firm-controlled the deployment, the more operational and data-protection responsibility moves from the provider to the firm.

No single row settles the choice. A firm reads the table against its own obligations: where regulated identity data must sit, how much isolation it must demonstrate, and how much operational and retention ownership it can carry.

Where the Deployment Choice Sits

Deployment is a separate decision from capability. The checks a platform performs — and how they are called, whether through an API or an SDK — are the same whether verification runs in a hosted service or the firm’s own environment. A firm can integrate identity verification into onboarding and then decide, separately, where it is deployed.

Grumpio delivers KYC through Legichain, its KYC and AML product, which can be provided with dedicated or on-premises storage so that a firm’s identity documents, biometric captures and verification evidence sit in a controlled, single-tenant environment rather than a shared one. Legichain verifies European Union and Türkiye identity cards and passports, reads the chip in an electronic document over NFC, and performs selfie capture, liveness detection, face matching and age estimation, alongside address verification — returned as a fully automated result through an API and an accompanying SDK. Coverage of document types and regions is treated as something to confirm against the markets a firm serves rather than assumed to be universal, and verifying a person this way is not a substitute for full know-your-business (KYB) verification. Pricing and configuration detail are kept off the page and held on the Legichain product site.

Confirming that a real, identified person has been onboarded is also the foundation the wider compliance picture rests on, which is why identity verification is usually evaluated alongside the AML screening that follows it. Treating the hosting question as an architecture decision — matching the deployment model to the firm’s actual obligations rather than a default — keeps it from becoming an expensive assumption later.

Boundaries and Responsibilities

The deployment model does not change who owns the outcome. Legichain returns an automated verification result; any review beyond it — handling a borderline case, escalating, or deciding to onboard — remains the regulated firm’s own function, wherever the software runs. On-premises deployment changes where the identity data sits and who runs the environment; it does not move the decision to the provider.

Nor does it, by itself, make a firm compliant or secure. Holding data in a particular location is one input to a data-protection and resilience posture, not compliance in its own right; a controlled environment still has to be run well, kept current and evidenced, and the retention and minimisation of the data it holds still governed. How a deployment is actually built and maintained — topology, model and document-coverage refresh, patching, key management and recovery — is the firm’s own design responsibility, one input to its wider regulatory readiness rather than the whole of it. We do not provide legal opinions or guarantee authorisation. We implement regulatory and audit requirements across technology, infrastructure and operations.

Summary and Next Steps

On-premises KYC software is a choice about deployment, not about what is verified. It decides where a firm’s identity documents, biometric captures and verification evidence sit, how isolated the environment is, and who runs it — while the document, liveness, face-matching, age and address checks stay the same. Its appeal is control and data residency over unusually sensitive data; its price is operational ownership, including keeping the pipeline current and governing retention wherever the software runs.

Choosing well means reading the firm’s real obligations — where regulated identity data must sit, how much isolation it must demonstrate, how much operational and retention load it can carry — and matching the deployment model to them rather than to a habit. Deciding that deliberately, as part of regulatory readiness rather than under supervisory pressure later, turns a hosting question into a defensible architectural position.