Schema uk fatca submission MasterFile€¦ · A schema is a data structure for holding and transmitting information electronically and in bulk. XML ‘extensible markup language’

FATCA UK SubmissionSchema v1.3

Guide

HMRC US Foreign Account Tax Compliance Act UK Submission Schema User Guide v1.3

©HM Revenue & Customs 2014 ∙ All rights reserved.

Scope of this guide FATCA is a service for Financial Institutions (FI) to report to HMRC on interests held by US citizens and other overseas residents under FATCA(Foreign Account Tax Compliance Act) and similar reporting obligations.

This guide explains the information to be included in each element of the XML that makes up the HMRC US FATCA UK Submission and Financial Institution Reports XML schema (v1.2).

AUDIENCE

This guide is expected to be used by people that have a good understanding of XML schemas and not by those that would use the HMRC portal website to enter their FIs account details (in this case the XML creation is produced by HMRC using a web-based set of input forms).



2

General informati on A schema is a data structure for holding and transmitting information electronically and in bulk. XML ‘extensible markup language’ is commonly used for this purpose. The UK Submission schema is used to verify that the XML file that is created conforms to HM Revenue & Customs rules for submission of FATCA information.

The term “message” that is used throughout this document refers to a XML instance based on the FATCA UK Submission schema.

The HMRC US FATCA UK Submission and Financial Institution Reports XML schema allows a submitter to create a new message, replace a previous message in its entirety, update a previous message or delete an erroneous message.

The Schema allows for the reporting of the financial information of organisations and individuals accounts on an annual basis (reporting period).

The option of a Pool Report is only to be used by Financial Institutions reporting from Bermuda. Therefore UK Financial Institutions should not enter information in this area of the schema.

The journey of FI data through the schema can take one of two possible ‘routes’:

Submission or

VoidSubmission

The Submission route should be used when creating a new or amending a previous submission message.

The VoidSubmission route should only be used when you want to delete a previous submission that you have no intention of replacing or amending. See pages 69, 82/83 for more information.



3

UNDERSTANDING HOW TO DETERMINE THE CATEGORY OF YOUR MESSAGE

In order to process your data correctly we have put in place a list of possible message types.

The initial submission for a reporting period is always set at ‘NewSubmission’. This is the only time you should use the ‘NewSubmission’ as the category for your message for that reporting period (see scenario 4 for exception to this rule).

Below are some examples of when the other message types are expected to be used:

Scenario 1: I have submitted a new submission message and had a verification email saying it has been accepted. I then realised that I had missed 10 accounts for one of my FIs.

You should submit a ‘SubmissionVariation’ category message to add the extra accounts for the FI (you are varying your already stated FI Report for that period).

Scenario 2: I have submitted a new submission message and had a verification email saying it has been successful. I then realised that there were erroneous account holders within the report.

You should submit a ‘SubmissionReplacement’ message. Remove the erroneous account holders from the original XML message and resend the message using the Replacement section (Ref Id = S2.3) of the Submission element.

If you have more than a minor change to either FI data or Account data, replace the entire submission using ‘SubmissionReplacement’.

Scenario 3: I have submitted a new submission message and had a verification email saying it has been successful. I then realised that a balance on one account is incorrect.

You should submit a ‘SubmissionVariation’ message. You will need to input:

The FIReturnRef (i.e. the parent of the AccountRef) with an action of ‘Variation’.

The AccountRef of the account that needs to be corrected fromthat original message (again with the action of ‘Variation’).

The entire account data for the account that needs to have its balance corrected.



4

Scenario 4: I have submitted a new submission message and had a verification message stating I have an invalid file and should resubmit the file once it has been corrected.

You should submit a ‘NewSubmission’ message as the data from the original message will not have been added to the database.

Scenario 5: I have submitted a NewSubmission message and a SubmissionVariation (or SubmissionReplacement) messagein quick succession.

I receive a verification message stating I have an invalid file(on the original NewSubmission).

You should correct the NewSubmission message and resubmit with the message category of NewSubmission; then send the SubmissionVariation (or Replacement) message again.

The database will not have stored the original data of the invalid file and cannot therefore update with the Variation file until the original file’s data is stored successfully.

Replacing a SubmissionReplacement messageWhen you need to replace a replacement message e.g. your process looks something like:

1. NewSubmission message on 30 April 20152. SubmissionReplacement message on 15 May 2015

further errors found with the replacement so…3. SubmissionReplacement message on 30 May 2015

The XML message at ‘3.’ should have in the ReplacedMessageRef element (S2.3.2) the MessageRef of the last message (i.e. 15 May 2015) involved in the process.

Other SubmissionReplacement facts: When issuing a SubmissionReplacement message any ‘action’

element (see next page) should always be ‘New’. SubmissionReplacement messages should never contain ‘Void’

elements.



5

UNDERSTANDING THE ‘ACTION ’ METADATA ELEMENTS

In order to process your return effectively HMRC need to understand what to do with the data you supply.

NewSelecting the ‘New’ action means that the data you are supplying within that section of the message has not been delivered to us before. It should be treated as newly created data.

It will have a new action reference (i.e. AccountRef, FIReturnRef, or PoolReportRef).

ReplacementIf the majority of the data you have previously supplied has changed then this would be the best option to take. Be careful, as the higher upthe hierarchy of the data in the message the more data you will need to supply.

Example:

A FIReturnAction with the Action of Replace would:

Look at the data in our database under that FI Return Reference and delete that data before replacing it completely with the data in the FIReturn element of the message.

VariationThe data given a ‘variation’ action means we should have previously received and successfully processed the data you wish to update. We will have a unique action reference (i.e. AccountRef, FIReturnRef, or PoolReportRef) that you supplied within the original message.

You have decided that it is necessary for us to overwrite that original data, identified by the action reference, with the data marked as a variation.

You will still need to fulfil the mandatory restrictions within the sectionyou are varying. This includes any ‘child’ elements that are required by the schema.

If you need to completely remove a set of data then the use of the ‘Void’elements (VoidSubmission, VoidFIReturn, VoidAccountData and VoidPoolReport) is recommended.

If you need to use a VoidFIReturn, VoidAccountData or VoidPoolReport the MessageCategory should always be SubmissionVariation.



6

HOW THE UK FATCA FI DATA INPUT IS STRUCTURED

The UK Submission schema will collect FATCA data that will then be put into an annual return to the IRS in the United States using the required US FATCA Schema format.

As there are certain pieces of data that the UK needs in order to process the FATCA information correctly and the US FATCA Schema didn’t allow for that information, it was necessary to create a UK Submission schema.

This also enabled HMRC to simplify the schema that UK FIs would need to comply with in order to make a FATCA return. We organised it like this:

The main participants in UK FATCA return processing are:

The user of the UK FATCA service for submitting returns.

The UK Financial Institution that needs to submit a return.

This could be the same entity. But we are aware that in many cases they will be different entities. Therefore when registering in the UK to use the FATCA service you will be asked to first supply details for the FATCA User and then similar details for one or more Financial Institutions.

The upside of doing this at registration is that you will not need to enter those details again every time you make a submission using this schema.

If the FATCA User or the FI details change since you registered, you willneed to update your registration details in the HMRC site so that HMRC can provide the correct FI details on your next submission to the US.

Details on the information requested for UK registration is in Annex A

The following diagram shows the flow of the process.



7

F IG 1: PROCESS FLOW OF UK FATCA REGISTRATION



8

Technical informati onHMRC have designed this XML schema using the following standards:

All elements have a unique ID to allow quick cross-reference. All element and attributes use Upper Camel Case (UCC), e.g.

ReportingPeriod, and avoid hyphens, spaces etc. ComplexTypes or simpleTypes are set up when the particular

types are likely to be re-used. e.g. ContactPersonInformation. There is only one ‘include’ for this schema. This is the standard

ISO 3166 Alpha 2 Country and ISO 4217 Alpha 3 Currency Codesschema used by US FATCA and OECD schemas.

NAMING THE XML MESSAGE

Once constructed your XML message should be named using the following format:

9999999999YYYYMMDDHHMMSS99.xml

First 10 digits are your unique UK FATCA ID that was produced at HMRC FATCA Registration.

The next 8 digits are the date the file was created starting with year then month then day (all single digit day date or month dates should have a leading zero). Example Wednesday 9th April 2014 would be 20140409.

The next 6 digits are the time of day in hours, minutes and seconds that the file was created.

The last 2 digits are an incremental number starting at ‘00’ and increasing to ‘99’ when a file is produced during the same second.

This is the same as the suggested format for the element MessageRef in the XML.

Not following this recommendation would mean that HMRC will be unable to give email notification if your XML message should arrive corrupted or unreadable by our systems.

MAXIMUM FILESIZE FOR ONE XML INSTANCE

When uploading a file to the HMRC Online Services portal website there is a limit to how large a file HMRC can consume. This is currently 25Mb (Megabytes). If your file is larger than 25Mb we will accept a compressed version of the XML file up to that size.

The 25Mb limit does not apply to submitters using the Secure Electronic Transfer (SET) route.



9

TABLE OF XML SYMBOLS IN USE IN THIS DOCUMENT

Symbol Explanation Example

This symbol means that an element is a sequence of other inner elements.

The element Sequence is composed of two (child) elements: FirstElement and SecondElement.

This symbol means that an element is made of one and only one of the inner elements.

The element Choice contains as child elementeither FirstChoice or SecondChoice.

