Archive for the ‘Export License’ Category

Statement Before House Committees Concerning Proposed Export Licensing for Cyber-Security Items

Wednesday, February 3rd, 2016 by Danielle McClellan

(Source: Homeland Security Committee) Author: Kevin J. Wolf, Assistant Secretary of Commerce for Export Administration.

Transcript of statement:

“Thank you, Chairmen Hurd and Ratcliffe, and Ranking Members Kelly and Richmond.

The Wassenaar Arrangement is a 41-member export control group in which the United States participates. It was established to contribute to regional and international security and stability by promoting greater responsibility in the transfer of conventional arms and dual-use goods and technologies, thus preventing destabilizing accumulations of such items. Participating States maintain a common control list of items warranting control for these reasons and seek, through their national policies, to ensure that transfers of these items do not contribute to the development or enhancement of military capabilities that undermine these goals, and are not diverted to support such capabilities. The list of such items is developed and updated by the Participating States through consensus determinations, generally made at the end of each year. …

In December 2013, Wassenaar approved new export controls on “command and delivery platforms” for “intrusion software” and related technology. Specifically, the entries in Category 4 (Computers) of the Wassenaar dual-use control list would control non-publicly available software (4.D.4.) that generates, operates, delivers, or communicates with “intrusion software.” “Intrusion software” is defined as software designed to covertly gain access to a computer or other networked device and, once inside, to extract or modify data or modify the execution path of the device to allow the execution of externally provided instructions. Related hardware and technology entries (4.A.5. and 4.E.1.c.) control systems and equipment for generating, operating, delivering, or communication with “intrusion software,” and technology for developing “intrusion software.” The original proposal for these controls came from another Wassenaar member nation in 2012. Examples of the types of commercial hacking software intended to be captured by this control include those offered by Hacking Team (Italy), Gamma/Fin-Fisher (Germany), and Vupen (France).

The controls were novel in that they were the first foray by a multilateral export control community into the area of offensive cyber tools. The agreed-upon entries covering software intentionally excluded “intrusion software” itself — that is, certain kinds of malware — from control because of a general understanding that everyone with a computer or mobile device infected by such malware or “exploits” could become an unwitting “exporter” of it (e.g., by forwarding an infected e-mail to someone in another country). The technology entry, however, imposes controls on non-publicly available technology for the development of such software as well as on technology for the development of the controlled delivery systems. …

In order to not take an action that would inadvertently harm our nation’s ability to engage in critical cyber defense and related research work, we decided in May 2015 to take the unprecedented step of publishing these Wassenaar control list entries as a proposed rule, with a request for private sector comments, rather than as a final rule. Our hope was that the private sector comments would give us a better sense for whether the rule would have unintended impacts on our cyber defense and cyber research ecosystems. All dual-use controls have consequences and impose costs on the private sector. That is the nature of controls. This one, however, was different because the impact would be not just on the economic bottom-line of U.S. companies, but on our government’s and our nation’s ability to share efficiently and quickly the types of technology necessary to conduct cyber defense and related research.

Immediately following publication of the proposed rule, Commerce received questions from U.S. private sector and others in the U.S. Government about the intended scope of the controls. In order to ensure that comments were informed and responsive to the proposed controls set forth in the rule, Commerce published answers to a list of “frequently asked questions” on its website to address what we determined were regular queries in order to encourage more focused and more useful public comments. It was clear from these initial questions that the terminology used in the control list entries and the proposed rule were understood differently by the cybersecurity community than by the export control agencies and the Wassenaar Participating States. By the end of the 60-day comment period, Commerce had received more than 260 comments, virtually all of them negative. Some commenters took the view that the underlying control at Wassenaar could not be implemented without causing significant harms to cybersecurity. Others made specific recommendations on ways to mitigate many of the concerns. Some praised the underlying objectives of the rule, while nonetheless proposing modifications to the scope of the proposed regulation, such as through license exceptions and definitions, to reduce the impact of unintended consequences. …

