IRS Logo
Print - Click this link to Print this page

ICMM Frequently Asked Questions (FAQs)

The links below will take you to FAQs for each specific notification type. These notifications may be sent from the IRS after files have been processed by the IRS System, the International Compliance Management Model (ICMM).  You can use the 3-letter code included in your error notification and in parentheses below to find the specific section relevant to your error notification.

Failed Download Notification (NDW)

Q1. Why did my organization receive this notification?
Q2. What could have prevented the IRS from downloading this transmission?
Q3. What do I need to do as a result of this notification?
Q4. Why can’t the IRS download the transmission now?
Q5. Was there a problem with the contents of my file?

Failed Decryption Notification (NDC)

Q1. Why did my organization receive this notification
Q2. Which specific decryption step failed?
Q3. What do I need to do as a result of this notification?
Q4.
What key should I use to encrypt my files?
Q5. How do I determine if the IRS public key I am using is the correct version?
Q6.
How do I download the valid public key for the IRS?

Incorrect AES Key Size (NKS)

Q1. Why did my organization receive this notification?
Q2. Which specific decryption step failed?
Q3.
What key should I use to encrypt my files?
Q4. How do I ensure I am using the right encryption method?

Failed Decompression Notification (NDP)

Q1. Why did my organization receive this notification?
Q2. What do I need to do as a result of this notification?
Q3. What tool should I be using to compress the file?

Failed Signature Check Notification (NSC)

Q1. Why did my organization receive this notification?
Q2. What do I need to do as a result of this notification?
Q3. How do I digitally sign the file?

Failed Threat Scan Notification (NTD)

Q1. Why did my organization receive this notification?
Q2. What threat did the IRS detect?
Q3. What do I need to do as a result of this notification?
Q4. What antivirus product should I use to clean my file?
Q5. What should I do if I need help with scanning my file for threats?

Failed Virus Scan Notification (NVS)

Q1. Why did my organization receive this notification?
Q2. What was the specific validation error or error that the IRS detected on my file?
Q3. Are there any characters that are not allowed due to XML syntax rules and should be avoided in submitted XML documents?
Q4. Is there any namespace or element-specific XML guidance?
Q5. What do I need to do as a result of this notification?

Failed Schema Notification (NSV)

Q1. Why did my organization receive this notification?
Q2. What was the specific validation error or error that the IRS detected on my file?
Q3. Are there any characters that are not allowed due to XML syntax rules and should be avoided in submitted XML documents?

Invalid MessageRefId Notification (NMR)

Q1. Why did my organization receive this notification?
Q2. Why was this issue not identified by my XML validation tool?
Q3. What do I need to do as a result of this notification?

Duplicate MessageRefId Notification (NDM)

Q1. Why did my organization receive this notification?
Q2. Why was this issue not identified by my XML validation tool?
Q3. What do I need to do as a result of this notification?

Invalid DocRefId Notification (NDR)

Q1. Why did my organization receive this notification?
Q2. What was this issue not identified by my XML validation tool?
Q3. What do I need to do as a result of this notification?

If You Have Not Received Your ICMM Notification Within 24 hours

Q1. I uploaded a FATCA Report to IDES 3 days ago.  I received an Alert from IDES via e-mail that my file was successfully uploaded, but I have not received a Notification back from the IRS about the status of my FATCA Report. What could be wrong?

Q2. What if I have mistakenly submitted my FATCA Report production files to the FATCA Report test environment?

Request for Additional Extension of Time to File Form 8966

Q1. How do I submit a request for additional extension of time to file Forms 8966? 

Request for Waiver from Filing Form 8966 Electronically

Q1. How do I submit a request to waive the requirement to file Forms 8966 electronically?

Field Level Errors

Q1. What should I do if I received a field-level error message in the valid file notification that does not appear to be consistent with the FATCA Schema Guidance for “Account Holder Type Not Valid” or “Pooled Reporting Type Not Populated?”
Q2. What should I do if I have already attempted to correct the errors specifically described in Q1 by resubmitting a file?

