0417 Publ 5124 (PDF)

Official source: IRS Forms, Instructions & Publications (https://www.irs.gov/pub/irs-pdf/p5124.pdf), retrieved 2026-10-03. U.S. Government work (17 U.S.C. § 105).

---

Publication 5124 (4-2017) Catalog Number 65544H Department of the Treasury Internal Revenue Service www.irs.gov

What’s New .................................................................................................................. 6

1 Introduction ............................................................................................................ 7

1.1 About FATCA ................................................................................................................................ 7

1.2 Special Rules for Non-GIIN Filers ................................................................................................. 8

1.3 HCTA Filers ................................................................................................................................... 8

1.4 Purpose ......................................................................................................................................... 9

2 FATCA XML Schema Overview .......................................................................... 10

2.1 Schema Versions ........................................................................................................................ 12

2.2 Schema Validation ...................................................................................................................... 13

2.2.1 Creating New Reports using Schema v2.0 ......................................................................... 13

2.2.2 Corrected, Void and Amended Reports using Schema v2.0 .............................................. 13

2.3 Prohibited and Restricted Characters ......................................................................................... 14

2.4 Namespace ................................................................................................................................. 15

2.5 Reciprocal Exchange .................................................................................................................. 15

2.5.1 Competent Authority Requests (CAR) ................................................................................ 16

2.6 Data Preparation and Naming Conventions ............................................................................... 16

2.7 System Testing ............................................................................................................................ 16

2.8 Other Resources ......................................................................................................................... 17

3 MessageSpec ...................................................................................................... 18

3.1 SendingCompanyIN .................................................................................................................... 19

3.1 TransmittingCountry .................................................................................................................... 19

3.2 ReceivingCountry ........................................................................................................................ 20

3.3 MessageType .............................................................................................................................. 20

3.4 Warning ....................................................................................................................................... 20

3.5 Contact ........................................................................................................................................ 20

3.6 MessageRefId ............................................................................................................................. 20

3.7 CorrMessageRefId ...................................................................................................................... 21

3.8 ReportingPeriod .......................................................................................................................... 21

3.9 Timestamp ................................................................................................................................... 21

4 FATCA Report Complex Types ........................................................................... 22

4.1 MonAmnt_Type ........................................................................................................................... 22

4.2 DocSpec_Type ............................................................................................................................ 23

4.2.1 DocTypeIndic ...................................................................................................................... 23

FATCA XML Schema v2.0 User Guide

2

4.2.2 DocRefId ............................................................................................................................. 25

4.2.3 CorrMessageRefId .............................................................................................................. 25

4.2.4 CorrDocRefId ...................................................................................................................... 26

4.3 Address_Type ............................................................................................................................. 26

4.3.1 CountryCode ....................................................................................................................... 27

4.3.2 Address Free ....................................................................................................................... 27

4.3.3 AddressFix .......................................................................................................................... 28

4.4 PersonParty_Type ....................................................................................................................... 29

4.4.1 ResCountryCode ................................................................................................................. 29

4.4.2 TIN ....................................................................................................................................... 30

4.4.3 Name ................................................................................................................................... 31

4.4.3.1 Titles ................................................................................................................................ 32

4.4.3.2 First Name ....................................................................................................................... 32

4.4.3.3 Middle Name ................................................................................................................... 32

4.4.3.4 Last Name ....................................................................................................................... 33

4.4.4 Nationality ............................................................................................................................ 33

4.4.5 BirthInfo ............................................................................................................................... 33

4.4.5.1 BirthDate ......................................................................................................................... 34

4.5 OrganisationParty_Type .............................................................................................................. 35

4.5.1 ResCountryCode ................................................................................................................. 35

4.5.2 TIN ....................................................................................................................................... 36

4.5.3 Name ................................................................................................................................... 37

4.5.4 Address ............................................................................................................................... 37

4.6 CorrectableReportOrganisation_Type ........................................................................................ 37

4.6.1 FilerCategory - New ............................................................................................................ 38

4.6.2 DocSpec .............................................................................................................................. 39

5 ReportingFI .......................................................................................................... 40

6 ReportingGroup ................................................................................................... 43

6.1 Sponsor ....................................................................................................................................... 43

6.2 Intermediary ................................................................................................................................ 44

6.3 NilReport - New ........................................................................................................................... 45

6.3.1 DocSpec .............................................................................................................................. 46

6.3.2 NoAccountToReport ............................................................................................................ 46

6.4 Account Report ............................................................................................................................ 47

6.4.1 DocSpec .............................................................................................................................. 48

FATCA XML Schema v2.0 User Guide

3

6.4.2 AccountNumber ................................................................................................................... 48

6.4.3 AccountClosed - New .......................................................................................................... 49

6.4.4 AccountHolder ..................................................................................................................... 50

6.4.4.1 Individual ......................................................................................................................... 50

6.4.4.2 Organisation .................................................................................................................... 50

6.4.4.3 AcctHolderType - Updated .............................................................................................. 51

6.4.5 Substantial Owner - Updated .............................................................................................. 52

6.4.5.1 Individual and Organization ............................................................................................. 52

6.4.6 AccountBalance .................................................................................................................. 53

6.4.7 Payment .............................................................................................................................. 54

6.4.7.1 Type ................................................................................................................................ 55

6.4.7.2 PaymentTypeDesc - New ............................................................................................... 55

6.4.7.3 PaymentAmt .................................................................................................................... 56

6.4.8 CARRef - New (Model 2 IGA Reporting Only) .................................................................... 56

6.4.8.1 PoolReportReportingFIGIIN ............................................................................................ 57

6.4.8.2 PoolReportMessageRefId ............................................................................................... 57

6.4.8.3 PoolReportDocRefId ....................................................................................................... 57

6.4.9 AdditionalData - New .......................................................................................................... 58

6.4.9.1 AdditionalItem .................................................................................................................. 58

6.5 Pool Report ................................................................................................................................. 59

6.5.1 DocSpec .............................................................................................................................. 59

6.5.2 AccountCount - Update ....................................................................................................... 59

6.5.3 AccountPoolReportType - Updated .................................................................................... 60

6.5.4 PoolBalance ........................................................................................................................ 60

7 Correcting, Amending and Voiding Records - New ............................................. 61

7.1 Unique MessageRefId and DocRefId ......................................................................................... 61

7.2 How to Correct, Amend or Void Records .................................................................................... 62

7.2.1 Amend ................................................................................................................................. 63

7.2.2 Void ..................................................................................................................................... 63

7.2.3 Correct ................................................................................................................................. 63

7.2.4 Special Cases to Amend and Correct Records .................................................................. 63

7.3 MessageSpec and DocSpec ....................................................................................................... 64

Appendix A: Glossary of Terms ............................................................................... 66

Appendix B: FATCA XML Schema Overview ........................................................... 71

Appendix C: MessageSpec ..................................................................................... 72

FATCA XML Schema v2.0 User Guide

4

Appendix D: Reporting FI ........................................................................................ 73

Appendix E: Reporting Group ................................................................................. 74

Appendix F: Account Report ................................................................................... 75

Appendix G: Pool Report ......................................................................................... 76

Appendix H: Account Holder ................................................................................... 77

Appendix I: Substantial Owner ............................................................................... 78

Appendix J: Sponsor & Intermediary ...................................................................... 79

Appendix K: Individual or Organization Account Holders ........................................ 80

Appendix L: Person Party Type .............................................................................. 81

Appendix M: Address Type ...................................................................................... 82

Appendix N: OrganisationParty_Type ..................................................................... 83

Appendix O: CorrectableReportOrganisationParty_Type ........................................ 84

Appendix P: DocSpec_Type ................................................................................... 85

FATCA XML Schema v2.0 User Guide

5

This section highlights important changes to the Foreign Account Tax Compliance Act (FATCA) XML Schema v2.0 User Guide. The schema and business rules are explained in detail throughout this publication. All changes are effective January 17, 2017 and the IRS will communicate the specific transition date as soon as possible.

Future Updates

The IRS will continue to consult with partners and receive feedback to improve the guide.

Data Elements Description

AccountClosed Allows a financial institution to declare the account status as closed.

Account Holder Type Update to the FATCA account holder type enumeration codes. Account Number Type Allows a financial institution to declare account number formats, such as IBAN and OSIN.

AdditionalData Provides additional text information for an account report.

CARRef Links account reports submitted in response to a Competent Authority Request (CAR) to the original pooled report from a financial institution from a Model 2 IGA jurisdiction. (For Model 2 reporting only)

FilerCategory Identifies the filer category code for a reporting financial institution and/or sponsor.

NilReport Indicates a reporting financial institution has no accounts to report.

Payment Type Description Provides text description for payment types.

Substantial Owner Allows a filer to name a substantial owner as an entity or organization.

FATCA XML Schema v2.0 User Guide

6

The Foreign Account Tax Compliance Act (FATCA) was enacted as part of the Hire Incentives to Restore Employment (HIRE) Act in 2010. FATCA was created to address non-reporting of income related to foreign financial accounts held by US taxpayers. FATCA requires certain foreign financial institutions (FFIs) to report certain information about its U.S. accounts, accounts held by owner-documented FFIs (ODFFI), and certain aggregate information concerning accounts held by recalcitrant account holders and, for 2015 and 2016, accounts held by nonparticipating FFIs. Generally, FFIs will commit to this reporting requirement by registering with the IRS and signing an agreement with the IRS.

The FATCA regulations also require a withholding agent to deduct and withhold tax equal to 30 percent of a withholdable payment made to a passive non-financial foreign entity (NFFE) unless the passive NFFE certifies to the withholding agent that it does not have any substantial U.S. owners or provides certain identifying information with respect to its substantial U.S. owners. A withholding agent is also required to report information about substantial U.S. owners of a passive NFFE and specified U.S. persons holding certain equity or debt interests in a payee that the withholding agent has agreed to treat as an ODFFI. Payments to NFFEs that report their substantial U.S. owners (or report that they have no substantial U.S. owners) directly to the IRS (direct reporting NFFEs) are excepted from withholding and reporting by a withholding agent or an FFI.

To facilitate FATCA implementation for FIs operating in jurisdictions with laws that prevent the FIs from complying with the terms of the FFI agreement, the Treasury Department developed two alternative model intergovernmental agreements (IGAs) (Model 1 IGA and Model 2 IGA) that allow FIs operating in such jurisdictions to perform due diligence and reporting on their account holders to achieve the objectives of FATCA. FFIs reporting under a Model 1 IGA (reporting Model 1 FFIs) report certain information about their U.S. reportable accounts and certain payees as required under the applicable IGA to their respective tax authorities. Reporting Model 1 FFIs do not report directly to the IRS. However, certain reporting Model 1 FFIs in a “Model 1 Option 2” jurisdiction may use the schema to report to their tax authorities. FFIs reporting under a Model 2 IGA (Reporting Model 2 FFIs) report directly to the IRS certain information about their U.S. accounts, and certain aggregate information concerning account holders who do not waive legal restrictions for the FFI to report this information (non-consenting U.S. accounts), and, for 2015 and 2016, certain payments made to accounts held by nonparticipating FFIs as required under the applicable IGA and the regulations.

Trustee-Documented Trusts subject to a Model 2 IGA are reported by the trustee of the TrusteeDocumented Trust. A Sponsoring Entity reports on behalf of Sponsored FFIs and Sponsored Direct Reporting NFFEs.

For the latest information about legislative and tax law topics covered in this publication, go to www.irs.gov/FATCA.

FATCA XML Schema v2.0 User Guide

7

An approved financial institution (FI) (other than a limited FFI or a limited branch), direct reporting NFFE, or sponsoring entity that registers with the IRS under FATCA will receive a global intermediary identification number (GIIN). There are certain entities that are permitted to use IDES to file on behalf of others that may not register to obtain a GIIN (non-GIIN filers) such as:

• U.S. withholding agents (USWA)

• Territory financial institutions (TFI) treated as U.S. persons

• Third party preparers

• Commercial software vendors

A non-GIIN filer must obtain a FATCA Identification Number (FIN) in order to enroll in the International Data Exchange Service (IDES) for FATCA reporting.

The GIIN and FIN appear on the FFI list published by the IRS on the first day of each month. As a best practice, always review the published FFI list before submitting a file. The publication of a FIN on the FFI list does not change the filer’s status for FATCA purposes, as it does not make the filer an FFI and does not serve any function related to withholding tax on payments under FATCA. A FIN will be accompanied by a generic name (e.g., “U.S. Withholding Agents 1”) on the FFI list.. For more information on FINs, go to the FATCA Identification Number (FIN) enrollment page at https://www.irs.gov/businesses/corporations/finenrollment-process.

The HCTA of a Model 1 IGA jurisdiction uses the schema to report to the IRS certain information on U.S. Reportable Accounts (as defined in the applicable IGA) of reporting Model 1 FFIs covered by the IGA and, for 2015 and 2016, information with respect to nonparticipating FFIs that receive payments from reporting Model 1 FFIs.

If a Model 1 IGA jurisdiction has elected to allow reporting Model 1 FFIs in its jurisdiction to use IDES to report to the IRS (“Model 1 Option 2”), the reporting Model 1 FFI transmits data directly to its HCTA using the schema. The HCTA approves or rejects the reports; if approved, the HCTA releases the data to the IRS.

FATCA XML Schema v2.0 User Guide

8

The FATCA XML Schema v2.0 User Guide (Publication 5124) outlines the business and validation rules to support a Form 8966, FATCA Report filed electronically through the International Data Exchange Service (IDES). There are reporting differences between filing electronically and filing in paper format with the IRS. To file a paper Form 8966 please see the filing instructions at www.irs.gov/pub/irs-pdf/f8966.pdf. All IDES users should be familiar with FATCA regulations, Extensible Markup Language (XML) and the FATCA XML schemas. These guidelines should be used in conjunction with the most current version of other FATCA resources and are available on www.irs.gov:

FATCA Online Registration:

FATCA Reporting (IDES, data preparation, transmission and messages):

Data Security:

Table 1 – FATCA related resources

FATCA XML Schema v2.0 User Guide

9

The FATCA XML schema governs the structure and content of files that define the electronic format for Form 8966, FATCA Report. It is used to create reports that conform to recommended standards and provide first level schema validation. The FATCA XML schema is based on an existing reporting schema and business requirements used by the Organisation for Economic Co-operation and Development (OECD) and the European Union (EU).

Table 2 – FATCA XML schema overview

The FATCA XML schema v2.0 takes precedence over any information presented in the guide. All schema and sample files can be viewed with an XML tool, such as XML Notepad. For more information on the schema library structure, samples and other resources, go to https://www.irs.gov/Businesses/Corporations/FATCA-XML-Schemas-and-Business-Rules-for-Form-8966.

FATCA XML Schema v2.0 User Guide

10

General terms in the schema are described by the definition, attribute, and constraints as listed below:

FATCA XML Schema v2.0 User Guide

11

Terms used throughout this guide:

Table 3 – FATCA schema terms and descriptions

The version of the schema and the corresponding business rules have a unique version number assigned that consists of two numbers separated by a period sign: major and minor version. The version is identified by the version attribute on the schema element. The target namespace of the FATCA schema contains only the major version.

FATCA XML Schema v2.0 User Guide

12

Figure 1 – Schema namespaces

The root element FATCA_OECD version attribute in the XML report file must be set to the value of the schema version. This will identify the schema version that was used to create the report.

All FATCA XML files should be validated by the sender using FATCA XML Schema v2.0 to identify potential error conditions before the file is transmitted through IDES. After the file is transmitted and passes security checks, the FATCA XML file goes through two levels of validation. The first level is for schema validation and if the file does not pass, it will be rejected. The second level is for application and business rule validation for data elements; if the file does not pass, you will receive an error notification.

The XML schema version 2.0 will support FATCA reporting for the current and all previous tax years. The schema version 2.0 is generally not backward compatible with schema version 1.1. The IRS requires filers use schema v2.0 for FATCA reporting. A data file formatted using schema v1.1 will not validate against schema v2.0 and will not pass application validation.

Data files created with schema v1.1 can be corrected, voided or amended using schema v2.0. Pool Reports should not be included in FATCA Report if the pool contains zero accounts. Any file will an empty pool report will not be validated against schema v2.0. If a Pool report with zero accounts was previously included in error, the IRS will not require you to void the report. In case additional accounts for the pool report are discovered later, a new Pool report can be submitted.

Example: In November 2016, a user submits Report2015 and receives a notification to correct record level errors within 120 days. In February 2017, the user should make all corrections using XML schema version 2.0.

FATCA XML Schema v2.0 User Guide

13

All XML data files should conform to recommended XML schema best practices. Certain special characters and patterns are prohibited and if included will cause the file to reject the transmission and generate an error notification.

Non-Optional Entity Reference

If an XML document contains one of these characters in the XML text content, the data packet will be rejected and generate an error notification (XML not well-formed). The characters are not allowed by XML syntax rules and must be replaced with the following predefined entity references. To prevent error notifications, do not include any of these characters in the XML documents.

Table 4 - Non-Optional entity references

Optional Entity Reference

If an XML document contains one of these characters in the XML text content, the use is not restricted by XML syntax rules. The characters can be replaced by the following predefined entity references to conform to XML schema best practices.

Table 5 - Optional entity reference

Note : In all cases, additional pattern matching may be performed on special characters that are directly followed by a known SQL command and the combination will trigger threat detection and a file level error notification.

SQL Injection Validation

If an XML document contains one of the following combinations of characters in the XML text content, the data packet will be rejected and generate a failed threat detection error notification. To prevent error notifications, do not include any of the combinations of characters.

FATCA XML Schema v2.0 User Guide

14

Table 6 - SQL injection validation

DocRefId and MessageRefId Character Sets

The StringMax200_Type data type is used to define several data elements, such as MessageRefId, CorrMessageRefId, DocRefId, and CorrDocRefId. A value with a character string not exceeding 200 characters will validate against the schema v2.0. However, the IRS strongly recommends that all characters in these elements conform to the following:

• Upper or lower case letters (“a-z”, “A-Z”)

• Numerals (“0-9”)

• Special characters including plus (“+”), underscore (“_”), hyphen/dash (“-“), and period (“.”).

The FATCA XML schema v2.0 uses namespaces based on OECD common reporting standards. The following namespaces are defined:

Table 7 - Namespace and prefix list

The IRS will participate in exchange of information with certain foreign tax administrations under a bilateral Model 1 IGA. The reciprocal report schema format, encryption method and data preparation are the same procedures used for FATCA reporting transmission during the applicable tax year. For additional information, refer to your U.S. Competent Authority Agreement.

FATCA XML Schema v2.0 User Guide

15

The IRS may send U.S. Competent Authority requests to Model 2 HCTAs in response to pooled reports from reporting Model 2 FFIs on non-consenting U.S. accounts and nonparticipating FFIs. An HCTA that receives a U.S. Competent Authority request through IDES should use the schema to send the requested information to the IRS.

There are specific data preparation guidelines on how to structure and package data files. Filers are responsible for completing the FATCA XML file as specified by FATCA regulations, IRS forms and applicable IGAs. During the data preparation process, you should provide information that conforms to the current schema while also complying by applicable business rules. All recommended file names are case sensitive and any variation in encryption method, name, extension or format may cause a transmission failure. For more information on IDES, go to Publication 5190. The IDES User Guide. There are several online resources to help you prepare and submit a valid FATCA XML document:

Table 8 - IDES data preparation resources

Each year the IRS reviews any new FATCA legal requirements and improvements to assess the impact on IRS forms and processing procedures. These changes determine updates to the XML schemas and business rules. IRS notifies all users of schema changes in the testing and production environments.

All enrolled users are eligible to participate during testing. All filers must enroll in IDES with a valid IRSissued GIIN, FIN or HCTA Entity ID/username, and a valid certificate. Filers are strongly encouraged to update their software and to test any schema changes. The test environment configurations may not be identical to the production system. For more information, go to https://www.irs.gov/Businesses/Corporations/IDES-Testing-Schedule.

FATCA XML Schema v2.0 User Guide

16

The FATCA Global IT Forum provides monthly updates on major developments. Technical experts are available to your answer questions and discuss various topics. The IRS distributes information to FATCA partners through the FATCA Newsletter . Subscribers receive communications regarding known issues, processing delays and early notification of upcoming testing sessions. Sign up on the subscription page at https://www.irs.gov/individuals/international-taxpayers/subscribe-to-the-fatca-news-and-information-list.

For assistance with transmission error notifications, go to the instructions contained in the notification or visit https://www.irs.gov/businesses/corporations/irs-fatca-report-notifications. You may also provide feedback on the quality of this publication and submit comments through the IDES FAQ webpage.

FATCA XML Schema v2.0 User Guide

17

The MessageSpec identifies the financial institution (FI), host country tax authority (TA or HCTA) and non-GIIN filers sending a message. It contains unique message identifiers, references corrected messages and specifies the date created, calendar year and reporting period.

Table 9 – MessageSpec

FATCA XML Schema v2.0 User Guide

18

This data element identifies the sender’s 19-character identifying number.

• If the sender is an FI, Sponsoring Entity or direct reporting NFFE, enter the assigned GIIN with appropriate punctuation (period or decimal). The field is mandatory and the report will not be accepted without a valid IRS-approved GIIN. Example: 98Q96B.00000.LE.250

• If the sender is an HCTA, enter the HCTA FATCA Entity ID in GIIN format. Example: 000000.00000.TA.250.

• If the sender is a non-GIIN filer, enter the FATCA Identification Number (FIN). The FIN is entered in the message header for filing purposes only. Do not use a FIN under FATCA data elements in the body of the report.

This data element identifies the tax jurisdiction as a 2-character alphabetic country code specified in the ISO 3166-1 Alpha 2 standard. Example: MX (Mexico) or Germany (DE).

• If the sender is a HCTA, enter the country code for the jurisdiction of the tax authority.

• If the sender is an FI, enter the country code for the jurisdiction where the reporting FI maintained the reportable financial accounts. Example: The sender is an FI established in Jurisdiction A and operates branches in Jurisdiction B. The reported financial accounts are maintained by the FI at its branch in Jurisdiction B. The TransmittingCountry is Jurisdiction B, the jurisdiction where the FI maintains the reported account.

• If the sender is a direct reporting NFFE, enter the country code for the jurisdiction of residence of the NFFE.

• If the sender is a Sponsoring Entity, enter the country code for the jurisdiction where the Sponsored FFI maintains the account or the jurisdiction where the Sponsored Direct Reporting NFFE is resident.

• If the sender is a withholding agent, enter the country code for the jurisdiction of residence of the payer.

FATCA XML Schema v2.0 User Guide

19

This data element identifies the jurisdiction of the receiving entities’ tax administration (TA) and uses the 2-character alphabetic country code specified in the ISO 3166-1 Alpha 2 standard. Example: When you send a FATCA Report to the IRS, the receiving country will always be “US” (United States).

This data element specifies contents of the message type. The element is an enumeration and the only value is “FATCA”.

This data element is a free text field for input of specific cautionary instructions about use of the message content. The field is not required for FATCA reporting and may be omitted.

This data element is a free text field for input of specific contact information for the sender. The field is not used for FATCA reporting and may be omitted.

This data element is a free text field to capture the unique identifier number for the sender’s message. It allows both the sender and receiver to identify and correlate a specific message. The MessageRefId is created by the sender and must be unique across all FATCA XML files received from the entity identified

FATCA XML Schema v2.0 User Guide

20

in the SendingCompanyIN element. The IRS strongly recommends using a Globally Unique Identifier (GUID) to help ensure uniqueness of assigned MessageRefId values.

This data element is a free text field to capture the unique identifier of a previously filed report. It is used to reference the original message when sending a corrected, amended or voided report. It allows the sender and the receiver to identify and correlate a specific message.

When revising a file, it must reference the previous MessageRefId created for the previous message. MessageSpec can contain multiple CorrMessageRefId elements. If the file contains corrections for records from multiple previous files, include the CorMessageRefId element for each original file. Files with new data (FATCA1) should not contain CorrMessageRefId element. For more information, go to Section 7. Correcting, Amending or Voiding Records.

This data element identifies the reporting year for the current message in YYYY-MM-DD format. Do not enter future years. Example: If reporting information for accounts or payments made in 2017, enter value as “2017-12-31”.

This data element identifies the date and time the message was created and may be automatically populated by the host system. The format is YYYY- MM-DD’T’hh:mm:ss and fractions of seconds are not used. Example: 2017-03-15T09:45:30.

FATCA XML Schema v2.0 User Guide

21

FATCA complex types are used to define the content of different elements and attributes in several structures. The structure of the components and schema validation are the same; however, different business rules or application requirements may apply based on the filing scenario. These complex types are used in different parts of the schema.

Figure 2 - MonAmnt_Type element

This data type is used to report payments and balances. It allows 2-digit fractional amount in the reported currency. All amounts must use the currCode attribute, valid three-character ISO 4217 currency code. If the amounts are not reported in U.S. dollars, enter the code for the reported currency. For amounts in dollars use the “USD” currency code. For example, fifty-thousand US dollars should be entered as “50000.00” or “50000 with “USD” currency code attribute.

FATCA XML Schema v2.0 User Guide

22

Figure 3 - DocSpec_Type

DocSpec_Type is the complex datatype for the DocSpec element. It uniquely identifies the data element, the type of data, references the record being corrected, amended or voided and associates each record to a report. The element allows you to manage record level error handling on previously filed reports and update a specific part of a record without resending an entire report.

The DocSpec element is included in all correctable elements, such as CorrectableAccountReport and CorrectableNilReport. For more information on how to correct, amend or void a record, go to Section 7.2. How to Amend, Correct and Void a Record.

Note : A record consists of data on the ReportingFI, Sponsor or Intermediary (if any), plus the account information from a NilReport or AccountReport or PoolReport.

This data element specifies the type of data being submitted, such as new data or test data. As a best practice, a message should contain only one DocTypeIndic in a single transmission. Do not combine new, corrected, void and amended records or any combination within the same message. As a best practice, send a separate XML file for each type of data.

Application Requirement: The DocTypeIndic codes FATCA11-14 must only be used during testing periods in the testing environment and must not be used for FATCA reporting to the production environment. The IRS will notify all users of open testing sessions. Failure to adhere to this restriction will result in f a file level error notification. For more information on testing, go to Section 2.7 System Testing.

FATCA XML Schema v2.0 User Guide

23

DocTypeIndic Data Type Description

Production Environment – Use FATCA 1, 2, 3 or 4

Testing Environment – Use FATCA 11,12,13 or 14

Table 10 - DocTypeIndic enumerated codes

FATCA XML Schema v2.0 User Guide

24

This data element is an identifier for a specific record and must be unique across all reporting systems and reporting periods. A unique DocRefId must be generated for each Nil Report or Account Report or Pool Report and each Reporting FI, Sponsor and Intermediary (if any). The DocRefId cannot be reused within the scope of FATCA reporting. A message with an invalid or duplicate DocRefId will cause an error notification. For more information on how to enter a TIN in GIIN format, go to Section 4.4.2 PersonParty_Type TIN or Section 4.5.2 OrganisationParty_Type TIN.

DocRefId Format

The DocRefId data element must conform to recommended best practices for file format and contain a minimum of 21 characters that include:

• Reporting FI GIIN: The GIIN for the reporting FI associated with the reporting group. Some filers may use a TIN in GIIN format and include an additional zero, such as 123456.78900.SL.840 .

• Period character: (.)

• Unique Value: The value for the referenced record that is unique within the reporting FI for all time.

• Recommended globally unique identifier (GUID).

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

format

Unique value Period (.)

This data element identifies a message that contained a record to be voided, amended or corrected. It references the MessageRefId from a previously filed report and ensures the proper records are updated. The value must match the MessageRefId from the MessageSpec element. The CorrMessageRefId element is used in combination with DocTypeIndic codes, FATCA2, FATCA3 or FATCA4 (or FATCA12, FATCA13, FATCA14, if test data). Note: Do not use CorrMessageRefId when submitting new data (FATCA1).

FATCA XML Schema v2.0 User Guide

25

This data element identifies a record to be voided, amended or corrected. It references the DocRefId from a previously filed report and ensures the proper records are updated. The value must match the DocRefId. The CorrDocRefId element is used in combination with DocTypeIndic codes, FATCA2, FATCA3 or FATCA4 (or FATCA12, FATCA13, FATCA14, if test data). Note: Do not use CorrDocRefId when submitting new data (FATCA1).

The Address_Type allows free text input of the address for any individual or organization included in the report (e.g., reporting FI, account holder, substantial owner). There are two available options, AddressFree or AddressFix with supplemental optional AddressFree.

AddressFix should be used for all FATCA reporting; however, you may select AddressFree to enter the data in a less structured format.

Table 11 - Address_Type

FATCA XML Schema v2.0 User Guide

26

The OECDLegalAddressType_EnumType datatype for an address indicates the legal character of that address as residential or business. The attribute is not used for FATCA reporting and may be omitted.

This data element provides the country code associated with the address. The country code is a 2character alphabetic country code specified in the ISO 3166-1 Alpha 2 standard.

This data element allows free text input of the address for the individual or organization. AddressFree should only be used if the data cannot be presented in the AddressFix format and the sender cannot define the various parts of the address.

• The address shall be presented as one string of bytes, blank, slash (/) or carriage return line feed used as a delimiter between parts of the address.

• AddressFree can be used as a supplemental element after the AddresFix element and when the AdressFix format is selected for address.

FATCA XML Schema v2.0 User Guide

27

Figure 4 – AddressFix element

This data element allows input in fixed format for the address for the individual or organization.

• In AddressFix element, enter the address and if additional information is needed, use the supplemental AddressFree element. In this case, the city, subentity, and postal code information should be entered in the appropriate data elements.

• All elements are optional, except the City element which is required for schema validation.

FATCA XML Schema v2.0 User Guide

Application Requirement

28

The PersonParty_Type is a correctable party type that identifies the account holder or substantial owner that is a natural person. The Name and Address data elements are mandatory. The business rules and structure of each subelement may be defined elsewhere in the schema. For more information, review Section 6.4.4.2. AccountHolder – OrganisationParty_Type.

Table 12 - PersonParty_Type

This data element describes the tax residence country code for the reported individual account holder or substantial owner. The country code is a 2-character alphabetic country code specified in the ISO 31661 Alpha 2 standard.

FATCA XML Schema v2.0 User Guide

29

Figure 5 - TIN - PersonParty

This data element identifies the U.S. Tax Identification Number (TIN) for the individual account holder or substantial owner and the attribute identifies the jurisdiction that issued the TIN. A U.S. TIN may be a U.S. social security number (SSN) or an individual taxpayer identification number (ITIN) issued by the IRS. For FATCA reporting a blank issuedBy attribute field will be assumed to indicate the issuing jurisdiction is the United States (US). For detailed information on TIN values and organisations, go to Section 4.5.2 OrganisationParty_Type TIN.

TIN Format

• A value for a TIN data element must be either in a GIIN format or in one of the following formats for a US TIN:

  • Nine consecutive digits without hyphens or other separators (e.g., 123456789)

  • Nine digits with two hyphens (e.g., 123-45-6789)

  • Nine digits with a hyphen entered after the second digit (e.g., 12-3456789)

Note: If the TIN field is omitted or the value is not in a valid format, the system will generate a record level error notification.

Direct Reporting NFFE

If the filer is a direct reporting NFFE the TIN element under the AccountHolder element should be omitted.

FATCA XML Schema v2.0 User Guide

30

Table 13 – Name

This data element contains the components to identify an individual by name. The FirstName and LastName elements are mandatory and cannot be omitted. The attribute nameType is not used for FATCA reporting and should be omitted.

FATCA XML Schema v2.0 User Guide

31

Titles 4.4.3.1

These data elements and attributes are not required for FATCA and may be omitted; however if included will not cause an error notification.

This data element allows for the individual’s first name. It is required for FATCA reporting and cannot be omitted.

If the sender does not have complete information or no first name for an individual account holder or substantial owner, you may use an initial here, such J.T. or enter “NFN” (No First Name). The attribute xnlNameType is not required for FATCA reporting and may be omitted.

This data element allows for the individual’s middle name. If the account holder or substantial owner has a middle name or initial it may be included. The data is optional and the attribute xnlNameType is not used for FATCA and may be omitted.

FATCA XML Schema v2.0 User Guide

32

This data element allows for the individual’s last name. This field may include any prefix or suffix legally used by the account holder or substantial owner. This element is required for FATCA reporting and cannot be omitted. The xnlNameType attribute is not used for FATCA reporting and may be omitted.

This data element is not required for FATCA and may be omitted.

This data element identifies the date of birth of the individual account holder or substantial owner and may be used by HCTA and tax administrations that are permitted to provide date of birth information in lieu of a TIN for the account holder or substantial owner of a preexisting account, in circumstances described in an applicable IGA.

Table 14 – BirthInfo

FATCA XML Schema v2.0 User Guide

33

Application Requirement

This data element is used only when the message sender is another tax administration that is permitted to provide a date of birth in lieu of a TIN for a preexisting account under an applicable IGA. It may be omitted if the tax administration has not received date of birth information from the financial institution or if a US TIN (if the sender is an HCTA) or a foreign TIN (for reciprocal reports) is provided for the account holder or substantial owner. The data format is YYYY-MM-DD.

The data elements above identify the account holder’s place of birth. The CountryInfo data element provides a choice between the current country (identified by 2-character country code or a former country (identified by name). The elements are not used for FATCA reporting and should be omitted; however, if included will not cause an error notification.

FATCA XML Schema v2.0 User Guide

34

The OrganisationParty_Type identifies information about any entity included in the report (e.g., an entity account holder or payee, an entity substantial owner, Reporting FI, Sponsor and Intermediary (if any)). The Name and Address data elements are required components and each can be presented more than once. One or more identifiers, such as the TIN, should be added as well as a residence country code. The element has been extended by adding two categories. The structures of the sub-elements are described Section 4.6. CorrectableReportOrganisation_Type.

Table 15 - OrganisationParty_Type

This data element describes the tax residence country code for the organization. The country code is a 2character alphabetic country code specified in the ISO 3166-1 Alpha 2 standard.

FATCA XML Schema v2.0 User Guide

35

Figure 6 - TIN - OrganisationParty

This element identifies the receiving tax administration or U.S. Tax Identification Number (TIN) for the organization. The attribute describes the jurisdiction that issued the TIN and reporting a blank issuedBy attribute field indicates the issuing jurisdiction is the United States (US). The data element can be repeated if a second TIN is present.

Based on the IGA and FI filing scenarios certain business rules may apply. See Sections 5, 6.1, 6.2, 6.4.4.2.1, and 6.4.5 for the applicable business rules for the TIN for reporting FI, sponsor, intermediary, entity account holder, and entity substantial owner.

TIN Format

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

  • Nine consecutive digits without hyphens or other separators (e.g., 123456789)

  • Nine digits with two hyphens (e.g., 123-45-6789)

  • Nine digits with a hyphen entered after the second digit (e.g., 12-3456789)

Note: The FIN should be entered in the message header for filing purposes only. Do not use a FIN for any TIN elements outside of the MessageSpec element or in the body of the FATCA XML report. If the TIN field is omitted or the value is not in a valid format, the IRS will generate a record level error notification.

FATCA XML Schema v2.0 User Guide

36

Figure 7 - NameOrganisation_Type

The organization element can have multiple names, but FATCA reporting requires only one name element. The value of the element should be the legal name of the entity or organization. The attribute nameType is not required for FATCA reporting and may be omitted. If included the value should be from the list below:

This data element is described elsewhere in the schema. For more information, go to Section 4.3. Address_Type.

This data type transmits data for Reporting FI, Sponsor, and Intermediary organizations and was extended from the OrganisationParty_Type by adding two elements: FilerCategory and DocSpec. The structures of the sub-elements are described Section 4.5. OrganisationParty_Type.

FATCA XML Schema v2.0 User Guide

37

Figure 8 - FilerCategory

This data element identifies the filer category codes and may be required based on specific filing status, such as direct reporting NFFE and Sponsoring Entities filing on behalf of direct reporting NFFEs. The element or code may not be presented more than once. Note: This element should not be included for tax years 2014 and 2015, but is required for 2016 and later years.

*** Application Requirement:**

Note: The FilerCategory element is reported under either the ReportingFI or the Sponsor element. It should never to be included in an Intermediary element. The values and rules for inclusion of FilerCategory are provided in Table 16. Filer category list.

FATCA XML Schema v2.0 User Guide

38

Filer Category Types:

Table 16 - Filer category list

FATCA610 should be used by a ReportingFI that is a withholding agent, or is filing in the same manner as a withholding agent, including:

• A U.S. branch of a PFFI that is treated as a U.S. person;

• A U.S. branch of a Reporting Model 2 FFI that is treated as a U.S. person;

• A U.S. branch of a Reporting Model 1 FFI (whether or not the U.S. branch is treated as a U.S. person);

• A U.S. branch of an RDC FFI (whether or not the U.S. branch is treated as a U.S. person); and

• A U.S. branch of a Limited FFI that is not treated as a U.S. person.

For more information and a description of this element, go to Section 4.2. DocSpec_Type.

FATCA XML Schema v2.0 User Guide

39

The ReportingFI data element uses the CorrectableReportOrganisation_Type to identify the financial institution that maintains the financial account, the financial institution that makes the payment, or the direct reporting NFFE that reports its owners. The structure and sub-elements elements are described in Section. 4.5 OrganisationParty_Type and Section 4.6 CorrectableReportOrganisation_Type.

Table 17 – ReportingFI

This data element identifies the FI that maintains a reportable account, makes a payment, or is a Direct Reporting NFFE or Sponsored Directed Reporting NFFE required to report its owners. If the reporting FI maintains branches outside of its country of tax residence then the GIIN for the reporting FI is the GIIN associated with the branch of the reporting FI that maintains the reported financial account.

ReportingFI

A ReportingFI may be one of the entities identified below. See Section 1.1 for a summary of when reporting under FATCA is required.

• If a Sponsoring Entity is filing a report for a Sponsored FFI or Sponsored Direct Reporting NFFE, information about the Sponsored FFI or Sponsored Direct Reporting NFFE should be reported in the ReportingFI element; information about the Sponsoring Entity should be reported in the Sponsor element in the ReportingGroup.

• If a Trustee is filing a report for a Trustee-Documented Trust, information about the TrusteeDocumented Trust should be reported in the ReportingFI element; information about the Trustee of the Trustee-Documented Trust should be reported in the Sponsor element in the ReportingGroup.

FATCA XML Schema v2.0 User Guide

40

TIN Value for ReportingFI

The list below summarizes the category and TIN values for a ReportingFI. This element is described in other parts of the schema. For more information, go to Section. 4.5.2 OrganisationParty_Type TIN.

TIN Values:

Table 18 - TIN values for ReportingFI

Note: The FIN should be entered in the message header for filing purposes only. Do not use a FIN for any TIN elements outside of the MessageSpec elements or in the body of the FATCA XML report.

*Note: If the TIN field is omitted or the value is not in a valid format, the IRS will generate a record level error notification.

Filer Category for ReportingFI

For more information, go to Section 4.6.1 FilerCategory. Unless otherwise noted, for all other reporting FIs, the filer category is mandatory. The list below summarizes the allowable values are for a reporting FI.

FATCA XML Schema v2.0 User Guide

41

Filer Category Values:

Table 19 - FileCategory values for ReportingFI

• If an HCTA in a Model 1 IGA jurisdiction is sending information on accounts maintained by a Reporting Model 1 FFI, use filer category FATCA602 (RDC FFI).

• If the reporting FI is a Related Entity or branch described in an applicable IGA, use filer category code FATCA603 (Limited Branch or Limited FFI).

• If reporting FI is a Sponsored FFI, Sponsored Direct Reporting NFFE, or Trustee-Documented Trust, the filer category is not allowed . For more information, go to Section 6.1 Sponsor.

Address for ReportingFI

For more information, go to Section 4.3 Address_Type. Enter the reporting FI’s mailing address. If the reporting FI is a participating FFI, provide the mailing address of the office of the branch that maintains the account.

FATCA XML Schema v2.0 User Guide

42

The ReportingGroup data element uses the CorrectableReportOrganisation_Type to identify

(1) a Sponsoring Entity or Trustee of a Trustee-Documented Trust that it is acting on behalf a Sponsored FFI, Sponsored Direct Reporting NFFE, or Trustee-Documented Trust (as applicable) that maintains the reported financial account, or (2) an Intermediary receiving a withholdable payment or holding an account with the reporting FI that provides the reporting FI with information on certain beneficial owners.

The structure and sub-elements are described in Section. 4.5 OrganisationParty_Type and Section 4.6 CorrectableReportOrganisation_Type.

Diagram

Table 20 – ReportingGroup

The data element provides specific account data and each FATCA Report must contain a Nil Report or AccountReport(s) and/or a PoolReport(s).

FATCA XML Schema v2.0 User Guide

43

This data element identifies a Sponsoring Entity or a Trustee of a Trustee-Documented Trust that has agreed to report on behalf a Sponsored FFI, Sponsored Direct Reporting NFFE, or Trustee-Documented Trust (as applicable). Information on the Sponsored FFI, Sponsored Direct Reporting NFFE, or TrusteeDocumented Trust should be entered in the Reporting FI element. The Sponsor structure and subelements are described in Section 4.5 OrganisationParty_Type and Section 4.6 CorrectableReportOrganisation_Type.

TIN Value for Sponsoring Entity

• The TIN of a Sponsoring Entity is the GIIN issued to such entity when it is acting in its capacity as a Sponsor.

• The Sponsoring Entity should use its Sponsoring Entity’s GIIN as a TIN value

• The TIN of a Trustee of a Trustee-Documented Trust is the GIIN it received when it registered to act as a trustee of a Trustee-Documented Trust.

Note: Do not use GIINs obtained by financial institutions designated as a Single, Lead or Member as a TIN value in Sponsor element.

Note: The FIN should be entered in the message header for filing purposes only. Do not use a FIN for any TIN elements outside of the MessageSpec element or in the body of the FATCA XML report. If the TIN field is omitted or the value is not in a valid format, the IRS will generate a record level error notification.

Filer Category for Sponsoring Entity

• This element is mandatory for a Sponsor. It will be validated on the application level and if not present, will generate a record level error notification. For more information, go to Section 4.6.1

FilerCategory. The list below summarizes the allowable values for a Sponsor.

This data element identifies an Intermediary that is:

• A Territory Financial Institution not treated as a U.S. person that is acting as an intermediary or is a flow-through entity and receives a withholdable payment from a withholding agent (the withholding agent is the Reporting FI); or

FATCA XML Schema v2.0 User Guide

44

• A certified deemed-compliant FFI that is acting as an intermediary for a withholdable payment and provides the withholding agent with information on a substantial U.S. owner of a passive NFFE account holder or payee (the withholding agent is the Reporting FI).

The structure and sub-elements are described in Section 4.5 OrganisationParty_Type and Section 4.6 CorrectableReportOrganisation.

TIN Value for Intermediary

• If the Intermediary is a Territory Financial Institution not treated as a U.S. person, enter the TIN issued to the Territory Financial Institution by the IRS, or if the Territory Financial Institution has not been issued a TIN by the IRS, enter the EIN assigned to the entity by the relevant U.S. territory.

• If the Intermediary is a certified deemed-compliant acting as an intermediary, the entity will not have a GIIN or U.S. TIN or EIN. Leave the TIN element blank.

Filer Category

• Element is not allowed and if included will generate an error notification.

Figure 9 - NilReport

This data element specifies that a financial institution has no accounts to report or that a Direct Reporting NFFE (or Sponsored Direct Reporting NFFE) has no substantial U.S. owners. Generally, a Nil Report is optional for filers other than Direct Reporting NFFEs and Sponsored Direct Reporting NFFEs. Nil reports that are submitted must also include ReportingFI and Sponsor or Intermediary, if applicable.

Also note that nil reporting may be required by a financial institution’s local jurisdiction. Consult your local tax administration for details. For more information on sample nil reports, go to https://www.irs.gov/Businesses/Corporations/FATCA-XML-Schemas-and-Business-Rules-for-Form-8966.

FATCA XML Schema v2.0 User Guide

45

Schema Requirement:

Nil Report is one of the options in xsd:choice. It is a required element in the choice, but if another option is selected then Nil Report may not be included in the element. If a Nil Report for a reporting FI is submitted and accepted, then an Account or Pool Report cannot be submitted for the same reporting FI in the same tax year, until the Nil Report has been voided. If an Account Report or Pool Report are submitted and accepted, then a Nil Report cannot be submitted for the same reporting FI in the same tax year, until the Account Report or Pool Report has been voided.

This data element is used to void, amend or correct a Nil Report. It uniquely identifies the FATCA report being transmitted and is described in Section 4.2. DocSpec. For example, if you file a Nil Report and discover that you have accounts to report, you can void the Nil Report and submit an Account and/or Pool Report as new data. If any data element in the Nil Report needs to be updated, you can also submit an amended Nil Report.

This data element is a fixed element and indicates there are no accounts to report. The only allowable value is “yes”.

FATCA XML Schema v2.0 User Guide

46

This data element contains detailed information on the accounts or payments required to be reported. The AccountReport uses the CorrectableAccountReport_Type and contains the account holder, account balance and other related account information.

Table 21 – AccountReport

FATCA XML Schema v2.0 User Guide

47

This element is used to correct, void or amend an Account Report record. It uniquely identifies the FATCA report being transmitted and is described in Section 4.2. DocSpec.

Figure 10 - AccountNumber

This data element provides the account number assigned by the financial institution to uniquely identify the account holder.

• The account number is a required element and can be any of the following:

  • Account number of a custodial account or depository account

  • Code (ISIN or other) related to a debt or equity interest (if not held in a custody account)

  • Identification code of a cash value insurance contract or annuity contract

• If the financial institution has no account numbering system, then enter “NANUM” for no account number.

• If the reporting FI is a withholding agent reporting a withholdable payment made to a payee that is not an account holder, enter NANUM for no account number.

• If the reporting FI is a Direct Reporting NFFE, enter NANUM for no account number.

AcctNumber_Type

The AcctNumberType attribute is optional or can be omitted and is not required for FATCA reporting. The AcctNumberType attribute should not be used for 2014 or 2015 tax years. If included, then the value should be from the list below:

FATCA XML Schema v2.0 User Guide

48

Figure 11 - AccountClosed

This data element indicates the account was closed or transferred in its entirety during the calendar year. If an account holder rolls over the amounts in one account (or type of account) into another account (or another type of account) with the same FFI during the calendar year, do not report the account as closed.

Application requirement :

FFIs reporting an account that is closed or transferred in its entirety should complete this element. Withholding agents should not complete this element. The AccountClosed element should not be used for 2014 or 2015 tax years.

FATCA XML Schema v2.0 User Guide

49

Table 22 – AccountHolder

This data element provides detailed information about the account holder or payee that is an individual or organization. The AccountHolder is a choice which has two options, Individual and Organisation.

This data element provides detailed information and identifies the account holder as a natural person. The structure of the AccountHolder as an Individual is described in Section 4.4. PersonParty_Type.

Individual Account Holder - Address : Enter the account holder’s or payee’s residence address. If the sender does not have a residence address on file for the individual, then enter the mailing address used by the financial institution to contact the individual account holder or payee.

Joint Account Holders – Name: If there are two account holders, include a separate account report for each account holder.

Application Requirement

This data element provides detailed information and identifies the account holder as not a natural person. The structure of the AccountHolder that is an Organisation is described in Section 4.5. OrganisationParty_Type.

FATCA XML Schema v2.0 User Guide

50

Organization Account Holder - Address: The Name and Address data elements are required components and each can be presented more than once. One or more identifiers, such as the TIN, should be added as well as a residence country code.

If the entity account holder or payee has been assigned a U.S. TIN, enter that number. If the entity account holder or payee does not have a U.S. TIN (e.g., a passive NFFE, owner-documented FFI, or nonparticipating FFI), leave the TIN element blank. Do not enter the tax identification number or country code for any jurisdiction outside the U.S.

Note: A Direct Reporting NFFE must create a separate account report for each substantial U.S. owner in order to associate each substantial U.S. owner with an Account Balance (for the value of such owner’s equity interest in the NFFE) and Payment (for the payments to such owner).

This data element is required if the account holder is an organization and identifies an entity account holder or payee. The AcctHolderType data element must be presented as one of the values listed below:

AcctHolderType

Important: FATCA106 should not be used for FATCA reporting to the IRS. Use of FATCA106 will generate an error message. Beginning tax year 2016 and later, FATCA105 can be used only if the filer category is Direct Reporting NFFE (FATCA606).

FATCA XML Schema v2.0 User Guide

51

Table 23 - SubstantialOwner

This data element identifies certain owners of the account holder or payee, and the substantial U.S. owners of a direct reporting NFFE. The SubstantialOwner element supports entities and organizations and describes the account holder as an individual in Section 4.4. PersonParty_Type or organization in Section 4.5. OrganisationParty_Type.

The substantial owner element may be one of the following:

• Each substantial U.S. owner (or, if applicable, controlling person that is a specified U.S. person) of a passive NFFE account holder or payee.

• Each specified U.S. person that owns certain equity or debt interests in an owner-documented FFI account holder or payee.

• Each substantial U.S. owner of a Direct Reporting NFFE (the Direct Reporting NFFE is the Reporting FI).

Note: If the entity account holder or payee is a nonparticipating FFI (NPFFI) or specified US person, do not complete the SubstantialOwner element.

These elements provides the name, address, and TIN of any specified U.S. owners of an owner documented FFI, substantial US owners (or, if applicable, controlling persons that are specified U.S. persons) of a passive NFFE, and substantial U.S. owners of a Direct Reporting NFFE. One or more substantial owners can be added.

FATCA XML Schema v2.0 User Guide

52

Figure 12 - AccountBalance element

This data element provides the account balance or value of the reported financial account or the value of the equity interest in a Direct Reporting NFFE held by a substantial U.S. owner. The appropriate attribute is the 3-letter currency code. The element allows zero (0) and negative balances. The AccountBalance is required and cannot be omitted. For more information, go to Section 6.4.7 Payment.

• In general, the account balance is the average balance or value of the financial account, if the financial institution reports average balance or value to the account holder for a calendar year; otherwise, enter the balance or value of the account as of the end of the calendar year. For information for reporting the balance or value of an equity or debt interest in the FI or a cash value insurance or annuity contract, see Treasury regulations section 1.1471-5(b)(4).

• If account is closed or transferred in its entirety during a calendar year, the account balance is the amount or value withdrawn or transferred from the account in connection with the closure or transfer.

• A withholding agent reporting a withholdable payment made to an account held by an ODFFI should enter the average calendar year balance or value if that amount is reported to the ODFFI; otherwise, enter the account balance or value as of the end of the calendar year. If the account holder is a passive NFFE, enter zero (0) account balance.

• For HCTAs, the account balance or value shall be in accordance with the terms of the Model 1 IGA.

• For Direct Reporting NFFEs, the account balance is, with respect to each substantial U.S. owner, the value of the equity interest in the NFFE held by the substantial U.S. owner.

• If an FI is reporting on a specific payee basis amounts paid to a nonparticipating FFI, then enter zero (0) in the account balance element.

FATCA XML Schema v2.0 User Guide

53

Figure 13 - Payment element

This data element provides account data on certain payments made to an account, payee, or owner, as described below. More than one payment type may be reported.

If the Reporting FI is an FI reporting an account, enter the payments to the account as follows: Depository accounts:

• The aggregate gross amount of interest paid or credited to the account during the calendar year. Use payment type FATCA502.

Custodial accounts:

• The aggregate gross amount of dividends paid or credited to the account during the calendar year. Use payment type FATCA501.

• The aggregate gross amount of interest paid or credited to the account during the calendar year. Use payment type FATCA502.

• The gross proceeds from the sale or redemption of property paid or credited to the account during the calendar year with respect to which the FFI acted as a custodian, broker, nominee, or otherwise as an agent for the account holder. Use payment type FATCA503.

• The aggregate gross amount of all other income paid or credited to the account during the calendar year reduced by reported interest, dividends, and gross proceeds. Use payment type FATCA504.

Debt or equity accounts:

• The aggregate gross amount of payments paid or credited to the account during the calendar year, including redemption payments (in whole or part) of the account. Use payment type FATCA504. Cash value insurance and annuity contract accounts:

• The aggregate gross amount of payments paid or credited to the account during the calendar year, including redemption payments (in whole or part) of the account. Use payment type FATCA504. Foreign reportable amounts: (2015 and 2016 only)

FATCA XML Schema v2.0 User Guide

54

• The aggregate gross amount of foreign reportable amounts paid or credited to a nonparticipating FFI may be reported divided by type of payment (using payment type FATCA501, FATCA502, FATCA503, and/or FATCA504, as applicable), or the entire amount may be reported as “FATCA Other” payment (using payment type FATCA504).

• As an alternative to reporting foreign reportable amounts, the FI may instead report all income, gross proceeds, and redemptions (regardless of source) paid to the nonparticipating FFI during the calendar year (using payment type FATCA504).

If an account is closed or transferred in its entirety during a calendar year, report the amounts paid or credited to the account for the calendar year until the date of transfer or closure using payment types FATCA501, FATCA502, FATCA503, and/or FATCA504, as applicable.

Withholding agents (other than FFIs) Report withholdable payments to the owner-documented FFI or passive NFFE using the payment types FATCA501, FATCA502, FATCA503, and/or FATCA504, as applicable.

Direct Reporting NFFEs Enter the total of all payments made by the NFFE during the calendar year to each substantial U.S. owner (either divided by payment type, or as one amount under FATCA504), including the gross amounts paid or credited to the substantial U.S. owner with respect to such owner’s equity interest in the NFFE during the calendar year, which include payments in redemption or liquidation (in whole or part) of the substantial U.S. owner’s equity interest in the NFFE.

This data element describes the specific payment type.

This data element is a free text field and can be used to provide additional information about the payment type. This element may be used for reciprocal reporting and currently is not used for FATCA reporting to IRS and may be omitted.

FATCA XML Schema v2.0 User Guide

55

Figure 14 - PaymentAmnt element

This data element provides specific payment amount and of MonAmnt_Type as described in Section 4.1. MonAmnt_Type.

Diagram

Table 24 – CARRef_Type

FATCA XML Schema v2.0 User Guide

56

This data element should only be included in FATCA account reports submitted in response to a Competent Authority Request (CAR). The CARRef contains identifying information for a pooled report (ReportingFI GIIN, MessageRefId, and DocRefId elements) and links the account report to the CAR and the original pool report. Any FATCA account report submitted in response to a CAR must include the CARRef element.

Note: The IRS sends a CAR to an HCTA to request additional account information, after it receives a pooled report from a Reporting Model 2 FFI.

This data element identifies the reporting financial institution (ReportingFI) GIIN associated with the original pool report.

This data element references the MesssagRefId of the FATCA XML file that contains the pool report associated with the CAR.

This data element identifies the DocRefId of the pool report related to the CAR.

FATCA XML Schema v2.0 User Guide

57

Figure 15 - AdditonalData element

This data element provides additional information for the account report. Currently, this element is not used for FATCA reporting to the IRS.

Figure 16 – AdditionalItem element

The AdditionalData data element contains one or multiple additional data items. Each item consists of descriptive name and content.

FATCA XML Schema v2.0 User Guide

58

This data element provides information about accounts held by recalcitrant account holders (or, in the case of a reporting FI that is a Reporting Model 2 FFI, non-consenting U.S. accounts) and, for 2015 and 2016, amounts paid to nonparticipating FFIs that are reported on a pooled basis. The element uses the CorrectablePoolReport_Type to specify the report type and balances or payments. Pooled reports should not be used if the message sender is providing information pursuant to a Model 1 IGA.

Table 25 - Pool Report

This data element is described in Section 4.2. DocSpec.

Application Requirement

This data element specifies the total number of accounts reported for pooled reports. For example, if there are 25 accounts described in the pooled report, then enter “25”.

FATCA XML Schema v2.0 User Guide

59

This data element describes pooled reporting account type categories for account holders.

Account Pool Report Types:

Figure 17 - PoolBalance element

This data element provides the amount of the aggregate balance or value for the pooled accounts, other than a pool of nonparticipating FFIs, at the end of the year.

For a pool of nonparticipating FFIs, enter, as the pool balance, the aggregate foreign reportable amounts paid to all nonparticipating FFIs within the reported pool. Instead of reporting foreign reportable amounts, the FI may report all income, gross proceeds, and redemptions (irrespective of source) paid to all nonparticipating FFIs. The data type is described in Section 4.1. MonAmnt_Type.

FATCA XML Schema v2.0 User Guide

60

During the year, a filer may change data reported in one or more records of a previously filed FATCA Report, such as a NilReport, Account Report and/or Pool Report. To facilitate accurate error handling, the XML schema contains correctable data types that allow you to update a specific part of the report without resending the entire report. This section explains how to resubmit corrected, voided or amended data that can be processed and associated with the original data.

The DocSpec data element identifies a specific correctable element in the message and each correctable data type, such as CorrectableAccountReport_Type or CorrectablePoolReport_Type, contains a DocSpec element. This structured element ensures all updates can be traced to a previous record. The DocSpec_Type is described in Section 4.2. DocSpec.

Figure 18 - DocSpec element

Note: These guidelines only apply to electronically filed reports. If the Form 8966 was filed in paper format with the IRS, then the corrected Form 8966 must also be filed in paper format with the IRS. Failure to follow this rule will result in your corrected Form 8966 not being processed by the IRS. The process of correcting, amending and voiding a report filed in paper format is in the Instructions for Form 8966.

The DocSpec contains a MessageRefId and DocRefId that uniquely identify correctable elements and messages. Each identifier must conform to recommended best practices for file format and remain unique across all reports for all time. Any duplicate identifiers will cause an error notification and cannot be reused within the scope of FATCA reporting.

FATCA XML Schema v2.0 User Guide

61

There are a few factors to consider when updating a record. A FATCA XML file must be accepted by the IRS and you must receive a notification before changing the file. If a file is not accepted (rejected) or fails transmission, a new file should be submitted because failed transmissions are not processed. For more information on error notifications, go to Section 1.4 Purpose. This section provides guidelines on how to void, amend and correct a record.

What is a record?

A record consists of filer information, such as ReportingFI and the reporting group information, such as a Sponsor or Intermediary (if any), plus a NilReport or AccountReport or PoolReport.

It is important to note that filer information is always associated with an account record. A ReportingFI, Sponsor or Intermediary (if any) cannot be corrected, voided, or amended alone; only a whole record can be changed.

For example:

• Record 1, Record 2 and Record 3 have the same ReportingFI (CompanyIGA2).

• If you change filer information for a Reporting FI (CompanyIGA2), plus specific record information (Record1), the update only applies to that specific record (Record1). The updated filer information does not apply to other records that contained the same ReportingFI (CompanyIGA2).

• If you void a record (Record2) and another record (Record3) contains the same Reporting FI, you are only voiding that specific record (Record2). The change does not impact the ReportingFI, associated with Record3.

What are failed transmissions and error notifications?

Each record has a unique identifier associated with filer information. Generally, a transmission may fail because of various file level errors, such as decryption, digital signatures or virus scanning. If a transmission fails file level validation, the processing is not completed and you will receive an error notification. In most cases, the user must correct the error and resubmit the file. After the IRS accepts the file, you can only make changes at the record level.

What are the differences between corrected, voided and amended records?

Generally, there are three scenarios for updating a previously filed and accepted FATCA Reports:

• Void: If you discover a record was sent in error and were not required to file, then you can void the record.

• Amend: If you discover a record should be updated and have not received a record level error notification, you can amend the record. In some special cases, as described below, instead of amending a record, you should void the old record and send a new record.

• Correction: If you receive a record-level error notification because the record failed application validation, you should correct the record. Some exceptions may apply.

FATCA XML Schema v2.0 User Guide

62

A record may be amended at any time after you receive a valid file notification. An amended record updates an existing record from a previously filed report.

• All data element fields in the amended record must have the amended values for the relevant account and/or pooled report.

• Do not amend a record in response to a record-level error notification; instead file a corrected record with DocTypeIndic FATCA2.

• Special rules for specific errors or changes may apply.

A record may be voided at any time after you receive a valid file notification and become aware of inaccurate information.

• All data element fields in the voided record must have the same values equal to the original record being voided.

• In most cases, do not void a record in response to a record-level error notification.

• Special rules apply for specific error notifications that require you to void the record (DocTypeIndic FATCA3) and submit a new record with DocTypeIndic FATCA1.

A record should be corrected in response to a record-level error notification.

• All data element fields in the corrected record must have the corrected values for the relevant account and/or pooled report, as noted in the error notification.

• As noted below in Section 7.2.4, special rules apply for specific error notifications that require you to void the record and submit a new record.

• For example:

  • You receive a record level error notification for Element A and you also discover an update to Element B; you can send a corrected record that included updated Element A and with an updated Element B.

  • You receive a record level error notification for Record4, but then discover you were not required to file the record. You can void the record instead of correction.

The following fields cannot be corrected or amended. You must void the record and submit a new record if there is an error in the field.

• No Account Holder or Substantial US Owner TIN

• Incorrect Account Holder or Substantial US Owner TIN

• Incorrect Account Holder or Substantial US Owner Name

• Incorrect Account Holder or Substantial US Owner Name and Address

FATCA XML Schema v2.0 User Guide

63

In addition, for certain IGA jurisdictions the following errors would result in a voided record:

• No Individual Account Holder or Substantial US Owner TIN or Date of Birth

• No Individual Account Holder or Substantial US Owner TIN and Incorrect Date of Birth

Note: For more information on IRS error notifications and resolutions, go to https://www.irs.gov/businesses/corporations/irs-fatca-report-notifications.

This section provides general guidelines on how to complete the data elements when creating a file to correct, amend or void a record. All changes in these fields must be made within the MessageSpec and DocSpec data elements.

MessageSpec

A file contains a MessageSpec element or header that provides information about the sender and specifies the date created, calendar year and reporting period.

DocSpec

The DocSpec uniquely identifies a data element and references the record being corrected, amended or voided.

FATCA XML Schema v2.0 User Guide

64

Note: For testing purposes only, use the applicable DocTypeIndic for test data, such as FATCA12, FATCA13 or FATCA14. Do not send test data to the production environment or production files to the test environment. For more information on testing, go to Section.2.7. System Testing.

Note: Sample files on how to correct, amend or void a record can be found at https://www.irs.gov/businesses/corporations/fatca-xml-reporting-schema-samples-to-correct-amend-or- void-records.

FATCA XML Schema v2.0 User Guide

65

FATCA XML Schema v2.0 User Guide

66

FATCA XML Schema v2.0 User Guide

67

FATCA XML Schema v2.0 User Guide

68

FATCA XML Schema v2.0 User Guide

69

Table 26 - Glossary of terms

FATCA XML Schema v2.0 User Guide

70

FATCA XML Schema v2.0 User Guide

85

FATCA XML Schema v2.0 User Guide

86