Why on-premises sanctions screening keeps customer data in house
A compliance lead or CISO whose policy bars sending customer names to a hosted screening API can meet that requirement by running yente inside their own network, with matching and the customer names it processes staying in house. The decision turns on three things: how GDPR transfer rules apply to the screened personal data, what licence governs the list data used for internal commercial screening, and who runs the update pipeline that keeps the lists current. This is a narrower question than the general AML page covers. Detection strategy and case handling are not the issue here. The issue is where personal data is processed and who can reach it.
The data at stake is personal data screened against lists of sanctioned persons and politically exposed persons, so the question is where processing and access happen, not only where the data is stored. The EDPB's Guidelines 05/2021 treat remote access from a third country, even only displaying data on a screen for support, as a transfer. A hosted API that matches names in another jurisdiction, or a vendor support engineer who can view request logs from abroad, therefore needs a transfer assessment, while a self-hosted deployment with access limited to your own staff and processors avoids that path. Confirm with your counsel which of your processors and support paths still reach the data, because the hosting decision alone does not settle it.
On the platform side the split is simple. yente is the screening service that answers match requests, and OpenSanctions supplies the list data it loads. Choosing on-premises screening is a hosting decision: the matching engine is the same whether you run it in your data center, a private cloud account or a hosted service. Your work is to confirm the OpenSanctions data licence for your intended internal use, set up a scheduled and auditable refresh of the bulk data, and document how you will test that the update pipeline is working. Ask any implementation partner to show how the data, the service and its logs stay inside your boundary, and which of those components they will operate after go-live.
Requirements that shape a local screening build
This table maps each legal and licensing requirement to what it means for where screening runs, who can reach it and how list data arrives. Read it as a checklist for network placement, access control and the update pipeline, and confirm each row with your privacy and legal teams before fixing the design.
| Requirement | What it asks for | Build impact on placement, access and updates |
|---|---|---|
| GDPR Article 44 and Chapter V | Every transfer of personal data to a third country, including onward transfers, must meet Chapter V conditions | Map every access path, including vendor support sessions, backups and logs, to a location. Keep screening data and its replicas inside the EEA unless a transfer basis is documented. |
| EDPB Guidelines 05/2021 | Remote access from a third country, even only viewing data on a screen, and storage in a non-EEA cloud both count as transfers | Block support tunnels from outside the EEA or require a documented basis. Vet cloud regions for backups and monitoring tools that copy screened names. |
| Article 83 fine levels | Up to EUR 20 million or 4% of worldwide annual turnover for transfer and principle breaches, and EUR 10 million or 2% for Articles 25 to 39 | Treat transfer errors as high-severity findings. Restrict production data in test and update environments, which often sit outside the core zone. |
| Article 32 security of processing | Appropriate technical and organizational measures for the risk, such as encryption, access control and resilience | Encrypt list and match data at rest, enforce role-based access to case records, and segregate the screening zone. Document controls for the assessor. |
| Articles 33 and 34 breach notification | Notify the supervisory authority of a personal data breach without undue delay, and affected individuals when risk is high | Log every query and export so the scope of an incident can be established quickly. Confirm the notification clock with counsel. |
| Article 48 third-country disclosure orders | A foreign court or agency order to disclose personal data is enforceable in the EU only under an international agreement such as a mutual legal assistance treaty | Ask hosting vendors how they respond to foreign demands. Keep key material under your control so a provider cannot release readable data alone. |
| US CLOUD Act, 18 U.S.C. 2713 | US providers must preserve or disclose data in their possession, custody or control, wherever it is stored | If a US-parented provider hosts or supports the stack, assess this exposure before engagement. Local deployment on your own hardware or EU-controlled hosting reduces it. |
| Schrems II and the DPF | Privacy Shield was invalidated, standard contractual clauses survived, and Data Privacy Framework adequacy covers only listed US organizations, with Case C-703/25 P pending | Check whether each US vendor is on the Data Privacy Framework List and track the appeal. Prefer designs where no transfer depends on that adequacy decision. |
| OpenSanctions data license for internal commercial use | Internal use of the bulk data by a commercial firm depends on the license terms for that dataset | Confirm the license tier before loading bulk data. Build the update pipeline to pull only licensed datasets, and record the license and version used for each screening run. |
What data leaves the network when screening is hosted
A hosted screening API receives more personal data than most teams expect. Each request carries the customer's name, and often date of birth, nationality, address and the names of payment counterparties, so the vendor becomes a processor of personal data every time a customer is onboarded or a payment is checked. Before choosing that model, the compliance and privacy teams should list the exact fields each request sends, including fields such as name, birth_date, nationality and address in the request body, and confirm whether the vendor logs them, where those logs are stored and who can read them.
Under the EDPB guidelines on Article 3 and Chapter V (version 2.0), the question is not only where the vendor's servers sit. Remote access from a third country, even only displaying data on a screen for support, counts as a transfer, and so does storage in a cloud outside the EEA. The same guidelines (Example 12) say that using an EU processor subject to third-country law is not itself a transfer, but complying with a third-country authority's request would be. A hosted screening vendor with foreign support staff or foreign-law obligations therefore creates exposure that the institution has to assess before signing, not after an incident.
The EDPB Recommendations 01/2020 on supplementary measures add a harder limit. Where a provider needs data in the clear to do its work and the destination's public authorities have powers that go beyond what is necessary and proportionate, the EDPB states it cannot envision an effective technical supplementary measure. Encryption helps only when the provider never sees the plaintext. Our reading is that a hosted matching service, which must read names to match them, usually falls into that category. This is an argument for the institution's own assessment, not a legal opinion, so the reader should take it to counsel and record the outcome as part of the transfer assessment.
Which platforms fit a local sanctions screening stack
A local screening stack usually combines a matching service, a licensed copy of watchlist data, a transaction monitoring layer that consumes screening hits, and a messaging layer that keeps internal systems talking without sending names outside the network. Each component carries a different licensing, update and evidence question, so confirm those before any build begins.
yente as the matching service
yente is the open source screening API that OpenSanctions maintains, and it is the component that receives customer and counterparty names and returns scored matches. Running it inside your network keeps the query traffic and the personal data in the screened record under your control. Confirm with the vendor which yente release you will deploy, how it loads its index, and whether it supports the matching features your false positive process depends on.
OpenSanctions bulk data packaged in-house
A local service is only as current as the dataset loaded into it, so the bulk data copy is the core of the design. Before you download anything, confirm the license tier that covers internal commercial use, since the data terms differ from those for a hosted API. Also confirm the supported update mechanism, the frequency of releases, and how a dataset version is recorded for audit.
Update pipeline and version control
A screening decision is only defensible if you can show which list version was in force at the time of the check. Build a repeatable pipeline that pulls the approved dataset, validates it, promotes it to the matching service and retains the prior version. Ask the partner how rollbacks work, how failed loads trigger alerts, and how each run is logged for examiners.
Jube for transaction-side screening
Jube is the open source transaction monitoring platform in this stack, and it can take screening results as one input among rules and models. Use it to route a sanctions hit on a payment into a case with the transaction context, the matched entity and the analyst decision attached. Confirm how Jube receives external screening results, how it stores them, and which case fields are retained.
Message layer for internal calls
Internal systems such as onboarding, payments and case handling need a reliable way to request screens and receive results. A message broker or API gateway inside the network keeps those calls on internal paths, sets timeouts and retries, and logs each request. Confirm the chosen product's encryption, authentication and queue durability settings with its own documentation before you rely on it for screening evidence.
GDPR records for screened personal data
Each screen creates personal data about the customer, the match and the decision, so the records need a lawful basis, a retention rule and access controls under GDPR. Keeping the stack in house reduces transfers, but it does not remove controller duties such as security of processing under Article 32. Ask your data protection lead to confirm retention periods for hits, false positives and case notes before go-live.
How the list update pipeline is built and tested
The update pipeline turns each new list release into a verified, tested and recorded change, so the production screening engine only ever runs on data the institution can explain and reconstruct later. Each step leaves a written output that compliance and security teams can review.
Confirm the license before any download
Compliance and legal confirm in writing which list sources the institution may use, and whether internal commercial use of the bulk data is covered by the provider terms in force. The owner records the license terms, the permitted use and the contact for changes in the screening system's configuration record. The step is done when the approved source list is signed off, and no dataset enters the network without it.
Set an approved download path
The platform team configures a single, documented route for pulling list data into the network, usually through a controlled egress point or a manual transfer process. Access is limited to named service accounts, and every fetch is logged with source, time and requester. The output is a runbook and an access review entry showing who can trigger a download and from where.
Verify and hash each dataset
On arrival, the team checks the file against the provider's published integrity information where one is offered, then computes and stores a cryptographic hash of every dataset and its metadata. Any mismatch stops the pipeline and opens an incident. The output is a release record listing file names, hashes, release identifiers and the person who approved the import.
Load the release into a staging instance
The verified data is loaded into a staging yente instance that mirrors the production configuration, including matching thresholds, dataset selection and scoring settings. Staging stays isolated from live customer traffic. The check is complete when the staging service reports the expected dataset version and record counts match the release record.
Run regression screening against known test names
The team runs a fixed set of test names through staging, including known sanctioned entries, known negatives, close variants and transliterations drawn from the institution's own tuning cases. Results are compared with the previous release. Any new missed match, unexpected change in match score or spike in alerts is reviewed by the compliance owner before promotion. The output is a regression report stored with the release record.
Promote the release to production
After compliance signs off on the regression report, the same verified artifacts are promoted to production through the change management process, not rebuilt by hand. The change ticket links to the release record and the regression report. The step is complete when production reports the approved dataset version and a post-change screening check returns the expected results.
Retain prior versions for audit reconstruction
The team keeps every prior dataset, release record, configuration and regression report under retention rules set by the institution's records policy, so it can show which list version screened a given customer or payment on a given date. Access to archived versions is restricted and logged. The output is an index that maps screening decisions to the exact list release used.
Where to host the screening stack by control need
When yente, its search index and the OpenSanctions bulk data run in a data center the institution owns and staffs, the transfer question mostly comes down to who can see the screens, logs and backups. The institution controls the hardware, network and administrator accounts, so the main work is defining access and recording it.
- Support access: Vendor engineers should connect through a jump host inside the institution's network, using named accounts, multi-factor authentication and session recording where policy requires it.
- Log location: Request logs that carry names, dates of birth and match scores should stay in the internal log store, with retention set by the institution's own records policy.
- Remote access from abroad: If a support engineer in a third country views a screen or a log extract, EDPB Guidelines 05/2021 treat that display as a transfer even though no data is copied, so access from outside the EEA needs a Chapter V basis or should be blocked.
- Backups and disaster recovery: Backup copies and any secondary site must sit inside the same control boundary, or the same transfer analysis applies to them.
Confirm that the data center operator and any colocation provider cannot reach the hardware, and document the answer with the record of processing.
A private cloud in an EU region keeps storage inside the EEA, but storage location is only part of the picture. The provider's staff, support tooling and legal exposure still matter, because Chapter V applies to any access from a third country and to any onward transfer.
- Provider staff access: Ask where provider administrators sit and whether they can open consoles, snapshots or disks from outside the EEA, since any such view is a transfer.
- Telemetry and support paths: Control plane logs, managed monitoring and support tickets can replicate names outside the region, so list every service that touches screening data.
- CLOUD Act exposure: Under 18 U.S.C. 2713, a provider subject to US jurisdiction must preserve or disclose data in its possession, custody or control wherever it is stored. Confirm the provider's answer on that point and who holds the encryption keys.
- Article 48 requests: A third-country disclosure order is recognized only if it rests on an international agreement, such as a mutual legal assistance treaty. Ask how the provider handles such requests and whether it notifies the customer first.
- Encryption limits: Customer-managed keys reduce exposure at rest, but EDPB Recommendations 01/2020 state that where a provider needs data in the clear and third-country powers go beyond what is necessary and proportionate, no effective technical supplementary measure may exist.
Get written answers on each point before signing, and file the transfer assessment with the processor agreement.
In an air-gapped or restricted network the stack has no route to the internet, so there is no outbound path to a hosted screening API. The trade-off moves to updates: bulk data and software must arrive through an import process the institution can evidence.
- Support access: Remote support is limited to on-site staff or to sessions brokered through an approved bastion with time-boxed credentials. A vendor engineer abroad viewing a screen is still a transfer.
- Update import: Bulk data and container images enter through a controlled transfer process with checksum verification and a record of who approved each import.
- Log containment: Logs with names stay inside the enclave. Any export for an investigation should be tied to a named case, logged and deleted according to policy.
- Hidden outbound calls: Confirm that monitoring agents, licence checks and telemetry features do not call out, since a single outbound connection could create an unplanned transfer.
- Personnel list: Keep a current register of everyone with console or database access, including contractors.
Test the network boundary with the operator and describe the update procedure in the data protection impact assessment.
Evidence a regulator or auditor will ask for
This table maps each piece of evidence a data protection authority, auditor or bank partner is likely to request for on-premises screening to the component that produces it. Read it as a checklist: if a row has no owner or no retained output, that gap is the first thing to close. GDPR requires no audit report or certificate, and Article 42 certification is voluntary, so the evidence is what you show in your own accountability file.
| Evidence item | What it shows | Component that produces it |
|---|---|---|
| Record of processing and legal basis | Purpose of screening, categories of personal data, recipients, retention and the lawful basis for each screening step | Controller's processing register, maintained with the screening owner and the data protection officer |
| Transfer impact analysis | Whether any third-country access path exists, such as remote support, offshore backups or vendor access, and the measures applied | Data flow map and transfer assessment, reviewed whenever a hosting or support path changes |
| Access logs for screening data | Who queried or exported screening records, when, and from which account or network path | Identity provider logs, yente and application audit logs, and log retention settings in the central log store |
| Data licence and scope | That the list data licence covers internal commercial use and the screening modes you run | Written licence terms from the list provider, filed with the procurement record and the OpenSanctions data source details |
| List version per screening decision | Which dataset version was active when each customer or payment was screened, so decisions can be reproduced | Update pipeline manifest and screening decision records that store the dataset version identifier |
| Regression test results after each update | That matching behavior on known test names did not change unexpectedly after a data or software update | Test suite of reference names and expected matches, run in staging and the results archived per release |
| Breach response procedure | How a personal data breach is assessed, documented, and reported to the supervisory authority under Article 33 and to individuals under Article 34 | Incident response runbook, breach register and notification templates owned by the security and privacy teams |
| Article 32 security measures | Encryption in transit and at rest, access control, resilience, and testing of the controls that protect screening data | Infrastructure configuration baseline, key management records, backup and restore test records, and security test reports |
Questions buyers ask before building local sanctions screening
Does GDPR forbid hosted sanctions screening?
No. GDPR does not ban hosted screening, but it makes every transfer of personal data to a third country subject to Chapter V conditions, including onward transfers. Sending customer names to a hosted API located outside the EEA, or allowing remote access from a third country even only to display data on a screen, can count as a transfer under EDPB Guidelines 05/2021. Article 44 infringements carry fines of up to EUR 20 million or 4% of worldwide annual turnover under Article 83(5)(c). Local screening keeps names inside your network, which simplifies the transfer assessment, but it does not remove your other GDPR duties. Ask your counsel to map where each screened field travels, including support access and backups.
What drives cost and effort for an on-premises sanctions build?
Cost splits into one-time work and recurring work. One-time items include architecture, infrastructure setup, integration with onboarding and payment systems, matching tuning, validation evidence and staff training. Recurring items include hosting, the update pipeline, monitoring, patching, list license fees where your use requires them, and analyst time for alert review. The largest variables are the number of screened systems, transaction and onboarding volume, how many list sources you load, and how much evidence your examiners or auditors expect. Ask any partner for a fixed-scope quote that lists each component, who performs it, what is one-time and what recurs, and which assumptions would change the price. DeployOpen does not publish a price list.
How long does the rollout take and what must the institution provide?
Duration depends on the scope agreed in writing, so no fixed timeline applies to every institution. The main pacing items are infrastructure availability, identity and access setup, network connections to core systems, data owner decisions on match thresholds, and test cases agreed with compliance. Your team typically provides a named technical owner, access to the target environment, sample records for testing, a decision on which lists and jurisdictions apply, and a compliance reviewer who signs off on false positive handling. Ask a partner to show which of these inputs sit on the critical path and what happens if any one of them is late.
Can our team run the update pipeline after handover?
Yes, if the handover is planned for it. Keeping lists current means scheduled retrieval of OpenSanctions bulk data, validation of each load, a controlled reindex of yente, regression checks against known test names, and a record of which dataset version screened each decision. Your staff need runbooks, alerting for failed loads, access controls on the data store, and a rollback path. Ask whether the scope includes training, written runbooks and a support retainer for upgrades. Retainers for ongoing support, upgrades and testing are available from DeployOpen, and the division of work after handover should be written into the statement of work.
What does the OpenSanctions license need to cover?
Confirm the license terms for your use before the build starts. Internal commercial use, which covers screening your customers inside your own company, is a different case from redistributing data or offering a screening service to third parties. Ask the data provider in writing whether your intended use, including bulk data loaded into an internal instance, requires a commercial license, and which datasets are covered. Record the license terms, the dataset versions used and the date of each load, because examiners may ask what list was in force when a decision was made. Do not assume that an open source software license covers the data.
Does a local build remove our GDPR obligations?
No. A local build changes where screening runs, not who is responsible for the data. As controller, you still need a lawful basis, data minimization, access control, logging, retention limits, security of processing under Article 32, and breach notification under Articles 33 and 34. Any vendor or implementation partner that handles the data as a processor needs a written agreement under Article 28. GDPR requires no audit or certificate, and Article 42 certification is voluntary and does not reduce your responsibility. Engage your data protection officer early, and treat the screening system as a processing activity in your records.
Deciding whether local screening is the right answer
Local screening is justified when a policy, a regulator expectation or a contract stops customer names from leaving the network, when third-country access to a hosted screening service is hard to exclude, or when the institution needs direct control over which list version was used for each decision. Start by writing down which of those three conditions applies. If none applies, a hosted API may still be acceptable, but the reasons for that choice should be recorded in the same file as the screening design. The EDPB guidance on Chapter V treats remote access from a third country, even display-only support access, as a transfer, so the hosting question includes who can log in to the vendor's support tools as well as where the data is stored. Ask any hosted provider to show its access paths in writing before you accept a hosted design.
Local screening is not automatically safer. A self-hosted yente deployment moves the risk to your team: someone must pull OpenSanctions bulk data on a schedule, validate each dataset, keep the previous version available for rollback, patch the service and retain query and response logs that show which list version produced each match. If those duties are not staffed and tested, a local deployment can hold older lists and weaker evidence than a managed service. Decide who owns the update pipeline, how a failed refresh raises an alert, and how long screening records are kept before you commit to hosting the stack yourself.
Transfer rules are also moving, so treat the hosting decision as something to revisit. In *Schrems II* (Case C-311/18), the Court of Justice invalidated the EU-US Privacy Shield while holding that standard contractual clauses remained valid. The Commission's Data Privacy Framework adequacy decision, Implementing Decision (EU) 2023/1795, is under appeal as Case C-703/25 P. Confirm with counsel whether any hosted or support path touches US systems, and set a review date tied to that case so that a change in the outcome leads to a documented decision, not an emergency migration.
How a local screening rollout moves from data review to handover
The sequence turns a decision to screen in house into a documented, tested system that the compliance and privacy teams can explain to examiners and auditors. Each phase closes with a named output, so the owner knows what is finished before the next phase starts.
Map data flows and confirm the license position
The team lists every field that leaves the customer system for screening, including names, dates of birth, nationality, addresses and any entity ownership data, and records where each field is stored and logged. In parallel, the licensing lead reviews the OpenSanctions data terms for internal commercial use and writes down which datasets the institution may load and under what conditions. The step closes with a data map and a written license position signed off by the business owner and legal counsel.
Assess transfers and personal data obligations
Privacy and legal staff assess how the screening data is processed under the GDPR, including the lawful basis, data minimization, retention of match records and the roles of any vendor or support provider with access. They check whether any remote access, support session or backup could place personal data outside the EEA or under third-country access rights, and they test that exposure against the EDPB guidance on transfers. The output is a memo for the data protection officer that states the conclusions, the open questions and the controls the institution will rely on.
Design hosting, network and the trust boundary
The architecture team decides where the yente service, its index, the update jobs and the Jube connection will run, and which networks, identity providers and secrets stores they can reach. They draw a trust boundary diagram that marks what crosses the boundary, which direction traffic flows and which administrators can reach each component. The step is complete when the security and privacy reviewers have approved the diagram and every external connection has a named owner and a documented reason.
Build and test the yente and Jube integrations
Engineers deploy yente inside the approved boundary, connect it to the transaction and customer systems, and configure Jube so that screening results feed into alerts and case handling. They test the request and response paths with synthetic records, check that logs capture who ran which query and what result came back, and confirm that failures in the screening service stop or flag payments as the institution's policy requires. The output is a test report with each connection marked as passed, failed or accepted with a documented risk.
Set up the update pipeline and regression set
The team automates the retrieval of new OpenSanctions data, builds the index in a staging environment, and runs a fixed regression set of known names, aliases and edge cases before anything reaches production. Each data release and software version is recorded with its source, checksum, date, approver and test results so that any screening decision can be traced to the list state at the time. The step closes when a complete update has run through staging and promotion with release records kept in the evidence store.
Validate the system and hand over runbooks
Compliance staff validate the matching thresholds, alert routing and case workflow against the institution's written screening policy, and they document any tuning decisions and the reasons behind them. The delivery team writes runbooks for routine updates, incident response, access reviews, failover and restoration, and trains the operators who will run them. The handover closes with an evidence pack that includes the data map, license position, DPO memo, trust boundary diagram, test results and release records, and a named owner for each runbook.
