top of page

Payment Controls, Sanctions Screening & WTR

Distinct Roles, Shared Risks

This explainer breaks down the purpose, scope, and regulatory basis of payment controls, sanctions screening, and WTR checks. While each serves a separate compliance function, their intersection points and differences are critical to understand. Learn how these controls operate, where they overlap, and how to design an integrated, risk-aligned framework that meets regulatory expectations without creating operational blind spots.


Target Audience

This explainer is designed for professionals working across compliance, payment operations, product, and technology functions within PSPs. It provides practical clarity for those implementing or managing sanctions screening, WTR checks, and payment controls, particularly in the context of regulatory compliance, transaction monitoring, and risk management.


It is especially relevant for compliance officers, AML specialists, and risk managers responsible for ensuring effective control design and governance. It also supports product and technology teams who build or maintain the infrastructure behind these controls, helping them understand how and where integration matters. Finally, this resource may also assist internal audit, regulatory affairs teams, and external stakeholders (including regulators, supervisors and industry partners)who need visibility into how these control layers interact in practice.


Why It Matters

Payment controls, WTR checks and sanctions screening serve different but connected purposes such as blocking prohibited parties, ensuring required transfer data, and detecting risky patterns, respectively. Mixing them up risks compliance failures and operational gaps; keeping them distinct but integrated ensures effective and auditable financial crime controls.


Overview

Payment controls, sanctions screening, and WTR checks are complementary components of a robust transaction monitoring and screening framework. Each addresses different risk vectors and regulatory requirements but must work in coordination to ensure effective, end-to-end financial crime compliance.


Payment controls are rule-based or risk-based mechanisms applied either before a transaction is executed (pre-event) or afterwards (post-event). Their primary purpose is to detect risky patterns, anomalies, or behaviours indicative of fraud, money laundering, or other threats. While not explicitly mandated by law, payment controls are widely regarded as an essential element of a firm’s AML and operational risk framework under the UK's risk-based approach. Regulators such as the FCA expect firms to implement proportionate systems and controls to mitigate transaction-related risks. When absent or poorly implemented, payment controls can allow high-risk transactions to proceed unchecked, leading to operational loss or systemic exposure.


Sanctions screening ensures that no party involved in a transaction - be it the payer, payee, or intermediary - is listed under applicable sanctions regimes. This control is non-negotiable, governed by international regulatory obligations such as those enforced by OFAC (US), HMT (UK), and the EU. It must always be applied in real time, and failure to detect and block sanctioned entities can result in legal penalties, reputational harm, frozen assets, and regulatory sanctions.


WTR checks focus on verifying the presence, accuracy, and structure of payer and payee information in payment messages. These checks ensure compliance with data integrity rules under regulations like FATF Recommendation 16, the UK Money Laundering Regulations 2017, and the EU Funds Transfer Regulation. WTR screening may be performed either in real time or post-event, depending on a PSP’s risk assessment and jurisdictional guidance. Failure to comply can result in regulatory breaches, enforcement actions by supervisory bodies, and may also lead to the identification of suspicious activity requiring a Suspicious Activity Report (SAR) to be filed under POCA


Together, these three layers form a multi-dimensional control system that protects the integrity of the financial system, supports regulatory compliance, and enhances the institution’s ability to detect and respond to evolving financial crime risks.


Controls Matrix

This outlines which types of controls apply to each layer and highlights their functional roles. It helps clarify how each control contributes to the broader compliance framework.


*WTR real-time block depends on the PSP’s risk appetite and implementation strategy.
*WTR real-time block depends on the PSP’s risk appetite and implementation strategy.

Where The Controls Intersect

