Source document: https://docs-lawep.s3.us-east-2.amazonaws.com/1697641826766.pdf (Antigua and Barbuda)
CRS XML user guide OECD CRS XML version 2.0 March 2022 Document version 1.0 PUBLIC Important Notes 1 Important notes before creating the CRS XML file CRS XML Schema 2 CRS XML Schema (OECD) 2.1 2.2 Abbreviations and acronyms CRS XML user guide (OECD) ©2022 BearingPoint Caribbean.

All rights reserved.


PUBLIC Multi Data Exchange Solution -CRS XML user guide | Final version 1.0 2 Important Notes 1 Important notes before creating the CRS XML file To create the correct CRS XML file, use the below statement for the XML header.
<crs:CRS_OECD xmlns:crs="urn:oecd:ties:crs:v2" xmlns:cfc="urn:oecd:ties:commontypesfatcacrs:v2" xmlns:ftc="urn:oecd:ties:fatca:v1" xmlns:iso="urn:oecd:ties:isocrstypes:v1" xmlns:stf="urn:oecd:ties:crsstf:v5" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="2.0" xsi:schemaLocation="urn:oecd:ties:crs:v1 CrsXML_v2.0.xsd"> The above statement should be placed directly above the <crs:MessageSpec> element.

The XML will look like below figure 1.


Figure 1-1 Example CRS XML file ©2022 BearingPoint Caribbean.

All rights reserved.

RESTRICTED Multi Data Exchange Solution - FATCA CRS User Guide | Final version 1.1 4 CRS XML Schema 2 CRS XML Schema (OECD) OECD CRS XML Schema.

Name Source & link https://www.oecd.org/tax/automatic-exchange/common-reporting-standard Remarks Consult the OECD CRS website to obtain more information and the relevant XSD files.
2.1 Abbreviations and acronyms CRS CRS MCAA CTS FATCA FI OECD Common Reporting Standard CRS Multilateral Competent Authority Agreement Common Transmission System Foreign Account Tax Compliance Act Financial Institution Organisation for Economic Co-operation and Development 2.2 CRS XML user guide (OECD) ©2022 BearingPoint Caribbean.

All rights reserved.

PUBLIC Multi Data Exchange Solution – CRS XML user guide | Final version 1.0 8 ANNEX 3.
COMMON REPORTING STANDARD USER GUIDE – 9 Annex 3 Common Reporting Standard User Guide Version 3.0 (CRS schema version 2.0) Introduction The OECD working with G20 countries has developed a common standard on reporting, due diligence and exchange of financial account information.
Under this common standard, jurisdictions obtain from reporting financial institutions and automatically exchange with exchange partners, as appropriate, on an annual basis financial information with respect to all reportable accounts, identified by financial institutions on the basis of common reporting and due diligence rules.

Part of the technical solution to support this common standard is a schema and related instructions.
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.

Examples are the OECD’s Standard Transmission Format “STF” or the Fisc 153 format used for information exchange for the European Savings Directive.

This User Guide explains the information required to be included in each CRS data element to be reported in the CRS XML Schema v2.0.
It also contains guidance on how to make corrections of data items within a file that can be processed automatically.

How the CRS User Guide links to the CRS Schema This User Guide is divided into logical sections based on the schema and provides information on specific data elements and any attributes that describe that data element.

The CRS Schema Information sections are I.

Message Header with the sender, recipient, message type, reporting period II.
Controlling Person or Account Holder details if an individual III.

Account Holder if an entity Iv.

Iv CRS Body; Reporting FI and Reporting Group and Account details The numbers of the sections are reflected in the numbering of the diagrams in Appendix A.

COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 10 – ANNEX 3.

COMMON REPORTING STANDARD USER GUIDE The CRS XML Schema is designed to be used for the automatic exchange of financial account information between Competent Authorities (“CAs”).
In addition the CRS could also be used for domestic reporting by Financial Institutions (“FIs”) to domestic tax authorities under the CRS.

Items relevant for domestic reporting only are shown in [brackets].

The CRS schema is re-using the FATCA schema and elements of STF, so there are some elements in the CRS schema that are not required for purposes of reporting and exchange under the CRS (e.g.

Pool Report and Nationality).

These elements are shown in the User Guide as optional, followed by “non-CRS”.
The comment “non-CRS” is also shown on the Appendix A diagrams where relevant.

The CRS XML Schema and its User Guide provide for elements that are unique to CRS e.g.

undocumented and closed accounts.

The requirement field for each data element and its attribute indicates whether the element is validation or optional in the schema.

Every element is one or the other in the schema.

“validation” elements MUST be present for ALL data records in a file and an automated validation check can be undertaken.
The Sender should do a technical check of the data file content using XML tools to make sure all “validation” elements are present and if they are not, correct the file.

The Receiver may also do so and if incorrect, may reject the file.

where there is a choice between 2 validation elements under a validation parent and only one is needed, this is shown as “validation (choice)”.

If the elements are under an optional parent, they are shown as optional.
There may be different business rules for elements that are optional in the schema: • Some optional fields are shown as “(Optional) Mandatory” – an optional element that is required for CRS reporting as specified in CRS reporting requirements depending on availability of information or legal factors.

Mandatory elements may be present in most (but not all) circumstances, so there cannot be a simple IT validation process to check these.

