How to meet licence conditions on controlled computing under OFSI

A technology exporter has a UK financial-sanctions licence in hand. The deal can proceed – in principle. Then the compliance team reads the conditions. End-use reporting obligations, asset-disposal restrictions, periodic certification requirements: each one carries its own deadline and its own documentation standard. Miss a single condition and the licence that unlocks the transaction becomes the evidence of the breach. That is the operational risk that sits inside every OFSI authorisation for controlled computing exports.

Licence conditions for controlled computing exports under OFSI are legally binding obligations attached to a specific licence granted under the relevant UK thematic sanctions regulations administered by the Office of Financial Sanctions Implementation. Failing to meet a condition is itself a sanctionable act, assessed on a strict-liability basis, with a maximum civil penalty of the greater of £1,000,000 or 50 percent of the breach value as currently in force – verify the current position before relying on it. The starting point is to read each condition as a separate legal obligation, not as guidance.

This guide sets out what licence conditions look like in practice, how to build the internal controls that meet them, where the common failure points lie, and how the OFSI position compares with the OFAC and EU approaches a business may also face.

What you need before you start: the pre-conditions readiness check

Before any condition-compliance programme can work, the business must have three things in place: a complete copy of the licence with every page of conditions, a designated responsibility map that names who owns each obligation, and a record-keeping system that will hold evidence for the full statutory period.

OFSI licences for controlled computing exports routinely impose conditions on the categories of goods or services covered, the identity of counterparties and end-users, the territorial scope of permitted activity, and the reporting obligations attached. Each of those categories generates a documentary trail. That trail must be created contemporaneously: back-filling records after a regulator query is not a compliance strategy, it is an aggravating factor.

The record-keeping obligation under UK financial-sanctions rules requires retention for five years as currently in force. Set that clock from the date each transaction or activity occurs, not from the licence expiry date. Some conditions survive licence expiry; verify whether that applies to yours.

Does your business have a single person who can confirm, on any given day, whether every condition on the face of the licence is currently being met? If not, that accountability gap is the first risk to fix.

How to map each licence condition to an internal control

A licence condition without an assigned internal control is simply a written risk. The mapping exercise – pairing each condition to a specific procedural step, a responsible team, and a verification checkpoint – is the core of condition compliance for controlled computing exports under OFSI.

Start with the categories of permitted activity. A licence authorising financial flows in connection with specified computing goods or technology will typically define the permitted goods by reference to technical parameters. Someone inside the business – not just the legal team – must be able to confirm, for each shipment or payment, that the goods fall within those parameters. That confirmation must be documented at the time of the transaction.

