Self-hosted OFAC sanctions screening

Self-hosted sanctions screening for OFAC compliance: what the function must do

A bank, fintech or payment firm can run yente on its own infrastructure against OpenSanctions data, but OFAC is not a technology standard with control IDs, so the core work is defining screening decisions, data licensing and records before any software is configured. Start by writing down which customers, counterparties and payment messages the firm screens, which lists apply to each, who decides whether a potential match is a true match, and what happens to a blocked or rejected item. Those decisions set the matching configuration and the workflow, not the reverse. Confirm the exact OFAC obligations, including blocking, rejection and reporting timelines, with counsel before scope is agreed, because the internal rules a firm writes must match what the law requires of it.

The supplied control facts set the technical and evidence expectations around the screening function. The FTC Safeguards Rule, at 16 CFR 314.4, applies to non-bank financial institutions under FTC jurisdiction and requires encryption of customer information, multi-factor authentication for anyone accessing information systems, change management, and logging of authorized user activity. A self-hosted screening service that holds customer names and match results falls under those controls if the firm is covered, so confirm coverage with counsel. SEC Rule 17a-4(b) applies to broker-dealers and sets retention of records for not less than three years, the first two in an easily accessible place. PCI DSS matters only where card data is stored, processed or transmitted, or where the screening system could affect that environment, so settle that scope early.

For firms operating in the EU, DORA shapes the contract and exit side of the same stack. Article 28(3) requires a register of information covering all ICT contractual arrangements, and Article 28(8) requires documented, tested exit strategies for ICT services that support critical or important functions. Where screening runs in your own network, you still need a named owner for the OpenSanctions data license, a dated process for refreshing lists, and an audit trail that shows which list version and threshold produced each decision. Ask any implementation partner to describe that evidence model in writing before the scope is agreed.

Which framework requirements map to screening controls

This table maps adjacent US and EU obligations to the configuration evidence a self-hosted yente deployment should be able to show. OFAC does not publish numbered control requirements, so these rows are frameworks that often apply alongside sanctions screening, not OFAC rules themselves. Read each row as a question for your counsel and compliance leads: which obligations apply to your entity, and which artifacts you can show an examiner or assessor.

Requirement	What it asks for	Screening configuration to evidence
FTC Safeguards encryption (16 CFR 314.4)	Encrypt customer information in transit over external networks and at rest	TLS between core systems and the yente API; encrypted storage for list files, match logs and case records
FTC multi-factor authentication (16 CFR 314.4)	MFA for any individual accessing an information system, unless the Qualified Individual approves an equivalent control in writing	MFA on the case console and admin access; yente API reachable only from approved internal services
FTC change management (16 CFR 314.4)	Documented procedures for changes to information systems	Version-controlled yente settings, threshold changes and list-refresh jobs, each with an approval record
FTC activity logging (16 CFR 314.4)	Log the activity of authorized users	Logs of every search, match disposition, threshold edit and export, with user ID and timestamp, sent to central storage
FTC testing cadence (16 CFR 314.4(d)(2))	Annual penetration testing and vulnerability assessments at least every six months, absent effective continuous monitoring	Yente, the update pipeline and the case system in test scope; test reports tied to a documented schedule
SEC Rule 17a-4(b) record preservation	Broker-dealers preserve certain records for at least three years, the first two easily accessible	Retention rules for screening results and dispositions; confirm with counsel whether this rule applies to your entity
DORA Article 28(3) register of ICT arrangements	A register of all contracts for ICT services	Register entries for the yente deployment, data sources, hosting and any support partner
DORA Article 28(8) exit strategy	Documented, tested exit strategies and transition plans for ICT services supporting critical functions	Tested fallback to manual review or an alternate screening engine; tested restore of list data
DORA Article 30(2) contract terms	Contracts state service and data locations, notice of changes and data return on termination	Contract clauses covering hosting location, processing location, change notice and return of case and match records

How yente matching thresholds, false positives and blocking decisions work

A self-hosted yente design turns on four decisions that the software does not make for you: which list sources are loaded, what fuzzy match score counts as a potential hit, how analysts clear false positives, and what happens after a confirmed match. Start by writing down each list source you intend to load, including the OpenSanctions datasets and any government lists your counsel requires, with the exact dataset version used for each run. yente returns scored candidates, but the threshold that separates an automatic review from silent clearance is a policy you own, so set it in writing and test it against a sample of known true matches and known false matches drawn from your own customer base before go-live. Record the results, because examiners will ask how the number was chosen.