This continuous border indicates a mandatory element or attribute within an instance document.The three lines in the upper left corner indicates that the element as no child element (this notation does not apply to attributes).

The element MandatoryElement must be present in any XML instance document.

This dashed border means that theelement or attribute is optional within an instance document. The OptionalElement is optional in any XML

instance document.

The figures indicate the cardinality.

The element Sequence is made of the following child elements:

FirstElement: this element must occur at least one time;

SecondElement: this element is optional and can occur at most five times.



10

Message elementselement UKFATCASubmissionFIReport

The root of the XML message. It has one attribute and three ‘children’. You need to supply the SchemaVersion you have used to create the message, the mandatory MessageData items and either a Submission dataset or a VoidSubmission dataset.

namespace http://hmrc.gov.uk/UKFATCASubmissionFIReport

Ref Id S

children MessageDataSubmissionVoidSubmission

attribute SchemaVersion

xpath /UKFATCASubmissionFIReport/@SchemaVersion

Ref Id DataType Required

S0 xs:decimal Yes

The root element has a mandatory attribute called SchemaVersion. This allows the XML instance to show the version of the HMRC US FATCA UK Submission schema used to create the message. If an updated schema is issued please ensure this attribute is updated to reflect the new version in the XML message.

Initially the schema will be set at ‘1.0’ and will increment by one minor point at each schema change i.e. 1.1, 1.2 etc

You will find the XML schema version you are validating against in the version attribute at the root of the schema. Emboldened in the example below:<xs:schema xmlns="http://hmrc.gov.uk/UKFATCASubmissionFIReport" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:iso="urn:oecd:ties:isofatcatypes:v1" targetNamespace="http://hmrc.gov.uk/UKFATCASubmissionFIReport" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.2">



11

element MessageData

The basic administration information about the submission. What the message is doing (MessageCategory), when the message was created (XML Timestamp) and the identity of the submitter – FATCA ID (FATCAUserID).

xpath /UKFATCASubmissionFIReport/MessageData

type MessageDataType

Ref Id S1

children MessageCategoryXMLTimeStampFATCAUserId



12

element MessageCategory

xpath /UKFATCASubmissionFIReport/MessageData/MessageCategory

Ref Id

DataType Required

S1.1 xs:token Yes

Indicates the type of XML message and helps to ensure the message is processedcorrectly. The MessageCategory element is an XML enumeration consisting of the following UK FATCA-related items:

Value Annotation

NewSubmission Used when submitting an original return of FATCA reporting information.

SubmissionVariation Used when submitting a message that updates a previous message sent by the same submitter.

SubmissionReplacement Used when a previous message needs to be resent with major amendments.

SubmissionVoid Cancellation of a previously submitted message.

For more information on which value to use for your message please see page 4.

element XMLTimeStamp

xpath /UKFATCASubmissionFIReport/MessageData/XMLTimeStamp


S1.2 xs:dateTime Yes

This data element identifies the date and time when the message was compiled. Itis anticipated this element will be automatically populated by the host system. The format for use is YYYY-MM-DD’T’hh:mm:ss. Fractions of seconds are not used. Example: 2015-03-15T09:45:30

element FATCAUserId

xpath /UKFATCASubmissionFIReport/MessageData/FATCAUserId


S1.3 xs:token Yes

This is the unique identifier given to the UK FATCA user by HMRC at registration of the FATCA Service (FATCA ID). It belongs to the original entity registering for the HMRC FATCA Service and will not change throughout the submission process.

Facets

Kind Value Annotation

length 10

pattern [0-9]{10} 10 numeric characters



13

element Submission

The main section of the XML file; this is where you will record all the pertinent information necessary to produce a FATCA return.

If you choose to enter data in this section of the XML message then you will not be able to also have a VoidSubmission section.

xpath /UKFATCASubmissionFIReport/Submission

type SubmissionType

Ref Id S2

children ReportingPeriodMessageRefReplacementFIReturn



14

element ReportingPeriod

xpath /UKFATCASubmissionFIReport/Submission/ReportingPeriod


S2.1 xs:date Yes

The ReportingPeriod identifies the calendar year to which the message relates in YYYY-MM-DD format. For example, if reporting information for the accounts or payments made in calendar year 2014, the field would read, “2014-12-31”

The ReportingPeriod cannot be in the future (e.g. if current year is 2015 putting ina submission for 2016-12-31). This will be schema valid but will generate an error when we process that message.

Facets


pattern [0-9]{4}-12-31 Date must contain December 31st.

pattern [^:Z]* No Zone information.

element MessageRef

xpath /UKFATCASubmissionFIReport/Submission/MessageRef


S2.2 xs:token Yes

Sender’s unique reference for the message. Suggested format is: HMRC FATCA ID + date of message (YYYYMMDD) + time of message HHMMSS + two digit incremental sequence (99). to ensure that this is kept unique:

12345678902016082015301000

Which would be the first Submission message on 20/08/2016 at 3:30.10PM for a FATCA User with the identifier 1234567890.

This element is a choice option. You would choose this over the Replacement element if the MessageCategory was anything but ‘SubmissionReplacement’. E.g.if it was a new submission you would choose this option.

Facets


minLength 24 Unique message reference cannot be less than 24 characters.

maxLength 36 Unique message reference cannot be longer than 36 characters.



15

element Replacement

If this message is a replacement to an already submitted message then this section is mandatory. If used HMRC will replace the entire message specified in ReplacedMessageRef with this one.

This element is a choice option therefore conditions apply to its use: the MessageCategory element must equal ‘SubmissionReplacement’.

xpath /UKFATCASubmissionFIReport/Submission/Replacement

type ReplaceMessageType

Ref Id S2.3

children MessageRefReplacedMessageRef

element MessageRef

Xpath /UKFATCASubmissionFIReport/Submission/Replacement/MessageRef


S2.3.1 xs:token Yes

Sender’s unique reference for the message. Suggested format is: HMRC FATCA ID + date of message (YYYYMMDD) + time of message HHMMSS + two digit incremental sequence (99). to ensure that this is kept unique:

12345678902016082015301000

Which would be the first Submission message on 20/08/2016 at 3:30.10PM for a FATCA User with the identifier 1234567890.

Facets



maxLength 36Unique message reference cannot be longer than 36 characters.



16

element ReplacedMessageRef

xpath /UKFATCASubmissionFIReport/Submission/Replacement/ReplacedMessageRef


S2.3.2 xs:token Yes

The original submission message reference. This will be used to find the submissionthat is to be replaced.

Please see page 5 (Replacing a SubmissionReplacement message) for further information as to what should go into this element.

Facets






17

element FIReturn

Where the Financial Institution’s reportable data is stored. There would only need to be one instance of this section if you only had one FI to report on but the schema allows for multiple occurrences to be used if necessary. This could be useful even if you had only one FI to report but that FI had a NilReturn tomake for a specific Jurisdiction or you wish to use a SubmissionVariation to both add an FI Return and ‘void’ an erroneous FI Return.When amending previously submitted returns FI return data you may need to use the NoVariation element to remove the need to include unnecessary Account or Pool Report data.



18

xpath /UKFATCASubmissionFIReport/Submission/FIReturn

type FIReturnType

Ref Id S2.4

children FIReturnActionFIRegisterIdDueDiligenceIndThresholdIndNilReturnAccountDataPoolReportNoVariationorVoidFIReturn

element FIReturnAction

This information is needed to ensure the processing of the return is as expected by the sender. The element indicates the current/updated Financial Institution Return’s reference and Action.

See page 6 for details on actions and Appendix C page 82 for possible issues when applying actions.

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/FIReturnAction

type FIReturnActionType

Ref id S2.4.1

children FIReturnRefAction



19

element FIReturnRef

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/FIReturnAction/FIReturnRef


S2.4.1.1 xs:token Yes

The unique reference (both within this document and within the FI’s returns) to identify this return. Suggested format to achieve this would be: FI’s HMRC registration identification number + Reporting Period (YYYYMMDD) + unique sequence + Reporting Jurisdiction.

unique sequence should only be necessary if you are not following the recommended process stated in pages 4-6.

The Reporting Jurisdiction should only be necessary if the FI needs to submit a Nil Return.

Facets


minLength 8 Unique FI return reference cannot beless than 8 characters.

maxLength 36 Unique FI return reference cannot belonger than 36 characters.

NB. Please ensure you keep a record of this reference. You will need it in order toupdate or remove a submitted return from our system.

element Action

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/FIReturnAction/Action



What action HMRC need to take with the data supplied i.e. Create new FI report, update or replace an existing FI report. The XML Enumeration values are as follows:

Value AnnotationNew Used when creating an original Financial Institution (FI) report

for the reporting period.

Replacement Used to completely replace the existing FI Report for that period.

Variation Used when updating or adding to a previous FI Report sent by the same submitter for the same period.

To remove a FI Report completely please use the VoidFIReturn element (S2.4.9).

See page 6 for more information.



20

element FIRegisterId

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/FIRegisterId


S2.4.2 xs:token Yes

HMRC Registration Identification number for the reportable Financial Institution. This information can be found in the HMRC Portal when needed. This identifier is globally unique within HMRC.

If the physical Financial Institution splits their return between agents then they will have a separate unique Registration Identification number for each submitter. If this was the case it means the reportable jurisdiction’s tax identifier for the FI (in the USAs case, the GIIN) would be the same for both Registration Ids.

Facets

Kind Value Annotationlength 13

