General and Specific License Handling

A sanctions licence does not remove sanctions. It creates a defined legal permission to carry out activity that would otherwise be prohibited, usually subject to scope, conditions, dates, reporting, recordkeeping and sometimes value or counterparty limitations. For a bank, licence handling is therefore not a document-upload task. It is a control lifecycle.

The operational challenge is that licensing terminology differs by jurisdiction. The United States Office of Foreign Assets Control distinguishes general licences, which publicly authorise categories of transactions and are generally self-executing for persons who meet their terms, from specific licences, which are issued to particular applicants for particular transactions or activities. In the United Kingdom, OFSI can issue general licences and specific licences under the relevant sanctions regulations. In the European Union, the language often centres on derogations, exemptions and authorisations administered by Member State competent authorities. These concepts can be similar in function but should not be treated as legally identical.

The bank must therefore answer more than “is there a licence?” It must determine which authority issued it, which sanctions regime it belongs to, which parties and activities it covers, the period for which it is valid, what conditions apply, whether the bank itself can rely on it, what reporting is required, what evidence must be retained, whether another prohibition remains applicable, and what happens when it expires or changes.

A static whitelist is not a licence-management system.

Why licences exist

Sanctions regimes frequently contain mechanisms that permit activity for policy reasons even when a broader prohibition exists. Examples can include humanitarian activity, basic needs, legal services, diplomatic functions, wind-down transactions, insolvency administration, civil nuclear activity, certain energy transactions, maintenance of frozen assets or other purposes identified by the competent authority.

The availability of a licence does not mean the transaction is low risk. It means a competent authority has created a legal route for activity that otherwise falls within a prohibition, subject to the licence terms.

The bank should therefore treat a licence as a controlled legal object. It has issuer, legal basis, scope, conditions and lifecycle. It should not be stored as a free-text note saying “legal approved.”

The system should also distinguish a licence from an exception written directly into legislation. An exception may operate automatically by law if its conditions are met. A general licence is a separate authorisation issued under licensing powers. A specific licence is individualised. EU derogations and authorisations can use different statutory structures. Legal teams should define the terminology used for each regime.

OFAC general licences

OFAC describes a general licence as authorising certain categories of transactions that would otherwise be prohibited under a particular sanctions programme. General licences are public and generally self-executing: a person who determines that the transaction meets the licence terms does not need separate OFAC approval.

This does not mean a bank can rely on the licence based only on its title. The bank must confirm that the transaction falls within scope. Conditions can relate to parties, transaction type, dates, sectors, reporting, recordkeeping or excluded activities.

Some general licences appear in regulations; others are published on the relevant sanctions-programme page. They can be amended, extended, superseded or revoked. The control therefore needs version and effective-date management.

If the bank relied on General Licence version A for a payment on one date and version B applies later, the case history should preserve which version supported the decision.

OFAC specific licences

OFAC describes a specific licence as a non-public document issued to a particular individual or entity authorising a particular transaction or activity in response to an application. The bank may be asked to process activity under a customer’s or another party’s specific licence.

The institution should not assume that possession of a PDF is enough. It should validate authenticity through approved processes, confirm that the licence covers the relevant transaction and parties, review conditions and determine whether the bank is authorised to act under it.

A specific licence can contain information that should be access-controlled. Case management should retain appropriate evidence without exposing sensitive licensing documents to staff who do not need them.

The bank should also track whether amendments, replacements or extensions have been issued.

OFSI general licences

OFSI can issue general licences under UK sanctions legislation. These permit specified activities without requiring every person to obtain an individual specific licence, provided the terms and conditions are met.

Current UK practice demonstrates why licence tracking must be dynamic. OFSI has issued and amended general licences in 2026 for matters including legal services, maritime insurance wind-down, interdiction, Kazakh oil exports and other activities. Some licences have been extended, amended or given additional reporting conditions after initial publication.

A bank relying on a UK general licence should therefore identify the licence number, relevant regulation, permitted activity, covered persons, conditions, reporting duties and expiry date. It should subscribe to or otherwise monitor official updates.

An old copy saved to a shared drive is not enough for live decisioning.

UK specific licensing

A person may apply to OFSI for a specific licence where a relevant licensing ground exists under the applicable regulations. A bank processing activity under a specific licence should confirm that the authorisation covers the intended action and that conditions are satisfied.

Licensing grounds vary by sanctions regime. The fact that one UK regime allows a licence for a particular purpose does not mean every regime has the same ground.

The legal team should map the licence to the relevant regulation and activity. Operations should not need to interpret the legislation independently from the payment queue.

The case should retain the authority’s licence reference and any conditions relevant to the bank.

EU authorisations and derogations

EU restrictive measures are implemented through EU legal acts, with national competent authorities playing important roles in authorisations and enforcement. Depending on the regulation, certain otherwise prohibited activities may be permitted through derogations, exemptions or authorisations.

A global sanctions platform should not rename every EU permission “general licence” merely because that term is familiar from OFAC or OFSI. The data model can have a generic object such as sanctionsPermission, but the displayed legal type should reflect the issuing framework.

The bank should capture competent authority, legal provision, covered activity, parties, conditions, dates and reporting.

For cross-border banking groups, a permission granted by one authority should not automatically be assumed to authorise another legal entity unless the legal framework says so.

Licence versus exemption

An exemption is usually an activity that the law itself excludes from a prohibition when conditions are satisfied. A licence or authorisation is permission granted under a legal power.

This distinction matters because the evidence and process can differ. An exempt activity may not require an application, but the bank may still need to demonstrate that the conditions were met. A specific licence may require an authority-issued document.

System requirements should therefore allow exception/exemption, general licence, specific licence, authorisation/derogation, and internal policy exception to be separate concepts.

An internal policy exception is not a government sanctions licence. This distinction must be explicit.

The licence object

A mature data model should store at least: issuing authority; jurisdiction; sanctions programme; legal basis; licence type; reference number; publication or issue date; effective date; expiry date; covered persons; permitted activity; prohibited or excluded activity; geographic scope; value/currency limits if applicable; reporting obligations; recordkeeping requirements; conditions; amendment history; responsible owner; legal interpretation; and evidence.

Not every licence uses every field. The model should be flexible enough to represent different regimes without losing precision.

The licence should also have lifecycle states such as DRAFT_REVIEW, VALIDATED, ACTIVE, SUSPENDED, EXPIRED, SUPERSEDED and REVOKED, with policy-defined meanings.

A licence should never remain operationally active simply because its document still exists.

Who can rely on the licence?

This is one of the most important questions. Some permissions are available broadly to persons who meet conditions. Others are issued to named applicants. A licence may authorise the customer, the bank, another intermediary or a combination of parties.

The bank should determine whether its own activity is authorised. A customer may have permission to make a payment, but the bank providing a separate prohibited service may need its own authorisation depending on the legal framework.

Conversely, some licences expressly cover payment processing or financial institutions facilitating the permitted activity.

The legal interpretation should be documented so operations are not left guessing.

Scope of activity

A licence can be narrow. It may permit payment of legal fees but not unrelated expenses. It may allow wind-down activity until a date. It may permit certain transactions involving specified entities but exclude others. It may allow maintenance of an asset without permitting transfer to a designated person.

Payment purpose therefore matters. A beneficiary name alone cannot determine licence coverage.

The bank should map permitted activity to transaction purpose and evidence. Where the purpose is unclear, a request for information may be required.

Controls should also consider indirect activity. A licence that permits one payment leg may not automatically authorise downstream use.

Parties

Licence scope may name designated persons, subsidiaries, service providers or categories of persons. The bank should resolve the identity of the parties involved and compare them with the licence.

Ownership and control can affect whether a company is within scope. The relevant legal rule should be applied.

Aliases, successor entities and reorganisations can create complexity. A legal review may be required if the entity in the payment does not exactly match the licence wording.

Do not use fuzzy matching alone to decide legal licence coverage.

Dates and time

