This page provides information about FATCA reporting, systems and data.
- Correcting, voiding and amending reports
- FATCA report types
- Providing your Australian Business Number (ABN)
- Reporting the Sponsor Global Intermediary Identification Number (GIIN) correctly
- Sponsored Entities requirements
- Trustee Documented Trust (TDT) reporting
- FilerCategory requirements
- Consider when to archive
- Effect of the CRS wider approach on FATCA
- Reporting differences between FATCA and CRS
- Nil reports
- New lodgment validation rule
- Restricted characters
- Reporting account holder United States taxpayer identification numbers (TINs)
- Due diligence actions where account holder US taxpayer identification number (TIN) is missing
- How to report missing US TINs
- Wrapper header
- Thresholds – Record keeping requirements
- Single file limitation and extension of BDE functionality
- DocRefId format requirements
- Update to the format requirements for the DocRefId
- Account Holder Type (AcctHolderType) requirements
- MessageRefId requirements
The FATCA reporting period is 1 January to 31 December. The report is due to be lodged by 31 July the following year.
FATCA reports can be lodged through the Business Portal or Tax Agent Portal. In addition, from 1 January 2018 FATCA reports can be lodged using Standard Business Reporting (SBR)-enabled software for the 2017 reporting period onwards.
If a FATCA report fails ATO validation at lodgment, the file must be corrected and the entire report re-lodged.
If the ATO accepts a lodgment but theUnited States Internal Revenue Service (IRS) detects an error in the lodged report, the IRS will provide the ATO with an error notification. ATO staff will contact you if corrective action is required.
The DocTypeIndic data element specifies the type of data being submitted. The following report types are used to lodge new data, corrected data, void data and amended data:
- FATCA1 (new data) – new data that has not previously been processed or voided.
- FATCA2 (correction) – corrected reports are only lodged when responding to a request from ATO staff to correct specific data. This would occur where there is an IRS record-level error notification.
- FATCA3 (void) – void reports are lodged to delete previously IRS processed reports. If there are specific errors in the original report ATO staff may request you lodge a void report. Users may also void a report at any time if they become aware of inaccurate information.
- FATCA4 (amendment) – amended reports are lodged to amend a previously lodged report that is later found, by you, to contain incorrect information. If, after lodging a report, you identify that some account holders were omitted from the report, you should lodge a new original report with just those omitted accounts and account information included. Users are able to amend a record in a previously IRS processed report at any time. This report type is NOT to be used in response to an IRS error notification.
The MessageRefId and DocRefId requirements (unique identifiers) for reporting a correction, void or amendment:
- When lodging a FATCA2, FATCA3 or FATCA4 report, it must have its own unique MessageRefId and refer to the report that is being corrected by inserting the original (FATCA1) report’s MessageRefId in the CorrMessageRefId element.
- When lodging a FATCA2, FATCA3 or FATCA4 report, it must have its own unique DocRefId and refer to the report that is being corrected by inserting the original (FATCA1) report’s DocRefId in the CorrDocRefId element.
To assist the ATO with compliance monitoring and reduce the need for us to contact reporters, the ABN of the ReportingFI and Sponsor (if a Sponsor is reporting) can be included in the report. The IRS issued ReportingFI TIN element is mandatory and should always be included in your report (Trustee Documented Trusts are excluded, see below). If there is a Sponsor, the Sponsor TIN is also a mandatory field and should be reported.
<TIN issuedBy="AU">(Insert ABN here)</TIN>
<TIN issuedBy="AU">(Insert ABN here)</TIN>
The GIIN value of a Sponsoring Entity is the GIIN issued to the entity when it is acting in its capacity as a Sponsor. Sponsors have the letters 'SP' in their GIIN in the following format: xxxxxx.xxxxx.SP.xxx
If the reporter has more than one GIIN, care must be taken to ensure they are correctly provided.
Ensure the Sponsor GIIN appears in the Sponsor element.
The sponsored ReportingFI GIIN should appear at the ReportingFI TIN element. (The sponsored ReportingFI TIN is the GIIN issued to the Sponsor when the Sponsor registers the ReportingFI.)
The GIIN value of a Sponsoring Entity is the GIIN issued to the entity when it is acting in its capacity as a Sponsor. Sponsors have 'SP' in their GIIN per the following format: xxxxxx.xxxxx.SP.xxx
If you have more than one GIIN, care must be taken to ensure they are correctly provided.
Ensure the Sponsor GIIN appears in the Sponsor element. The sponsored ReportingFI GIIN should appear at the ReportingFI TIN element. (The sponsored ReportingFI TIN is the GIIN issued to the Sponsor when the Sponsor registers the ReportingFI.)
When reporting for Trustee Documented Trusts (TDTs), the Trustee reports on behalf of the Trust. The Trust itself is not required to register for a GIIN.
The Trustee is required to register and obtain a GIIN, which is reported in the Sponsor data element. The Trustee of a TDT’s GIIN should not be reported in the ReportingFI element.
The details of the Trust are reported in the ReportingFI data element.
For TDTs, the IRS FATCA XML User Guide (PDF, 1.15MB) advises to leave the ReportingFI TIN field blank. This means the TIN field in the ReportingFI element should be removed completely.
- Sponsor element must be present and completed
- DocRefId’s should begin with the Sponsor GIIN
Sponsor FilerCategory code must be ‘FATCA609’
The FilerCategory element is mandatory and should be included in all FATCA reports for the 2016 and later reporting years.
If the report is being lodged by a Sponsor, report the FilerCategory code in the Sponsor element.
If the report is not being lodged by a Sponsor, report the FilerCategory code in the ReportingFI element.
Refer to the IRS schema guidance webpage.
FATCA reports received from Australian reporters are passed on to the US IRS immediately after lodgment. If the IRS advises of any errors requiring correction, we contact reporters to fix the errors.
Consider the timing for archiving of FATCA reports to enable any necessary corrections.
US persons must be reported in both FATCA and CRS reports. For more information see CRS and FACTA – Effect of the ‘wider approach’ on FATCA practices.
- The SendingCompanyIN and ReportingFI IN must be the same identifying number for CRS.
- MessageRefId and DocRefId are in a different format for CRS to those in the FATCA report.
- Using nine zeros in 2017 year reports and nine A’s in 2018 and 2019 year reports, where the TIN is unavailable only applies to FATCA.
If there are no reportable accounts for the year, nil reports are preferred but not mandatory. Lodging a nil report will help us monitor FATCA compliance and may reduce the need for us to contact reporters.
In January 2017, the FATCA XML Schema v2.0 replaced v1.1. All users are required to submit FATCA Reports using version 2.0, even if for prior years, because version 1.1 is no longer supported.
The ATO will be applying some additional levels of logical validation to the lodged files. To view the validations visit ATO Automatic Exchange of Information (AEOI) on SBR.gov.au and refer to ATO FATCA.0001 2017 Package zip file. These rules apply for both BDE and SBR.
From 18 July 2019, two new validation rules are being added to the FATCA service.
Summary of the new rules:
- Ensure that when Sponsor details are provided, the Reporting FI TIN is provided in a GIIN format, and the Reporting FI TIN issuedBy attribute is set to either ‘US’ or left blank.
- Ensure that when Sponsor details are not provided, the Reporting FI FilerCategory code is set to FATCA602.
Certain characters are prohibited and may not be included in a FATCA report.
Refer to the IRS’s page FATCA XML Schema Best Practices for Form 8966 for more details.
The IRS requires a U.S. Taxpayer Identification Number (TIN) to be provided for each individual reported.
The IRS will accept the reporting of accounts without a TIN through to the 2019 reporting period, but only if strict conditions are met. One of these conditions is that a date of birth must be provided in the absence of a U.S. TIN. See due diligence actions (below).
If the US TIN is not held for a pre-existing account holder that is an individual, reporting Australian financial institutions must comply with the required due diligence actions outlined in Notice 2017-46 (PDF, 57.30KB) (summarised below).
Reporting Australian financial institutions must:
- obtain and report the date of birth for each account holder and controlling person whose US TIN is not reported
- annually request missing US TINs from each account holder
- search electronically searchable data maintained by the reporting institution for any missing US TINs, before reporting each year.
If due diligence actions are taken the Internal Revenue Service (IRS) will not determine that there is significant non-compliance for the calendar years 2017, 2018 and 2019.
When lodging with the ATO, the requirements for missing US TINs differ for 2017 and 2018 reporting. If, after due diligence actions have been undertaken US TINs are not found, then:
- For the 2017 year reports, you must use nine zeros (000000000) to populate the US TIN data element.
- For the 2018 year and subsequent year reports, you must use nine capital As (AAAAAAAAA) to populate the US TIN data element.
Consider if your system requires changes to accommodate entering alpha type characters in the account holder TIN data element.
Some other countries may be using nine As. This may affect reporting from/for branches in other countries.
- From 1 January 2019 all FATCA reports must be lodged with wrapper header information.
- To view the BDE wrapper header guidance, see Bulk Data Exchange common information artefacts.
- To view the SBR wrapper header guidance, see SBR ebMS3 web services artefacts.
If your users have applied thresholds, they must keep a written record of the procedures by which they determine the information that is required to be contained in the statement, according to section 396-25 of the Taxation Administration Act 1953.
Do not encrypt files prior to lodging as we will encrypt them as part of our dispatching process.
Under the solution implemented on 1 January 2018, lodgment of FATCA files will be limited to a single report per file. The report should contain all of an entity's reportable accounts.
The mandatory data format for the DocRefId data elements took effect from 1 January 2016. This data element applies to all reports lodged after 1 January 2016, including re-lodgments for prior reporting years.
The data format is <reporting FI GIIN><period character (.)><unique value across all time for the reporting FI>
- The first part – <reporting FI GIIN> is the GIIN for the reporting FI associated with the reporting group.
- The second part is a period character (.)
- The third part – <unique value across all time for the reporting FI> is an identifying value for the referenced record that is unique within the reporting FI for all time.
This element should contain at least 21 characters, which includes the first part – reporting FI GIIN, the second part – period character (.), and at least one alphanumeric character to represent the third part. The maximum length of DocRefId is 200 characters.
Each DocRefId within the report needs to be unique.
For void or corrected reports, the new format does not apply to the CorrDocRefIds as they must be the DocRefId from the original report that generated the error.
The DocRefId identifies specific records within the report and appears in:
- Sponsor (if applicable)
- All Account Holders
- Nil Report (if applicable)
From 23 March 2018, the DocRefId must not include any non-alphanumeric characters.
However, there are two exceptions to the rule: periods (.) and dashes (-) can be used.
All other non-alphanumeric characters cannot be used. Some examples of non-alphanumeric characters that must not be included in the DocRefId are underscore (_), at symbol (@), plus (+), ampersand (&), exclamation mark (!) and asterisk (*).
Refer to the IRS’s FATCA XML Schema Best Practices for Form 8966 DocRefId page for more details.
The AcctHolderType is mandatory. Refer to the IRS schema guidance webpage.
Each MessageRefId in the FATCA report can only ever be used once by the ReportingFI. If a MessageRefId is used more than once an error notification will issue and the file will not be processed by the Internal Revenue Service (IRS). It is recommended that financial institutions use MessageRefID values that would distinguish messages from other messages previously sent (and accepted by the IRS) and from any other financial institution message.