US FATCA Validation

Introduction

Following successful transmission of 2014 data from Guernsey to the IRS under the US IGA agreement, the IRS sent a notification to the Director of Income Tax in Guernsey detailing record-level errors. These errors relate to additional validation requirements which were published shortly before the IGA reporting date of 30 September 2015.

To clarify, no file level errors arose, as the report submitted to the IRS was mandated to validate against the IRS FATCA schema.

The IRS's additional validation requirements for record-level errors are detailed in Figure 4-2 of the International Compliance Management Model (ICMM) Notifications User Guide.

In order to prevent recurrences of such errors, new validation rules have been implemented in IGOR which are applied to all US FATCA XML returns. IGOR applies these rules at the time of receiving a return, and will entirely reject a return which breaks any of these rules.

The goal of the IGOR validation rules is that if a return is received by IGOR, then it will be entirely accepted by the IRS without any record-level errors being returned. Therefore the validation rules are designed to be as strict as those being used by the IRS. This means that, for FIs operating in multiple jurisdictions, ensuring that XML passes IGOR's validation rules serves to provide some quality assurance that issues will not arise when reporting in other jurisdictions.

In some exceptional cases, it appears that the IRS's implementation of their rules is incomplete. In those cases, the IGOR implementation of the rules may be slightly stricter.

Version history

Validation Errors

"The US TIN must be specified for this element..."

Message

The US TIN must be specified for this element in a TIN element with the issuedBy attribute absent or set to 'US'.

Affected elements

Explanation

This error occurs if no TIN is specified for one of the above elements.

See also "The TIN is not in the correct format/must not be empty" for further information on TIN formats.

Example

<ftc:AccountHolder>
  <ftc:Individual>
    <sfa:ResCountryCode>GG</sfa:ResCountryCode>
    <sfa:Name>...

The TIN is missing. The XML required by the IRS is:

<ftc:AccountHolder>
  <ftc:Individual>
    <sfa:ResCountryCode>GG</sfa:ResCountryCode>
    <sfa:TIN issuedBy='US'>123456789</sfa:TIN>
    <sfa:Name>...

"The US GIIN or EIN must be specified for an Intermediary..."

Message

The US GIIN or EIN must be specified for an Intermediary in a TIN element with the issuedBy attribute absent or set to 'US'. If the US TIN is not known, specify a TIN of nine consecutive zeroes ('000000000').

Affected elements

Explanation

This error occurs if no TIN is specified for an Intermediary.

Note that the IRS's documentation suggests that the TIN for an Intermediary should be a valid EIN or GIIN. However, IGOR does not presently validate the format of the Intermediary TIN because the IRS has not given clear guidance about what formats are acceptable, or how it is determined whether an EIN or GIIN should be provided.

Example

<ftc:Intermediary>
  <sfa:ResCountryCode>GG</sfa:ResCountryCode>
  <sfa:Name>...

The TIN element is missing. The XML required by the IRS is:

<ftc:Intermediary>
  <sfa:ResCountryCode>GG</sfa:ResCountryCode>
  <sfa:TIN issuedBy='US'>000000000</sfa:TIN>
  <sfa:Name>...

The real GIIN or EIN should be provided if known.

"The first TIN must have the issuedBy attribute absent or set to 'US'"

Affected elements

Explanation

The IRS's validation process actually ignores the issuedBy attribute of the TINs, and instead simply validates that the first TIN is in the format of a valid US TIN. In order to ensure that the TIN which the IRS validates passes this check, IGOR validates that the first TIN is a US TIN.

Example

<ftc:AccountHolder>
  <ftc:Individual>
    <sfa:ResCountryCode>US</sfa:ResCountryCode>
    <sfa:TIN issuedBy='DE'>98765432</sfa:TIN>
    <sfa:TIN issuedBy='US'>12-3456789</sfa:TIN>
    <sfa:Name>...

The first TIN in this case has issuedBy='DE'. The XML required by the IRS is:

<ftc:AccountHolder>
  <ftc:Individual>
    <sfa:ResCountryCode>US</sfa:ResCountryCode>
    <sfa:TIN issuedBy='US'>12-3456789</sfa:TIN>
    <sfa:TIN issuedBy='DE'>98765432</sfa:TIN>
    <sfa:Name>...

"The TIN is not in the correct format/must not be empty"

Messages

The TIN is not in the correct format. A TIN must be a 9 digit number, or 9 digits with dashes in the form '12-3456789' or '123-45-6789'.

A TIN must not contain any whitespace characters (including leading and trailing spaces).

The TIN must not be empty. If the US TIN is not known, specify a TIN of nine consecutive capital letter 'A's (AAAAAAAAA), or nine 2s, 3s, 4s, 5s or 6s (if applicable - see guidance).

A TIN of nine consecutive zeroes is not permitted for 2017 data onwards. If the US TIN is not known, specify a TIN of nine consecutive capital letter 'A's (AAAAAAAAA), or nine 2s, 3s, 4s, 5s or 6s (if applicable - see guidance).

A TIN of only one character repeated is not permitted.

Affected elements

Explanation

IGOR validates that any TIN in the above elements with issuedBy absent or set to 'US' is not blank and is in one of the formats permitted by the IRS.

Spaces within the TIN field are not permitted (including leading and trailing spaces).

If the US TIN for an account holder is not known:

Aside from for these exceptions, a TIN which consists solely of a single character repeated is not permitted. This rule applies regardless of whether the TIN is US-issued or not.

Example

<ftc:AccountHolder>
  <ftc:Individual>
    <sfa:ResCountryCode>GG</sfa:ResCountryCode>
    <sfa:TIN issuedBy="US">12345678</sfa:TIN>
    <sfa:Name>...

The TIN in this example is invalid as it has only 8 digits. A US TIN must be in the form '123456789', '12-3456789', or '123-45-6789'. The following is valid:

<ftc:AccountHolder>
  <ftc:Individual>
    <sfa:ResCountryCode>GG</sfa:ResCountryCode>
    <sfa:TIN issuedBy="US">123456789</sfa:TIN>
    <sfa:Name>...

"A date of birth is required if the TIN is nine consecutive capital letter 'A's"

Messages

A date of birth is required if the TIN is nine consecutive capital letter 'A's (AAAAAAAAA).

Affected elements

Explanation

For 2017 data onwards, a TIN of nine consecutive capital letter 'A's (AAAAAAAAA) can be used to indicate that the US TIN of an individual is not known. In this case a date of birth is required.

For 2018 data onwards, a TIN of nine consecutive capital letter 'A's (AAAAAAAAA) can be used to indicate that the US TIN of an organisation is not known. No date of birth is required for organisations.

Example

<ftc:AccountHolder>
  <ftc:Individual>
    <sfa:ResCountryCode>GG</sfa:ResCountryCode>
    <sfa:TIN issuedBy="US">AAAAAAAAA</sfa:TIN>
    <sfa:Name>...</sfa:Name>
    <sfa:Address>...</sfa:Address>
  </ftc:Individual>
  ...

Because the TIN is AAAAAAAAA, a date of birth must be specified:

<ftc:AccountHolder>
  <ftc:Individual>
    <sfa:ResCountryCode>GG</sfa:ResCountryCode>
    <sfa:TIN issuedBy="US">AAAAAAAAA</sfa:TIN>
    <sfa:Name>...</sfa:Name>
    <sfa:Address>...</sfa:Address>
    <sfa:BirthInfo>
      <sfa:BirthDate>1976-04-12</sfa:BirthDate>
    </sfa:BirthInfo>
  </ftc:Individual>

"The FirstName/LastName of a Name element must not be empty"

Messages

The FirstName of a Name element must not be empty. If you have no first name information, you can specify 'NFN' (meaning 'No First Name').

The LastName of a Name element must not be empty.

Affected elements

Explanation