False positive handling needs its own rules. Common names, transliterations and shared dates of birth will generate many candidates, and each clearance should carry a documented rationale that names the record, the list entry, the fields compared and the reviewer. Keep the schema, id and score values from the yente response with the case so the decision can be reproduced later. Set a second-review rule for high-value or high-risk clearances, and re-test the threshold whenever a list refreshes or your customer mix changes.

A confirmed match triggers a legal decision, not a technical one. Whether a payment must be blocked, rejected or held, who must be told, and how and when a report goes to the regulator depend on OFAC regulations and your own institution's obligations. Confirm the blocking and reporting timeline with qualified counsel, and do not rely on any figure in this section. Also confirm how list data may be used internally, because licensing for commercial use of OpenSanctions data differs from public government lists. The license question and the infrastructure choices are covered in the OpenSanctions data guidance and in the sibling page on on-premises sanctions screening, which covers the detail.

Which open-source platforms fit around yente

yente only answers a match query. The screening outcome depends on the systems that send it names, hold the customer record and act on the result. The cards below cover the platforms most often placed around yente and what your team must confirm about each integration before go-live.

yente for list matching

yente is the matching service that receives a name, date of birth or entity details and returns scored candidates from the sanctions and PEP datasets loaded into it. Its output is only as useful as the inputs you send, so confirm which fields your sources provide, how you normalize names and transliterations, and which match threshold your compliance team has approved in writing. Confirm the data license terms that apply to your internal use before loading any list.

Hyperswitch for payment routing

*Hyperswitch* is an Apache-2.0 payments platform that routes payments across processors, and it is the place where a screen can sit in the payment path before funds move. Confirm whether your screening call happens before authorization, before payout, or both, and what Hyperswitch does with a held or declined payment. Check that the screening request carries no card data beyond what your PCI scope allows.

Apache Fineract for customer records

*Apache Fineract* holds the customer, account and loan records for institutions running core banking or lending on it. Screening results must attach to the customer record so that an onboarding decision, a hold or a release can be traced to a specific screening event. Confirm how your Fineract configuration stores match results, who can override them, and how the record links to any blocked funds or accounts.

Odoo or SuiteCRM for master data

Odoo or SuiteCRM often holds the customer master data that feeds names and addresses to yente during onboarding. Duplicate or stale contact records create false positives and missed matches, so confirm the field mapping, the single source of truth for legal names, and how changes trigger a re-screen. Confirm the license terms of the edition you deploy, since Odoo Enterprise and SuiteCRM are licensed differently.

Jube as the monitoring layer

*Jube* is a self-hosted transaction monitoring platform that watches activity after onboarding, while yente checks parties against lists. Sanctions hits and suspicious patterns often reach the same investigator, so confirm how alerts from each system are routed, deduplicated and recorded in one case view. Confirm that neither tool becomes the sole record for a decision that your regulator expects you to document.

Where screening runs: onboarding, payments and periodic rescreening

Screening at onboarding runs when a new customer or party record is created, before the relationship is activated. The trigger is the record event in your onboarding workflow, so the account stays in a pending state until the review is complete. Yente receives the identifying fields your matching profile uses, such as name, date of birth and country, and returns candidate matches with scores and the list source behind each one.

Trigger: the account opening or party creation event, with activation blocked while any potential match is open.
Data sent: only the fields your matching profile needs, passed from the onboarding system to the yente service inside your network. Confirm the minimum field set with your privacy and compliance leads.
Analyst action: clear, escalate or block the relationship. Each disposition should cite the list entry and the attributes that were compared.
Records produced: the request reference, the candidate list with scores, the reviewer decision and identity, the timestamp, and the list version applied.

Confirm the response time your business can accept at this step and check that the workflow cannot activate an account while a potential match is unresolved.

Evidence auditors and examiners ask for from screening

This table lists the evidence an examiner or auditor is likely to request for a self-hosted OFAC screening program, the component that produces each item, and what to confirm before the review. Use it to check whether your records can be produced on request without rebuilding them after the fact. DeployOpen prepares this evidence, but independent auditors and examiners decide whether it is sufficient.