FATCA ICMM Notifications and Record-level Errors

1.1 FATCA Notification Code NTP: File Contains Test Data for Production Environment

Q1. Do I need to void or correct this record?

1.2 FATCA Notification Code NPT: File Contains Production Data for Test Environment

Q2. Do I need to void or correct this record?

1.3 FATCA Notification Code NVF: Valid File Notification (With Record-Level Errors)

Q3. What does this notification mean? 
Q4. Why weren’t these errors identified by my XML validation tool?
Q5.
Which record contained the detected errors?
Q6. Do I need to resubmit the entire file or just the corrected record?
Q7. What triggers a “TIN not valid” error message?
Q8. I have verified that the US TIN (in SSN or EIN form) for my reporting FI, intermediary, account holder, or substantial owner is correct; why am I getting the “TIN not valid” error?
Q9. How do I submit a Date of Birth in place of a TIN for a U.S. account holder if I am reporting from a Model 1 or Model 2 jurisdiction and do not have a TIN?
Q10. What do the record-level error codes in the notification mean?
Q11. Do I need to correct data submitted in my FATCA Record file?
Q12. How do I submit my corrected, amended, or void data?
Q13. We received an error message regarding the amount shown in the payments field in Schema version 2.0.  We reviewed the file but were unable to determine why a record-level error was returned.  The IRS replied that the error was issued because the file included more than two zeroes to the right of the decimal place in the field specified for payment amounts.  The additional zeroes were routinely added by our back-end system and are not significant.  Why this was considered an error?

1.4 ICMM Record-level Error Notifications for Paper Forms 8966

Q14. What does this notification mean?
Q15.
What does the record-level error code in the notification mean?
Q16. What do “Field ID” and “Field Error Description” in the notification pertain to?
Q17.
 Do I need to resubmit the complete form or just corrections to the errors?

1.5 ICMM Paper Pooled Report Error Notification for Paper Forms 8966

Q18. What does this notification mean?
Q19. Do I need to resubmit the complete form or just corrections to the errors?

1.6 ICMM Paper Pooled Report Error Notification for Paper Forms 8966

Q20. What does this notification mean?
Q21. Do I need to resubmit the complete form or just corrections to the errors?
Q22. How do I resubmit my paper Form 8966?

ICMM TIN

Q1. What triggers a “TIN not valid” error message?
Q2. How do I submit a Date of Birth in place of a TIN for a U.S. account holder if I am reporting from a Model 1 or Model 2 jurisdiction and do not have a TIN?
Q3. We are a reporting Model 1 FFI.  We maintain preexisting accounts that are U.S. reportable accounts where we have been unsuccessful in obtaining a U.S. TIN from the account holder.  May we continue to use nine zeroes in place of a U.S. TIN when we report info?

Additional Resources and Support

International Compliance Management Model (ICMM) Related Questions and Comments


Failed Download Notification (NDW)

Q1. Why did my organization receive this notification?
The IRS could not download the referenced file that had been posted to IDES.

Return to Top

Q2. What could have prevented the IRS from downloading this transmission?
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.

Return to Top

Q3. What do I need to do as a result of this notification?
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.

Return to Top

Q4. Why can’t the IRS download the transmission now?
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.

Return to Top

Q5. Was there a problem with the contents of my file?
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.

Return to Top


Failed Decryption Notification (NDC)

Q1. Why did my organization receive this notification?
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:
a) the AES key provided with the file was not the same as the AES key used to encrypt the payload
b) the AES key used to encrypt is of the wrong type
c) the AES key used to encrypt is missing completely
d) the public IRS key used to encrypt the AES key was not valid
e) the encryption settings were incompatible with the IRS decryption algorithm
f) the payload and/or encrypted AES key file was changed or modified after encryption    

Return to Top

Q2. Which specific decryption step failed?
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.

Return to Top

Q3. What do I need to do as a result of this 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.

Return to Top

Q4. What key should I use to encrypt my files?
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.  

Return to Top

