ICMM frequently asked questions (FAQs)

Your certificate posted to IDES was not valid. The IRS cannot download a file from IDES if the transmitter certificate is not valid.

Added: 03-24-18

Please post a valid certificate to IDES. Then re-encrypt the FATCA XML file with a new AES key. Re-package and resubmit the payload file to IDES using the new valid certificate.

Added: 03-24-18

The MessageRefId schema field in the submitted file is duplicative of another file you have submitted. This field should be a unique identifying number for a report file and is required to be a string of at least one alphanumeric character.

Updated: 03-03-16

While your file is in the valid XML format, comparison of MessageRefIds takes place outside of XML validation. FATCA XML User Guide (IRS Publication 5124 available at FATCA XML Schema) states that the MessageRefId should be a unique identifying alphanumeric value (created by the sender) that identifies the particular message being sent. The IRS cannot accept more than one file from the same sender with the same MessageRefId.

Updated: 03-03-16

Please correct the file by including a unique, valid alphanumeric character string in the MessageRefId field (see the FATCA XML User Guide, IRS Publication 5124 available at FATCA XML Schema) that does not consist of all blanks and does not exceed 200 characters in length. Use this file to recreate an IDES transmission and upload to IDES following all procedures (see the IDES User Guide, available on the IRS IDES Homepage) for transmission preparation and upload. The IRS will send another notification to you through IDES once your file has been downloaded and processed further.

Updated: 04-11-17

The IRS could not download the referenced file that had been posted to IDES. The file could not be decoded because the encoding mechanism used did not match what was listed in the IDES metadata.

Added: 03-24-18

The file encoding schema supported by the IRS is Base64.

Added: 03-24-18

Ensure the file encoding is valid. Currently the IRS only supports Base 64 file encoding for transmission through IDES. Re-encrypt the payload and repost the file to IDES. The IRS will send another notification to you through IDES after we have downloaded and processed your file further.

Added: 03-24-18

The IRS could not decompress the file with the IDES file ID, transmission ID and timestamp after download from IDES. This failure occurred either because the file was compressed using an unsupported compression tool/algorithm, one or more files in the transmission are missing compression (not zipped), or because the file became corrupted after compression but before the AES encryption step.

Please recompress the digitally signed XML file using a supported compression tool, and create a new IDES transmission with this file, following all procedures (see the IDES User Guide, available on the IRS IDES Homepage) for IDES transmission preparation and upload. The IRS will send another notification to you through IDES once your file has been downloaded and processed further.

For a list of recommended tools and additional instructions, please refer to the IDES User Guide, available on the IRS IDES Homepage.

The IRS could not decrypt the referenced file following download from IDES because the AES-256 key file was either blank, missing or could not be decrypted, or because the decryption process failed to complete. There are several situations that may have occurred:

1. the AES key provided with the file was not the same as the AES key used to encrypt the payload
2. the AES key used to encrypt is of the wrong type
3. the AES key used to encrypt is missing completely
4. the public IRS key used to encrypt the AES key was not valid
5. the encryption settings were incompatible with the IRS decryption algorithm
6. the payload and/or encrypted AES key file was changed or modified after encryption

For security reasons the IRS does not disclose which situation caused the decryption failure. However, if your file was submitted after the July 11, 2016 conversion to CBC encryption, this notification is used to indicate any decryption issue other than an AES key size issue. After the July 11, 2016 conversion, AES key size issues (which indicate potential use of the legacy ECB encryption) are identified specifically by the NKS notification.

First, make sure you have the valid IRS public encryption key on your system, downloaded from IDES. Next, please encrypt the digitally-signed and compressed payload of the referenced file with a new AES key and then encrypt the new AES key with the valid IRS public key. Insert the re-encrypted payload and AES key files and a new XML header in an archive to create the IDES transmission. Finally, upload the transmission to IDES following all additional procedures (see IDES User Guide, available on the IRS IDES Homepage) for transmission preparation and upload. The IRS will send another notification to you through IDES once your file has been downloaded and processed further.

