Форма 8966 инструкция по заполнению на русском

Identifying numbers for paper Forms 8966.

Beginning in 2018, the unique identifying number must be entered in the “Identifier” box provided at the top of the form. If the filer is submitting an amended, corrected, or voided Form 8966, it must continue to include the same unique identifying number that was reported on the original Form 8966 that is being amended, corrected, or voided.

Reporting on accounts held by nonparticipating Foreign Financial Institutions (FFIs).

Reporting by participating FFIs (PFFIs) (including Reporting Model 2 FFIs) on accounts held by nonparticipating FFIs was only required for 2015 and 2016. For 2017 and subsequent years, PFFIs (including Reporting Model 2 FFIs) are not required to report an account held by a nonparticipating FFI in Part II or Part V. Therefore, PFFIs (including Reporting Model 2 FFIs) should not check the box for “nonparticipating FFI” on line 5 of Part II, should not check the pooled reporting type “nonparticipating FFI” on line 1 of Part V, and should not complete line 3 of Part V.

Reporting Model 2 FFI related entities or branches.

Reporting Model 2 FFIs may have related entities or branches provided that the conditions in the Model 2 intergovernmental agreement (IGA) are met, including the requirement that the related entity or branch reports U.S. accounts to the IRS to the extent permitted. A related entity or branch of a Reporting Model 2 FFI filing Form 8966 should select the filer category code for limited branch or limited FFI on line 1b of Part I.

Reporting Model 2 FFIs reporting on non-consenting U.S. accounts.

If a Reporting Model 2 FFI is reporting a preexisting account that is a non-consenting U.S. account, the Reporting Model 2 FFI should use the pooled reporting category for recalcitrant account holders that are U.S. persons or recalcitrant account holders with U.S. indicia (as appropriate). If a Reporting Model 2 FFI is reporting a new individual account that has a change in circumstances that causes the Reporting Model 2 FFI to know or have reason to know that the original self-certification is incorrect or unreliable and the Reporting Model 2 FFI is unable to obtain a valid self-certification establishing whether the account holder is a U.S. citizen or resident, the Reporting Model 2 FFI should use the pooled reporting category for recalcitrant account holders with U.S. indicia.

U.S. branches.

On line 1b of Part I, all U.S. branches of an FFI not treated as U.S. persons should select the filer category code for PFFIs (code 01). All U.S. branches that are treated as U.S. persons should select the filer category code for withholding agents (code 10).

Note.

A separate Form 8966 must be filed for each substantial U.S. owner of a passive NFFE and each specified U.S. person owning certain equity or debt interests in an ODFFI, and for each group of accounts of an FFI for which pooled reporting is permitted as described in Part V.

• PFFI. A PFFI must file Form 8966 to report information with respect to U.S. accounts, accounts held by ODFFIs, and accounts held by recalcitrant account holders (based on the pools described in Part V).

• U.S. branch of an FFI not treated as a U.S. person. A U.S. branch of an FFI that is not treated as a U.S. person is subject to the same Form 8966 reporting requirements as a PFFI. See Regulations section 1.1471-4(d)(2)(iii)(C).

• Registered deemed-compliant FFI (RDCFFI). An RDCFFI must file Form 8966 to report a U.S. account for which it has reporting obligations as a condition of its applicable RDCFFI status. See Regulations section 1.1471-5(f)(1)(i) or an applicable Model 2 IGA.

• Related entity or branch described in an applicable Model 2 IGA. A related entity or branch described in an applicable Model 2 IGA must file Form 8966 to report a U.S account to the extent permitted under the relevant laws pertaining to the branch or FFI.

• Reporting Model 2 FFI. A Reporting Model 2 FFI must file Form 8966 to report information with respect to U.S. accounts, accounts held by ODFFIs, and non-consenting U.S. accounts (based on the pools described in the instructions for Reporting Model 2 FFIs in Part V).

• Qualified Intermediary (QI), Withholding Foreign Partnership (WP), or Withholding Foreign Trust (WT). A QI, WP, or WT must file Form 8966 to report on its accounts, partners, beneficiaries, or owners, as applicable and as provided in its QI, WP, or WT agreement.

• Direct Reporting NFFE. A Direct Reporting NFFE must file Form 8966 to report its substantial U.S. owners or report that it has none. See Regulations section 1.1472-1(c)(3).

• Sponsoring Entity. A Sponsoring Entity must file Form 8966 to report an account of an FFI or a substantial U.S. owner of a passive NFFE that it has agreed to treat as a Sponsored FFI or a Sponsored Direct Reporting NFFE. See Regulations section 1.1471-4(d)(2)(ii)(C) regarding the reporting required of a Sponsoring Entity acting on behalf of a Sponsored FFI. See Regulations section 1.1472-1(c)(5) regarding the reporting required of a Sponsoring Entity acting on behalf of a Sponsored Direct Reporting NFFE.

  Sponsored FFIs and Sponsored Direct Reporting NFFEs do not need to file Form 8966 if a Sponsoring Entity is reporting on its behalf.

• Trustee-Documented Trust. A trustee of a Trustee-Documented Trust reports on Form 8966 all information required to be reported under an applicable IGA as if it were a Reporting Model 2 FFI with respect to each U.S. account maintained by the Trustee-Documented Trust.

Special Rules for Certain Form 8966 Filers

Combined Reporting Following a Merger or Bulk Acquisition of Accounts

If a PFFI (including a Reporting Model 2 FFI) (successor) acquires accounts of another PFFI (including a Reporting Model 2 FFI) (predecessor) in a merger or bulk acquisition of accounts, the successor may assume the predecessor’s obligations to report the acquired accounts on Form 8966 for the calendar year in which the merger or acquisition occurs, provided the requirements in Regulations section 1.1471-4T(d)(2)(ii)(G)(1) through (4) are satisfied.

When to file.

Form 8966 is required to be filed for the 2022 calendar year on or before March 31, 2023. A Reporting Model 2 FFI must file Form 8966 on the same filing dates that apply to a PFFI, unless a different reporting date is specified in an applicable Model 2 IGA.

Extension of time to file.

An automatic 90-day extension of time to file Form 8966 may be requested. To request an automatic 90-day extension of time to file Forms 8966, file Form 8809-I. See the Instructions for Form 8809-I for where to file that form. You should request an extension as soon as you are aware that an extension is necessary, but no later than the due date for filing Forms 8966. No extension of time to file is permitted for Forms 8966 filed by a Reporting Model 2 FFI to report a non-consenting U.S. account. A Reporting Model 2 FFI should refer to the applicable Model 2 IGA for the due dates for those filings.

Under certain hardship conditions, the IRS may grant an additional 90-day extension to file Form 8966. See Regulations section 1.1471-4(d)(3)(vii). To request an additional 90-day extension of time to file Form 8966, file a second Form 8809-I before the end of the initial extended due date. See the Instructions for Form 8809-I for more information on the requirements for requesting an additional extension for filing Form 8966.

Each branch requesting an automatic or additional extension must file a separate Form 8809-I.

Electronic filing requirement.

An entity that is a financial institution is required to file Form 8966 electronically, irrespective of the number of Forms 8966 filed. All other filers are strongly encouraged to electronically file Forms 8966. To request a waiver from the required filing of Forms 8966 electronically, submit Form 8508-I. Waiver requests should be filed at least 45 days before the due date of the returns. See the instructions for Form 8508-I for where to file and additional information.

How to file electronically.

