It means a transfer is refused when the screening system is unavailable, times out, or returns anything the policy does not explicitly permit. Rather than being allowed through and reviewed afterwards. The distinction is the difference between a control and a report: a control changes the outcome, and a system that lets payments proceed when screening is down is producing a report about payments it already made.
The architectural consequence is that screening sits in the settlement path rather than beside it. If it can be bypassed by a timeout, a retry, a queue backing up, or a feature flag set during an incident, it is not in the path. And every one of those is a normal operational event rather than an exotic failure.
The objection is availability: screening dependencies do fail, and refusing payments during an outage has a commercial cost. That cost is real and it is the correct trade. A sanctions breach is not a degraded experience, it is an enforcement matter, and “our provider was down” has never been an accepted answer.
Fail-closed also has to include ambiguity, not only unavailability. A screening result the policy does not recognise, whether a new response code, an unexpected match type or a malformed payload, must be treated as a stop, not a pass. Allow-known-good, deny everything else.
What makes this affordable is that the fail-closed path can be fast and cheap. Most transfers clear screening in milliseconds against a cached list with a hard timeout, and the small proportion that do not are queued for review rather than rejected outright. The design goal is that the refusal is a delay for the customer and never a silent pass for the institution.