Please follow the procedures in the IDES User Guide, available on the IRS IDES Homepage, and your local encryption software to generate a unique, one-time use AES-256 key. You should be using this unique, one-time use AES-256 key to encrypt your payload and the valid IRS public key available on IDES to encrypt the AES key.

The valid IRS key is available on IDES. Please see the IDES User Guide, available on the IRS IDES Homepage, for additional information and instructions on how to find and download the IRS public key for encrypting the AES key for transmission.

Please see the IDES User Guide, available on the IRS IDES Homepage, and the main IDES Service page, for additional information and instructions on how to find and download the IRS public key for encrypting the AES key for transmission to the IRS. Also, please consult the documentation for your encryption software application for assistance in importing the IRS public key into your system after downloading.

The IRS could not download the referenced file that had been posted to IDES.

The IRS automatically downloads transmissions from IDES after receiving an alert from IDES that a transmission is available for download. We do not divulge the exact cause or reason for the failure of the automated process, but a system failure or outage on either side of the IRS-IDES connection led to the failure to download.

Please upload the referenced transmission to IDES again by the due date that pertains to your organization, which is included in the notification body. The IRS will be notified when the transmission is available, and will download it at that time.

Because IDES automatically deletes transmissions that are not downloaded within seven days of upload, your transmission is no longer available on IDES. You must upload the transmission to IDES again to satisfy FATCA requirements. Please refer to the IDES User Guide, available on the IRS IDES Homepage, if you have any questions on how to prepare and upload transmissions to IDES. The IRS will be notified by IDES when your transmission is available, and will download it at that time.

The IRS has not been able to process your file, so we cannot provide any feedback at this time on whether it is valid or not. After we have downloaded your transmission from IDES, we will process it and notify you of the results, including whether the file was successfully processed or if any additional errors were identified.

The referenced file failed validation against the Intergovernmental FATCA XML Schema.

There were one or more validation errors identified on your file. The IRS does not provide specific error information for this type of file error, but these errors can be identified by using any widely accepted XML validation tool.

Use of the ampersand (&) and less than (<) symbols are prohibited as they are not allowed by XML syntax rules and will cause the transmission to be rejected with a failed schema error notification. These symbols must be replaced with entity references.

Substituting any ampersand symbols with "&amp;" and less than symbols with "&lt;" in XML files will prevent the generation of the error notification.

The IRS could not validate the digital signature on the payload file with the IDES file ID, transmission ID and timestamp, with your organization’s valid public key on IDES.

Please re-sign the file using the specific instructions for signing the XML file in the “Data Preparation for FATCA XML Report” section of the IDES User Guide, available on the IRS IDES Homepage as well as the procedures for your local encryption software package. Ensure that you are use the digital signature “enveloping” type as the enveloped and detached types will cause the transmission to fail. Then recreate and upload the transmission to IDES following all additional procedures (see the IDES User Guide, available on the IRS IDES Homepage) for transmission preparation and upload.

Please follow the procedures for your local encryption software and for IDES. The IDES User Guide contains the signature methods acceptable for use in FATCA filing. See the IDES User Guide, available on the IRS IDES Homepage, and your local encryption software for instructions on how to apply the digital signature.

The IRS detected one or more security threats or prohibited character strings embedded in the decrypted version of the payload and/or Sender Metadata files. The IRS cannot accept files with these embedded security threats or strings.

For security reasons the IRS does not disclose specific threats identified on electronic communications received from third parties, or what is used to identify these threats. However, these threats can include items such as:

• hyperlinks embedded within received files
• JavaScript components
• executable files (e.g., .exe files)
• compressed archive files
• character strings specifically prohibited by the IRS

These items should not be part of any submitted file.

Note the full list of restricted character strings and optional and non-optional entity reference substitutions is provided in FATCA XML Schema Best Practices for Form 8966). As these character strings would not be detected by an antivirus product, you will need to take other measures to ensure these characters are not present in any of your files.