Licence dates are operational controls. Effective date and expiry date should be machine-readable and tested against the transaction event relevant under the legal framework.

A payment initiated before expiry but settling after expiry can require legal analysis. A licence may permit wind-down until a specific time. Time zones can matter.

The platform should therefore store timestamps, not only dates, where the licence uses precise times.

Automatic expiry should trigger alerts, disable related rules and require review of queued or scheduled transactions.

Amendments and supersession

Authorities can amend licences to change scope, extend expiry or introduce reporting requirements. The bank should treat each version as effective-dated legal content.

A superseded licence should remain visible historically but should not drive new decisions.

If a condition changes, the bank may need to review transactions already planned but not yet executed.

Change management should document who assessed the amendment, which controls were changed, when they became effective and how testing was performed.

Reporting requirements

General and specific licences can impose reporting obligations. The user of the licence may need to report transactions, maintain records, notify an authority or submit information within a stated period.

The bank should identify who owns each report. It should not assume the customer will report if the licence places a duty on the bank.

Reporting fields can include authority, report type, trigger event, due date, covered transactions, submission date, reference and evidence.

A licence is not fully implemented if payments are permitted but mandatory reporting is forgotten.

Recordkeeping

Authorities can require records to be retained for specified periods. Even where the licence does not contain a special retention rule, normal sanctions and regulatory recordkeeping may apply.

The bank should retain the licence version, legal analysis, transaction evidence, customer information, approvals, reports and final payment state.

A later regulator should be able to reconstruct why the bank believed the transaction was authorised.

Screenshots of a webpage without version or date are weak evidence.

Conditions

Conditions are the heart of licence controls. A licence may require that funds be paid into a frozen account, that transactions stay below a cap, that certain entities are excluded, that a service occurs before a deadline, or that records and reports be maintained.

Conditions should be converted into structured controls where possible. If a condition is manual, the case should clearly prompt the analyst.

The bank should distinguish mandatory conditions from internal risk controls. Both may be important, but they are not the same legal category.

Failure to meet a condition can mean the activity was not authorised.

Value and currency limits

Some licences can contain monetary or transactional limits. The bank must determine whether limits apply per transaction, in aggregate, over a period, per person or under another definition.

A simple per-payment check can fail if the legal limit is cumulative.

The platform may need a licence-usage ledger that records authorised value consumed and remaining capacity.

Currency conversion rules should be documented if the licence uses one currency but the payment is made in another.

Licence usage ledger

For repeatable permissions, a usage ledger can be valuable. It can link each transaction to the licence, amount, currency, date, covered person, purpose and analyst or automated approval.

This provides evidence and supports aggregate conditions.

The ledger should handle returns and reversals carefully. A returned payment may not automatically restore licence capacity unless the legal interpretation supports it.

Audit controls should reconcile licence usage to actual booked transactions.

Whitelists

Whitelists are an operational tool that can suppress screening alerts for known authorised activity. They are not legal permissions.

A whitelist entry should reference the licence or legal basis, scope, identifiers, expiry and owner. It should be as narrow as possible.

Permanent whitelisting of a designated person because “they have a licence” is dangerous. The licence may cover only a particular activity and period.

Whitelist expiry should be automatic and aligned with the permission lifecycle.

Screening and licences

Screening should still identify the sanctioned party even when a licence may authorise the transaction. Suppressing the underlying match can destroy auditability.

A better design is: detect the match, resolve identity, determine legal restriction, evaluate licence, then permit or prohibit the transaction.

The case can then show that the transaction involved a designated person but was authorised under a valid permission.

This is more transparent than pretending the person was not sanctioned.

Payment holds

When a payment involving a potentially licensed activity triggers sanctions controls, the bank may hold it temporarily while licence scope is verified. That hold is operational and should not be confused with a legal freeze.

The payment status should record start time, reason, analyst and final disposition.

If the licence is confirmed, the payment can be released subject to conditions. If not, the legal action depends on the applicable sanctions rule.

The bank should have service-level expectations for time-sensitive licensed payments, particularly humanitarian or legally sensitive activity.

Humanitarian transactions

Humanitarian activity is a major area where exemptions, general licences and authorisations can be important. Sanctions programmes increasingly include frameworks intended to protect legitimate humanitarian assistance.

The bank should not create a blanket rule that all humanitarian payments are automatically permitted or automatically prohibited. It must identify the applicable legal provision and conditions.

At the same time, controls should avoid unnecessary barriers when the activity is clearly authorised. Poorly designed sanctions controls can delay aid and create serious harm.

Specialist queues and pre-validated programme information can improve both compliance and speed.

Legal services

Payment for legal services is another common licensed category. Current OFSI practice includes a legal-services general licence under UK autonomous sanctions regimes subject to scope and fee conditions.

Banks should confirm the legal-service provider, designated person or group, permitted fees and expenses, dates, caps and reporting requirements where applicable.

A payment described as “legal fees” is not sufficient evidence on its own.

The bank should preserve invoice or engagement evidence according to risk and legal requirements.

Wind-down permissions

When a person is designated, authorities can issue licences permitting orderly wind-down of existing relationships or contracts for a limited period.

These licences are time-sensitive. The purpose is usually to exit or conclude specified activity rather than begin new business.

The bank should distinguish pre-existing obligations from new transactions and monitor the expiry closely.

A wind-down licence should not become a route for continued ordinary business after the authorised period.

Insolvency and restructuring

Insolvency can create complex sanctions questions because administrators, creditors and designated persons may have legal interests in assets.

Authorities can issue permissions for insolvency-related payments and activities. The bank should understand the role of the insolvency practitioner, court orders, frozen property and licence terms.

Operational urgency does not remove sanctions obligations.

Case management should link the licence to the relevant legal process and assets.

Energy and maritime licences

Energy and maritime sanctions can involve temporary or conditional licences for transactions such as oil supply, insurance wind-down, civil nuclear activity or specific transport arrangements.

These permissions can require information about commodity, vessel, port, price, contract date or end-user in addition to party screening.

The bank should therefore connect licence management to trade and maritime data where relevant.

A payment engine alone may not have enough context.

Civil nuclear permissions

OFAC has used general licences to authorise certain transactions related to civil nuclear energy under Russia-related sanctions, subject to defined scope. This illustrates an important concept: a sector can be sanctions-sensitive while particular activity is explicitly authorised.

Banks should not infer that every nuclear-related payment is prohibited or that every civil-nuclear licence covers all energy activity.

The exact licence wording controls.

Where technical purpose is unclear, specialist review may be necessary.

Specific licence authenticity

A bank should have an approved process for receiving and validating specific licences. Depending on authority and available methods, this can include verifying reference details, checking secure official correspondence, consulting legal teams or contacting the authority through established channels.

Analysts should be alert to altered or incomplete documents but should not become forensic-document experts without training.

The validation result should be recorded.

Customer-provided screenshots should not automatically become trusted legal evidence.

Relationship to AML

A licensed sanctions transaction can still present AML risk. Permission to transact under sanctions does not establish legitimate source of funds, economic purpose or absence of criminal proceeds.

Conversely, an AML case closure does not authorise a sanctions-prohibited transaction.

The two decision streams can share evidence but need separate outcomes.

Case systems should avoid one COMPLIANCE_APPROVED status that hides which discipline actually approved what.

Relationship to fraud

Fraud controls can also apply. A fraudster could submit a fake licence or impersonate a law firm. Sanctions authorisation does not waive authentication or payment-security controls.

Operational orchestration should allow fraud, sanctions and AML decisions to coexist.

If one control blocks the payment, the final customer outcome should reflect the governing reason without unnecessarily exposing protected information.

The audit trail should preserve all relevant decisions.

Relationship to export controls

A sanctions licence may not authorise export-controlled goods. A trade or export licence may not authorise dealing with a sanctioned person.

Banks should avoid assuming that one authority’s permission resolves every legal restriction.

