Sanctions scope, prohibitions, and licenses

Sanctions programs can restrict dealings with named parties, certain territories, sectors, or specified activity. The applicable duties depend on the relevant legal nexus and program. An entity’s location, the involvement of U.S. persons, and other facts can matter.

Build a legal applicability map with qualified owners. The map should identify the actual entity, product, parties, route, and source rule. Avoid using a single global blocked-country table as a substitute for this analysis. It can both miss prohibited activity and reject permissible activity. Engineering needs a structured policy that states what the law requires for the defined situation.

A sanctions decision begins with the activity and the legal connection, not with a generic country score. Identify the relevant parties, institutions, currencies, goods or services, and jurisdictions. A U.S. obligation may apply through one connection while another jurisdiction imposes a separate requirement. The engineering model should be able to represent these facts without pretending that one universal screening flag resolves every legal question.

Keep the scope analysis distinct from the evidence match. A system can correctly detect a listed name and still need review to determine whether the person is the listed subject and what restriction applies. Conversely, a transaction can raise a prohibition issue that a simple name comparison would never detect. Scope and screening are complementary parts of the control.

Inside the mechanism. Start with the parties, activity, jurisdictions, and applicable program. A customer’s address alone does not establish the full legal scope of a transaction. Preserve the actual route, institutions, ownership information, and relevant dates. The control should identify which facts support the applicable determination and which remain unresolved. A generic high-risk flag is not a substitute for this scoped analysis.

A concrete example. The transaction connects customers, banks, currencies, services, and places. A legal scope analysis determines which restrictions can apply to those facts. The case identifies 2,451 eligible records from a source population of 4,300. The required workflow completes for 2,377, but 36 completed records miss the illustrative internal target. Another 74 remain incomplete. Communication evidence covers 2,353 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.

When the assumption fails. The product substitutes a country score for the activity-specific analysis. Retain parties, connections, activity, authority, and the qualified owner’s determination. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

The transaction connects customers, banks, currencies, services, and places. A legal scope analysis determines which restrictions can apply to those facts.

01Reference conditionActivity and jurisdiction map↗02Failure and stressActivity and jurisdiction map↗03Controlled responseActivity and jurisdiction map↗

Establish jurisdiction and activity — the flow

1. 01FactsIdentify parties route and activity
2. 02NexusEstablish the applicable jurisdiction
3. 03RuleMap the relevant restriction

Establish jurisdiction and activity — the distinction

Geographic restriction

• Applies to defined locations or activity

Party restriction

• Applies to identified persons or entities

Scope record

Fictional educational excerpt / Not for execution

Scope record

Illustrative data; not a real customer record or a prescribed policy.

1. 1

   Productcross-border payment

   Specific activity

2. 2

   Partiessender receiver intermediary

   Relevant actors

3. 3

   Legal basisprogram-specific

   Requires an approved interpretation

Sanctions scope is more than a country list

Establish jurisdiction and activity — control and failure modes

Control design

Use a program-specific applicability map. Sanctions scope is more than a country list.

Failure mode 1avoid

Approve from a low fraud score. Fraud probability does not override a prohibition.

Failure mode 2avoid

Block all foreign activity automatically. The rules are not a universal foreign-payment ban.

Failure mode 3avoid

Assume one jurisdiction covers every entity. Legal nexus can differ.

Screening identifies possible matches or relevant attributes. Legal disposition determines what the institution must do under the applicable restriction. A fuzzy name match is not itself a confirmed prohibited party. Equally, a lack of a name match does not prove all activity is permissible.

Use states such as candidate, under review, false match, confirmed relevant match, and resolved action. Tie each transition to evidence and authorized roles. The system should preserve the list version and matched identifiers. A reviewer must be able to explain why two similar names refer to different people without erasing the original alert.

Inside the mechanism. Detection selects a possible issue; legal disposition determines what the institution must or may do under the relevant facts and authority. Store candidate match, identity resolution, applicable restriction, and final action separately. A high name-similarity score does not itself establish that the customer is the listed party. Conversely, a weak name match does not answer ownership or activity-based restrictions. The workflow needs both identity evidence and rule-specific interpretation.

A concrete example. The matching engine generates a candidate because one record resembles another. Identity resolution and the applicable legal handling remain separate steps. The matcher returns 221 candidates from 21,500 records. It identifies 49 of 53 known fictional identity matches and misses 4. After scoped suppressions and stale-evidence returns, review demand is 178. The example keeps identity resolution, control availability, and the final legal disposition separate.

When the assumption fails. The API field potential_match is mapped directly to a final blocked state. Keep candidate, resolved identity, scope, and disposition as distinct evidence-backed states. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