Please remove all prohibited characters from the payload and Sender Metadata files, then rebuild the full transmission for this payload file by following all procedures (see the IDES User Guide, available on the IRS IDES Homepage) and scanning for viruses and other security threats with up-to-date antivirus software at each step in the process (digital signature, compression, encryption of the payload and AES key files, creation of the IDES metadata file, creation of the full transmission files) and upload the full transmission to IDES. The IRS will send another notification to you through IDES once your file has been downloaded and processed further.

As prohibited characters would not be detected by an antivirus product, you will need to take other measures to ensure these characters are not present in any of your files. Generally, any up-to-date and widely accepted antivirus software product should be capable of finding any other threat the IRS detected. The IRS uses such products for virus and threat detection and removal. However, the IRS does not recommend the use of a particular product for this purpose.

It is the sender’s responsibility to ensure all files are virus and threat free and comply with all IRS requirements and restrictions. Please contact your local IT support staff for assistance with this step, or consult the IDES User Guide and documentation provided by your antivirus software provider. The IRS cannot provide technical assistance with this process.

The IRS detected one or more known viruses within the decrypted version of the referenced file following download from IDES. The IRS cannot accept a file with viruses present.

For security reasons the IRS does not disclose specific viruses identified on electronic communications received from third parties, or what is used to identify viruses. However, the viruses the IRS detects are typically found by up-to-date commercial anti-virus products.

Please rebuild the full transmission for this payload file by following all procedures (see the IDES User Guide, available on the IRS IDES Homepage) and scanning for viruses and other security threats with up-to-date antivirus software at each step in the process (digital signature, compression, encryption of the payload and AES key files, creation of the IDES metadata file, creation of the full transmission files), then upload the full transmission to IDES. The IRS will send another notification to you through IDES once your file has been downloaded and processed further.

Generally, any up-to-date and widely accepted antivirus software product should be capable of finding the virus that the IRS detected. The IRS uses such products for virus and threat detection and removal. However, the IRS does not recommend the use of a particular product for this purpose.

It is the sender’s responsibility to provide clean files, and to ensure all files are virus and threat free. Please contact your local IT support staff for assistance with this step, or consult the documentation provided by your antivirus software provider. The IRS cannot provide technical assistance with this process.

Since this data is considered to be test data, and the IRS discourages submission of test data in its production environments, no further action should be taken with respect to this record. Please do not attempt to void, correct, or amend this record with additional test data. However, if you determine that the record is a valid record please resubmit with the proper DocTypeIndic value through IDES to the ICMM production environment.

Updated: 03-01-2018

This record does not need to be voided or otherwise modified in the test environment. If the records are valid production submissions, please submit through IDES to the ICMM production environment.

Added: 09-14-15

The IRS has received and successfully completed processing of your file. At this time, one or more record-level errors have been identified in your file and require correction. You will need to correct all identified record-level errors and resubmit the file

Added: 09-14-15

It is possible for a FATCA XML file to validate against the FATCA Intergovernmental Schema while not complying with FATCA reporting requirements. The FATCA XML User Guide (IRS Publication 5124) details rules for FATCA data elements needed to validate against the FATCA schema, as well as mandatory data elements and values which extend beyond validation but are needed to satisfy reporting requirements

Updated: 03-03-16

The record indicated by the DocRefId value included with the error descriptions in the notifications is the record that must be corrected and resubmitted.

Updated: 03-03-16

Only the record with the corrected data needs to be resubmitted. However, since the record must be transmitted in a valid FATCA Report file, the full file must have sufficient data from the original file to pass XML validation and other checks, as defined in IRS Publication 5124 PDF, including MessageSpec and Reporting FI data elements. In addition, the following changes from the original file are necessary:

• The DocTypeIndic value should be “FATCA2” for corrected data
• The MessageRefId and DocRefId values for the file being corrected must be provided in the CorrMessageRefId and CorrDocRefId fields for the submitted file.

Updated: 03-03-16

The “TIN not in IRS specified format” error is generated when a non-GIIN value for a TIN data element is not in a valid format for a U.S. TIN. A value for a TIN data element must be either in a GIIN format or in one of the following formats for a U.S. TIN to be considered valid when filed:

• Nine consecutive numerical digits without hyphens or other separators (e.g., “123456789”)
• Nine numerical digits with two hyphens, one hyphen entered after the third numeric digit and a second hyphen entered after the fifth numeric digit (e.g., “123-45-6789”)
• Nine numerical digits with a hyphen entered after the second digit (e.g., “12-3456789”)

If a filer has confirmed that the Account Holder is not required to have a US TIN in the agreed upon format then the filer does not need to re-file to correct this specific error. Any other errors included in the notification must be corrected and the filer should re-submit a corrected file for those errors only. The Account Holder TIN must be provided and cannot be blank characters in the TIN data sub-element.

Updated: 03-24-18

The “TIN not in IRS specified format, contains only one character repeated" error is generated when a US TIN is in one of the valid formats specified in Q7 above, but consists of nine digits that are all the same (ex. 555555555, 111-11-1111, 33-333333) or when a non-US TIN, which does not have to conform to the formats specified in Q7, consists of digits or characters that are all the same (ex. 9999999, XXXXXXX). A valid TIN will not consist only of one repeated character, regardless of country of origin.

If a filer has confirmed that the Account Holder is not required to have a US TIN in the agreed upon format then the filer does not need to re-file to correct this specific error. Any other errors included in the notification must be corrected and the filer should re-submit a corrected file for those errors only. The Account Holder TIN must be provided and cannot be blank characters in the TIN data sub-element.

Updated: 03-24-18

The “TIN not in IRS specified format, contains non-numeric characters" error is generated when a US TIN is in one of the valid formats specified in Q7 above, but includes any characters other than numeric digits (1-9) or "-" in the positions specified in Q7. A valid US TIN will not include any non-numeric characters.

If a filer has confirmed that the Account Holder is not required to have a US TIN in the agreed upon format then the filer does not need to re-file to correct this specific error. Any other errors included in the notification must be corrected and the filer should re-submit a corrected file for those errors only. The Account Holder TIN must be provided and cannot be blank characters in the TIN data sub-element.

Updated: 03-24-18

Though the nine digits in the US TIN you have provided are the correct TIN for the person or entity being documented, you may have used an incorrect format for the TIN. Please see Question 7 above for the correct formats to be used for US TINs in FATCA reporting.

Updated: 03-24-18

The 21 record-level error codes, descriptions, and remedial actions are provided in Section 5.4 of Publication 5189, The ICMM Notifications User Guide PDF.

Updated: 03-24-18

Each record will be associated with a report-level DocRefID (Account, Pooled or Nil Report DocRefID) as well as one or more organization-level DocRefIDs (ReportingFI DocRefID, Intermediary DocRefID, and/or Sponsor DocRefID). If any of these DocRefIDs do not follow the DocRefID formatting requirements (see FATCA XML Schemas Best Practices for Form 8966 DocRefId), you will receive an “Invalid DocRefID” error. All DocRefIDs in the record should be checked to ensure they follow the formatting requirements. Please note that DocRefIDs must not include any non-alphanumeric characters, excluding periods and dashes. Prohibited non-alphanumeric characters include but are not limited to_, @, +, &, ! and *.

Updated: 04-18-18

The record-level error codes 8001 (Pooled Report Error), 8007 (Account Report Error), and 8013 (Nil Report Error) indicate errors found with specific data elements in the record that must be corrected through a resubmission. In these cases the notifications will contain a “FieldErrorGrp” for each field-level error, with a description of the error (“FieldErrorTxt”) and the XML path for the data element (“FieldNm”) in error. Field-level errors are provided in the order in which they appear in the FATCA Schema in Figure 4-2 ICMM Field-level Errors for Electronic FATCA XML Reports PDF (pdf 147KB). Each field-level error must be corrected to resolve the record-level error.

Updated: 03-24-18

The procedures to correct, amend, or void specific records below may be applied to those cases in which 1) the ReportingFI/TIN element does not contain a field error, and 2) the filer has not used more than once the DocRefId value of the record being corrected.

When a filer resubmits corrected record data in response to a “valid file with errors” notification from the IRS for an electronically submitted file, the following changes must be made within the “DocSpec” element for the corrected record:

• The “DocTypeIndic” element must be “FATCA2” to denote a corrected record
• The “CorrMessageRefId” element must be set equal to the “MessageRefId” for the original file in which the record being corrected was contained
• The “CorrDocRefId” element must be set equal to the “DocRefId” for the original record being corrected
• All fields identified in the error listing for the record in the notification must be corrected.In addition, all other record elements from the original record submission must be included, and the resubmitted file with the corrected record data must represent a valid FATCA XML file.

Amended records in which a filer chooses to amend (change or edit) previously submitted records are prepared similarly to corrected records. To submit an amended record, the filer must make the following changes within the resubmitted record:

• The “DocTypeIndic” element must be “FATCA4” to denote an amended record
• The “CorrMessageRefId” element must be set equal to the “MessageRefId” for the original file in which the record being amended was contained
• The “CorrDocRefId” element must be set equal to the “DocRefId” for the original record being amended
• All fields in the amended record must have values that the filer wishes to report to the IRS for the relevant account or pooled report.

Voided records in which a filer wishes to delete a previously submitted record are submitted in the following manner:

• The “DocTypeIndic” element must be “FATCA3” to denote a voided record
• The “CorrMessageRefId” element must be set equal to the “MessageRefId” for the original file in which the record being voided was contained
• The “CorrDocRefId” element must be set equal to the “DocRefId” for the original record being voided
• All fields in the voided record must have the same values as the original record being voided (deleted).

Updated: 03-03-16

The IRS agrees that this scenario is not an error by the filer. The ICMM system will misinterpret a MonAmnt_Type element with additional trailing zeroes after the second position to the right of the decimal point in the element; as a result the filer will receive a Valid File Notification (with Record-Level Errors) or NVF Notification because of the additional trailing zeroes. The MonAmnt_Type data with additional trailing zeroes are valid according to the FATCA XML Schema v2.0.

As of March, 24, 2018 this error condition is no longer being reported in NVF Notifications. For notifications received prior to that date, filers that receive an error for that reason (schema-valid MonAmnt_Type value with additional trailing zeroes) may ignore that error in the NVF Notification; those conditions do not require correction. However, please correct all other documented field-level errors on any other elements in the NVF notification.

Updated: 03-24-18

The IRS has received your Form 8966 and has identified errors in your document that require correction. You will need to correct all identified record-level errors and resubmit the Form. Please mark the new form as “Corrected” by checking the box at the top of the first page, and send to the address indicated in the instructions.

Added: 09-14-15

The IRS has received your Form 8966 submitted as an account report and we have identified errors and inconsistencies in your document that require correction. You will need to correct all identified record level errors and resubmit the Form. Please mark the new form as “Corrected” by checking the box at the top of the first page, and send to the address indicated in the instructions.

Added: 09-14-15

These values provide the Part and Line reference, and standard description for each error found on your submitted Form 8966. Field-level errors are provided alphabetically by description in Figure 4-4 ICMM Field-level Errors for Paper Reports PDF (101KB). Each field-level error must be corrected to resolve the overall record-level error.

Added: 09-14-15

Corrected Forms 8966 must have complete entries for all required fields. Please resubmit all data, including corrected data, from your original Form 8966 on your corrected form.

Added: 01-17-17

The IRS has received your Form 8966 submitted as a pool report and we have identified errors and inconsistencies in your document that require correction. You will need to correct all identified record level errors and resubmit the Form. Please mark the new form as “Corrected” by checking the box at the top of the first page, and send to the address indicated in the instructions

Added: 01-17-17

Corrected Forms 8966 for pool reporting must have complete entries for all required fields. Please resubmit all data, including corrected data, from your original Form 8966 on your corrected form.

Added: 01-17-17

The IRS has received your Form 8966 submitted as a nil report and we have identified errors and inconsistencies in your document that require correction. You will need to correct all identified record level errors and resubmit the Form. Please mark the new form as “Corrected” by checking the box at the top of the first page, and send to the address indicated in the instructions.

Added: 01-17-17

