A mid-sized payments firm processes thousands of transactions daily across a dozen currencies. Its compliance team runs each instruction through a screening engine. One morning, an alert fires: the originating bank sits in a jurisdiction that a recent programme update brought into scope. The operations desk waits. Legal is phoned. The clock runs. That scenario – the real cost of an under-built payment-processing control – is where this guide begins.
As of August 2026, OFAC requires any US person, and any person transacting in US dollars through a US correspondent bank, to screen payments against its sanctions lists, block or reject prohibited transactions, and report blocked property within a short statutory window. The obligation is strict-liability: a payment firm that processes a prohibited transfer may face a civil penalty even without knowledge that the counterparty was sanctioned. This guide sets out the steps to build and operate a compliant payment-processing control programme under OFAC, with reference to how the UK and EU regimes impose parallel – and sometimes diverging – obligations.
The guide moves through seven steps: establishing the legal basis, mapping your payment flows, configuring screening, handling alerts, managing blocks and rejects, reporting and record-keeping, and testing the programme. Each step pairs the OFAC position with at least one cross-regime comparator.
Step 1: Understand who OFAC's payment-processing rules reach
OFAC's prohibitions bind US persons wherever they are located, and they bind any person – regardless of nationality – who routes a US-dollar payment through a US correspondent bank or who touches US financial infrastructure. That extraterritorial reach is the first thing a cross-border payments business must accept before it designs any control.
The governing authority is OFAC, which administers economic-sanctions programmes under IEEPA and related statutes. The relevant prohibitions arise in programme-specific regulations that vary by the sanctioned regime in play. What remains consistent across all programmes is the core structure: US persons and US-dollar correspondent clearing are within scope; non-US persons transacting entirely outside the US financial system occupy a narrower – but not risk-free – position.
Why does this matter for a European or Asian payments business? Because a single leg of a multi-currency chain that clears through a US bank pulls the entire transaction into OFAC's orbit. We regularly advise non-US payment firms that discover, mid-integration, that their dollar-corridor exposure is broader than their legal team assumed. Mapping that reach is not optional; it is the precondition for every control that follows.
The UK equivalent – OFSI, administering financial sanctions under SAMLA and programme-specific regulations – applies to UK persons and to conduct within the UK. The EU's Council regulations apply to EU persons and to conduct within EU territory. Neither has the same correspondent-bank hook as OFAC, but both impose independent obligations. A payments business operating across the Atlantic or across the Channel must comply with each independently; satisfaction of OFAC's rules does not discharge OFSI's.
Step 2: Map your payment flows and exposure points
Before configuring a single screening rule, map every payment flow the business touches – originator, beneficiary, correspondent banks, intermediaries, and the currency and clearing system used for each corridor. Without that map, a firm cannot know which sanctions programmes are in scope and which screening fields are relevant to each flow.
The mapping exercise should produce a corridor-by-corridor inventory: for each payment product, record (a) whether any leg clears in US dollars; (b) the domicile of the originating and receiving institutions; (c) the populations of payers and payees the product serves; and (d) any embedded payment-message fields – SWIFT, ISO 20022, ACH – that carry party data. Each of those fields is a potential screening surface.
A practical point our practice returns to repeatedly: the mapping is not a one-time exercise. Payment products evolve. New corridors open. A firm that mapped its flows two years ago and has since added a real-time-payment rail into a new market needs to re-run the exercise for the new product before launch, not after its first alert.
The cross-regime angle matters here too. If the same underlying payment also routes through a UK bank or involves an EU-domiciled entity, the OFSI and EU screening obligations layer on top. The asset-freeze tests under OFSI and the Council regulations are triggered by different lists and, in some cases, different ownership-and-control determinations. A compliant OFAC map does not automatically cover the UK or EU exposure.
Step 3: Configure screening to cover the right fields
Effective payment-screening matches party data in the payment message against OFAC's SDN List (OFAC's list of Specially Designated Nationals and blocked persons), its non-SDN lists, and – where the payment corridor brings other programmes into scope – the OFSI Consolidated List and the EU Consolidated List. The configuration question is not just which list, but which fields, with what fuzzy-match settings, and at which point in the payment cycle.
Field coverage is where firms most often under-build. The originator and beneficiary fields are obvious. Less obvious are: the originating bank's country code, any reference or remittance information that might contain a party name, the ultimate-beneficial-owner data carried in enhanced SWIFT messaging, and – for ISO 20022 payments – the richer structured fields the standard makes available. A screening configuration that ignores those additional fields may pass a transaction that a more thorough review would have stopped.
Fuzzy-match thresholds require deliberate tuning. Set the threshold too high and the tool misses transliterated names or names with variant spellings. Set it too low and the alert queue drowns the operations team in false positives, creating pressure to clear alerts quickly and increasing the risk that a true match slips through. In our experience, the right threshold is programme-specific and corridor-specific; a global default is rarely correct.
The screening tool must be updated whenever OFAC updates its lists. OFAC updates can occur at any time, without notice. A firm that updates its lists weekly – rather than in near-real-time – carries a gap risk during the interval. The same applies to OFSI and EU list updates, which are independently timed and may not coincide with OFAC updates.
How does OFAC differ from other regimes on payment holds and blocks?
When a US person or a US-dollar correspondent bank identifies a payment that appears to involve a blocked party, OFAC requires the funds to be blocked – frozen in a segregated, interest-bearing account – rather than simply returned. That block-not-return requirement is specific to OFAC and differs materially from the approach under OFSI and most EU-programme regulations, where an asset freeze does not automatically mean the funds must be held by the processing firm on an ongoing basis in the same manner.
Under OFAC, a blocked payment must be reported to OFAC within 10 business days of the blocking. Annual reports on blocked property are also required. These are hard deadlines; missing them is itself a potential violation. A payments firm that simply returns a suspect payment to the sender – without first determining whether OFAC blocking is required – may have committed a violation: the act of returning can itself constitute an unauthorised transaction.
The reject category is separate. OFAC's rules permit rejection of certain payments that are not required to be blocked – for example, payments involving a country-programme prohibition where no US-person or US-property nexus triggers the block requirement. Rejected payments may be returned, but the firm must document the basis for rejection rather than blocking.
Under OFSI, the required response to a hit is an asset freeze and prompt reporting to OFSI. The reporting window under OFSI's regime is not identical to OFAC's 10-business-day deadline; firms operating under both regimes need parallel reporting tracks with separately managed timelines. The EU programme regulations similarly impose independent freeze obligations and reporting duties to competent authorities in the member state concerned. Cross-regime payment operations require a response matrix – documented in advance – that maps the alert type to the correct action under each regime, so that the operations team is not improvising at the point a real hit appears.
Step 5: Build and document the alert-review workflow
A screening system that generates alerts but has no structured review workflow is not a control; it is a risk register waiting to produce a violation. The alert-review workflow must answer four questions before a payment is either released or escalated: Does the match candidate correspond to a listed person or blocked entity? Does the payment have any nexus – US dollar, US correspondent, US person – that makes OFAC the governing authority? Is the match a true positive or a false positive? And if it is a true positive, what is the required action – block, reject, or hold pending a licence?
Each question should map to a documented decision step with a named role responsible for it. First-line operations teams typically handle false-positive clearance against a pre-approved negative-match library. True positives – or alerts that cannot be cleared at first line within a defined time – escalate to a sanctions specialist or counsel. The escalation trigger, the time allowed at first line, and the holding instruction for the payment during review must all be defined in writing before the workflow goes live.
Document every alert, every decision, and every release or block. OFAC expects firms to be able to demonstrate, on examination, that each alert was reviewed and that each release decision had a documented basis. That documentation is also the evidence base for any voluntary self-disclosure if a later review reveals an error. We have acted for payment firms in post-incident reviews where adequate contemporaneous documentation of the alert process materially changed the enforcement outcome; the absence of documentation, conversely, is itself an aggravating factor in OFAC's penalty analysis.
The position above covers the standard case. Your facts – the corridor, the payment message format, the composition of your customer base, and the regimes in play – change the analysis. If your alert workflow is untested or undocumented, that gap is addressable now.
To discuss a review of your alert-management process, contact Calder & Vance at info@caldervance.com.
Step 6: Manage reporting, record-keeping, and the annual cycle
OFAC's reporting obligations have two streams: the initial report of blocked property within 10 business days, and the annual report of all property that remains blocked as of 30 June each year, filed by 30 September. Both are mandatory. A firm that blocks funds and then fails to file either report has compounded the original alert into two separate compliance failures.
Record-keeping under the relevant OFAC programme regulations generally requires that transaction records, licence records, and blocking records be retained for five years. That retention period runs from the date of the transaction or the date of the blocking, not from the date of a regulatory inquiry. Payment firms with high transaction volumes need a records-management system that can retrieve a specific payment record on demand within the retention window; an informal email archive does not meet that standard.
The cross-regime comparison is useful here. OFSI's reporting duties are triggered by knowledge or reasonable grounds to know that a frozen asset is held; the firm must report to OFSI promptly and provide specified information about the asset. EU competent authorities similarly require notification. The timelines and the information required differ. A payment firm operating across all three regimes should maintain a compliance calendar that tracks each reporting deadline independently and assigns ownership of each filing.
Annual reviews of the overall programme are also expected. That means reviewing screening configurations against any list changes or programme updates that occurred during the year, re-assessing the fuzzy-match thresholds against the alert data from the period, and confirming that new products or corridors launched during the year were brought into scope before going live. An annual review is not a substitute for real-time monitoring; it is the mechanism for catching systemic drift that real-time monitoring does not surface.
If a transaction has already been flagged, or a filing has been refused, early advice can preserve options that narrow with time. Contact Calder & Vance at info@caldervance.com to discuss the position.
Step 7: Test the programme – and know when to involve counsel
A payment-processing control programme that has never been tested is an assertion, not a control. Testing takes three forms: technical testing of the screening engine against a set of known SDN names and variant spellings; process testing of the alert-review workflow through simulated alerts; and periodic independent review of the programme design against the current OFAC requirements and enforcement posture.
Technical testing should be run at implementation, after any material change to the screening configuration, and at least annually. The test set should include: exact-name matches, transliterated names, names with diacritics removed, common misspellings, and aliases drawn from the SDN record. If the tool misses names that a well-calibrated engine should catch, the configuration needs adjustment before the next live cycle.
Process testing – sometimes called a transaction-monitoring drill – runs a scenario through the workflow from alert generation to the point of decision. The drill reveals whether the escalation path works in practice, whether the time allowed at first line is realistic, and whether the operations team understands the block-versus-reject distinction. Gaps identified in a drill can be corrected without regulatory consequence; gaps identified in an enforcement review cannot.
When should a payments firm involve external sanctions counsel? The clearest triggers are: a true-positive alert that requires a block; a transaction that falls in a grey area between block and reject; a disclosure obligation that has not been discharged within the reporting window; any indication that a prior release decision may have been incorrect; and any communication from OFAC or a correspondent bank that references a potential violation. In our experience, the cost of early involvement – scoping the exposure, assessing disclosure options, preparing the response – is significantly lower than the cost of managing a matter that has escalated because no action was taken promptly.
Is your programme designed to the current OFAC standard? Testing it now, under controlled conditions, is the lowest-cost way to find out.
Related practices
- Compliance audit and testing – independent review of screening logic and programme design against the applicable regime standard.
- Payment-processing controls: advanced scenarios – correspondent banking, crypto rails, and multi-regime exposure in complex payment chains.
- Payment-processing controls: licensing and enforcement – specific-licence applications, voluntary self-disclosure, and penalty-mitigation strategy.