Sanctions screening in a bank compares supplied identifying information about customers, companies, owners, counterparties and payment parties with the sanctions data selected for the bank's control. It produces possible matches for investigation. It does not authenticate identity, complete KYC or customer due diligence, perform behavioural transaction monitoring, resolve sanctions ownership and control, or make the final legal decision.
Banks and digital banks need to connect these distinct controls without collapsing them. The useful operating sequence is identity and KYC/CDD information → screening → candidate investigation → ownership/control or programme analysis where relevant → authorised bank decision → retained evidence and ongoing reassessment.
This guide is an operational framework, not legal advice or a universal checklist. Applicable restrictions, reporting duties, licences and permitted actions depend on the jurisdiction, sanctions regime, bank entity, product and facts. For the underlying legal-perimeter and matching framework, use the practical sanctions-screening guide.
What banks may need to screen
The appropriate population depends on the bank's applicable law, risk assessment, products and data. It may include:
- retail and business customers;
- companies and supplied beneficial owners, controllers, directors or signatories;
- respondent and correspondent institutions;
- counterparties introduced during the relationship;
- payers, payees, originators, beneficiaries and relevant intermediaries; and
- existing records affected by a customer-data, ownership or sanctions-data change.
Checklynx can compare records supplied by the bank or an upstream system against configured supported sanctions, PEP, wanted-list and adverse-media sources. The bank remains responsible for establishing the population, verifying upstream facts where required, selecting applicable sources and deciding what the results mean.
Banking screening responsibility matrix
This matrix is a Checklynx-recommended implementation aid. It does not state that every bank must screen every party at every event.
| Banking event | Party or data supplied for screening | Candidate output | Downstream bank owner | Decision screening cannot make |
|---|---|---|---|---|
| Retail customer onboarding | Customer name and available identifiers | No candidate or possible match with source context | Onboarding, compliance or MLRO workflow | Authenticate identity, complete CDD, approve or reject the account |
| Business customer onboarding | Company and supplied directors, owners, controllers or related parties | Candidates separated by screened subject | KYC/KYB and compliance | Discover or verify every owner, resolve ownership/control, approve the relationship |
| Owner or controller change | Updated ownership/control records supplied by the bank | New or changed candidates | KYC refresh, sanctions specialist or legal | Decide whether an unlisted entity is restricted under the applicable ownership/control test |
| New counterparty | Counterparty and relevant supplied related-party identifiers | Counterparty candidates | Business owner and compliance | Determine overall counterparty acceptability |
| Payment initiation or receipt | Relevant payer, payee, originator, beneficiary or intermediary fields | Candidate tied to the payment event | Payments operations and sanctions/compliance | Authorise execution or make the final block, reject, release or reporting decision |
| Correspondent-bank onboarding | Respondent institution and supplied relevant owners/controllers | Entity and related-party candidates | Correspondent-banking due-diligence team | Complete respondent-bank CDD or assess its full AML programme |
| Sanctions-data change | Configured monitored population | New candidates caused by the source change | Screening operations and compliance | Confirm identity or automatically determine the legal response |
| Customer master-data change | Changed name, identifier, company or related-party data | Updated match set | KYC operations and compliance | Establish the changed facts merely because screening is clear |
| Periodic portfolio review | Defined records supplied through batch, API or monitoring | Population-level candidates and run evidence | Compliance operations | Replace the broader periodic KYC/CDD review |
| Alert escalation | Candidate, source record and bank context | Reviewed candidate and recorded workflow outcome | Analyst, sanctions officer, MLRO or legal | Determine applicable law, licence, reporting or final disposition by itself |
Connected controls, separate meanings
Identity verification and KYC/CDD
Identity verification supports the question “is this person or business who it claims to be?” KYC/CDD is broader: it may establish and maintain information about the customer, purpose, ownership and risk. Screening uses relevant supplied identifiers from those processes but does not perform them.
The KYC and KYB onboarding workflow shows how screening can sit inside a broader onboarding system without being described as identity or ownership verification.
Customer and payment-party screening
Customer screening concerns the relationship population. Payment-party screening concerns parties and identifiers introduced by a payment event. A clear onboarding result cannot answer every later beneficiary, counterparty, intermediary or route question. The transaction-screening solution covers the payment-party workflow.
Payment-party screening and behavioural monitoring
Name or identifier screening compares supplied parties with configured risk sources. Behavioural transaction monitoring looks for patterns or activity. They may exchange signals, but one does not replace the other. Checklynx does not claim to provide behavioural transaction monitoring.
Matching and ownership/control analysis
A clean company-name search does not establish that every relevant owner or controller was identified, nor whether an unlisted entity is restricted through applicable ownership/control rules. The bank needs established corporate facts and jurisdiction-specific analysis. See the UBO and related-party screening guide for the screening handoff.
Where banking controls differ by jurisdiction
There is no single global bank-screening rule. Use each authority for the job and jurisdiction it actually governs.
| Jurisdiction | Authoritative context | Safe operational conclusion |
|---|---|---|
| International / FATF | FATF Recommendation 6 addresses targeted financial sanctions connected with relevant UN Security Council resolutions.1 | Treat FATF as an international standard for national implementation, not a self-executing global software specification. |
| United Kingdom | The FCA discusses customer, counterparty and payment screening, list/data quality, calibration, ownership/control and alert management as distinct areas.2 | Robust CDD can support sanctions controls, but name screening alone does not resolve every sanctions risk. Use the UK Sanctions List as the government designation source.3 |
| European Union | The EBA has issued guidelines on policies, procedures and controls for Union and national restrictive measures.4 | Distinguish binding EU legal acts from EBA supervisory guidance and from a bank's implementation choices. |
| EU instant payments | Article 5d of Regulation (EU) No 260/2012, introduced by Regulation (EU) 2024/886, sets a specific verification model for in-scope PSPs offering instant credit transfers.5 | Do not rewrite this as “screen every EU instant payment in the same way.” Confirm scope and other applicable restrictive-measures obligations. |
| Germany | Bundesbank explains that financial sanctions in Germany are predominantly based on EU law and identifies official sources and its Service Centre Financial Sanctions.6 | Use Finanzsanktionen for the legal context and validate the applicable EU measure; operational screening is only one control. |
| Spain | Spanish Treasury uses the concept sanciones financieras internacionales; Spanish AML law separately addresses correspondent-banking due diligence.78 | Screening a respondent bank or supplied owner is one input, not complete correspondent-banking CDD. |
| UAE | CBUAE guidance treats name screening, targeted financial sanctions, transaction monitoring and correspondent banking as connected but distinct controls.9 | Attribute any requirement to the applicable UAE framework and licensed institution; do not generalise it globally. |
| South Africa, Kenya and Nigeria | National laws, authorities and supervisory materials govern the relevant bank duties. | Verify the current primary rule and supervised population before publishing a local cadence, party-scope or disposition claim. Do not infer one country's rule from another. |
Customer screening versus payment-party screening
A bank may screen a customer at onboarding and still encounter a new sanctions question when a beneficiary, counterparty, intermediary, owner, account or route changes. The bank should identify which records are available before an irreversible step, who can pause or release the flow, and where incomplete identifiers must be escalated.
For in-scope EU instant credit transfers, Article 5d uses a specific payment-service-user verification model after relevant targeted financial restrictive measures enter into force or are amended, and at least once per calendar day. It also addresses additional verification during execution under that mechanism.5 This provision should not be converted into a universal cadence for every banking product or jurisdiction.
For deeper event and payment-chain design, see sanctions screening for payment institutions.
Ongoing screening when lists or customer data change
Ongoing re-screening asks whether a maintained supplied record produces a new candidate after configured source or customer information changes. Useful triggers can include:
- an official sanctions-data update;
- a customer, legal-name or identifier change;
- a new or changed beneficial owner/controller supplied by the upstream process;
- introduction of a new counterparty or payment role; and
- a policy-defined portfolio review.
Avoid presenting one cadence as universally required. The bank should map applicable rules, data-change events, queue capacity and escalation times. The ongoing monitoring solution supports configured re-screening; it is not behavioural transaction monitoring or complete ongoing CDD.
How bank teams investigate a candidate
- Identify the event and party. Record which customer, company, owner, counterparty or payment party generated the candidate and the state of the relationship or payment.
- Resolve identity. Compare available identifiers and source context. Record why the subject is or is not the listed party.
- Assess ownership/control where relevant. Use established corporate facts and the applicable regime; do not treat matching software as the legal analysis.
- Determine the applicable measure. Identify the legal act or programme, nexus, restriction, exception, licence and reporting implications.
- Make and evidence the authorised decision. The bank—not the screening result—decides whether to proceed, escalate, pause, release, block, reject, seek a licence or report.
The sanctions-alert investigation guide covers reviewer evidence. Case management can route work and preserve ownership, while audit trail and evidence supports reconstruction of screening and review history.
Correspondent banking: screening is one input
Screening a respondent institution and supplied owners, controllers or directors can identify candidates. It cannot assess the respondent's complete AML/CFT programme, quality of supervision, customer base, payable-through-account risks, management approval or allocation of responsibilities.
Banks should therefore keep the screening output inside the broader correspondent-banking due-diligence process required by the applicable framework. A clean name result is not approval of the correspondent relationship.
How Checklynx fits into bank controls
Checklynx can screen records supplied by a bank or upstream system through portal, API and CSV/batch workflows. It can support configured ongoing re-screening, candidate review, case assignment and retention of screening/review history.
Checklynx does not authenticate identity documents or biometrics, complete KYC/CDD, discover or verify every beneficial owner, perform behavioural transaction monitoring, authorise payments, determine applicable sanctions law, resolve ownership/control by itself, make final blocking/rejection/licensing/reporting decisions, replace legal or compliance judgement, or guarantee compliance.
Banks evaluating the screening layer can review Checklynx sanctions screening software. Technical teams can use the real-time screening API; defined portfolios can use CSV batch screening.
Frequently asked questions
Is sanctions screening part of a bank's KYC process?
It is commonly connected to onboarding and KYC/CDD because it uses supplied customer and ownership information. It remains a distinct control: KYC/CDD establishes and maintains customer facts and risk context; screening compares relevant identifiers with configured sources and returns candidates.
Is customer screening enough for a digital bank?
Not necessarily. Digital-bank products may introduce companies, supplied owners/controllers, beneficiaries, counterparties and payment-chain parties after onboarding. The bank should map those events and applicable requirements instead of relying on one customer-name result.
Are sanctions and PEP screening the same?
No. They may use related matching infrastructure, but sanctions designation and PEP status have different meanings and downstream treatment. A PEP candidate is not a sanctions hit or an automatic rejection. See the PEP screening guide.
Does a sanctions candidate mean a bank must freeze the account or payment?
No. A candidate must be investigated. The legally appropriate response depends on identity, ownership/control, applicable law, programme, nexus, party role, facts and any exception or licence. The authorised bank process must make and document that decision.
Does a clear sanctions result clear the customer or payment?
No. It means no candidate was returned at the configured criteria for the supplied records and sources. It does not establish that every relevant party was identified, resolve ownership/control or other restrictions, complete CDD, or approve the relationship or payment.
Can Checklynx screen bank portfolios in bulk and through an API?
Yes. Checklynx supports screening of supplied records through portal, API and CSV/batch workflows, plus configured ongoing re-screening. The bank remains responsible for data quality, population and source selection, review and legal decisions.
Official sources
- FATF, Recommendation 6 update — international targeted-financial-sanctions standard.
- UN Security Council, United Nations Security Council Consolidated List — UN-listed individuals and entities.
- FCA, Sanctions systems and controls: our firms, our findings — UK supervisory findings covering due diligence, screening, ownership/control and alert management.
- UK Government, The UK Sanctions List — UK government designation source.
- European Banking Authority, Guidelines on internal policies, procedures and controls for Union and national restrictive measures — EU supervisory guidance.
- European Union, Regulation (EU) 2024/886 — EU instant-payments framework, including Article 5d amendments.
- Deutsche Bundesbank, Financial sanctions — German authority context and official-source links.
- Spanish Treasury, International financial sanctions — Spanish authority terminology and sanctions context.
- Spain, Ley 10/2010, Article 13 — cross-border correspondent-banking due diligence.
- Central Bank of the UAE, Targeted Financial Sanctions Obligations — current CBUAE rulebook context for licensed financial institutions.
Footnotes
-
See Source 1 above: FATF Recommendation 6 update. ↩
-
See Source 3 above: FCA sanctions systems and controls findings. ↩
-
See Source 4 above: UK Sanctions List. ↩
-
See Source 5 above: EBA restrictive-measures guidance. ↩
-
See Source 6 above: Regulation (EU) 2024/886, Article 5d. ↩ ↩2
-
See Source 7 above: Deutsche Bundesbank financial sanctions. ↩
-
See Source 8 above: Spanish Treasury international financial sanctions. ↩
-
See Source 9 above: Ley 10/2010, Article 13. ↩
-
See Source 10 above: CBUAE targeted financial sanctions guidance. ↩