Evidence item	Produced by	What the reviewer checks
List source versions and load dates	Update pipeline and yente data load records	Which sanctions datasets were active on each screening date, and how quickly updates were loaded after publication
Matching configuration and threshold history	Version-controlled configuration repository and change tickets	Each fuzzy matching threshold value, who approved it, when it changed, and the reason recorded at the time
Sampled false positive clearance with rationale	Case system alert dispositions	A sample of cleared alerts showing the identifiers compared, the rationale for clearance, and the reviewer identity
Match decision logs	yente request and response logs, linked to the case system	That every screened customer or payment has a recorded result, including no-match outcomes, traceable to the list version used
Blocking and escalation records	Case system and payment hold workflow	Timestamps for blocks, escalations to the compliance officer, and any reports filed, against the applicable reporting deadlines
Retention of screening records	Archive storage and retention policy	That screening records, dispositions and list versions are kept for the period the institution's policy and applicable rules require, and can be retrieved
Access logs for authorized users	Identity provider and SIEM	Who viewed, changed or released a hold, with authentication events and multi-factor authentication evidence
Change management records	Ticketing system and deployment pipeline	Approval, testing and deployment evidence for rule, threshold and software changes to the screening stack
Penetration test and vulnerability assessment results	Security testing reports and remediation tracker	Scope, dates, findings and closure of issues for the systems that hold or process screening data

What screening tooling alone does not satisfy

A running yente instance produces match results, but it does not decide which matches are real, who may change a threshold, or how a blocked payment is reported. The cards below cover the controls, records and contracts that sit around the tool and that examiners, auditors and counsel will ask about.

List licensing and internal use

Sanctions and PEP data comes from providers whose terms govern whether you may load it into an internal system, run it for commercial purposes, or share matched records with affiliates. Confirm in writing with the data provider which dataset tier covers your use, how often you may refresh it, and whether derived records such as match logs fall under the same terms. Ask who owns the update obligation when a license changes.

Threshold governance and change approval

Fuzzy match scores decide which hits reach an analyst, so the threshold is a risk decision. Document the chosen values for names, addresses and dates of birth, the person who approved them, and the test results behind each change. Require a second approver and a regression run against known true matches before any threshold moves into production.

Alert staffing and clearing procedures

Every potential match needs a documented disposition, whether it is cleared, escalated or confirmed. Write the analyst procedure, define who holds clearing authority, and set a review queue that covers weekends and list update days. Record the evidence used for each clearance, such as identifiers compared and the reviewer's rationale, so a later examiner can follow the decision without the analyst.

Records retention by regulator

The retention period depends on who regulates you, not on the screening software. Where a broker-dealer is in scope, SEC Rule 17a-4(b) requires business records to be kept for not less than three years, the first two in an easily accessible place. Other regulators and state rules may set longer periods for screening logs and alert files. Confirm the applicable rule with counsel and configure storage, backups and deletion jobs to match.

Vendor and ICT contract terms

Where DORA applies, Article 30(2) requires each ICT services contract to state where services are provided and data processed, to require advance notice of changes, and to cover data return when the provider becomes insolvent or the contract ends. If a third party hosts, maintains or supplies data to your screening stack, these clauses belong in its contract. Review them with counsel and record the arrangement in your register of information.

OFAC blocking and reporting procedures

A true match on an OFAC list usually means the property must be blocked and reported, and the screening tool cannot make that determination. Your written policy should define who confirms a match, how funds are frozen, how the blocked property is recorded, and who files the report and within what period. Counsel should review the procedure against current OFAC guidance, and the team should rehearse it using a test case that is clearly illustrative.

What buyers ask before hiring help with self-hosted screening

What drives the cost of a self-hosted sanctions screening build?

The cost is driven by who is paid for each component, and most of it is labor rather than software. Expect separate lines for watchlist data licensing, infrastructure to run the yente service and its update pipeline, rule and threshold tuning, integration with customer onboarding and payment systems, validation of match behavior, and the analyst hours spent clearing alerts. Open-source software removes the license fee for the screening engine itself, but it does not remove the cost of data licenses or of the work to prove the system behaves as your policy requires. Infrastructure and data refresh recur every year, while design, integration and validation are largely one-time. Ask any quote to itemize these lines separately, state which ones are fixed and which are priced per volume or per update cycle, and name who holds each data license.

How long does a self-hosted OFAC screening project take?