Those filing electronically should refer to Pub. 5124 for instructions on how to populate the fields for the electronic Form 8966. These instructions can generally be used to supplement Pub. 5124. Information on how to submit the Form 8966 electronically to the IRS is provided in Pub. 5190 and Pub. 5188.

If you are required to file electronically but fail to do so, and you do not have an approved waiver on record, penalties under sections 6721 through 6724 may apply.

Where to file paper Form 8966.

If you have received a waiver of the Form 8966 electronic filing requirement from the IRS or are not otherwise required to file Form 8966 electronically, you may send all paper Forms 8966, along with Form 8966-C, Cover Sheet for Form 8966 Paper Submissions, to the following address.

More information and updates to Form 8966.

For information about FATCA, including updates to Form 8966 and its instructions, as well as answers to Frequently Asked Questions, go to IRS.gov/FATCA.

Account/financial account.

An account or financial account means a financial account described in Regulations section 1.1471-5(b).

Account holder.

An account holder is the person who holds a financial account, as determined under Regulations section 1.1471-5(a)(3).

Account maintained by a PFFI or Reporting Model 2 FFI.

An account maintained by a PFFI or Reporting Model 2 FFI means an account that a PFFI or Reporting Model 2 FFI is treated as maintaining under Regulations section 1.1471-5(b)(5).

Branch.

A branch means a unit, business, or office of a financial institution that is treated as a branch under the regulatory regime of a country or that is otherwise regulated under the laws of a country as separate from other offices, units, or branches of the financial institution, and includes a disregarded entity of a financial institution. A branch includes units, businesses, and offices of a financial institution located in the country (or jurisdiction) in which the financial institution is a resident as well as units, businesses, and offices of a financial institution located in the country in which the financial institution is created or organized. All units, businesses, or offices of a PFFI located in a single country (or jurisdiction), including all disregarded entities located in such single country (or jurisdiction), must be treated as a single branch.

Branch that maintains an account.

A branch, including a disregarded entity, maintains an account if the rights and obligations of the account holder and the FFI with regard to such account (including any assets held in the account) are governed by the laws of the country of the branch or disregarded entity.

Direct Reporting NFFE.

A Direct Reporting NFFE is an NFFE that has elected to report its substantial U.S. owners to the IRS pursuant to Regulations section 1.1472-1(c)(3).

Deemed-compliant FFI.

A deemed-compliant FFI means an FFI that is treated, pursuant to section 1471(b)(2) and Regulations section 1.1471-5(f), as meeting the requirements of section 1471(b).

Excepted NFFEs.

Excepted NFFEs include NFFEs that are QIs, WPs, and WTs, certain publicly traded corporations (including certain affiliates of such corporations), certain territory entities, active NFFEs, excepted nonfinancial entities, Direct Reporting NFFEs, and Sponsored Direct Reporting NFFEs as described in Regulations section 1.1472-1(c)(1).

Exempt beneficial owner.

An exempt beneficial owner is any person described in Regulations section 1.1471-6(b) through (g) and includes any person treated as an exempt beneficial owner under an applicable Model 1 IGA or Model 2 IGA.

Financial institution (FI).

An FI is any institution that is a depository institution, custodial institution, investment entity, insurance company (or holding company of an insurance company) that issues cash value insurance or annuity contracts, or a holding company or treasury center that is part of an expanded affiliated group of certain FFIs, and includes a financial institution as defined under an applicable Model 1 IGA or Model 2 IGA. See Regulations section 1.1471-5(e)(1).

Foreign financial institution (FFI).

Except as otherwise provided for certain foreign branches of a U.S. financial institution or Territory Financial Institution, an FFI means a financial institution that is a foreign entity. The term foreign financial institution also includes a foreign branch of a U.S. financial institution with a QI Agreement in effect.

Foreign reportable amount.

The term “foreign reportable amount” means the aggregate amount of foreign source payments described in Regulations section 1.1471-4(d)(4)(iv).

Global intermediary identification number (GIIN).

A GIIN is a number assigned to a PFFI, Reporting Model 1 FFI, Reporting Model 2 FFI, RDCFFI, and certain other registering entities (for example, a Direct Reporting NFFE). A separate GIIN will be issued to the FFI to identify, among other things, each jurisdiction where the FFI maintains a branch not treated as a limited branch. A Direct Reporting NFFE will be issued only one GIIN, irrespective of where it maintains branches.

Model 1 IGA.

A Model 1 IGA means an agreement between the United States or the Treasury Department and a foreign government or one or more foreign agencies to implement FATCA through reporting by financial institutions to such foreign government or agency thereof, followed by automatic exchange of the reported information with the IRS. For a list of jurisdictions treated as having an IGA in effect, see Treasury.gov/Policy-Issues/Tax-Policy/Foreign-Account-Tax-Compliance-Act.

Model 2 IGA.

A Model 2 IGA means an agreement or arrangement between the United States or the Treasury Department and a foreign government or one or more foreign agencies to implement FATCA through reporting by financial institutions directly to the IRS in accordance with the requirements of the FFI agreement, as modified by an applicable Model 2 IGA, supplemented by the exchange of information between such foreign government or agency thereof and the IRS. For a list of jurisdictions treated as having an IGA in effect, see Treasury.gov/Policy-Issues/Tax-Policy/Foreign-Account-Tax-Compliance-Act.

Non-consenting U.S. account.

For purposes of a Reporting Model 2 FFI, a non-consenting U.S. account shall have the meaning that it has under an applicable Model 2 IGA.

Non-financial foreign entity (NFFE).

A non-financial foreign entity (NFFE) is a foreign entity that is not a financial institution. An NFFE includes a territory NFFE as defined in Regulations section 1.1471-1(b)(132) and a foreign entity treated as an NFFE pursuant to a Model 1 IGA or Model 2 IGA.

Nonparticipating FFI.

A nonparticipating FFI is an FFI other than a PFFI, a deemed-compliant FFI, or an exempt beneficial owner.

Nonreporting FI.

A nonreporting FI means an entity that is resident in or established in a jurisdiction that has in effect a Model 1 IGA or Model 2 IGA and that is treated as a nonreporting FI in Annex II of the applicable Model 1 IGA or Model 2 IGA or that is otherwise treated as a deemed-compliant FFI or an exempt beneficial owner under Regulations sections 1.1471-5 or 1.1471-6.

Owner-documented FFI (ODFFI).

An ODFFI is an FFI described in Regulations section 1.1471-5(f)(3).

Participating FFI (PFFI).

A PFFI is an FFI that has agreed to comply with the requirements of an FFI agreement with respect to all branches of the FFI, other than a branch that is a reporting Model 1 FFI or a U.S. branch. The term PFFI also includes an FFI or branch of an FFI described in a Model 2 IGA that has agreed to comply with the requirements of an FFI agreement with respect to a branch, and a QI branch of a U.S. financial institution, unless such branch is a reporting Model 1 FFI.

Passive NFFE.

A passive NFFE is an NFFE that is not an excepted NFFE. With respect to a Reporting Model 2 FFI filing this Form 8966 to report its accounts and payees, a passive NFFE is an NFFE that is not an active NFFE (as defined in the applicable Model 2 IGA).

Pooled reporting.