Corrected Forms 8966 for nil reporting must have complete entries for all required fields. Please resubmit all data, including corrected data, from your original Form 8966 on your corrected form.

Added: 01-17-17

To resubmit a Form 8966, paper filers should submit a new Form 8966 with all appropriate fields populated with either data from the originally filed form or changes to reflect corrections or amendments

• To correct an account or pooled report, in response to error notifications received from the IRS, make corrections to the fields in the part and line numbers, specified in the error notification, and check the “Corrected Form” box
• To amend or change an account or pooled report, submitted on a previously filed Form 8966, change the fields that need edits and check the “Amended Form” box
• To void or delete a previously filed Form 8966, check the “Voided form” box

In all cases, fields from the original submission, that are not being corrected or edited, must be populated with the same data as the original filing (note: voided forms must include the same data as the original form being voided).

The table in, Figure 4 3 ICMM Record-level Processing Error Codes (paper filing) PDF (10KB), provides the codes, descriptions, and remedial actions needed for record - level errors ICMM will detect in records on paper Forms 8966. Four digit record-level error codes are always provided when record-level errors are present. Unlike the electronic case, in which a single file can contain multiple account reports and pooled reports as records, a single Form 8966 is considered to be a single, standalone record. A filer can only document a single account or pooled report on each paper Form 8966, and cannot file both types of reports on a single form. Also, unlike the electronic case, there is no way to identify a specific Form 8966 submitted by a filer; that is, there is no analog on the paper filing side to the MessageRefId and DocRefId data elements in the FATCA XML schema which can be used to exactly identify prior paper records. The IRS will need to analyze the filing history from a given filer to determine if corrections to errors on specific paper account and pooled reports have been provided. Because there is no way to directly correlate corrections to original submissions with errors, the record-level errors in electronic filing centered on corrected or amended reports with no matching originals have no paper counterparts, so the range of paper record-level errors is smaller.

Updated: 03-03-16

The “TIN not in IRS specified format” error is generated when a non-GIIN value for a TIN data element is not in a valid format for a U.S. TIN. A value for a TIN data element must be either in a GIIN format or in one of the following formats for a U.S. TIN to be considered valid when filed:

• Nine consecutive numerical digits without hyphens or other separators (e.g., “123456789”)
• Nine numerical digits with two hyphens, one hyphen entered after the third numeric digit and a second hyphen entered after the fifth numeric digit (e.g., “123-45-6789”)
• Nine numerical digits with a hyphen entered after the second digit (e.g., “12-3456789”)

If a filer has confirmed that the Account Holder is not required to have a US TIN in the agreed upon format the filer should enter their own country code in the TIN Issued by element and include “NA” (indicating “Not Available”) for the TIN element.  If the filer has already submitted the record and received an error notification for the TIN element, then the filer does not need to re-file to correct this specific error. Any other errors included in the notification must be corrected and the filer should re-submit a corrected file for those errors only. To avoid an error, the Account Holder TIN element must be included and cannot consist of blank characters in the TIN data sub-element.

Updated: 04-19-2021

The “TIN not in IRS specified format, contains only one character repeated" error is generated when a US TIN is in one of the valid formats specified in Q7 above, but consists of nine digits that are all the same (ex. 555555555, 111-11-1111, 33-333333) or when a non-US TIN, which does not have to conform to the formats specified in Q1, consists of digits or characters that are all the same (ex. 9999999, XXXXXXX). A valid TIN will not consist only of one repeated character, regardless of country of origin.

If a filer has confirmed that the Account Holder is not required to have a US TIN in the agreed upon format the filer should enter their own country code in the TIN Issued by element and include “NA” (indicating “Not Available”) for the TIN element.  If the filer has already submitted the record and received an error notification for the TIN element, then the filer does not need to re-file to correct this specific error. Any other errors included in the notification must be corrected and the filer should re-submit a corrected file for those errors only. To avoid an error, the Account Holder TIN element must be included and cannot consist of blank characters in the TIN data sub-element.

Updated: 04-19-2021