The FATCA XSD schema requires the FirstName and LastName elements of a Name to be included, but allows them to be empty. The IRS has sent back validation errors where either of these elements is empty, so they must both be populated.

The use of 'NFN' (No First Name) for individual account holders (and presumably therefore also substantial owners), is suggested on page 6 of the FATCA XML User Guide for situations where the FI has no first name information.

Example

<ftc:SubstantialOwner>
  <sfa:ResCountryCode>GG</sfa:ResCountryCode>
  <sfa:TIN issuedBy="US">123456789</sfa:TIN>
  <sfa:Name>
    <sfa:FirstName></sfa:FirstName>
    <sfa:LastName>Smith</sfa:LastName>
  </sfa:Name>
  ...

Both the FirstName and LastName must be populated. If no FirstName information is available, use 'NFN':

<ftc:SubstantialOwner>
  <sfa:ResCountryCode>GG</sfa:ResCountryCode>
  <sfa:TIN issuedBy="US">123456789</sfa:TIN>
  <sfa:Name>
    <sfa:FirstName>NFN</sfa:FirstName>
    <sfa:LastName>Smith</sfa:LastName>
  </sfa:Name>
  ...

"The Address element must contain a City"

Message

The Address element must contain either an AddressFix element with a populated (non-blank) City element or a populated AddressFree element.

Affected elements

Explanation

If the AddressFix element is being used instead of the AddressFree element (i.e. the AddressFree is missing or blank) then the City must not be empty.

Example

<ftc:AccountHolder>
  <ftc:Individual>
    <sfa:ResCountryCode>US</sfa:ResCountryCode>
    <sfa:TIN issuedBy="US">123456789</sfa:TIN>
    <sfa:Name>
      <sfa:FirstName>John</sfa:FirstName>
      <sfa:LastName>Doe</sfa:LastName>
    </sfa:Name>
    <sfa:Address>
      <sfa:CountryCode>US</sfa:CountryCode>
      <sfa:AddressFix>
        <sfa:Street>1234 Abcd Street</sfa:Street>
        <sfa:PostCode>98765</sfa:PostCode>
        <sfa:City />
        <sfa:CountrySubentity>Wisconsin</sfa:CountrySubentity>
      </sfa:AddressFix>
      <sfa:AddressFree />
    </sfa:Address>
    ...

"The GIIN must be specified for a Sponsor element"

Message

The GIIN must be specified for a Sponsor element, in a TIN element with the issuedBy attribute absent or set to 'US'.

Affected elements

Explanation

The IRS requires the Sponsor's GIIN to be specified in a TIN element.

Example

<ftc:Sponsor>
  <sfa:ResCountryCode>GG</sfa:ResCountryCode>
  <sfa:Name>...

The GIIN is missing. The XML required by the IRS is:

<ftc:Sponsor>
  <sfa:ResCountryCode>GG</sfa:ResCountryCode>
  <sfa:TIN issuedBy='US'>ABC123.12345.SP.831</sfa:TIN>
  <sfa:Name>...

The GIIN used here is illustrative only; the correct GIIN for your Sponsor FI should be used in its place.

"The first TIN listed within a Sponsor element must have the issuedBy attribute absent or set to 'US'"

Affected elements

Explanation

As with Account Holders, the IRS's validation process ignores the issuedBy attribute of the TINs, and instead simply validates that the first TIN of a Sponsor is in the format of a valid GIIN. In order to ensure that the TIN which the IRS validates passes this check, IGOR validates that the first TIN has issuedBy absent or set to 'US'.

Example

<ftc:Sponsor>
  <sfa:ResCountryCode>GG</sfa:ResCountryCode>
  <sfa:TIN issuedBy='GB'>12345 67890</sfa:TIN>
  <sfa:TIN issuedBy='US'>ABC123.12345.SP.831</sfa:TIN>
  <sfa:Name>...

The first TIN in this case has issuedBy='GB'. The XML required by the IRS is:

<ftc:Sponsor>
  <sfa:ResCountryCode>GG</sfa:ResCountryCode>
  <sfa:TIN issuedBy='US'>ABC123.12345.SP.831</sfa:TIN>
  <sfa:TIN issuedBy='GB'>12345 67890</sfa:TIN>
  <sfa:Name>...

"The Sponsor's GIIN is not in the correct format/must not be empty."

Messages

The Sponsor's GIIN is not in the correct format. A GIIN must be a 19-character string in the form ABC123.12345.SP.123, with no leading or trailing spaces.

The Sponsor's GIIN is not in the correct format. A Sponsor GIIN must have the letters 'SP' in the penultimate section.

The Sponsor's GIIN must not be empty.

The Sponsor's GIIN is not in the IRS FATCA Foreign Financial Institution (FFI) List.

Affected elements

Explanation

IGOR validates that any GIIN in a Sponsor element with issuedBy absent or set to 'US' is a GIIN in the format prescribed by the IRS, and is included in the IRS FATCA Foreign Financial Institution (FFI) List.

It must not be empty, and must have 'SP' in the penultimate section (denoting the GIIN type 'Sponsor').

Example

<ftc:Sponsor>
  <sfa:ResCountryCode>GG</sfa:ResCountryCode>
  <sfa:TIN issuedBy='US'>ABC123.1234.SP.831</sfa:TIN>
  <sfa:Name>...

The GIIN in this example is invalid as the second group only contains 4 digits.

<ftc:Sponsor>
  <sfa:ResCountryCode>GG</sfa:ResCountryCode>
  <sfa:TIN issuedBy='US'>ABC123.12345.LE.831</sfa:TIN>
  <sfa:Name>...

The above example is also invalid because the GIIN type (the penultimate group of letters) is 'LE' instead of 'SP'.

The following is valid:

<ftc:Sponsor>
  <sfa:ResCountryCode>GG</sfa:ResCountryCode>
  <sfa:TIN issuedBy='US'>ABC123.12345.SP.831</sfa:TIN>
  <sfa:Name>...

"The Name of a ReportingFI element must not be empty"

Affected element

Explanation

The FATCA XSD schema requires the Name element of a ReportingFI to be included, but allows it to be empty. The IRS has sent back validation errors where this element is empty, so IGOR validates that the Name is populated.

Example

<ftc:ReportingFI>
  <sfa:ResCountryCode>GG</sfa:ResCountryCode>
  <sfa:TIN issuedBy="US">ABC123.12345.SL.831</sfa:TIN>
  <sfa:Name />
  <sfa:Address>...

The Name must be populated. The following is valid:

<ftc:ReportingFI>
  <sfa:ResCountryCode>GG</sfa:ResCountryCode>
  <sfa:TIN issuedBy="US">ABC123.12345.SL.831</sfa:TIN>
  <sfa:Name>ABC Trust Limited</sfa:Name>
  <sfa:Address>...

"A payment amount of zero with more than two factional digits is invalid"

Affected elements

Explanation

The FATCA XSD schema requires payment amounts to have a maximum of two fractional digits, which may be padded to the right with additional zeros. The IRS has, in cases where the payment amount is zero, sent back validation errors where additional zeros are included so IGOR validates that there are no more than two fractional digits where a payment amount is zero.

Example

<ftc:Payment>
  <ftc:Type>FATCA501</ftc:Type>
  <ftc:PaymentAmnt currCode="USD">0.00000000</ftc:PaymentAmnt>
</ftc:Payment>

The additional zeros must not be included. The following is valid:

<ftc:Payment>
  <ftc:Type>FATCA501</ftc:Type>
  <ftc:PaymentAmnt currCode="USD">0.00</ftc:PaymentAmnt>
</ftc:Payment>

"Account holder type FATCA105/FATCA106 may not be used"

Affected elements

Explanation

The account holder types FATCA105 and FATCA106 are not valid for submissions to IGOR. FATCA105 is not applicable in for model 1 IGA reporting, and FATCA106 is for U.S. Government use only.