Neither the Commerce Department nor the Administration has reached a conclusion about how to respond to the public comments. We are still reviewing and considering them. Importantly, all U.S. Government agencies with expertise and equities in cyber defense research and related work are reviewing the comments and will provide input as a next step, before we make a decision on what to do about the proposed rule.   As requested by your committees, I can, however, summarize the essence of the comments – reiterating that the Administration has not come to any final conclusions regarding how to respond to the comments or to the extent to which they are correct technically. The public comments, including presentations at technical advisory committee meetings during the past three months, focus on three main issues.

First, some commenters asserted that the proposed regulation’s definition of “intrusion software” is too broad and, as a technical matter, fails. They assert that malware recovery tools would be caught by the entries because they interact with malware to regain control of an infected system, and some defense research tools would be caught because they analyze malware to develop new defensive products. They also assert that products that patch systems or add capabilities to programs would themselves be controlled under these entries because of the way they interact with or manipulate programs. These products are integrated with the hardware (systems, equipment, and components) and are designed to legitimately bypass or defeat protections, modify the standard execution path of software, and access data. According to the commenters, they would often thus be software for the generation, operation, delivery of or communication with “intrusion software” and caught by the new controls.

Second, other commenters contend that the proposed rule to implement the control list entries as written, based on the definition of “intrusion software,” would impose a heavy and unnecessary licensing burden on legitimate transactions that contribute to cyber security. Government agencies and private sector cyber security companies routinely test their systems and networks to identify vulnerabilities and, if possible, discover existing malicious attack agents. These companies then provide their clients with threat mitigation tools and strategies. To accomplish this, they use the same tools the controls on intrusion items identify, though their use is authorized by their target. To accomplish their mission, they need to employ tools for computers or networks that have the functional specifications of the control parameters, e.g., avoid detection, defeat protective countermeasures, extract data or information, modify system or user data, and modify the standard execution part of a program or process to execute externally provided instructions. These are exactly the characteristics a successful malicious attacker’s software would have and what the assessment team’s tools need to be able to replicate. During these defensive engagements, members of the assessment team frequently need to create custom scripts (i.e., software programs) to effectively assess the extent of the vulnerabilities by creating exploits, and to determine if a successful attack has taken place or is in progress.

Third, other commenters state that the proposed rule’s controls on technology for the development of “intrusion software” could cripple legitimate cybersecurity research. To address cyber threats, technical information must be shared with experts across the globe. In order to identify and quickly counter threats, the cybersecurity industry relies heavily on collaboration with other companies within and outside of the United States, as well as independent experts around the world. Many of these experts are self-taught, have no prior formal relationship with cybersecurity firms, and, in many cases, may be unknown until they discover a new vulnerability. To address vulnerability, a company must be able to engage in a back-and-forth dialogue with these researchers and experts. Often, the dialogue must include detailed discussion of exactly how a particular vulnerability could be exploited to gain control of a computer; without such discussion it is not possible to evaluate the risk posed by a vulnerability or to fashion an effective and comprehensive defense. Some commenters were concerned that, by subjecting vulnerability research, assessments, and testing to export licensing requirements including classification, screening, and other control elements, the control would limit the ability to fix and patch such vulnerabilities, leading to an overall decrease in the quality of cybersecurity. When vulnerabilities are discovered, they must be reported as soon as possible so that a fix can be developed. This process involves sharing not only the vulnerability and exploit, but also the technical information on how the exploits work, including the technology to develop them.

The commenters had many suggestions regarding how to address their concerns. The Administration will be reviewing all of them and many other ideas for how to address the policy objectives of the control but without unintended collateral harms. As I have said many times in response to questions about the rule, the only thing that is certain about the next step is that we will not be implementing as final the rule that was proposed. In working through this process, we will continue to seek input from those with expertise and equities in cyber security in both the U.S. government and the private sector before deciding in conjunction with its interagency partners what the next step should be. I thus welcome the Subcommittees’ inputs and am prepared to answer any questions you may have.”

Transition to the Refactored AESDirect System in ACE

Wednesday, February 3rd, 2016 by Danielle McClellan

(Source: census@subscriptions.census.gov, 14 Jan 2016)

This message is not intended for filers using AESWebLink and AESDirect EDI Upload. It is strictly for the attention of filers using the legacy AESDirect portal at aesdirect.census.gov and the AESPcLink application.