Duration depends on scope, the number of systems being integrated and how deep validation must go, and no fixed timeline applies to every institution. A screening-only deployment with one or two intake points moves faster than a build that covers onboarding, card or wire payments, and historical rescreening of the existing customer base. Validation effort grows with the number of match scenarios you need to document for examiners. Because most DeployOpen engagements are fixed-scope, the phases, deliverables and timeline are agreed in writing before work starts. Ask the proposal to tie each milestone to a named integration or test set, so you can see what extends the schedule if a dependency slips.

What does our team need to supply before a screening build starts?

The build depends on decisions that only the institution can make, so the first requirement is a written sanctions screening policy and named owners for it. You will need to supply the list sources your program has chosen to screen against, the fields available in customer and payment records, the decision rules for when a match is blocked, escalated or cleared, and access to test data and staging environments. Name one person who approves threshold settings and one who signs off on alert dispositions. Without these, a partner can install the software but cannot tune it to your risk appetite. Confirm early whether the screening design must align with other controls, such as the transaction monitoring stack, so that case records and audit trails flow in one direction.

Can an in-house team build and run OFAC screening without a partner?

A capable engineering team can deploy yente and manage its infrastructure, but the harder work is the compliance evidence around it. The team must understand list licensing, fuzzy matching behavior, false positive handling and the blocking and reporting steps that follow a true match, and it must be able to explain them to an examiner. Ask whether your staff has done validation testing of a matching engine before, whether someone will own data refreshes on a fixed schedule, and who covers on-call duties when a list update fails. If those gaps are real, a partner can split the work: DeployOpen plans, implements, integrates, documents and supports self-hosted platforms in your own infrastructure, while your team keeps policy and final decisions.

What does a fixed-scope engagement cover, and what does a retainer add?

A fixed-scope engagement covers the agreed deliverables, such as the deployment in your environment, configured integrations, test evidence and documentation, each defined in writing before work begins. Changes to scope are handled through a written change to that agreement rather than assumed. A retainer covers ongoing work after go-live, which can include upgrades, list refresh support, patching, backup and restore checks, and periodic testing. Ask what the retainer includes for list updates, how quickly support responds to incidents, and how changes to the matching configuration are reviewed and recorded. DeployOpen does not publish a price list, so request a quote from a written scope and compare the two parts separately.

Does self-hosted screening help with compliance audits by itself?

No. A self-hosted deployment prepares systems, controls and evidence, but it does not satisfy an examiner or auditor on its own. Independent auditors and certification bodies issue opinions, and DeployOpen prepares the systems and records for those assessments without issuing audit reports or attestations. For OFAC screening, the evidence that matters includes documented list sources, the matching thresholds and the reasons they were chosen, the record of alert dispositions and the audit trail showing who changed a setting and when. Ask the partner to show how each of these is captured, and confirm with your own counsel or examiners which records your program must keep and for how long.

Who is responsible for list data licensing and refreshes?

Your institution is responsible for confirming that its use of each list is permitted, and this is a decision to make before the build starts. Screening data licenses are commercial terms that vary by source and by use, including whether data may be used internally by a commercial organization. Confirm the license for each list directly with the provider, record who approved it, and decide who will run refreshes on a set schedule. Ask any partner to describe how an update is tested before it reaches production and how a failed refresh is detected and escalated.

How DeployOpen scopes, builds and supports screening

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For OFAC screening with yente, that means agreeing the list sources, matching settings and evidence requirements in writing before any build begins, then delivering a screening service the compliance team can run and explain to examiners.

How we scope

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
The written scope names the list sources, update cadence, screened data fields and systems that call the screening service.
Scope also records who approves matching thresholds and how false positive handling and blocking decisions are routed.

How we build

Deployment of yente and its OpenSanctions data pipeline inside the client's own network, with hardening and access controls.
Integration with customer onboarding and payment flows, including logging of every screening request and result.
Testing of match thresholds against representative sample data agreed with the compliance team before go-live.

How we hand over

Documentation of architecture, configuration keys, update procedures and the audit trail design for examiner review.
Runbooks for list refreshes, threshold changes, alert review and recovery after a failed data update.
Knowledge transfer sessions so the client's staff can operate the screening service after handover.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
Retainers can cover yente version upgrades, list pipeline monitoring and periodic review of configuration changes.
Confirm with DeployOpen the support hours, response expectations and escalation path before signing any retainer.

Self-hosted sanctions screening for OFAC compliance