IGOR

IGOR XML Reporting Guide

Introduction

This document should be read in conjunction with the IRS FATCA User Guide and the Common Reporting Standard User Guide (annex 3 of the OECD Standard for Automatic Exchange of Financial Information in Tax Matters).

A limitation of the FATCA and CRS user guides is that they define the intended use of the schemas when exchanging information internationally (i.e. FIs or Tax Authorities sending information to a foreign Tax Authority). However, they make only loose recommendations regarding the usage of the schemas for 'domestic' reporting, i.e. an FI reporting information to their local Tax Authority.

This document bridges this gap by providing additional notes on how Guernsey FIs should report domestically using IGOR, and how IGOR interprets the XML schema.

Conventions used

This document in general uses CRS element and attribute names and terminology. The CRS schema is structurally identically to the FATCA schema but some terminology is different. Where there are differences, FATCA terminology is included in brackets.

Throughout this document, the term message is used to refer to a complete XML document containing EOI information.

Basic requirements of a valid message

Authentication

A message can be submitted to IGOR either by logging in and selecting an Organisation to report for in the web user interface, or by using a web service call and an Organisation API key.

For FATCA reporting, in order for IGOR to verify that the user is authorised to transmit the message, every ReportingFI must have exactly one IN element with issuedBy="US" which must contain a valid GIIN which is one of the Organisation's authorised FIs, otherwise the entire message is rejected. For CRS reporting, if a GIIN is priovided it is treated as for FATCA; if no GIIN is provided then the ReportingFI is authenticated by name: the name in the Name element must match eactly the name registered with IGOR.

The SendingCompanyIN in the MessageSpec element must be either an IGOR organisation ID (recommended), or a a valid GIIN which is one of the Organisation's authorised FIs.

For FATCA reporting, the element containing the GIIN of the ReportingFI is called TIN instead of IN. IGOR will treat a TIN as a GIIN if the issuedBy attributed is either "US" or omitted, but for consistency with CRS the issuedBy attribute should be specified with the value "US".

The IRS has not yet established a registration process to allow sponsored entities to have their own GIINs. If the ReportingFI is a FATCA sponsored entity then the TIN element of the ReportingFI should contain the GIIN of the sponsoring entity. This approach is analogous to that proposed in the FATCA FAQ on Sponsoring/Sponsored Entities.

The GIIN of the Sponsor element itself is not authenticated by IGOR.

XSD Validation

All messages submitted under FATCA or CRS are validated first against the relevant FATCA or CRS schema definition (XSD) files. Note this means that some elements or attributes which are ignored by IGOR are still mandatory if required by the relevant XSD. In the commentary below, recommended values are provided for such fields.

XML Comments

XML comments may be included in messages. XML comments are removed by IGOR before the message is stored, and are therefore not visible to the States of Guernsey Revenue Service or the destination country.

Encoding