The matching engine generates a candidate because one record resembles another. Identity resolution and the applicable legal handling remain separate steps.

01Reference conditionDetection before disposition↗02Failure and stressDetection before disposition↗03Controlled responseDetection before disposition↗

Separate detection from legal disposition — the flow

1. 01DetectFind a candidate match
2. 02ResolveCompare identifying evidence
3. 03DisposeApply the relevant legal action

Separate detection from legal disposition — the distinction

Candidate hit

• Possible identity or rule match

Confirmed disposition

• Evidence and policy support an action

Screening state

Fictional educational excerpt / Not for execution

Screening state

Illustrative data; not a real customer record or a prescribed policy.

1. 1

   Name similarityhigh

   Candidate evidence

2. 2

   Birth dateconflicting

   Identity distinction

3. 3

   Actionreview

   No automatic guilt conclusion

A candidate requires identity and rule analysis

Separate detection from legal disposition — control and failure modes

Control design

Separate matching from disposition. A candidate requires identity and rule analysis.

Failure mode 1avoid

Treat every fuzzy hit as a confirmed target. Similar names can identify different people.

Failure mode 2avoid

Treat no hit as full legal clearance. Other restrictions may apply.

Failure mode 3avoid

Delete false-match evidence. The resolution needs a trace.

Blocking and rejecting are different actions under sanctions rules. Blocking generally involves immobilizing property in which a blocked person has an interest, when required. Rejection concerns refusing a transaction that is prohibited but not subject to blocking under the relevant rule. Exact treatment and reporting depend on the program and facts.

The application should not offer one generic deny button for every outcome. Separate customer messaging, ledger treatment, custody, reporting, and release authority. A blocked balance cannot be treated as ordinary platform revenue or simply returned because a support agent wants to resolve a complaint.

The difference between blocking and rejection changes how funds are handled and how the customer is informed. A generic decline state is not sufficient for every disposition. The workflow needs the applicable determination, the amount and property affected, the institution holding it, required records, and any reporting or follow-up action. Engineers should obtain the approved disposition logic from qualified owners and preserve its version in the decision record. A manual override must not turn a legal restriction into an ordinary customer-service exception.

Inside the mechanism. Blocking and rejection have different effects on property and transaction processing. Model the applicable disposition explicitly rather than mapping both to declined. Keep the affected amount, currency, property interest, authority, recordkeeping, and required reporting workflow linked to the decision. Do not release or return property solely because an internal case was closed. The relevant action must follow the applicable program and facts.

A concrete example. Different applicable restrictions can require different handling of a transaction or property. A generic decline code cannot express every disposition or retained obligation. The case identifies 605 eligible records from a source population of 680. The required workflow completes for 587, but 9 completed records miss the illustrative internal target. Another 18 remain incomplete. Communication evidence covers 581 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.

When the assumption fails. The product uses the same release behavior for blocked property and rejected instructions. Implement the approved disposition with amount, property, holder, reporting, and follow-up evidence. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

Different applicable restrictions can require different handling of a transaction or property. A generic decline code cannot express every disposition or retained obligation.

01Reference conditionBlocking and rejection workflow↗02Failure and stressBlocking and rejection workflow↗03Controlled responseBlocking and rejection workflow↗

Distinguish blocking and rejection — the flow

1. 01AnalyzeIdentify the property interest and prohibition
2. 02ActUse the required block or reject treatment
3. 03RecordPreserve custody and reporting evidence

Distinguish blocking and rejection — the distinction

Block

• Immobilize property when the rule requires it

Reject

• Refuse a prohibited transaction under its applicable treatment

Disposition record

Fictional educational excerpt / Not for execution

Disposition record

Illustrative data; not a real customer record or a prescribed policy.

1. 1

   Resultblocking required

   Approved legal conclusion

2. 2

   Ledgerrestricted property

   Separate balance treatment

3. 3

   Releaseauthorized process only

   No ordinary refund path

Their legal and financial handling can differ

Distinguish blocking and rejection — control and failure modes

Control design

Model block and reject as distinct dispositions. Their legal and financial handling can differ.

Failure mode 1avoid

Use one decline state for everything. It loses custody and reporting meaning.

Failure mode 2avoid

Return blocked property on request. Release requires the appropriate authority.

Failure mode 3avoid

Recognize blocked funds as revenue. The property remains subject to restrictions.

A license can authorize activity that would otherwise be prohibited, subject to its terms. General and specific licenses have different forms and scopes. A license is not a blanket exemption for every transaction involving a party.

Capture the authority, eligible activity, parties, conditions, dates, and supporting documents. Evaluate the actual transaction against that scope. Store the interpretation and approval. If a license expires or conditions change, the control must notice before new activity relies on it. A screenshot of an old license is not a maintained authorization system.