Q5. How do I determine if the IRS public key I am using is the correct version?
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.  

Return to Top

Q6. How do I download the valid public key for the IRS?
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.  

Return to Top

 


Incorrect AES Key Size (NKS)

Q1. Why did my organization receive this notification?
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: http://www.irs.gov/Businesses/Corporations/FATCA-Error-Notifications. For more information on formatting the AES key file, please consult the IDES User Guide at https://www.irs.gov/pub/fatca/p5190idesuserguide.pdf.

Added:  01-17-17

Return to Top

Q2. Which specific decryption step failed?
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

Return to Top

Q3. What key should I use to encrypt my files?
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

Return to Top

Q4. How do I ensure I am using the right encryption method?
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

Return to Top

 


Failed Decompression Notification (NDP)

Q1. Why did my organization receive this notification?
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.  

Return to Top    

Q2. What do I need to do as a result of this notification?
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.

Return to Top

Q3. What tool should I be using to compress the file?
For a list of recommended tools and additional instructions, please refer to the IDES User Guide, available on the IRS IDES Homepage.

Return to Top


Failed Signature Check Notification (NSC)

Q1. Why did my organization receive this 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.

Return to Top  

Q2. What do I need to do as a result of this notification?
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.

Return to Top

Q3.  How do I digitally sign the file?
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.

Return to Top


Failed Threat Scan Notification (NTD)

Q1. Why did my organization receive this notification?
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.

Return to Top.

Q2. What threat did the IRS detect?
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.

Return to Top

Q3. What do I need to do as a result of this notification?
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.  

Return to Top

Q4. What antivirus product should I use to clean my file?
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.

Return to Top  

Q5. What should I do if I need help with scanning my file for threats?
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.

Return to Top


Failed Virus Scan Notification (NVS)

Q1. Why did my organization receive this notification?
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.

Return to Top

Q2. What virus did the IRS detect?
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.

Return to Top

Q3. What do I need to do as a result of this notification?
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.

Return to Top

Q4. What antivirus product should I use to clean my file?
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.

Return to Top

Q5. What should I do if I need help with scanning my file for viruses?
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.

Return to Top


Failed Schema Notification (NSV)

Q1. Why did my organization receive this notification?
The referenced file failed validation against the Intergovernmental FATCA XML Schema.

Return to Top   

Q2. What was the specific validation error or error that the IRS detected on my file?
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.

Return to Top

Q3. Are there any characters that are not allowed due to XML syntax rules and should be avoided in submitted XML documents?
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.  

Return to Top


Invalid MessageRefId Notification (NMR)

Q1. Why did my organization receive this notification?
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

Return to Top

Q2. Why was this issue not identified by my XML validation tool?
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

Return to Top

Q3. What do I need to do as a result of this notification?
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

Return to Top


Duplicate MessageRefId Notification (NDM)

Q1. Why did my organization receive this notification?
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

Return to Top

Q2. Why was this issue not identified by my XML validation tool?
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

Return to Top

Q3. What do I need to do as a result of this notification?
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

Return to Top


Invalid DocRefId Notification (NDR)

Q1. Why did my organization receive this notification?
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 or otherwise do not follow the required format of <ReportingGIIN>.<UniqueValue>. These fields 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-03-16

Return to Top   

Q2. What was this issue not identified by my XML validation tool?
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

Return to Top

Q3. What do I need to do as a result of this notification?
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.

Return to Top


If You Have Not Received Your ICMM Notification Within 24 hours

Q1. I uploaded a FATCA Report to IDES 3 days ago.  I received an Alert from IDES via e-mail that my file was successfully uploaded, but I have not received a Notification back from the IRS about the status of my FATCA Report. What could be wrong?

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.

Return to Top

Q2. What if I have mistakenly submitted my FATCA Report production files to the FATCA Report test environment?
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.

Return to Top


Request for Additional Extension of Time to File Form 8966