(E.g.
(E.g.

the CRS provides that a reporting FI is required to report the TIN of an Account Holder only if issued by his jurisdiction of residence/place of birth only if otherwise required to retain and report and is held in electronically searchable records).

• Optional elements may represent a choice between one type or another, where one of them must be used (e.g.

choice between address fix or address free).

Shown as “Optional” requirement.


• The element may not be required for either schema validation or CRS.

It should not be reported in a CRS only file as indicated by “Optional (non CRS)”.

Appendix A to the CRS User Guide shows a diagrammatic representation of the CRS XML Schema with all its elements.

The numbers next to the headings are the corresponding section numbers in the User Guide text.

Appendix B to the CRS User Guide contains a Glossary of namespaces for the CRS XML Schema.
COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 ANNEX 3.

COMMON REPORTING STANDARD USER GUIDE – 11 Common Reporting Standard Schema Information I.

Message Header Information in the message header identifies the tax administration that is sending the message.

It specifies when the message was created, what period (normally a year) the report is for, and the nature of the report (original, corrected, supplemental, etc.).
Element Attribute Size Input Type Requirement SendingCompanyIN 1 to 200 characters stf:StringMin1Max200_Type Optional [Although not used for exchange between Competent Authorities under CRS, for domestic reporting the Sending Company Identification Number element would be Mandatory and would identify the Financial Institution reporting to the Sending tax authority by domestic TIN (or IN).]
Element Attribute Size Input Type Requirement TransmittingCountry 2-character iso:CountryCode_Type Validation This data element identifies the jurisdiction where the reported financial account is maintained or where the reported payment is made by the reporting FI.

If the sender is a tax administration, the transmitting country is the jurisdiction of the tax administration.

This data element uses the 2-character alphabetic country code and country name list1 based on the ISO 3166-1 Alpha 2 standard.
[For domestic reporting this element would be the domestic Country Code.]

Element Attribute Size Input Type Requirement ReceivingCountry 2-character iso:CountryCode_Type Validation This data element identifies the jurisdiction of the tax administration (the Competent Authority) that is the intended recipient of the message.

This data element uses the 2-character alphabetic country code based on the ISO 3166-1 Alpha 2 standard.

[For domestic reporting this element would be the domestic Country Code.]
Element MessageType Attribute Size Input Type Requirement crs:MessageType_EnumType Validation This data element specifies the type of message being sent.

The only allowable entry in this field for CRS AEOI is “CRS”.

Element Warning Attribute Size Input Type Requirement 1 to 4’000 characters stf:StringMin1Max4000_Type Optional 1.
The following disclaimer refers to all uses of the ISO country code list in the CRS schema: For practical reasons, the list is based on the ISO 3166-1 country list which is currently used by banks and other financial institutions, and hence by tax administrations.

The use of this list does not imply the expression by the OECD of any opinion whatsoever concerning the legal status of the territories listed.
Its content is without prejudice to the status of or sovereignty over any territory, to the delimitation of international frontiers and boundaries and to the name of any territory, city or area.

COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 12 – ANNEX 3.
COMMON REPORTING STANDARD USER GUIDE This data element is a free text field allowing input of specific cautionary instructions about use of the CRS message content, for example terms of the Instrument or Convention under which the data is exchanged.

If the reported data is for a period other than for a full reporting year this information can be given here as narrative e.g.

“ten month period”.
“ten month period”.

Element Contact Attribute Size Input Type Requirement 1 to 4’000 characters stf:StringMin1Max4000_Type Optional This data element is a free text field allowing input of specific contact information for the sender of the message.

[May give FI or third party contact for domestic reporting only.]
Element Attribute Size Input Type Requirement MessageRefID 1 to 170 characters stf:StringMin1Max170_Type Validation This data element is a free text field capturing the sender’s unique message identifier (created by the sender) that identifies the particular message being sent.

The identifier allows both the sender and receiver to identify the specific message later if questions or corrections arise.
For exchanges between Competent Authorities, the first part must be the country code of the sending jurisdiction, the second part the year to which the data relates (which should ideally be the year in which the reporting period begins, but may also be the year in which it ends) and the third part the receiving country code, before a unique identifier created by the sending jurisdiction (the “national part”).
[If the CRS schema is used for domestic reporting, the FI could include an FI Identification Number in the MessageRefID at the start of the unique identifier created by the FI which is recommended as good practice.]

Element Attribute Size Input Type Requirement MessageTypeIndic crs:CrsMessageTypeIndic_EnumType Validation This data element allows the sender to define the type of message sent.

This element identifies whether data is new or corrected (see Guidance on the Correction Process below).
Messages must contain all new or all corrected/deleted data, or advise that there is no data to report.
The possible values are: • CRS701 = The message contains new information • CRS702 = The message contains corrections/deletions for previously sent information • CRS703 = The message advises there is no data to report [The MessageTypeIndic can be used domestically to indicate that the Financial Institution has carried out the appropriate checks of its client data but there is no data to report (a “nil return” in effect).
In such a case, the MessageTypeIndic will have the value CRS703, the Account Report (section IVc) will be omitted while the CrsBody and ReportingFI will be provided.]

The MessageTypeIndic can also be used between Competent Authorities to indicate that there is no data to report (a “nil return/zero data message” in effect).

In such a case, the MessageTypeIndic will have the value CRS703 and the CrsBody will be omitted.
This is the only case where the CrsBody can be omitted, in all other case the CrsBody must be provided.

COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 ANNEX 3.

COMMON REPORTING STANDARD USER GUIDE – 13 Element Attribute Size Input Type Requirement CorrMessageRefID 1 to 170 characters stf:StringMin1Max170_Type Optional (non CRS) This element is not to be used in the context of the CRS XML Schema.
Element Attribute Size ReportingPeriod Input Type xsd:date Requirement Validation This data element identifies the last day of the reporting period (normally a tax 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”.

If exceptionally the reporting period is not a year then show the length of the reporting period in warning.
Element Timestamp Attribute Size Input Type xsd:dateTime Requirement Validation This data element identifies the date and time when the message was compiled.

It is anticipated this element will be automatically populated by the host system.

The format for use is yyyy-MM-DD’T’hh:mm:ss.nnn.

Fractions of seconds may be used (in such a case the milliseconds will be provided in 3 digits, see “.nnn” in the format above).

Examples: 2015-03-15T09:45:30 or 2015-03-15T09:45:30.789 (with milliseconds).

II.
II.

PersonParty _Type The data elements in this section are used for Individual Account Holders or Controlling Persons of Passive NFEs.
This complex type is comprised of the following data elements: Element Attribute Size Input Type Requirement ResCountryCode 2-character iso:CountryCode_Type Validation Attribute Size Input Type Requirement 1 to 200 characters cfc:TIN_Type (Optional) Mandatory Element TIN Element Name Element Address Element Attribute crs:NamePerson_Type Attribute cfc:Address_Type Attribute Nationality iso:CountryCode_Type Element BirthInfo Attribute COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 Size Size Size Size Input Type Requirement Validation Input Type Requirement Validation Input Type Requirement Optional (Non CRS) Input Type Requirement (Optional) Mandatory 14 – ANNEX 3.
COMMON REPORTING STANDARD USER GUIDE IIa.

ResCountryCode Element Attribute Size Input Type Requirement ResCountryCode 2-character iso:CountryCode_Type Validation This data element describes the tax residence country code(s) for the individual being reported upon and must be present in all data records for CRS AEOI between Competent Authorities.
A separate report for each residence jurisdiction of the Reportable Person including Controlling Persons who are Reportable Persons is required, along with details of the Entity, if there is more than one jurisdiction of residence.

[For domestic reporting, if the individual is certified or treated as tax resident in more than one jurisdiction then this element may be repeated and the data should be sent to the tax authority.
It would also be advisable to mandate the use of the domestic country code for undocumented accounts, which will not be exchanged between Competent Authorities.]

The complete information including all residence country codes that have been identified as applicable to the Reportable Person may be sent to every Competent Authority of a jurisdiction of residence so that there is an awareness of the possible need to resolve dual residence status or other issues attached to multiple reporting.
It is recommended that the Competent Authority send a data record to each of the residence jurisdictions showing all reportable residence jurisdictions.

Alternatively, in certain circumstances the sending jurisdiction may choose to send data with only the residence country code of the receiving jurisdiction to each and may use a different method to exchange information relevant to multiple residence jurisdictions in accordance with the applicable legal instrument(s) if and when required.

IIb.
IIb.

TIN Type Element TIN Attribute Size Input Type Requirement 1 to 200 characters cfc:TIN_Type (Optional) Mandatory This data element identifies the Tax Identification Number (TIN) used by the receiving tax administration to identify the Individual Account Holder.

The TIN (if available) should be supplied as specified in the CRS.
Element TIN Attribute issuedBy Size Input Type Requirement 2-character iso:CountryCode_Type (Optional) Mandatory This attribute identifies the jurisdiction that issued the TIN.

If the issuing jurisdiction is not known then this may be left blank.

IIc.

NamePerson_Type Element NamePerson_Type Attribute nameType Size Input Type Requirement stf:OECDNameType_EnumType Optional This data element allows the FI to report both the name at birth and the name after marriage.
COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 ANNEX 3.

COMMON REPORTING STANDARD USER GUIDE – 15 OECDNameType_EnumType It is possible for a CRS individual or entity to have several names.

This is a qualifier to indicate the type of a particular name.

Such types include nicknames (“nick”), names under which a party does business (“dba” a short name for the entity, or a name that is used for public acquaintance instead of the official business name) etc.
The possible values are: • OECD201 = SMFAliasOrOther (not used for CRS) • OECD202 = indiv • OECD203 = alias • OECD204 = nick • OECD205 = aka • OECD206 = dba • OECD207 = legal • OECD208 = atbirth Element Attribute Size Input Type Requirement PrecedingTitle 1 to 200 characters stf:StringMin1Max200_Type Optional Element Title Element FirstName Attribute Size Input Type Requirement 1 to 200 characters stf:StringMin1Max200_Type Optional Attribute Size Input Type Requirement 1 to 200 characters stf:StringMin1Max200_Type Validation This data element is required for CRS reporting.
If the reporting FI or tax administration transmitting the message does not have a complete first name for an Individual Account Holder or Controlling Person an initial or NFN (“No First Name”) may be used here.

Element FirstName Element MiddleName Attribute Size Input Type Requirement xnlNameType 1 to 200 characters stf:StringMin1Max200_Type Optional Attribute Size Input Type Requirement 1 to 200 characters stf:StringMin1Max200_Type Optional This data element allows for the Individual’s Middle Name.
The data is optional for CRS reporting; if the Reporting FI holds a Middle Name or initial it may be included here.
Element Attribute Size Input Type Requirement MiddleName xnlNameType 1 to 200 characters stf:StringMin1Max200_Type Optional Element NamePrefix Element NamePrefix Element LastName Attribute Size Input Type Requirement 1 to 200 characters stf:StringMin1Max200_Type Optional Attribute Size Input Type Requirement xnlNameType 1 to 200 characters stf:StringMin1Max200_Type Optional Attribute Size Input Type Requirement 1 to 200 characters stf:StringMin1Max200_Type Validation COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 16 – ANNEX 3.
COMMON REPORTING STANDARD USER GUIDE This data element is required for CRS reporting.

The reporting FI or tax administration transmitting the message must provide the Individual Account Holder’s last name.

This field can include any prefix or suffix legally used by the Account Holder.

As the element is a string it is possible to use this for a free format name or two last names although wherever possible the structured first name and last name should be used.
Element LastName Attribute Size Input Type Requirement xnlNameType 1 to 200 characters stf:StringMin1Max200_Type Optional Element Attribute Size Input Type Requirement GenerationIdentifier 1 to 200 characters stf:StringMin1Max200_Type Optional Element Suffix Element Attribute Size Input Type Requirement 1 to 200 characters stf:StringMin1Max200_Type Optional Attribute Size Input Type Requirement GeneralSuffix 1 to 200 characters stf:StringMin1Max200_Type Optional IId.
Address_Type There are two options for Address type in the schema – AddressFix and AddressFree.

AddressFix should be used for all CRS reporting unless the reporting FI or tax administration transmitting the message cannot define the various parts of the account holder’s address.

This data element is the permanent residence address e.g.

of the individual account holder.


If the reporting FI or tax administration does 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.

Element CountryCode Attribute Size Input Type Requirement 2-character iso:CountryCode_Type Validation This data element provides the country code associated with the account holder’s address.
[For undocumented accounts the domestic country code will be used as no address is available.

As the address requires another data item to be completed then “undocumented” could be used instead of an actual address.]

Element AddressFree Attribute Size Input Type Requirement 1 to 4’000 characters stf:StringMin1Max4000_Type Optional* This data element allows input of address information in free text.
If the user chooses the option to enter the data required in a less structured way in “AddressFree” all available address details shall be presented as one string of bytes, blank or “/” (slash) or carriage return-line feed used as a delimiter between parts of the address.

*This option should only be used if the data cannot be presented in the AddressFix format.
NOTE: If the reporting FI or tax administration transmitting the message selects AddressFix, it will have the option of inputting the full street address of the account holder in the AddressFree element rather than using the related fixed elements.

In this case, the city, subentity, and postal code information should still be entered in the appropriate fixed elements.

COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 ANNEX 3.
COMMON REPORTING STANDARD USER GUIDE – 17 Element Attribute Size Input Type Requirement AddressType legalAddressType stf:OECDLegalAddressType_EnumType Optional OECDLegalAddressType_EnumType This is a datatype for an attribute to an address.

It serves to indicate the legal character of that address (residential, business etc.)
The possible values are: • OECD301 = residentialOrBusiness • OECD302 = residential • OECD303 = business • OECD304 = registeredOffice • OECD305 = unspecified Element Street Element Attribute Size Input Type Requirement 1 to 200 characters stf:StringMin1Max200_Type Optional Attribute Size Input Type Requirement BuildingIdentifier 1 to 200 characters stf:StringMin1Max200_Type Optional Element SuiteIdentifier Element FloorIdentifier Element DistrictName Element POB Element PostCode Element City Element Attribute Size Input Type Requirement 1 to 200 characters stf:StringMin1Max200_Type Optional Attribute Size Input Type Requirement 1 to 200 characters stf:StringMin1Max200_Type Optional Attribute Size Input Type Requirement 1 to 200 characters stf:StringMin1Max200_Type Optional Attribute Size Input Type Requirement 1 to 200 characters stf:StringMin1Max200_Type Optional Attribute Size Input Type Requirement 1 to 200 characters stf:StringMin1Max200_Type Optional Attribute Size Input Type Requirement 1 to 200 characters stf:StringMin1Max200_Type Validation Attribute Size Input Type Requirement CountrySubentity 1 to 200 characters stf:StringMin1Max200_Type Optional The above data elements comprise the AddressFix type.
The “City” data element is required for schema validation.

The PostCode should always be included where it exists.

Information pertaining to the account holder’s street address may be entered here or in the AddressFree data element.

COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 18 – ANNEX 3.

COMMON REPORTING STANDARD USER GUIDE IIe.


Nationality Element Nationality Attribute Size Input Type Requirement 2-character iso:CountryCode_Type Optional (non-CRS) This data element is not required for CRS and should not be completed.

IIf.

BirthInfo Element BirthDate Attribute Size Input Type xsd:date Requirement (Optional) Mandatory This data element identifies the date of birth of the Individual Account Holder.
The date of birth may be left empty when it is not required to be reported under the CRS (this may occur for Pre-existing Accounts if the date of birth is not available in the records of the Reporting Financial Institution and is not otherwise required to be collected by such Reporting Financial Institution under domestic law).

The data format is yyyy-MM-DD.


The three data elements below apply specifically to the place of birth and may be provided in accordance with CRS guidance where the financial institution is required to obtain and report the information under domestic law, and it is available in its electronically searchable records.
Element City Element CitySubentity Element CountryInfo Attribute Size Input Type Requirement 1 to 200 characters stf:StringMin1Max200_Type Optional Attribute Size Input Type Requirement 1 to 200 characters stf:StringMin1Max200_Type Optional Attribute Size Input Type Requirement Optional This data element gives a choice between a current jurisdiction (identified by 2-character country code) or a former jurisdiction (identified by name).
One or other should be supplied if place of birth is reported, together with City or City and CitySubentity.

Element CountryCode Attribute Size Input Type Requirement 2-character iso:CountryCode_Type Optional Element Attribute Size Input Type Requirement FormerCountryName 1 to 200 characters stf:StringMin1Max200_Type Optional COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 ANNEX 3.

COMMON REPORTING STANDARD USER GUIDE – 19 III.


OrganisationParty _Type This complex type identifies the name of an Account Holder that is an Entity as opposed to an Individual.
It is comprised of the following four data elements: Element Attribute Size Input Type Requirement ResCountryCode 2-character iso:CountryCode_Type (Optional) Mandatory Element IN Element Name Element Address Attribute Size Input Type Requirement 1 to 200 characters crs: OrganisationIN_Type (Optional) Mandatory Attribute Size Input Type Requirement 1 to 200 characters cfc:NameOrganisation_Type Validation Attribute Size Input Type Requirement cfc:Address_Type Validation IIIa.
ResCountryCode Element Attribute Size Input Type Requirement ResCountryCode 2-character iso:CountryCode_Type (Optional) Mandatory This data element describes the tax residence country code for the organisation reporting or being reported upon.

IIIb.
IIIb.

Entity IN (OrganisationIN_Type) Element IN Attribute Size Input Type Requirement 1 to 200 characters crs: OrganisationIN_Type (Optional) Mandatory This data element provides the identification number (IN) used by the sending and/or receiving tax administration to identify the Entity Account Holder.

For CRS this may be the US GIIN, a TIN, company registration number, Global Entity Identification Number (EIN) or other similar identifying number specified by the tax administration.
This data element can be repeated if a second IN is present.

Element IN Attribute issuedBy Size Input Type Requirement 2-character iso:CountryCode_Type Optional This attribute describes the jurisdiction that issued the IN.

If the issuing jurisdiction is not known then this may be left blank.

Element IN Attribute INType Size Input Type Requirement 1 to 200 character stf:StringMin1Max200_Type Optional This Attribute defines the type of identification number being sent (e.g.

US GIIN, EIN, TIN).
US GIIN, EIN, TIN).

Possible values should normally be agreed between Competent Authorities.

COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 20 – ANNEX 3.

COMMON REPORTING STANDARD USER GUIDE IIIc.

Organisation Name Element Name Attribute Size Input Type Requirement 1 to 200 characters cfc:NameOrganisation_Type Validation Legal name of the entity that is reporting or being reported on.

Element Name Attribute nameType Size Input Type Requirement stf:OECDNameType_EnumType Optional IV.
CRS Body Element CrsBody Attribute Size Input Type Requirement crs:CrsBody_Type (Optional) Mandatory The CRS body comprises the Reporting FI and Reporting Group elements.

The CrsBody can be omitted only when the MessageTypeIndic is CRS703 (Nil reporting) and the SendingCompanyIN is omitted, i.e.

only in the case of Nil reporting between Competent Authorities.

In all other case, the CrsBody must be provided.

IVa.
IVa.

Reporting FI Identifies the financial institution that maintains the reported financial account or that makes the reported payment.

Reporting FI or tax administration uses the OrganisationParty_Type to provide identifying information Element ReportingFI Element DocSpec Attribute Size Input Type Requirement crs:CorrectableOrganisationParty_Type Validation Attribute Size Input Type Requirement stf:DocSpec_Type Validation DocSpec identifies the particular report within the CRS message being transmitted.
It allows for identification of reports requiring correction (see also guidance on Corrections below).

IVb.

ReportingGroup This data element provides specific details about the CRS report being sent by the reporting FI or tax administration transmitting the message.

Although in the schema this element is repeatable, for CRS only one ReportingGroup for each CRSBody is to be provided.

The AccountReport should be repeated as required.


Element Attribute Size Input Type Requirement ReportingGroup crs:CorrectableOrganisationParty_Type Validation COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 ANNEX 3.
COMMON REPORTING STANDARD USER GUIDE – 21 The following four data elements comprise the Reporting Group: Element Sponsor Attribute Size Input Type Requirement crs:CorrectableOrganisationParty_Type Optional (non-CRS) where a Financial Institution uses a third party to submit information on their behalf for CRS this element is not used but contact details can be given in Element “Contact”.

Element Intermediary Attribute Size Input Type Requirement crs:CorrectableOrganisationParty_Type Optional (non-CRS) IVc.
Account Report Element Attribute Size Input Type Requirement AccountReport crs: CorrectableAccountReport_Type (Optional) Mandatory AccountReport is mandatory under CRS (except where the MessageTypeIndic CRS703 is used to indicate that there is no data to report).

In all other instances AccountReport must be completed.
AccountReport includes the following data elements under CorrectableAccoutReport_Type: Element DocSpec Attribute Size Input Type Requirement stf:DocSpec_Type Validation DocSpec identifies the particular report within the CRS message being transmitted.

It allows for identification of reports requiring correction.

See guidance on Corrections and a description of DocSpec Type.

IVd.
IVd.

Account Number Element Attribute Size Input Type Requirement AccountNumber 1 to 200 characters crs:FIAccountNumber_Type Validation Provide the account number used by the financial institution to identify the account.

If the financial institution does not have an account number then provide the functional equivalent unique identifier used by the financial institution to identify the account.

Mandatory for financial institutions that have an account number (including alpha numeric identifiers).
For example: The account number may be (i) the account number of a Custodial Account or Depository Account; (ii) the code (ISIN or other) related to a Debt or Equity Interest (if not held in a custody account); or (iii) the identification code of a Cash value Insurance Contract or Annuity Contract.

If exceptionally there is no account numbering system use NANUM for no account number as this is a validation element.
This format for account number is the same as FATCA and can be used for structured account numbers as well as free format; a non-standard account identifier or an insurance contract number could be included here.

COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 22 – ANNEX 3.
COMMON REPORTING STANDARD USER GUIDE Element Attribute Size Input Type Requirement AccountNumber AcctNumberType cfc:AcctNumberType_EnumType Optional There is an option to include information about the account number type as an enumeration.
The possible values are: • OECD601 = IBAN International Bank Account Number (follows a known structure) • OECD602 = OBAN Other Bank Account Number • OECD603 = ISIN International Securities Information Number (follows a known structure) • OECD604 = OSIN Other Securities Information Number • OECD605 = Other Any other type of account number e.g.

insurance contract where an IBAN or ISIN is available, it should be provided and the appropriate information about the account number type supplied.
Element Attribute Size Input Type Requirement AccountNumber UndocumentedAccount xsd:boolean (Optional) Mandatory [This attribute is for use in CRS domestic reporting to indicate that the account is undocumented.]

Element Attribute Size Input Type Requirement AccountNumber ClosedAccount xsd:boolean (Optional) Mandatory This attribute is for use in CRS reporting to indicate that the account is closed.
Element Attribute Size AccountNumber DormantAccount Input Type xsd:boolean Requirement Optional This attribute may be used in CRS reporting to indicate that the account is dormant.

IVe.
IVe.

Account Holder Element AccountHolder Attribute Size Input Type Requirement crs:AccountHolder_Type Validation For CRS this data element may identify an entity account holder who is • • a passive NFE with one or more controlling person that is a Reportable Person a CRS Reportable Person As there is a choice of entering an individual, or an organisation plus AcctHolderType (but one or other must be entered as the account holder), these are shown as validation (choice) below.
Element Individual Attribute Size Input Type Requirement crs:PersonParty_Type Validation (choice) If the Account Holder reported is a natural person, report his/her identifying information here.

COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 ANNEX 3.
COMMON REPORTING STANDARD USER GUIDE – 23 Element Organisation Attribute Size Input Type Requirement crs:OrganisationParty_Type Validation (choice) If the Account Holder reported is not a natural person, report the entity’s identifying information here.
Element Attribute Size Input Type Requirement AcctHolderType crs:CrsAcctHolderType_EnumType Validation (choice) This data element identifies an entity account holder that is • • • a passive NFE with one or more controlling person that is a Reportable Person a CRS Reportable Person a passive NFE that is a CRS Reportable Person Complete only if the reported financial account is held by an entity or the reported payment is made to an entity described-above.
Allowable entries for CRS: • CRS101 = Passive Non-Financial Entity with – one or more controlling person that is a Reportable Person • CRS102 = CRS Reportable Person • CRS103 = Passive Non-Financial Entity that is a CRS Reportable Person IVf.

Controlling Person Element Attribute Size Input Type Requirement ControllingPerson crs:ControllingPerson_Type (Optional) Mandatory Provide the name of any Controlling Person of a Passive NFE that is a Reportable Person.
Mandatory only if the entity Account Holder is a Passive NFE with one or more Controlling Persons who is are Reportable Persons.

If the Passive NFE has more than one Controlling Person that is a Reportable Person, then the name of all such Reportable Persons must be reported.

A separate report should be created with respect to each Reportable Jurisdiction that has been identified as a jurisdiction of residence of the Controlling Persons who are Reportable Persons.
However, only information of the Reportable Persons of each Reportable Jurisdiction (including information of the Passive NFE and other associated data) should be included in the report.
where an Entity Account Holder is a Reportable Person and is also a Passive NFE with one or more Controlling Persons that is a Reportable Person, and both the Entity and any of such Controlling Persons are resident in the same Reportable Jurisdiction, the information with respect to the account may be reported (i) as an account of an Entity that is a Passive NFE with a Controlling Person that is a Reportable Person, or (ii) as such and as an account of an Entity that is a Reportable Person (i.e.
as if were information with respect to two accounts).

where none of such Controlling Persons is resident in the same Reportable Jurisdiction as the Entity, the information with respect to the account must nevertheless be reported as an account of an Entity that is a Reportable Person.

COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 24 – ANNEX 3.
COMMON REPORTING STANDARD USER GUIDE Element Individual Attribute Size crs:PersonParty_Type Input Type Validation Requirement Defines a Controlling Person with its Name, Address, Country of Residence.
Element Attribute Size Input Type Requirement CtrlgPersonType crs:CrsCtrlgPersonType_EnumType (Optional) Mandatory This data element allows the identification of the type of each Controlling Person (“CP”) when available, by use of the attribute “ControllingPersonType” with the following options: a. CP of legal person – ownership b. CP of legal person – other means c. CP of legal person – senior managing official d. CP of legal arrangement – trust – settlor e. CP of legal arrangement – trust – trustee f. CP of legal arrangement – trust – protector g. CP of legal arrangement – trust – beneficiary h. CP of legal arrangement – trust – other i. CP of legal arrangement – other – settlor-equivalent j. CP of legal arrangement – other – trustee-equivalent k. CP of legal arrangement – other – protector-equivalent l. CP of legal arrangement – other – beneficiary-equivalent m. CP of legal arrangement – other – other-equivalent Allowable entries for CRS: • CRS801 = CP of legal person – ownership • CRS802 = CP of legal person – other means • CRS803 = CP of legal person – senior managing official • CRS804 = CP of legal arrangement – trust – settlor • CRS805 = CP of legal arrangement – trust – trustee • CRS806 = CP of legal arrangement – trust – protector • CRS807 = CP of legal arrangement – trust – beneficiary • CRS808 = CP of legal arrangement – trust – other • CRS809 = CP of legal arrangement – other – settlor-equivalent • CRS810 = CP of legal arrangement – other – trustee-equivalent • CRS811 = CP of legal arrangement – other – protector-equivalent • CRS812 = CP of legal arrangement – other – beneficiary-equivalent • CRS813 = CP of legal arrangement – other – other-equivalent COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 ANNEX 3.
COMMON REPORTING STANDARD USER GUIDE – 25 IVg.

Account Balance Element Attribute Size Input Type Requirement AccountBalance cfc:MonAmnt_Type Validation Provide the account balance or value of the reported financial account.

• Depository and custodial accounts.

The account balance or value shall be in accordance with CRS guidance.

• Cash value and annuity contracts.

The cash value insurance or annuity contract is the balance or value of the account.

• Debt or equity accounts.


The account balance is the value of the debt or equity interest that the account holder has in the financial institution.

• Enter Zero if account has been closed, in combination with account closed attribute.

• Numeric characters (digits).

Account balance is entered with 2-digit fractional amounts of the currency in question.

For example, USD 1 000 would be entered as 1000.00.
Element AccountBalance Attribute currCode Size Input Type Requirement 3 characters iso:currCode_Type Validation All amounts must be accompanied by the appropriate 3 character currency code2 based on the ISO 4217 Alpha 3 standard.

IVh.

Payment Element Payment Attribute Size crs:Payment_Type Input Type Optional Requirement Provide information on payment made to the reported financial account during the reporting period.
Payment information is a repeating element, if more than one payment type needs to be reported.

For example payment types may include the following: Depository accounts: • The aggregate gross amount of interest paid or credited to the account during the calendar year.

2.
2.

The following disclaimer refers to all uses of the ISO currency code list in the CRS schema: For practical reasons, the list is based on the ISO 4217 Alpha 3 currency list which is currently used by banks and other financial institutions, and hence by tax administrations.

The use of this list does not imply the expression by the OECD of any opinion whatsoever concerning the legal status of the territories listed.
Its content is without prejudice to the status of or sovereignty over any territory, to the delimitation of international frontiers and boundaries and to the name of any territory, city or area.

COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 26 – ANNEX 3.
COMMON REPORTING STANDARD USER GUIDE Custodial accounts: • The aggregate gross amount of dividends paid or credited to the account during the calendar year (or relevant reporting period); • The aggregate gross amount of interest paid or credited to the account during the calendar year (or relevant reporting period); • The gross proceeds from the sale or redemption of property paid or credited to the account during the calendar year (or relevant reporting period) with respect to which the FFI acted as a custodian, broker, nominee, or otherwise as an agent for the account holder and; • The aggregate gross amount of all other income paid or credited to the account during the calendar year (or relevant reporting period).
Debt or equity accounts: • The aggregate gross amount of payments paid or credited to the account during the calendar year (or relevant reporting period), including redemption payments.

Cash value insurance and annuity contract accounts: • The aggregate gross amount of payments paid or credited to the account during the calendar year (or relevant reporting period), including redemption payments.
Element Type Attribute Size Input Type Requirement crs:CrsPaymentType_EnumType Validation Select the proper code to identify the payment type.

Specific payment types listed are: • CRS501 = Dividends • CRS502 = Interest • CRS503 = Gross Proceeds/Redemptions • CRS504 = Other – CRS.
(Example: other income generated with respect to the assets held in the account) Element PaymentAmnt Attribute Size Input Type Requirement cfc:MonAmnt_Type Validation Payment Amounts are entered with 2-digit fractional amounts of the currency in question.

For example, USD 1 000 would be entered as 1000.00.
Element PaymentAmnt Attribute currCode Size Input Type Requirement 3 characters iso:currCode_Type Validation All payment amounts must be accompanied by the appropriate 3 character currency code based on the ISO 4217 Alpha 3 standard.

COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 ANNEX 3.

COMMON REPORTING STANDARD USER GUIDE – 27 IVi.


Pool Report Element PoolReport Attribute Size Input Type Requirement ftc:CorrectablePoolReport_Type Optional (Non-CRS) Pool reporting is not applicable to CRS.

Schema version The version of the schema and the corresponding business rules have a unique version number assigned that usually consists of two numbers separated by a period sign: major and minor version (ex: 2.0).
The version number could also contain a third number (ex: 2.0.1) which indicates that the schema was revised with very minor changes (ex: only new enumerations were added).

The version is identified by the version attribute on the schema element.

The target namespace of the CRS schema contains only the major version.
<xsd:schema xmlns:crs= "urn:oecd:ties:crs:v2" xmlns:xsd= "http://www.w3.org/2001/XMLSchema" xmlns:ftc= "urn:oecd:ties:fatca:v1" xmlns:cfc= "urn:oecd:ties:commontypesfatcacrs:v2" xmlns:stf= "urn:oecd:ties:crsstf:v5" xmlns:iso= "urn:oecd:ties:isocrstypes:v1" targetNamespace= "urn:oecd:ties:crs:v2" elementFormDefault= "qualified" attributeFormDefault= "unqualified" version= "2.0"> <xsd:import namespace="urn:oecd:ties:isocrstypes:v1" schemaLocation="isocrstypes_v1.1.xsd"/> <xsd:import namespace="urn:oecd:ties:crsstf:v5" schemaLocation="oecdcrstypes_v5.0.xsd"/> <xsd:import namespace="urn:oecd:ties:commontypesfatcacrs:v2" schemaLocation="CommonTypesFatcaCrs_v2.0.xsd"/> <xsd:import namespace="urn:oecd:ties:fatca:v1" schemaLocation="FatcaTypes_v1.2.xsd"/> Element CRS_OECD Attribute version Size Input Type Requirement 1 to 10 characters s stf:StringMin1Max10_Type (Optional) Mandatory The root element CRS_OECD version attribute in the XML report file must be set to the value of the schema version.
This will identify the schema version that was used to create the report.

For the CRS schema version 2.0, the version attribute must be set to the value “2.0”.

Transliteration where transliteration is required because sending and receiving jurisdictions do not use a common alphabet, Competent Authorities may agree how they will undertake such transliteration.
If there is no such agreement, then the sending jurisdiction should, if so requested, transliterate from its domestic alphabet or literation to a Latin alphabet aligned with international standards for transliteration (for example as specified in ISO 8859).

The sending jurisdiction may send designatory data (e.g.

name or address) in both domestic alphabet or literation and separately in Latin alphabet within each account record if they so choose.
The receiving jurisdiction should also be prepared to transliterate between Latin and its own domestic alphabet or literation.

COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 28 – ANNEX 3.

COMMON REPORTING STANDARD USER GUIDE Guidance on the correction process for Common Reporting Standard In the course of AEOI, the sending jurisdiction may need to correct some elements of data previously sent.
The section below describes how to make automatic corrections by sending a file of corrected data that can be processed in the same systems as the original data that was received.

Reference to corrections also includes deletion of data elements in the following section.

Technical guidance In order to identify the elements to correct, the top-level elements Reporting FI or Account Report include an element of type DocSpec_Type, which provides necessary information for corrections.
DocSpec Type Element DocSpec Attribute Size stf:DocSpec_Type Input Type Validation Requirement DocSpec identifies the particular record within the CRS message being transmitted.

It allows for identification of records that require correction.

DocSpec_Type is comprised of the following elements: Element DocTypeIndic Attribute Size Input Type Requirement stf:OECDDocTypeIndic_EnumType Validation This element specifies the type of data being submitted.
Allowable entries are: • OECD0 = Resent Data (only to be used for resending the Reporting FI element) • OECD1 = New Data • OECD2 = Corrected Data • OECD3 = Deletion of Data • OECD10 = Resent Test Data (only to be used for resending the Reporting FI element) • OECD11 = New Test Data • OECD12 = Corrected Test Data • OECD13 = Deletion of Test Data A message can contain either new records (OECD1) or corrections/deletions (OECD2 and OECD3), but should not contain a mixture of both.
OECD10 – OECD13 should only be used during previously agreed-upon testing periods or after a bilateral discussion where both parties agree to testing.

This is to help eliminate the possibility that test data could be co-mingled with “live” data.

Element DocRefID Attribute Size Input Type Requirement 1 to 200 characters stf:StringMin1Max200_Type Validation A unique identifier for this document (i.e.

one record and all its children data elements).


COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 ANNEX 3.

COMMON REPORTING STANDARD USER GUIDE – 29 A correction (or deletion) must have a new unique DocRefID for future reference.

Element CorrDocRefID Attribute Size Input Type Requirement 1 to 200 characters stf:StringMin1Max200_Type Optional The CorrDocRefID references the DocRefID of the element to be corrected/deleted.
It must always refer to the latest reference of this Account-report (DocRefID) that was sent.

In this way, a series of corrections or amendments can be handled as each correction completely replaces the previous version.

The CRS Correction examples below show how this works in practice.
Element Attribute Size Input Type Requirement CorrMessageRefID 1 to 170 characters stf:StringMin1Max170_Type Optional (Non-CRS) Since the DocRefID is unique in space and time, this element is not used for CRS at the DocSpec level.

Uniqueness of MessageRefID and DocRefID In order to ensure that a message and a record can be identified and corrected, the MessageRefID and DocRefID must be unique in space and time (i.e.
there must be no other message or record in existence that has the same reference identifier).

The MessageRefID identifier can contain whatever information the sender uses to allow identification of the particular message but must start with the sending country code as the first element for Competent Authority to Competent Authority transmission, then the year to which the data relates, then the receiving country code before a unique identifier.

e.g.
e.g.

FR2013CA123456789 The unique identifier in the DocRefID could be the reference used by the FI to report nationally, or a different unique reference created by the sending tax administration, but must in all cases start with the country code of the sending jurisdiction e.g.
FRFI286abc123xyz or FRabc123xyz [If the CRS schema is used for domestic reporting, the FI may similarly include an FI Identification Number in both MessageRefID and DocRefID which is recommended as good practice to ensure uniqueness in time and space and helps to link queries to source data.]

MessageSpec and Corrections Correction messages must have their own unique MessageRefID so they can also be corrected in the future.

There is no equivalent for the DocSpecIndic when it comes to messages as a whole.
To cancel a complete message, the MessageSpec.CorrMessageRefID is not to be used.

Instead, a correction message should be sent deleting all records of the erroneous message in these instances.

COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 30 – ANNEX 3.

COMMON REPORTING STANDARD USER GUIDE DocSpec_Type Document specification: Data identifying and describing the document, where 'document' here means the part of a message that is to transmit the data about a single block of CRS information.
stf: DocTypeIndic stf: DocRefID Sender's unique identifier of this document stf: CorrMessageRefId Reference id of the message of the document referred to if this is a correction stf: CorrDocRefId Reference id of the document referred to if this is correction Correctable elements In the CRS XML Schema, there are two correctable elements, the Reporting FI and the Account Report.

Only these two elements are correctable in the CRS XML Schema.
These two correctable elements must be considered separately for the correction process.

The correction of one of the two correctable elements must not impact the other related correctable element.

If a correction targets a previously sent child element of a correctable element, the whole correctable element (the correctable element and all its children) must be resubmitted.

This is applicable for both the Reporting FI and Account Report elements.
In order to be able to identify the elements to correct, the definition of these correctable elements includes an element of type DocSpec_Type, which includes the elements named DocTypeIndic, DocRefID and CorrDocRefID.
For a correction message, the following combinations of DocTypeIndic are permissible for the correctable elements, taking into account that the Account Report element is not mandatory: w/o Account Report OK OK Reporting FI OECD1 OECD2 OECD3 OECD0 Account Report OECD1 OECD2 OECD3 OECD0 OK OK OK OK OK Combinations of DocTypeIndic for the correctable elements within a correction message when a correction targets only the Account Report element and there is no modification of the related Reporting FI element, the DocTypeIndic “OECD0-Resend Data” is used for the Reporting FI element.
This type is only allowed for Reporting FI element.

If the receiving Competent Authority encounters other combinations than those presented above, the receiving Competent Authority rejects the received file and returns a status message with the relevant error code (see CRS Status Message User Guide).

COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 ANNEX 3.
COMMON REPORTING STANDARD USER GUIDE – 31 Structure of a correction message A correction message has essentially the same structure as an initial message (with new data), as it follows the same schema.

There is only a minor difference in the Message Header: the MessageTypeIndic will be set to CRS702 (CRS702 = The message contains corrections for previously sent information).
As for the initial messages, all correction messages must have their own unique MessageRefID, while the Reporting FI element can have a DocTypeIndic value of OECD0, in case it has not been modified.

A corrected element will have a DocTypeIndic value of OECD2 or OECD3 (OECD1 for initial messages).

Its CorrDocRefID references the DocRefID of the element to correct (this element is not specified in initial messages).
Since the DocRefID is unique in time and space, the correcting records must have different DocRefIDs than those of the records being corrected.

A correction message can contain either corrections (OECD2) or deletions (OECD3) or both, as well as a resent Reporting FI element (OECD0), but may not contain new data (OECD1).

Relationship between messages The following section describes how messages exchanged through the correction mechanism described above interact with one another.
Since messages specify the reporting period to which they relate, a correction message may correct records originating from any previous initial or correction messages for the same reporting period.

Correction of an initial message The correction of an initial message is the most common situation.

The correction is used to correct the elements that were not correct (from a technical point or business point of view), or to delete elements from the initial message.
A new DocRefID is created for each correctable element and should follow the format described previously.

The CorrDocRefID must reference the DocRefID of the elements to be corrected/ deleted from the initial message.

Correction of a correction message Corrections of corrections are legitimate.

In that case, the CorrDocRefID of the second correction of the message must reference the DocRefID of the first correction.
This is required in order to uniquely determine the order in which the receiving Competent Authority must handle the corrections.

Otherwise, in case two corrections reference the same message and, for technical reasons (e.g.

infrastructure or architecture constraints), arrive out of order, the receiving Competent Authority would first integrate the second correction, then the first one, effectively dismissing the second (and most recent) correction.
If the receiving Competent Authority receives messages that it considers as probably being out of order, it should – as a best practice – wait for some time before discarding the message, in case the previous messages arrive late.

If the relevant message does not arrive, the receiving Competent Authority should contact the sending Competent Authority.

COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 32 – ANNEX 3.
COMMON REPORTING STANDARD USER GUIDE Common Reporting Standard Correction examples The following sections provide examples of concrete correction scenarios, and highlight correction rules applicable to each of them.

Each example includes one or more figures to illustrate the situation.

These figures omit most of the data, and only highlight the main areas of interest.
In the examples below, the following convention has been used to highlight the elements that need to be corrected or resent: • The dark grey colour is used when the Reporting FI element has to be resent, even if no modifications are required.
In this situation, the element is identified with the same DocRefID as the immediately preceding version of the Reporting FI element and the code OECD0 is used; • The black colour is used to identify the elements that require being corrected (initial message) or are corrected (correction message).
First example: Two successive corrections of the same account This example covers the following scenario: • The sending Competent Authority sends an initial message with one Reporting FI and two Account Reports; • • It then sends a first correction message correcting the Payment Amount of the first Account Report; It finally sends a second correction message, correcting the Account Balance, yet again for the first Account Report.
There are four areas of interest here highlighted by the figure below: • The CorrDocRefID of the Account Report refers to the immediately preceding message, not to any preceding one (in particular, not systematically to the first one); • The DocTypeIndic of the Account Report is set to OECD1 within an initial message and to OECD2 within a correction message; • The sending Competent Authority must always resend the Reporting FI associated to the Account Report being corrected, even though it did not require modifications.
The DocTypeIndic is set to OECD0 and the DocRefID is the same as the immediately preceding message; • The sending Competent Authority must only resend the corrected Account Report.

The second one, which does not require corrections, is not part of the correction message.

Please note that the DocRefIDs provided in the figure examples have been simplified to make the figures easier to read.

COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 ANNEX 3.
COMMON REPORTING STANDARD USER GUIDE – 33 <ReportingFI> <ReportingFI> <DocTypeIndic> = OECD1 <DocTypeIndic> = OECD0 <DocTypeIndic> = OECD0 <DocRefId> = FI1 <DocRefId> = FI1 <DocRefId> = FI1 <AccountReport> <AccountReport> <DocTypeIndic> = OECD1 <DocTypeIndic> = OECD2 <DocTypeIndic> = OECD2 <DocRefId> = AR1 <DocRefId> = AR3 <DocRefId> = AR4 <CorrDocRefId> = AR1 <CorrDocRefId> = AR3 <DocTypeIndic> = OECD1 <DocRefId> = AR2 Two successive corrections of the same account The DocRefID should follow the DocRefID format defined previously: • • It must start with the country code of the sending jurisdiction; It must be unique in time and space.
e.g.

FR2013-11111 or or FRabc123xyz Please note that these examples show exchanges between Competent Authorities, but the same correction process would apply if the CRS schema is used domestically.

The diagram below shows the message “Correction 2” within the CRS schema diagram (for the first example shown above).

COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 34 – ANNEX 3.
COMMON REPORTING STANDARD USER GUIDE DocSpec of the Account Report indicates it is corrected DocTypeIndic: OECD2 = Corrected Data DocRefID: AR4 A correction must have a new DocRefID for future reference.

CorrDocRefID: AR3 Always references the latest DocRefID of the record to be corrected.

NB: CorrMessageRefID: since the DocRefID is unique in time and space, this element is not used for CRS.
DocSpec of the Reporting FI indicates it is resent DocTypeIndic: OECD0 = Resend Data DocRefID: FI1 when the Reporting FI is resent, it keeps the same DocRefID DocRefID: No CorrDocRefID is provided when the Reporting FI is resent.

The Account Balance is corrected.

All the Account Report information is also resubmitted.

Showing the “Correction 2” message within the CRS schema COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 ANNEX 3.
COMMON REPORTING STANDARD USER GUIDE – 35 Second example: Two successive corrections of data from the same message This example covers the following scenario: • The sending Competent Authority sends an initial message with one Reporting FI and two Account Reports; • • It then sends a first correction message correcting the address of the Reporting FI; It finally sends a second correction message, correcting the first Account Report (new Account Payment).
The figure below highlights the three areas of interest: • The sending Competent Authority must always resend the Reporting FI associated to the Account Report being corrected, even though it did not require modifications.

The DocTypeIndic is set to OECD0 and the DocRefID is the same as the immediately preceding message; • The sending Competent Authority must only resubmit the corrected Account Report.
The other Account Report, which does not require corrections, is not part of the correction message; • The sending Competent Authority can send the corrected Reporting FI without the Account Reports if they do not require corrections.
<ReportingFI> <ReportingFI> <ReportingFI> <DocTypeIndic> = OECD1 <DocTypeIndic> = OECD2 <DocTypeIndic> = OECD0 <DocRefId> = FI1 <DocRefId> = FI2 <DocRefId> = FI2 <CorrDocRefId> = FI1 <AccountReport> <AccountReport> Two successive corrections of data from the same message COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 36 – ANNEX 3.

COMMON REPORTING STANDARD USER GUIDE The diagram below shows the message “Correction 1” within the CRS schema diagram (for the second example shown above).
DocTypeIndic: OECD2 = Corrected Data DocRefID: FI2 A correction must have a new DocRefID for future reference.

CorrDocRefID: FI1 Always references the latest DocRefID (for Reporting FI in this case) Since no data in Account Report needs to be corrected, only the Reporting FI is sent as correction.

Showing the message “Correction 1” within the CRS schema COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 ANNEX 3.
COMMON REPORTING STANDARD USER GUIDE – 37 Third example: Correction of a child element of the Account Report This example covers the following scenario: • The sending Competent Authority sends an initial message with a Reporting FI, and an Account Report, composed of an Account Number, an Account Holder, two Controlling Persons (residing in the same jurisdiction) and an Account Balance element; • It then wants to correct the Address of the first Controlling Person.
In this case, the sending Competent Authority must correct the Account Report from the initial message, and send it back with the corrected Controlling Person data.

It must also include the Reporting FI since this element is mandatory, as well as the second Controlling Person, the Account Number, the Account Holder and the Account Balance; even though these elements did not require modifications.

The figure below highlights this.


<ReportingFI> <AccountReport> <ControllingPerson> <ControllingPerson> Correction of a child element of the Account Report COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 38 – ANNEX 3.
COMMON REPORTING STANDARD USER GUIDE Fourth example: Correction of both correctable elements within the same message This example covers the following scenario: • The sending Competent Authority sends an initial message containing two Account Reports and the associated Reporting FI.

The first Account Report is composed of an Account Number, an Account Holder, a Controlling Person and an Account Balance element.
The second Account Report is composed of an Account Number, an Account Holder and an Account Balance element.

The Reporting FI is composed of a Name and an Address element; • It then wants to correct the Address of the Reporting FI and the Account Balance of the first Account Report.

In this case, the sending Competent Authority must correct the Reporting FI and the first Account Report from the initial message.

The Reporting FI must contain the corrected Address as well as the Name.
The first Account Report must contain the corrected Account Balance, as well as the Account Number, the Account Holder and the Controlling Person elements.

The second Account Report is not resubmitted.

The figure below highlights this.

<ReportingFI> <Address> <Address> <AccountReport> <AccountBalance> <AccountBalance> Correction of both correctable elements within the same message COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 ANNEX 3.
COMMON REPORTING STANDARD USER GUIDE – 39 Fifth example: Removal of a child element of the Account Report This example covers the following scenario: • The sending Competent Authority sends an initial message with a Reporting FI, and an Account Report composed of an Account Number, an Account Holder, two Controlling Person and an Account Balance element; • It then wants to remove the first Controlling Person element.
In this case, the sending Competent Authority must correct the Account Report from the initial message, and send it back without the deleted Controlling Person element, but with the other Controlling Person, the Account Number, the Account Holder, the Account Balance elements, as well as the Reporting FI element, as this element is mandatory.

The figure below highlights this.


<ReportingFI> <AccountReport> <ControllingPerson> Removal of a child element of the Account Report COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 40 – ANNEX 3.
COMMON REPORTING STANDARD USER GUIDE Sixth example: Removal of a child element of the Reporting FI This example covers the following scenario: The sending Competent Authority sends an initial message with two Account Reports and the associated Reporting FI having a Name and two Addresses; It then wants to remove the second Address of the Reporting FI.
In this case, the sending Competent Authority must correct the Reporting FI from the initial message, and send it back without the deleted Address but with the other Address, and the Name.

The Account Reports are not resubmitted.

The figure below highlights this.

<ReportingFI> <Address> <Address> Removal of a child element of the Reporting FI COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 ANNEX 3.
COMMON REPORTING STANDARD USER GUIDE – 41 Seventh example: Removal of an Account Report This example covers the following scenario: • The sending Competent Authority sends an initial message with two Account Reports and the associated Reporting FI.

Each Account Report is composed of an Account Number, an Account Holder and an Account Balance element; • It then wants to remove the first Account Report.
In this case, the sending Competent Authority must correct the first Account Report indicating that it must be deleted (DocTypeIndic is set to OECD3), omit the second Account Report since it does not require corrections, and send it back with the child elements of the corrected Account Report as well as the Reporting FI since this element is mandatory.

The figure below highlights this.


<ReportingFI> <AccountReport> <AccountReport> Removal of an Account Report An exception can occur if the correction message removes only the Reporting FI, without the associated Account Reports.

In this case, the deletion of the Reporting FI must be rejected, as a Reporting FI must always be associated to an Account Report.
The removal of a Reporting FI element is allowed only if all the associated Account Reports have been already removed (either in same message or in previous messages).

COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 42 – ANNEX 3.

COMMON REPORTING STANDARD USER GUIDE Eighth example: Creation of a child element This example covers the following scenario: • The sending Competent Authority sends an initial message containing an Account Report and the associated Reporting FI.
The Account Report is composed of an Account Number, an Account Holder, two Controlling Persons, and an Account Balance element; • It then wants to add a Payment element to the Account Report.
In this case, the sending Competent Authority must correct the Account Report from the initial message, specifying a new Payment element and send it back with the Account Number, the Account Holder, two Controlling Persons, and the Account Balance elements, as well as the Reporting FI element, since this element is mandatory.

The figure below highlights this.

<ReportingFI> <AccountReport> <Payment> Creation of a child element COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 ANNEX 3.
COMMON REPORTING STANDARD USER GUIDE – 43 Ninth example: Adding an Account Report for an existing Reporting FI This example covers the following scenario: • The sending Competent Authority sends an initial message with one Account Report and the associated Reporting FI; • It then wants to send another Account Report.

In this case, the sending Competent Authority creates a new initial message, with only the new Account Report and the already sent Reporting FI.

The figure below highlights this.


<MessageTypeIndic> = CRS701 <MessageTypeIndic> = CRS701 <ReportingFI> <DocRefId> = FI1 <DocRefId> = FI1 <DocTypeIndic> = OECD1 <DocTypeIndic> = OECD0 <DocRefId> = AR1 <DocRefId> = AR2 <DocTypeIndic> = OECD1 <DocTypeIndic> = OECD1 Adding an Account Report for an existing Reporting FI This scenario occurs only in specific circumstances, such as late reporting or in case of split messages.

COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 44 – ANNEX 3.
COMMON REPORTING STANDARD USER GUIDE Tenth example: Adding a new Reporting FI with its Account Reports This example covers the following scenario: • The sending Competent Authority sends an initial message with one Account Report and the associated Reporting FI; • It then wants to send another Reporting FI with two Account Reports.

In this case, the sending Competent Authority creates a new initial message, with only the new Reporting FI and the two Account Reports.

The figure below highlights this.


<MessageTypeIndic> = CRS701 <MessageTypeIndic> = CRS701 <DocRefId> = FI1 <DocRefId> = FI2 <DocTypeIndic> = OECD1 <DocTypeIndic> = OECD1 <DocRefId> = AR1 <DocRefId> = AR3 <DocTypeIndic> = OECD1 <DocTypeIndic> = OECD1 <DocRefId> = AR4 <DocTypeIndic> = OECD1 Adding a new Reporting FI with its Account Reports As in the previous example, this scenario occurs only in specific circumstances, such as late reporting or in case of split messages.
COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 APPENDIX A. CRS XML SCHEMA v2.0 DIAGRAMS – 45 Appendix A CRS XML Schema v2.0 Diagrams COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 46 – APPENDIX A. CRS XML SCHEMA v2.0 DIAGRAMS Message Header (Section I) COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 APPENDIX A. CRS XML SCHEMA v2.0 DIAGRAMS – 47 ) V I n o i t c e S ( y d o B S R C COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 48 – APPENDIX A. CRS XML SCHEMA v2.0 DIAGRAMS ) a V I n o i t c e S ( I F g n i t r o p e R COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 APPENDIX A. CRS XML SCHEMA v2.0 DIAGRAMS – 49 ) b V I n o i t c e S ( p u o r G g n i t r o p e R COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 50 – APPENDIX A. CRS XML SCHEMA v2.0 DIAGRAMS ) c V I n o i t c e S ( t r o p e R t n u o c c A COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 APPENDIX A. CRS XML SCHEMA v2.0 DIAGRAMS – 51 ) d V I n o i t c e S ( e p y T r e b m u N t n u o c c A COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 52 – APPENDIX A. CRS XML SCHEMA v2.0 DIAGRAMS ) e V I n o i t c e S ( r e d l o H t n u o c c A COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 APPENDIX A. CRS XML SCHEMA v2.0 DIAGRAMS – 53 ) e V I n o i t c e S ( s r e d l o H t n u o c c A n o i t a s i n a g r O / l a u d i v i d n I COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 54 – APPENDIX A. CRS XML SCHEMA v2.0 DIAGRAMS ) f V I n o i t c e S ( n o s r e P g n i l l o r t n o C COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 APPENDIX A. CRS XML SCHEMA v2.0 DIAGRAMS – 55 ) h V I n o i t c e S ( , .
s n o i t a r t s i n i m d a x a t y b e c n e h d n a , .
, y r o t i r r e t .
a e r a r o y t i c , y r o t i r r e t y n a f o e m a n e h t o t d n a COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 56 – APPENDIX A. CRS XML SCHEMA v2.0 DIAGRAMS ) I I n o i t c e S ( - , .
s n o i t a r t s i n i m d a x a t y b e c n e h d n a , .
a e r a r o y t i c , y r o t i r r e t y n a f o e m a n COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 APPENDIX A. CRS XML SCHEMA v2.0 DIAGRAMS – 57 Person Name Type COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 58 – APPENDIX A. CRS XML SCHEMA v2.0 DIAGRAMS e p y T s s e r d d A COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 APPENDIX A. CRS XML SCHEMA v2.0 DIAGRAMS – 59 1 - , s n o s a e r l a c i t c a r p r o F , .
.

 , y r o t i r r e t y n a r e v o y t n g i e r e v o s .
a e r a r o y t i c , ) I I I n o i t c e S ( e p y T y t r a P n o i t a s i n a g r O COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 60 – APPENDIX A. CRS XML SCHEMA v2.0 DIAGRAMS ) i V I n o i t c e S ( ) S R C - n o N ( t r o p e R l o o P COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 APPENDIX A. CRS XML SCHEMA v2.0 DIAGRAMS – 61 Sponsor & Intermediary (Non-CRS) COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019 APPENDIX B. GLOSSARy OF NAMESPACES – 63 Appendix B Glossary of Namespaces CRS Schema Namespaces Namespace Description Filename crs cfc ftc stf iso CRS specific types CrsXML_v2.0.xsd Common types for FATCA and CRS CommonTypesFatcaCrs_v2.0.xsd FATCA specific types OECD Common Types FatcaTypes_v1.2.xsd OECDCrsTypes_v5.0.xsd ISO types (Country & Currency codes) isocrstypes_v1.1.xsd COMMON REPORTING STANDARD XML SCHEMA: USER GUIDE © OECD 2019