Export license determination

Description

Export-license determination is the per-transaction question that sits in front of every cross-border shipment of goods, software, or technology that touches a controlled list. The logic decomposes into three layers stacked in a specific order. Classification comes first: what is the item, and what category does it fall into under the EAR Commerce Control List (giving an ECCN), the ITAR US Munitions List, or the EU dual-use Regulation 2021/821 Annex I. Destination comes second: where is the item going, and what licensing requirements does that destination trigger under the applicable regime (the EAR Country Chart at 15 CFR Part 738 Supplement 1 pairs ECCN reasons-for-control with destination-specific licensing requirements; the EU regime uses Member-State competent-authority routing with the EU General Export Authorisations 001 through 008 carving out specific destination-and-item combinations). End-use and end-user screening comes third: does any catch-all under EAR Part 744 or its EU equivalent apply. The output is a per-transaction decision in one of four forms. License required, with the application submitted through the relevant regulator's portal (SNAP-R for BIS, ELAN-K2 for Germany's BAFA, SPIRE for the UK's ECJU, DGT for France) and the transaction held until the license issues. License not required, where the destination, end-user, and end-use combination falls outside the controlled scope. License-exception claimed, where a specific exception authorizes the export without an individual license (EAR ENC for mass-market encryption is the most-used by software platforms; OGEL Cryptographic Development is the UK equivalent); the conditions of the exception are documented at the time of export, because the exception only holds if those conditions were met at that moment. Transaction refused, where neither a license nor an exception is available and the transaction cannot proceed. The defensibility argument hinges on documentation of how the decision was reached, not just the decision itself. Classifications drift as products change; a classification correct two years ago may be incorrect for the current build, particularly where cryptographic strength has been increased, where new information-security features have been added, or where the item has been integrated into a higher-functionality system. A determination workflow that does not re-classify on substantive product change tends to produce stale decisions that an audit will surface; the regulators read those as a process gap rather than as a single-transaction error. The under-budgeted piece is usually the dual-use software question. Modest cryptographic or information-security functionality is enough to put an otherwise routine SaaS export inside the EAR perimeter, and the perimeter once crossed brings the full classification-destination-end-use determination workflow into play for every cross-border export. The mass-market encryption exception (License Exception ENC under 15 CFR 740.17) substantially reduces the operational cost for consumer-facing products with standard encryption, but raises the documentation burden because the exception requires both classification by the operator and, for many sub-categories, a notification or self-classification report to BIS. The cleanest operational pattern is to commit to the classification determination once per product version, file the supporting documentation at the version level, and run the per-transaction screening only against destination and end-use changes between exports.

Applicability

Applies when: markets include US.

How predicates are evaluated

Required by (3 regulations)

• US EAR

  15 CFR §736.2 + Country Chart at 15 CFR Part 738 Supp. No. 1 — pair ECCN reasons-for-control with destination-specific licensing requirements; License Exceptions ENC, TSU, APP for software platforms; SNAP-R submission for individual licenses.

  15 CFR §736.2 + Country Chart at 15 CFR Part 738 Supp. No. 1

  Source →

• EU Dual-Use

  Regulation (EU) 2021/821, Articles 7-12 — Individual Export Authorisations from Member State competent authorities plus EU GEAs (001-008); BAFA ELAN-K2 / DGT / CDIU per Member State.

  Regulation (EU) 2021/821, Articles 7-12

  Source →

• UK Export Control

  Export Control Order 2008 Articles 3-26 — SIEL/OIEL/OGEL framework; SPIRE submission; OGEL Cryptographic Development the most-used by software platforms.

  Export Control Order 2008 Articles 3-26

  Source →

Fulfilled by (2)

• descartes · partial · high effort · $$$
• In-house build · high effort

Magist does not accept payment from vendors. Methodology.

Evidence formats

• license-determination matrix
• license file
• license-exception use log