The Refactored AESDirect system in the Automated Commercial Environment was launched on November 30, 2015. Since that time, filers have submitted over 47,000 accepted shipments using the new system.

As part of the transition of AESDirect to the ACE Portal, the ability to file Electronic Export Information via legacy AESDirect at aesdirect.census.gov and the AESPcLink application will be terminated in stages over the next two months. All legacy AESDirect filers will be notified of their mandatory transition date to the Refactored AESDirect system upon login and be provided a specific date their account will be closed off based upon their Filer ID.

The dates for this transition are based upon the two-digit prefix of the Filer ID and accounts will be closed off from legacy AESDirect accordingly.

  • Prefixes 00-19 on 02/15/2016
  • Prefixes 20-39 on 02/22/2016
  • Prefixes 40-59 on 02/29/2016
  • Prefixes 60-79 on 03/07/2016
  • Prefixes 80-99 on 03/14/2016

Please make sure you have taken steps to begin filing in the Refactored AESDirect system in ACE prior to your mandatory transition date.

For more information regarding the transition, please see our AESDirect Transition to ACE – Refactored AESDirect page here.

For further information or questions, contact the U.S. Census Bureau’s Data Collection Branch.

Tips on How to Resolve AES Fatal Errors

Wednesday, February 3rd, 2016 by Danielle McClellan

(Source: census@subscriptions.census.gov, 19 Jan 2016)

When a shipment is filed to the AES, a system response message is generated and indicates whether the shipment has been accepted or rejected. If the shipment is accepted, the AES filer receives an Internal Transaction Number (ITN) as confirmation. However, if the shipment is rejected, a Fatal Error notification is received.

To help you resolve AES Fatal Errors, here are some tips on how to correct the most frequent errors that were generated in AES for this month.
Fatal Error Response Code: 515

– Narrative: ECCN Must be Formatted NANNN

– Reason: The Export Control Classification Number (ECCN) was not reported in the correct format.

– Resolution: The Export Control Classification Number (ECCN) must be reported in a NANNN format, where N is a numeric character and A is an alpha character. Verify the ECCN, correct the shipment and resubmit.

 

Fatal Error Response Code: 561

– Narrative: DDTC License Number Unknown

– Reason: The License Code/ License Exemption Code reported requires a Department of State/ Directorate of Defense Trade Controls (DDTC) license number, but the DDTC license number reported is unknown in AES.

– Resolution: The DDTC license number reported must be valid in AES. Verify the DDTC license number, correct the shipment and resubmit. For further assistance, contact the licensing agency. The Department of State/ Directorate of Defense Trade Controls / DDTC Help Desk can be reached on 202-663-2838.

For a complete list of Fatal Error Response Codes, their reasons, and resolutions, see Appendix A – Commodity Filing Response Messages.

It is important that AES filers correct Fatal Errors as soon as they are received in order to comply with the Foreign Trade Regulations. These errors must be corrected prior to export for shipments filed predeparture and as soon as possible for shipments filed postdeparture, but not later than five calendar days after departure.

For further information or questions, contact the U.S. Census Bureau’s Data Collection Branch.

ACE Export Reports Access Tips

Wednesday, February 3rd, 2016 by Danielle McClellan

The Census Bureau has released a few helpful tips to make the vetting process for obtaining authorization to access your export data in ACE a little easier.

Some helpful tips:

  • Vetting by the Census Bureau Team is NOT required to file Electronic Export Information (EEI) via AESDirect in ACE.
  • Only request “EIN Reports Authorization” if you want to access export reports in ACE.
  • Newly established export accounts without prior filing history at the EIN level will not be authorized to access export reports in ACE.
  • EINs associated with an established ACE Importer Account do not require further vetting by the Census team, therefore do not select the feature “Requests EIN Reports Authorization” when adding the exporter role to an existing account.
  • Submit the Certificate of Authority (COA) for subsidiaries that plan on retrieving export reports. Prior filing history for each requested EIN is required.
  • If you have multiple EINs associated with an account, request access for each EIN and submit a comprehensive COA listing the subsidiaries requesting access.
  • In addition, shipment information must be verified by the Census Team prior to obtaining approval for Reports Authorization.

The information provided in this broadcast will assist you in obtaining Export Reports Access. Please visit our website for additional information on obtaining Exports Reports authorization by the Census Bureau here.

