Sanctions screening helps payment businesses identify whether a customer, beneficiary, company, vessel, or other counterparty may be subject to restrictive measures. For cross-border payments, screening should happen early enough to prevent a prohibited payment and clearly enough for an analyst to verify the evidence.
No single list represents every obligation. Coverage depends on the countries, licences, counterparties, and payment corridors relevant to the institution. A Nigerian payment business with international exposure may need Nigerian sources alongside United Nations, United States, and United Kingdom lists.
What the major official lists cover
The United Nations Security Council Consolidated List contains individuals and entities subject to measures imposed under different Security Council sanctions regimes. The list includes identifying information and links each record to a sanctions committee or regime.
The United States Office of Foreign Assets Control publishes sanctions data including the Specially Designated Nationals and Blocked Persons List. OFAC records can include individuals, entities, vessels, aircraft, aliases, addresses, and other identifiers.
The UK Sanctions List identifies people, businesses, organisations, and ships designated or specified under UK sanctions regulations. Since January 2026, it is the single UK government source for current UK designations.
Nigeria also maintains relevant local sanctions and terrorist financing sources. Institutions should select lists according to their legal obligations, customer base, products, and geographic exposure rather than enabling sources without a documented reason.
A list is data, not a final decision
Official data needs to be downloaded, parsed, normalised, versioned, and matched against transaction or customer information. Names may appear in different scripts, orders, or spellings. Records can contain aliases, dates of birth, nationality, registration details, addresses, and programme information.
An exact name match can be highly relevant, but common names still require identity checks. A fuzzy match can catch transliteration or spelling variation, but it also increases false positives. Screening quality depends on using every available identifier and showing the analyst what matched.
What analysts need to see
A useful watchlist alert should show:
- The matched customer, beneficiary, or counterparty
- The official source and list type
- Exact, alias, or fuzzy match method
- Match score or confidence
- Relevant identifiers and jurisdiction
- The official source page or record context
- The transaction and control that produced the alert
The source link should take the analyst to a useful official page, not merely download a raw XML or CSV file. Raw files are suitable for ingestion, while human-readable source pages are better for investigation.
Screening customers and transactions
Customer screening usually happens during onboarding and periodic rescreening. Transaction screening examines parties and available payment context when activity occurs. Cross-border platforms may screen the sender, beneficiary, business counterparty, bank, wallet address, vessel, or narration depending on the transaction type.
Not every field should be treated equally. A beneficiary name is stronger evidence than a name casually mentioned in an unrelated narration. Rules should distinguish direct party screening from contextual mentions and should preserve which field produced the match.
Keeping official sources current
Sanctions lists change. New records are added, details are amended, and people or entities can be removed. A screening system should keep source versions, sync status, record counts, additions, updates, removals, and failures.
Automated source synchronisation can retrieve supported official formats on a schedule. Sources that do not provide a stable machine-readable endpoint may require a controlled manual upload or a dedicated parser. Every update should be validated before it becomes active.
How Remllo supports sanctions evidence
Remllo WatchTower can screen configured transaction parties against enabled watchlist sources and attach the match evidence to alerts and cases. Internal teams can manage sources, imports, rescreening, tenant list access, and allowlists through controlled administrative workflows.
The system preserves source and match context so analysts can compare the transaction with the official record. AI-generated investigation narration can summarise available evidence, but it should never invent source facts or replace verification by the analyst.
Remllo Identity can support sanctions and PEP checks in onboarding or verification workflows where the relevant provider and country are enabled. WatchTower focuses on transaction and investigation context, while Identity focuses on people and business verification.
Separate global coverage from tenant policy
A platform may maintain several official sources, but each customer should only use the lists and controls appropriate to its business. A domestic microfinance bank and a cross-border trade platform do not have identical exposure. Source access, screening controls, and enforcement actions should therefore be configurable by organisation.
This separation also supports commercial packaging and operational safety. Enabling a new international source should not silently change decisions for every existing tenant. Administrators should be able to see which sources are active, when they last synced, and which organisations can use them.
Avoiding common screening mistakes
Do not treat a country name as proof that a counterparty is sanctioned. Do not assume that an organisation is safe because its exact legal name is absent if ownership and control rules may apply. Do not let an AI summary become the source of truth. The official record, transaction data, and institution policy remain the evidence.
A strong programme combines current official data, explainable matching, analyst review, and clear outcomes. The value of screening is not the number of lists connected. It is the ability to stop relevant risk and explain every decision.