All XML messages submitted to IGOR must be valid (see http://www.w3.org/TR/REC-xml/#dt-valid) and should be UTF-8 encoded. Other encodings may be used, but are not guaranteed to be handled correctly by IGOR.

XML Element Usage

The outline of the CRS schema is shown below, showing the elements which are relevant to this document:

MessageSpec element

The sub elements of the MessageSpec element are only used by IGOR for message processing. Apart from the ReportingPeriod, none of the information is forwarded to the destination country.

SendingCompanyIN

The SendingCompanyIN must be either an IGOR organisation ID (recommended), or the GIIN of an FI which has been registered within your IGOR Organisation. If using a GIIN it does not necessarily need to correspond to any of the reporting FIs or sponsors contained in the message, but the sender should chose the GIIN of the most 'obvious' main sponsor or lead FI.

The SendingCompanyIN has special significance if corrections are used (i.e. if you are using DocSpec elements to amend or void previously submitted data). The SendingCompanyIN of a message containing a correction must be the same as the SendingCompanyIN of the message being corrected.

TransmittingCountry and ReceivingCountry

The content of these fields is ignored for domestic reporting to IGOR. They must be provided in order to pass XSD validation, and it is recommended they should both contain "GG" (for Guernsey).

For CRS reporting, in order to avoid ambiguity, the ReceivingCountry must be GG.

Warning and Contact

These elements are ignored by IGOR and will not be forwarded to the destination country.

MessageRefId

This string uniquely identifies the message. It may contain any characters.

IGOR will check that the MessageRefId is unique and will reject any message where it is the same as a previous MessageRefId successfully submitted by the same SendingCompanyIN. The string comparison used for this test is case insensitive, so MessageRefIds which differ only in letter case are considered to be the same.

MessageTypeIndic

This element appears in CRS only. If present, it is ignored by IGOR, and it should be omitted.

The CRS User Guide contains a requirement that 'messages must contain all new or all corrected data'. However, Guernsey FIs can ignore this requirement when reporting via IGOR. IGOR accepts messages for both CRS and FATCA which contain a mixture of new and corrected reports.

CorrMessageRefId

For FATCA reporting, this element is ignored by IGOR and should be omitted. When transmitting corrections under FATCA, the CorrMessageRefId under the DocSpec element should be used.

For CRS reporting the CorrMessageRefId must be omitted. CorrMessageRefId is not used for CRS corrections (CRS uses globally unique DocRefIds instead) and IGOR does not support the CRS convention of using the CorrMessageRefId to cancel a previous message.

MessageType and Timestamp

These must be provided in the form recommended by the FATCA and CRS specifications, although presently they are ignored by IGOR.

ReportingPeriod

This must be provided as recommended by the FATCA and CRS specifications. The ReportingPeriod is used by IGOR to determine whether to send messages to users to remind them to submit reports.

When a message contains a correction, the ReportingPeriod of the message must be the same as the ReportingPeriod of the message which contained the element being corrected. If not, IGOR will reject the message.

CrsBody/FATCA element

The details of how account, account holder and organisation information should be reported using the CRS and FATCA schema is outside the scope of this document, except to say that these details are not processed by IGOR but are simply forwarded verbatim to the destination country.

Multiplicity of ReportingGroups

The CRS specification states on page 244 'although in the schema this element is repeatable, for CRS only one ReportingGroup for each CrsBody is to be provided'.

For IGOR, this restriction is applied to both FATCA and CRS reporting. Messages must contain exactly one ReportingGroup in each CrsBody (or FATCA) element.

The rationale behind this restriction is that allowing multiple ReportingGroups would create significant ambiguity over how to interpret corrections, because it is not clear how newly added AccountReports should relate to previously provided Sponsor and Intermediary details for the same ReportingFI. Rather than attempt to resolve this ambiguity by creating a novel interpretation of the correction process which would have counter-intuitive behaviour in certain cases, we have opted to impose the same restriction to FATCA as exists in CRS.

ReportingGroup contents

Under CRS, the ReportingGroup element should only contain AccountReports. Therefore if a Sponsor, Intermediary or PoolReport is included in a CRS message, the message will be rejected.

Under the Model 1 IGA used for FATCA reporting, pooled reports are not permitted. Therefore if a PoolReport is included in a FATCA message, the message will be rejected.

DocSpec elements

IGOR processes DocSpec elements in order to handle corrections of reported data in accordance with the intended use of the CRS and FATCA specifications. The best available guidance on the correction process is in the CRS User guide starting on page 252.

The following notes on the parts of the DocSpec element provide some additional information about how IGOR handles corrections.

DocRefId

Every DocSpec element must have a DocRefId. It may contain any characters.

IGOR will reject any messages with duplicate DocRefIds when the message is submitted. For a CRS message, a DocRefId must never be reused by a given SendingCompanyIN. For FATCA, the DocRefId need only be unique within the message.

As for MessageRefId, the string comparison used for this test is case insensitive, so DocRefIds which differ only in letter case are considered to be the same.

DocTypeIndic

IGOR does not recognise separate DocTypeIndics for live and test data. All DocTypeIndic elements, whether being submitted to a live or test IGOR Organisation, must use the following values:

CorrDocRefId

The entire message will be rejected if any CorrDocRefId (or CorrMessageRefId and CorrDocRefId for FATCA) is not valid. A CorrDocRefId is not valid if:

Correcting or deleting already-corrected elements

The CRS user guide states on page 254 that 'the CorrDocRefId [...] must always refer to the latest reference of this AccountReport (DocRefId) that was sent'.

However, the FATCA user guide does not stipulate whether the CorrDocRefId of an element which is a correction or a deletion of an element which has already been corrected should be the DocRefId of the original element or of the corrected element. For example, if new data is sent with DocRefId = A, and a correction is then sent with DocRefId = B and CorrDocRefId = A, should the CorrDocRefId of a further correction be A or B?

To resolve this ambuguity in FATCA, IGOR will accept a correction which has a CorrDocRefId equal to any DocRefId from the chain of corrections of the element when receiving either CRS or FATCA reports. We recommend that senders should follow the CRS requirement and use the latest DocRefId if this can be achieved without additional implementation complexity.

Once an element has been deleted, any message containing a further request to correct or delete the element will cause the whole message to be rejected.

Treatment of ReportingFIs when correcting AccountReports

Each ReportingGroup may contain multiple AccountReports and for FATCA may optionally contain a Sponsor and/or an Intermediary. These are all correctable elements having a DocSpec. However, while the CRS and FATCA user guides give clear guidance on how these elements are to be corrected, there is some ambiguity about what should be provided in the ReportingFI which corresponds to the correction, which is a mandatory element in the containing CrsBody (or FATCA) body element.

The IGOR implementation of the correction process requires that if any body element contains a correction or deletion, then the ReportingFI of that body element must be a correction of the same ReportingFI element which was in the body element containing the original element. The ReportingFI element must therefore also contain a repeat of the information contained in the original element.

For example, if an original message contains this information:

Then a correction to AccountReport A1 should look like this:

Note it is not necessary to repeat AccountReport A2 or the CrsBody containing ReportingFI B; those details will remain unaltered.

When deleting a ReportingFI, it is however necessary to also delete all current AccountReports (and for FATCA, also any Sponsor or Intermediary) within the same body.