For additional assistance, call the International Trade Helpline at 800-549-0595:

It Never Pays to Lie…Actually it Could Cost You $50K

Tuesday, January 19th, 2016 by Danielle McClellan

By: Danielle McClellan
On September 14, 2012 GLS Solutions, Inc. of Aventura, Florida exported a $28,335 FLIR 440 High Performance Infrared Camera to Venezuela. The camera is classified under ECCN 6A003.b.4 and is controlled for National Security and Regional Stability reasons. GLS knew that a license was required to export the camera but continued to export it without obtaining a license. GLS has been assessed a penalty of $50,000 for one violation of “Acting with Knowledge of a Violation.” $32,500 of the penalty will be suspended for one year and eventually waived if GLS does not commit and further violations within the one year probationary period.

Gregorio L. Salazar, owner and president of GLS Solutions, was aware of the violation; however, in his initial disclosure letter to BIS regarding the illegal export of the camera he stated he was, “not aware that this camera required approval from United States Government in order to be shipped to Venezuela.” Nearly 6 months later, during a follow-up interview with a BIS Special Agent, Salazar admitted that he knew the licensing requirement for the FLIR camera prior to exporting it to Venezuela and explained that a FLIR Systems, Inc. representative informed him prior to the export that a license was required.  In addition to the penalty on the company, Salazar will pay $50,000 for one charge of providing, “False or Misleading Statement(s) in a Disclosure to BIS.” BIS did not suspend any of Salazar’s fine.

GLS Solutions Charging Letter
Gregorio L. Salazar Charging Letter

“Living in a Licensing Wonderland,” DDTC Posts License Process Times for November 2015

Tuesday, January 19th, 2016 by Danielle McClellan

DDTC Source (lyrics by John Black)
Licensing officers sing, are you listening?
In the cue, licenses glistening!
A button to press, it’s licensing success!
Living in a licensing wonderland!

In order to provide greater transparency and predictability for US defense firms in planning munitions license submissions, the Directorate of Defense Trade Controls will provides monthly update of the Directorate’s processing times. The timelines are expressed in averages across all case activity. For electronic cases, the average is based on the date the case was signed by the applicant until the date of final action. For hardcopy cases, the processing times are determined by the date the case entered the Directorate until the time the case is signed out of the Directorate. Processing numbers include all case types except Commodity Jurisdictions (CJs), Government Jurisdictions (GJs), and Electronic Rejections.

Month and Year  Jun ’15 Jul ’15 Aug ’15 Sep ’15 Oct ’15 Nov ’15
Cases Received 4,171 3,972 3,607 3,509 3,670 3,117
Cases Closed 4,102 4,020 3,777 3,570 3,861 3,185
Cases Open at
End of Month
3,336 3,307 3,175 3,134 2,968 2,928
Average Processing
Time
(in Calendar Days)
24 27 26 28 26 28

 

Oy, 521! X-Ray Stealth Now EAR Controlled and More Changes on Wing Folding Systems

Friday, December 4th, 2015 by Danielle McClellan

By: Danielle McClellan

Oy, another 521!  On November 16, 2015 BIS added XBS Epoxy System to the List of 0Y521 Series. The Epoxy system is designed to obfuscate critical technology components against X-ray and terahertz microscopy imaging attempts.  This seems to be the stuff that you could spray on that oversized jug of body cream or your Swiss army knife so they would not be detected by airport x-ray machines.  Oy, TSA!

The 0Y521 Series was established in April 2012 for items for which there is no ECCN but that should be controlled for export because they provided at least a significant military or intelligence advantage to the US, or because foreign policy reasons justify its control.  0Y521 controls are temporary controls that allow BIS to impose controls on a temporary basis while it sorts things out—including making sure the controls are justified and attempting to get other countries to impose similar export controls.

This rule classifies XBS Epoxy System (ECCN 0C521) to be controlled for regional stability (RS) Column 1 reasons. The only license exception available for these items is for exports, reexports, and transfers (in-country) made by or consigned to a department or agency of the US Government. The license requirements and policies for ECCN 0Y521 series appear in § 742.6(a)(7) of the EAR.