Where a transaction involves sensitive goods, the customer may need separate export authorisation. The bank may require evidence depending on risk and policy.

The case should identify each legal permission separately.

Scenario: general licence with conditions

A payment involves a designated entity but falls within a current OFAC general licence for specified activity. The bank confirms the licence is active, the entity and transaction type are covered, excluded activities are absent and reporting conditions are understood.

The payment can then be processed if all other applicable controls are satisfied. The case should still retain the sanctions match and licence basis.

If the payment falls outside the permitted category, the existence of the general licence does not help.

This is why the licence title is not enough.

Scenario: specific licence issued to customer

A corporate customer provides an OFAC specific licence authorising payment to a blocked entity for a defined contract. The bank should validate the licence, confirm parties and activity, review dates and conditions and determine whether financial institutions are authorised to process the payment.

If the customer changes beneficiary or contract purpose, the bank should not assume the old licence still applies.

The specific licence should be linked to the transaction in the case system.

Usage should be monitored if the licence authorises multiple transactions.

Scenario: licence expires overnight

A batch contains several scheduled payments under a general licence expiring at midnight in the relevant time zone. Some are initiated before expiry but expected to settle after.

The bank should have legal interpretation for the relevant action time and should not rely on a simple file-creation timestamp.

Transactions that cannot be completed within the authorised period may need to be stopped or escalated.

The system should trigger expiry before the deadline, not discover it after settlement.

Scenario: licence amended with reporting condition

An OFSI general licence is extended and a new reporting requirement is introduced. Existing payment rules continue to permit activity.

If the bank updates only the expiry date but not the reporting workflow, it has implemented the amendment incompletely.

Change management should compare versions, identify changed obligations, update systems and procedures, test and communicate the change.

This example demonstrates why licence ingestion needs obligation-level analysis.

Scenario: partial scope

A specific licence covers payment of professional fees but not reimbursement of unrelated business expenses. The customer sends one combined payment.

The bank should determine whether the transaction can be separated, whether the licence covers all components or whether further authorisation is required.

A payment description saying “fees and expenses” is insufficient if the licence conditions are more specific.

The decision should be based on evidence.

Scenario: multiple legal entities

A banking group has a customer relationship in the UK, payment processing in an EU entity and USD clearing through a U.S. correspondent. The customer has a UK specific licence.

The group should not assume the UK licence resolves U.S. or EU restrictions. Each relevant legal entity and payment leg requires applicable sanctions analysis.

The architecture should make the legal-entity path visible.

Global policy can coordinate the case but cannot erase jurisdictional boundaries.

Scenario: expired whitelist

A designated law-firm client was placed on a whitelist linked to a legal-services general licence. The licence expires, but the whitelist remains active and a payment passes without alert.

This is a control failure. Whitelist lifecycle should be linked automatically to the licence’s effective dates and changes.

A lookback may be required depending on exposure.

The incident should be analysed for systemic remediation.

Scenario: licence revoked or superseded

An authority revokes a licence or publishes a replacement. The bank must identify affected customers, queued transactions, standing instructions and whitelist entries.

A controlled update should deactivate the old permission and activate the new one at the correct time.

Historical transactions should continue to show the licence that was valid at the time.

Do not delete the old record.

Licence repository

A central licence repository can help a global bank manage official permissions and customer-specific licences. It should have ownership, access controls, legal review, version management and effective dates.

The repository should not be open for any user to upload a document and mark it active.

Different licence types may need different validation workflows.

The repository should provide structured data to screening, payment, trade and case systems.

Integration with payment systems

Payment systems need enough information to know whether a licence may apply. They do not necessarily need the entire licence document.

A service can return: licence candidate, coverage status, conditions requiring review, expiry and decision reference. High-risk cases can route to manual review.

The payment system should record which permission was used and its version.

If the licence service is unavailable, fail-safe behaviour should be defined according to risk and legal requirements.

Integration with customer screening

A customer can remain sanctions-relevant even if certain transactions are licensed. Screening should continue to detect changes in designations and ownership.

A licence should not permanently suppress customer screening.

If ownership changes, licence scope may need reassessment.

The customer profile should show active permissions without implying full sanctions clearance.

Integration with trade finance

Trade-finance cases often have enough data to assess licence conditions related to goods, vessel, contract, ports or transaction date.

The licence object should be linked to the trade case and amendments. If the underlying transaction changes, coverage should be re-evaluated.

The system should prevent users from manually copying a licence reference into a new trade deal without validation.

Reuse should follow defined rules.

Licence conditions as rules

Some conditions can be automated. Examples include date, value, currency, beneficiary, transaction type or named entity. Others require judgement, such as whether an activity is “ordinarily incident and necessary” or falls within a particular legal purpose.

The bank should automate objective conditions where reliable and route interpretive conditions to trained staff.

Automating legal judgement poorly can create false confidence.

Each rule should trace back to the licence text and legal interpretation.

Change management

Licences can be issued with little notice. Sanctions teams need a process from official publication to legal analysis, data entry, system configuration, testing and operational communication.

High-risk changes should have four-eye review. Emergency changes may use expedited governance but should still preserve evidence.

The bank should record when the official update was published, when it was received, when legal interpretation was approved, when production systems changed and when testing completed.

This creates a measurable implementation timeline.

Testing

Test cases should cover valid general licence, invalid scope, expired licence, future-dated licence, amended conditions, revoked licence, specific licence for wrong party, cumulative cap, reporting trigger, currency conversion, return, reversal and transaction split across multiple payments.

Testing should also verify that sanctions matches are not hidden when a licence applies.

Historical reconstruction should show the correct version.

Negative tests should ensure unlicensed activity remains blocked or escalated according to policy.

Quality assurance

QA should ask whether analysts confirmed licence scope rather than title, whether conditions were evidenced, whether the correct version was used and whether reporting was completed.

It should also identify repeated manual work that could be structured.

Errors should be categorised: identity resolution, legal interpretation, condition validation, system configuration, reporting or recordkeeping.

This supports targeted remediation.

Management information

Useful licence MI can include active general licences, active specific licences, upcoming expiries, transactions processed under licence, value by licence, manual-review volumes, overdue reports, expired whitelist entries, failed condition checks and QA findings.

MI should distinguish legal permission from internal policy exceptions.

Senior management should be able to see concentration: for example, if a significant business process depends on one temporary licence expiring soon.

That can create business-continuity and customer-impact risk.

BA data model

The BA should model Authority, Jurisdiction, SanctionsRegime, Permission, PermissionVersion, CoveredParty, Condition, Transaction, Usage, Report, Evidence, Decision and WhitelistEntry as separate but linked objects.

Effective dates and status transitions are mandatory design features.

The model should allow many transactions under one permission and multiple permissions relevant to one transaction.

It should also support a transaction that is not covered by any permission.

BA acceptance criteria

Acceptance criteria should include: exact licence match; multiple licence candidates; licence effective tomorrow; expiry during payment processing; customer-specific licence; general licence; EU authorisation; conditions requiring manual evidence; cumulative cap; currency conversion; return payment; revoked licence; amendment; list change; ownership change; and failed reporting.

The expected result should include payment state, licence state, decision owner and audit evidence.

Avoid acceptance criteria that say only “system should support licences.”

The detail determines whether the control works.

Developer and architect view

Licence data should come from governed sources. Public general licences can be ingested from authority publications with legal review. Specific licences require secure handling and controlled entry.

Rules should be versioned and deployable with effective dates. Caching should not allow an expired permission to remain usable.

APIs should return both status and reason. A simple boolean licensed=true is insufficient.

Event notifications for amendment and expiry can drive downstream controls.

Operations view

Operations needs clear instructions: when to hold, what evidence to collect, who can approve, how to apply a licence and what final payment state to use.

Analysts should not interpret complex licence language under payment-cut-off pressure without support.

Playbooks can translate legal conditions into operational questions while preserving the legal reference.

Escalation should be fast for humanitarian and time-sensitive cases.

Legal and sanctions-specialist view

