Publication 5124 is a historical U.S. technical reference
The April 2017 edition explains FATCA XML schema version 2.0, effective from 17 January 2017. It translates Form 8966 reporting into an electronic message, rather than explaining Singapore’s submission portal. FATCA concerns foreign financial institutions’ U.S. accounts and specified payments, as well as direct-reporting non-financial foreign entities. A passive NFFE generally faces the withholding regime unless it establishes that it has no substantial U.S. owners or discloses those owners; a direct-reporting NFFE reports to the IRS instead. The guide includes 2014–2016 transitional reporting rules, which remain historical rules in this article. Singapore filers must separately follow the applicable IRAS supplementary specifications and local reporting arrangements. Where the narrative differs from the XML schema, the publication says that the schema controls.
Model 1, Model 2 and the identity of the reporting party
Under Model 1, an institution generally reports to its home-country tax authority; it does not automatically send its reports directly to the IRS. The guide also describes Model 1 Option 2, in which the institution sends through IDES to its authority for approval and release. Model 2 institutions generally report directly to the IRS, with the authority involved in competent-authority requests for non-consenting account information. Sponsors report for sponsored institutions or sponsored direct-reporting NFFEs, and a trustee reports for a trustee-documented trust. A territorial financial institution and a withholding agent may have different reporting roles. In the guide’s Model 1 terminology, a passive NFFE’s relevant persons are specified U.S. controlling persons, and a U.S. reportable account follows the applicable intergovernmental agreement. These are not interchangeable with an unspecified category of agents.
GIIN, FIN and enrolment are different concepts
A GIIN is the institution’s FATCA registration identifier, ordinarily 19 characters including its punctuation. Certain filers without a GIIN, including U.S. withholding agents, U.S.-person territorial financial institutions and reporting third parties or software providers, obtain a FATCA Identification Number for IDES enrolment. A FIN belongs in the relevant transmission identity, not in a body field that requires the reporting entity’s GIIN or tax number. Appearance of a FIN on the monthly FFI list does not establish that the holder is an FFI or determine its withholding status. The guide points to Publication 5118 for registration, 5147 for the FFI list, 5190 for IDES, 5188 for metadata, 5189 for ICMM and 5216 for notifications. Security publications 4557 and 4600 and the Form 8966 instructions address separate supporting matters.
Message hierarchy, version and validation
The root FATCA_OECD contains a version attribute, one MessageSpec and one or more FATCA bodies. Each body contains a ReportingFI and one or more ReportingGroups. A group can contain Sponsor and Intermediary information, then either a NilReport or account reports and/or pool reports. Version 2.0 is not backward-compatible with version 1.1; even a correction of an older submission must use the required version 2.0 structure. The publication distinguishes schema-required fields from fields that are mandatory under application rules, and from optional fields that an IGA may nevertheless require. Fields marked null are not used for this reporting purpose. Schema failures can reject the file, while business-rule failures can identify individual records. A technically valid optional element is therefore not necessarily an acceptable omission.
Encoding, namespaces and safe text values
Use UTF-8, not UTF-16 or UTF-32. The guide recommends extended Latin characters and limits identifiers to a practical set of letters, digits, plus, underscore, hyphen and period. Its principal namespaces are ftc urn:oecd:ties:fatca:v2, sfa urn:oecd:ties:stffatcatypes:v2, iso urn:oecd:ties:isofatcatypes:v1 and stf urn:oecd:ties:stf:v4. Ampersand and less-than characters must be represented by XML entities; greater-than, apostrophe and quotation-mark entities may also be used. Threat checks can reject patterns such as double hyphens, slash-asterisk and ampersand-hash, as well as certain SQL-like text after quotation marks. IDES packaging, filename case, certificates and encryption have their own requirements. Testing requires valid test credentials and must use the test environment rather than production codes.
MessageSpec identifies sender, jurisdiction and reporting year
SendingCompanyIN is the sender’s GIIN, the authority’s tax-authority identifier in GIIN format, or the appropriate FIN for a non-GIIN sender. TransmittingCountry uses the two-letter ISO code of the jurisdiction where the reported account is maintained, not automatically the head-office jurisdiction. For direct-reporting NFFEs it follows residence; sponsors follow the relevant account or NFFE jurisdiction, and withholding agents follow the payer’s residence. ReceivingCountry is US for an IRS-bound message and MessageType is FATCA. The optional Warning allows up to 4,000 characters; Contact allows up to 200 but is marked unused for this processing. ReportingPeriod is the reporting year’s 31 December in YYYY-MM-DD format, without a future period. Timestamp follows YYYY-MM-DDThh:mm:ss without fractional seconds.
Message and document references must remain unique
MessageRefId is unique across every file sent by that sender, has a maximum of 200 characters and is preferably based on a GUID. The message-level CorrMessageRefId can repeat to identify several original messages, but must not accompany new-data FATCA1 reporting. Each correctable ReportingFI, Sponsor, Intermediary, NilReport, AccountReport and PoolReport has its own DocSpec and permanently unique DocRefId. DocRefId has a minimum of 21 and maximum of 200 characters: the 19-character GIIN, a period and a unique suffix are the guide’s required pattern. Reusing an identifier for a different record is not acceptable. Monetary fields use an ISO three-letter currCode and no more than two fractional decimal places; do not add thousands separators to the XML numeric value.
DocTypeIndic distinguishes new, corrected, voided and amended data
Production FATCA1 is new data; FATCA2 corrects data after an IRS record-level error notification; FATCA3 voids an accepted record; FATCA4 amends an accepted record when the filer discovers the problem independently. Test equivalents are FATCA11, FATCA12, FATCA13 and FATCA14. The guide recommends one operation type in a file, rather than mixing new, correction, void and amendment records. Multiple corrections may refer to different original messages. For FATCA2, 3 and 4, CorrMessageRefId and CorrDocRefId identify the original message and original element. They are not references to the new file itself. A file-level rejection, including the notification categories N1–N4 discussed in the guide, is not a reason to send a record correction against data that were never accepted.
Addresses use a fixed structure or an unstructured alternative
CountryCode is mandatory even when the rest of the address is free text. AddressFix is preferred and requires City; Street, BuildingIdentifier, SuiteIdentifier, FloorIdentifier, DistrictName, POB, PostCode and CountrySubentity are optional structured components, generally limited to 200 characters each. AddressFree permits up to 4,000 characters and can stand alone when components cannot be separated, or supplement AddressFix. The optional legalAddressType code list is OECD301 residential or business, 302 residential, 303 business, 304 registered office and 305 unspecified, but the publication marks that attribute unused. The schema diagram confirms that CountryCode sits outside the choice between AddressFree and AddressFix, so using free text does not remove the country requirement.
Individuals: names, U.S. TIN and limited birth-date reporting
An individual must have a name and address. FirstName and LastName are required; where a first name is unavailable the guide permits an initial or NFN. Titles, prefixes, suffixes, name-type attributes and nationality are marked unused rather than extra mandatory identity requirements. U.S. SSNs and ITINs have nine digits; the guide permits unpunctuated or its stated hyphenated forms. TIN may be optional in the schema but mandatory in application rules, subject to the relevant IGA. An omitted issuedBy country is assumed to be US. BirthDate uses YYYY-MM-DD and is used in the specified authority/IGA pre-existing-account situations in lieu of a TIN; it is not a general exemption from obtaining a TIN. Birthplace components are marked unused. For an individual account holder, use the residence address or mailing address if the former is unavailable.
Organisations and correctable organisation records
An Organisation has at least one legal name and one address. Residence country and TIN can repeat, but identifiers must fit the entity’s actual reporting role: a U.S. TIN, GIIN or expressly permitted blank is not interchangeable with a foreign tax number or a FIN. Organisation name-type codes include SMFAlias, Individual, Alias, Nick, AKA, DBA, Legal and AtBirth under OECD201–208, but are not required for the IRS use described. CorrectableReportOrganisationParty extends the organisation data with FilerCategory and a required DocSpec. The same structure is reused for ReportingFI, Sponsor and Intermediary; reuse of the structure does not make every category code valid for every role.
FilerCategory: all eleven role codes and year limitations
FilerCategory applies from reporting year 2016, not 2014 or 2015. FATCA601 identifies a participating FFI other than Model 2; 602 a registered deemed-compliant FFI including Model 1; 603 a limited branch; 604 a Model 2 FFI; 605 a QI, WP or WT; 606 a direct-reporting NFFE; 607 a sponsor of an FFI; 608 a sponsor of a direct-reporting NFFE; 609 a trustee of a trustee-documented trust; 610 a withholding agent; and 611 a territorial financial institution that is a U.S. person. Code 610 also addresses the specified U.S. branches in the guide, with treatment depending on FFI status and whether the branch is treated as a U.S. person. ReportingFI generally supplies its category, but a sponsored FFI, sponsored direct-reporting NFFE and trustee-documented trust omit it there. Sponsor must use 607, 608 or 609. Intermediary must not contain FilerCategory.
ReportingFI identifiers depend on status and branch
ReportingFI identifies the institution maintaining the account, the payer making the reportable payment, or the direct-reporting NFFE. Use the GIIN of the branch maintaining the account rather than automatically the head office’s GIIN. The guide’s table uses a GIIN for participating or registered deemed-compliant institutions, Model 1 institutions, direct-reporting NFFEs, most sponsored FFIs and sponsored direct-reporting NFFEs; a QI, WP or WT supplies both GIIN and EIN. A U.S.-person territorial financial institution or withholding agent uses a U.S. EIN. The table explicitly leaves TIN blank for limited institutions, trustee-documented trusts and closely held sponsored investment vehicles in its specified categories. A general error footnote below the table must not be read as permission to invent an identifier for those blank categories; resolve role-specific treatment against the schema and applicable local specification. The address is the mailing address or relevant account-maintaining branch office.
Sponsors, trustees and intermediaries
For a sponsored institution or direct-reporting NFFE, identify that entity in ReportingFI and the sponsor in Sponsor. For a trustee-documented trust, identify the trust in ReportingFI and the trustee in Sponsor. The sponsor or trustee must use the GIIN registered for that capacity, rather than a Single, Lead or Member GIIN held in another capacity. The appropriate sponsor category is 607, 608 or 609. Intermediary describes the relevant territorial institution or certified deemed-compliant intermediary; a non-U.S.-person territorial institution uses its IRS TIN or territorial EIN, while an applicable certified deemed-compliant institution without a GIIN or TIN leaves the field blank. Intermediary never supplies a FilerCategory. Both sponsor and intermediary records still need their own unique DocSpec.
NilReport is an alternative, not a zero-account pool
A NilReport declares that there are no reportable accounts, or that a direct-reporting NFFE has no substantial U.S. owners. The publication generally treats nil reporting as optional except for direct-reporting and sponsored direct-reporting NFFEs, but an IGA or local rule may require it. The ReportingFI and applicable Sponsor remain necessary. NoAccountToReport contains the literal value yes. A nil report cannot coexist with account or pool reporting for that institution and year: an accepted nil report must first be voided before new account records are sent, and accepted account data must be handled before a nil declaration can replace them. A zero-count PoolReport is invalid. The guide says older zero-count pools need not be voided merely because they used that old convention; newly discovered reportable accounts require a new valid pool.
Account number, closure and joint holders
AccountNumber is required. NANUM is used where no numbering system exists, where a withholding-agent payee has no relevant account, or for a direct-reporting NFFE. The optional AcctNumberType starts with 2016 reporting: OECD601 is IBAN, 602 another bank account number, 603 ISIN, 604 another securities number and 605 another identifier. AccountClosed also starts with 2016 and must not be used for 2014 or 2015. It addresses an actual closure or complete transfer from the institution; an internal rollover within the same institution does not itself close the account, and a withholding agent omits this indicator. AccountHolder selects either an individual or an organisation. Two reportable joint holders require separate reports, rather than a combined identity field. A direct-reporting NFFE similarly creates a separate report for each substantial U.S. owner with the relevant value and payments.
Organisation account-holder codes and substantial owners
An organisation account holder requires AcctHolderType: FATCA101 is an owner-documented FFI with relevant U.S. owners; 102 a passive NFFE with substantial U.S. owners or the IGA’s relevant U.S. controlling persons; 103 a non-participating FFI; 104 a specified U.S. person; 105 a direct-reporting NFFE; and 106 is reserved for U.S. government use, not for an FI or home authority. Code 105 applies from 2016; the narrative associates it with direct-reporting category 606, while sponsored reporting has its separate sponsor category 608. Those distinct role fields should not be collapsed into one code. An organisation’s account-holder TIN is the U.S.-assigned TIN, if any; do not substitute a foreign TIN and foreign issuing country into that field. SubstantialOwner can repeat and can be an individual or organisation. It applies to the appropriate owner-documented FFI, passive NFFE or direct-reporting NFFE reporting, but not to a non-participating FFI or specified U.S.-person holder.
AccountBalance varies with the type of reporting
AccountBalance is mandatory and may be zero or negative, with a required currency code. Use the reported average value if the institution reports on that basis; otherwise the guide generally uses year-end balance. For closure or full transfer, report the amount withdrawn or transferred under the applicable rule rather than automatically inserting zero. A withholding agent reporting an owner-documented FFI uses the relevant average or year-end value, while a passive-NFFE payee or non-participating-FFI payee has a zero account balance for the stated payment-reporting situations. An authority follows the IGA’s requirements. A direct-reporting NFFE reports the value of each substantial U.S. owner’s equity interest. Thus the same XML field represents different measured items depending on the reporting role.
Payment codes and the categories to aggregate
FATCA501 is dividends, 502 interest, 503 gross proceeds or redemptions and 504 other reportable payments. A depository account reports gross interest; a custodial account separates dividends, interest, gross sale/redemption proceeds and the other applicable amounts. Debt or equity interests and cash-value insurance or annuity contracts aggregate their relevant payments, including redemptions, under 504. For an account closed during the year, include payments up to closure. PaymentAmnt is required whenever a Payment is supplied and uses the monetary currency/decimal format. PaymentTypeDesc permits up to 4,000 characters but is not used for the IRS reporting described; it can support reciprocal reporting contexts. Reporting payments correctly requires classifying their nature, not simply copying the year-end balance.
Special payment reporting and competent-authority references
The guide’s non-participating-FFI payment reporting is limited to 2015 and 2016. It permits the specified foreign-reportable amounts by payment type, or aggregation under 504; its alternative election reports the specified all-source income, proceeds and redemption amounts. A withholding agent reports the relevant withholdable payments to owner-documented FFIs or passive NFFEs. A direct-reporting NFFE reports total payments to each substantial U.S. owner, including liquidation and redemption payments. CARRef is for Model 2 responses to a competent-authority request and identifies the original pool’s GIIN, MessageRefId and DocRefId, each within the stated 200-character limit. AdditionalData is not used for the IRS purpose; where another permitted use applies, each AdditionalItem requires a name, up to 200 characters, and content, up to 4,000.
PoolReport: eligible populations and positive account counts
Pool reporting is for the guide’s Model 2 recalcitrant or non-consenting populations and the historical non-participating-FFI cases, not ordinary Model 1 account reporting. AccountCount is a positive integer; zero is not valid. AccountPoolReportType is FATCA201 for U.S. indicia, 202 for no U.S. indicia, 203 dormant accounts, 204 non-participating FFIs for 2015/2016, 205 U.S. persons and 206 passive NFFEs. Each pool has its own DocSpec. PoolBalance ordinarily aggregates year-end account values. For the non-participating-FFI pool, it aggregates the specified reportable foreign payments, or the elected all-source alternative, rather than account balances. A currency code remains mandatory. Different populations and currencies must be organised into the appropriate records rather than combined indiscriminately.
Corrections replace the complete reporting context
Wait for acceptance and the relevant notification before submitting an operation against an earlier record. A rejected transmission or rejected file is resent as new data using new identifiers. A valid correction or amendment includes the complete relevant record, with the ReportingFI, applicable Sponsor or Intermediary and the account, nil or pool data; do not send only a changed FI fragment. Changing the FI information associated with one account record does not automatically change other accounts that share that institution. A correction prompted by an IRS error can also include other newly discovered changes in that record. If a record should never have been reportable, void it. The publication’s diagrams show that each correctable organisation and report has a separate DocSpec; those references must identify the actual original element being replaced.
Identity errors require voiding and new reporting
The guide requires void-then-new treatment for specified identity defects, including missing or incorrect TINs, incorrect account-holder or substantial-owner names, and the stated combined name/address errors. Its IGA cases also address missing TIN or date of birth and incorrect birth dates. Do not use an amendment to silently change the identity of the previously accepted person. A FATCA3 void reproduces the original record’s data and uses its original references; it is followed, where appropriate, by a fresh FATCA1 report with new identifiers. Ordinary changes to other accepted information can use FATCA4 when independently discovered, while IRS-notified record errors use FATCA2. A paper Form 8966 correction remains a paper correction, not an XML correction to a nonexistent electronic record.
Glossary and schema appendices make the structure readable
The glossary distinguishes participating, registered deemed-compliant, owner-documented and non-participating FFIs; active/passive and direct-reporting NFFEs; branches, sponsors, authorities and the different reporting models. A branch’s account-maintaining jurisdiction follows the applicable legal and operating context, not merely its parent’s postal address. Appendices B–P then map the root, header, ReportingFI, ReportingGroup, AccountReport, PoolReport, individual/organisation account holders, substantial owners, Sponsor/Intermediary, PersonParty, Address, OrganisationParty, correctable organisation and DocSpec structures. Solid and dashed boxes and repeat counts show required versus optional components and repetition. In particular, account holders and substantial owners choose between individual and organisation; organisations require names and addresses; correctable records add DocSpec; and the group chooses nil reporting instead of account/pool reporting. Read these diagrams together with the application rules, because an optional schema box can still be mandatory for a particular reporting role.
Official source
This article independently explains the substantive contents of the official PDF, including the relevant conditions, procedures and annexes. The linked document remains the authoritative source for its original wording, and later changes should be checked separately.
Read the official PDF ↗