How to Turn a Sanctions Policy Into an Operating Control

A sanctions policy can state the correct obligation and still fail in operation. It may require screening before a payment is released, prohibit dealings with blocked persons, and require escalation of potential matches. Those commitments matter, but they leave an operator without instructions at 2:17 a.m., when a payment arrives with incomplete data and the screening service returns a possible match.

The operating control begins where the policy becomes specific. It identifies the event that triggers screening, the parties and fields in scope, the lists and matching rules in force, the conditions that create a hold, the people allowed to resolve the case, and the evidence that must exist before money moves.

OFAC strongly encourages sanctions compliance programs to be risk-based, with a design that reflects the company’s size and sophistication, products and services, customers and counterparties, and geographic locations. The details therefore differ from one fintech to the next. Every design still has to connect risk to control activity, accountability, and evidence.

Take a policy requirement to screen a payment before release. Ask these questions before discussing vendors or interface design:

• Which parties, documents, transaction attributes, and data fields must be screened?
• Which sanctions programs, lists, matching rules, and configuration versions apply?
• What happens when required data is missing, the screening service is unavailable, or a potential match appears?
• Who may recommend a disposition, who may authorize it, and what evidence must support the decision?
• Can management, a sponsor bank, an auditor, or an independent tester reconstruct the event years later?

“The vendor handles that” names a dependency. The company still has to show how it controls the outcome.

OFAC describes screening that may reach customers, supply chain, intermediaries, counterparties, commercial and financial documents, and transactions. Which of those apply depends on the business and the sanctions programs at issue. A fintech should translate its risk assessment into a precise control scope before it configures a screening product.

For a payment flow, the scope might include the sender, the beneficiary, the originating and beneficiary financial institutions and their identifiers, intermediaries, geographic data, and the payment narrative. Ownership belongs in scope as well. Under OFAC’s 50 Percent Rule, an entity owned 50 percent or more, directly or indirectly, individually or in the aggregate, by one or more blocked persons is itself blocked, even when its own name appears on no list.

Scope is also where data breaks. Name fields cut short by message formats, party details pushed into free-text narrative, addresses stored as a single unstructured line, and identifiers captured upstream but never passed to the screening call all create coverage gaps that the policy cannot see. OFAC lists the failure to include pertinent identifiers, such as SWIFT Business Identifier Codes, among the root causes it has seen in sanctions violations. Map each screened field to its source system and confirm that it reaches the screening engine intact.

The control also needs timing rules. Screening before release is one trigger. Changes to customer data, list updates, changed risk, and recovery from an outage may each require rescreening. FFIEC examination guidance expects procedures for timely updating of the sanctions lists a bank screens against, and OFAC identifies failure to load SDN List updates into screening software as another recurring root cause.

Exclusions should be deliberate: supported by the risk assessment, approved by an accountable owner, and visible to testing. A quiet gap in field mapping or transaction coverage is an implementation defect, however well the policy is written.

A workable pre-release control has a simple backbone. The system receives the screening request, records the input data and active configuration, evaluates the result, and either permits the next controlled step or creates a hold and a case.

A potential match stays held while an analyst works the alert. OFAC’s published sequence runs from confirming which list produced the alert, to evaluating the match against the identifiers in the listing and gathering additional information where needed, to checking for authorizations or exemptions, to deciding whether property must be blocked or the transaction rejected, and finally to reporting and recordkeeping. OFAC notes that many screening results are false positives.

The workflow should keep the analyst’s recommendation separate from the authorized disposition, and it should make release impossible while a required decision remains open. Clearing a name alert settles one question. Ownership, jurisdiction, activity, and licensing questions may remain, and the control should resolve them before the payment proceeds, is rejected, is blocked, or moves to further escalation.

Failure conditions need the same design. Missing data, stale lists, service outages, queue backlogs, manual overrides, and configuration changes each need an owner and a defined response: what stays held, who is notified, how accumulated work is cleared, and how the exception is reviewed afterward. Backlogs deserve particular attention. In its July 2021 settlement with Payoneer, a cross-border payments company, OFAC found that during backlog periods the company allowed flagged and pended payments to be released automatically without review.

Disposition starts its own obligations. A report of blocked property is due to OFAC within 10 business days of blocking, and blocked property held as of June 30 must be reported annually by September 30. A rejected transaction must be reported within 10 business days. The workflow should record each required handoff, its owner, its due date, and the evidence that it was completed.

A status field that says “cleared” is too thin to defend a consequential decision. The record should let a reviewer understand the input, the logic applied, the information considered, the people involved, and the event that followed.

The record also has to last. OFAC’s recordkeeping rule requires records of transactions subject to its regulations to remain available for examination for at least 10 years after the transaction, and records of blocked property for as long as the property is blocked and at least 10 years after it is unblocked. OFAC extended the period from five years to ten, effective March 12, 2025. The FFIEC examination manual still states a five-year period for rejected-transaction and blocked-property records. Retention settings, archive design, and vendor contract terms should be checked against the current rule.

Bright Sea’s working design standard is to preserve the screening request and protected source data, list and rule versions, timestamps, the raw result, case and hold history, analyst rationale, the authorized disposition, and the release, rejection, blocking, or escalation event. Quality-review results, reports filed with OFAC, and corrective actions should stay connected to the same control history.