Legal specialists determine how the permission interacts with the underlying prohibition and whether the bank’s activity falls within scope.

They should document interpretation in reusable form where possible so each analyst does not recreate the legal analysis.

Material uncertainty should be escalated rather than resolved through operational convenience.

Policy should also define when external counsel or authority engagement is required.

Internal audit view

Audit should test governance of licence inventory, validation, version control, condition implementation, whitelist linkage, reporting, expiry and evidence.

It should sample transactions processed under licences and confirm that each was within scope.

Audit should also inspect permissions that expired and verify downstream controls were removed.

A licence repository with accurate documents but broken payment integration is not an effective control.

The four-stage decision model

A useful mental model is: restriction → permission → conditions → execution.

First identify the applicable prohibition. Second identify whether a valid licence, exemption or authorisation can permit the activity. Third confirm every material condition. Fourth execute the exact permitted action and retain/report evidence.

Starting with the licence without first understanding the prohibition can create errors because the transaction may not be prohibited in the first place or may be restricted under another rule not covered by the licence.

The model also prevents “licence = customer cleared” thinking.

Licence does not override another prohibition

A transaction can be covered by one licence but prohibited by another sanctions programme, export-control rule or legal restriction.

The bank should therefore re-run the full applicable legal analysis, not stop once one permission is found.

This is particularly important for multi-jurisdiction payments or parties subject to several designations.

The case should show which restrictions were considered and which permission addressed each one.

Final practitioner exercise

Take a payment involving a designated company for legal services. Identify the sanctions programme, legal entity processing the payment, licence or exception, covered designated person, law firm, fee amount, expense amount, dates, reporting and recordkeeping. Add a USD correspondent and an EU branch to the flow and determine whether additional legal analysis is required.

Then change one variable at a time: licence expires; amount exceeds cap; beneficiary changes; ownership changes; authority amends reporting requirement; payment returns; customer submits a specific licence; correspondent asks for evidence.

A learner should be able to explain how each change affects the decision without using the vague phrase “legal approved.”

The exercise is complete only when the payment status, permission status, conditions, reporting owner and audit evidence are all defined.

Authoritative references

• OFAC FAQ 74 — What is an OFAC license?: https://ofac.treasury.gov/faqs/74
• OFAC — Licenses: https://ofac.treasury.gov/faqs/topic/1501
• OFAC — Sanctions Programs and Country Information: https://ofac.treasury.gov/sanctions-programs-and-country-information
• OFSI — UK financial sanctions general guidance, updated 12 May 2026: https://www.gov.uk/government/publications/financial-sanctions-general-guidance/uk-financial-sanctions-general-guidance
• OFSI — General licences collection: https://www.gov.uk/government/collections/ofsi-general-licences
• HM Treasury/OFSI — U.S. and UK Economic Sanctions Authorities: A Comparative Overview, 23 June 2026: https://www.gov.uk/government/publications/the-us-and-uk-economic-sanctions-authorities-a-comparative-overview
• European Commission — EU sanctions: https://finance.ec.europa.eu/eu-and-world/sanctions-restrictive-measures_en

Educational note: licence, exemption, derogation and authorisation rules differ by sanctions regime and can change rapidly. Always use current official sources and approved legal interpretation for live transactions.

Advanced practice: turning sanctions permissions into controlled bank operations

A sophisticated licence-management programme treats legal permissions as executable obligations, not attachments. The bank must be able to show why the underlying activity was prohibited, why the permission applied, which conditions were satisfied, which legal entity relied on it, how the payment or asset action was executed, and what reporting or recordkeeping followed. This section deepens that operational chain.

Start with the prohibition, not the licence

Analysts often receive a licence before they have identified the exact prohibition. That can lead to a false assumption that any transaction involving the named person is automatically covered. The better sequence is to identify the applicable sanctions measure first. Is the issue an asset freeze, transaction ban, sectoral restriction, service prohibition or another rule? Which legal entity is subject to it? Only then should the bank test whether the permission addresses that prohibition.

This sequence also reveals situations where the licence is unnecessary. If the transaction is not prohibited by the relevant rule, the bank should not represent the activity as “authorised by licence” simply because a licence document exists.

General-licence version control

General licences can be amended, extended, replaced or revoked. The bank should therefore store each published version as a separate effective-dated object. Version comparison should identify changed expiry dates, covered parties, excluded activities, monetary conditions, reporting obligations and recordkeeping language.

A legal analyst should classify each change by operational impact. Extending an expiry may require only a date update. Adding a reporting condition can require a new workflow and owner. Narrowing scope can require immediate reassessment of queued transactions and standing instructions.

Testing should prove that the previous version cannot authorise activity after supersession unless the legal framework explicitly permits it.

Specific-licence intake and authenticity

Customer-specific licences can contain sensitive information and should enter through a controlled process. The bank should identify the source, customer, issuing authority, reference, issue date and any authenticity checks performed. Access to the document should be restricted according to role.

The bank should be alert to incomplete pages, altered dates, missing conditions or screenshots that omit official context. Suspicion of forgery should route to fraud/legal processes, but ordinary operations staff should not make unsupported accusations.

Where the authority provides a verification or contact process, the institution can use that through approved channels.

Translating conditions into controls

Conditions can be divided into objective and interpretive categories. Objective conditions include date ranges, named parties, amount caps and currencies. These can often be automated reliably. Interpretive conditions can depend on purpose, whether activity is “ordinarily incident and necessary,” legal status or another contextual judgement. These need human or legal review.

The system should store the condition text, structured interpretation and control owner. If the automated rule is narrower than the legal permission for operational safety, label that as bank policy. If it is broader, legal review is required.

Every automated condition should be traceable to an approved interpretation.

Multi-transaction permissions

A licence authorising recurring or multiple payments requires cumulative control. The bank should decide whether each transaction consumes a cap, whether returned or cancelled payments restore capacity, how foreign-currency values are translated, and what happens to transactions in flight when the remaining amount is exhausted.

The licence-usage ledger should reconcile with booked transactions. It should not rely on analyst notes to calculate remaining allowance.

For a permission with no monetary cap, usage tracking can still support reporting and audit.

Multi-party permissions

A licence can refer to named designated persons, affiliates, banks, professional advisers, counterparties or categories of persons. A transaction can introduce additional parties not contemplated in the licence.

The bank should therefore compare all legally relevant parties with the permission. If a different beneficiary or intermediary appears, scope may need re-evaluation. Ownership changes can also alter whether the transaction remains within the licence.

Entity resolution matters: fuzzy matching should identify candidate parties, but licence coverage should be based on verified identity and legal interpretation.

Multi-jurisdiction permissions

Global payments often cross legal entities and external correspondents. One authority’s licence does not automatically bind another jurisdiction. A UK licence may solve a UK prohibition while a U.S. correspondent still needs its own legal basis. An EU authorisation can have territorial and entity limits.

The case should therefore have one PermissionAssessment per relevant regime when necessary. A group-level decision can coordinate them, but should preserve each legal result.

This is especially important for centralised payment hubs processing instructions for multiple branches and subsidiaries.

Humanitarian programme design

Humanitarian payments deserve specialised operational design because delay can create real harm while sanctions requirements remain binding. A bank can maintain pre-validated information about recognised organisations, programme purpose, common counterparties and applicable general licences or exemptions while still screening each material transaction.

This does not mean “humanitarian = auto-release.” It means avoid rediscovering the same verified facts in every case. Exceptions, excluded parties, end-use and reporting conditions still matter.

Metrics should include time to decision and reasons for delay, not only sanctions outcomes.

Legal-services programme design

Legal-services licences can contain fee caps, hourly-rate expectations, expense conditions or reporting. The bank should understand whether the payment is for professional fees, disbursements or another purpose.

A single invoice can contain licensed and unlicensed components. Operations may need the customer or law firm to separate them. The bank should not rewrite the payment purpose itself to make it fit the licence.

