FATCA reporting

This page provides information about FATCA reporting, systems and data.

Lodgment

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 via ATO online services using the File Transfer facility:

  • Business Portal
  • Online services for agents

Correcting, voiding and amending reports

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 the United 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.

FATCA report types

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.

Providing your Australian Business Number (ABN)

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.

For example:

<ns2:ReportingFI>

      <ResCountryCode>AU</ResCountryCode>

      <TIN issuedBy="US">xxxxxx.xxxxx.xx.xxx</TIN>

     <TIN issuedBy="AU">(Insert ABN here)</TIN>

      <Name>XXXXXX</</Name>

      <Address>

<ns2:Sponsor>

      <ResCountryCode>AU</ResCountryCode>

      <TIN issuedBy="US">xxxxxx.xxxxx.SP.xxx</TIN>

      <TIN issuedBy="AU">(Insert ABN here)</TIN>

      <Name>XXXXXX</</Name>

      <Address>

Reporting the Sponsor Global Intermediary Identification Number (GIIN) correctly

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.)

Sponsored Entities requirements

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.)

Trustee Documented Trust (TDT) reporting

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.

Note:

  • Sponsor element must be present and completed
  • DocRefId’s should begin with the Sponsor GIIN

Sponsor FilerCategory code must be ‘FATCA609’

FilerCategory requirements

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.

Consider when to archive

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.

Effect of the CRS wider approach on FATCA

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.

Reporting differences between FATCA and CRS

Reporting differences between FATCA and CRS include:

  • 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.

Testing

Testing for BDE is available via the External Vendor Testing Environment (EVTE).

Nil reports

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.

Users can create and lodge a nil report using the FATCA XML schema or the FATCA - Small Reporters Tool via the user guide.

Schema

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.

Validation

The ATO will be applying some additional levels of logical validation to the lodged files. To view the validations visit FATCA specification and refer to ATO FATCA.0001 2017 Package zip file. These rules apply for BDE.

New lodgment validation rule

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 issued by 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.

Restricted characters

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.

2020 year reports without account holder US TINs

From the 2020 reporting year onwards, a US Taxpayer Identification Number (TIN) must be provided for each account holder reported: individuals, entities and substantial owners.

The IRS has developed a series of codes that may be used to populate the TIN field in circumstances where the TIN is not available, as an alternative to using nine As (AAAAAAAAA). 

The use of these codes is optional and does not mean that a foreign financial institution (FFI) will not be at risk of being found significantly non-compliant due to a failure to report each required US TIN. The IRS will take into account the facts and circumstances leading to the absence of the US TIN, such as:

  • the reasons why the TIN could not be obtained
  • whether the FFI has adequate procedures in place to obtain TINs
  • the efforts made by the FFI to obtain TINs. 

Table: Codes for missing TIN

Code

Reason

222222222

Pre-existing individual account with only US indicia being a US place of birth.

333333333

New individual account that has indicia of a US place of birth and either:

  1. has a change in circumstances causing the self-certification originally obtained at account opening to be incorrect or unreliable, and a new self-certification has not been obtained, or

     
  2. was below the threshold for documenting and reporting the account at the time of account opening and subsequently exceeded the threshold, and a self-certification has not been obtained.

444444444

Pre-existing individual and entity account that has US indicia other than a US place of birth, and either:

  1. has a change in circumstances, causing the self-certification or other documentation originally obtained to be incorrect or unreliable, and a new self-certification or other documentation has not been obtained, or

     
  2. was below the threshold for documenting and reporting at the time of account opening and subsequently exceeded the threshold, and a self-certification or other documentation has not been obtained.

555555555

New individual and entity account that has US indicia other than a US place of birth, and either:

  1. has a change in circumstances causing the self-certification or other documentation originally obtained to be incorrect or unreliable, and a new self-certification or other documentation has not been obtained, or

     
  2. was below the threshold for documenting and reporting the account at the time of account opening and subsequently exceeded the threshold, and a self-certification or other documentation has not been obtained.

666666666

Pre-existing entity account with account balance exceeding $1,000,000 held by a passive NFFE with respect to which no self-certifications have been obtained, and no US indicia have been identified in relation to its controlling persons.

777777777

For pre-existing accounts where there is no TIN available and the account has been dormant or inactive, but remains above the reporting threshold, also known as a 'dormant account'.  For reference, the U.S. defines 'dormant account' in US Treasury Regulations §1.1471-4(d)(6)(ii).

Learn about the extension to the deadline for 2020 year reports

Reporting account holder United States taxpayer identification numbers (TINs) for 2020

From the 2020 reporting year onwards, a US Taxpayer Identification Number (TIN) must be provided for each account holder reported: individuals, entities and substantial owners. Initially, if the account holder’s US TIN was not known, 9A’s were to be supplied in the account holder TIN element. From January 2021, the codes for missing TIN are to be used.

Reporting account holder United States taxpayer identification numbers (TINs) for 2017 to 2019

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 US TIN. See due diligence actions (below).

Reporting of TINs for non-US entities

Non-US entity account holders with US substantial owners may include the relevant country code in the “TIN Issued by” element and the characters “NA” in the TIN (taxpayer identification number) when reporting for the non-US entity. Reporters are still required to provide TINs for any US substantial owners.

Due diligence actions where account holder US taxpayer identification number (TIN) is missing

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.

The transitional TIN reporting arrangements provided by Notice 2017-46 conclude with 2019 year reporting.

How to report missing US TINs

When lodging with the ATO, the requirements for reporting missing US TINs differ for the 2017 reporting year and prior years. If you have not been able to obtain the US TIN of an account holder after due diligence:

  • For the 2017 and prior year reports, you must use nine zeros (000000000) to populate the US TIN data element.
  • For the 2018 reporting year and subsequent years, 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.

Wrapper header

Thresholds – Record keeping requirements

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.

Encryption

Do not encrypt files prior to lodging as we will encrypt them as part of our dispatching process.

Single file limitation and extension of BDE functionality

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.

DocRefId format requirements

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.

DocRefId Examples:

S519K4.99999.SL.392.12291cc2-37cb-42a9-ad74-06bb5746b60b

127BM7.00001.ME.124.406abc8a1830490e847890ba3b13a646

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.

Update to the format requirements for the DocRefld

The DocRefId identifies specific records within the report and appears in:  

  • ReportingFI
  • 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 (*).

DocRefId pattern:

<ReportingGIIN>.<UniqueValue>

DocRefId examples:

  • S519K4.99999.SL.392.12291cc2-37cb-42a9-ad74-06bb5746b60b
  • 127BM7.00001.ME.124.406abc8a1830490e847890ba3b13a646

Refer to the IRS’s FATCA XML Schema Best Practices for Form 8966 DocRefId page for more details.

Account Holder Type (AcctHolderType) requirements

The AcctHolderType is mandatory.  Refer to the IRS schema guidance webpage

MessageRefId requirements

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.

 

Last modified date