Inside the mechanism. A license or other authorization has a scope, conditions, dates, and relevant parties or activity. Store the exact authority and the facts that make it applicable. A document attached to one case is not a permanent allowlist for every future transaction by that customer. Changes in amount, purpose, route, or ownership can require another assessment. A release record should show why this particular action was within the authorization.

A concrete example. A license or other authority can depend on parties, activity, conditions, dates, and reporting requirements. It is not an unlimited whitelist entry. The case identifies 346 eligible records from a source population of 540. The required workflow completes for 336, but 5 completed records miss the illustrative internal target. Another 10 remain incomplete. Communication evidence covers 333 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.

When the assumption fails. A prior licensed transaction is reused to approve a different activity after conditions change. Bind the authority to its exact scope, evidence, validity, and required handling. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

A license or other authority can depend on parties, activity, conditions, dates, and reporting requirements. It is not an unlimited whitelist entry.

01Reference conditionScoped license authority↗02Failure and stressScoped license authority↗03Controlled responseScoped license authority↗

Treat licenses as scoped authority — the flow

1. 01AuthorityIdentify the relevant license
2. 02ConditionsMatch activity parties and dates
3. 03EvidenceRecord the approved reliance

Treat licenses as scoped authority — the distinction

License scope

• Defined authorized activity and conditions

Blanket clearance

• An unsupported assumption of unrestricted activity

License check

Fictional educational excerpt / Not for execution

License check

Illustrative data; not a real customer record or a prescribed policy.

1. 1

   Activityspecified category

   Must match the authorization

2. 2

   Expiryrecorded

   Time condition

3. 3

   Transactionoutside scope

   Cannot rely on this license

Authority applies within its stated scope

Treat licenses as scoped authority — control and failure modes

Control design

Evaluate every relevant license condition. Authority applies within its stated scope.

Failure mode 1avoid

Treat a license as permanent clearance. Dates and conditions can limit it.

Failure mode 2avoid

Reuse another entity’s authority blindly. Party scope may differ.

Failure mode 3avoid

Skip recordkeeping once approved. Reliance needs evidence.

OFAC’s compliance framework identifies management commitment, risk assessment, internal controls, testing and auditing, and training as core program components. The specific program should fit the organization’s risk and operations.

Turn those components into owned work. Track unresolved screening gaps, list failures, overdue reviews, and training needs. Test the complete transaction path, including manual channels and exceptional releases. A sanctions control that covers only the main API can miss activity initiated through a back-office tool. Governance should surface those gaps and ensure that fixes are verified.

Inside the mechanism. A functioning program connects risk assessment, control design, data quality, staffing, training, testing, and corrective action. Test whether the required population reaches the control and whether an unresolved issue prevents an unauthorized release. List-update success is only one part of that path. Case ownership, evidence retention, and a tested response to unavailable screening are equally important operational dependencies.

A concrete example. Governance, risk assessment, internal controls, testing, and training must connect to the actual product and institution. A vendor contract alone does not perform those tasks. The case identifies 877 eligible records from a source population of 1,020. The required workflow completes for 851, but 13 completed records miss the illustrative internal target. Another 26 remain incomplete. Communication evidence covers 842 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.

When the assumption fails. A new payment feature launches without updating control ownership and coverage. Trace each affected exposure through the program and require evidence that the control works. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

Governance, risk assessment, internal controls, testing, and training must connect to the actual product and institution. A vendor contract alone does not perform those tasks.

01Reference conditionCompliance program operation↗02Failure and stressCompliance program operation↗03Controlled responseCompliance program operation↗

Operate the compliance program — the flow

1. 01CommitAssign authority and resources
2. 02ControlCover the real activity paths
3. 03TestVerify coverage and remediate gaps

Operate the compliance program — the distinction

Primary API coverage

• One route is screened

Complete channel coverage

• All relevant initiation routes are addressed

Channel audit

Fictional educational excerpt / Not for execution

Channel audit

Illustrative data; not a real customer record or a prescribed policy.

1. 1

   Public APIscreened

   Main path works

2. 2

   Back-office transfernot mapped

   Coverage gap

3. 3

   Remediationadd controlled screening

   Verify before relying on it

Manual paths can bypass the main control

Operate the compliance program — control and failure modes

Control design

Test every relevant channel and exception. Manual paths can bypass the main control.

Failure mode 1avoid

Count a policy as complete coverage. Implementation may differ.

Failure mode 2avoid

Ignore release overrides. Exceptions can carry high impact.

Failure mode 3avoid

Close gaps without retesting. The correction remains unproven.

Continue with Screening engines and match resolution to follow the next part of the system. Use the glossary for terminology and risk mathematics for formulas and worked calculations.