Payment and Transaction Screening: SWIFT, Stripping, Real-Time

Customer screening looks at static records; payment screening looks at money in motion, and it has to decide in seconds. As a payment passes through your institution, real-time screening inspects it and decides whether to let it through, hold it for review, or stop it, before it leaves. The stakes are high because once a prohibited payment exits, the breach is done.

This is also where the evasion techniques we studied, wire stripping and cover payments, are aimed, because they target exactly these message fields. So payment screening is a fast, high-pressure control, and the exam tests both how it works and what you do when it fires.

To screen a payment you must understand its anatomy. A wire, carried in SWIFT message formats, the older M-T messages and newer M-X ones, contains structured fields: the originator, the beneficiary, the ordering and beneficiary banks, intermediary banks, and reference or remittance information. Effective screening reads all the relevant fields, not just the obvious two parties, because a sanctioned name, address, or country can hide in an intermediary field, a reference line, or free-text remittance information.

Incomplete or vague fields are themselves a red flag, a payment that conspicuously omits expected detail may have been deliberately thinned. The discipline is comprehensive field coverage, since evaders place the prohibited reference wherever they think you won't look.

Two payment-evasion methods deserve special attention here. Wire stripping is the deliberate removal or alteration of identifying details, names, addresses, references, so a sanctioned party never reaches the screening filter; major enforcement cases have turned on exactly this. Cover payments, historically a concern with the M-T-two-oh-two cover message, can obscure the underlying originator and beneficiary by separating the cover payment from the underlying customer credit transfer.

The defenses are integrity-focused: watch for fields that have been blanked or genericized, for inconsistencies between related messages, and for counterparties whose payments are routinely thin on detail. Industry moved toward more transparent payment formats partly to close these gaps. On the exam, a payment with suspiciously missing originator detail should make you think stripping.

When a payment screening filter fires, the immediate action is to hold the payment, not to release it under time pressure from the business. Then you investigate the alert, which is the subject of our next domain. The outcome drives the action you learned earlier: if it's a true match involving a blocked person's interest, you block the payment, freeze it, segregate it, and report; if it's prohibited but without a blockable interest, you reject and return it; and if it's a false positive, you release it and document why.

The classic exam trap is a front-office manager pressing to release a held payment to meet a deadline, the correct answer is to keep the hold until the alert is properly resolved, because once it's gone, you can't unsend it.

Two follow-through obligations close the loop. First, reporting: under U.S.

rules, blocked transactions and rejected transactions are both reportable to OFAC within the required timeframes, and other regimes have their own reporting duties, so a payment decision isn't finished until the report is made. Second, recordkeeping: you retain a full record of the alert, the investigation, the decision, and the rationale, so the file stands up to examination later. And the smartest programs feed payment-screening outcomes back into tuning, persistent false positives suggest a calibration fix, while a near-miss that should have alerted exposes a gap.

Let's rehearse the single most common payment-screening scenario on this exam, because it's worth getting reflexive. A payment hits the filter and is held. The front office, or a relationship manager, pushes hard to release it before a payment cutoff, arguing the customer is important and the delay is embarrassing.

What do you do? You keep the hold until the alert is properly investigated and resolved. The reasoning is asymmetry: if you release a true match, the prohibited payment leaves and the breach is irreversible, you can't recall it, whereas holding a false positive a little longer is only an inconvenience.

Business pressure, deadlines, and customer importance are not reasons to release an unresolved sanctions hit; they're exactly the conditions under which institutions have made costly mistakes. So when the option says release to meet the deadline, that's the trap, and keep the hold and escalate is almost always the right answer. With static and payment screening covered, the next lecture extends screening into trade, goods, vessels, ports, and end-users, where the prohibited element hides in shipping documents rather than names.