pattern [A-Z]{3}[0-9]{10} First 3 letters of the FI name followed by 10 digits.

element DueDiligenceInd

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/DueDiligenceInd


S2.4.3 xs:byte Yes

This is a Boolean data type to indicate the due diligence requirements check.If an FI has elected to rely on the procedures described in relevant U.S. Treasury Regulations to establish whether an account is a Reportable Account or an account held by a Non-participating Financial Institution then this entry should be ‘1’ (Yes) otherwise set to ‘0’ (No). The XML Enumeration values are:

Value Annotation0 No I have not elected to perform due diligence in line with the US

regulations.

1 Yes; I have elected to rely on the procedures described in the US regulations.



21

element ThresholdInd

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/ThresholdInd


S2.4.4 xs:byte Yes

The Boolean data type to indicate the threshold qualification.Indicates if the FI has elected to apply thresholds in the due diligence process. ‘1’ (Yes) otherwise set to ‘0’ (No).

Value Annotation0 No I have not elected to apply thresholds in the due diligence.

1 Yes; I have elected to apply thresholds in the due diligence.

element NilReturn

You would use this option to send a nil return for a specific reportable jurisdiction for the Financial Institution.

You cannot have both a NilReturn element and an AccountData element under the same Financial Institution ‘tree’. If you need to report a nil return and enter a return for another jurisdiction for the sameFinancial Institution then add another FIReturn section within the message with the same HMRC Registration Identification number (FIRegisterId).

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/NilReturn

type NilReturnType

Ref id S2.4.5

children ReportableJurisdiction



22

element ReportableJurisdiction

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/NilReturn/ReportableJurisdiction


S2.4.5.1 xs:string Yes

This data element uses the 2-digit alphabetic country code specified in the ISO 3166-1 Alpha 2 standard. Example: US.

It identifies the Country Code(s) for the reportable jurisdictions that the FI has no account data to submit during this reporting period.

It is suggested that you use this data to suffix the FIReturnRef element (S2.4.1.1) to make it unique.

The XML enumeration for this item is in Appendix B



23

element AccountData



24

Holds the account information that the Financial Institution needs to report on. This includes account holders (including entities and individuals) tax identification numbers and the jurisdiction they should be reported to. It also identifies Information of actual ‘payment’ and balance information on the account for that reporting period.

It also allows the submitter to void or delete a previously submitted erroneous account. This is achieved using an ‘XML Choice’ element. Therefore you can not have a VoidAccount and the mandatory (for new or updated account data) set of account information in the same AccountData element occurrence.

When you need to vary the information in a previous AccountData submission that doesn’t need an update to the Person or Organisation details you can do so by using the NoVariation element. You cannotuse the NoVariation element in a NewSubmission, SubmissionReplacement or SubmissionVoid message.

If there is an AccountData element there will not be a NilReturn element, PoolReport or NoVariation element for this instance of the FI.

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData

type AccountDataType

Ref id S2.4.6

children AccountActionAccountNumberAccountIdentifierAccountBalanceAccountClosedIndUndocumentedAccountIndPaymentDataAccountHolderTypePersonOrganisationNoVariationorVoidAccountData



25

element AccountActi on

Similar in function to the FIReturnAction, this allows us to process the data correctly at the account level. The sender will need to understand what they want to do with the message and apply the correct action to that instance of the account section.

Details of actions are found on page 6. See Appendix C for information on possible issues when applying an AccountAction.

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/AccountAction

type AccountActionType

Ref Id S2.4.6.1

children AccountRefAction



26

element AccountRef

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/AccountAction/AccountRef


S2.4.6.1.1 xs:token Yes

The unique reference (both within this document and within the FI’s period return) to identify this account section. Suggested format: FI’s HMRC registrationidentification number + Reporting Period + Unique Sequence.

NB. You will need this reference if you need to amend or void an account. Please keep a record of it and keep it safe.

If more characters are needed to input the unique sequence part of the reference we suggest removing the Reporting Period from the reference. Do not remove the HMRC registration identification number part of the reference.

Facets


minLength 8Unique Account reference cannot be less than 8 characters.

maxLength 36 Unique Account reference cannot be longer than 36 characters.

element Action

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/AccountAction/Action



What action HMRC need to take with the data supplied i.e. Create new Account record, update or resend an existing Account record. The XML Enumeration values are as follows:

Value AnnotationNew Used when creating an original Account record for that

period.

Replacement Used when you need to completely replace the account data specified by the AccountRef for the period.

Variation Used when updating or replacing a previous Account record sent by the same submitter for the same period.

To remove an Account record completely please use the VoidAccountData element (S2.4.6.13).

See page 6 for more details.



27

element AccountNumber

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/AccountNumber


S2.4.6.2 xs:token Dependent

This element is a choice. If your account has a recognised type such as BIC, IBAN, OBAN, SIN, ISIN or an identification code of a Cash Value Insurance Contract or Annuity Contract then input the number here.

If you use this element you cannot use AccountIdentifier in this instance of the account record.

Facets


minLength 1 Unique account number cannot be less than 1 character.

maxLength 72Unique account number cannot be longer than 72 characters.

element AccountIdentifier

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/AccountIdentifier


S2.4.6.3 xs:token Dependent

This element is a choice. If your account is not of a recognised type such as BIC, IBAN, OBAN, SIN, ISIN or an identification code of a Cash Value Insurance Contract or Annuity Contract then input the identifier here. You should be able to identify this account using this data.

If your Account Holder type is set as “Non Participating Financial Institution” then you should enter “NPFFI” in this element.

This element can also hold “NANUM” where you find it impossible to differentiate between an aggregate report and genuine account data which does not have an account reference.

If you use this element you cannot use AccountNumber in this instance of the account record.

Facets


minLength 1 Unique account identifier cannot beless than 1 character.

maxLength 72Ideally unique account identifier cannot be longer than 72 characters.



28

element AccountBalance

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/AccountBalance

type MonetaryType


S2.4.6.4 xs:decimal Yes

Provide the account balance or value of the reported financial account. All payment amounts must be accompanied by the appropriate 3 digit currency code. Enter the balance for the account.

Allows a maximum value of: 99,999,999,999,999.99 (just short of 100 trillion).

Do not include the comma separator at the thousands mark in your XML, it will fail validation.

If the FI is a Non Participating Financial Institution then please enter 0.00.

Where the balance is made up from a mixed currency account it must be reported in a single currency. HMRC suggest that you use the 'primary' currency of the account but you can use whatever currency you feel appropriate. The Forex date can either be the end of year, or another date (such as annual valuation date, reporting date etc) providing you use this consistently for each account affected.

Facets

Kind Value AnnotationtotalDigits 16

fractionDigits 2

minInclusive 0 Allows 0.00 or greater.

@currCode attribute Facets (Ref Id = “a1”)


Type iso:currCode_Type

Standard 3 character ISO currency code, please choose from the enumerated list (see Appendix B).

Use RequiredYou cannot have an amount without a stated currency code.



29

element AccountClosedInd

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/AccountClosedInd


S2.4.6.5 xs:byte No

The Boolean data type to indicate the account is active or not.

This data is not needed for US FATCA – it is for future use; please do not use at this point.

Value Annotation0 The account is open and active.

1 The account is closed and inactive.

element UndocumentedAccountInd

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/UndocumentedAccountInd


S2.4.6.7 xs:byte No

This Boolean data type is used in CRS to indicate the account is “undocumented” or not.

This data is not needed for US FATCA – it is for future use; please do not use at this point.

Value Annotation0 For CRS purposes this is not an “undocumented” account

1 For CRS purposes this is an “undocumented” account



30

element PaymentData

Where available this holds payment data about the account. The type of payment and the monetary amount including the currency code is recorded here.

If interest received is also reflected in the amount of redemption then it should not be double counted. All payments must be positive figures (a withdrawal from the account is not a payment amount and nor is it a redemption). The payment figure should reflect the total amounts paid to the account, whether paid into the account or directly to the account holder). Interest received into the account should not be netted against amounts that the FI pays out.

It is expected that there should be no more than five occurrences of this data set for an account.xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/PaymentData

type PaymentDataType

Ref Id S2.4.6.8

children PaymentCodePaymentAmount



31

element PaymentCode

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/PaymentData/PaymentCode



The Payment Code is needed to ascertain to what the payment relates.The options available are detailed in the XML enumeration below.

Value Annotation00 Custodial Account: total gross amount of interest (US Code OECD504)

01 Custodial Account: total gross amount of dividends (US Code OECD503)

02 Custodial Account: total gross amount of other income generated with respect to the assets held in account. (US Code FATCA519)

03 Custodial Account: total gross proceeds from the sale or redemption of property paid or credited to the account. (US Code FATCA518)

10 Depository Account: total gross amount of interest. (US Code OECD504)

20 Other Accounts: total gross amount paid or credited to the Account Holder including the aggregate amount of any redemption payments made to the Account Holder. (US Code FATCA519)

90 Aggregate Reports: the aggregate amount of payments made to each Nonparticipating Financial Institution. (US Code FATCA519)



32

element PaymentAmount

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/PaymentData/PaymentAmount

type MonetaryType


S2.4.6.8.2 xs:decimal Yes

The total amount of payment for the given PaymentCode (includes the smallest unit for the currency used).

If your payment is less than 0.01 then please do not create this element (figures of 0.00 or below will not validate).



Facets


fractionDigits 2

minExclusive 0 Zero amounts are not accepted.





