Payment Screening, inside the payment flow

The Client Screening feature provides information regarding the parties that you have onboarded, while Payment Screening looks at the message itself and therefore is able to identify a new counterparty, a sanctioned beneficiary bank, or a designated vessel mentioned in the reference field even if both account holders are clean.

The SWIFT MT and ISO 20022 pain and pacs messages should be parsed one field at a time rather than treated as a block of text; batch files are screened in the same way as live messages, using the same lists and the same thresholds, so a bulk payment process does not revert to a less stringent check.

The median screen time is 62 ms, which means that the screening takes place inline and messages are passed through without any delay. It doesn't affect your cut-off times since the screen is completed within the release call and not in a separate queue.

You decide on the behaviour, it being a matter of compliance rather than a technical default; the payments either remain pending until the screening results return or proceed with the gap noted for review. The choice you make is recorded and logged.

The debtor and creditor, together with all the agent details, addresses, BICs, country codes and the free-text reference; the reference and the address are just as important as the information relating to the parties, since a particular entity or vessel is sometimes named only in those fields.

The payment is held until it is released and the analyst is given access to the exact field, list and score associated with the match. A reason code is needed for each of the actions release, block and escalate, and the right to release can be separated from the right to review so that the same person does not carry out both actions.

The thresholds are established separately for each corridor and message type, secondary identifiers are used to narrow the match, and a counterparty which has been cleared can be put on a whitelist. A high hold rate indicates a tuning problem, not that it is a safety feature.

Yes, a cleared counterparty stays cleared until the underlying list record is modified, which is the reason why the same beneficiary does not raise an alert on every payment in which it appears; when the record is changed, the whitelist entry is reopened rather than just carrying on without any notice.

For each screen and for each message, the data should include information regarding which fields were read, which list version was in effect, who took the decision, when, and for what reason. This data can be exported either on a per-message basis or on a per-period basis.

Yes. The event writes back to the customer record on Fusion, so a pattern of near misses raises the customer's rating rather than living only in the payment log.