Example

  </ftc:Organisation>
  <ftc:AcctHolderType>FATCA106</ftc:AcctHolderType>
</ftc:AccountHolder>

The account holder type may not be FATCA106; use one of the other account holder types instead. The following is valid:

  </ftc:Organisation>
  <ftc:AcctHolderType>FATCA101</ftc:AcctHolderType>
</ftc:AccountHolder>

"The Filer Category of the ReportingFI element must be specified"

Affected elements

Example

<ftc:FATCA>
  <ftc:ReportingFI>
    ...
    </sfa:Address>
    <ftc:DocSpec>...</ftc:DocSpec>
  </ftc:ReportingFI>
  <ftc:ReportingGroup>
    <ftc:AccountReport>...

The Filer Category must be specified, or a Sponsor element should be specified which has a Filer Category. The following is valid.

<ftc:FATCA>
  <ftc:ReportingFI>
    ...
    </sfa:Address>
	<ftc:FilerCategory>FATCA601</ftc:FilerCategory>
    <ftc:DocSpec>...</ftc:DocSpec>
  </ftc:ReportingFI>
  <ftc:ReportingGroup>
    <ftc:AccountReport>...

"This Filer Category is not valid for a ReportingFI"

Affected elements

Explanation

Only the following Filer Categories are valid in the ReportingFI element when reporting to IGOR:

FATCA607, 608 and 609 are prohibited for ReportingFIs by the IRS FATCA XML User Guide (but are permitted in the sponsor element), and FATCA604, 606 and 611 are not valid in a model 1 IGA jurisdiction

Example

<ftc:ReportingFI>
  ...
  </sfa:Address>
  <ftc:FilerCategory>FATCA606</ftc:FilerCategory>
  ...

The Filer Category FATCA606 is not valid for a ReportingFI. The following is valid:

<ftc:ReportingFI>
  ...
  </sfa:Address>
  <ftc:FilerCategory>FATCA601</ftc:FilerCategory>
  ...

"The Filer Category of a ReportingFI element must be omitted if there is a Sponsor with a Filer Category specified"

Affected elements

Explanation

The Filer Category element must be omitted from the ReportingFI element if an associated Sponsor element has been specified which has a Filer Category.

Example

<ftc:FATCA>
  <ftc:ReportingFI>
    ...
    </sfa:Address>
	<ftc:FilerCategory>FATCA602</ftc:FilerCategory>
    <ftc:DocSpec>...</ftc:DocSpec>
  </ftc:ReportingFI>
  <ftc:ReportingGroup>
    <ftc:Sponsor>
	  ...
      </sfa:Address>
	  <ftc:FilerCategory>FATCA609</ftc:FilerCategory>
      <ftc:DocSpec>...</ftc:DocSpec>
    </ftc:Sponsor>

The Filer Category has been specified on both the ReportingFI and Sponsor. Only one should be specified. The following is valid:

<ftc:FATCA>
  <ftc:ReportingFI>
    ...
    </sfa:Address>
    <ftc:DocSpec>...</ftc:DocSpec>
  </ftc:ReportingFI>
  <ftc:ReportingGroup>
    <ftc:Sponsor>
	  ...
      </sfa:Address>
	  <ftc:FilerCategory>FATCA609</ftc:FilerCategory>
      <ftc:DocSpec>...</ftc:DocSpec>
    </ftc:Sponsor>

"This Filer Category is not valid for a Sponsor"

Messages

This Filer Category is not valid for a Sponsor.

The Filer Category must be specified for a Sponsor.

Affected elements

Explanation

Only the following Filer Categories are valid in the Sponsor element when reporting to IGOR:

The Filer Category for a Sponsor must be specified and must be one of these values.

Example

<ftc:Sponsor>
  ...
  </sfa:Address>
  ...

The Filer Category is not included for a Sponsor. The following is valid:

<ftc:Sponsor>
  ...
  </sfa:Address>
  <ftc:FilerCategory>FATCA607</ftc:FilerCategory>
  ...