The “TIN not in IRS specified format, contains non-numeric characters" error is generated when a US TIN is in one of the valid formats specified in Q1 above, but includes any characters other than numeric digits (1-9) or "-" in the positions specified in Q1. A valid US TIN will not include any non-numeric characters.

If a filer has confirmed that the Account Holder is not required to have a US TIN in the agreed upon format the filer should enter their own country code in the TIN Issued by element and include “NA” (indicating “Not Available”) for the TIN element.  If the filer has already submitted the record and received an error notification for the TIN element, then the filer does not need to re-file to correct this specific error. Any other errors included in the notification must be corrected and the filer should re-submit a corrected file for those errors only. To avoid an error, the Account Holder TIN element must be included and cannot consist of blank characters in the TIN data sub-element.

Updated: 04-19-2021

Though the nine digits in the US TIN you have provided are the correct TIN for the person or entity being documented, you may have used an incorrect format for the TIN. Please see Question 1 above for the correct formats to be used for US TINs in FATCA reporting.

Added: 03-24-18

The IDES alert of a successful upload is information about the transmission of your file. IDES alerts cannot provide information about the receipt and processing of your files by IRS ICMM. The IRS should issue an ICMM Notification for every FATCA Report that is successfully transmitted through IDES letting you know the status of your FATCA Report. You should always receive a Notification within 24 hours, and in most cases within a few minutes, of the IRS ICMM system receiving your file. However, the IRS has identified specific instances during testing where ICMM Notifications are not issued to filers when certain errors are present. In addition, the IRS has identified circumstances in which filers did not download their notifications before the 7 day retention period expired, and these notifications were deleted and are no longer available for download. The IRS is working to address and resolve these issues.

In the meantime, there are a few things you can do to maximize your ability to receive notifications sent to you, and to determine whether a notification has been sent to in response to your file. These are as follow:

• First, make sure that e-mail alerts from IDES are not blocked as SPAM by your own e-mail system. Your e-mail system may have deleted it or may have sent it to you SPAM inbox. If you have been sent an alert that a notification is present, but the alert email is blocked you may never be aware of the notification’s availability for download.
• Second, make sure your IDES User Profile is configured to allow IDES to send you e-mails, including alerts regarding notifications. There is a box that can be set to either send or not send you an e-mail notification. If you would like to receive and e-mail notification make sure it is set to send e-mail notification.
• Third, check your IDES inbox over the next 24 hours following the upload of your file to IDES to determine whether there is a Notification waiting for download. Even if you have not received an e-mail Alert, the Notification could still be in your folder ready for download. After seven days the notification will automatically be deleted from the system.

If you have checked your folder in IDES and there is no Notification present after 48 hours or longer since your file was uploaded successfully, an error types which is suppressing a notification from being sent may have been detected on your file. A few things to check that may help include the following:

• Making sure the digital certificate you are using for signature and encryption for FATCA data has not expired or been revoked by your Certificate Authority.
• Also, you should double check the Metadata XML file that is part of your data packet, to ensure all of the mandatory data elements are correct. In particular, please make sure that FATCAEntCommunicationTypeCd is set to “RPT”, and that the TaxYear is set to “2014.”
• Make sure all of the entries are correct. Did you indicate you were submitting a FATCA Report? Did you select the correct tax reporting year (it should be 2014)? Etc.

Once you’ve checked these items, you should resubmit your file.

It is possible that you submitted your FATCA Report production files to the FATCA Report test environment instead of to the FATCA Report production environment. Any production files that are submitted to the test environment will not be processed and will need to be re-submitted to the production environment. Please do not submit production files to the test environment. In addition, please do not submit test files to the production environment.

The IRS could not decrypt the referenced file because the size of AES key file was incorrect. The IRS expects a 48 byte AES key file, consisting of a 32 byte (256 bit) key and 16 byte (128 bit) initialization vector combined in a 48 byte encrypted file. Please do not submit a request to correct, amend or void any of the records in this file until you receive a notification that this file has been received as valid. For more information on this notification, including the classification of a failed file decryption under an intergovernmental agreement (IGA), please see: FATCA Error Notifications. For more information on formatting the AES key file, please consult the IRS IDES Homepage.

