Sanctions scope, prohibitions, and licenses
Translate legal restrictions into a precise control boundary.
Build the legal boundary first
Enlarge to read every label and explore the connections
Sanctions analysis links parties, activity, and legal nexus to the applicable rule. A favorable risk score cannot resolve a restriction.
Identify parties, activity, and legal nexus.
Apply the rule and any valid license conditions.
Keep legal disposition separate from fraud scoring.
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
- FactsIdentify parties route and activity
- NexusEstablish the applicable jurisdiction
- RuleMap the relevant restriction
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.
The transaction connects customers, banks, currencies, services, and places. A legal scope analysis determines which restrictions can apply to those facts.
- Geographic restriction
- Applies to defined locations or activity
- Party restriction
- Applies to identified persons or entities
Scope record
Illustrative data; not a real customer record or a prescribed policy.
- Productcross-border payment
Specific activity
- Partiessender receiver intermediary
Relevant actors
- Legal basisprogram-specific
Requires an approved interpretation
Sanctions scope is more than a country list
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.
Separate detection from legal disposition
- DetectFind a candidate match
- ResolveCompare identifying evidence
- DisposeApply the relevant legal action
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.
The matching engine generates a candidate because one record resembles another. Identity resolution and the applicable legal handling remain separate steps.
- Candidate hit
- Possible identity or rule match
- Confirmed disposition
- Evidence and policy support an action
Screening state
Illustrative data; not a real customer record or a prescribed policy.
- Name similarityhigh
Candidate evidence
- Birth dateconflicting
Identity distinction
- Actionreview
No automatic guilt conclusion
A candidate requires identity and rule analysis
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.
Distinguish blocking and rejection
- AnalyzeIdentify the property interest and prohibition
- ActUse the required block or reject treatment
- RecordPreserve custody and reporting evidence
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.
Different applicable restrictions can require different handling of a transaction or property. A generic decline code cannot express every disposition or retained obligation.
- Block
- Immobilize property when the rule requires it
- Reject
- Refuse a prohibited transaction under its applicable treatment
Disposition record
Illustrative data; not a real customer record or a prescribed policy.
- Resultblocking required
Approved legal conclusion
- Ledgerrestricted property
Separate balance treatment
- Releaseauthorized process only
No ordinary refund path
Their legal and financial handling can differ
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.
Treat licenses as scoped authority
- AuthorityIdentify the relevant license
- ConditionsMatch activity parties and dates
- EvidenceRecord the approved reliance
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.
A license or other authority can depend on parties, activity, conditions, dates, and reporting requirements. It is not an unlimited whitelist entry.
- License scope
- Defined authorized activity and conditions
- Blanket clearance
- An unsupported assumption of unrestricted activity
License check
Illustrative data; not a real customer record or a prescribed policy.
- Activityspecified category
Must match the authorization
- Expiryrecorded
Time condition
- Transactionoutside scope
Cannot rely on this license
Authority applies within its stated scope
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.
Operate the compliance program
- CommitAssign authority and resources
- ControlCover the real activity paths
- TestVerify coverage and remediate gaps
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.
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.
- Primary API coverage
- One route is screened
- Complete channel coverage
- All relevant initiation routes are addressed
Channel audit
Illustrative data; not a real customer record or a prescribed policy.
- Public APIscreened
Main path works
- Back-office transfernot mapped
Coverage gap
- Remediationadd controlled screening
Verify before relying on it
Manual paths can bypass the main control
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.
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.