Those fields may live in different systems. That works when identifiers, access controls, retention, and change history allow the record to be reconstructed reliably. A reviewer should never have to infer a decision from screenshots, email fragments, and an analyst’s memory. Designing evidence into the control reduces audit-time reconstruction and gives the reviewer a more complete record.

One team can participate in several parts of a sanctions process, but the responsibilities should stay visible. Payment operations may confirm that screening completed and prevent release while an alert is open. Sanctions compliance may own risk interpretation, rule requirements, escalation standards, and disposition authority. A quality function may sample completed cases and trace recurring errors to their cause. Independent testing evaluates whether the design is sound and whether the control operated as designed.

FFIEC examination guidance expects a bank’s OFAC compliance program to include a risk assessment, internal controls, independent testing, a designated responsible individual, and training. The FFIEC’s BSA/AML independent-testing guidance offers a useful model for structuring the testing function: qualified testers who are independent of the function under review, a documented scope and procedures, workpapers available for examiner review, and deficiencies tracked through corrective action.

The FFIEC states that a bank using a third party to perform OFAC checks on its behalf remains ultimately responsible for that third party’s compliance. Document which party performs each step, which party owns the control outcome, which evidence each party can access, and how the responsible institution exercises oversight.

For a fintech that moves money through a partner bank, this record is the kind of evidence the bank may request during diligence and ongoing monitoring. The federal banking agencies’ 2023 interagency guidance sets out how banks are expected to manage third-party relationships, including partnerships of this kind. On September 15, 2026, the OCC, Federal Reserve, FDIC, and NCUA proposed to rescind and replace that guidance. The proposal would remove language the agencies describe as overly prescriptive for bank-fintech partnerships, and it restates that a banking organization’s use of third parties does not diminish its responsibility to comply with applicable laws and regulations. Comments are due November 16, 2026.

The practical point for the fintech holds under either version. A bank that remains accountable for sanctions compliance may seek evidence that its partner’s control works in a form the bank’s own examiners can review. A reconstructable decision record can support that request.

A walkthrough confirms that the procedure sounds coherent. Operating testing asks whether the control behaved that way. Samples should include ordinary releases, alerts, incomplete records, outages, rescreening events, configuration changes, overrides, and activity near control boundaries.

Start with transactions that completed and work backward. Confirm that screening occurred before release, the expected parties and fields were present, the correct configuration was active, and any alert had a supported and authorized disposition.

Run failure-path and detection tests in an isolated production-equivalent environment that uses a controlled replica or snapshot of the production configuration and synthetic data incapable of generating a live block, rejection, report, customer effect, or external transmission.

• Attempt release with an unresolved alert and confirm that the system keeps the payment held.
• Interrupt the screening service, restore it, and confirm that held payments are rescreened before release.
• Submit a payment with a required field missing or truncated and confirm that the control creates an exception.
• Build and clear a simulated alert backlog and confirm that no payment is released without review.
• Change customer data, load a list update, and confirm that rescreening occurs.
• Attempt a manual override with each user role and confirm that unauthorized changes fail and all attempts are logged.
• Onboard a test entity whose blocked owners hold 50 percent or more in the aggregate, and confirm that ownership review identifies it.

Those tests cover the alerts the engine produced. The engine itself needs detection testing, because a match it never flags leaves no alert to sample. Build a test set of listed names and identifiers with realistic variations: transliterations, reordered name parts, dropped or merged words, truncation, typographical errors, and identifiers such as BICs. Include weak aliases where the program has chosen to screen them. OFAC FAQ 124 states that OFAC does not require a particular screening approach and does not generally expect screening against weak aliases; weak aliases can help an organization evaluate whether a result is a valid match.

Run the set through the production configuration in the production-equivalent test environment, record which entries alert and at what score, and repeat after every threshold change, list-loading change, and vendor release. Include cases just above and just below the matching threshold so the results show where detection actually stops.

The Payoneer settlement shows why. OFAC found weak algorithms that allowed close matches to SDN List entries to go unflagged, and a failure to screen for BICs even when SDN List entries contained them. The same enforcement release pointed to algorithm testing, BIC screening, and holding flagged payments until review as lessons for other companies.

Useful metrics include unresolved alerts by age, releases attempted during holds, screening failures, records missing required data, manual overrides, detection-test misses, quality defects by cause, and time from configuration approval to verified deployment. Thresholds and reporting frequency should reflect the program’s actual risk and volume.

The strongest test follows the money and the decision record through normal activity, exceptions, and change.

The Control Evidence Map turns this method into a working artifact. Use one map per control. Record the obligation, control objective, trigger and scope, decision logic, exception path, required evidence, and assurance model, then attach the systems, owners, records, and test procedures that show each part exists.

Begin with a control that matters to a live product or bank relationship. A narrow control mapped honestly will reveal more than a broad policy summary: where scope is assumed, where authority is unclear, where evidence disappears, where an outsourced step lacks oversight, and where testing cannot reach the real transaction flow.

This article and the map describe a design method. Sanctions requirements differ by program, transaction, jurisdiction, and facts, and legal and compliance owners should identify the authorities that apply to the specific activity before approving a control.