Sanctions and Payment Screening in the UK: A Practical Process for Money Transfer Operators

A UK money transfer business that pays a designated person has breached financial sanctions, whether or not anyone meant to. Screening is how you stop that happening, and the records of your screening are how you show you tried. Done well, it holds very few legitimate transfers and leaves a clear decision behind every one it does hold.

This guide is for compliance heads, MLROs and operations leads at UK payment institutions and their agents. It sets out a working process: which lists to screen, who and when to screen, how to judge a possible match, what to record, and when to escalate. We show where RemitSo's admin panel does the mechanical work and where judgement stays with your team. It is general guidance, not legal advice; confirm your obligations with OFSI, the FCA or an adviser.

UK financial sanctions mostly take the form of asset freezes. If a person or organisation is designated, you must not deal with their funds, and you must not make funds available to them or for their benefit, directly or indirectly. That includes entities they own or control, even if those entities are not named on any list.

Three features shape how you design screening:

• Civil penalties do not require intent. The Office of Financial Sanctions Implementation (OFSI) can impose monetary penalties on a strict liability basis. "We did not know" is not a defence; "we screened properly and recorded our decisions" is your best mitigation.
• You must report. Businesses that transmit money are among the "relevant firms" that must tell OFSI as soon as practicable when they know or reasonably suspect that someone is a designated person, or that a breach has happened, and what funds they hold for a designated customer.
• Licences are the only way through. If a payment involving a designated person must be made, it needs a licence from OFSI, and licences cannot be issued retrospectively. Your team cannot decide that an exception is reasonable.

No UK law says "screen every payment in this way". Screening is the control that lets you meet these duties, and regulators expect it to be proportionate to your risk and to work in practice. Sanctions screening sits beside, not inside, your AML monitoring: one asks "is this person designated?", the other asks "is this behaviour suspicious?". You need both.

The UK Sanctions List is your baseline. Since 28 January 2026 it has been the only list of UK designations: the separate OFSI consolidated list of asset freeze targets closed on that date and is no longer updated, so check your screening does not still depend on it. UN designations have effect in UK law through the UK's sanctions regulations; many operators screen the UN list as well because banks and payout partners expect it. Beyond that, your corridors, currencies and partners decide.

Write the choice down in your sanctions policy, with the reason for each list. A partner or bank will often require more lists than UK law does; that becomes a contractual obligation you must meet and evidence.

Gaps in screening usually come from a party or a moment that nobody thought about. Cover all of these:

• Senders, when they register and on every transfer.
• Recipients, when they are added and on every transfer to them.
• Account holders, where the name on the paying card or bank account differs from the customer.
• Staff, at joining and whenever lists change. A designated employee is a breach risk too.
• Everyone already on file, when a list changes. A customer cleared last month may be designated today.

Data quality decides how good your matching can be. Capture the full name as it appears on the identity document, date of birth and country for senders, and the recipient details your payout method needs, in separate name fields rather than one free-text box. Structured names make matching far more accurate.

Exact matching misses real hits. Names are transliterated from other scripts in several valid ways, word order varies, and designated people use aliases. Fuzzy matching closes that gap but produces possible matches that a person must review. The aim is not fewer alerts; it is alerts worth reviewing.

• Set your matching sensitivity deliberately, write down why, and test it with known names and spelling variants.
• Use secondary identifiers. Date of birth, nationality and address separate a common name from the designated person. Collect them so the reviewer has something to compare.
• Remember lists name more than people. Entries include organisations, vessels and aircraft, which matter if a recipient is a business.
• Do not auto-clear. A rule that dismisses matches below a score is a decision nobody reviewed.

Each possible match ends in one of three outcomes. The table sets out what follows each.

Keep rulings per person. Once a reviewer has cleared a name with good reasons, the same customer should not stop on every transfer for the same entry; that wastes time and teaches reviewers to click through. A ruling should be revisited when the list entry changes.

Separate duties where you can: the analyst who rules on a match should not be the one who approves the payout. For confirmed matches and borderline cases, a second reviewer signs off.

A confirmed match triggers two separate questions.

1. Sanctions. Freeze the funds, do not process the transfer, and report to OFSI as soon as practicable with the information you hold. If the customer asks for the money back, that is itself a dealing with frozen funds; take advice before doing anything.
2. Money laundering. If the activity also gives grounds to suspect money laundering or terrorist financing, the MLRO decides whether to submit a suspicious activity report to the National Crime Agency. See our guide to suspicious activity reports.