For purposes of this form, a PFFI is permitted to report recalcitrant account holders (or, with respect to a Reporting Model 2 FFI, non-consenting U.S. accounts) on an aggregate basis in a reporting pool rather than report specific account holder information. With respect to recalcitrant account holders, a reporting pool consists of account holders that fall within a particular type described in Regulations section 1.1471-4(d)(6). With respect to non-consenting U.S. accounts, see Accounts and Withholdable Payments Required To Be Reported—Accounts for which pooled reporting is permitted, later.

Qualified Intermediary (QI), Withholding Foreign Partnership (WP), Withholding Foreign Trust (WT).

A QI is a foreign entity (or foreign branch of a U.S. financial institution) that has in effect a QI agreement with the IRS. A WP is a foreign partnership that has in effect a withholding foreign partnership agreement with the IRS. A WT is a foreign trust that has in effect a withholding foreign trust agreement with the IRS.

Recalcitrant account holder.

A recalcitrant account holder is an account holder (other than an account holder that is an FFI) of a PFFI or registered deemed-compliant FFI that has failed to provide the FFI maintaining its account with the information required under Regulations section 1.1471-5(g).

Registered deemed-compliant FFI (RDCFFI).

A registered deemed-compliant FFI is an FFI described in Regulations section 1.1471-5(f)(1), and includes a Reporting Model 1 FFI, a QI branch of a U.S. financial institution that is a Reporting Model 1 FFI, and a nonreporting FI treated as a registered deemed-compliant FFI under a Model 2 IGA.

Related entity or branch of a Reporting Model 2 FFI.

A related entity or branch of a Reporting Model 2 FFI is an entity or branch treated as a nonparticipating FFI under Article 3(5) of the Model 2 IGA (or any analogous provision in an applicable Model 2 IGA).

Reporting Model 1 FFI.

A Reporting Model 1 FFI is an FI, including a foreign branch of a U.S. financial institution, treated as a reporting financial institution under a Model 1 IGA.

Reporting Model 2 FFI.

A Reporting Model 2 FFI is an FI or branch of an FI treated as a reporting financial institution under a Model 2 IGA.

Specified U.S. person.

A specified U.S. person is any U.S. person described in Regulations section 1.1473-1(c).

Sponsored Direct Reporting NFFE.

A Sponsored Direct Reporting NFFE is a Direct Reporting NFFE that has a Sponsoring Entity perform due diligence and reporting requirements on behalf of the Sponsored Direct Reporting NFFE as described in Regulations section 1.1472-1(c)(5).

Sponsored FFI.

A Sponsored FFI is an FFI that is an investment entity, a controlled foreign corporation, or a closely held investment vehicle that has a Sponsoring Entity that performs certain due diligence, withholding, and reporting obligations on behalf of the Sponsored FFI.

Sponsoring Entity.

A Sponsoring Entity is an entity that has registered with the IRS to perform the due diligence, withholding, and reporting obligations of one or more Sponsored FFIs or Sponsored Direct Reporting NFFEs.

Substantial U.S. owner.

A substantial U.S. owner is a specified U.S. person described in Regulations section 1.1473-1(b). For purposes of filing this form, a Reporting Model 2 FFI reporting an account held by a passive NFFE should substitute the term “controlling person that is a specified U.S. person” for “substantial U.S. owner” and refer to the applicable Model 2 IGA for the definition of controlling person. A territory NFFE that is not an excepted NFFE determines its substantial U.S. owners by applying the 10% threshold in Regulations section 1.1473-1(b)(1).

Territory Financial Institution.

A Territory Financial Institution is a financial institution that is incorporated or organized under the laws of any U.S. territory, excluding a territory entity that is a financial institution only because it is an investment entity.

Territory Financial Institution treated as a U.S. person.

A Territory Financial Institution treated as a U.S. person means a Territory Financial Institution treated as a U.S. person under Regulations section 1.1471-3(a)(3)(iv).

Trustee-Documented Trust.

A Trustee-Documented Trust is a trust described as such in a Model 1 IGA or Model 2 IGA.

U.S. account.

A U.S. account is any account held by one or more specified U.S. persons. A U.S. account also includes any account held by a passive NFFE that has one or more substantial U.S. owners, or in the case of a Reporting Model 2 FFI, any account held by a passive NFFE that has one or more controlling persons that are specified U.S. persons. See Regulations section 1.1471-5(a) and an applicable Model 2 IGA.

U.S. branch treated as a U.S. person.

A U.S. branch treated as a U.S. person is a U.S. branch that is treated as a U.S. person under Regulations section 1.1441-1(b)(2)(iv)(A).

Withholding agent.

With respect to a withholdable payment, a withholding agent is a person described in Regulations section 1.1473-1(d).

Withholdable payment.

A withholdable payment is a payment described in Regulations section 1.1473-1(a).

Accounts to be reported.

A PFFI, Reporting Model 2 FFI, or RDCFFI required to report as if it is a PFFI must file a separate Form 8966 annually for each account required to be reported, or for each group of accounts for which pooled reporting is permitted, in accordance with the FFI agreement and Regulations section 1.1471-4(d). Such an FFI must report with respect to accounts required to be reported that are maintained at any time during each calendar year. This includes accounts that the FFI is required to treat as U.S. accounts or accounts held by ODFFIs, including accounts that are identified as U.S. accounts following a change in circumstances during such year or due to the expiration during such year of the time period provided in the applicable due diligence procedures for documenting the account holder. Such an FFI must also report accounts that are treated as held by recalcitrant account holders at the end of the calendar year. If an account holder rolls over the amounts in one account into another account (of the same or different type) with the same FFI during the calendar year, do not report the account twice. Form 8966 reporting is required for the following accounts.

Account information to be reported.

The following information is reported on Form 8966. See Specific Instructions, later, to determine the information you are required to report based on your filing status.

Withholding Agent Reporting

A withholding agent (other than an FFI reporting accounts maintained by such FFI under the account reporting rules described earlier in Accounts and Withholdable Payments Required To Be Reported), files Form 8966 to report the following in connection with a withholdable payment.

Form 8966 Completion

Special instructions for filers not specifically listed in chart.

For purposes of applying the specific instructions (including this chart), a withholding agent includes a U.S. branch or Territory Financial Institution treated as a U.S. person. A Reporting Model 2 FFI files consistent with the requirements of a PFFI unless otherwise indicated. A Sponsoring Entity of a Sponsored FFI files under the requirements of a PFFI. A RDCFFI files under the requirements of a PFFI with respect to an account it is required to report as a condition of its deemed-compliant status. A trustee of a Trustee-Documented Trust files under the requirements of a PFFI. A Sponsoring Entity of a Sponsored Direct Reporting NFFE files under the requirements of a Direct Reporting NFFE. A related entity or branch described in an applicable Model 2 IGA, to the extent it is permitted to report, files under the requirements of a PFFI unless otherwise indicated. Entities filing consistent with a PFFI should substitute their chapter 4 status for PFFI where that term is used in the instructions, except as otherwise noted.

Amount and character of payments.

The amount and character of payments made with respect to an account may be determined under the same principles that the filer uses to report information on resident account holders to its domestic tax authority. Thus, the amount and character of items of income required to be reported need not be determined in accordance with U.S. federal tax principles. If any type of payment is not reported to domestic tax authorities, such amounts may be determined in the same manner as used for reporting to the account holder. Otherwise, reporting must either be in accordance with U.S. federal tax principles, or with any reasonable method consistent with the accounting principles applied by the PFFI. IRS consent is required to change such method, except that a change to rely on U.S. federal income tax principles is automatically permitted. See Regulations section 1.1471-4(d)(4)(iv)(E).

