Beneficial ownership screening with open source tools: what CDD asks of your stack
A compliance lead at a bank or payments firm whose business customers are companies needs to know who stands behind each one. In practice, beneficial ownership screening means screening the legal entity itself and each identified natural person behind it against sanctions, PEP and registry data, then keeping evidence of how that check was run. The entity is not a name you can match on its own. Its owners, controlling persons and, where relevant, senior managers each need their own screening record, and the link between them must be visible to an examiner. This function sits inside the customer due diligence and ongoing monitoring duties covered in the AML and CDD obligations described on the hub page, and the sibling topics on sanctions screening with yente and on the BSA and EU AML rules explain the screening and reporting duties in more detail. This page does not restate those rules. DeployOpen builds and documents the systems, controls and evidence that support a CDD file, but it does not issue audit opinions or attestations. An independent auditor or examiner decides whether your program meets the standard.
The stack has four parts you should decide on before writing code. First, the data: yente matches against OpenSanctions datasets, and you need to confirm which sanctions, PEP and company registry sources you are licensed to load for your use, since registry data is often governed by separate terms from watchlist data. Second, the matching: decide how the entity name, registration number and jurisdiction are sent to yente, and how each owner is submitted as a person with date of birth, nationality and known aliases where you hold them, so that a company hit and an owner hit are both traceable. Third, the refresh: set how often entity and owner records are rescreened, and which events, such as a change in the ownership register or a new director, trigger an immediate rerun instead of waiting for the cycle. Fourth, the record: store the query, the dataset version, the match score, the reviewer's decision and the reason for it against the customer file. Confirm with your compliance team which of these items they consider part of the verification record and how long each must be kept.
Before procurement, ask any implementation partner to show a worked example of an ownership chain from a corporate customer through to the screening output, including what happens when an owner is itself a company. Ask how the data refresh is scheduled and logged, how a failed or stale dataset is detected, and who approves a changed threshold or rule. Ask how the audit trail links the entity decision to each owner decision. Also confirm with your own legal team how the owner identification data you collect is handled under your data protection obligations, because owner names and dates of birth are personal data. Clear answers to these questions will tell you more about readiness than a list of supported data sources.
Which CDD and screening requirements map to which configuration
This table maps the beneficial ownership, screening and record concepts in US and EU customer due diligence to specific work in the yente workflow. Read each row as a requirement, the function it demands, how to configure yente and surrounding processes, and the evidence an examiner or auditor will ask to see. Confirm exact rule citations, thresholds and retention periods with your compliance counsel before configuring.
| Requirement concept | What the function must do | Configuration in yente and workflow | Evidence to retain |
|---|---|---|---|
| Identify beneficial owners | Collect identity details for each individual owner above the applicable ownership threshold and for the control person. | Structured onboarding fields create one person record per owner, so each owner is screened separately. | Signed customer certification, owner list, copies of supporting identity documents. |
| Screen the entity and its owners | Screen the legal entity and each identified individual against sanctions and PEP data at onboarding. | Send entity and person queries to yente against sanctions and PEP datasets; route all hits to a review queue. | Query inputs, dataset version, match scores and reviewer decision for each hit. |
| Matching thresholds | Set a documented score cutoff and make sure no potential match is cleared without review. | Tune the cutoff on labeled test names with known outcomes; put threshold changes under change control. | Threshold rationale, test results, approval record and version history. |
| Registry verification | Confirm the entity exists and that declared owners and officers match an authoritative registry where one is available. | Pull registry extracts through an approved connector, compare them with declared owners and flag mismatches for review. | Dated registry extract, mismatch log and resolution note for each case. |
| Refresh triggers | Re-verify owners when ownership or control changes, when new list data is published and on a risk-based schedule. | Schedule batch rescreening of the customer book and trigger event-based checks on KYC record changes. | Refresh calendar, dataset release dates applied, rescreen results and exceptions. |
| Data sources and licensing | Use only list sources your license allows for your internal commercial use and record their terms. | Load OpenSanctions bulk data inside your network and log the dataset manifest for every run. | License terms on file, dataset manifest per run, data source owner sign-off. |
| Retained verification records | Keep a record of what was checked, when, by whom and with what outcome for the retention period your counsel confirms. | Store each decision with an input snapshot and dataset version in an append-only store. | Retention schedule, sample record retrieval test, access log. |
| Personal data handling | Limit owner data to what screening and CDD require and protect it for the full life of the record. | Send only needed fields to yente, restrict access by role, and encrypt data in transit and at rest. | Data flow diagram, access review results, lawful basis documentation for EU individuals. |
How matching companies and people differs in practice
Beneficial ownership screening runs two different matching problems in one workflow: legal entities and individual owners. Each decision below changes what yente returns, what analysts review and what the file must later show, so each needs an explicit, documented choice made against the institution's own data.
Entity name versus person matching
Company names carry legal suffixes, trading names, abbreviations and group affiliations, while person names carry order variations, patronymics and shared common names. Treat these as separate matching profiles rather than one configuration. Check how often a legal entity hit is driven by a generic word such as "holding" or "trading", and whether person hits rely on date of birth or nationality when those fields are present in the onboarding data.
Transliteration and alias handling
Owners and companies often appear under several spellings across registries, sanctions lists and identity documents, including different character sets. Decide which transliteration rules apply to inbound data before the query reaches yente, and whether known aliases from source lists are allowed to raise a candidate. Test a sample of multilingual names from your own customer base, because the error pattern for one language rarely matches another.
Registry identifier matching
A company registration number, tax identifier or jurisdiction code is usually a stronger signal than a name. Decide when an exact identifier match should override a weak name score, and when a mismatch in identifier format should send the case to manual review instead of closing it. Confirm with your data providers which identifiers each registry supplies and how often those identifiers are missing or formatted differently.
Owners below the ownership threshold
Your CDD procedure sets the ownership percentage that triggers identification of beneficial owners, and the screening scope must follow that rule. Define whether minority owners, controllers without ownership, and nominee or senior managing official roles are also screened. Record how the threshold was applied to each entity, so an examiner can see why a given owner was or was not checked.
Setting and documenting the score cutoff
yente returns scored candidates rather than a yes or no answer, so the match score cutoff is a business decision your institution must set and defend. Values are not universal: test candidate thresholds against a labeled set of your own historical customers and owners, measure missed true matches and analyst workload at each level, and keep the results. Record the chosen value, the version of the data it was tested against and the approver.
Analyst review of scored candidates
Every candidate above the cutoff, and any borderline candidate you choose to keep, needs a recorded disposition: confirmed, discounted with a reason, or escalated. Define who can clear a candidate, what evidence is required, and how the decision links back to the entity and owner record. Without this trail, a tuned threshold cannot be shown to have been applied consistently.
Self-hosted yente or a hosted screening API for owner checks
Here yente runs inside your own cloud account or data center and loads OpenSanctions bulk data from a local copy. Owner names, dates of birth and registration numbers stay within the network during each check, so residency is governed by your own controls. The trade-off is that your team owns every refresh, storage location and access decision.
- Data residency: Customer and owner records stay in the environment you control, so the questions become where the dataset copy, match logs and review notes are stored and who can read them.
- GDPR: You act as controller for screened personal data. Document the lawful basis, data minimization, log retention and any transfers from group entities, and review the processing record with your data protection officer. See the GDPR text on EUR-Lex for the principles to test against.
- Update pipeline ownership: Your platform team schedules pulls of new dataset versions, validates them and rolls them out, and keeps a record of which version screened each customer.
- Licence for internal use: Internal commercial use of bulk data is governed by OpenSanctions terms, which may differ from the terms for a hosted service. Confirm which licence applies to your use case.
- Operating cost: Infrastructure, patching and on-call support for the service are yours, and they recur for as long as the screening runs.
Confirm the licence terms in writing with OpenSanctions before you copy any data into the environment.
A hybrid model keeps yente and the sanctions and PEP data in-network but sends some queries outward, typically to a company registry API to confirm an owner's registration or fetch current officer details. Each outbound call is a data transfer that needs its own justification, and the design is only as clean as its weakest connector.
- Residency split: Map each field to the place where it is processed. A registry query may send company numbers or owner names to a registry in another jurisdiction, which changes your residency position for those fields.
- GDPR transfer analysis: Where registry data originates outside your region or calls route through a provider located abroad, document the transfer mechanism and limit the fields sent to what the check needs.
- Pipeline ownership: Split responsibility. The platform team owns the local dataset, while the compliance or data team owns registry connectors, credentials and the contracts behind them.
- Licence and terms: Registry providers and OpenSanctions each set their own terms, so combined output may carry obligations from both. Ask each provider whether caching results inside your systems is permitted.
- Failure handling: Define what happens when a registry is unavailable, such as queuing the check or routing the entity to manual review, and record that outcome in the case file.
Ask for a data flow diagram that shows every outbound field before approving any hybrid design.
A hosted API moves the matching service and often the underlying data to a vendor's infrastructure. You send names and identifiers over the network and receive matches back. Initial effort is lower, but residency, subprocessor and exit terms become contract questions that your legal and procurement teams must answer.
- Residency and location: Confirm in the contract where requests, cached results and logs are processed and stored, and whether that extends to the vendor's subprocessors.
- GDPR roles: The vendor is usually a processor for the screening service, so you need a data processing agreement, documented instructions from you, and a review of any onward transfers.
- Update ownership: The vendor typically refreshes list data, but confirm the refresh frequency, how you receive notice of changes and how you evidence which list version screened a given customer.
- Licence for internal use: Confirm whether the subscription covers internal commercial use of the underlying data and whether results may be stored in your case files. Some terms restrict redistribution even while the service is in use.
- Exit and data return: Define how screening history, match decisions and logs are exported if you leave. Where DORA applies, Article 28(8) expects documented, tested exit strategies for ICT services that support critical or important functions.
Ask for the data processing terms, subprocessor list and list-refresh record in writing before you send any owner data.
Refreshing checks and recording verification for examiners
A beneficial ownership check is only as current as its last run, so the first decision is which events force a new screening. Set three refresh triggers and document each one: a scheduled re-screen of the full customer book at an interval your compliance policy defines, a list update event whenever a new yente index built from OpenSanctions data is loaded, and an ownership change event whenever the customer's KYC record shows a new director, a transfer of shares or a change in the controlling party. The scheduled re-screen catches people who become sanctioned or politically exposed after onboarding. The list update trigger covers the gap between data releases. The ownership change trigger is the one most often missed, because it depends on your onboarding workflow emitting an event when the owner data is edited. Confirm with your engineering team which system writes that event and what happens when it fails.
Every screening run should produce a record that an examiner can replay without asking you for context. Log the list version or index identifier that yente served, the exact query inputs sent (entity name, registration number, country, and each owner's name and date of birth where held), the match scores and the threshold applied, the reviewer who dispositioned each hit, the decision (clear, escalate, or block), and a written rationale in the reviewer's words. Store these as structured records, keyed to the customer and the run, so a single customer history can be pulled in one query. Retention periods for CDD records differ by jurisdiction and by the type of record, so have counsel confirm the period for each regime you operate under before you configure any purge job. Do not assume a period from this page or from another vendor's default.
How long and how much work does beneficial ownership screening take?
What drives the implementation effort for beneficial ownership screening?
The main drivers are the number of entity types you onboard, the number and quality of registry sources you connect, and how deeply the screening must integrate with onboarding and case tools. A single jurisdiction with one registry feed and a basic onboarding form is a much smaller job than a multi-country book with corporate, trust and foundation customers. Each additional entity type adds ownership rules, test cases and review paths. Each registry source adds a licensing check, a connector, field mapping and a refresh schedule. Integration work with the onboarding platform, the case management tool and the record store usually takes the largest share of the time. Ask any partner to break its estimate into these three areas before you compare numbers.
What does a quote for this work include?
A quote covers the work listed in the written scope, not a standard package. Ask for the deliverables, the entity types and jurisdictions in scope, the registry and list sources to connect, the integration points, the testing and documentation expected for examiners, and the handover and training plan. Separate one-time costs, such as design, build, integration and validation, from recurring costs, such as data licenses, infrastructure, updates and support. DeployOpen does not publish a price list. Quotes follow from the written scope, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Can our internal team run beneficial ownership screening after handover?
Yes, if the team has the skills and time to operate it, and the handover is planned for that purpose. The operating work includes monitoring refresh jobs, reviewing match alerts, maintaining ownership rules, handling software upgrades and keeping evidence current. A compliance analyst needs to understand matching thresholds and review decisions, and an engineer needs to run the service, its updates and its logs. Ask the implementation partner what documentation, runbooks and training are included, and whether ongoing support or a retainer is available for upgrades and testing. Confirm the staffing you need on both sides before you agree the handover date.
How much time does the compliance team need to give the project?
Compliance needs to define the rules the system applies, and that takes time at the start and at each review point. Expect involvement in the entity types, the ownership threshold and look-through logic, the sources to use, how matches are triaged, and what counts as verification evidence. Compliance also signs off on test results and the documentation examiners will read. The total amount of time depends on the scope and on how quickly internal decisions are made, so ask the partner to list the decision points and their owners in the project plan. Agree those dates in writing so the review cycle does not stall the build.
What does IT need to provide for beneficial ownership screening?
IT provides the hosting environment, network access, identity and access controls, and the integration endpoints. Typical needs include a place to run the screening service inside your own cloud account, data center or private network, secure connections to the onboarding and case tools, secrets management, logging and backup. IT also owns change control and the patching cycle after go-live. Ask the partner to name the environments, access requirements and integration contacts in the scope. If your team has standard hosting or security baselines, confirm early that the design fits them, because late changes to infrastructure tend to add the most rework.
How is a fixed-scope engagement agreed in writing?
A fixed-scope engagement starts with a written scope that defines the deliverables, the systems and entity types covered, the acceptance tests, the responsibilities of each party, and the timeline. Both sides review the document before work begins, and changes are recorded as written change requests that can affect cost and timing. Ask for the acceptance criteria in plain terms, such as which screening results must be reproducible and which records must be retained. Clarify what happens if a data source changes or a dependency is delayed. Treat the signed scope as the reference point for every later decision about cost and time.
Does the list or registry data cost extra, and who pays for it?
Registry and watchlist data can carry license terms that are separate from the software cost, and those terms decide whether you can use the data for internal commercial screening. Confirm the license with the data provider before design work starts, including the permitted use, the refresh rights and any fees per year or per volume. Software licensing for the open-source components is a separate question. Ask the partner to show which costs it passes through to you, which it includes in its fee, and which you pay directly to a provider. Verify these terms with the provider, since they can change.
Which open source components fit the screening layer
A beneficial ownership check runs through three components: a matching engine, a review tool where analysts record decisions, and a store that keeps verification evidence. Each one has to be chosen, integrated and tested against the others before the CDD process can rely on it.
Yente for entity and person matching
Yente is the open source matching service that screens names against OpenSanctions data, and it is the component that compares legal entities and their owners and controllers against sanctions and PEP lists. Confirm which OpenSanctions datasets your license covers, how the service is updated, and how it handles company names with legal suffixes, transliterations and shared owner names. Test match thresholds on a sample of your own customer records before go-live, since thresholds decide how many alerts reach analysts.
Case management for analyst decisions
Every potential match needs a documented disposition: discounted, escalated or confirmed. A case tool holds the alert, the matched record, the evidence reviewed and the approver's sign-off. Open source options for this layer vary widely in scope and in how they handle audit trails, so confirm each candidate's fit for case workflow, role-based approval and export before selecting it. DeployOpen integrates the selected tool with the matching service and the records store.
Company registry data connectors
Owner identification depends on registry data: the entity's legal name, registration number, jurisdiction and listed directors or shareholders. Registry access terms differ by country, and some registries restrict bulk reuse or commercial use. Confirm for each jurisdiction in scope whether data arrives by API, file download or manual lookup, how often it changes, and whether you may store it. The connector should record the source and retrieval date with every fetched record.
Verification record store
The database or document store holds what the institution relied on at each check: the list version, the registry extract, the match decision and the reviewer's identity. Design it for retrieval by customer and by date, since examiners will ask what was known when a decision was made. Confirm your retention period against the record-keeping rules that apply to your entity type, and confirm that backups preserve the same audit trail.
Refresh scheduling and change tracking
Beneficial ownership is not static. A new director, a changed shareholding or an updated sanctions list can alter a customer's status after onboarding. Define which events trigger a re-screen, how often scheduled re-checks run for each risk tier, and how the system marks which customers were checked against which data version. The scheduler and its logs are part of the evidence set, so they belong in the design review.
Access control and encryption
The screening layer holds personal data about owners, directors and sanctioned persons, so access must be restricted by role and logged. Use multi-factor authentication for every user with access to customer information, encrypt stored records and data in transit, and log activity by authorized users. These controls align with the safeguards expected for financial institutions under the FTC Safeguards Rule in the US and with GDPR data protection duties in the EU.
What examiners ask to see for each verification
This table lists the evidence items an examiner is likely to request for a beneficial ownership check and the component that produces each one. Read it as a starting point for a conversation with your examiner or auditor, since expectations on format and retention vary by institution and supervisor. The main takeaway is that each record must be traceable to a specific list version, configuration and analyst decision.
| Evidence item | Produced by | What to confirm with the examiner |
|---|---|---|
| Screening logs for each owner and entity | yente query log and the calling onboarding service | Which identifiers, timestamps and request IDs must link each log entry to a customer file |
| List version records | yente with the OpenSanctions dataset version loaded at query time | Whether they expect the dataset version, load date and source list names recorded per check |
| Owner identification records | Customer onboarding case file in the case management system | Which owner identity fields and ownership percentages must be captured and how they are verified |
| Match review and analyst decisions | Case management system with analyst notes and four-eyes approval | How discounted matches are documented and whether a second reviewer is required |
| Refresh run history | Scheduler logs for bulk data updates and re-screening jobs | How often re-screening must run for existing legal entity customers and how misses are reported |
| Configuration change records | Version control for matching thresholds, rules and deployment settings | Whether threshold changes need documented approval and back-testing before go-live |
| Retention settings and archive proof | Storage policy in the data platform and backup tooling | The retention period for CDD records and whether archived copies must stay readable and searchable |
What screening tooling alone does not satisfy
A screening engine only matches the data it is given and returns the hits it is configured to return. The cards below cover the duties that sit around yente: collecting ownership facts from customers, judging registry data quality, governing false positives, meeting data licence terms, controlling threshold changes, and testing the whole process independently.
Ownership data must still be collected
yente can only screen the names and identifiers you submit. Beneficial owner details, control positions and ownership percentages come from the customer, usually through an onboarding form and supporting documents. Check that your onboarding flow asks for every individual who owns or controls the entity, records how each person was identified, and blocks account opening when ownership fields are blank. A missing owner is a silent gap, because the screen runs without error on the entities you did send.
Registry data quality sits outside the tool
Company registry records can be outdated, incomplete or inconsistent across countries. A match against a stale officer list gives a false sense of coverage. Decide which registries you rely on for each jurisdiction, how often they are pulled, and what happens when a registry is unavailable or returns no record. Ask your partner to document these source-level limits so reviewers know what the check can and cannot show.
False positive policy needs governance
Fuzzy matching will raise alerts that a human must clear. Who may close an alert, what evidence is required, and when a case goes to a second reviewer are business decisions, not configuration defaults. Write a disposition policy with named roles, record the rationale for each closed alert, and review closure patterns on a schedule. Without this, analysts clear similar hits inconsistently and examiners cannot follow the decisions.
Licence compliance is an organizational duty
Sanctions and PEP data sources carry their own licence terms, and those terms differ for internal commercial use versus redistribution. The open-source software licence does not settle this. Assign an owner for the data licences, confirm in writing which data products your use requires, and keep records of the terms in force. Repeat the check when you add a new list or change how results are shared with customers or third parties.
Threshold changes need sign-off
Matching thresholds, list selection and entity types change how many hits you see and what you miss. Treat each change as a controlled event: document the proposed value, the test results that justify it, the approver, and the effective date. Keep the previous configuration so you can show what was in force on any past date. Uncontrolled tuning is one of the first points examiners probe in a screening programme.
Independent testing of the process
Your own team and your tool vendor cannot be the only check on whether beneficial ownership screening works. Plan periodic independent testing that samples onboarded entities, traces ownership back to source documents, and re-runs screening on a set of known test cases. Results should feed findings and remediation tracking. Ask any implementation partner which parts of this testing they perform and which parts your internal audit must own.
How DeployOpen fits the beneficial ownership build
DeployOpen plans, implements, integrates, hardens, documents and supports the self-hosted open-source components of a beneficial ownership build inside your own cloud accounts, data centers or air-gapped network. For this use case that means the yente screening service, the OpenSanctions data pipeline that feeds it, the connectors that pull legal entity and owner records into screening, and the logging and storage that hold each verification record. Your team keeps custody of the entity data, the list files and the keys, and decides who may approve a cleared or escalated owner. DeployOpen's work covers the deployment, the configuration of matching thresholds and dataset selection that you approve, the integration with your onboarding workflow and case tooling, and the runbooks your operators will use when a refresh fails or a list changes.
Every engagement is fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. The written scope should name each owner-tracing depth you intend to cover, each registry or document source, the refresh schedule, and the evidence you need to hand to an auditor or examiner. Ask for those items to be listed as deliverables. DeployOpen can prepare systems, controls and evidence for a compliance assessment, such as access logs, change records and documented test results for the screening configuration. It does not issue audit reports, attestations or certifications, and independent auditors or certification bodies make those determinations. Confirm with your compliance lead which assessor will review the evidence and what format they expect before the scope is signed.
How DeployOpen scopes, delivers and supports beneficial ownership screening
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including the yente screening service for beneficial ownership checks. Work starts from a written scope that defines which entity and owner data is screened, which lists are used, and what evidence your CDD file must hold.
How we scope
- Written scope covering legal entity onboarding, owner and controller data flows, and the registry and list sources in use
- Agreed definitions of which ownership thresholds, roles and related parties trigger a screen and a review
- Confirmation of data licensing for each list and registry, including whether internal commercial use is covered
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins
How we build
- Deploy yente and its data pipeline inside your cloud account, data center or air-gapped network
- Configure matching for company names and individual owners, with thresholds tested against sample records you supply
- Wire screening results into onboarding and case records, with logs covering each check, input and reviewer decision
- Test matching behavior, refresh jobs and access controls before the system goes live
How we hand over
- Operating documentation for data refresh schedules, match review steps and escalation paths
- Records describing how each verification is stored, dated and linked to the customer file for examiner review
- Knowledge transfer sessions for compliance and platform staff, with an agreed runbook for routine tasks
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Routine updates to list pipelines, configuration changes and documentation as your ownership rules change
- Clear ownership of recurring tasks, so refresh failures and new data licenses are handled before they affect onboarding
