Sanctions Screening for Payment Platforms Before Payout Release

Sanctions clearance is a decision, not a search score#

Before a payment platform releases a payout, it needs to determine whether the parties, ownership, property, and transaction are permitted under the applicable sanctions rules. A name-search result helps identify possible matches. It does not settle the legal treatment of a transaction.

The operational design should preserve four distinct outcomes: unresolved review, cleared for the specified facts, blocked property, and a prohibited transaction that must be rejected rather than blocked. Give each outcome an owner, evidence, and consequences for money movement.

Establish jurisdiction and program scope#

OFAC FAQ 11 explains that U.S. persons include U.S. citizens and permanent residents wherever located, persons within the United States, and U.S.-incorporated entities and their foreign branches. Certain programs also reach foreign subsidiaries, and some prohibitions apply to non-U.S. persons. Do not infer exemption merely because a seller or platform is overseas.

Map the actual platform entities, providers, jurisdictions, and transaction exposure. Review sanctions programs and country information to identify applicable authorities and any relevant licences or exceptions. Other jurisdictions may impose their own obligations; coverage required by law is not an optional internal policy choice.

Keep sanctions lists separate from politically exposed person and adverse-media sources. Those sources can support other risk reviews, but they do not have the same legal effect as a blocking designation. Define each source’s purpose and how a result affects a payout.

Check ownership even when the entity name has no hit#

Under OFAC FAQ 399, ownership interests of blocked persons are aggregated. If two blocked persons each own 25% of an entity, their combined 50% makes the entity blocked under the rule, even if the entity itself is not named on the SDN List. Ownership interests blocked under different OFAC programs are also aggregated.

FAQ 401 explains indirect ownership through entities that are themselves 50% or more owned in the aggregate by blocked persons. Do not apply ordinary percentage multiplication as your only test. For example, a blocked person owning 50% of Entity A makes A blocked; if A owns 50% of Entity B, B is blocked too.

Keep the ownership chain and its supporting documents, including the basis for each relevant stake and any unresolved branch. A provider’s legal-name match is not a substitute for entity ownership due diligence. Escalate incomplete or contradictory ownership before releasing an affected payout.

FAQ 398 distinguishes control from the 50% ownership rule. Control without the required ownership does not automatically make an entity blocked under that rule, but other restrictions, dealings with blocked persons, and the relevant facts still need review. Do not turn “below 50%” into blanket clearance.

Separate potential matches, blocking, and rejection#

OFAC FAQ 32 distinguishes rejecting prohibited transactions from blocking property. The decision depends on the program and property interest, not on which provider status is easier to implement. Route confirmed cases to the sanctions decision-maker to establish the required treatment.

A potential fuzzy match is not a confirmed designation. Use the OFAC match-resolution guidance to compare the type of party, complete name, identifiers, address, and other available facts. Record why the result is a false positive or why it remains unresolved. A weak score, missing identifier, or vendor timeout alone cannot justify clearance.

If a licence or other authorisation is relevant, record its scope, conditions, dates, and supporting legal assessment. A closed internal case does not itself authorise release of blocked property. Neither does another provider accepting a transfer.

Keep screening current at the points that matter#

Screen relevant parties when establishing the relationship and when material facts change. Before release, confirm that the decision covers the actual obligation, beneficiary version, ownership, and applicable current restrictions. Rescreening after a relevant list or ownership update should reach affected active parties and queued instructions.

Define refresh and review targets that your risk assessment and operating model can support. Distinguish a list retrieval, a published usable version, and a completed screen. A successful download timestamp does not prove a queued payout was screened against the new data.

Keep a payout’s release decision tied to the screening inputs, list version, ownership assessment, reviewer, and time. If the destination or material party data changes, require an appropriate new decision. Do not let a months-old onboarding clearance silently cover a changed transaction.

Treat list failure and rollback as degraded controls#

Use the OFAC Sanctions List Service and approved sources for the required coverage. Preserve each source artifact, retrieval time, version or checksum, parser result, and production publication event. Validate format and material changes before replacing a usable dataset.

If ingestion fails, retain the last usable copy for investigation and continuity, but mark the screening service degraded. An old copy does not establish compliance with new restrictions. Pause affected releases or use an authorised, current-data review path; do not silently treat a previous “clear” result as current.

A rollback can restore a working parser or dataset while omitting a new designation. Preserve the failed artifact, difference, rollback decision, affected parties, and recovery plan. Restore current coverage and reassess the affected queued instructions before releasing them.

Delta processing is useful only if the complete base and update sequence are reliable. Missing updates or an incomplete ownership dependency graph can leave an entity unscreened. Rebuild and reconcile the affected dataset when continuity cannot be established.

Meet reporting and retention duties independently of case closure#

31 CFR §501.603 requires initial blocking reports within 10 business days from when property becomes blocked. Assign a reporting owner and retain the legal authority, property and transaction details, and filing evidence. Check its annual blocked-property and applicable unblocking or transfer reporting provisions as well.

31 CFR §501.604 requires reports of covered rejected transactions within 10 business days. Keep rejection separate from a provider’s technical decline. Follow the applicable reporting procedure and identify the legal authority rather than using “SDN” as the entire reason.

Do not wait for a support ticket to close before tracking the legal reporting clock. Identify your own obligation even when another party is involved in the flow; do not assume its filing eliminates yours without the applicable rule and evidence.

Under current 31 CFR §501.601, covered transaction records generally must be available for examination for at least 10 years after the transaction. Records of blocked property must be retained for the period it remains blocked and at least 10 years after unblocking, subject to the rule’s provisions. Apply any longer preservation requirement where relevant.

Worked example: a seller without a direct name match#

Suppose a seller company has no direct SDN name hit, but two blocked owners each hold 25%. The ownership analysis establishes aggregate 50% ownership under the applicable rule. An empty name-search result cannot clear the company.

Before executing its queued payout, the sanctions owner determines the applicable property and transaction treatment. If the platform holds property that must be blocked, preserve that treatment and trigger the reporting process. Do not return the money to the seller, change provider, or label the event as an ordinary cancellation.

If instead an alert concerns a common name and reliable identity evidence establishes a different person, retain the false-positive rationale and reassess the actual payout conditions. These cases need different evidence and outcomes even if both first appeared as an alert in the same queue.

Keep sanctions restrictions independent of provider events#

Store the sanctions decision and restriction separately from the payment’s technical status. A provider reporting “paid” describes its transfer result; it does not remove a legal restriction. Record actual money movement accurately even if it reveals that a transfer crossed a control it should not have crossed.

If a designation or other restriction is discovered after submission, stop any further affected instructions and escalate immediately. Trace where the funds are and determine the legal and reporting response. Do not overwrite the payment as “held” if it has already moved, or assume that cancelling an internal job retrieved the funds.

Persist one durable payout instruction before dispatch. For an unknown provider result, retrieve or trace the original operation before any replacement. Routing through another provider must never bypass an active sanctions restriction.

Authenticate and durably save provider receipts before acknowledgement. Apply validated technical state and accounting changes with the processed marker and any outbound intent in one local transaction. Dispatch outbound work after commit. Keep the statutory restriction active until an authorised legal decision permits changing it; retries and duplicate events do not supply that decision.