Sanctions Screening in the Payment Flow

Screen the payment before it is released. A sanctions hit found after the money has moved is a report. A hit found before release is a control. The difference is the step in the payment factory where the result is allowed to stop the file.

This sits next to payment fraud prevention and straight-through processing. Fraud controls ask whether the beneficiary is the one you meant. Sanctions controls ask whether any party on the message is one you are not allowed to pay. Both have to hold when someone is in a hurry. An STP rule that skips a hit because the payment is "urgent" has switched the control off.

What is actually screened

The beneficiary name is the field everyone configures. It is not the only field that can make a payment prohibited.

On a cross-border credit transfer the message names several parties: who ordered it, who receives it, which bank sent it, which bank receives it, and which banks stood in between. A payment can be clean on the beneficiary and still be a hit because an intermediary is blocked. If the screening feed only receives the beneficiary name — because the format mapping dropped the agent fields on the way from pain.001 into the screening tool — the control is narrower than the payment.

On an International ACH entry the design is explicit. The IAT carries addenda so the originator and receiver names and addresses, and the two banks, travel with the entry. The Federal Reserve's FAQ says a gateway operator screens inbound IATs and flags a possible hit, and that the receiving institution is still responsible for its own due diligence. For a company, the practical reading is: do not assume a flag someone else set is your screening, and do not drop the addenda in the interface because "the payment posts without them".

Which list applies — a US list, a UK list, an EU list, a local list — is a decision for the corridors you actually pay, made by compliance, reviewed when the corridor changes. This page does not pick the list. A screening tool pointed at the wrong list is a control that looks busy.

Where it sits in the factory

The only place the result changes the outcome is before release:

1. The payment is built, with every party the message will carry, not a shortened version for the screening file.
2. Screening runs against the current list. A list loaded last week is not a current list. The update itself is a control, with a timestamp someone can show.
3. A clear result releases. A hit holds. The payment does not sit in a "released, pending review" status that the next job will pick up.
4. A person with a named role clears a false positive, or escalates a true one. The decision, the list version, and the payment reference are stored with the payment. A hit with no decision record is an open control, not a cleared one.
5. Repair is screened again. A wire that was rejected, edited, and resubmitted is a new message. The edit is exactly where a party can be introduced that the first screening did not see.

OFAC's note on instant payments makes the design constraint obvious: if the rail completes before anyone can look at a hit, the institution needed an exception path. A corporate payment factory has the same constraint on a slower rail. "We screen overnight" does not cover a same-day file. The hold has to be as fast as the release.

What usually fails

• The screening file is a subset of the payment. Beneficiary only. Agents stripped because the screening vendor's layout had fewer fields than pain.001.
• STP and the hit are not connected. The payment job does not read the screening status. Operations learns about the hit from a morning report, after the bank has it.
• False positives are cleared verbally. The payment goes. The reason does not. The next examiner asks for the decision and there is an email, if anyone kept it.
• The list update is a person's habit. They are on leave. Screening runs on the previous list. Nothing in the payment status says so.
• The bank is treated as the control. The bank rejects a payment three days later. The company's own release had no screening result at all. The reject is then a surprise rather than a second line.

What I left out, on purpose

• Penalty figures, enforcement cases, and which programme applies to a given country. They change, and stating them here would be stale the quarter they change. Compliance owns that list. Treasury owns the point in the flow where the result can stop a payment.
• A vendor comparison. Screening tools are not the control. The hold is the control. A tool that cannot hold the payment is a report.
• AML transaction monitoring, which is a different question — behaviour over time, not a name on a list at the moment of release. Do not let one project "deliver sanctions" by switching on a monitoring rule.

Screening that cannot stop the payment is a log. Put the result on the release, and keep the decision with the payment.

See also payment fraud prevention, what is a payment factory and straight-through processing.