Currency translation.

Account balance or value, and any reportable payment, may be reported in U.S. dollars or in the currency in which the account or payment is denominated. In the case of an account, or payments denominated in multiple currencies, the filer may elect to report the account balance or value, or payments, in a currency in which the account or payments are denominated and is required to identify the currency, including the applicable currency code, in which the account is reported. See Regulations section 1.1471-4(d)(4)(iv)(B) and (F). If an account balance or payment is reported in U.S. dollars, the filer must calculate the amount in the manner described in Regulations section 1.1471-5(b)(4).

Rounding off to whole currency amounts.

You may round fractional currency amounts up (or down) to the closest non-fractional (whole) currency amount. If the fractional currency amount is equal to or greater than half the value of the basic currency unit, round up to the next whole currency amount. If the fractional currency amount is less than half the value of the basic currency unit, round down to the next whole currency amount. If you choose to round currency amounts, you must round all currency amounts reported.

The following illustrates the application of this rule to U.S. dollar amounts. To round off amounts to the nearest whole dollar, drop amounts under 50 cents and increase amounts from 50 to 99 cents to the next dollar. For example, $1.39 becomes $1 and $2.50 becomes $3. If you have to add two or more amounts to figure the amount to enter on a line, include cents (your fractional currency amount) when adding and only round off the total.

Correcting a previously filed Form 8966: Corrected, Amended, and Voided Reports.

If you are filing Form 8966 to correct or amend a previously filed Form 8966, submit the corrected information on the Form 8966 applicable to the year of the initial reporting as follows.

Corrected report.

If you are filing Form 8966 to correct information submitted to the IRS in a previously filed Form 8966 in response to an IRS notification, complete Form 8966 containing the corrected information as if it were the original Form 8966 for the year in question and check the box “Corrected report.” You do not need to include a copy of the originally filed Form 8966 marked “Voided report” with the corrected Form 8966.

If the Form 8966 that you are correcting was filed electronically with the IRS, then the corrected Form 8966 must also be filed electronically with the IRS. If the Form 8966 that you are correcting 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.

Amended report.

If you are filing Form 8966 to correct a previously filed Form 8966 and you have not been contacted by the IRS, complete Form 8966 containing the corrected information as if it were the original Form 8966 and check the box “Amended report.” A copy of the Form 8966 as originally filed with the IRS, updated by checking the “Voided report” box, must be filed with the amended Form 8966.

If the Form 8966 that you are amending was filed electronically with the IRS, then the amended Form 8966 and accompanying voided Form 8966 must be filed electronically with the IRS. If the Form 8966 that you are amending was filed in paper format with the IRS, then the amended Form 8966 and accompanying voided Form 8966 must be filed in paper format with the IRS. Failure to follow this rule will result in your amended Form 8966 not being processed by the IRS.

Voided report.

If you are filing an amended report, also file a copy of the Form 8966 as originally filed with the IRS, updated by checking the “Voided report” box.

No accounts to report.

A Direct Reporting NFFE or a Sponsoring Entity reporting on behalf of a Sponsored Direct Reporting NFFE that has no substantial U.S. owners to report during the calendar year should check this box and complete Part I only. This box is optional for filers other than Direct Reporting NFFEs and Sponsoring Entities filing on behalf of a Sponsored Direct Reporting NFFE.

Identifier.

Filers submitting paper Forms 8966 must assign a unique identifying number to each Form 8966 they file. The identifying number must be numeric (for example, 001) and must be exactly three digits. Enter the three-digit identifying number in the box for “Identifier” at the top of the form.

If you are filing a paper Form 8966 that is an amended, corrected, or voided report, you must include the unique identifying number that you assigned to the original form that is being amended, corrected, or voided. For example, to amend a form that had an identifying number of 002, the amended form should also have the identifying number 002. In addition, the identifying number will be used by the IRS to identify the form in any correspondence with the filer.

The identifying number must be unique to each original Form 8966 filed for the current year. The identifying number can be reused on a new original form in a subsequent year.

Part I—Identification of Filer

Use Part I to provide identifying information about the Form 8966 filer. All filers must complete lines 1a through 3c. Filers provide information on lines 4 through 10 as required by the specific instructions for those lines.

Part II—Account Holder or Payee Information

See the chart at Specific Instructions and Special instructions for filers not specifically listed in chart, earlier, before you begin this part to determine whether you are required to complete Part II.

Jointly held accounts. If you are reporting a jointly held account in Part II, you must report each account holder that is a specified U.S. person on a separate Form 8966.

Part III—Owner Information (File a Separate Report for Each U.S. Owner That Is a Specified U.S. Person)

See the chart at Specific Instructions and Special instructions for filers not specifically listed in chart, earlier, before you begin this part to determine whether you are required to complete Part III.

Use Part III to report information about substantial U.S. owners of a passive NFFE, substantial U.S. owners of a Direct Reporting NFFE, substantial U.S. owners of a Sponsored Direct Reporting NFFE, and specified U.S. persons owning certain equity or debt interests in an ODFFI identified in Part II, line 1a. Complete lines 1 through 4 to report U.S. owner information as follows.

Part IV—Financial Information

See the chart at Specific Instructions and Special instructions for filers not specifically listed in chart, earlier, before you begin this part to determine whether you are required to complete Part IV.

Use Part IV to provide financial information about:

PFFI Filers

Enter the following information on lines 1 through 4d for each account required to be reported by a PFFI and held by a specified U.S. person, a passive NFFE with respect to its substantial U.S. owners, or an ODFFI with respect to certain equity or debt interests held by more than one specified U.S. person.

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 on lines 4a through 4d. See Regulations section 1.1471-4(d)(4)(iv)(D).

Withholding Agents

A withholding agent that is not an FFI should enter the following information on lines 1 through 4d in connection with withholdable payments made to:

Direct Reporting NFFEs and Sponsored Direct Reporting NFFEs

If you are a Direct Reporting NFFE or a Sponsoring Entity filing Form 8966 on behalf of a Sponsored Direct Reporting NFFE, complete lines 1 through 4d as follows.

Part V—Pooled Reporting Type

See the chart at Specific Instructions and Special instructions for filers not specifically listed in chart, earlier, before you begin this part to determine whether you are required to complete Part V.

If you are a PFFI, use Part V to report information about the accounts held by recalcitrant account holders (or, for a Reporting Model 2 FFI, non-consenting U.S. accounts) on a pooled basis. If you are required to report more than one type of pooled reporting account, file a separate Form 8966 for each type.

Direct Reporting NFFEs and Sponsored Direct Reporting NFFEs. Do not complete Part V.

If you are a Reporting Model 2 FFI reporting a preexisting account that is a non-consenting U.S. account, use the pooled reporting category for recalcitrant account holders that are U.S. persons or recalcitrant account holders with U.S. indicia (if the Reporting Model 2 FFI treats the account as a U.S. account based on U.S. indicia as permitted under Annex I of the Model 2 IGA). If you are a Reporting Model 2 FFI reporting a new individual account that has a change in circumstances that causes you to know or have reason to know that the original self-certification is incorrect or unreliable and you are unable to obtain a valid self-certification establishing whether the account holder is a U.S. citizen or resident, use the pooled reporting category for recalcitrant account holders with U.S. indicia.

Paperwork Reduction Act Notice.

The IRS could not download the transmission with the IDES file ID, transmission ID and timestamp. Even though you successfully uploaded the transmission, it could not be downloaded before the seven day IDES retention period expired.