Where fee caps are cumulative, the usage ledger becomes important.

Wind-down versus business-as-usual

A wind-down licence normally provides a temporary path to conclude or unwind existing activity. The bank should identify contracts and obligations that predate the relevant event and distinguish them from new commercial activity.

Monitoring should detect whether transaction volume or relationship scope grows during the wind-down period. Growth is not automatically a breach but can indicate that activity no longer reflects wind-down purpose.

Expiry planning should start before the final day so open positions and scheduled transactions can be resolved lawfully.

Licence and frozen assets

A licence can permit movement or maintenance of frozen assets under specific conditions. The asset-state system should record the exact authorised release rather than simply mark the account “unfrozen.” A partial payment can be permitted while the remaining property stays restricted.

Securities and investment assets add complexity because dividends, interest, maturities and corporate actions can generate new value. The licence may or may not cover those events.

The bank should therefore control at asset and event level.

Reporting workflow

Reporting should be driven by structured triggers. When a covered transaction is executed, the licence service can create a reporting task with authority, required data, due date and owner. The report should link back to the relevant permission version and transactions.

If reporting is customer-owned rather than bank-owned, the institution may still need evidence or monitoring depending on the licence and policy. The responsibility should be explicit.

Overdue reporting should escalate like any other regulatory deadline.

Recordkeeping workflow

The audit pack should include authoritative licence text, approved legal interpretation, authenticity evidence for specific licences, relevant customer and transaction data, condition checks, approvals, reports and final payment/asset state.

A reviewer should not have to reconstruct permission logic from email threads.

Retention periods should follow applicable law and policy and should not be embedded as a universal number across jurisdictions.

Licence service failure

What happens if the central licence repository is unavailable during payment processing? A well-designed control defines fallback behaviour based on risk. Some transactions may be held. Others may use a replicated validated cache with strict expiry. High-risk manual overrides should require documented authority.

The bank should avoid a failure mode where “licence service unavailable” silently becomes “licence assumed valid.”

Resilience testing should include stale cache, clock mismatch and partial data.

Whitelist governance

Operational whitelists should be derivative controls, not independent sources of permission. Every whitelist entry should have owner, scope, reason, linked licence or legal basis, effective date and expiry.

The bank should periodically reconcile active whitelist entries with active permissions. Orphaned entries are a material control risk.

Whitelist logic should be narrow. If a licence permits legal-fee payments, whitelisting the entire beneficiary/customer pair for all transaction types is excessive.

Change-management case

An authority publishes an amended general licence at 18:00 local time. The amendment becomes effective immediately and removes one category of permitted activity. The bank has queued payments matching that category.

The change process should capture publication, ingestion, legal assessment, impact analysis, rule update, queue review, testing and communication. Emergency deployment governance may be necessary, but evidence should still be retained.

This scenario tests whether the bank can change sanctions permissions as quickly as sanctions themselves change.

Licence data quality

Common problems include wrong expiry, missing amendment history, inconsistent licence number, customer-specific licence attached to wrong legal entity, unstructured conditions, duplicate records and local copies diverging from the central version.

Data-quality monitoring should identify these defects before they affect transactions. High-risk critical fields can have four-eye validation.

The bank should also compare authoritative public general licences with its internal inventory to identify missed updates.

Segregation of duties

The person who enters a customer-specific licence should not necessarily be the same person who approves its legal applicability and releases high-risk payments. Segregation depends on the institution’s operating model, but decision rights should be clear.

Roles can include licence intake, legal interpretation, control configuration, payment operations, sanctions approval, regulatory reporting and QA. The case should identify who performed each step.

This reduces both error and inappropriate override risk.

MI for management

Management should know not only how many licensed transactions were processed but which permissions the business depends on, upcoming expiries, value concentration, reporting obligations, overdue conditions, rule-change latency and override rates.

A business line relying heavily on a temporary licence has a strategic dependency. Management should know what happens when the permission expires.

This makes licence management part of business continuity as well as sanctions compliance.

Internal-audit reconstruction

Audit should select an active licence and trace from authority publication to legal interpretation, system rule, payment execution, reporting and retained evidence. It should then select an expired licence and prove that all linked operational permissions were removed on time.

For specific licences, audit should verify authenticity and access control. For general licences, audit should confirm version changes were implemented.

The audit question is not “is there a licence file?” It is “did the bank execute only what the current permission allowed?”

Practitioner conclusion

Strong licence handling allows a bank to comply with sanctions while still processing activity that competent authorities deliberately permit. It avoids two equal errors: processing activity outside the permission and blocking activity that is lawfully authorised. The control succeeds when legal scope, conditions, dates, reporting and transaction state are connected by design rather than held together by analyst memory.

60-minute mastery extension: general and specific licence handling

Licence handling becomes reliable only when the learner can move from legal permission to operational execution without turning the permission into a blanket clearance. Use about 30 minutes for the core chapter and diagrams, 15 minutes for the cases below, 10 minutes for the licence-control design and 5 minutes for the final test.

Case 1 — general licence is not a whitelist

A counterparty is designated but a current general licence authorises a defined category of legal-service payments. The screening system should still identify the designation. The sanctions decision should then test whether the payment falls within the licence scope, dates, parties, fee or expense conditions and reporting requirements.

The operational rule should not say if licence exists, suppress alert. A better sequence is identify → apply restriction → test permission → test conditions → execute → report/retain evidence.

Case 2 — customer-specific licence

A customer provides a specific licence authorising a payment to a blocked person under a particular contract. Validate authenticity through the bank’s approved process and determine whether the bank itself is permitted to process the transaction. Compare beneficiary, contract, purpose, amount and dates with the licence.

Now change the beneficiary to an affiliate not mentioned in the licence. The original permission should not automatically follow the customer’s commercial relationship. Scope must be re-evaluated.

Case 3 — one licence, several legal entities

A UK customer has an OFSI specific licence. The payment is booked in a UK branch, processed by an EU group entity and clears in USD through a U.S. correspondent. The learner should identify which legal entities can rely on which permission and whether separate EU or U.S. analysis is necessary.

This case demonstrates why a group-level LICENSED = YES flag is unsafe.

Case 4 — licence expiry during processing

A general licence expires at a specified time. Several payments are initiated before expiry but will settle later. The bank needs approved legal interpretation of which transaction event matters under the licence and sanctions rule. System design should use timestamps and time zones where the legal text does.

Expiry should be an active event that disables linked controls, alerts owners and checks queued transactions. Do not wait for an analyst to notice the date on a PDF.

Case 5 — amendment adds reporting

An authority extends a general licence but adds a new reporting condition. The payment rules are updated with the new expiry, but the reporting workflow is not changed. The bank can still be non-compliant even though every payment fell within the authorised activity.

This case demonstrates why licence implementation includes conditions, reporting and recordkeeping—not just release logic.

Case 6 — cumulative value limit

Assume a specific licence authorises payments up to a stated aggregate value. Five separate payments individually fit below the cap. Together they exceed it.

A per-payment rule fails. The bank needs a licence-usage ledger and a clear rule for currency conversion, returns, cancellations and partial usage. The learner should specify what happens when a payment is pending and the remaining authorised capacity is insufficient.

Case 7 — return and reversal

A licensed payment is rejected by a correspondent and returns. Does the returned value restore the licence capacity? The answer depends on the licence terms and legal interpretation; the system should not assume it.

The return should remain linked to the original licence usage and payment. If a retry is attempted, coverage should be rechecked against the current licence version.

Case 8 — sanctions licence versus export licence

A transaction is authorised under a financial-sanctions licence but involves controlled technology. The sanctions permission does not necessarily satisfy export-control law. The customer may need a separate export authorisation.

Model both permissions separately. The final bank decision should show which restriction each permission addresses.

Licence-condition matrix

Build a matrix with rows for: covered party, activity, payment purpose, value, currency, geographic scope, contract, effective date, expiry, excluded activity, reporting, recordkeeping and downstream services. For each condition mark automated, manual, not applicable or specialist interpretation required.