Throughout, do not tip off the customer. Support staff need a standard response for held transfers that explains a delay without giving a reason. For how investigations are run end to end, see AML investigation and case management.

A screening system is only as good as the version of the list it checked. Supervisors and partners will ask two questions: how quickly do new designations reach your screening, and how would you know if a load failed?

• Load lists automatically, at least daily, from the publisher's dataset.
• Keep a load history: version, time, and what changed (entries added, changed, delisted).
• Re-screen existing customers, recipients and staff whose names a change could affect.
• Alert a named person if a list is out of date or could not be loaded, and have a written fallback, such as pausing new recipients on affected corridors, until it is fixed.
• When a new UK designation is urgent, be able to load on demand rather than wait for the next scheduled run.

Screening that nobody checks drifts. Build a light routine:

• Monthly: sample cleared matches and check the reasoning would satisfy a supervisor.
• Quarterly: test matching with known designated names and variants; review list choices against current corridors and partners.
• Board reporting: possible matches, time to decision, confirmed matches, reports to OFSI, and any list-load failures.
• Training: everyone who rules on matches is trained on your process and on tipping-off, with records.

A compliance dashboard keeps these figures in one place.

The names and figures are illustrative, not drawn from any real operator.

Tuesday, 10:15. A long-standing customer sends £850 to a new recipient. The recipient's name partly matches an entry on the UK Sanctions List. The platform raises a possible match, and the operator's risk rule, built on the recipient sanctions-check indicator, holds the transfer for a person.

10:40. The analyst compares identifiers. The listed person has a different date of birth and nationality from those on the recipient's details, and the payout account is in the customer's home country, not the listed person's. The analyst records a false positive with those reasons. A second reviewer agrees; the transfer is released.

Wednesday, overnight. The nightly load brings a new UK designation. The load reports one entry added, and the platform re-screens the people whose names it could affect. One existing customer now partly matches. Their next transfer of £300 is held.

Wednesday, 09:30. This time the identifiers line up: name, date of birth and country. The analyst escalates. The MLRO confirms the match, the funds are frozen, OFSI is notified, and the MLRO considers whether a suspicious activity report is also needed. Support tells the customer the transfer is delayed, and nothing more.

RemitSo's admin panel does the loading, matching and record keeping, so your team spends its time on decisions. See the admin features.

• Screening against 8 lists: the UK Sanctions List, UN Consolidated, OFAC SDN, OFAC consolidated non-SDN, EU financial sanctions, Canada, Australia DFAT and Swiss SECO, each switchable on or off to match your policy.
• Signed lists, checked before loading: the lists are published every day as a signed, versioned dataset, and every installation checks the signature before loading, so you can show which version applied on any date and that it arrived unaltered.
• Lists loaded every night, with "Load now": each list shows its source version, when its publisher last changed it, and a load history of entries added, changed and delisted.
• Re-screening after every load of the people a change could affect: customers, recipients, account holders and staff.
• Sanction lookup: every screening, what it matched, and what an officer decided about each match, kept per person so a cleared name is not flagged again.
• Confirm, not only dismiss: an officer can confirm a match as well as clear it, so the decision behind a freeze and an OFSI report is recorded where the screening is.
• "Possible sanction match found" and "Sanction match confirmed" alerts to the people you choose. The match itself blocks nothing; your risk rules decide which transfers wait for a person.
• "Sanction lists out of date" and "Sanction lists could not be loaded" alerts: you know about a failed load before a supervisor asks.
• 47 risk indicators, including sanctions checks on customer, recipient and payment holder, and high-risk countries: combine them into rules that hold the right transfers.
• Suspicious activity reports prepared and managed in the console, then filed by your compliance officer, and permissions that keep sanction lookup with compliance.

Your team still chooses the lists, sets the rules, rules on every match, reports to OFSI and decides on suspicion. For the wider picture, see sanctions screening for remittance companies and UK payment institution licensing. Book a demo to see a match ruled on end to end.

• OFSI: UK financial sanctions general guidance
• OFSI: Reporting information to OFSI
• OFSI: Monetary penalties for breaches of financial sanctions
• FCDO: The UK Sanctions List
• GOV.UK: Moving to a single list for UK sanctions designations, 28 January 2026
• National Crime Agency, UKFIU guidance: Understanding DAMLs and DATFs

Checked October 2026. Regulations change; confirm current requirements with the regulator or your adviser.