Payment institutions do not manage sanctions risk only at the point a customer is approved. They move value between people and businesses, often quickly, and may handle a changing set of payers, payees, merchants, beneficiaries, payout recipients and financial institutions. A control framework that screens only the account holder can miss material exposure in the payment itself.
This guide explains how to design a payment-specific sanctions-screening workflow. It is written for compliance officers, MLROs, payment-operations leaders and product owners. It is not legal advice. The correct action in a live case depends on the sanctions regime, the firm’s nexus, the facts, any applicable licence or exception, and instructions from the relevant authority.
For the general framework—legal scope, relevant regimes, screening populations, alert investigation and control testing—start with the practical sanctions-screening guide.
Executive practical summary: design the control around the payment
Use this sequence to assess a payment-screening operating model:
- Parties: identify the payer, payee, beneficiary, merchant, payout recipient, relevant corporate owner/controller and payment-chain institution for each product.
- Trigger events: define when a new party, changed data, payment, payout, list update, ownership/control change or new corridor requires assessment.
- Alert decision: contain the case where possible, resolve identity, assess the applicable regime and ownership/control question, then follow the authorised disposition path.
- Evidence and ownership: preserve the source, data, rationale, decision and timestamps; name the person accountable for the queue, escalation, release and list-change response.
This page addresses that payment-specific operating model. For the broader legal framework, list and regime fundamentals, see the general sanctions guide.
Why payment institutions need a distinct sanctions workflow
The defining feature of a payment institution is that its risk is linked to value movement. A customer can be acceptable at onboarding and still create a new sanctions question when they add a beneficiary, initiate a payout to a merchant, change a corporate owner, enter a new corridor or use a different payment rail.
Payment speed makes this harder: a card-acquiring flow may introduce a merchant, settlement account and owners; a transfer may introduce a beneficiary and intermediary institutions; a marketplace payout may introduce a seller not onboarded as the consumer. Map the journey before selecting controls: who is known, which data is available, where the flow can be paused and which legal entity owns the decision.
Four layers of authority: do not call them all “requirements”
Sanctions content can become misleading when binding rules, supervisory material and implementation choices are blended together. Use this distinction to prevent an internal control choice from being presented as law.
| Layer | What it means for a payment institution |
|---|---|
| Binding legal requirement | A prohibition, regulation, decision or national implementing measure that applies to the institution, person, property or transaction in scope. For example, EU Regulation 2024/886 amended Regulation (EU) No 260/2012 with a specific instant-payments provision. |
| Supervisory expectation or guidance | Material from a supervisor or authority explaining how firms may demonstrate effective systems and controls. It is important, but it is not automatically a statutory rule for every firm or jurisdiction. |
| FATF standard | An international standard directed primarily at jurisdictions. It influences national frameworks but should not be described as a self-executing private-sector obligation. |
| Checklynx-recommended implementation practice | A practical control design derived from legal and supervisory sources. It should be tailored to the institution’s products, exposure and legal perimeter, and never presented as a universal legal command. |
The UN Security Council Consolidated List and FATF Recommendations 6 and 7 are important global reference points, but they do not establish every operator’s private-sector legal duties. EU and UK measures can extend to entities owned or controlled by designated persons in the applicable legal context. Under OFAC’s 50 Percent Rule, the automatic rule addressed here is direct or indirect aggregate blocked ownership of 50% or more; distinct programme restrictions require separate analysis.23
For an EU or EEA payment institution, applicable EU legal acts and relevant national measures are the starting point; EBA restrictive-measures guidelines are supervisory guidance. FCA guidance makes a useful distinction: screening is not the underlying legal obligation, but it helps firms avoid breaches. In the US, OFAC programmes require programme-specific analysis; its compliance framework is risk-based guidance, not a replacement for the applicable programme.
Start with legal perimeter and nexus
Before choosing lists, map where the institution operates, which legal entities, agents, currencies, counterparties and correspondent relationships are involved, and whether the transaction creates EU, UK, US or other nexus. Legal advice may be needed for complex cross-border models.
Maintain a regime-and-programme matrix, rather than an undifferentiated “global sanctions list.” It should distinguish:
- legally applicable regimes and restrictions;
- additional lists or data sources included because of documented risk decisions;
- the products, countries, legal entities and parties to which each control applies; and
- the owner who monitors official changes and translates them into operational action.
Risk assessment can help calibrate which additional lists, parties, fields and review frequencies are appropriate. It is not permission to disregard a designation or restriction that is legally applicable.
Map the parties, data and payment-chain exposure
The party-and-data matrix answers who is involved and what data may resolve an alert. It is a Checklynx-recommended implementation template, not a statement that every payment institution is legally required to collect or screen every field in every situation.
| Party or object | How the role arises in a payment flow | Data that may help resolve an alert | Payment-specific control question |
|---|---|---|---|
| Payer / originator | Instructs, funds or authorises a transfer, card payment or payout, sometimes through an authorised user. | Names, date of birth/incorporation, address, customer/account IDs, authorisation data and payment purpose. | Is the value-directing party the listed subject, or has an authorised user or account changed? |
| Payee | Receives the value as an account holder or business counterparty. | Legal/trading names, account ID, address, registration number, location and payment narrative. | Is this a direct concern, or do the identifiers resolve a similar name? |
| Beneficiary | Is entitled to receive a transfer and may first appear at recipient creation. | Name, account/IBAN, address, beneficiary institution, country and available transfer information. | Should a new recipient be held, reviewed or only released under a documented path? |
| Merchant / seller | Accepts a card payment or receives settlement as an acquirer customer or platform seller. | Legal/trading names, merchant ID, settlement account, location, directors and relevant ownership data. | Has a new name, account, owner or related entity changed the settlement exposure? |
| Corporate customer | Holds an account, initiates transfers or makes payments for a group. | Entity IDs, addresses, group structure, authorised users, linked accounts and counterparties. | Does the match concern the company, user, group entity or newly introduced counterparty? |
| UBO / controller | May be relevant to a corporate customer, merchant, payee or beneficiary. | Ownership/control rights, shareholder/director records, group chart and source dates. | Is the unlisted entity restricted under the applicable regime’s ownership/control test? |
| Acquiring or issuing counterparty | Acquirer, issuer, sponsor, processor or scheme participant in authorisation, clearing or settlement. | Legal name, institution ID, contractual role, rail, route, currency and country. | Is it a technical participant or a counterparty whose role changes the analysis? |
| Relevant intermediary | Correspondent, beneficiary institution, payout partner or agent between originator and beneficiary. | BIC/equivalent ID, route, message fields, location, corridor and instructions. | Does the chain introduce a party or route needing investigation? |
| Payout, return or refund recipient | Receives settlement, refund, return or chargeback-related value after the original event. | Recipient and account IDs, original-payment reference, relationship and event reason. | Has a later value movement introduced a different recipient or account? |
Not every product can or must collect every field; privacy, data minimisation, product design and legal scope still apply. A firm should know which gaps prevent resolution and have an escalation path for thin-data alerts. Regulation (EU) 2023/1113 is not itself a sanctions-screening rule, but information accompanying covered transfers can make originator and beneficiary investigations more reliable.
Design controls around moments that change exposure
The lifecycle table below answers when to assess and what decision the control must support. A scheduled customer rescreen can be useful, but it cannot stand in for events that introduce a new party or newly relevant restriction.
1. Onboarding and relationship changes
Checklynx-recommended implementation practice: Assess the relevant relationship before activation using the applicable regime matrix, and retain source records, date obtained and relationship-owning legal entity. A legal-name, beneficial-owner, settlement-account, product or geography change can be a rescreening trigger, not merely a CRM update.
2. Beneficiary, payee and merchant creation
A new beneficiary, payee, settlement account or payout recipient brings a new party into the value flow. Checklynx-recommended implementation practice: identify the available fields and decide whether an alert holds creation, first use or release; make that intervention decision explicit before building a real-time experience.
3. Payment initiation, execution and payout
At payment and payout, use the party/data map and the available country, destination, purpose, currency, institution, asset or service context. A direct-name screen cannot establish all of these questions. FCA material describes screening new customers, transaction counterparties and payments, and emphasises proportionate, calibrated, tested and reviewed systems; this is not a single global transaction-screening mandate.
4. List changes, periodic reviews and material events
Lists and programmes change. OFAC says its SDN list has no predetermined update timetable, so periodic review should not be the only way an institution learns a party may now be restricted. Checklynx-recommended implementation practice: treat official changes, ownership/control changes, new corridors, rails, portfolios and material data corrections as operational events with a documented population, owner, investigation path and completion record.
Payment-lifecycle control table
The exact lifecycle control must follow the applicable regime, product architecture, data availability and operational ability to intervene; the table does not prescribe one legally mandated step for every product.
| Lifecycle point | Parties and information newly relevant | Practical control objective | Checklynx-recommended implementation practice |
|---|---|---|---|
| Customer, merchant or corporate onboarding | Customer, merchant, legal entity, users, settlement account and relevant ownership/control information. | Establish baseline identity and relationship data. | Record the relationship-owning entity, identifiers and corporate-data provenance; escalate material ownership/control uncertainty. |
| Beneficiary or payee setup | New recipient, account destination, beneficiary institution and available relationship data. | Recognise a new sanctions-relevant party. | Decide whether an alert blocks creation, first use or only release; test sparse-data and common-name cases. |
| Payment initiation | Parties, amount, currency, route, geography, purpose and available chain participants. | Assess exposure not resolved at onboarding. | Map fields available before an irreversible decision point and escalate known data gaps. |
| Execution and payout | Final recipient/account, intermediary or beneficiary institution, route and timing. | Prevent unauthorised release while a material alert is assessed. | Define queue state, deadline, release authority and audit hand-off. Keep Article 5d distinct for in-scope EU instant transfers. |
| Returns, refunds and chargebacks, where relevant | Original parties, destination account, recipient and event context. | Treat a later value movement as a new operational event. | Reuse reliable context, but check whether recipient, account, ownership, list status or route has changed. |
| List or programme change | Existing active customers, beneficiaries, merchants, counterparties and potentially affected historic or pending payments. | Detect new exposure promptly rather than relying only on a calendar review. | Assign accountable owners for official-source monitoring, impact assessment, population selection, alert triage and completion evidence. Maintain a clear time-stamped record of the change and response. |
| Ownership/control or corporate-data change | Merchant, corporate customer, payee, beneficiary or counterparty becomes linked to a new owner/controller or group structure. | Reassess whether an unlisted entity may now be restricted under the applicable regime. | Trigger review from credible ownership, director, settlement-account, legal-name or group-structure changes. Do not treat a vendor’s corporate record as conclusive legal analysis. |
| New corridor, rail, product or partner | New country, currency, correspondent, payout partner, acquirer/issuer relationship or payment type. | Identify whether the changed architecture creates a new legal perimeter, data gap or route-specific restriction. | Require compliance and operations sign-off on the party/data map, intervention point, reporting path and list-change ownership before launch. The appropriate scope is risk- and regime-dependent. |
EU scope: instant payments are a specific rule, not a shortcut
For EU PSPs offering instant credit transfers within the provision’s scope. Regulation (EU) 2024/886 introduced Article 5d into Regulation (EU) No 260/2012. Article 5d requires verification of whether payment service users are subject to targeted financial restrictive measures immediately after relevant new or amended measures enter into force and at least once every calendar day.1
During execution, the payer’s and payee’s PSPs must not carry out an additional targeted-financial-restrictive-measures verification of those payment service users beyond Article 5d(1). This is not a general statement that instant payments are free of sanctions controls, nor does it remove other restrictive-measures obligations.
Two mistakes are common in summaries of this rule. The first is to generalise the “at least daily” cadence to every payment product in every jurisdiction. The second is to say that the rule requires a fresh payer/payee name-screen during every instant transfer. Both lose the distinction in Article 5d.
Article 5d states that PSPs must comply with that Article by 9 January 2025. Confirm whether the provider is a PSP offering instant credit transfers and whether other instant-payment provisions, which may have separate deadlines, are relevant to its Member State and service.1
Ownership and control: why a clean name result may not close the case
Corporate payment flows require a second layer of analysis. An entity may not appear by name on a list yet still be subject to restrictions because of its relationship to a designated owner or controller. The treatment is regime-specific.
EU and UK measures can extend to entities owned or controlled by designated persons in the applicable legal context. In contrast, OFAC’s 50 Percent Rule addresses direct or indirect aggregate blocked ownership of 50% or more by one or more blocked persons; distinct programme restrictions require separate analysis. Do not merge these ownership and control tests.23
The operational lesson is not “screen every UBO in the same way under every law.” Provide an escalation path for corporate merchants, beneficiary institutions, counterparties and payout recipients: obtain corporate evidence, identify the regime, assess ownership/control and record the reasoning. Name matching alone cannot do this work.
Workflow diagram: from identification to rescreening
Investigate alerts before deciding the legal action
An alert needs triage, not reflex. Establish whether it concerns the listed person or entity by comparing available identifiers, relationship and payment context. A business case may require ownership/control analysis.
Then classify the legal effect: source and version, applicable programme or legal act, the institution’s nexus, the party’s role and actual prohibition. OFAC distinguishes SDN blocking from non-SDN restrictions, while EU and UK action can turn on the measure, exceptions and licensing framework.
Only then should the institution decide the disposition: pause, release, refuse, reject, block, seek advice, assess a licence or exception, and/or report. “Freeze the payment” must not be the automatic response to every name alert.
Checklynx-recommended implementation practice: Define the alert state model before go-live. Specify what can be auto-cleared, what must be reviewed, which person can release a payment, when specialist sanctions or legal escalation is mandatory, how aged alerts are monitored, and how the decision is communicated to operations and customer-facing teams. Keep jurisdiction-specific reporting playbooks separate; reporting deadlines and triggers are not universal.
Operational alert-investigation decision framework
This implementation framework prevents an automated match being treated as a legal conclusion and uncertainty sitting in an unowned queue. It is not legal advice and does not replace jurisdiction-specific blocking, rejection, reporting or licensing analysis.
| Decision stage | Questions for the reviewer | Evidence to obtain or preserve | Possible next step |
|---|---|---|---|
| 1. Contain and identify | Which party alerted, what is the payment state, and can the relevant step be paused? | Alert/payment/party IDs, timestamps, route, account identifiers and queue owner. | Use the defined review state; escalate if the product cannot await a decision. |
| 2. Resolve identity | Is this payer, beneficiary, merchant, customer or intermediary actually the listed subject? | Names, date of birth/incorporation, nationality, address, document/registration/account IDs, narrative and relationship data. | Record a false-positive rationale, obtain more data or continue to specialist review. |
| 3. Review ownership and control | Is an unlisted corporate party linked to a designated owner/controller under the relevant test? | Filings, shareholder/director records, ownership/control rights, group chart and sources. | Escalate material or unclear structures; do not convert generic UBO data into a legal conclusion. |
| 4. Assess programme and prohibition | Which legal act/programme applies to the institution, party role, property or transaction? | Authoritative source/version, nexus, party role and payment-chain/geographic context. | Determine the authorised legal path; SDN and non-SDN restrictions are not identical. |
| 5. Decide, escalate and communicate | Who may approve the outcome, and is a licence, exception or report relevant? | Rationale, approver/timestamps, escalation notes and any reporting or licence assessment. | Apply the approved disposition and jurisdiction-specific reporting playbook. |
| 6. Learn and rescreen | Did the case expose a data, calibration, route or product-control weakness? | Root cause, configuration/version, affected population, owner and test result. | Correct under change governance and reassess affected exposure as appropriate. |
Payment-specific investigation examples
These illustrations are not statements of legal outcomes.
- New beneficiary close match: obtain available account, address, date-of-birth, institution, country and relationship data; use the predefined hold and escalation path if the first transfer cannot be resolved. FCA guidance supports attention to counterparties and payments, not a universal release rule.
- Merchant settlement-account change: treat the changed recipient account and legal-entity details as a fresh event; escalate a designated-person ownership/control concern rather than relying on a merchant-name rescreen.
- Beneficiary-chain institution concern: a clear customer result does not resolve a route concern. Accompanying transfer information can help investigation, while the applicable regime and facts determine the sanctions assessment.
Evidence to retain for a defensible payment decision
Good operations make the decision reproducible. For each material alert, record what was screened, the source and version, why the alert appeared, comparison attributes, ownership/control analysis, decision, action and time.
For a material alert, retain:
- party and transaction identifiers, including the party’s role in the payment;
- source list or legal measure, version or retrieval date, and relevant programme;
- match rationale and supporting identity attributes;
- corporate-structure and ownership/control evidence where applicable;
- payment-chain, geographic and purpose information used in the assessment;
- analyst notes, escalation, approvals and timestamps;
- final disposition and any applicable report, licence or exception assessment; and
- configuration, list-change and audit evidence that shows how the alert entered the workflow.
FCA findings highlight calibration, testing, resourcing and alert management. OFAC’s framework identifies management commitment, risk assessment, internal controls, testing/auditing and training. These sources support governance, not one vendor, threshold or operating model.
Outsourcing needs active oversight: the institution should understand data, configuration, updates, alert queues and service failures, then test representative cases, changes and recovery procedures.
A practical first-90-days implementation roadmap
The roadmap is a Checklynx-recommended implementation approach for an institution improving a payment-screening control. It assumes legal advice and accountable senior ownership where needed; it does not prescribe one technology, threshold, service level or sequence.
Days 1–30: establish the payment-risk baseline
Start with a cross-functional inventory: compliance maps legal perimeter and programmes; operations identifies decision points and queue ownership; product/engineering describes event data; finance and partner teams identify settlement and chain parties.
Produce a regime-and-programme matrix, party/data matrix, lifecycle map and issue log. They should cover the parties, intervention points and gaps set out above, including missing beneficiary identifiers, unresolved settlement-account ownership, manual release paths and unclear list-update ownership.
Prioritise gaps by legal exposure and irreversibility. For EU instant-credit-transfer offerings, identify whether Article 5d applies, the payment service users in scope, measure-change ownership and evidence for the at-least-daily verification.1
Days 31–60: design decisions and test the operational path
Turn the inventory into decisions for missing or late data, list changes, beneficiary review, ownership/control and payment release. Test the alert-state model against a common-name beneficiary, merchant settlement-account change, ownership/control concern, intermediary data point, later value movement, official list update and time-sensitive payment. Confirm an owner, evidence, permitted action and audit record for each. Clarify official-source, data-mapping, outage/queue-failure and hold-override ownership.
Days 61–90: implement governance, assurance and change control
Finalise alert investigation, payment-release authority, sanctions/legal escalation, jurisdiction-specific reporting and licence/exception procedures. Establish risk-based assurance: sample cleared and escalated alerts, reconcile official-source changes, test new-beneficiary, merchant-account and return/refund paths, and assign an escalation route to queue-ageing, missing-data and failed-control measures. New corridors, currencies, partners, rails and features should not go live without an updated party/data map, legal-perimeter review, intervention design, ownership assignment and test evidence. This is a recommended discipline, not a universal legal approval requirement.
Operational checklist
Use this as an implementation checklist, not as a substitute for legal analysis.
FAQs
Must every payment institution screen every payment in the same way?
No. Identify the binding regimes and restrictions that apply to the payment flow, then assess the exposure-changing events rather than assuming an onboarding result covers every later event.
Is screening at customer onboarding enough?
No. New beneficiaries, merchants, counterparties, owners, payment-chain institutions, list changes and later value movements can create a new assessment point. Assign an owner for each rescreening or reassessment path.
Do EU instant payments require a payer and payee check on every transfer?
EU scope: not as a simple generalisation. For PSPs offering instant credit transfers within scope, Article 5d requires payment-service-user verification immediately after relevant new or amended targeted-financial-restrictive-measures enter into force and at least once each calendar day. It also says payer and payee PSPs do not perform an additional Article-5d-type verification of those payment service users during execution; other restrictive-measures questions remain separate.1
Should a payment institution screen beneficial owners?
Do not state a universal “UBO screening” rule without the applicable law. But beneficial-ownership and control data can be essential where a merchant, beneficiary or corporate customer is not directly listed yet may be restricted under the relevant regime. Build a targeted escalation process rather than relying on a clean company-name result.
Does a name alert mean the payment must be frozen?
No. A name alert must first be investigated and classified. The legally appropriate outcome can differ by regime, party role, programme, transaction facts, licence or exception. Some cases are false positives; others may require a block, rejection, refusal, report or escalation.
Can a payment institution outsource sanctions screening?
Technology and operations may be outsourced, but outsourcing does not eliminate the institution’s need to oversee the control. The firm should understand the data flow, configuration ownership, official-source update process, alert handling, payment-release authority, testing and failure recovery.
Is FATF Recommendation 16 a sanctions-screening rule?
No. FATF Recommendation 16 is an international payment-transparency standard, not a sanctions list or universal private-sector screening law. FATF states that the 2025 changes take effect by the end of 2030; local implementation and any already-effective domestic rules must be checked separately. Originator and beneficiary information can support an investigation.4
Sources
Primary sources used for this draft; review each immediately before publication.
- European Union, Regulation (EU) 2024/886 (Official Journal PDF) — Article 5d instant-credit-transfer provision.
- European Union, Regulation (EU) 2023/1113 — information accompanying transfers of funds.
- European Commission, Overview of sanctions and related resources — EU sanctions framework.
- European Banking Authority, Final guidance on internal policies, procedures and controls for Union and national restrictive measures — supervisory guidance relevant to PSPs.
- FATF, Recommendation 6 update and Recommendation 7 / proliferation-financing material — international targeted-financial-sanctions standards.
- FATF, Recommendation 16 payment-transparency update — international payment-transparency standard.
- UN Security Council, UN Consolidated List — UN-listed persons and entities.
- FCA, Financial Crime Guide: financial sanctions — UK financial-services guidance on screening customers, counterparties and payments.
- UK Government, UK Sanctions List — current UK designation source; use with regime-specific guidance at the time of action.
- FCA, Sanctions systems and controls: our firms, our findings — supervisory findings on calibration, testing and alert management.
- OFSI, UK financial sanctions general guidance and UK financial sanctions FAQs — ownership and control guidance.
- OFAC, A Framework for OFAC Compliance Commitments — risk-based compliance framework.
- OFAC, 50 Percent Rule FAQ, Sanctions programmes and country information and SDN update timetable FAQ — US ownership, programme and update context.
- OFAC, SDN List, non-SDN lists and reporting FAQ — list and disposition context.
Related reading
- General sanctions guide — legal framework, list and regime fundamentals.
- Core sanctions-screening knowledge-base guide — identity and screening context for alert resolution.
- Payments industry page — payment-sector context for readers assessing their operating model.