This is more useful than a free-text “licence checked” box.

Licence state machine

A practical state machine can include RECEIVED, AUTHENTICITY_REVIEW, LEGAL_REVIEW, VALIDATED, ACTIVE, AMENDED, SUSPENDED, EXPIRED, SUPERSEDED, REVOKED and ARCHIVED. The exact labels can vary, but the control must distinguish current usability from historical evidence.

No downstream system should continue to treat an expired, revoked or superseded permission as active merely because the record still exists.

BA acceptance criteria

Test general licence, specific licence, statutory exemption, EU authorisation, wrong beneficiary, wrong activity, future effective date, expiry, amendment, revoked permission, cumulative cap, currency conversion, partial payment, return, reversal, legal-entity mismatch, ownership change, reporting condition and licence-service outage.

For each case define expected licence state, payment state, decision owner, evidence, report trigger and audit trail.

QA audit

Sample transactions released under licences. Confirm that analysts used the correct licence version, resolved identity before permission analysis, verified all material conditions, did not treat customer ownership changes as irrelevant, completed reporting and did not suppress the underlying sanctions evidence.

Also sample expired licences to confirm linked whitelists and rules were deactivated.

Final practitioner test

The learner should be able to explain general licence versus specific licence, licence versus statutory exemption, OFAC/OFSI licence terminology versus EU authorisations, why one permission does not override unrelated prohibitions, why the bank itself may need to be covered, and why licence conditions must become operational controls.

Finish with: “Designated beneficiary, specific customer licence, payment within amount but after expiry, separate export-controlled goods, USD correspondent.” A good answer identifies multiple legal questions rather than saying “licensed, release.”

Wind-down licence execution under deadline pressure

Wind-down general licences authorise defined transactions for limited periods to exit prohibited positions safely, and their deadlines create execution risk where complex positions cannot unwind orderly within the window. Execution planning starts from position inventory: every exposure covered by the wind-down authorisation quantified with unwinding mechanics, counterparty dependencies and market-liquidity constraints. Critical-path analysis identifies positions whose unwinding determines the timeline, particularly illiquid holdings, multi-party structures requiring coordinated action, and transactions needing third-party approvals that the bank does not control. Buffer management reserves contingency time for the inevitable frictions, since wind-down plans assuming frictionless execution fail on first contact with market reality.

Counterparty coordination under wind-down conditions requires proactive engagement: counterparties must understand the authorisation scope, the deadline, and each party's obligations, with communication documented to evidence good-faith compliance efforts. Market-conduct considerations apply where large wind-down transactions might move prices or signal positions; execution strategies balance speed against market impact within the deadline constraint. Failed-wind-down contingency addresses positions remaining at expiry: continued holding under the applicable frozen-position rules, specific-licence applications for extended wind-down where the framework provides, and breach-risk assessment for any activity continuing past the deadline. Every wind-down should conclude with reconciliation proving the authorised scope was respected and the remaining position correctly characterised, since post-wind-down examination is certain and the evidence must show compliance rather than effort.

Licence-reporting calendars and condition tracking

Licence conditions frequently impose reporting obligations with specific content, format, recipients and deadlines, and condition-tracking failures convert authorised activity into breaches through administrative lapse. Reporting calendars centralise every licence-related obligation across the bank's licence portfolio: periodic usage reports, transaction-level notifications, funds-transfer reports, and ad-hoc reporting triggered by defined events. Each calendar entry specifies the responsible owner, preparation timeline preceding the deadline, review and approval requirements, submission channel and confirmation-evidence retention. Consolidated calendaring prevents the diffusion where each business area tracks its own licences with inconsistent rigour and gaps at organisational seams.

Condition-operationalisation translates legal licence language into executable controls: value limits encoded in payment-system checks, party restrictions embedded in screening rules, purpose limitations reflected in transaction-review procedures, and date boundaries enforced systematically. Legal-to-operations handoff documentation records the interpretation applied to each condition with legal sign-off, preventing operations teams from improvising meanings under processing pressure. Condition-breach detection runs continuously rather than awaiting reporting dates: limit-utilisation monitoring with approaching-threshold alerts, party-scope verification on each transaction, and purpose-consistency review catch breaches while remediation remains possible. Breach-of-condition incidents follow the standard breach playbook with the additional dimension of licence-jeopardy assessment, since condition breaches can invalidate the authorisation retrospectively with severe consequences.

Supporting specific-licence applications without overstepping

Customers pursuing specific licences frequently need bank documentation, transaction histories, position statements and procedural guidance supporting their applications, and the bank's assistance must help without misrepresenting facts or prejudging the authority's decision. Support standards define what the bank provides: factual account and transaction statements with certification where procedures permit, position descriptions limited to the bank's own records, and process guidance on application mechanics without legal advice on merits. Staff must not draft licence justifications, characterise transaction legality, or promise outcomes, since each overstep creates misrepresentation exposure and undermines the application's credibility.

Application-tracking discipline follows supported applications through submission, authority questions, decisions and conditions: the bank records its supporting role with dates and content, monitors decision outcomes affecting transaction planning, and implements granted licences through the standard licence-operationalisation workflow with the same rigour as directly received authorisations. Refused applications trigger pipeline-transaction review ensuring no activity proceeds on assumed permission, and customer communication explaining the position without disclosing the bank's own risk assessment. The support function demonstrates constructive compliance engagement while maintaining the boundary between factual assistance and advocacy that protects both the application and the bank.

General-licence change monitoring and customer notification

General licences amend, extend, expire and supersede on timescales demanding active monitoring rather than periodic review: replacement licences narrowing previously authorised activity create immediate exposure for transactions planned under the old terms, and amended conditions invalidate established processing procedures overnight. Monitoring design subscribes to official publication channels across all applicable authorities with intraday review discipline, impact-assesses each licence change against the bank's licence-reliant positions and procedures, and implements updates with the testing and communication rigour of rule changes rather than administrative tweaks.

Customer-notification obligations for licence changes affecting customer activity require prepared communication infrastructure: affected-customer identification from licence-usage records, notification templates explaining the change's practical consequences with action required and deadlines, and delivery tracking proving notification occurred. Proactive notification distinguishes service-oriented compliance from reactive breach management, particularly where customers plan transactions weeks ahead on current licence understanding. Notification records also demonstrate the bank's reasonable care in supervisory examination of licence-transition incidents, where the characteristic finding is customers transacting on expired permissions the bank knew had changed but never communicated.

Licence-source discipline

Licence registers should record the official source publication for every permission relied upon, with version control capturing amendments and supersession. A licence position that cannot be traced to its official source text with effective dates is an assumption rather than a control.

Authoritative anchors

OFAC FAQ 74 — What is an OFAC licence?: https://ofac.treasury.gov/faqs/74

OFSI general licences: https://www.gov.uk/government/collections/ofsi-general-licences

OFSI UK financial sanctions general guidance: https://www.gov.uk/government/publications/financial-sanctions-general-guidance/uk-financial-sanctions-general-guidance

European Commission sanctions framework: https://finance.ec.europa.eu/eu-and-world/sanctions-restrictive-measures_en

World-class practitioner layer: licence handling as executable legal permission

A bank should treat a sanctions licence as a controlled legal object, not as an attachment in a case-management system. The critical question is not whether a document called a licence exists, but whether the exact transaction the bank proposes to execute is within the permission created by the competent authority. That requires a structured test of authority, programme, parties, activity, currency or asset, dates, value limits, conditions, reporting requirements, recordkeeping duties and any other prohibition that continues to apply.

OFAC’s current guidance remains a useful illustration. OFAC defines a general licence as a public, self-executing authorisation for categories of transactions that would otherwise be prohibited, while a specific licence is issued to a particular person for a particular transaction or activity. A person relying on either still has to comply with the terms, conditions, reporting and recordkeeping requirements that apply. The operating lesson for a bank is that a general licence should never become a permanent “allow” rule merely because the counterparty was once associated with authorised activity. The bank must test each relevant transaction against the current licence text and facts.

