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

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

February 3rd, 2016 by Danielle McClellan

(Source:, 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 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 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

February 3rd, 2016 by Danielle McClellan

(Source:, 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

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:

Executive Order Revokes Iran Sanctions…but Iran Isn’t out of The Woods Yet

February 3rd, 2016 by Danielle McClellan

By: Danielle McClellan

On January 16, 2016, President Obama signed an executive order revoking the 20-year system of sanctions against Iran for pursing a nuclear weapons program in the past. The new Executive Order revokes the following Executive Orders: 13574, 13590, 13622, and 13645 with regards to Iran. An amendment to Executive Order 13628 was also made.

These changes come about after it was found that Iran has continued to comply with an international nuclear agreement that required them to abstain from obtaining nuclear weapons. Part of this agreement included that the US would lift sections on Iran as long as it refrained from building a nuclear program for a decade or more.

Most of the sanctions relief will apply to non-US citizens doing business with Iran; US citizens will still be unable to do business with Iran (this has not changed). The following has occurred due to the executive order:

  • Iranian assets will also be freed up and no longer held in the internarial financial system.
  • OFAC has also removed nearly 400 Iranians from its blocked persons list
  • OFAC will grant waivers for Americans to import food, carpets and other floor coverings from Iran.
  • A presidential memorandum was signed that will allow the export of a commercial passenger aircraft to Iran on a case by case basis.

Although these changes sound nice, it’s important to remember that all other US sanctions against Iran are still in place and will continue to be in place as long as Iran’s support for terrorism, regional destabilization, human rights abuses, and ballistic missile development occur.

Federal Register:

US Relaxes Sanctions on Iran: Put on Your Party Hat, because You Can’t Export It to Iran

February 3rd, 2016 by Danielle McClellan

By: John Black

Implementation Day has arrived.  Iran reached a nuclear non-proliferation milestone and the US relaxed some of its sanctions on Iran.  As reported in the media, President Obama has removed strict US trade controls on sanctions on Iran.  As reported in other media sources, the US has capitulated and freed Iran to have an unfettered path to development of nuclear weapons.

So, US exporters, you can put on your “US hearts Iran” party hat if you want, but you may not export that party hat to Iran because it is classified as EAR99 which still requires an export license for Iran, as does nearly every other product known to man other than medicine, medical devices and agricultural products.

The Obama Administration did remove the requirement that foreign parties that are owned or controlled by US parties obtain a US Government approval  before they do business with Iran, such as sending EAR99 “US hearts Iran” party hats to Iran.  No doubt, those cone shaped paper hats with the rubber bands that always get stuck in your hair are going directly to the Iranian nuclear scientist and engineers who, upon wearing the cone hats, will be able to work faster, smarter and more effectively in developing nukes.

In the final analysis, the actual scope of the changes to US export and reexport controls is very narrow, and typically tricky.

More specifically, to make the changes President Obama issued an executive order revoking sanctions imposed under other executive orders.  Since no new regulations have been published to do this, to figure out what happened, you have to read the new executive order and see what it eliminated in the previous executive orders and subtract those from OFAC’s Iran regulations.  Before you do that, I can give you a key overview of what happened that is most important to most US parties and foreign entities owned or controlled by US parties.

To implement the executive order, the Office of Foreign Assets Control (OFAC) created a new General License H to cancel existing rules.  Here are the key aspects of the General License H for foreign entities owned or controlled by US entities, and for US entities:

General License H Authorizes Foreign Entities Owned or Controlled by US Entities To:

  • Transfer to Iran foreign made items not subject to US jurisdiction—this includes purely foreign made items and foreign made items with US content that are exempt from US jurisdiction under the EAR de minimis rules; or
  • Transfer to Iran certain US made items (mainly EAR99 items, see exclusion 6 below) as long as the transfer is not a direct or indirect export from the United States.

Excluded from those two authorizations are:

  1. Direct or indirect exports from the United States to Iran;
  2. Movement of funds involving US financial institutions
  3. Activities involving parties on the SDN or activities prohibited non-Iran OFAC rules;
  4. Activities involving any entity on the FSE list;
  5. Activities for which the Export Administration Regulations (EAR) require a license—for example, most items with an EAR classification other than EAR99;
  6. Any military, paramilitary, intelligence or law enforcement entity of the Government of Iran;
  7. Activities otherwise prohibited or sanctionable by executive orders (EO):
    1.  12938 or 13382: Proliferation of weapons of mass destruction and their delivery systems;
    2. 13224:  International terrorism;
    3. 13572 or 13582:  Syria;
    4. 13611: Yemen; or
    5. 13553, 13606 or section 2 or 3 of 13628:  Iran’s human rights abuses
  8. Certain nuclear activities


General License H Authorizes Parties in the US to Be Involved In:

  • Activities Related to the establishment or alteration of corporate policies and procedures to the extent necessary to allow US owned or controlled foreign entities to engage in activities that General License H authorizes for the foreign entities; or
  • Activities to make available to US owned or controlled foreign entities automated and globally integrated computer, accounting, email, telecommunications or other business support systems, platform, database application, or server necessary to store, collect, transmit, generate, or other process documents of information related to activities that General License H authorizes for the foreign entities.

In addition, to the General License H, OFAC also announced a more formal safety of flight licensing policy for Iran.  Specifically, there is a good chance OFAC will approve licenses:

  • To export, reexport, sell, lease or transfer to Iran commercial passenger aircraft for exclusively civil aviation end-use
  • To export, reexport, sell, lease or transfer to Iran spare parts and components for commercial passenger aircraft
  • Provide associated services, including warranty, maintenance, and repair services and safety inspections for the above, as long as licensed items and services are used exclusively for commercial passenger aviation.

OFAC has stated that if it approves such licenses, it will require that the licensed activities do not involve SDN listed parties.

Before you have an export control party, including “I heart Iran” party hats, remember that the US can revoke General License H and all of the changes it made at the drop of a hat for any reason whenever it wants to do so.

Secondary Sanctions:  A big part of the OFAC relaxation does not apply to export or reexport controls, but comes in the area of secondary sanctions.   For example, OFAC has the authority to penalize a foreign entity with no ties to the US who is involved in the petroleum business in Iran, even if that purely foreign party is not transferring any items subject to US jurisdiction.   For non-US parties who are not owned or controlled by US parties and are not dealing in products subject to US jurisdiction, OFAC announced that it will no longer enforce its secondary sanctions on these sectors:

  • Financial and bank
  • Petrochemical and energy
  • Gold and precious metals
  • Automotive
  • Shipping, shipbuilding and ports

For companies outside of the scope of US export and reexport controls, the OFAC secondary sanctions are important.  For example, under US secondary sanctions, a French company with no US ties, could have a French export license to send 100% French machines to an Iranian oil site and still get penalized by US secondary sanctions.  So, if the US did not lift its secondary sanctions, it could have largely cancelled out the relaxations other countries made in their trade controls on Iran.

And, before anybody in France, or anywhere else in the world, dons their foreign-made made “I heart Iran” berets, remember OFAC can re-impose any or all of its secondary sanctions at the drop of a hat for any reason whenever its wants to do so.

These dramatic, yet limited, changes have created new business opportunities, but I recommend that everybody proceed with caution.  The US Government made it clear it will continue to enforce the existing rules.  The US Government does not want to be seen as being too lax regarding Iran, and a big, new enforcement case would give the US Government the publicity it needs to continue to convince Congress and companies everywhere that it remains tough on Iran and violations carry with them huge business risks.

For further guidance from OFAC, there is a lot of information at:

For the OFAC safety of flight guidance go to:

Crude Oil is Now EAR99: Export Control Holiday Party Pointers

January 19th, 2016 by Danielle McClellan

By: Danielle McClellan (Holiday party tip by John Black)
While few of our readers are involved in exporting crude petroleum, here is a nice jewel to brandish at holiday parties when the conversation shifts to President Obama authorizing exports of crude petroleum.  A handy tip is once somebody mentions the topic, immediately chime in with “Yep, it used to be 1C981 but not it’s EAR99.  Problem is, you still gotta screen against the denial lists, and there is no free lunch when it comes to AES filing either.  And, the worst thing is your ERP system probably still identifies the embargoed Crimea region are part of Ukraine, and we know that is a poster child violation waiting to happen.”  (FYI, the likely result is that you will not be invited back to that party next year.)
As widely reported in the media, the Obama Administration has removed most restrictions on exports of crude petroleum.  On December 18, 2015, the Bureau of Industry and Security (BIS) announced that crude petroleum would no longer be classified under ECCN 1C981 and would now be classified as EAR99. This change comes after the H.R.2029 – Consolidated Appropriations Act, 2016 (section 101 of Division O) passage.
It is important to remember that any exports of crude oil to embargoed or sanctioned countries or persons on any US Government denial list, normally still will require export authorization from BIS even though the item is EAR99.

Companies who hold a current license for crude oil exports should view EAR 750.79(i) regarding terminating license conditions upon the termination of the requirement for the export license.

BIS has not yet amended the Export Administration Regulations to reflect this change.


Company Fined $38,930 for Selling Internet Security Products to Iran, Sudan and Syria

January 19th, 2016 by Danielle McClellan

By: Danielle McClellan

Barracuda Networks, Inc. of California and its United Kingdom subsidiary, Barracuda Networks Ltd. voluntarily disclosed violations to the Office of Foreign Assets Controls (OFAC) related to the sale of various internet security products.

Between August 2009 and April 2012 Barracuda UK sold web filtering products that are used to block or censor Internet activity along with internet security products and the related software subscriptions to entities in Iran, Sudan and entities on the Specially Designated Nationals and Blocked Persons List (SDNs). During the same time period Barracuda US provided firmware and software updates to the illegal software subscriptions. The total transaction value for these sales was $123,586.

Both companies were charged with a total of 37 violations and fined a total of $38,930. OFAC released the following factors and considerations related to the fine:

  1. Barracuda acted with reckless disregard for sanctions requirements by (a) permitting distributors and resellers to sell its products and updates to SDNs and to customers in sanctioned countries when it knew or had reason to know that the products were located in sanctioned countries or with SDNs, in potential violation of U.S. sanctions requirements, and (b) distributing its products and technology to more than 17,000 resellers and distributors worldwide without implementing any written sanctions compliance policies or procedures, and failing to provide training to its employees regarding export controls and sanctions;
  2. Barracuda knew or had reason to know that it was exporting goods, technology, and services to Iran and Sudan because IP addresses associated with those countries were used to contact the company; further, Barracuda knew or had reason to know that it was exporting technology to Syrian SDNs because the SDNs were listed on sales invoices;
  3. The exportation of the Web filtering software and hardware to Iran, Sudan, and SDNs in Syria could potentially have caused significant harm to U.S. sanctions program objectives because the technology could have been used to block or censor Internet activity;
  4. Barracuda did not screen IP addresses used to contact Barracuda’s servers because it had no OFAC compliance program in place at the time of the transactions;
  5. Barracuda has no prior OFAC sanctions history, including no penalty notice or Finding of Violation in the five years preceding the earliest date of the transactions giving rise to the apparent violations, making it eligible for up to 25 percent “first offense” mitigation;
  6. Barracuda took significant remedial steps including developing a method to disable products in sanctioned countries, prioritizing U.S. sanctions and export controls compliance by establishing an Office of Trade Compliance and hiring a general counsel with subject matter expertise in these areas, issuing company-wide a statement from the CEO about sanctions-related policy, implementing a trade compliance manual, and enhancing its sales software to include red flags for orders that may require a license; and
  7. Barracuda substantially cooperated with OFAC’s investigation, including by agreeing to toll the statute of limitations for approximately 521 days.

OFAC Notice:

EGYPTAIR Leases Aircraft to Sudan Airways…Fined $140,000

January 19th, 2016 by Danielle McClellan

By: Danielle McClellan

Between August 2010 and February 2011 EGYPTAIR leased two Boeing 737-566 aircraft to Sudan Airways without obtaining the required BIS licenses. Both aircraft were flown under Sudan Airways flight numbers and are classified as 9A991.b and controlled for Anti-Terrorism reasons. EGYPTAIR has been assessed a penalty of $140,000 for two charges of reexporting an item without required licenses.

EGYPTAIR did not self-disclose the violations and will pay the $140,000 fine in installments.

Charging Letter

AESDirect Is Now Available in ACE!!!

January 19th, 2016 by Danielle McClellan


Attention all export filers… the new AESDirect is available in ACE for export filing.

If you have ACE Exporter Account access, you can begin filing using the new system. If you have not yet obtained ACE Exporter Account access, please review the broadcast message covering ACE registration and exporter access.

Today marks the beginning of the transition from the legacy AESDirect application to the Refactored AESDirect in ACE. During this transition period, both the legacy and the ACE AESDirect application are available for export filing. Take advantage of this time and begin transitioning your users to the new system. Please ensure proper transition management to avoid duplicate filing.

For more information, including the new user guide, FAQs, archived broadcast messages, training materials, etc. please check out the ACE Transition page. The ACE One-Pager also has a wealth of contact information and resource links to assist you with this transition.

Note: If you have technical issues filing in the new system, please contact the AES Help Desk at or 800-549-0595, option 1.

If you have technical issues with your ACE Accounts Access, please contact the ACE Service Desk at or 1-866-530-4172, option 1, then option 2.

Guidance on WebLink and EDI batch filing will be provided within the next 2 weeks. This deployment is for Portal and Bulk Upload filing through AESDirect only.