Q1. How do I submit a request for additional extension of time to file Forms 8966?
An automatic 90-day extension of time to file Form 8966 may be requested. To request an automatic 90-day extension of time to file Forms 8966, file Form 8809-I. See the Instructions for Form 8809-I for where to file that form. You should request an extension as soon as you are aware that an extension is necessary, but no later than the due date for filing Forms 8966. No extension of time to file is permitted for Forms 8966 filed by a Reporting Model 2 FFI to report a non-consenting U.S. account or a non-consenting nonparticipating FFI. A Reporting Model 2 FFI should refer to the applicable Model 2 IGA for the due dates for those filings.  Under certain hardship conditions, the IRS may grant an additional 90-day extension to file Form 8966. See Regulations section 1.1471-4(d)(3)(vii). To request an additional 90-day extension of time to file Form 8966, file a second Form 8809-I before the end of the initial extended due date. See the instructions to Form 8809-I for more information on the requirements for requesting an additional extension for filing Form 8966.

Please note:  You must receive a response from the IRS indicating that they approve or deny your extension request.   

Note:  You must submit a separate request for each filer (for example, if you are requesting an additional extension of time to file Form 8966 both on behalf of yourself and with respect to reporting on behalf of a sponsored entity, you must submit two requests).

Updated:  04-28-17

Return to Top


Request for Waiver from Filing Form 8966 Electronically

Q1. How do I submit a request to waive the requirement to file Forms 8966 electronically?
You should file Form 8508-I at least 45 days before the due date of the Form 8966. Form 8966 is due March 31 of the year following the reporting year, unless you are an FFI reporting under a Model 2 IGA with a different reporting date specified in the applicable Model 2 IGA. Waiver requests will be processed beginning January 1st of the calendar year the return is due. You will be required to submit specific documentation as indicated within the form to substantiate the reason for requesting the waiver.
   
Note:  You must submit a separate request for each filer (for example, if you are requesting a waiver from electronic filing of Form 8966 both on behalf of yourself and with respect to reporting on behalf of a sponsored entity, you must submit two requests).  

Updated:  04-28-17

Return to Top


Field Level Errors

Q1. What should I do if I received a field-level error message in the valid file notification that does not appear to be consistent with the FATCA Schema Guidance for “Account Holder Type Not Valid” or “Pooled Reporting Type Not Populated?”
The Internal Revenue Service (IRS) performed record-level processing of FATCA 8966 XML Report files submitted before August 8, 2015 and transmitted valid file notifications to filers informing them of the number of records processed and any errors within records requiring correction.  The notifications instruct filers to resolve these errors and resubmit corrected records in a valid FATCA XML Report.

The IRS identified two incorrect messages regarding field-level errors that were sent in certain cases due to a system defect.  They are as follow:

  • “Account Holder Type Not Valid” error for an individual filer for whom an entity type is not required. This is for Account Reports in which the account holder is an “Individual”.   
  • “Pooled Reporting Type Not Populated” error.  This is for Pooled Reports only.

If your organization has received either one or both of the error messages within the context of the scenarios described above, further action is not needed. The IRS will resend updated notifications that correct the original notifications. If you have other errors listed in the notifications, please resolve them and resubmit corrections. If the only errors in your notification were one or both of the errors referred to above, you are not required to resubmit corrected records for these errors.

Added:  08-27-15

Return to Top

Q2. What should I do if I have already attempted to correct the errors specifically described in Q1 by resubmitting a file?
If you have already submitted amended files in an attempt to resolve these errors, please resubmit your files following the schema guidance. In order to do this, you should mark the record as a “corrected” record using the following information: “DocTypeIndic” = FATCA2, and use the “CorrMessageRefId” and “CorrDocRefId” values referring back to the original record.  If you made further corrections to other errors in the report you should submit the corrected data not related to the two specific errors described in Q1.

Added:  08-27-15

Return to Top


FATCA ICMM Notifications and Record-level Errors

1.1 FATCA Notification Code NTP: File Contains Test Data for Production Environment

Q1.  Do I need to void or correct this record?
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.

Added:  09-14-15

Return to Top