The same discipline applies internationally even though terminology differs. A UK general licence, an OFSI specific licence, an EU derogation, an exemption and a national competent-authority authorisation can perform similar functions but are not interchangeable legal concepts. Global policy should therefore model a generic permission object while retaining jurisdiction-specific legal attributes. The data model should record the issuing authority, legal instrument, programme, licence or authorisation identifier, covered persons, covered activity, validity period, monetary and qualitative limits, reporting requirements, document provenance, legal interpretation, approver and evidence of use.

Case: payment is inside the licence purpose but outside its conditions

Assume a humanitarian organisation asks the bank to make a payment involving a sanctioned counterparty and provides a general licence authorising specified humanitarian transactions. The payment purpose appears eligible, but the transaction is routed through a financial institution that is not covered by the permission or the licence requires specified records that the customer cannot provide. The correct conclusion is not “humanitarian = permitted.” The analyst must test every material condition. If one condition is not met, the bank may need another legal basis, a specific authorisation or a different route.

The case system should force the investigator to answer separate questions: what prohibition would apply absent the permission; which licence or exemption is being relied on; whether the bank is a person entitled to rely on it; whether every relevant party and activity is covered; whether any excluded conduct or counterparty is present; whether another sanctions programme independently prohibits the transaction; whether conditions can be met before execution; and what post-transaction reporting is required. A permission is therefore a legal path through a prohibition, not a substitute for sanctions analysis.

Case: licence expires while the transaction is in flight

A payment can be initiated while a licence is valid and settle after the licence expires. Whether it may continue depends on the licence wording, the point at which the legally relevant act occurs, any wind-down provision and the applicable law. Systems therefore need more than a document expiry date. They need time-aware decisioning linked to payment state. A payment captured at 14:00, released from screening at 14:05 and settled at 17:00 may cross a legal transition that requires re-evaluation.

For this reason, sanctions orchestration should support effective-dated rules and event-driven re-screening or re-authorisation. A change to a licence, designation or programme should identify payments that are authorised but not final, cases awaiting approval, blocked assets for which a release licence has been issued, recurring payments that depend on the permission and future-dated instructions already accepted by the bank.

Licence inventory and use controls

A mature bank maintains a controlled inventory rather than relying on investigators to search the internet at decision time. Each entry should include authoritative source, version, effective date, expiry date where relevant, status, linked programmes, conditions, legal interpretation and change history. General licences can be amended, superseded, revoked or expire. Specific licences can contain confidential terms. Access therefore needs appropriate restriction without making operational teams blind to conditions they must enforce.

A useful architecture separates four functions. Legal or sanctions advisory interprets the permission. A rule service converts approved interpretation into structured conditions. Transaction controls test those conditions against payment/customer data. Case management records the evidence and approval. Reporting services then identify uses that must be reported to the authority. This prevents an analyst’s free-text note from becoming the only control protecting a legally sensitive transaction.

Quantitative limits and consumption

Some permissions may include value caps, transaction limits or other measurable constraints. Where relevant, consumption should be calculated across the scope defined by the legal instrument, not merely per payment. If a licence permits an aggregate amount, parallel channels can create over-consumption unless the bank uses a shared counter. The control needs reservation, release and reconciliation logic so two simultaneously authorised payments cannot each assume the full remaining amount is available.

The same principle applies to blocked-funds release. A licence allowing specified blocked property to be released should be tied to the exact blocked-property record, account, asset or transaction covered. The release workflow should reconcile the authorised amount, actual debit, residual blocked balance and final settlement outcome. Manual release without inventory reconciliation is a major operational risk.

Changes, revocation and lookback

When a licence changes, the bank should ask which controls, customers, payments, blocked assets and historical decisions depended on it. Not every change requires a historical lookback, but every material change requires impact assessment. A licence may be narrowed, broadened, extended, replaced or revoked. The institution should preserve the version used at decision time so an auditor can distinguish a correct historical decision from a decision assessed under today’s text.

This is especially important in fast-moving programmes. OFAC’s recent-actions pages show that general licences can be issued or amended repeatedly within weeks. A robust system therefore ingests authoritative change events and routes them to legal interpretation, control deployment and affected-population analysis rather than expecting operations to notice a webpage update.

BA and architecture requirements

A business analyst should be able to trace the requirement from legal source to executable control. The requirement should state which authority and programme it applies to, the data needed to test eligibility, how missing data is handled, who can approve reliance, what evidence is retained, how changes propagate, what happens during screening outages and how reporting is produced. Acceptance criteria should include negative cases: wrong authority, expired permission, excluded counterparty, exceeded cap, transaction outside purpose, conflicting prohibition and incomplete mandatory evidence.

The audit record should preserve the legal source and version, licence identifier, permission type, conditions evaluated, transaction data used, ownership/control conclusion where relevant, result of other sanctions checks, approver, timestamps, actual payment outcome and any authority report. That record turns a difficult judgement into a reconstructable controlled decision.

Knowledge check

1. Why is a sanctions licence not equivalent to a whitelist?
2. What is the operational difference between a general and specific OFAC licence?
3. Why must licence validity be assessed against transaction state and time rather than only initiation time?
4. What should happen when a second sanctions prohibition applies even though one licence appears relevant?
5. Why do aggregate monetary limits require shared consumption controls?
6. What evidence must be retained to reconstruct reliance on a permission years later?

Answer guide

A licence authorises only the activity within its scope and conditions; it does not make a party universally safe. OFAC general licences publicly authorise defined categories and are self-executing when conditions are met, whereas specific licences are issued to particular applicants for particular activity. Timing matters because execution, settlement or another legally relevant act can occur after a permission changes. An independent prohibition must be analysed separately. Aggregate limits need shared reservation and reconciliation so parallel transactions cannot over-consume permission. Reconstruction should retain authority, programme, licence version, covered parties/activity, conditions, transaction facts, legal interpretation, decision, approval, actual outcome and reporting evidence.

Glossary

General licence — Public authorisation permitting categories of otherwise prohibited activity when its terms are met.

Specific licence — Individual authorisation issued by a competent authority to specified applicant(s) for specified activity.

Derogation — Permission available under a legal framework allowing competent authorities to authorise activity otherwise restricted when stated criteria are satisfied.

Exemption — Activity legally carved out from a prohibition when applicable conditions are met.

Permission object — Structured bank record representing a licence, authorisation, exemption or derogation and its executable conditions.

Consumption control — Logic that tracks use of a quantitative permission or cap across relevant transactions.

Effective dating — Recording when a legal rule or permission becomes valid and ceases to apply.

Authoritative source — The competent authority’s official publication used as the legal-source anchor.

References and further reading

• OFAC FAQ 74, “What is an OFAC license?” https://ofac.treasury.gov/faqs/74
• OFAC FAQ 7, general and specific licence reliance: https://ofac.treasury.gov/faqs/7
• OFAC Specific Licenses and Interpretive Guidance: https://ofac.treasury.gov/ofac-license-application-page
• OFAC General Licence recent actions: https://ofac.treasury.gov/recent-actions/general-licenses
• UK OFSI guidance and sanctions information: https://www.gov.uk/government/organisations/office-of-financial-sanctions-implementation

Knowledge check

1. Why is a sanctions licence not equivalent to a permanent whitelist for a customer or designated person?

2. What must a bank establish before relying on an OFAC general licence for a payment?

3. How does a specific licence differ operationally from a general licence, and why can the bank not assume that a customer’s specific licence automatically authorises every service provided by the bank?

4. A licence expires at 23:59 in the issuing authority’s stated time zone. A payment is initiated before expiry but will settle after expiry. Which facts must be resolved before release?

5. Why should licence usage, amendments, supersession and reporting obligations be stored as structured data rather than only as an uploaded PDF and analyst note?

6. What is the difference between an exemption written into law, a government licence or authorisation, and an internal bank policy exception?