License applications for this item may be submitted through SNAP–R in accordance with § 748.6 of the EAR. Exporters are directed to include detailed descriptions and technical specifications with the license application, and identify the item as 0C521.

In this rule, BIS has also removed technology and software related to aircraft wing folding systems from the 0Y521 Series List. The following changes have been made:

  • Entries No. 3 0D521 and No. 2 0E521, respectively, in Supplement No. 5 to part 774 are obsolete because, in accordance with procedure established in the April 13, 2012, final rule, the U.S. Government adopted a control through the relevant multilateral regime(s), which determined an appropriate longer-term control over the item. The wing fold system ‘‘software’’ is now controlled by ECCN 9D001, and the ‘‘technology’’ is controlled by ECCN 9E003.j on the CCL

As always, BIS is encouraging you to submit your comments on these changes.  You may submit comments by any of the following methods:

  • Federal eRulemaking Portal: www.regulations.gov. The identification number for this rulemaking is BIS– 2015–0043.
  • By email directly to: publiccomments@bis.doc.gov. Include RIN 0694–AG70 in the subject line.
  • By mail or delivery to Regulatory Policy Division, Bureau of Industry and Security, U.S. Department of Commerce, Room 2099B, 14th Street and Pennsylvania Avenue NW., Washington, DC 20230. Refer to RIN 0694–AG70.

FOR FURTHER INFORMATION CONTACT:

Michael Rithmire, Electronics and Materials Division, Office of National Security and Technology Transfer Controls by phone at (202) 482–6105 or by email at Michael.Rithmire@bis.doc.gov.

DDTC Updates GC’s for Amendments and Adds Time Restrictions

Friday, December 4th, 2015 by Danielle McClellan

By: Danielle McClellan

DDTC has posted an updated guidance that will simplify the authorization matrix and spreadsheets and add a new time restriction for amending the General Correspondence (GC) for Amendments of Existing ITAR Authorizations. They will also clarify who may submit the GC and will take comments from industry after they implement the update. Contact Pete Walker at walkerwp@state.gov, 202-663-2806 with questions and comments.

§122.4 states that a registrant must notify DDTC of all material changes to their registration file. These include:

  • Restructuring,
  • Merger/acquisitions and/or
  • Registration code consolidations and combinations thereof

Per §122.4(c)(3), the licenses affected by these changes must be identified to DDTC via a spreadsheet/matrix attached to a General Correspondence letter. Any license not identified will be considered invalid. Per §122.4(c)(4), affected agreements require an executed amendment for a US entity name change within 60 days of notification. Any agreements not so amended will be considered invalid.

GC requests are applicable regardless of the number of authorizations involved and will cover approval of both DSP licenses and agreements. NEW CHANGE:

  • The GC request must be submitted within 60 days after DDTC approval or acknowledgment of the change.
  • DDTC will entertain name/address changes or registration code change amendments up to 180 days after the date of the approved GC
  • DDTC general policy will be to RWA amendments to GCs that fall outside of the 180 day time frame (they will review these on a case-by-case basis)
    • If the GC amendment is RWA (Return without Action), the applicant will have to individually replace any remaining licenses, and amend any agreements pursuant to 124.1(c)

Name or Registration Change:

When requesting a name or registration code change the following documentation must be included in with the submitted GC for the US entity:

  1. A letter identifying the requested changes;
  2. A §126.13 certification letter;
  3. A copy of the DTCC’s letter acknowledging the requested change(s), if issued, and;
  4. A matrix/spreadsheet containing the authorizations to be transferred.

Mergers & Acquisitions Changes:

For these, the GC must come from the acquiring party and if the GC does not come from the acquirer the GC will likely be RWA’d. The GC must contain the following:

  • A subject line clearly indicating that the GC will amend export authorizations as a result of a corporate restructuring, merger/acquisition and/or registration code consolidation or any combination thereof.
  • Concise description of the proposed transaction, in particular the
    • Acquirer and acquiree’s registrant codes (i.e., the “before and after” registration codes.)
  • The request must reference the submitted documentation and, if applicable, provide an attached DTCC approval letter.
  • The following statement MUST be included: “Modifications to the existing agreements submitted as part of this letter are specifically limited to a change to the registration code and/or to the U.S. entity name as a result of an approved merger or acquisition, and are signed by the new U.S. entity, the former U.S. licensor and the foreign licensee(s). Any other modifications will be requested through a proposed amendment in accordance with §124.1(c) or (d).” If no executed amendment is required (such as registration code change only) then this statement is not necessary.
  • The spreadsheet/matrix of authorizations to be transferred must include all existing and pending authorizations. Only those authorizations identified in the list will be amended. Any authorization not included will be considered invalid and a new authorization must be obtained. The spreadsheet/matrix must include the following information for each authorization:
  1. License or agreement number; (Note: §122.4(c)(3) states that registrants shall advise DDTC of all approvals on which unshipped balances will be shipped under the surviving registration code. However, registrants should also consider referencing exhausted licenses in order to retain access to such licenses in DTrade;)
  2. Disposition of authorization (Approved or Pending Approval);
  3. Date of Authorization Expiration;
  4. New registration number and/or company name (if applicable), and;
  5. State Y or N if an executed amendment is required (for agreements only.)

For expeditious review, the applicant should filter the spreadsheet as follows: registration #/new name/existing authorizations/pending authorizations.
Agreements Changes

DDTC will annotate affected agreements in its database.

Changing the Registration Code for Agreements:

  • Submit a GC request

US Entity Name Change for Agreements issued thru DTrade:

  • Upload a cover letter
  • Upload executed “minor amendment” (defined by §124.1(d)) into DTrade case file

 

US Entity Name Change for Paper Agreements:

  • The following documents must be sent via separate cover letters
    • Upload a cover letter citing GC case number in the body
    • Upload executed “minor amendment” (defined by §124.1(d)) into DTrade case file

Third Parties Affected by Change

A third-party is a US entity other than the license holder who has submitted the GC request. Third party licenses affected by a US entity name change does not require a DSP amendment for he affect DSP license. The DDTC issues web notice of name change serves as approval for the change. This notice should be attached to all affected licenses.

Agreements affected by US entity name changes will require the agreement holder to amend the agreement. The executed amendment will serve as a minor amendment (§124.1(d)). The agreement holder must upload the re-executed agreement to the relevant DTrade Case. Any applicants with a pending agreement or amendment must notify the respective DDTC Agreement or Licensing Officer of the upload of a revised executed agreement.
For Company Address Changes Only:

If the US registrant changes address (i.e. address change only, no change in company name or registration code) the following must be submitted:

  1. A letter identifying the requested changes to the company address;
  2. A §126.13 certification letter, and;
  3. A copy of the DTCC’s letter acknowledging the requested change(s), if issued.

DDTC will issue an acknowledgement letter to the US registrant regarding the address change and issue a web notice to alert the US applicants of the address change and provide guidance.

View DDTC’s full notice here: http://pmddtc.state.gov/licensing/documents/gl_GCsMandA.pdf

ACE, AES and AESDirect…Confused Yet?

Thursday, November 5th, 2015 by Danielle McClellan

By: Danielle McClellan

The ACE, AES and AESDirect system is a bit of a convoluted puzzle of applications that are intertwined. If you understood them before, be prepared to change what you thought you knew. In early 2016 changes will be taking place to the systems. Before we look at the changes, let’s look at each one individually.

ACE (Automated Commercial Environment): this is the primary system that the trade community reports import and export shipments. ACE is a single window that will continue to change and adapt so that it can automate more processes and eliminate paper.

AES (Automated Export System): this is the central point where export shipment data is filed and sent to the US Customs and Border Protection. AES collects, processes and stores all Electronic Export Information (EEI). AES creates Internal Transaction Numbers (ITNs) and provides exporter’s with messages such as “Fatal Errors” and “Compliance Alerts.” AES is housed in ACE.

AESDirect is the online system for Electronic Export Information (EEI) maintained by the US Census Bureau. AES filers can register their accounts in AESDirect and file their export shipments to the AES for processing. Basically AESDirect is just another way to file your export shipment data…50% of exports are processed directly thru AES and the other half are processed thru AESDirect.