Use Required You cannot have an amount without a stated currency code.



33

element AccountHolderType

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/AccountHolderType



The type of account holder as specified by the FATCA regime.

Value AnnotationIndividual Natural Person

Reportable Entity

Organisation / Company

Entity with Reportable Controlling Person

Organisation/Controlling Person (US Substantial Owner)

Owner Documented Financial Institution

To use this type the reporting the FI has to be a designated withholding agent that has agreed to treat the financial institution in question as an Owner Documented FI. This is an elective position under the terms of the US regulations and is supported by the schema to allow for this election.

Non Participating Financial Institution



34

element Person

Where the account holder data is stored if the account is held by an individual.Please report his/her identifying information here, such as name, address, date of birth (if known) and tax information including their reportable jurisdiction(s).

If data is input to this section then the same AccountData section cannot have Organisation data as well. If you need to add a “controlling person” to the account you should take the Organisation choice and enter the controlling person information in that dataset.

Do not use this element to enter Controlling Person data.

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Person

type ContactPersonInformation

Ref Id S2.4.6.10

children FirstNameLastNameAddressHolderTaxInfoBirthDate



35

element FirstName

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Person/FirstName


S2.4.6.10:b1 xs:token Yes

First name or initials of the account holder. If a middle name needs to be entered it should go here along with the first name if there is enough space.

Facets


minLength 1Must be at least one character entered here.

maxLength 70 The first name cannot be greater than 70 characters long.

element LastName

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Person/LastName


S2.4.6.10:b2 xs:token Yes

Last name or surname of the account holder.

Facets


minLength 1 Must be at least one character entered here.

maxLength 70 The last name cannot be greater than 70 characters long.



36

element Address

This data element is the permanent residence address of the individual account holder. If the reporting FIdoes not have a permanent residence address on file for the individual, then the address is the mailing address used by the financial institution to contact the individual account holder when the report is compiled.

Where possible please use the structured address items as described. The City and Country are required / mandatory for schema validation as these items are mandatory in the US FATCA specifications.Although building identifier, street name, district name and postal code are optional, it would be expected that most of these items would be included.

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Person/Address

type ContactAddressType

Ref Id S2.4.6.10:b3

children BuildingIdentifierStreetNameDistrictNameCityPostCodeCountryCode



37

element BuildingId

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Person/Address/BuildingId


S2.4.6.10:b3.1 xs:token No

Number / name of the building for the legally registered address.

FacetsKind Value AnnotationminLength 1maxLength 70

element StreetName

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Person/Address/ StreetName



Name of the road or street where the building resides.

Facets


minLength 1

maxLength 100

element District

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Person/Address/DistrictName



Name of the district or county where the building resides.

Facets


minLength 1

maxLength 70



38

element City

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Person/Address/City


S2.4.6.10:b3.4 xs:token Yes

Name of the town or city where the building resides.

Facets


minLength 1

maxLength 70

element PostCode

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Person/Address/PostCode



The postal code for the building.

Facets


minLength 1

maxLength 35

element CountryCode

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Person/Address/CountryCode


S2.4.6.10:b3.6 xs:string Yes

Country / jurisdiction where the building is located.

Standard two letter ISO Country Code as used by the US FATCA Schema. Matches ISO 3166-1. (Please see Appendix B for the list of codes in the enumeration.)

This element is a large XML Enumeration.



39

element HolderTaxInfo

This data element/type provides reportable jurisdiction information and the Tax Identification Number (TIN) used by the receiving tax administration to identify the Account Holder. Examples: US has SSN, IoM has NINO.

Although both the TIN code and actual TIN are optional, there has to be at least one HolderTaxInfo element due to the ReportableJurisdiction being mandatory. There can be no more than 249 (the maximum current number of countries in the ISO list) occurrences of this element.

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Person/HolderTaxInfo

type HolderTaxInfoType

Ref Id S2.4.6.10:b4

children TINCodeTINReportableJurisdiction



40

element TINCode

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Person/HolderTaxInfo/TINCode

type TINCodeType



Tax Identification Number codes. Currently one of the following XML enumerations.

Value AnnotationEIN Employer Identification NumberSSN Social Security NumberITIN Individual Taxpayer Identification NumberATIN Adoption Taxpayer Identification NumberPTIN Preparer Tax Identification NumberNINO National Insurance NumberOther

@TINCountryCode attribute Facets (Ref Id = “b4.1.1”)


Type iso:CountryCode_Type

Specifies the country of issue – should relate to Reportable Jurisdiction in most cases.

Standard 2 character ISO country code, please choose from the enumerated list (see Appendix B).

If “Other” is specified for the TIN Code then the TIN Country Code attribute can be omitted.



41

element TIN

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Person/HolderTaxInfo/TIN



The actual Tax Identification Number for the individual account holder. Should match the format expected by the TIN Code chosen.

Facets


minLength 1

maxLength 80


xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Person/HolderTaxInfo/ ReportableJurisdiction


S2.4.6.10:b4.3 xs:string Yes

The element indicates the financial institution reports submitters’ jurisdiction countries.

It is known in the US FATCA as the Tax Residence Countries applicable to this account. Standard 2 character ISO country code, please choose from the enumerated list (see Appendix B).

element BirthDate

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Person/BirthDate


S2.4.6.10:b5 xs:date No

This data element identifies the date of birth of the individual account holder and provides tax administrations with the choice of providing date of birth information in lieu of a TIN for the Account Holder, in circumstances described in an applicable FATCA IGA.

The date of birth can be omitted if the FI has not recorded the date of birth information or if a TIN is provided for the Account Holder.

The data format is YYYY-MM-DD.



42

element Organisati on

Where the account holder data is stored if the account is held by any entity other than a “natural” person. Report the entities identifying information here: Organisation Names, Tax Information, Controlling Person’s details (if applicable) and addresses.

If data is input to this section then the same AccountData section cannot have “Person” element data or a NoVariation element as well.

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Organisation

type OrganisationType

Ref Id S2.4.6.11

children OrganisationNameAddressHolderTaxInfoControllingPerson



43

element OrganisationName

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Organisation/OrganisationName



Legal name of the company/organisation that holds the account.

Facets



maxLength 105Organisation name cannot be longer than 105 characters.



44

element Address

This data element is the registered address of the company or organisation that is the account holder. It could be the mailing address used by the financial institution to contact the company/organisation account holder at the period when the report is compiled.

Where possible please use the structured address items as described. The City and Country are required / mandatory for schema validation as these items are mandatory in the US FATCA specifications.Building identifier, street name, district name and postal code are optional.

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Organisation/Address


Ref Id S2.4.6.11.4




45

element BuildingId

xpath/UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Organisation/Address/ BuildingId


S2.4.6.11.4:b3.1 xs:token No

Number / name of the building for the legally registered address.


element StreetName

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Organisation/Address/ StreetName


S2.4.6.11.4:b3.2 xs:token No


Facets


minLength 1

maxLength 100

element District

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Organisation/Address/ DistrictName


S2.4.6.11.4:b3.3 xs:token No


Facets


minLength 1

maxLength 70



46

element City

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Organisation/Address/City


S2.4.6.11.4:b3.4 xs:token Yes


Facets


minLength 1

maxLength 70

element PostCode

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Organisation/Address/PostCode


S2.4.6.11.4:b3.5 xs:token No


Facets


minLength 1

maxLength 35

element CountryCode

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Organisation/Address/ CountryCode


S2.4.6.11.4:b3.6 xs:string Yes






47


This data element/type provides reportable jurisdiction information and the Tax Identification Number (TIN) used by the receiving tax administration to identify the Account Holder when they are an organisation or company. Examples: US has EIN, IoM has NINO.

Although the both the TIN code and actual TIN are optional, there has to be at least one HolderTaxInfo element due to the ReportableJurisdiction being mandatory. There can be no more than 249 (the maximum current number of countries in the ISO list).

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Organisation/HolderTaxInfo


Ref Id S2.4.6.11.5




48

element TINCode

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Organisation/HolderTaxInfo/ TINCode

type TINCodeType


S2.4.6.11.5:b4.1 xs:token No










49

element TIN

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Organisation/HolderTaxInfo/ TIN


S2.4.6.11.5:b4.2 xs:token No

The actual Tax Identification Number for the account holder that is an organisation. Should match the format expected by the TIN Code chosen.

Facets


minLength 1

maxLength 80


xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Organisation/HolderTaxInfo/ ReportableJurisdiction



The element indicates the account holders’ reportable jurisdiction.

It is known in the US FATCA as the Tax Residence Countries applicable to this account. Standard 2 character ISO country code, please choose from the enumerated list (see Appendix B).



50

element ControllingPerson

This element is logically mandatory when an organisation has at least one controlling person. There can be multiple occurrences for one organisation in the event of there being more than one controlling person in the organisation.

If there is more than one controlling person for an organisation and they appear to have the same first and last name when your data is written, try to include in either the first or last name entries a differentiator. E.g if the first controlling person is Jack Smith and the second controlling person is Jaqueline Smith entering ‘J Smith’ for both could lead to confusion once your data gets to the US.

If, given our definition of ‘Controlling Person’, your organisation doesn’t have such an individual then you can safely leave this element out of the XML message.

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Organisation/ControllingPerson

type ContactPersonInformation

Ref Id S2.4.6.11.6

children FirstNameLastNameAddressHolderTaxInfoBirthDate



51

element FirstName

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Organisation/ControllingPerson/ FirstName


