How Screening Works in a Payment Flow

Screening happens at defined points in the payment lifecycle, and the timing matters as much as the matching itself. In most banks, a payment is screened when it is first received, before any validation or routing takes place, so that a blocked payment never reaches the clearing system. For outgoing SWIFT payments, the screening engine checks the sender, the beneficiary, the intermediary banks, the remittance information and any other party named in the message, including the fields that carry free text. Incoming payments are screened too, because a bank cannot knowingly accept funds from a sanctioned party, and a blocked incoming payment must be handled carefully to avoid returning money to a sanctioned person. Modern screening is usually done by a dedicated screening engine that sits between the payment hub and the compliance case management system. The payment hub sends the payment details to the engine, the engine compares them against the loaded lists, and it returns a result. Clear, possible match, or confirmed match. A clear result lets the payment continue automatically, often within milliseconds. A possible match creates an alert in a work queue for a sanctions analyst to review, and the payment waits until the analyst clears it or escalates it. A confirmed match stops the payment and triggers the blocking or rejection procedure. Every one of these steps is logged, because regulators expect a complete audit trail. Screening is not a one time event. Lists update during the day, so banks run retrospective screening, sometimes called delta screening, over payments that were already processed, to catch names that were added after the payment went out. They also screen their whole customer base periodically, because a long standing customer can appear on a list years after onboarding. Batch files, standing orders and direct debits are screened in bulk, and trade finance documents are screened against goods, ports and vessels as well as names. A BA designing a payment flow must map every entry point where a payment or a party can enter the bank, and make sure screening covers each one. The screening decision tree is the logic the payment hub follows for every payment. The first question is whether the payment is in scope: domestic payments within one country are usually not screened against international lists, while cross-border payments always are. The second question is whether any field matches a list entry. The third is whether the match is a true hit or a false positive. The fourth is whether the payment can proceed, must be held, or must be blocked. The tree must be written down, and each branch must have an owner, a deadline, and an audit record. A payment that enters the tree and never comes out is a payment that is lost. Real-time screening and batch screening serve different payment types. An instant payment must be screened in real time, in under a second, because the payment settles in seconds and cannot wait for a batch. A bulk payment file can be screened in batch, because the file is processed over hours. The screening engine must therefore support both modes, and the requirements must state which payment types use which mode, and what the maximum screening time is for each. A real-time screening that takes 5 seconds will cause an instant payment to time out, and a batch screening that runs once a day will delay a payment by a day. When a payment is held for screening, the hold procedure must be precise. The payment is placed in a queue, the customer is told it is under review, the analyst is assigned, and a deadline is set. The deadline is usually measured in hours, not days, because the customer is waiting. If the analyst cannot clear the payment within the deadline, it is escalated, and if it cannot be cleared at all, it is blocked and the funds are returned. The procedure must state the deadlines, the escalation path, and the customer communication at each stage, because a held payment without communication is a customer complaint.