Added: 01-17-17

This notification indicates an issue specifically with the AES key file size. You may not be using the CBC cipher, required as of July 11, 2016 or the AES key file size may be incorrect for another reason.

Added: 01-17-17

Please follow the procedures in the IDES User Guide, available on the IRS IDES Homepage, and your local encryption software to generate a unique, one-time use AES-256 key with CBC ciphering. You should be using this unique, one-time use AES-256 key to encrypt your payload and the valid IRS public key available on IDES to encrypt the AES key. Ensure that your 16-byte initialization vector is included with your AES key in the encrypted key file.

Added: 01-17-17

Please refer to the IDES User Guide, available on the IRS IDES Homepage, and your local encryption software for specific instructions on using the AES-256-CBC encryption process.

Added: 01-17-17

The IRS could not download the referenced file that had been posted to IDES. Your specified file format type and actual file contents were inconsistent.

Added: 03-24-18

The IRS supports 5 file formats:

Added: 03-24-18

Ensure the specified file format type and actual file contents are consistent and repost the file to IDES. Ensure the specified file format is one of the approved types that can be sent to the IRS. Ensure the file type included in the IDES metadata is consistent with the file type of the enclosed notification.

Added: 03-24-18

One or more records with DocRefId schema fields in the submitted file consist of one or more blank characters or exceed 200 characters in length. This field should contain the unique identifier of the specific account or pooled report it references and is required to be at least one, but not more than 200, alphanumeric characters, and cannot be all-blank characters.

Updated: 03-24-18

The FATCA XML Schema User Guide (IRS Publication 5124 available at FATCA XML Schema) states that the DocRefId data element should contain the unique identifier of the specific account or pooled report it references. Currently the IRS’s more specific requirements for DocRefIds are not reflected in the XML schema so DocRefId validation errors will not be detected by a schema validation tool. The IRS requires non-blank DocRefIds that follow the format of <ReportingGIIN>.<UniqueValue> and are no more than 200 characters in length in order to be able to accept your file.

Updated: 03-03-16

Please correct the file by ensuring DocRefIds for all records follow the required DocRefId format (<ReportingGIIN>.<UniqueValue>) per the guidance at FATCA XML Schemas Best Practices for Form 8966 DocRefId Ensure that they contain no blank spaces and are no more than 200 characters in length. Use this file to recreate an IDES transmission and upload to IDES following all procedures (see IDES User Guide, available on the IRS IDES Homepage) for transmission preparation and upload. The IRS will send another notification to you through IDES after we have downloaded and processed your file further.

The MessageRefId schema field in the referenced file consists of one or more blank characters or exceeds 200 characters in length. This field should be a unique identifier for a report file and is required to be at least one, but not more than 200, alphanumeric characters and cannot be all blank characters.

Updated: 03-03-16

The FATCA XML User Guide (IRS Publication 5124 available at FATCA XML Schema) states that the MessageRefId should be a unique identifying number (created by the sender) that identifies the particular message being sent. Although a MessageRefId consisting of all blanks is valid against the schema, the IRS does not consider a blank MessageRefId to be unique. Furthermore, the IRS has limited the MessageRefId and DocRefId fields to 200 characters. The IRS requires non-blank MessageRefIds and DocRefIds that are no more than 200 characters in length in order to be able to accept your file.

Updated: 04-11-17

Please correct the file by including a unique, valid alphanumeric character string in the MessageRefId field (see the FATCA XML User Guide, IRS Publication 5124 available at FATCA XML Schema) that does not consist of all blanks and that is no more than 200 characters in length. Use this file to recreate an IDES transmission and upload to IDES following all procedures (see the IDES User Guide, available on the IRS IDES Homepage) for transmission preparation and upload. The IRS will send another notification to you through IDES once your file has been downloaded and processed further.

Updated: 04-11-17

Form 8809-I PDF needs to be submitted. Please follow the instructions for that form.

Updated: 03-24-2018

Form 8508-I PDF needs to be submitted. Please follow the instructions for that form.

Updated: 03-01-2018