S2.4.6.11.6:b1 xs:token Yes

First name or initials of the controlling person. If a middle name needs to be entered it should go here along with the first name if there is enough space.

Try to avoid situations where the same organisation has two controlling people with duplicate first and last name entries. Differentiate with either middle name or initials if possible.

Facets



maxLength 70The first name cannot be greater than 70 characters long.

element LastName

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Organisation/ControllingPerson/ LastName


S2.4.6.11.6:b2 xs:token Yes

Last name or surname of the controlling person.

Try to avoid situations where the same organisation has two controlling people with duplicate first and last name entries. Differentiate with a suffix ifpossible.

Facets



maxLength 70The last name cannot be greater than 70characters long.



52

element Address

This data element is the permanent residence address of the controlling person. If the reporting FI does not have a permanent residence address on file for the controlling person, then the address is the mailing address used by the financial institution to contact the account holder when the report is compiled.

Where possible please use the structured address items as described. The City and Country are required / mandatory for schema validation as these items are mandatory in the US FATCA specifications.Building identifier, street name, district name and postal code are optional.

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Organisation/ControllingPerson/ Address


Ref Id S2.4.6.11.6:b3




53

element BuildingId

xpath/UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Organisation/ControllingPerson/ Address/BuildingId


S2.4.6.11.6:b3.1 xs:token No

Number / name of the building for the registered address.


element StreetName

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Organisation/ControllingPerson/ Address/StreetName


S2.4.6.11.6:b3.2 xs:token No


Facets


minLength 1

maxLength 100

element District

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Organisation/ControllingPerson/ Address/DistrictName


S2.4.6.11.6:b3.3 xs:token No


Facets


minLength 1

maxLength 70



54

element City

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Organisation/ControllingPerson/ Address/City


S2.4.6.11.6:b3.4 xs:token Yes


Facets


minLength 1

maxLength 70

element PostCode

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Organisation/ControllingPerson/ Address/PostCode


S2.4.6.11.6:b3.5 xs:token No


Facets


minLength 1

maxLength 35

element CountryCode

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Organisation/ControllingPerson/ Address/CountryCode








55


This data element/type provides reportable jurisdiction information and the Tax Identification Number (TIN) used by the receiving tax administration to identify the Controlling Person. Examples: US has SSN, IoM has NINO.

Although the both the TIN code and actual TIN are optional, there has to be at least one HolderTaxInfo element due to the ReportableJurisdiction being mandatory. There can be no more than 249 (the maximum current number of countries in the ISO list).

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Organisation/ControllingPerson/ HolderTaxInfo


Ref Id S2.4.6.11.6:b4




56

Element TINCode

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Organisation/ ControllingPerson/HolderTaxInfo/TINCode

type TINCodeType


S2.4.6.11.6:b4.1 xs:token No










57

element TIN

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Organisation/ ControllingPerson/HolderTaxInfo/TIN


S2.4.6.11.6:b4.2 xs:token No

The actual Tax Identification Number for the controlling person. Should match the format expected by the TIN Code chosen.

Facets


minLength 1

maxLength 80


xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Organisation/ ControllingPerson/HolderTaxInfo/ReportableJurisdiction



The element indicates the controlling persons’ jurisdiction countries.

It is known in the US FATCA as the Tax Residence Countries applicable to the ‘substantial owner’. Standard 2 character ISO country code, please choose from the enumerated list (see Appendix B).

element BirthDate

xpath/UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/Organisation/ControllingPerson /BirthDate


S2.4.6.11.6:b5 xs:date No

This data element identifies the date of birth of the controlling person and provides tax administrations with the choice of providing date of birth information in lieu of a TIN for the controlling person, in circumstances described in an applicable FATCA IGA.

The date of birth can be omitted if the FI has not recorded the date of birthinformation or if a TIN is provided for the controlling person.

The date format is YYYY-MM-DD.



58

element NoVariati on

This element allows you to submit a variation on already submitted Account data without having to include unnecessary Person / Organisation data, where that data is unchanging.

This element should not be present in an AccountData record with the action of ‘New’ or ‘Replacement’! It should only be present in a message with the category of SubmissionVariation.

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/NoVariation

type NoVariationType

Ref Id S2.4.6.12

children NoChildChange

element NoChildChange

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/NoVariation/NoChildChange


S2.4.6.12:d1 xs:token Yes

This element acts as a statement that you do not require any change to the child data of the parent element during this variation.

You only have the option of entering “Applied” within this tag.



59

element VoidAccountData

Use this element when you need to completely remove an account record that should never have been previously submitted. Only one of these elements can occur per AccountData section. If you wish to remove multiple accounts either void at the FI return level or add more AccountData sections in your FI Return section.

HMRC will only allow the original submitter (FATCA ID) of an account to void that account.

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/VoidAccountData

type VoidActionType

Ref Id S2.4.6.13

children VoidReference

element VoidReference

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/AccountData/VoidAccountData/ VoidReference


S2.4.6.13:c1 xs:token Yes

Contains the unique reference of the account data that is to be deleted from the data stored for that periods return.

This would be the value of the AccountRef element (S2.4.6.1.1) from the original submission.

Facets


minLength 8Unique Account reference cannot be less than 8 characters.

maxLength 36Unique Account reference cannot be longer than 36 characters.



60

element PoolReport



61

This element is one of a set of options when reporting account data. THIS OPTION SHOULD ONLY BE USED BY BERMUDAN FINANCIAL INSTITUTIONS.

As the UK is a Model 1 territory it requires detailed account data from UK Financial Institutions to be provided under domestic legislation. Model 1 territories cannot have pool reporting as consent does not have to be sought from account holders before a pool report is undertaken.

Bermudan Financial Institutions can provide information with respect to a pool of account holders with similar characteristics using this element.

It also allows the Bermudan FI’s to void or delete a previously submitted Pool Report by using the VoidPoolReport XML choice.

If this option is taken the message cannot have an AccountData or NilReturn element for the same FIReturn element within the message.

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/PoolReport

type PoolReportType

Ref Id S2.4.7

children PoolReportActionAccountCountAccountStatusPoolBalanceorVoidPoolReport

element PoolReportActi on

This allows HMRC to identify the specific Pool Report submitted by the Bermudan Financial Institution and how it should be processed correctly.

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/PoolReport/PoolReportAction

type PoolReportType

Ref Id S2.4.7.1

children PoolReportRefAction



62

element PoolReportRef

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/PoolReport/PoolReportAction/PoolReportRef



The unique reference (within this document) to identify this Pool Report. Suggested format to achieve this would be: FI’s HMRC registration Identification Number + Reporting Period (YYYYMMDD) + Account Status Code (S2.4.7.3). You will need to have recorded this reference as it will be necessary to make amendments to the referred to Pool Report.

Facets


minLength 8 Cannot be less than 8 characters.

maxLength 36 Can be up to 36 characters in length.

element Actionxpath /UKFATCASubmissionFIReport/Submission/FIReturn/PoolReport/PoolReportAction/Action



What action HMRC need to take with the data supplied i.e. Create new Pool Report, update or resend an existing Pool Report. The XML Enumeration values are as follows:

Value AnnotationNew Used when creating an original Pool Report record for that period.

Variation Used when updating or replacing a previous Pool Report sent by the same submitter for the same period.

To remove Pool Report record completely please use the VoidPoolReport element (S2.4.7.5).

element AccountCount

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/PoolReport/AccountCount


S2.4.7.2 xs:nonNegativeInt Yes

This data element provides the number of accounts that are within the pool. For example, input 25 if there are 25 accounts collated within the pooled report.



63

element AccountStatus

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/PoolReport/AccountStatus



You should provide the status of accounts that are collated within the pool. The enumerated options are taken from the US FATCA schema.

Value AnnotationFATCA201 Recalcitrant account holders with US Indicia

FATCA202 Recalcitrant account holders without US Indicia

FATCA203 Dormant accounts

FATCA204 Non-participating financial institutions

FATCA205 Recalcitrant account holders that are US persons

FATCA206 Recalcitrant account holders that are passive Non-Financial Foreign Entities



64

element PoolBalance

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/PoolReport/PoolBalance

type MonetaryType


S2.4.7.4 xs:decimal Yes

The balance for the given set of pooled accounts (includes the smallest unit for the currency used).



Facets


fractionDigits 2

minInclusive 0 Must be 0.00 or greater.





Use Required You cannot have a balance without a stated currency code.



65

element VoidPoolReport

Use this element when you need to completely remove or delete a Pool Report record that has been previously submitted in error. Only one of these elements can occur per Pool Report section. If you wish to remove multiple Pool Reports either void at the FI return level or add more Pool Report sections in your FI Return ‘parent’.

HMRC will only allow the original submitter (FATCA ID) of a Pool Report to void that Pool Report.

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/PoolReport/VoidPoolReport

type VoidActionType

Ref Id S2.4.7.5



xpath /UKFATCASubmissionFIReport/Submission/FIReturn/PoolReport/VoidPoolReport/VoidReference


S2.4.7.5:c1 xs:token Yes

Contains the unique reference of the pool report data that is to be deleted from the data stored for that periods return.

This would be the value of the PoolReportRef element (S2.4.7.1.1) from theoriginal submission.

Facets


minLength 8Unique Pool Report reference cannot be less than 8 characters.

maxLength 36Unique Pool Report reference cannot be longer than 36 characters.



66

element NoVariati on