1.2 FATCA Notification Code NPT: File Contains Production Data for Test Environment

Q2. Do I need to void or correct this record?
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

Return to Top

1.3 FATCA Notification Code NVF: Valid File Notification (With Record-Level Errors)

Q3. What does this notification mean?
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

Return to Top

Q4. Why weren’t these errors identified by my XML validation tool?
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

Return to Top

Q5. Which record contained the detected errors?
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

Return to Top

Q6. Do I need to resubmit the entire file or just the corrected record?
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, 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

Return to Top

Q7. What triggers a “TIN not valid” error message?
The “TIN not valid” 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 US TIN is correct and receives a Valid File Notification (NVF) with a “TIN not valid” error because the original TIN was not in one of the above formats, then the filer does not need to re-file to correct the “TIN not valid” 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:  04-24-17

Return to Top

Q8. I have verified that the US TIN (in SSN or EIN form) for my reporting FI, intermediary, account holder, or substantial owner is correct; why am I getting the “TIN not valid” error?
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 27 above for the correct formats to be used for US TINs in FATCA reporting.

Added:  01-17-17

Return to Top

Q9. How do I submit a Date of Birth in place of a TIN for a U.S. account holder if I am reporting from a Model 1 or Model 2 jurisdiction and do not have a TIN?
Per provisions of Model 1 and Model 2 IGA’s, for 2014 accounts reported in 2015, Model 1 HCTAs and Reporting FIs in Model 2 jurisdictions should include a date of birth if a U.S. TIN is not available for a U.S. account holder or substantial owner. The date of birth must be properly formatted per Publication 5124 and placed in the BirthInfo/Birthdate sub-element of the Accountholder or Substantial Owner element, as appropriate. If a date of birth is provided in lieu of a TIN, filers should leave the TIN sub-element for the Accountholder or Substantial Owner element blank. You will receive a “TIN not populated” error.  Please ignore this particular error message.  You do not need to correct this.

Updated:  03-13-17

Return to Top

Q10. What do the record-level error codes in the notification mean?
The 12 record-level error codes, descriptions, and remedial actions are provided in Figure 4-1 ICMM Record-level Processing Error Codes (electronic filing) (pdf 75KB).

Added:  09-14-16

Return to Top

