Unit 05 · Chapter 1 · 10 min read

Sanctions scope, prohibitions, and licenses

Translate legal restrictions into a precise control boundary.

A payment is low risk for fraud and still cannot proceed under an applicable restriction. Sanctions compliance is not a model score with a price attached. It starts with the people, activity, jurisdiction, and legal rule.

Establish jurisdiction and activity

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.

Establish jurisdiction and activity Establish jurisdiction and activity — the flow Follow the sequence. Map the relevant restriction. Facts Identify parties route and activity Nexus Establish the applicable jurisdiction Rule Map the relevant restriction — Follow the sequence. Map the relevant restriction. Chapter sources · Open image

Establish jurisdiction and activity Establish jurisdiction and activity — the distinction These concepts answer different questions. Read each definition in the context of the section. Geographic restriction Applies to defined locations or activity Party restriction Applies to identified persons or entities — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Establish jurisdiction and activity Scope record Fictional teaching record. Requires an approved interpretation. Scope record Illustrative data; not a real customer record or a prescribed policy. Product cross-border payment Specific activity Parties sender receiver intermediary Relevant actors Legal basis program-specific Requires an approved interpretation Sanctions scope is more than a country list — Fictional teaching record. Requires an approved interpretation. Chapter sources · Open image

Establish jurisdiction and activity Establish jurisdiction and activity — control and failure modes Sanctions scope is more than a country list. The branches show why alternative designs fail. Control design Use a program-specific applicability map. Sanctions scope is more than a country list. Failure mode 1 Approve from a low fraud score. Fraud probability does not override a prohibition. avoid Failure mode 2 Block all foreign activity automatically. The rules are not a universal foreign-payment ban. avoid Failure mode 3 Assume one jurisdiction covers every entity. Legal nexus can differ. avoid — Sanctions scope is more than a country list. The branches show why alternative designs fail. Chapter sources · Open image

Separate detection from legal disposition

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.

Separate detection from legal disposition Separate detection from legal disposition — the flow Follow the sequence. Apply the relevant legal action. Detect Find a candidate match Resolve Compare identifying evidence Dispose Apply the relevant legal action — Follow the sequence. Apply the relevant legal action. Chapter sources · Open image

Separate detection from legal disposition Separate detection from legal disposition — the distinction These concepts answer different questions. Read each definition in the context of the section. Candidate hit Possible identity or rule match Confirmed disposition Evidence and policy support an action — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Separate detection from legal disposition Screening state Fictional teaching record. No automatic guilt conclusion. Screening state Illustrative data; not a real customer record or a prescribed policy. Name similarity high Candidate evidence Birth date conflicting Identity distinction Action review No automatic guilt conclusion A candidate requires identity and rule analysis — Fictional teaching record. No automatic guilt conclusion. Chapter sources · Open image

Separate detection from legal disposition Separate detection from legal disposition — control and failure modes A candidate requires identity and rule analysis. The branches show why alternative designs fail. Control design Separate matching from disposition. A candidate requires identity and rule analysis. Failure mode 1 Treat every fuzzy hit as a confirmed target. Similar names can identify different people. avoid Failure mode 2 Treat no hit as full legal clearance. Other restrictions may apply. avoid Failure mode 3 Delete false-match evidence. The resolution needs a trace. avoid — A candidate requires identity and rule analysis. The branches show why alternative designs fail. Chapter sources · Open image

Distinguish blocking and rejection

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.

Distinguish blocking and rejection Distinguish blocking and rejection — the flow Follow the sequence. Preserve custody and reporting evidence. Analyze Identify the property interest and prohibition Act Use the required block or reject treatment Record Preserve custody and reporting evidence — Follow the sequence. Preserve custody and reporting evidence. Chapter sources · Open image

Distinguish blocking and rejection Distinguish blocking and rejection — the distinction These concepts answer different questions. Read each definition in the context of the section. Block Immobilize property when the rule requires it Reject Refuse a prohibited transaction under its applicable treatment — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Distinguish blocking and rejection Disposition record Fictional teaching record. No ordinary refund path. Disposition record Illustrative data; not a real customer record or a prescribed policy. Result blocking required Approved legal conclusion Ledger restricted property Separate balance treatment Release authorized process only No ordinary refund path Their legal and financial handling can differ — Fictional teaching record. No ordinary refund path. Chapter sources · Open image

Distinguish blocking and rejection Distinguish blocking and rejection — control and failure modes Their legal and financial handling can differ. The branches show why alternative designs fail. Control design Model block and reject as distinct dispositions. Their legal and financial handling can differ. Failure mode 1 Use one decline state for everything. It loses custody and reporting meaning. avoid Failure mode 2 Return blocked property on request. Release requires the appropriate authority. avoid Failure mode 3 Recognize blocked funds as revenue. The property remains subject to restrictions. avoid — Their legal and financial handling can differ. The branches show why alternative designs fail. Chapter sources · Open image

Treat licenses as scoped authority

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.

Treat licenses as scoped authority Treat licenses as scoped authority — the flow Follow the sequence. Record the approved reliance. Authority Identify the relevant license Conditions Match activity parties and dates Evidence Record the approved reliance — Follow the sequence. Record the approved reliance. Chapter sources · Open image

Treat licenses as scoped authority Treat licenses as scoped authority — the distinction These concepts answer different questions. Read each definition in the context of the section. License scope Defined authorized activity and conditions Blanket clearance An unsupported assumption of unrestricted activity — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Treat licenses as scoped authority License check Fictional teaching record. Cannot rely on this license. License check Illustrative data; not a real customer record or a prescribed policy. Activity specified category Must match the authorization Expiry recorded Time condition Transaction outside scope Cannot rely on this license Authority applies within its stated scope — Fictional teaching record. Cannot rely on this license. Chapter sources · Open image

Treat licenses as scoped authority Treat licenses as scoped authority — control and failure modes Authority applies within its stated scope. The branches show why alternative designs fail. Control design Evaluate every relevant license condition. Authority applies within its stated scope. Failure mode 1 Treat a license as permanent clearance. Dates and conditions can limit it. avoid Failure mode 2 Reuse another entity’s authority blindly. Party scope may differ. avoid Failure mode 3 Skip recordkeeping once approved. Reliance needs evidence. avoid — Authority applies within its stated scope. The branches show why alternative designs fail. Chapter sources · Open image

Operate the compliance program

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.

Operate the compliance program Operate the compliance program — the flow Follow the sequence. Verify coverage and remediate gaps. Commit Assign authority and resources Control Cover the real activity paths Test Verify coverage and remediate gaps — Follow the sequence. Verify coverage and remediate gaps. Chapter sources · Open image

Operate the compliance program Operate the compliance program — the distinction These concepts answer different questions. Read each definition in the context of the section. Primary API coverage One route is screened Complete channel coverage All relevant initiation routes are addressed — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Operate the compliance program Channel audit Fictional teaching record. Verify before relying on it. Channel audit Illustrative data; not a real customer record or a prescribed policy. Public API screened Main path works Back-office transfer not mapped Coverage gap Remediation add controlled screening Verify before relying on it Manual paths can bypass the main control — Fictional teaching record. Verify before relying on it. Chapter sources · Open image

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.

Manual paths can bypass the main control. The branches show why alternative designs fail. Chapter sources · Open image

Chapter connections

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.

Sources

Reviewed 2026-09-17