This element allows you to submit a variation on already submitted FI Return without having to include unnecessary Account or Pool Report data, where that data is unchanging.

This element should not be present in a FI Return record with the action of ‘New’ or ‘Replacement’! It should only be present in a message with the category of SubmissionVariation.

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/NoVariation

type NoVariationType

Ref Id S2.4.8

children NoChildChange

element NoChildChange

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/NoVariation/NoChildChange


S2.4.8:d1 xs:token Yes

This element acts as a statement that you do not require any change to the child data of the parent element during this variation.

You only have the option of entering “Applied” within this tag.



67

element VoidFIReturn

Use this element when you need to completely remove or delete a FI Return record that has been previously submitted in error. Only one of these elements can occur per FI Return section. If you wish to remove multiple FI Returns within the same SubmissionVariation either void at the submission level or add more FI Return sections under the Submission ‘parent’.

HMRC will only allow the original submitter (FATCA ID) of a FI Return to void that FI Return data.

xpath /UKFATCASubmissionFIReport/Submission/FIReturn/VoidFIReturn

type VoidActionType

Ref Id S2.4.9



xpath /UKFATCASubmissionFIReport/Submission/FIReturn/VoidFIReturn/VoidReference


S2.4.9:c1 xs:token Yes

Contains the unique reference of the FI Return data that is to be deleted from the data stored for that periods return.

This would be the value of the FIReturnRef element (S2.4.1.1) from the original submission.

Facets


minLength 8Unique FI Return reference cannot be less than 8 characters.

maxLength 36Unique FI Return reference cannot be longer than 36 characters.



68

element VoidSubmission

Use this option if you have received an acknowledgement from us that we have received a message from you that you never meant to be submitted.

Only the sender (FATCA ID) of the original message can void that message.

If you void a message you cannot logically ‘replace’ that message or make a ‘variation’ on any item of data that was created by the message.

If you wish to ‘undo’ a void you should resend the original message with a new (unique) message reference. We will then treat it as a brand new submission though the end result is still the same.

See Appendix C for other issues that can cause error when using VoidSubmission.

This is a choice with the Submission element. If you have a VoidSubmission element in the message you cannot have a Submission element.

xpath /UKFATCASubmissionFIReport/VoidSubmission

type VoidMessageType

Ref Id S3

children MessageRefVoidMessageRef



69

element MessageRef

Xpath /UKFATCASubmissionFIReport/VoidSubmission/MessageRef


S3.1.1 xs:token Yes

Sender’s unique reference for the message. Suggested format is: HMRC FATCA Identifier + date of message (YYYYMMDD) + time of message HHMMSS + two digit incremental sequence (99). to ensure that this is kept unique:

12345678902016082015301000

Which would be the first Void message on 20/08/2016 at 3:30.10PM for a FATCA User with the identifier 1234567890.

Facets




element VoidMessageRef

Xpath /UKFATCASubmissionFIReport/VoidSubmission/VoidMessageRef


S3.1.2 xs:token Yes

The original submission’s message reference. This will be used to find the data that the message held and remove it from the current dataset.

Facets






70

Annex A – Data collected at UK HMRC Registrati on

User / submitt er detailsThere will only be one set of these details needed per registration of the authorised submitter.

• Organisation name (optional)• Contact Name – first and surname• Building identifier• Street• District (optional)• City• Post code (optional)• Country code• Email• Telephone (optional)

Financial Insti tuti on detailsThere is likely to be more than one set of these details unless you are submitting on behalf of your own (and only) Financial Institution.

• Organisation name (dependant)• Contact Name – first and surname (dependant)• Building identifier • Street• District (optional)• City• Post code (optional)• Country code• Email• Telephone (optional)• Reportable Jurisdiction(s)• UTR (dependant)• NINO (dependant)• Acknowledgement that you have no UK tax identifier

(dependant)• Tax Identifying Number(s) for the specific reportable

jurisdiction e.g. GIIN.



71

Annex B – Included schema – ISO enumerati ons

isofatcatypes_v1.0.xsdIn order to make the HMRC US FATCA Submission schema viable you will need to have this schema (included with many other XML schemase.g. US IRS FATCA schema, OECD schemas).

It holds the enumerations (basically a list) of 249 countries and the international standard two letter character codes for each of those countries (ISO 3166-1 Alpha 2). This allows you to select a two character code to include in the submission XML rather than input a long description of the country.

It also holds the three character international code for currencies (ISO 4217 Alpha 3). This is used when specifying any monetary amount in the submission.

Both lists are shown below.

ISO 3166-1 Alpha 2 – Country CodesCode DescriptionAD ANDORRAAE UNITED ARAB EMIRATESAF AFGHANISTANAG ANTIGUA AND BARBUDAAI ANGUILLAAL ALBANIAAM ARMENIAAO ANGOLAAQ ANTARCTICAAR ARGENTINAAS AMERICAN SAMOAAT AUSTRIAAU AUSTRALIAAW ARUBAAX ALAND ISLANDSAZ AZERBAIJANBA BOSNIA AND HERZEGOVINABB BARBADOSBD BANGLADESHBE BELGIUMBF BURKINA FASOBG BULGARIABH BAHRAINBI BURUNDIBJ BENINBL SAINT BARTHELEMYBM BERMUDABN BRUNEI DARUSSALAMBO BOLIVIA, PLURINATIONAL STATE OF



72

Code DescriptionBQ BONAIRE, SINT EUSTATIUS AND SABABR BRAZILBS BAHAMASBT BHUTANBV BOUVET ISLANDBW BOTSWANABY BELARUSBZ BELIZECA CANADACC COCOS (KEELING) ISLANDSCD CONGO, THE DEMOCRATIC REPUBLIC OF THECF CENTRAL AFRICAN REPUBLICCG CONGOCH SWITZERLANDCI COTE D'IVOIRECK COOK ISLANDSCL CHILECM CAMEROONCN CHINACO COLOMBIACR COSTA RICACU CUBACV CAPE VERDECW CURACAOCX CHRISTMAS ISLANDCY CYPRUSCZ CZECH REPUBLICDE GERMANYDJ DJIBOUTIDK DENMARKDM DOMINICADO DOMINICAN REPUBLICDZ ALGERIAEC ECUADOREE ESTONIAEG EGYPTEH WESTERN SAHARAER ERITREAES SPAINET ETHIOPIAFI FINLANDFJ FIJIFK FALKLAND ISLANDS (MALVINAS)FM MICRONESIA, FEDERATED STATES OFFO FAROE ISLANDSFR FRANCEGA GABONGB UNITED KINGDOMGD GRENADAGE GEORGIAGF FRENCH GUIANAGG GUERNSEYGH GHANA



73

Code DescriptionGI GIBRALTARGL GREENLANDGM GAMBIAGN GUINEAGP GUADELOUPEGQ EQUATORIAL GUINEAGR GREECEGS SOUTH GEORGIA AND THE SOUTH SANDWICH ISLANDSGT GUATEMALAGU GUAMGW GUINEA-BISSAUGY GUYANAHK HONG KONGHM HEARD ISLAND AND MCDONALD ISLANDSHN HONDURASHR CROATIAHT HAITIHU HUNGARYID INDONESIAIE IRELANDIL ISRAELIM ISLE OF MANIN INDIAIO BRITISH INDIAN OCEAN TERRITORYIQ IRAQIR IRAN, ISLAMIC REPUBLIC OFIS ICELANDIT ITALYJE JERSEYJM JAMAICAJO JORDANJP JAPANKE KENYAKG KYRGYZSTANKH CAMBODIAKI KIRIBATIKM COMOROSKN SAINT KITTS AND NEVISKP KOREA, DEMOCRATIC PEOPLE'S REPUBLIC OFKR KOREA, REPUBLIC OFKW KUWAITKY CAYMAN ISLANDSKZ KAZAKHSTANLA LAO PEOPLE'S DEMOCRATIC REPUBLICLB LEBANONLC SAINT LUCIALI LIECHTENSTEINLK SRI LANKALR LIBERIALS LESOTHOLT LITHUANIALU LUXEMBOURGLV LATVIA



74

Code DescriptionLY LIBYAMA MOROCCOMC MONACOMD MOLDOVA, REPUBLIC OFME MONTENEGROMF SAINT MARTIN (FRENCH PART)MG MADAGASCARMH MARSHALL ISLANDSMK MACEDONIA, THE FORMER YUGOSLAV REPUBLIC OFML MALIMM MYANMARMN MONGOLIAMO MACAOMP NORTHERN MARIANA ISLANDSMQ MARTINIQUEMR MAURITANIAMS MONTSERRATMT MALTAMU MAURITIUSMV MALDIVESMW MALAWIMX MEXICOMY MALAYSIAMZ MOZAMBIQUENA NAMIBIANC NEW CALEDONIANE NIGERNF NORFOLK ISLANDNG NIGERIANI NICARAGUANL NETHERLANDSNO NORWAYNP NEPALNR NAURUNU NIUENZ NEW ZEALANDOM OMANPA PANAMAPE PERUPF FRENCH POLYNESIAPG PAPUA NEW GUINEAPH PHILIPPINESPK PAKISTANPL POLANDPM SAINT PIERRE AND MIQUELONPN PITCAIRNPR PUERTO RICOPS PALESTINE, STATE OFPT PORTUGALPW PALAUPY PARAGUAYQA QATARRE REUNION



75

