On-Premises AML Software

On-premises AML software is anti-money-laundering screening 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 — sanctions, politically exposed person (PEP), adverse-media and wallet screening — but the software and, above all, the firm's screening data run in an environment the firm controls, rather than in a multi-tenant platform shared with other customers.

For most regulated firms this deployment model is not a technical footnote. It decides where customer data and screening evidence physically sit, who operates the environment that holds them, and how isolated that environment is from other tenants. A crypto exchange, an e-money issuer or a payments firm with data-residency obligations, single-tenant requirements or strict internal-oversight expectations is making a real architectural choice when it weighs an on-premises or dedicated deployment against a hosted one.

This article sets out what on-premises AML software is, why firms consider it, what it asks of them in return, how hosted, dedicated and on-premises deployments compare, where the choice sits in a regulated platform, and where the boundaries lie.

What On-Premises AML Software Is

On-premises AML software describes a deployment model, not a different kind of check. The screening logic — matching a person, a company or a blockchain address against sanctions, PEP, adverse-media and wallet-risk data — behaves the same way wherever it runs. What changes is where it runs and who controls the environment and the data inside it.

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

One nuance shapes everything that follows. AML screening depends on external reference data — sanctions designations, PEP records and adverse-media sources that change from one day to the next. Because of that, an on-premises deployment rarely means a fully disconnected one; the reference data still has to reach the environment and stay current. On-premises describes where the firm's own data and the screening run, not a claim that the check needs nothing from outside.

Why Firms Consider On-Premises Deployment

The clearest driver is data residency. Screening handles identifying detail about customers and produces evidence a firm has to retain, and some firms are required — by regulation, by internal policy or by a client mandate — to keep that data within a defined jurisdiction or inside their own environment. A deployment that holds the data in a controlled location answers that requirement directly, where a shared hosted service may not.

Control and isolation are the next reasons. A single-tenant or on-premises arrangement means the firm's screening data is not co-located with other customers' data, and the firm has direct oversight of the environment that holds it. For an institution that has to demonstrate to a supervisor exactly where regulated data sits and who can reach it, that directness is easier to evidence than a shared platform is.

Third-party and technology risk is the third. Operational-resilience expectations now push regulated firms to govern their reliance on technology providers and to know, and record, where their data is held and how a provider is overseen. Choosing a dedicated or on-premises deployment changes the shape of that dependency: it reduces exposure to a shared platform while placing more of the environment inside the firm's own control and its own resilience arrangements. It also sits closer to the firm's internal systems, which can simplify integration with the platforms AML screening already runs alongside.

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, critically, the reference data current. Move the deployment inside a dedicated or on-premises environment and more of that operational work becomes the firm's own: running and patching the environment, managing its availability and recovery, and resourcing the people who keep it healthy.

The reference data deserves particular attention. Sanctions and PEP lists change frequently, and a screening check is only as good as the data behind it; a list that has fallen out of date is a control failure, not a minor lapse. A deployment that isolates the environment must still get updated designations into it reliably and on time. The obligation to screen against current data does not soften because the software runs on the firm's own infrastructure — if anything, the firm takes on more of the responsibility for meeting it.

Upgrades and change follow the same pattern. New capabilities, fixes and data-source changes that a hosted service applies centrally have to be planned and applied to a dedicated or on-premises deployment on a cadence the firm manages. None of this argues against on-premises deployment; it sets the honest price of it. The model suits firms that need the control and are prepared to carry the operational ownership that comes with it.

Hosted, Dedicated and On-Premises Compared

The three 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 responsibility moves from the provider to the firm.

No row makes one model correct on its own. A firm reads the table against its own obligations: where regulated data has to sit, how much isolation it must be able to show, and how much operational ownership it can realistically carry.

Where the Deployment Choice Sits

Deployment is a separate decision from capability. The checks a platform makes — and the way they are called, whether through an API on the critical path or a panel for review — are the same whether the screening runs in a hosted service or inside the firm's own environment. A firm can integrate AML screening into its onboarding and monitoring flows and then decide, separately, where that screening is deployed.

Grumpio delivers screening through Legichain, its AML and KYC product, which can be provided with on-premises or dedicated storage so that a firm's screening records, results and evidence sit in a controlled, single-tenant environment rather than a shared one. Legichain covers person and company screening against sanctions and PEP data, adverse-media screening and multi-blockchain wallet risk screening, returned as an automated API result with a risk score and a PDF evidence report, and available through both an API and a web panel drawing on a single credit pool. Pricing and product detail are published on the Legichain site. Screening a company in this way is not a substitute for full know-your-business (KYB) verification, and no dataset reflects every party across every jurisdiction without gaps.

Which firms reach for a dedicated or on-premises deployment is usually predictable: those with data-residency obligations, single-tenant requirements or internal-hosting policies that a shared service does not meet. For most others a hosted deployment is the proportionate choice. Treating the question as an architecture decision — and matching the deployment model to the firm's actual obligations rather than to a default — is what keeps it from becoming an expensive assumption later.

Scope and Boundaries

The deployment model does not change who owns the compliance decision. Wherever the software runs, a match is a signal the firm assesses rather than a verdict the software delivers, and the review of any flag and the record that supports it belong to the regulated firm. On-premises deployment changes where the data sits and who runs the environment; it does not move the decision to the provider.

It also does not, 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. How a deployment is actually built and maintained — the topology, the way reference data is refreshed, patching, key management and recovery — is the firm's own design responsibility and sits outside a general description like this one. 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 AML software is a choice about deployment, not about what is screened. It decides where a firm's screening data and evidence sit, how isolated the environment is, and who runs it — while the sanctions, PEP, adverse-media and wallet checks themselves stay the same. Its appeal is control and data residency; its price is operational ownership, including the standing responsibility to keep the reference data current wherever the software runs.

Choosing well means reading the firm's real obligations — where regulated data must sit, how much isolation it has to demonstrate, how much operational 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, is what turns a hosting question into a defensible architectural position.