7. A humanitarian payment references a valid permission. Why must the bank still screen parties and test the transaction against the exact permission conditions?

8. What evidence should be retained so an auditor can reconstruct a licensed transaction years later?

Answer guide

A licence is a defined legal permission with scope, parties, activity, conditions, dates and often reporting or recordkeeping requirements; it does not erase the underlying sanctions status. An OFAC general licence is public and self-executing only for transactions that actually satisfy its terms, so the bank must verify programme, parties, activity, timing, exclusions and conditions. A specific licence is issued to specified licensees for specified activity; whether another financial institution may rely on it depends on its wording and the applicable legal framework. Where execution and settlement span expiry, the bank must identify the legally relevant event, licence wording, applicable time zone, transaction state, any wind-down provision and whether another permission is required. Structured lifecycle data supports automatic expiry, version control, cumulative limits, reporting, reconciliation and historical reconstruction. A statutory exemption operates because the law excludes qualifying activity; a licence or authorisation is permission issued under legal powers; an internal policy exception is only the bank’s own governance decision and cannot override law. Humanitarian purpose does not remove party, ownership, activity or condition checks. The retained record should include the exact permission/version, authority, legal basis, parties, purpose, amounts, conditions tested, evidence, approvals, screening results, reporting, timestamps and final transaction state.

Glossary

General licence — A publicly available authorisation permitting defined categories of otherwise prohibited activity when its terms and conditions are met. Terminology and effect are jurisdiction-specific.

Specific licence — An individualised authorisation issued by a competent authority to identified applicants or licensees for defined activity.

Exemption — A category of activity excluded from a prohibition by the governing legal framework when the stated conditions are satisfied.

Derogation / authorisation — Terms commonly used in EU restrictive-measures frameworks for legally permitted departures from a prohibition under specified conditions; exact legal meaning depends on the regulation.

Licence scope — The combination of persons, activity, assets, geography, dates, values and other conditions covered by a permission.

Licence condition — A requirement that must be satisfied for reliance on the permission, such as reporting, recordkeeping, payment route, value, timing or counterparty limits.

Effective date — The date or timestamp from which the permission can be relied upon.

Expiry — The point after which the permission no longer authorises new activity unless extended, replaced or otherwise provided for by law.

Supersession — Replacement of an earlier licence or version by a later one. Historical versions should remain available for reconstruction but must not drive current decisions.

Licence usage ledger — A controlled record linking transactions and other activity to the permission used, supporting aggregate limits, reporting and reconciliation.

Operational whitelist — A narrow screening or workflow mechanism used to reduce repeat alerts. It is not itself legal permission and should reference the underlying legal basis, scope and expiry.

Wind-down permission — A time-limited authorisation allowing specified activity needed to terminate or conclude existing relationships or obligations.

Competent authority — The government or regulatory body empowered under the applicable legal framework to administer permissions, guidance or enforcement.

Legal basis — The regulation, statute, order, directive or other authority that creates the prohibition and the power for the permission.

References and further reading

Use the current legal text, licence or authorisation document and competent-authority guidance for live decisions. The sources below are authoritative starting points used for this chapter. They are not substitutes for transaction-specific legal analysis.

• U.S. Treasury / OFAC — FAQ 74: What is an OFAC license? Defines OFAC general and specific licences, confirms that general licences are public and self-executing when their terms are met, and states that users of either type must comply with applicable conditions, recordkeeping and reporting requirements. Updated 9 September 2026.
  https://ofac.treasury.gov/faqs/74

• U.S. Treasury / OFAC — Consolidated Frequently Asked Questions. Current source for programme-specific licensing, exemptions, reporting and other implementation guidance. Relevant licensing FAQs were refreshed in September 2026.
  https://ofac.treasury.gov/faqs/all-faqs

• U.S. Treasury / OFAC — Specific Licenses and Interpretive Guidance. Official application, status and reporting entry point for specific licences and interpretive guidance.
  https://ofac.treasury.gov/ofac-license-application-page

• U.S. Treasury / OFAC — General Licenses recent actions. Current publication stream showing new, amended and superseded general licences. It demonstrates why a bank must version permissions and monitor effective dates instead of relying on a static copy.
  https://ofac.treasury.gov/recent-actions/general-licenses

• U.S. Treasury / OFAC — Sanctions Programs and Country Information. Programme pages contain the operative legal authorities, general licences, directives, FAQs and programme updates that must be checked for the transaction being assessed.
  https://ofac.treasury.gov/sanctions-programs-and-country-information

• UK Government — How to use exceptions and licences to comply with sanctions. Cross-government guidance explaining that a regulatory exception applies automatically when its defined circumstances are met, while a licence is written permission for otherwise prohibited activity. Published 23 March 2026 and updated 23 April 2026.
  https://www.gov.uk/guidance/how-to-use-exceptions-and-licences-to-comply-with-sanctions

• UK Office of Financial Sanctions Implementation — UK financial sanctions general guidance. Section 6 covers exceptions and licensing and emphasises that licensing grounds differ between sanctions regimes. Updated 12 May 2026.
  https://www.gov.uk/government/publications/financial-sanctions-general-guidance/uk-financial-sanctions-general-guidance

• UK Office of Financial Sanctions Implementation — General licences collection. Current catalogue of OFSI general licences, amendments, extensions, revocations and expiries. Last updated 19 August 2026 when reviewed for this chapter.
  https://www.gov.uk/government/collections/ofsi-general-licences

• UK Office of Financial Sanctions Implementation — Designated Individuals Licensing Principles. Current OFSI principles for licence applications involving designated natural persons and a useful reminder that satisfying a licensing ground does not remove OFSI's discretion. Updated 10 September 2026.
  https://www.gov.uk/government/publications/financial-sanctions-licensing/ofsi-licensing-designated-individuals-licensing-principles--2

• UK Office of Financial Sanctions Implementation — General Licence INT/2026/9559192 (UK Interdiction). A current 2026 example showing that a general licence can permit specified related payments and payment processing subject to stated scope and conditions. Published 15 June 2026.
  https://www.gov.uk/government/publications/ofsi-general-licence-int20269559192

• HM Treasury / OFSI — The U.S. and UK Economic Sanctions Authorities: A Comparative Overview. Compares OFAC and OFSI licensing terminology, general and specific licences, reporting and recordkeeping, and helps prevent a global bank from treating U.S. and UK permissions as legally identical. Published 23 June 2026.
  https://www.gov.uk/government/publications/the-us-and-uk-economic-sanctions-authorities-a-comparative-overview

• European Commission — Consolidated FAQs on sanctions against Russia and Belarus. Current Commission implementation guidance containing programme-specific explanations of derogations and authorisations. Last updated 24 August 2026.
  https://finance.ec.europa.eu/publications/consolidated-version_en

• European Commission — Contacts for EU sanctions. Confirms that primary responsibility for implementing EU sanctions rests with Member States and directs EU operators to the relevant national competent authority.
  https://finance.ec.europa.eu/eu-and-world/sanctions-restrictive-measures/contacts-eu-sanctions_en

• EUR-Lex — Council Regulation (EU) No 833/2014, current consolidated text. Illustrates how EU legal instruments use provision-specific derogations and competent-authority authorisations, including conditions and powers to amend, suspend or revoke authorisations. Always use the version effective for the relevant date.
  https://eur-lex.europa.eu/eli/reg/2014/833/2026-04-24/eng

Accuracy boundary

Licensing language is not interchangeable across jurisdictions. “General licence”, “specific licence”, “exception”, “exemption”, “derogation” and “authorisation” can have different legal structures, legal effects and users. Before relying on a permission, identify the underlying prohibition, issuing authority, applicable legal entity and nexus, covered persons and activity, effective dates, limits, conditions, reporting and recordkeeping duties, and any separate prohibition that remains applicable. A sanctions licence also does not by itself satisfy export-control, fraud, AML or other legal requirements.