The IRS automatically downloads transmissions from IDES after receiving an alert from IDES that a transmission is available for download. A system failure or outage on either side of the IRS-IDES connection led to the failure to download.

You will need to upload the transmission referenced by the listed IDES Sender’s File ID and IDES Transmission ID in the error notification again. Please ensure that the IRS encryption key you used for the initial transmission has not changed. If it has, please re-encrypt the plain text version of the file you are sending with the new IRS key, and upload this new encrypted transmission to IDES. The IRS will receive notification when the transmission is available and will download it at that time. The IRS will send another notification to you through IDES once your file has been downloaded and processed further.

IDES automatically deletes transmissions that are not downloaded within seven days of upload. Additionally, once the download of a transmission is initiated by IRS, IDES will automatically delete the transmission in 24 hours. As a result of one of these automated deletions, your transmission is no longer available on IDES. You must upload the transmission to IDES again to satisfy FATCA requirements. Please refer to the IDES User GuidePDF, available on the IRS IDES Home, if you have any questions on how to prepare and upload transmissions to IDES. The IRS will be notified by IDES when your transmission is available, and will download it at that time.

The IRS was not able to process your file therefore the records within the file could not be processed. Once the IRS has successfully downloaded your transmission from IDES, the file will be processed and you will be notified of the results, including whether the file was successfully processed or if any additional errors were identified.

The IRS could not decrypt the file with the IDES file ID, transmission ID and timestamp after downloading it from IDES. There are three situations that may have occurred:
a) the AES key provided with the file was not the same as the AES key used to encrypt the payload
b) the AES key used to encrypt is of the wrong type/wrong size, or it is missing completely
c) the public IRS key used to encrypt the AES key was not valid
d) the payload and/or encrypted AES key file was changed or modified after encryption

For security reasons the IRS does not disclose which situation caused the decryption failure.

First, make sure you have the valid IRS public encryption key on your system, downloaded from IDES. Next, please encrypt the digitally-signed and compressed payload of the referenced file with a new AES key and then encrypt the new AES key with the valid IRS public key. Insert the re-encrypted payload and AES key files and a new XML header in an archive to create the IDES transmission. Finally, upload the transmission to IDES following all additional procedures (see IDES User GuidePDF, available on the IRS IDES Home) for transmission preparation and upload. The IRS will send another notification to you through IDES once your file has been downloaded and processed further.

Please follow the procedures in the IDES User GuidePDF, available on the IRS IDES Home, and your local encryption software to generate a unique, one-time use AES-256 key. You should be using this unique, one-time use AES-256 key to encrypt your payload and the valid IRS public key available on IDES to encrypt the AES key.

The valid IRS key is available on IDES. Please visit International Data Exchange Service for additional information and instructions on how to find and download the IRS public key for encrypting the AES key for transmission.

Please see the IDES User GuidePDF, available on the IRS IDES Home, for additional information and instructions on how to find and download the IRS public key for encrypting the AES key for transmission to the IRS. Also, please consult the documentation for your encryption software application for assistance in importing the IRS public key into your system after downloading.

The IRS could not decrypt the referenced file because the size of AES key file was incorrect. The IRS expects a 48 byte AES key file, consisting of a 32 byte (256 bit) key and 16 byte (128 bit) initialization vector combined in a 48 byte encrypted file. Please do not submit a request to correct, amend or void any of the records in this file until you receive a notification that this file has been received as valid. For more information on this notification, including the classification of a failed file decryption under an intergovernmental agreement (IGA), please see: IRS FATCA ICMM Report Notifications Page. For more information on formatting the AES key file, please consult the IDES User GuidePDF.

Added: 01-17-17

This notification indicates an issue specifically with the AES key file size. You may not be using the CBC cipher, required as of July 11, 2016 or the AES key file size may be incorrect for another reason.

Added: 01-17-17

Please follow the procedures in the IDES User Guide, available on the IRS IDES Homepage, and your local encryption software to generate a unique, one-time use AES-256 key with CBC ciphering. You should be using this unique, one-time use AES-256 key to encrypt your payload and the valid IRS public key available on IDES to encrypt the AES key. Ensure that your 16-byte initialization vector is included with your AES key in the encrypted key file.

Added: 01-17-17

Please refer to the IDES User Guide, available on the IRS IDES Homepage, and your local encryption software for specific instructions on using the AES-256-CBC encryption process.

Added: 01-17-17

The IRS could not decompress the file with the IDES file ID, transmission ID and timestamp after download from IDES. This failure occurred either because the file was compressed using an unsupported compression tool/algorithm, one or more files in the transmission are missing compression (not zipped), or because the file became corrupted after compression but before the AES encryption step.

Please recompress the digitally signed XML file using a supported compression tool, and create a new IDES transmission with this file, following all procedures (see the IDES User GuidePDF, available on the IRS IDES Home) for IDES transmission preparation and upload. The IRS will send another notification to you through IDES once your file has been downloaded and processed further.

The IRS could not validate the digital signature on the payload file with the IDES file ID, transmission ID and timestamp, with your organization’s valid public key on IDES.

Please re-sign the file using the procedures provided in the IDES User GuidePDF, available on the IRS IDES Home, and your local encryption software package and recreate and upload the transmission to IDES following all procedures (see the IDES User Guide, available on the IRS IDES Home) for transmission preparation and upload. The IRS will send another notification to you through IDES once your file has been downloaded and processed further.

Please follow the procedures for your local encryption software and for IDES. See the IDES User GuidePDF, available on the IRS IDES Home, and your local encryption software for instructions on how to apply the digital signature.

The IRS detected one or more security threats embedded in the decrypted version of the payload and/or Sender Metadata files. The IRS cannot accept files with embedded security threats

For security reasons the IRS does not disclose specific threats identified on electronic communications received from third parties, or what is used to identify these threats. However, these threats can include items such as:

• hyperlinks embedded within received files
• JavaScript components
• executable files (e.g., .exe files)
• compressed archive files
• prohibited characters (Apostrophe (‘), Double Quote («)

These items should not be part of any submitted file.

Note that the Apostrophe (‘) and Double Quote («) characters are prohibited by IRS as they could pose a security threat. (For a full list of character restrictions, see FATCA XML Schema Best Practices for Form 8966). As these characters would not be detected by an antivirus product, you will need to take other measure to ensure these characters are not present in any of your files.

Please remove all prohibited characters from the payload and Sender Metadata files, then rebuild the full transmission for this payload file by following all procedures (see the IDES User GuidePDF, available on the IRS IDES Home) and scanning for viruses and other security threats with up-to-date antivirus software at each step in the process (digital signature, compression, encryption of the payload and AES key files, creation of the IDES metadata file, creation of the full transmission files) and upload the full transmission to IDES. The IRS will send another notification to you through IDES once your file has been downloaded and processed further.

Generally, any up-to-date and widely accepted antivirus software product should be capable of finding any other threat that the IRS detected. The IRS uses such products for virus and threat detection and removal. However, the IRS does not recommend the use of any particular product for this purpose. Prohibited characters will not be detected by an antivirus product; you will need to take other measures (e.g., a text editor) to ensure these characters are not present in any of your files.

It is the sender’s responsibility to ensure all files are virus and threat free and comply with all IRS requirements and restrictions. Please contact your local IT support staff for assistance with this step, or consult the IDES User Guide and documentation provided by your antivirus software provider.

The IRS detected one or more computer viruses embedded in the decrypted version of the file. The IRS cannot accept a file with viruses present.

For security reasons the IRS does not disclose specific viruses identified on electronic communications received from third parties, or what is used to identify viruses. However, the viruses the IRS detects are typically found by up-to-date commercial anti-virus products.

Please rebuild the full transmission for this payload file by following all procedures (see the IDES User GuidePDF, available on the IRS IDES Home) and scanning for viruses and other security threats with up-to-date antivirus software at each step in the process (digital signature, compression, encryption of the payload and AES key files, creation of the IDES metadata file, creation of the full transmission files), then upload the full transmission to IDES. The IRS will send another notification to you through IDES once your file has been downloaded and processed further.

Generally, any up-to-date and widely accepted antivirus software product should be capable of finding the virus that the IRS detected. The IRS uses such products for virus and threat detection and removal. However, the IRS does not recommend the use of a particular product for this purpose.

It is the sender’s responsibility to provide clean files, and to ensure all files are virus and threat free. Please contact your local IT support staff for assistance with this step, or consult the documentation provided by your antivirus software provider.

The referenced file has one or more XML schema validation errors.

Use of the ampersand (&) and less than (<) symbols are prohibited as they are not allowed by XML syntax rules and will cause the transmission to be rejected with a failed schema error notification. These symbols must be replaced with entity references.

Substituting any ampersand symbols with «&amp;» and less than symbols with «&lt;» in XML files will prevent the generation of the error notification.

The IRS is currently mandating that users do not use default namespaces, but use namespace prefixes for all elements. This guidance is temporary and the restriction will be lifted in the coming weeks.

Please verify the presence of prefixes for all elements in the referenced file, then revalidate the referenced file against the current version of the FATCA XML Schema (IRS Publication 5124 available at FATCA XML Schema) to identify and resolve the specific validation issue. Use this inspected file to recreate an IDES transmission and upload to IDES following all procedures (see the IDES User GuidePDF, available on the IRS IDES Home) for transmission preparation and upload. The IRS will send another notification to you through IDES once your file has been downloaded and processed further.

The MessageRefId schema field in the referenced file consists of one or more blank characters or exceeds 200 characters in length. This field should be a unique identifier for a report file and is required to be at least one, but not more than 200, alphanumeric characters and cannot be all blank characters.

Updated: 03-03-16

The FATCA XML User Guide (IRS Publication 5124 available at FATCA XML Schema) states that the MessageRefId should be a unique identifying number (created by the sender) that identifies the particular message being sent. Although a MessageRefId consisting of all blanks is valid against the schema, the IRS does not consider a blank MessageRefId to be unique. Furthermore, the IRS has limited the MessageRefId and DocRefId fields to 200 characters. The IRS requires non-blank MessageRefIds and DocRefIds that are no more than 200 characters in length in order to be able to accept your file.

Updated: 04-11-17

Please correct the file by including a unique, valid alphanumeric character string in the MessageRefId field (see the FATCA XML User Guide, IRS Publication 5124 available at FATCA XML Schema) that does not consist of all blanks and that is no more than 200 characters in length. Use this file to recreate an IDES transmission and upload to IDES following all procedures (see the IDES User GuidePDF, available on the IRS IDES Home) for transmission preparation and upload. The IRS will send another notification to you through IDES once your file has been downloaded and processed further.

Updated: 04-11-17

The MessageRefId schema field in the submitted file is duplicative of another file you have submitted. This field should be a unique identifying number for a report file and is required to be a string of at least one alphanumeric character.

Updated: 03-03-16

While your file is in the valid XML format, comparison of MessageRefIds takes place outside of XML validation. FATCA XML User Guide (IRS Publication 5124 available at FATCA XML Schema) states that the MessageRefId should be a unique identifying alphanumeric value (created by the sender) that identifies the particular message being sent. The IRS cannot accept more than one file from the same sender with the same MessageRefId.

Updated: 04-11-17

Please correct the file by including a unique, valid alphanumeric character string in the MessageRefId field (see the FATCA XML User Guide, IRS Publication 5124 available at FATCA XML Schema) that does not consist of all blanks and does not exceed 200 characters in length. Use this file to recreate an IDES transmission and upload to IDES following all procedures (see the IDES User GuidePDF, available on the IRS IDES Home) for transmission preparation and upload. The IRS will send another notification to you through IDES once your file has been downloaded and processed further.

Updated: 04-11-17

One or more records with DocRefId schema fields in the submitted file consist of one or more blank characters or exceed 200 characters in length. This field should contain the unique identifier of the specific account or pooled report it references and is required to be at least one, but not more than 200, alphanumeric characters, and cannot be all-blank characters.

Updated: 03-24-18

The FATCA XML User Guide (IRS Publication 5124 available at FATCA XML Schema) states that the DocRefId data element should contain the unique identifier of the specific account or pooled report it references. Although a DocRefId consisting of all blanks is valid against the schema, the IRS does not consider a blank DocRefId to be unique. Furthermore, the IRS has limited the MessageRefId and DocRefId fields to 200 characters. The IRS requires non-blank MessageRefIds and DocRefIds that are no more than 200 characters in length in order to be able to accept your file.

Updated: 04-11-17

Please correct the file by including a valid alphanumeric character string in all DocRefId fields per the FATCA XML Schema User Guide (IRS Publication 5124 available at FATCA XML Schema) that does not consist of all blanks and that is no more than 200 characters in length. Use this file to recreate an IDES transmission and upload to IDES following all procedures (see the IDES User GuidePDF, available on the IRS IDES Home) for transmission preparation and upload. The IRS will send another notification to you through IDES once your file has been downloaded and processed further.

Updated: 04-11-17

The IRS has received and successfully completed the first phase of processing your file. At this time, there is no action for you to take with respect to this notification. Individual records in this file will be processed further at a later date, and you will be notified if any errors are encountered and if you need to take any further action.

Updated: 03-24-18

Your certificate posted to IDES was not valid. The IRS cannot download a file from IDES if the transmitter certificate is not valid.

Added: 03-24-18

Please post a valid certificate to IDES. Then re-encrypt the FATCA XML file with a new AES key. Re-package and resubmit the payload file to IDES using the new valid certificate.

Added: 03-24-18

The IRS could not download the referenced file that had been posted to IDES. The file could not be decoded because the encoding mechanism used did not match what was listed in the IDES metadata.

Added: 03-24-18

The file encoding schema supported by the IRS is Base64.

Added: 03-24-18

Ensure the file encoding is valid. Currently the IRS only supports Base 64 file encoding for transmission through IDES. Re-encrypt the payload and repost the file to IDES. The IRS will send another notification to you through IDES after we have downloaded and processed your file further.

Added: 03-24-18

The IRS could not download the referenced file that had been posted to IDES. Your specified file format type and actual file contents were inconsistent.

Added: 03-24-18

The IRS supports 5 file formats:

Added: 03-24-18

Ensure the specified file format type and actual file contents are consistent and repost the file to IDES. Ensure the specified file format is one of the approved types that can be sent to the IRS. Ensure the file type included in the IDES metadata is consistent with the file type of the enclosed notification.

Added: 03-24-18

The IDES alert of a successful upload is information about the transmission of your file. IDES alerts cannot provide information about the receipt and processing of your files by IRS ICMM. The IRS should issue an ICMM Notification for every FATCA Report that is successfully transmitted through IDES letting you know the status of your FATCA Report. You should always receive a Notification within 24 hours, and in most cases within a few minutes, of the IRS ICMM system receiving your file. However, the IRS has identified specific instances during testing where ICMM Notifications are not issued to filers when certain errors are present. In addition, the IRS has identified circumstances in which filers did not download their notifications before the 7 day retention period expired, and these notifications were deleted and are no longer available for download. The IRS is working to address and resolve these issues.

In the meantime, there are a few things you can do to maximize your ability to receive notifications sent to you, and to determine whether a notification has been sent to in response to your file. These are as follow:

• First, make sure that e-mail alerts from IDES are not blocked as SPAM by your own e-mail system. Your e-mail system may have deleted it or may have sent it to you SPAM inbox. If you have been sent an alert that a notification is present, but the alert email is blocked you may never be aware of the notification’s availability for download.
• Second, make sure your IDES User Profile is configured to allow IDES to send you e-mails, including alerts regarding notifications. There is a box that can be set to either send or not send you an e-mail notification. If you would like to receive and e-mail notification make sure it is set to send e-mail notification.
• Third, check your IDES inbox over the next 24 hours following the upload of your file to IDES to determine whether there is a Notification waiting for download. Even if you have not received an e-mail Alert, the Notification could still be in your folder ready for download. After seven days the notification will automatically be deleted from the system.

If you have checked your folder in IDES and there is no Notification present after 48 hours or longer since your file was uploaded successfully, an error types which is suppressing a notification from being sent may have been detected on your file. A few things to check that may help include the following:

• Making sure the digital certificate you are using for signature and encryption for FATCA data has not expired or been revoked by your Certificate Authority.
• Also, you should double check the Metadata XML file that is part of your data packet, to ensure all of the mandatory data elements are correct. In particular, please make sure that FATCAEntCommunicationTypeCd is set to “RPT”, and that the TaxYear is set to “2014.”
• Make sure all of the entries are correct. Did you indicate you were submitting a FATCA Report? Did you select the correct tax reporting year (it should be 2014)? Etc.

Once you’ve checked these items, you should resubmit your file.

It is possible that you submitted your FATCA Report production files to the FATCA Report test environment instead of to the FATCA Report production environment. Any production files that are submitted to the test environment will not be processed and will need to be re-submitted to the production environment. Please do not submit production files to the test environment. In addition, please do not submit test files to the production environment.

Form 8809-IPDF needs to be submitted. Please follow the instructions for that form.

Updated: 03-24-18

Since this data is considered to be test data, and the IRS discourages submission of test data in its production environments, no further action should be taken with respect to this record. Please do not attempt to void, correct, or amend this record with additional test data. However, if you determine that the record is a valid record please resubmit with the proper DocTypeIndic value through IDES to the ICMM production environment.

Added: 09-14-15

This record does not need to be voided or otherwise modified in the test environment. If the records are valid production submissions, please submit through IDES to the ICMM production environment.

Added: 09-14-15

The IRS has received and successfully completed processing of your file. At this time, one or more record-level errors have been identified in your file and require correction. You will need to correct all identified record-level errors and resubmit the file.

Added: 09-14-15

It is possible for a FATCA XML file to validate against the FATCA Intergovernmental Schema while not complying with FATCA reporting requirements. The FATCA XML V1.1 User Guide (IRS Publication 5124) details rules for FATCA data elements needed to validate against the FATCA schema, as well as mandatory data elements and values which extend beyond validation but are needed to satisfy reporting requirements.

Added: 09-14-15

The record indicated by the DocRefId value included with the error descriptions in the notifications is the record that must be corrected and resubmitted.

Updated: 03-03-16

Only the record with the corrected data needs to be resubmitted. However, since the record must be transmitted in a valid FATCA Report file, the full file must have sufficient data from the original file to pass XML validation and other checks, as defined in IRS Publication 5124PDF (pdf 1.59MB), including MessageSpec and Reporting FI data elements. In addition, the following changes from the original file are necessary:

• The DocTypeIndCd value should be “FATCA2” for corrected data
• The MessageRefId and DocRefId values for the file being corrected must be provided in the CorrMessageRefId and CorrDocRefId fields for the submitted file.

Updated: 03-03-16

The “TIN not in IRS specified format” error is generated when a non-GIIN value for a TIN data element is not in a valid format for a U.S. TIN. A value for a TIN data element must be either in a GIIN format or in one of the following formats for a U.S. TIN to be considered valid when filed:

• Nine consecutive numerical digits without hyphens or other separators (e.g., “123456789”)
• Nine numerical digits with two hyphens, one hyphen entered after the third numeric digit and a second hyphen entered after the fifth numeric digit (e.g., “123-45-6789”)
• Nine numerical digits with a hyphen entered after the second digit (e.g., “12-3456789”)

If a filer has confirmed that the Account Holder is not required to have a US TIN in the agreed upon format then the filer does not need to re-file to correct this specific error. Any other errors included in the notification must be corrected and the filer should re-submit a corrected file for those errors only. The Account Holder TIN must be provided and cannot be blank characters in the TIN data sub-element.

Updated: 03-24-18

Updated: 03-24-18

Updated: 03-24-18

Though the nine digits in the US TIN you have provided are the correct TIN for the person or entity being documented, you may have used an incorrect format for the TIN. Please see Question 7 above for the correct formats to be used for US TINs in FATCA reporting.

Updated: 03-24-18

Each record will be associated with a report-level DocRefID (Account, Pooled or Nil Report DocRefID) as well as one or more organization-level DocRefIDs (ReportingFI DocRefID, Intermediary DocRefID, and/or Sponsor DocRefID). If any of these DocRefIDs do not follow the DocRefID formatting requirements (see FATCA XML Schemas Best Practices for Form 8966 DocRefId), you will receive an “Invalid DocRefID” error. All DocRefIDs in the record should be checked to ensure they follow the formatting requirements. Please note that DocRefIDs must not include any non-alphanumeric characters, excluding periods and dashes. Prohibited non-alphanumeric characters include but are not limited to_, @, +, &, ! and *.

Updated: 04-18-18

The record-level error codes 8001 (Pooled Report Error), and 8007 (Account Report Error), and 8013 (Nil Report Error) indicate errors found with specific data elements in the record that must be corrected through a resubmission. In these cases the notifications will contain a “FieldErrorGrp” for each field-level error, with a description of the error (“FieldErrorTxt”) and the XML path for the data element (“FieldNm”) in error. Field-level errors are provided alphabetically by descriptionin the order in which they appear in the FATCA Schema in Figure 4-2 ICMM Field-level Errors for Electronic FATCA XML Reports PDF(pdf 147KB). Each field-level error must be corrected to resolve the record-level error.

Updated: 03-24-18

The procedures to correct, amend, or void specific records are below:
When a filer resubmits corrected record data in response to a “valid file with errors” notification from the IRS for an electronically submitted file, the following changes must be made within the “DocSpec” element for the corrected record:

• The “DocTypeIndic” element must be “FATCA2” to denote a corrected record
• The “CorrMessageRefId” element must be set equal to the “MessageRefId” for the original file in which the record being corrected was contained
• The “CorrDocRefId” element must be set equal to the “DocRefId” for the original record being corrected
• All fields identified in the error listing for the record in the notification must be corrected.
  In addition, all other record elements from the original record submission must be included, and the resubmitted file with the corrected record data must represent a valid FATCA XML file.

Amended records in which a filer chooses to amend (change or edit) previously submitted records are prepared similarly to corrected records. To submit an amended record, the filer must make the following changes within the resubmitted record:

• The “DocTypeIndic” element must be “FATCA4” to denote an amended record
• The “CorrMessageRefId” element must be set equal to the “MessageRefId” for the original file in which the record being amended was contained
• The “CorrDocRefId” element must be set equal to the “DocRefId” for the original record being amended
• All fields in the amended record must have values that the filer wishes to report to the IRS for the relevant account or pooled report.

Voided records in which a filer wishes to delete a previously submitted record are submitted in the following manner:

• The “DocTypeIndic” element must be “FATCA3” to denote a voided record
• The “CorrMessageRefId” element must be set equal to the “MessageRefId” for the original file in which the record being voided was contained
• The “CorrDocRefId” element must be set equal to the “DocRefId” for the original record being voided
• All fields in the voided record must have the same values as the original record being voided (deleted).

Updated: 03-03-16

The IRS agrees that this scenario is not an error by the filer. The ICMM system will misinterpret a MonAmnt_Type element with additional trailing zeroes after the second position to the right of the decimal point in the element; as a result the filer will receive a Valid File Notification (with Record-Level Errors) or NVF Notification because of the additional trailing zeroes. The MonAmnt_Type data with additional trailing zeroes are valid according to the FATCA XML Schema v2.0.

As of March, 24, 2018 this error condition is no longer being reported in NVF Notifications. For notifications received prior to that date, filers that receive an error for that reason (schema-valid MonAmnt_Type value with additional trailing zeroes) may ignore that error in the NVF Notification; those conditions do not require correction. However, please correct all other documented field-level errors on any other elements in the NVF notification.

Updated: 03-24-18

The IRS has received your Form 8966 and has identified errors in your document that require correction. You will need to correct all identified record-level errors and resubmit the Form. Please mark the new form as “Corrected” by checking the box at the top of the first page, and send to the address indicated in the instructions.

Updated: 03-24-18

The record error code on the paper notification is one of 4 record-level error codes provided in Table 4-3 which also contains descriptions and remedial actions for each error type.

Added: 09-14-15

These values provide the Part and Line reference, and standard description for each error found on your submitted Form 8966. Field-level errors are provided alphabetically by description in Figure 4-4 ICMM Field-level Errors for Paper ReportsPDF (pdf 101KB). Each field-level error must be corrected to resolve the overall record-level error.

Added: 09-14-15

Corrected Forms 8966 must have complete entries for all required fields. Please resubmit all data, including corrected data, from your original Form 8966 on your corrected form.

Added: 01-17-17

The IRS has received your Form 8966 submitted as a pool report and we have identified errors and inconsistencies in your document that require correction. You will need to correct all identified record level errors and resubmit the Form. Please mark the new form as “Corrected” by checking the box at the top of the first page, and send to the address indicated in the instructions

Added: 01-17-17

Corrected Forms 8966 for pool reporting must have complete entries for all required fields. Please resubmit all data, including corrected data, from your original Form 8966 on your corrected form.

Added: 01-17-17

The IRS has received your Form 8966 and has identified errors in your document that require correction. You will need to correct all identified record-level errors and resubmit the Form. Please mark the new form as “Corrected” by checking the box at the top of the first page, and send to the address indicated in the instructions.

Added: 01-17-17

All submitted Forms 8966, whether original, corrected, amended, or void forms, must have complete entries for all required fields. All appropriate fields should be populated with either data from the originally filed form or changes to reflect the corrections to the errors or amendments.

Added: 01-17-17

To resubmit a Form 8966, paper filers should submit a new Form 8966 with all appropriate fields populated with either data from the originally filed form or changes to reflect corrections or amendments:

• To correct an account or pooled report, in response to error notifications received from the IRS, make corrections to the fields in the part and line numbers, specified in the error notification, and check the “Corrected Form” box
• To amend or change an account or pooled report, submitted on a previously filed Form 8966, change the fields that need edits and check the “Amended Form” box
• To void or delete a previously filed Form 8966, check the “Voided form” box.

In all cases, fields from the original submission, that are not being corrected or edited, must be populated with the same data as the original filing (note: voided forms must include the same data as the original form being voided).

The table in, Figure 4 3 ICMM Record-level Processing Error Codes (paper filing)PDF (pdf 10KB), provides the codes, descriptions, and remedial actions needed for record — level errors ICMM will detect in records on paper Forms 8966. Four digit record-level error codes are always provided when record-level errors are present. Unlike the electronic case, in which a single file can contain multiple account reports and pooled reports as records, a single Form 8966 is considered to be a single, standalone record. A filer can only document a single account or pooled report on each paper Form 8966, and cannot file both types of reports on a single form. Also, unlike the electronic case, there is no way to identify a specific Form 8966 submitted by a filer; that is, there is no analog on the paper filing side to the MessageRefId and DocRefId data elements in the FATCA XML schema which can be used to exactly identify prior paper records. The IRS will need to analyze the filing history from a given filer to determine if corrections to errors on specific paper account and pooled reports have been provided. Because there is no way to directly correlate corrections to original submissions with errors, the record-level errors in electronic filing centered on corrected or amended reports with no matching originals have no paper counterparts, so the range of paper record-level errors is smaller.

Updated: 03-03-16

The “TIN not in IRS specified format” error is generated when a non-GIIN value for a TIN data element is not in a valid format for a U.S. TIN. A value for a TIN data element must be either in a GIIN format or in one of the following formats for a U.S. TIN to be considered valid when filed:

• Nine consecutive numerical digits without hyphens or other separators (e.g., “123456789”)
• Nine numerical digits with two hyphens, one hyphen entered after the third numeric digit and a second hyphen entered after the fifth numeric digit (e.g., “123-45-6789”)
• Nine numerical digits with a hyphen entered after the second digit (e.g., “12-3456789”)

If a filer has confirmed that the Account Holder is not required to have a US TIN in the agreed upon format then the filer does not need to re-file to correct this specific error. Any other errors included in the notification must be corrected and the filer should re-submit a corrected file for those errors only. The Account Holder TIN must be provided and cannot be blank characters in the TIN data sub-element.

Updated: 03-24-18

The “TIN not in IRS specified format, contains only one character repeated» error is generated when a US TIN is in one of the valid formats specified in Q7 above, but consists of nine digits that are all the same (ex. 555555555, 111-11-1111, 33-333333) or when a non-US TIN, which does not have to conform to the formats specified in Q7, consists of digits or characters that are all the same (ex. 9999999, XXXXXXX). A valid TIN will not consist only of one repeated character, regardless of country of origin.

If a filer has confirmed that the Account Holder is not required to have a US TIN in the agreed upon format then the filer does not need to re-file to correct this specific error. Any other errors included in the notification must be corrected and the filer should re-submit a corrected file for those errors only. The Account Holder TIN must be provided and cannot be blank characters in the TIN data sub-element.

Updated: 03-24-18

The “TIN not in IRS specified format, contains non-numeric characters» error is generated when a US TIN is in one of the valid formats specified in Q1 above, but includes any characters other than numeric digits (1-9) or «-» in the positions specified in Q1. A valid US TIN will not include any non-numeric characters.

Though the nine digits in the US TIN you have provided are the correct TIN for the person or entity being documented, you may have used an incorrect format for the TIN. Please see Question 1 above for the correct formats to be used for US TINs in FATCA reporting.

Updated: 03-24-18