Counterparty conditions are equally operational. Where a licence names or limits the persons with whom dealings are permitted, the compliance function must screen each actual counterparty against that list before each transaction, not just at onboarding. Counterparty ownership structures can change. A counterparty that was clean at licence grant may have a designated person in its ownership chain six months later. The 50 percent rule (OFAC's rule treating entities owned 50 percent or more by blocked persons as themselves blocked) has its UK analogue in the ownership and control test (the UK test for whether a non-listed entity is caught through a designated person). Both require continuous monitoring, not a point-in-time check.

Territorial conditions define where the permitted activity can occur. For computing goods that are physically delivered or digitally transferred, this means logging the delivery point, the recipient jurisdiction, and any transit or re-export step. A condition that permits supply to a named jurisdiction does not automatically permit supply through a third country. Read territorial restrictions narrowly.

Requirement by requirement: the step-by-step compliance checklist for OFSI conditions

The checklist below is not exhaustive, but it covers the conditions that appear most frequently on OFSI specific licences for controlled computing activity. Treat each item as a binary: either you have the documented evidence that the condition is met, or you have a gap to close before the next transaction proceeds.

Pre-transaction:

• Confirm the goods, services, or funds fall within the licensed scope as defined in the licence, not as assumed from the licence application.
• Screen all counterparties – including the end-user and, where known, the end-user's ownership chain – against the UK Consolidated List and against any names or categories specified in the licence itself.
• Confirm the territorial scope of the transaction matches the permitted jurisdiction(s) on the licence face.
• Where the licence requires pre-transaction notification to OFSI, send that notification and retain confirmation before proceeding.

At transaction:

• Record the transaction date, value, counterparty identity, goods or services description, and the licence number under which it proceeds.
• Obtain and retain any end-user certificates or declarations required by the licence conditions.
• If the licence conditions impose payment routing requirements – for example, payment through a specified financial institution or account – confirm the routing before instructing the payment.

Post-transaction and ongoing:

• File any periodic reports required by the licence conditions, on the schedule specified, to the address specified. OFSI licences can impose quarterly or annual reporting; the schedule is on the face of the licence.
• Retain all transaction records and supporting documentation for the full five-year period.
• Monitor for any change in counterparty ownership, designation status, or goods classification that could affect the continued validity of the licence or the accuracy of representations made in the application.
• Where the licence includes an asset-disposal or use restriction on computing equipment supplied under it, monitor compliance with that restriction for the period stated.

In our experience, the steps that most frequently fail in practice are post-transaction: the periodic report that falls due six months after the transaction closes, when the deal team has moved on and no one owns the obligation.

How do OFSI licence conditions compare with OFAC and EU requirements?

OFSI, OFAC, and the EU operate parallel licensing regimes for controlled computing activity, but their condition-compliance architectures differ in ways that matter operationally for a business subject to more than one of them.

Under OFAC, specific licences (case-by-case authorisations to conduct an otherwise prohibited transaction) and general licences (standing authorisations permitting a defined category of transactions without a separate application) both carry conditions. OFAC's reporting obligation requires blocked-property and rejected-transaction reports within 10 business days as currently in force. OFAC's civil-penalty jurisdiction is grounded in IEEPA; penalties are assessed on a strict-liability basis and can be substantial. The facilitation prohibition – which bars US persons from facilitating transactions that would be prohibited if conducted directly – is an additional compliance layer that has no direct OFSI equivalent.

The EU regime, governed by the relevant Council Regulation and administered through member-state competent authorities, takes a different approach. EU asset-freeze prohibitions extend to making funds or economic resources available directly or indirectly to or for the benefit of listed persons. An EU licence condition that permits a specific transaction within that prohibition will typically also require the licensee to report to the competent authority and to monitor the end use of any goods or funds released. The EU's dual-use export control regime, governed by Regulation (EU) 2021/821, operates alongside and independently of the financial-sanctions licensing regime; a business may need both a sanctions authorisation and an export-control licence, and the conditions on each are separately imposed.

The critical cross-regime rule is structural: where two regimes both apply, the stricter prohibition governs. A transaction cleared under an OFSI licence may still require OFAC authorisation if US-nexus elements are present – a US-dollar payment, a US-person participant, or US-origin technology. In our cross-border practice, the single most common oversight in controlled-computing licensing matters is the assumption that a UK licence resolves the US exposure. It does not.

For the OFAC-specific dimension of controlled computing licence conditions, see our practice page on computing licence conditions under OFAC. For the UAE treatment of similar licensing obligations, the UAE guide on computing licence conditions sets out the applicable national regime. The EU position is addressed in the EU computing licence conditions briefing.

What are the risk flags that indicate a condition-compliance failure is developing?

Condition-compliance failures rarely arrive as sudden events. They develop through a sequence of small omissions, each one manageable in isolation, that accumulate into a material breach. The following indicators, in our experience, precede the majority of condition-compliance problems we see on controlled computing matters.

No named condition owner. If there is no individual with a written responsibility for each licence condition, the obligation will be managed reactively. Reactive condition management – monitoring only when something prompts a review – consistently misses periodic reporting deadlines and counterparty-change triggers.

Conditions read once at licence grant. Licence conditions are re-read at grant and then rarely again. But the legal obligation continues for the life of the licence and, in some cases, beyond it. A condition requiring annual reporting imposes that obligation in year two just as firmly as in year one.

Counterparty changes not flagged to the compliance function. Where a counterparty is acquired, restructures, or brings in a new shareholder, the compliance team may not be informed unless there is a formal process for flagging relationship changes. A designated person appearing in the ownership chain of a licensed counterparty can render the entire existing arrangement non-compliant, regardless of the licence's face terms.

General licence assumption. A persistent myth in this area is that a general licence covers all controlled-computing transactions, rendering a specific licence application unnecessary. General licences are category-specific and contain their own conditions and exclusions. The goods, the destination, the counterparty type, and the transaction structure all determine whether a general licence applies. Where any element falls outside the general licence terms, a specific licence is required and failure to obtain one means the transaction proceeds without authorisation. Do not assume that because a general licence exists for a related category of activity, it covers yours.

No alert on licence expiry. A licence has a defined validity period. Transactions conducted after that period has expired are not authorised, regardless of whether the application for renewal is in progress. Set calendar alerts for licence expiry dates well in advance – in our practice, we recommend flagging at least 90 days before expiry for any licence covering ongoing or recurring activity.

The final readiness check: are you ready to operate under the licence?

The readiness check below is the last step before a business proceeds with a controlled computing transaction under an OFSI licence. It is not a substitute for legal advice, but it is the operational equivalent of a pre-flight list: if any item is not confirmed, the transaction should not proceed.

• The licence is valid (not expired, not suspended).
• The goods, services, or funds are within the licensed scope – confirmed against the licence text, not the application narrative.
• All counterparties have been screened within the past 30 days against the UK Consolidated List and any lists referenced in the licence.
• No counterparty has a known change in ownership, control, or designation status since the licence was granted.
• All pre-transaction notification obligations have been discharged and confirmation retained.
• Transaction records are being created contemporaneously and will be held for five years.
• The person responsible for the next periodic report knows its due date.
• Any US-nexus elements in the transaction have been assessed against OFAC requirements separately.
• Any EU-nexus elements have been assessed against the relevant competent authority's conditions separately.
• There is a process for flagging material changes – counterparty changes, goods reclassification, destination changes – to the compliance function during the life of the licence.

We regularly advise exporters and financial institutions on structuring condition-compliance programmes at the point of licence grant, before the first transaction proceeds. The cost of that structural work is a fraction of the cost of responding to a regulator query or a penalty notice.

This publication is general information and does not constitute legal advice. For advice on your situation, contact info@caldervance.com.