Code DescriptionRO ROMANIARS SERBIARU RUSSIAN FEDERATIONRW RWANDASA SAUDI ARABIASB SOLOMON ISLANDSSC SEYCHELLESSD SUDANSE SWEDENSG SINGAPORESH SAINT HELENA, ASCENSION AND TRISTAN DA CUNHASI SLOVENIASJ SVALBARD AND JAN MAYENSK SLOVAKIASL SIERRA LEONESM SAN MARINOSN SENEGALSO SOMALIASR SURINAMESS SOUTH SUDANST SAO TOME AND PRINCIPESV EL SALVADORSX SINT MAARTEN (DUTCH PART)SY SYRIAN ARAB REPUBLICSZ SWAZILANDTC TURKS AND CAICOS ISLANDSTD CHADTF FRENCH SOUTHERN TERRITORIESTG TOGOTH THAILANDTJ TAJIKISTANTK TOKELAUTL TIMOR-LESTETM TURKMENISTANTN TUNISIATO TONGATR TURKEYTT TRINIDAD AND TOBAGOTV TUVALUTW TAIWANTZ TANZANIA, UNITED REPUBLIC OFUA UKRAINEUG UGANDAUM UNITED STATES MINOR OUTLYING ISLANDSUS UNITED STATESUY URUGUAYUZ UZBEKISTANVA HOLY SEE (VATICAN CITY STATE)VC SAINT VINCENT AND THE GRENADINESVE VENEZUELA, BOLIVARIAN REPUBLIC OFVG VIRGIN ISLANDS, BRITISHVI VIRGIN ISLANDS, U.S.VN VIET NAM



76

Code DescriptionVU VANUATUWF WALLIS AND FUTUNAWS SAMOAYE YEMENYT MAYOTTEZA SOUTH AFRICAZM ZAMBIAZW ZIMBABWE



77

ISO 4217 Alpha 3 – Currency CodesCode DescriptionAED UAE Dirham: UNITED ARAB EMIRATESAFN Afghani: AFGHANISTANALL Lek: ALBANIAAMD Armenian Dram: ARMENIAANG Netherlands Antillean Guilder: CURACAO; SINT MAARTEN (DUTCH PART)AOA Kwanza: ANGOLAARS Argentine Peso: ARGENTINAAUD Australian Dollar: AUSTRALIA; CHRISTMAS ISLAND; COCOS (KEELING) ISLANDS;

HEARD ISLAND AND McDONALD ISLANDS; KIRIBATI; NAURU; NORFOLK ISLAND; TUVALU

AWG Aruban Florin: ARUBAAZN Azerbaijanian Manat: AZERBAIJANBAM Convertible Mark: BOSNIA AND HERZEGOVINABBD Barbados Dollar: BARBADOSBDT Taka: BANGLADESHBGN Bulgarian Lev: BULGARIABHD Bahraini Dinar: BAHRAINBIF Burundi Franc: BURUNDIBMD Bermudian Dollar: BERMUDABND Brunei Dollar: BRUNEI DARUSSALAMBOB Boliviano: BOLIVIA, PLURINATIONAL STATE OFBOV Mvdol: BOLIVIA, PLURINATIONAL STATE OFBRL Brazilian Real: BRAZILBSD Bahamian Dollar: BAHAMASBTN Ngultrum: BHUTANBWP Pula: BOTSWANABYR Belarussian Ruble: BELARUSBZD Belize Dollar: BELIZECAD Canadian Dollar: CANADACDF Congolese Franc: CONGO, THE DEMOCRATIC REPUBLIC OFCHE WIR Euro: SWITZERLANDCHF Swiss Franc: LIECHTENSTEIN; SWITZERLANDCHW WIR Franc: SWITZERLANDCLF Unidades de fomento: CHILECLP Chilean Peso: CHILECNY Yuan Renminbi: CHINACOP Colombian Peso: COLOMBIACOU Unidad de Valor Real: COLOMBIACRC Costa Rican Colon: COSTA RICACUC Peso Convertible: CUBACUP Cuban Peso: CUBACVE Cape Verde Escudo: CAPE VERDECZK Czech Koruna: CZECH REPUBLICDJF Djibouti Franc: DJIBOUTIDKK Danish Krone: DENMARK; FAROE ISLANDS; GREENLANDDOP Dominican Peso: DOMINICAN REPUBLICDZD Algerian Dinar: ALGERIAEGP Egyptian Pound: EGYPTERN Nakfa: ERITREAETB Ethiopian Birr: ETHIOPIA



78

Code DescriptionEUR Euro: ALAND ISLANDS; ANDORRA; AUSTRIA; BELGIUM; CYPRUS; ESTONIA;

EUROPEAN UNION; FINLAND; FRANCE; FRENCH GUIANA; FRENCH SOUTHERN TERRITORIES; GERMANY; GREECE; GUADELOUPE; HOLY SEE (VATICAN CITY STATE); IRELAND; ITALY; LUXEMBOURG; MALTA; MARTINIQUE; MAYOTTE; MONACO; MONTENEGRO; NETHERLANDS; PORTUGAL; REUNION; SAINT BARTHELEMY; SAINT MARTIN (FRENCH PART); SAINT PIERRE AND MIQUELON; SAN MARINO; SLOVAKIA; SLOVENIA; SPAIN; Vatican City State (HOLY SEE)

FJD Fiji Dollar: FIJIFKP Falkland Islands Pound: FALKLAND ISLANDS (MALVINAS)GBP Pound Sterling: GUERNSEY; ISLE OF MAN; JERSEY; UNITED KINGDOMGEL Lari: GEORGIAGHS Ghana Cedi: GHANAGIP Gibraltar Pound: GIBRALTARGMD Dalasi: GAMBIAGNF Guinea Franc: GUINEAGTQ Quetzal: GUATEMALAGYD Guyana Dollar: GUYANAHKD Hong Kong Dollar: HONG KONGHNL Lempira: HONDURASHRK Croatian Kuna: CROATIAHTG Gourde: HAITIHUF Forint: HUNGARYIDR Rupiah: INDONESIAILS New Israeli Sheqel: ISRAELINR Indian Rupee: BHUTAN; INDIAIQD Iraqi Dinar: IRAQIRR Iranian Rial: IRAN, ISLAMIC REPUBLIC OFISK Iceland Krona: ICELANDJMD Jamaican Dollar: JAMAICAJOD Jordanian Dinar: JORDANJPY Yen: JAPANKES Kenyan Shilling: KENYAKGS Som: KYRGYZSTANKHR Riel: CAMBODIAKMF Comoro Franc: COMOROSKPW North Korean Won: KOREA, DEMOCRATIC PEOPLE’S REPUBLIC OFKRW Won: KOREA, REPUBLIC OFKWD Kuwaiti Dinar: KUWAITKYD Cayman Islands Dollar: CAYMAN ISLANDSKZT Tenge: KAZAKHSTANLAK Kip: LAO PEOPLE’S DEMOCRATIC REPUBLICLBP Lebanese Pound: LEBANONLKR Sri Lanka Rupee: SRI LANKALRD Liberian Dollar: LIBERIALSL Loti: LESOTHOLTL Lithuanian Litas: LITHUANIALVL Latvian Lats: LATVIALYD Libyan Dinar: LIBYAMAD Moroccan Dirham: MOROCCO; WESTERN SAHARAMDL Moldovan Leu: MOLDOVA, REPUBLIC OFMGA Malagasy Ariary: MADAGASCARMKD Denar: MACEDONIA, THE FORMER YUGOSLAV REPUBLIC OFMMK Kyat: MYANMAR



79

Code DescriptionMNT Tugrik: MONGOLIAMOP Pataca: MACAOMRO Ouguiya: MAURITANIAMUR Mauritius Rupee: MAURITIUSMVR Rufiyaa: MALDIVESMWK Kwacha: MALAWIMXN Mexican Peso: MEXICOMXV Mexican Unidad de Inversion (UDI): MEXICOMYR Malaysian Ringgit: MALAYSIAMZN Mozambique Metical: MOZAMBIQUENAD Namibia Dollar: NAMIBIANGN Naira: NIGERIANIO Cordoba Oro: NICARAGUANOK Norwegian Krone: BOUVET ISLAND; NORWAY; SVALBARD AND JAN MAYENNPR Nepalese Rupee: NEPALNZD New Zealand Dollar: COOK ISLANDS; NEW ZEALAND; NIUE; PITCAIRN; TOKELAUOMR Rial Omani: OMANPAB Balboa: PANAMAPEN Nuevo Sol: PERUPGK Kina: PAPUA NEW GUINEAPHP Philippine Peso: PHILIPPINESPKR Pakistan Rupee: PAKISTANPLN Zloty: POLANDPYG Guarani: PARAGUAYQAR Qatari Rial: QATARRON New Romanian Leu: ROMANIARSD Serbian Dinar: SERBIARUB Russian Ruble: RUSSIAN FEDERATIONRWF Rwanda Franc: RWANDASAR Saudi Riyal: SAUDI ARABIASBD Solomon Islands Dollar: SOLOMON ISLANDSSCR Seychelles Rupee: SEYCHELLESSDG Sudanese Pound: SUDANSEK Swedish Krona: SWEDENSGD Singapore Dollar: SINGAPORESHP Saint Helena Pound: SAINT HELENA, ASCENSION AND TRISTAN DA CUNHASLL Leone: SIERRA LEONESOS Somali Shilling: SOMALIASRD Surinam Dollar: SURINAMESSP South Sudanese Pound: SOUTH SUDANSTD Dobra: SAO TOME AND PRINCIPESVC El Salvador Colon: EL SALVADORSYP Syrian Pound: SYRIAN ARAB REPUBLICSZL Lilangeni: SWAZILANDTHB Baht: THAILANDTJS Somoni: TAJIKISTANTMT Turkmenistan New Manat: TURKMENISTANTND Tunisian Dinar: TUNISIATOP Pa’anga: TONGATRY Turkish Lira: TURKEYTTD Trinidad and Tobago Dollar: TRINIDAD AND TOBAGOTWD New Taiwan Dollar: TAIWANTZS Tanzanian Shilling: TANZANIA, UNITED REPUBLIC OF