So, in early 2016, the current AESDirect (also known as Legacy AESDirect) will transition into ACE. This means that AESDirect filers need to sign up for an ACE account if they do not already have one. If you have an ACE Importer account you should contact your Trade Account Owner (TAO) to request the export functionality be added to your account.

Specific Details:

  • The current AESDirect application available at aesdirect.census.gov, referred to as Legacy AESDirect, will transition completely into ACE in:
    • early 2016 for web, EDI and AESPcLink filers
    • mid-2016 for Weblink filers (specifications are forthcoming in October)
  • The ACE AESDirect application is referred to as Refactored AESDirect.
  • The online portal filing capability for the Refactored AESDirect will be available in late October 2015.

You must transition to the Refactored AESDirect based on the time frames noted above!!!

AESDirect filers are strongly encouraged to sign up for ACE Exporter accounts if they are completely new to the ACE system (brief how-to video).

Filers who have ACE Importer accounts should contact their Trade Account Owner (TAO) designated by their company and request that export functionality is added to their account (brief how-to video).

ALL legacy AESDirect account holders (regardless of filing method) will need an ACE account to access the Refactored AESDirect application because the legacy application will be retired in 2016!!! Sign up in advance and be prepared!

The videos referenced are accessible on CBP’s website.

For further information or questions, contact the U.S. Census Bureau’s Data Collection Branch.

Slackers Rejoice! DDTC Extends ITAR Authorizations Expiration Dates for ECR Shifted Items

Thursday, November 5th, 2015 by Danielle McClellan

By: Danielle McClellan

Maybe you are not an ECR slacker.  Most likely, despite your great plan and diligent efforts, you are one of the many exporters who haven’t quite figured out yet which of your hardware, materials, software and technical data shifted from the USML to the CCL as a result of Export Control Reform (ECR).  On paper, the task of reclassifying everything sounds easy.  In practice, it requires a lot of resources and time.  No one ever said ECR would make your life easier in the short term.

Enter DDTC to make things easier for some exporters for a bit longer—not something DDTC is well known for doing.  DDTC certainly knows from its experience processing license applications that sometimes it takes longer to get something done than outsiders would first expect.  Regardless of it’s motives, DDTC has extended the transition period for ITAR authorizations involving items that shifted from USML to CCL jurisdiction.

When ECR went into full force in 2013, DDTC published a final rule that provided a “Transition Plan” for exporter’s to follow regarding ITAR licenses, authorizations, and agreements. At that time, DDTC stated that all ITAR licenses, authorizations, and agreements would remain valid for a period of two years from the effective date of the rule (October 15, 2013) for  items that shifted from the USML to the CCL—there was no change to the validity period authorizations for items that did not shift.   Authorizations that covered both USML and CCL items remained valid until the expiration as long as simple amendments were made to agreements to add the USML x paragraph designation for non-USML items.

DDTC recently decided to give more flexibility for authorizations covering only items that shifted to the CCL.   On its website, DDTC recently added revisions to the various expiration dates  by adding an Updated Guidance paragraph after the previously issued guidance:

“A license or authorization issued by the Department will be effective for up to two years from the effective date of the revised USML category if all the items on the license or authorization have transferred to the export jurisdiction of the Department of Commerce.” (78 Fed. Reg. 67,752)

Updated guidance: Licenses or authorizations that would otherwise expire at the conclusion of the referenced two-year period will remain valid for 48 months from the date of issuance, or as otherwise indicated on the license or authorization.

“Approvals issued for agreements submitted prior to the effective date of the relevant revised USML category that contain transitioning and non-transitioning items will remain valid until expired, unless they require an amendment, or for a period of two years from the effective date of the relevant final rule, whichever occurs first, unless otherwise revoked, suspended, or terminated.” (78 Fed. Reg. 67,752)

Updated guidance: For agreements that would otherwise expire at the conclusion of the referenced two-year period, DDTC is extending the period of validity by one year.

“Approvals issued for agreements submitted prior to the effective date of the relevant revised USML category that contain solely transitioning items will remain valid for a period of two years from the effective date of the relevant USML category, unless revoked, suspended, or terminated.” (78 Fed. Reg. 67,752)

Updated guidance: For agreements that would otherwise expire at the conclusion of the referenced two-year period, DDTC is extending the period of validity by one year.