Q11. Do I need to correct data submitted in my FATCA Record file?
The record-level error codes 8001 (Pooled Report Error) and 8007 (Account 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 alphabetically by description in Figure 4-2 ICMM Field-level Errors for Electronic FATCA XML Reports (pdf 147KB). Each field-level error must be corrected to resolve the record-level error.

Added:  09-14-16

Return to Top

Q12. How do I submit my corrected, amended, or void data?
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

Return to Top

Q13. We received an error message regarding the amount shown in the payments field in Schema version 2.0.  We reviewed the file but were unable to determine why a record-level error was returned.  The IRS replied that the error was issued because the file included more than two zeroes to the right of the decimal place in the field specified for payment amounts.  The additional zeroes were routinely added by our back-end system and are not significant.  Why this was considered an error?
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.

The IRS will correct the misinterpreted error condition from being reported in NVF Notifications.  Until then, filers that receive the same record-level error for the same reason (schema-valid MonAmnt_Type value with additional trailing zeroes) may ignore the errors in the NVF Notification; these conditions do not require correction. However, please correct all other documented field-level errors on any other elements in the NVF notification.

Added:  04-20-17

Return to Top

1.4 ICMM Record-level Error Notifications for Paper Forms 8966

Q14. What does this notification mean?
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

Return to Top

Q15. What does the record-level error code in the notification mean?
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

Return to Top

Q16. What do “Field ID” and “Field Error Description” in the notification pertain to?
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

Return to Top

Q17. Do I need to resubmit the complete form or just corrections to the errors?
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

Return to Top

1.5 ICMM Paper Pooled Report Error Notification for Paper Forms 8966

Q18. What does this notification mean?
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

Return to Top

Q19. Do I need to resubmit the complete form or just corrections to the errors?
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

Return to Top

1.6 ICMM Paper Pooled Report Error Notification for Paper Forms 8966

Q20. What does this notification mean?
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

Return to Top

Q21. Do I need to resubmit the complete form or just corrections to the errors?
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

Return to Top

Q22. How do I resubmit my paper Form 8966?
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

Return to Top


ICMM TIN

Q1. What triggers a “TIN not valid” error message?
 

The “TIN not valid” 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:

  • 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 US TIN is correct and receives a Valid File Notification (NVF) with a “TIN not valid” error because the original TIN was not in one of the above formats, then the filer does not need to re-file to correct the “TIN not valid” 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:  04-24-17

Return to Top

Q2. How do I submit a Date of Birth in place of a TIN for a U.S. account holder if I am reporting from a Model 1 or Model 2 jurisdiction and do not have a TIN?
Per provisions of Model 1 and Model 2 IGA’s, for 2014 accounts reported in 2015, Model 1 HCTAs and Reporting FIs in Model 2 jurisdictions should include a date of birth if a U.S. TIN is not available for a U.S. account holder or substantial owner. The date of birth must be properly formatted per Publication 5124 and placed in the BirthInfo/Birthdate sub-element of the Accountholder or Substantial Owner element, as appropriate. If a date of birth is provided in lieu of a TIN, filers should leave the TIN sub-element for the Accountholder or Substantial Owner element blank. You will receive a “TIN not populated” error.  Please ignore this particular error message.  You do not need to correct this.

Updated:  03-13-17

Return to Top

Q3. We are a reporting Model 1 FFI.  We maintain preexisting accounts that are U.S. reportable accounts where we have been unsuccessful in obtaining a U.S. TIN from the account holder.  May we continue to use nine zeroes in place of a U.S. TIN when we report information in 2018 on that account with respect to the 2017 year?
No.  Prior to 2017, Article 3(4) of the Model 1 IGA provided that a reporting Model 1 FFI was not required to report a U.S. TIN for the account holder of a preexisting account if the TIN was not in the FFI’s records; instead, the FFI could report the account holder’s date of birth if the date of birth was in the FFI’s records. The IRS published an FAQ to explain how to report an account holder for which the FFI did not have a TIN (i.e., either entering nine zeros or omitting the TIN and receiving an error message that should be ignored).  See ICMM FAQ Q9 for updated rules for complying with Article 3(4) for reporting in 2017 with respect to the 2016 year.

Article 6(3)(b) of the Model 1 IGA provides that by January 1, 2017, the Model 1 jurisdiction commits to establish rules requiring reporting Model 1 FFIs to obtain U.S. TINs for preexisting accounts for reporting with respect to 2017 and later years.  Beginning January 2018, the IRS will update its record validation rules so that error notifications will be sent if a reporting Model 1 FFI reports nine zeros as the TIN for an account holder.  

If you have questions regarding the obligations under the IGA between the U.S. and your jurisdiction, or any domestic legislation passed to implement the provisions of the IGA, please contact the office of the Competent Authority in your jurisdiction.

Added:  04-24-17

Return to Top


Additional Resources and Support

FATCA File Notification Support

If you need additional assistance with your FATCA file notifications, you will find a link in the notification itself that provides a link to a similar website that includes contact information for additional support.

Please see the resources below for assistance with other FATCA related systems:

  • For assistance with IDES-related issues, see the IDES website

Return to Top


International Compliance Management Model (ICMM) Related Questions and Comments

For ICMM related questions and comments please send your e-mail to ICMM Customer Support.

The ICMM Webpage and ICMM FAQs are updated on a regular basis with information related to ICMM and with answers to ICMM questions. You may submit a question here if you do not find the information you need elsewhere. Due to the volume of questions received, the IRS is unable to provide personalized responses, but answers to the most frequently asked questions will be posted periodically.

NOTE:  Do not provide any personal identification information such as your name, taxpayer identification number, social security number, address, or telephone number.

Page Last Reviewed or Updated: 28-Apr-2017