Although payment controls, sanctions screening, and WTR checking serve distinct purposes, they intersect in several critical areas. These intersections create opportunities for risk amplification, control synergy, and if poorly managed, alert duplication or control failure.


  • Shared Transaction Flow All three controls operate on the same payment message, with sanctions screening, WTR checks, and payment controls triggered in sequence or in parallel based on the transaction structure.

  • Dependence on Data Quality Each layer relies on clean, well-formatted data; poor inputs especially in SWIFT MT formats can lead to false positives, WTR non-compliance, and flawed payment risk detection.

  • Overlapping Risk Indicators Certain red flags like missing payee details, sanctioned jurisdictions, or obscured party names can trigger alerts across multiple controls simultaneously.

  • Integrated Investigation Workflows Alerts in one control layer often require review in the context of others, supported by unified case management and escalation processes.

  • Regulatory & Audit Expectations Regulators expect PSPs to clearly separate, govern, and document how these controls intersect to ensure traceability, effectiveness, and compliance.


Integration Points

These include:


  • Common infrastructure

    Sanctions, WTR, and payment controls can all run on the same core architecture such as a shared message parser or ingestion layer to reduce duplication and ensure consistent data flow.

  • Data harmonisation

    A unified data dictionary standardises how fields like names, account numbers, and addresses are captured and interpreted across systems, improving screening accuracy and reducing false positives.

  • Alert management

    A shared case management platform allows different control alerts to be triaged, investigated, and escalated through one workflow, improving efficiency and auditability.

  • Risk scoring engines

    Centralising risk scoring lets PSPs correlate findings across multiple controls; for example, combining WTR deficiencies with payment anomalies to flag higher-risk transactions.

  • Reporting

    Consolidated dashboards provide a comprehensive view of all control layers, enabling compliance teams to track trends, measure effectiveness, and report accurately to senior management or regulators.


Common Mistakes

These include:


  • Assuming WTR checking must always be performed post-event, regardless of risk assessment. This disregards regulatory flexibility; in some scenarios, real-time validation is necessary based on risk exposure or jurisdiction.

  • Using sanctions screening as a catch-all control for other risks like WTR non-compliance, fraud or AML typologies. Sanctions screening is designed for name-matching against restricted entities. It does not address data integrity or behavioural anomalies.

  • Relying on payment controls as a substitute for WTR checking. Payment controls detect transactional risks but don’t validate mandatory payer/payee data required under WTR.

  • Ignoring WTR obligations for domestic or intra-PSP transfers where local rules still apply. Some jurisdictions require WTR compliance even within the same PSP or country; neglecting this can lead to regulatory breaches.

  • Failing to clearly define roles and triggers for each control layer, leading to overlaps or gaps. Without role clarity, responsibilities blur causing duplication, missed alerts, or inefficient investigations.

  • Treating all alerts the same, regardless of the underlying control type or risk context. Not all alerts carry equal risk or urgency; lumping them together degrades triage quality and investigation prioritisation.

  • Using fragmented systems or workflows that prevent integrated case handling or escalation. Siloed tools hinder visibility across control types and delay risk escalation, leading to operational inefficiencies.

  • Applying corridor-agnostic rules that miss jurisdiction-specific regulatory requirements. Different regions have different rules so controls must adapt accordingly to stay compliant and relevant.

  • Neglecting audit trail and governance documentation for each control mechanism. In the event of a breach or audit, lack of clear documentation weakens the institution’s regulatory defence.

  • Over-engineering controls without tailoring them to actual risk exposure or message type. Complex controls that aren’t risk-aligned create inefficiencies and unnecessary alert volumes.

  • Treating WTR validation as equivalent to sanctions screening (they are not). WTR focuses on data completeness and structure, while sanctions screening targets restricted parties. Conflating the two weakens both.

  • Relying on screening tools to compensate for poor WTR data capture. Screening engines cannot fill in missing or poorly structured data. Quality input is essential for compliance and risk detection.

  • Ignoring the format and structure of payment messages, especially in SWIFT MT. Misplaced or malformed data fields can break screening logic and lead to undetected or misinterpreted risks.


Summary

Payment controls, sanctions screening, and WTR checking each play a distinct but connected role in transaction compliance. Sanctions screening is always real-time and mandatory, WTR checking may be real-time or post-event depending on risk, and payment controls are tailored to detect behavioural risks. A strong framework treats each control separately but ensures they work together through clear governance, shared data, and coordinated execution.


bottom of page