80

Code DescriptionUAH Hryvnia: UKRAINEUGX Uganda Shilling: UGANDAUSD US Dollar: AMERICAN SAMOA; BONAIRE; SINT EUSTATIUS AND SABA; BRITISH

INDIAN OCEAN TERRITORY; ECUADOR; EL SALVADOR; GUAM; HAITI; MARSHALL ISLANDS; MICRONESIA, FEDERATED STATES OF; NORTHERN MARIANA ISLANDS; PALAU; PANAMA; PUERTO RICO; TIMOR-LESTE; TURKS AND CAICOS ISLANDS, UNITED STATES; UNITED STATES MINOR OUTLYING ISLANDS; VIRGIN ISLANDS (BRITISH); VIRGIN ISLANDS (US)

USN US Dollar (Next day): UNITED STATESUSS US Dollar (Same day): UNITED STATESUYI Uruguay Peso en Unidades Indexadas (URUIURUI): URUGUAYUYU Peso Uruguayo: URUGUAYUZS Uzbekistan Sum: UZBEKISTANVEF Bolivar: VENEZUELA, BOLIVARIAN REPUBLIC OFVND Dong: VIET NAMVUV Vatu: VANUATUWST Tala: SAMOAXAF CFA Franc BEAC: CAMEROON; CENTRAL AFRICAN REPUBLIC; CHAD; CONGO;

EQUATORIAL GUINEA; GABONXAG Silver: ZZ11_SilverXAU Gold: ZZ08_GoldXBA Bond Markets Unit European Composite Unit (EURCO): ZZ01_Bond Markets

Unit European_EURCOXBB Bond Markets Unit European Monetary Unit (E.M.U.-6): ZZ02_Bond Markets

Unit European_EMU-6XBC Bond Markets Unit European Unit of Account 9 (E.U.A.-9): ZZ03_Bond Markets

Unit European_EUA-9XBD Bond Markets Unit European Unit of Account 17 (E.U.A.-17): ZZ04_Bond

Markets Unit European_EUA-17XCD East Caribbean Dollar: ANGUILLA; ANTIGUA AND BARBUDA; DOMINICA;

GRENADA; MONTSERRAT; SAINT KITTS AND NEVIS; SAINT LUCIA; SAINT VINCENT AND THE GRENADINES

XDR SDR (Special Drawing Right): INTERNATIONAL MONETARY FUND (IMF)XFU UIC-Franc: ZZ05_UIC-FrancXOF CFA Franc BCEAO: BENIN; BURKINA FASO; COTE D'IVOIRE; GUINEA-BISSAU;

MALI; NIGER; SENEGAL; TOGOXPD Palladium: ZZ09_PalladiumXPF CFP Franc: FRENCH POLYNESIA; NEW CALEDONIA; WALLIS AND FUTUNAXPT Platinum: ZZ10_PlatinumXSU Sucre: SISTEMA UNITARIO DE COMPENSACION REGIONAL DE PAGOS "SUCRE"XUA ADB Unit of Account: MEMBER COUNTRIES OF THE AFRICAN DEVELOPMENT

BANK GROUPXXX The codes assigned for transactions where no currency is involved:

ZZ07_No_CurrencyYER Yemeni Rial: YEMENZAR Rand: LESOTHO; NAMIBIA; SOUTH AFRICAZMW Zambian Kwacha: ZAMBIAZWL Zimbabwe Dollar: ZIMBABWE



81

Annex C – errors within an UK FATCA message

Incorrect FATCA ID (FATCAUserId)It is important that you use the FATCA ID that has been issued to you within your submission. If the FATCA ID you use in the tag FATCAUserIddoes not appear in our registration database then your submission willerror.

Using an already existing MessageRefThe MessageRef data item in: /UKFATCASubmissionFIReport/Submission/MessageRefmust be globally unique. This means if you submit the same MessageRef for different messages then it will error.

Future dated Reporting PeriodThe ReportPeriod data cannot be future dated i.e. if the current year was 2017 then you could not use 2018-12-31. If you do submit a future dated reporting period your submission will error.

Wrong ReplacedMessageRef when replacing messagesIf we cannot find the message reference identified by your ReplacedMessageRef data your replacement submission will error.

Wrong MessageRef when voiding messagesIf we cannot find the message reference identified by your /UKFATCASubmissionFIReport/VoidSubmission/MessageRef data your void submission will error.

Supplying an invalid Registration Identification NumberIf your submission includes a Registration Identification number (FIRegisterId) that either isn’t in our registration data or is not part of your FI registration group (if you are an agent for many FIs) then your submission will error.

Inconsistent FIReturnRefIf either:

You supply a new FI with an already existing FIReturnRef or; you want to vary an existing FI and the FIReturnRef doesn’t

exist in our database or; when varying you have a FIReturnRef that is in our database

but not one that you originally created

then the submission will error.



82

Wrong VoidRef when voiding a FI Return or an AccountData datasetThe FIReturnRef of the FI Return you are attempting to void should exist in our database and should have originally been submitted by thesame FATCA ID as you have for this message.

Similarly in the case of an AccountData void the AccountRef should exist and have been submitted by the same FATCA ID and have the same ‘parent’ FIReturnRef as it did originally.

If this is not the case the submission will error.

Inconsistent AccountRefIf either:

You supply a new Account with an already existing AccountRef or;

you want to vary an existing Account and the AccountRef doesn’t exist in our database or;

when varying you have an AccountRef that is in our database but not one that you originally created

then the submission will error.

Pool Report errorsUnless you are a Bermudian Financial Institution you should not be completing the Pool Report section of the XML message. Doing so will mean that your data will NOT be sent to the IRS.

For Bermudian FIs the following would be erroneous:

You supply a new Pool Report with an already existing PoolReportRef or;

you want to vary an existing Pool Report and the PoolReportRefdoesn’t exist in our database

You try to void a Pool Report using a PoolReportRef that doesn’t exist in our database or one that does exist but was submitted by a different FATCA ID.

Amending successfully submitted dataIf you use an action of ‘New’ in your submission variation we expect that data to be added to the existing parent not to amend an already existing ‘child’ dataset. See Table 1 for details of valid combinations of message categories and actions.



83

Changing an AccountType for an account holderIf, due to an error, you need to change the Account Holder Type from say Organisation to Individual it is best to first void that account and add it in again with the correct dataset. Otherwise using the action of ‘Variation’ without voiding the account first could corrupt the data dueto some organisation data remaining in our database for that account.

Duplicate Controlling PeoplePlease ensure that where an organisation or company has controlling people with duplicate entries for their first and last name that you add something to differentiate them. E.g. if you have only the first initial in the FirstName element and the controlling people are named Ben Brown and Belinda Brown then either write the name out in full for the first name or perhaps add a middle initial for one of the people in the FirstName element.



84

Table 1: Message Category and Actions: validity, depending on context

NewSubmission SubmissionVariation SubmissionReplacement SubmissionVoid

Valid elements Invalid elements Valid elements Invalid elements Valid elements Invalid elements

ACT

ION

New

FIReturnNilReturnAccountDataPoolReport

MessageRef

VoidFIReturnVoidAccountDataVoidPoolReportReplacementNoVariation


MessageRef



Replacement

VoidFIReturnVoidAccountDataVoidPoolReportMessageRefNoVariation

No Action applies to thismessage category as only the VoidSubmission element should be completed.

Replacement Not a valid combination.

FIReturnNilReturnAccountDataPoolReportMessageRef


Not a valid combination.

Variation Not a valid combination.

FIReturnNilReturnAccountDataPoolReport VoidFIReturnVoidAccountDataVoidPoolReportNoVariation

Not a valid combination.

valid only for Bermudian Financial Institution



Table 2: FI Return Actions and their effect on AccountData validity

FI Return: New FI Return: Variation FI Return: Replacement

Acc

ount

Dat

a A

ctio

n

New Valid Valid Valid

Replacement Not a valid combination. Valid Not a valid combination.

Variation Not a valid combination. Valid Not a valid combination.



86

Table 3: FI Return Actions and their effect on PoolReport validity

FI Return: New FI Return: Variation FI Return: ReplacementPo

olRe

port

Act

ion

New Valid Valid Valid

Replacement Not a valid combination. Valid Not a valid combination.

Variation Not a valid combination. Valid Not a valid combination.



87

Annex D – Terminology

Name in HMRC Portal Name in HMRC schema DescriptionFATCA ID FATCAUserId 10 digit unique identifier of the user of the HMRC

Portal for registering and submitting returns.Registration Identification Number

FIRegisterId 13 character unique identifier of the Financial Institution for that particular FATCA service user.



88

Documents

Schema uk fatca submission MasterFile€¦ · A schema is a data structure for holding and transmitting information electronically and in bulk. XML ‘extensible markup language’