September 2017

TABLE OF CONTENTS – 3

Table of contents

Abbreviations and acronyms ..................................................................... 5

Introduction ................................................................................................ 7
Part A CRS Status Message XML Schema Information ..................... 13
Annex A CRS Status Message XML Schema Diagrams ..................... 23
Annex B Glossary of Namespaces and Frequently Used Terms ......... 29
Part B CRS Status Message Error Codes.............................................. 31

COMMON REPORTING STANDARD STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
 ABBREVIATIONS AND ACRONYMS – 5

Abbreviations and acronyms

CRS Common Reporting Standard

CRS MCAA CRS Multilateral Competent Authority Agreement
CTS Common Transmission System
FATCA Foreign Account Tax Compliance Act
FI Financial Institution
OECD Organisation for Economic Co-operation and Development

COMMON REPORTING STANDARD STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
 INTRODUCTION – 7

Introduction

With the first exchanges under the Common Reporting Standard being
scheduled for September 2017, jurisdictions are now putting in place the
required legislative, operational and IT framework. From an IT perspective,
jurisdictions will rely on the CRS XML Schema, developed at the level of
the OECD as part of the CRS, for exchanging the information with each
other and, in many instances, to receive information from their Financial
Institutions.
As the information to be provided through the CRS XML Schema may
contain errors, caused by either an incorrect file preparation and/or by
incomplete or inaccurate record information, work has been taken up at the
level of the OECD with a view to developing a common XML Schema for
providing the sending Competent Authorities with information as to such
file and record errors in a structured manner.
As a result of that work, this document contains the structure of the CRS
Status Message XML Schema, as well as a User Guide setting out the
practical guidelines for using the XML Schema.
The CRS Status Message XML Schema allows Competent Authorities that
have received CRS information through the CRS XML Schema to report
back to the sending Competent Authority, whether the file received
contained any of the file and/or record errors.
In case file errors are discovered, this will generally entail that the receiving
Competent Authority is not in a position to open and use the file. As such,
file errors are of a fundamental nature and therefore it is expected that a
CRS Status Message is sent to the sending Competent Authority in these
instances, with a view to timely receiving a new file (without the file error)
with the CRS information contained in the initial erroneous file sent. This
approach also reflects the requirements set out in Article 4 of the CRS
MCAA in relation to the notification and remediation of errors that prevent
the exchange relationship from operating efficiently.
Record errors address key issues of data quality of the CRS information
received, but do not as such impede the receiving Competent Authority from
opening and using the file. The record errors contained in the CRS Status

COMMON REPORTING STANDARD STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
8 – INTRODUCTION

Message XML Schema reflect the additional validations that were agreed.
As these agreed additional validations are a recommendation, record errors
are, unlike file errors, not required to be provided, but are a matter of best
efforts. However, in case record errors are communicated to the sending
Competent Authority through the CRS Status Message XML Schema, it is
recommended that the sending Competent Authority undertakes action to
address these errors and to provide the receiving Competent Authority with
corrected information.
The CRS Status Message XML Schema may, in addition to communications
between Competent Authorities, also be used by a Competent Authority to
provide a status message to its domestic Financial Institutions. Specific
instructions for such cases are marked in italic and [brackets] throughout the
User Guide.
While the CRS Status Message XML Schema allows providing structured
information to the sender of the initial CRS message on any file and/or
record errors, the schema does not accommodate substantive follow-up
requests or qualitative feedback. For this type of input, Competent
Authorities should rely on the usual bilateral communication methods.

How the User Guide links to the CRS Status Message XML Schema

Structure and general requirements

Part A of the User Guide contains further guidance on the use of the CRS
Status Message XML Schema. The 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 Status Message XML Schema Information sections are:
I Message Header with the sender, recipient(s), message type and
the timestamp
II The body of the CRS Status Message XML Schema, containing
information as to whether any file and/or record errors were
detected or whether the file had no errors, as well as the details of
any file and/or record errors found and the decision as to accept
or reject the CRS message. The error codes to be used to indicate
file or record errors are contained in Part B of this User Guide.
The requirement field for each data element and its attribute indicates
whether the element is validation or optional in the CRS Status Message
XML Schema.

COMMON REPORTING STANDARD STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
 INTRODUCTION – 9

“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.
“Optional” elements are, while recommended, not required to be provided
and may in certain instances represent a choice between one type or another,
where one of them must be used.
Certain elements, such as the Original Message Ref ID element, are labelled
as “Optional (Mandatory)”, indicating that the element is in principle
mandatory, but is only required to be filled in certain cases (i.e. to the extent
the Original Message Ref ID is available). The User Guide further details
these situations and the criteria to be used.
Annex A to the CRS Status Message User Guide shows a diagrammatic
representation of the CRS Status Message XML Schema with all its
elements. The numbers next to the headings are the corresponding section
numbers in the User Guide text, which provides further guidance on the
information to be provided in each element.
Annex B to the CRS Status Message User Guide contains a Glossary of
namespaces for the CRS Status Message XML Schema, as well as a list of
frequently used terms.
Part B of the User Guide contains further guidance on the file and record
error codes to be used when populating the CRS Status Message XML
Schema.

General principles for using the CRS Status Message XML Schema
For each CRS message received, the receiving Competent Authority will
send a CRS Status Message to indicate the outcomes of the file (and any
record) validations.
A CRS Status Message refers to only one initial CRS message (CRS XML
Schema file), indicated in the field OriginalMessage.OriginalMessageRefID.
Although a validation of the CRS Status Message is recommended, no CRS
Status Message should be sent with respect to another CRS Status Message.
As such, CRS Status Messages may only be sent in relation to a CRS
message. Competent Authorities may request consultations pursuant to
Section 6 of the CRS MCAA, in case discussions with respect to a CRS
Status Message are required.
A request to correct or delete any of the records in a CRS message (i.e. a
CRS XML Schema file) should not be sent by the sending Competent
Authority until the earlier of the receiving Competent Authority indicating

COMMON REPORTING STANDARD STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
10 – INTRODUCTION

through a CRS Status Message that the initial file has been received as valid
(Status is Accepted) or 15 days as of the sending of the CRS message.

Referencing
Each Status Message sent in accordance with the CRS XML Status Message
Schema must only refer to one CRS Message (i.e. one CRS XML Schema
file), as indicated in the field OriginalMessage. OriginalMessageRefID. It is
not acceptable to send a Status Message for another Status Message, as there
will be no validation carried out on a status message.

Relationship between the status indicated and validation errors

When the Competent Authority that has received the original CRS message
indicates in the CRS Status Message XML Schema that the original CRS
message has been rejected, at least one error (file error or record error) must
be specified. When no file error or record error is indicated, the original
CRS message must be accepted.
Even if error(s) are specified, the original CRS message can still be
accepted, in which case it describes errors deemed not grave enough to
justify a rejection by the receiver.
For instance, in case of file errors, a file could still be accepted, if there are
only minor XML validation errors (while notifying the file errors).
In case of record errors, the general approach should be that the file is
accepted, unless the record errors are so recurrent and frequent that the file
is to be rejected as a whole.
When the Status is rejected, the file must be corrected and resubmitted when
the rejection is due to file errors. In case the Status is rejected due to a large
number of record errors, the concerned sending and receiving Competent
Authorities may consult each other in accordance with Section 6 of the CRS
MCAA, with a view to resolving the issues.
When the Status is accepted, only the records errors must be corrected via a
new correction message.

How to report error(s) through the CRS Status Message?

If the Competent Authority receiving the initial CRS message encounters
one or more file errors, it rejects the received file and returns a CRS Status
Message with the found errors. The Competent Authority that sent the initial
CRS message must then correct its implementation and send back the
message. Since the first message is ignored (the file was rejected), a

COMMON REPORTING STANDARD STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
 INTRODUCTION – 11

correction message is not needed (unless the file was already a correction, in
which case the new file remains of the same type).
If the Competent Authority receiving the initial CRS message encounters
one or more record errors, it can decide how it wishes to proceed. If the
error is deemed grave enough, it rejects the message, and the Competent
Authority that sent the initial CRS message proceeds as if the file was
rejected for file error(s) (see above). If the errors are not considered as
grave, the Competent Authority receiving the initial CRS message integrates
the data in its national system and sends a CRS Status Message indicating
acceptance of the received message, but mentioning the detected errors.

Can the sending Competent Authority reuse the MessageRefID for the
CRS message to correct errors?
For traceability purposes, the new message must have a different
MessageRefID than the rejected one, even if it mostly holds the same
content.
In case of record error(s), a correction message must always have a new
MessageRefId.

Example for the sequence of exchanges under the CRS Status

Message XML Schema
In relation to an exchange of CRS information between Canada and France,
the following events occur:
1. Canada sends a CRS message with new data to France
‒ France is not able to decrypt the file and sends a CRS Status
Message
2. Canada corrects the file with proper encryption
‒ France found XML validation errors and send a CRS Status
Message
3. Canada corrects the XML validation issues and resubmits the file
‒ France found no file error, but ten (minor) record errors.
France accepts the file
4. Canada corrects the ten records errors (the file contains the ten
corrected records)
‒ France found no further errors. France accepts the file.

COMMON REPORTING STANDARD STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
12 – INTRODUCTION

COMMON REPORTING STANDARD STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
 PART A: CRS STATUS MESSAGE XML SCHEMA INFORMATION – 13

Part A

CRS Status Message XML Schema Information

I. Message Header

Information in the message header identifies the Competent Authority that is

sending the message, as well as the Competent Authorities receiving the
message. It specifies when the message was created and the nature of the
report.
Element Attribute Size Input Type Requirement
SendingCompanyIN Max 200 characters csm:StringMax200Type Optional

The Sending Company IN element is only to be used if the CRS Status

Message Schema is used by Financial Institutions in the context of domestic
reporting with its Competent Authority.
[Only to be provided, if the CRS Status Message XML Schema is used
domestically. When this element is used, it could reflect the Sending
Company IN of the Financial Institution that sent the initial CRS message or
the IN of the third party filer that submitted the CRS message (i.e. the file for
which this CRS Status Message is produced).]
Element Attribute Size Input Type Requirement
TransmittingCountry 2-character iso:CountryCode_Type Validation

This data element identifies the jurisdiction of the Competent Authority

transmitting the message, which is the Competent Authority that has
received the initial CRS message to which the Status Message relates. It
uses the 2-character alphabetic country code and country name list1 based on
the ISO 3166-1 Alpha 2 standard.

1. The following disclaimer refers to all uses of the ISO country code list in the CRS Status Message XML 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 STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
14 – PART A: CRS STATUS MESSAGE XML SCHEMA INFORMATION

Element Attribute Size Input Type Requirement

ReceivingCountry 2-character iso:CountryCode_Type Validation

This data element identifies the jurisdiction of the Competent Authority

receiving the message, which is the Competent Authority that has sent the
initial CRS message to which the Status Message relates. This data element
identifies the jurisdiction of the Competent Authority that is the intended
recipient of the message. It uses the 2-character alphabetic country code
based on the ISO 3166-1 Alpha 2 standard.
Element Attribute Size Input Type Requirement
MessageType csm:MessageType_EnumType Validation

This data element specifies the type of message being sent. The only
allowable entry in this field is “CRSMessageStatus”.
Element Attribute Size Input Type Requirement
Warning Max 4’000 characters csm:StringMax4000Type Optional

This data element is a free text field allowing input of specific cautionary
instructions about use of the CRS Status Message.
Element Attribute Size Input Type Requirement
Contact Max 4’000 characters csm:StringMax4000Type Optional

This data element is a free text field allowing input of specific contact
information for the sender of the message (i.e. the Competent Authority
sending the CRS Status Message).
Element Attribute Size Input Type Requirement
MessageRefID Max 200 characters csm:StringMax200Type Validation

This data element is a free text field capturing the sender’s unique
identifying number (created by the sender) that identifies the particular CRS
Status Message being sent. The identifier allows both the sender and
receiver to identify the specific message later if questions arise.
It should be noted that the unique identifier for the CRS Status Message to
be entered here is not to be confused with OriginalMessageRefID which
indicates the MessageRefID of the original CRS message, in relation to
which the CRS Status Message is provided.
The MessageRefID identifier can contain whatever information the sender
of the CRS Status Message uses to allow identification of the particular CRS
Status Message but should start with the word “Status”, followed by the
sender country code (i.e. the Competent Authority receiving the original
CRS message) as the first element for Competent Authority to Competent
Authority transmission, then the year to which the data relates, then the
receiver country code (i.e. the sender of the original CRS message) before a
unique identifier.
e.g. StatusFR2013CA123456789

COMMON REPORTING STANDARD STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
 PART A: CRS STATUS MESSAGE XML SCHEMA INFORMATION – 15

Element Attribute Size Input Type Requirement

MessageTypeIndic csm:CrsMessageTypeIndic_EnumType Not used (Optional)

This element is not to be used in the context of the CRS Status Message
XML Schema.
Element Attribute Size Input Type Requirement
CorrMessageRefID Max 200 characters csm:StringMax200Type Not used (Optional)

This element is not to be used in the context of the CRS Status Message
XML Schema.
Element Attribute Size Input Type Requirement
ReportingPeriod xsd:date Not used (Optional)

This element is not to be used in the context of the CRS Status Message
XML Schema.
Element Attribute Size Input Type Requirement
Timestamp xsd:dateTime 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.
Fractions of seconds may be used. Example: 2018-02-15T14:37:40.

II. CRS Status Message

The body of the CRS Status Message is composed of the following three top
elements:
Element Attribute Size Input Type Requirement
OriginalMessage csm:OriginalMessage_Type Validation

The Original Message element indicates the original CRS message (i.e.
which CRS XML file) for which a CRS Status Message is provided. It
specifies the MessageRefID of the original CRS message and the File Meta
Data information.
Element Attribute Size Input Type Requirement
ValidationErrors csm:ValidationErrors_Type Validation

The Validation Errors element indicates if the Competent Authority that has
received the initial CRS message has found errors with respect to that
original CRS message, with the result being either file errors found, record
errors found or no error found.
[If the CRS Status Message XML Schema is used domestically, the CRS
Status Message will be sent from the Competent Authority to the Financial
Institution that provided the original CRS message.]
Element Attribute Size Input Type Requirement
ValidationResult csm:ValidationResult_Type Validation

COMMON REPORTING STANDARD STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
16 – PART A: CRS STATUS MESSAGE XML SCHEMA INFORMATION

The Validation Result element indicates whether the original CRS message
was accepted or rejected by the Competent Authority receiving the original
CRS message.
[If the CRS Status Message XML Schema is used domestically, the CRS
Status Message will be sent from the Competent Authority to the Financial
Institution that provided the original CRS message.]

IIa. Original Message

Element Attribute Size Input Type Requirement
OriginalMessage csm:OriginalMessage_Type Validation

The Original Message element is composed of the Original Message Ref ID

element, which identifies the original CRS message to which the CRS Status
Message relates, and a File Meta Data element, which contains the file meta
data for the file transmission of the original CRS message.
Element Attribute Size Input Type Requirement
OriginalMessageRefID Max 200 csm:StringMax200Type Optional (Mandatory)
characters

The Original Message Ref ID element should contain the unique identifier
of the original CRS message for which this CRS Status Message is
provided. It should be noted that this Original Message Ref ID is not to be
confused with the Message. Message Ref ID in the message head of the
CRS Status Message, as the latter is the unique identifier for this CRS Status
Message.
In case the Original Message Ref ID cannot be read from the CRS XML file
(e.g. the file cannot be decrypted), then this element can be omitted. In all
other cases, this element must be provided. For record error(s), the Original
Message Ref ID element must always be provided.
Element Attribute Size Input Type Requirement
FileMetaData csm:FileMetaData_Type Optional (Mandatory)

The File Meta Data element provides the file meta data information of the
original CRS Message to which this CRS Status Message relates. The
element FileMetaData is mandatory for exchanges between competent
authorities, unless this information is not available to the Competent
Authority that has received the original CRS message.
[The File Meta Data element is optional for domestic use.]

IIa. Original Message – File MetaData

Please note that the File MetaData section may be subject to subsequent
change on the basis of the file preparation steps to be agreed upon with the
supplier of the Common Transmission System, once selected.

COMMON REPORTING STANDARD STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
 PART A: CRS STATUS MESSAGE XML SCHEMA INFORMATION – 17

Element Attribute Size Input Type Requirement

FileMetaData csm:FileMetaData_Type Optional
(Mandatory)

The File Meta Data element contains information about the original
transmission of the CRS message through the CTS. This data includes the
CTS Transmission ID for the original transmission as sent by the sending
Competent Authority, the date and time the transmission was sent through
the CTS, the sender of the original transmission, and the size of the
decrypted, uncompressed CRS message. Accordingly, the File Meta Data
element is composed of:
Element Attribute Size Input Type Requirement
CTSTransmissionID Max 200 csm:StringMax200Type Optional
characters (Mandatory)

The CTS Transmission ID element should specify the CTS Transmission ID

assigned to the original transmission by the CTS when the original CRS
message was transmitted, to the extent the CTS Transmission ID is available
to the receiver of the original CRS message. Including this identifier will
help the sender correlate the CRS Status Message to the original
transmission of the CRS message.
[The CTS Transmission ID element is optional for domestic use.]
Element Attribute Size Input Type Requirement
CTSSendingTimeStamp xsd:dateTime Optional

The CTS Sending Time Stamp element contains the date and time the
original transmission was initially delivered to the receiving Competent
Authority by the CTS. The format for use is YYYY-MM-DD’T’hh:mm:ss.
Fractions of seconds may be used. Example: 2018-02-15T14:37:40.
Element Attribute Size Input Type Requirement
UncompressedFileSizeKBQty xsd:integer Optional

The Uncompressed File Size KB Qty element provides the size of the
decrypted, decompressed payload file (in kilobytes) in which the error
condition triggering the sending of the CRS Status Message was detected.
This optional element may be provided to the Competent Authority that has
sent the original CRS message, if available.

COMMON REPORTING STANDARD STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
18 – PART A: CRS STATUS MESSAGE XML SCHEMA INFORMATION

IIb. Validation Errors

Element Attribute Size Input Type Requirement
ValidationErrors csm:ValidationErrors_Type Validation

The Validation Errors element specifies whether the Competent Authority

that has received the original CRS message has found errors in that original
CRS message.
[If the CRS Status Message XML Schema is used domestically, the CRS
Status Message will be sent from the Competent Authority to the Financial
Institution that provided the original CRS message.]
The Validation Errors element allows providing:
‒ File validation errors;
‒ Record validation errors
If no error is found, both the File Error and Record Error elements should be
omitted.
Element Attribute Size Input Type Requirement
FileError csm:FileError_Type Optional

The File Error element indicates that one or more file errors have been
found in the original CRS message.
Element Attribute Size Input Type Requirement
RecordError csm:RecordError_Type Optional

The Record Error element indicates that one or more record errors have been
found in the original CRS message.

IIb. Validation Errors – File Error

Please note that the File Error Section may be subject to subsequent change
on the basis of the file preparation steps to be agreed upon with the supplier
of the Common Transmission System, once selected.
Element Attribute Size Input Type Requirement
FileError csm:FileError_Type Optional

The File Error element is composed of:

Element Attribute Size Input Type Requirement
Code Max 10 csm:StringMax10Type Validation
characters

In the Code element one appropriate file error code should be entered. The
list of applicable file error codes and their description is contained in Part B
of this User Guide. Only file error codes listed in the latest version of the
aforementioned User Guide may be provided here.

COMMON REPORTING STANDARD STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
 PART A: CRS STATUS MESSAGE XML SCHEMA INFORMATION – 19

Element Attribute Size Input Type Requirement

Details Max 4’000 csm:ErrorDetail_Type Optional
characters

The Details element is a free text field, allowing to further explain the cause
of the error. This element is optional, but any available information to help
with detecting the error source, even if the information is technical (e.g.
XSD validation error codes), should be provided here.
Element Attribute Size Input Type Requirement
Details Language 2-character iso:LanguageCode_Type Optional

In this attribute to the Details element, the language in which the further
details on the error are provided can be specified.

IIb. Validation Errors – Record Error

Element Attribute Size Input Type Requirement
RecordError csm:RecordError_Type Optional

The Record Error element is composed of:

Element Attribute Size Input Type Requirement
Code Max 10 characters csm:StringMax10Type Validation

In the Code element one appropriate record error code should be entered.
The list of applicable record error codes and their description is contained in
Part B of this User Guide. Only record error codes listed in the latest version
of the aforementioned User Guide may be provided here.
Element Attribute Size Input Type Requirement
Details Max 4’000 csm:ErrorDetail_Type Optional
characters

The Details element is a free text field, allowing further explaining the cause
of the error. This element is optional, but any available information to help
with detecting the error source, even if the information is technical should
be provided here.
Element Attribute Size Input Type Requirement
Details Language 2-character iso:LanguageCode_Type Optional

In this attribute to the Details element, the language in which the further
details on the error are provided can be specified.
Element Attribute Size Input Type Requirement
DocRefIDInError Max 200 csm:StringMax200Type Optional
characters

The Doc Ref ID in error element should contain the DocRefID of the record
for which an error was detected. This element can be repeated if the error
concerns more than one record.

COMMON REPORTING STANDARD STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
20 – PART A: CRS STATUS MESSAGE XML SCHEMA INFORMATION

Element Attribute Size Input Type Requirement

FieldsInError csm:StringMax400Type Optional

The Fields in Error element allows listing the fields (i.e. the CRS XML
Schema elements) which are causing the error. The element can be repeated
in case the error is caused by more than one field (e.g the Account Balance
must be zero, if the account was indicated as closed in the Account Closed
attribute). The Fields in Error element is composed of the File Path element.
Element Attribute Size Input Type Requirement
FieldPath Max 400 csm:StringMax400Type Optional
characters

The Field Path element allows specifying the path (i.e. the XPATH without
the namespaces) of the field (i.e. CRS XML Schema element) which is
causing the error. For field-level errors in records of CRS XML files, the
Field Path value will be the complete path to the data element requiring
correction, in the following form:
“/element1/sub-element1.1/ sub-element1.1.1/…/finalsubelement”

Example:
The Address City is missing (for Address Fix). In this case, the Field Path can
be either:
Reporting FI: CRS_OECD/CrsBody/ReportingFI/Address/AddressFix/City
Individual Account Holder:
CRS_OECD/CrsBody/ReportingGroup/AccountReport/AccountHolder/
Individual/Address/AddressFix/City
Organisation Account Holder:
CRS_OECD/CrsBody/ReportingGroup/AccountReport/AccountHolder/
Organisation/Address/AddressFix/City
Controlling Person:
CRS_OECD/CrsBody/ReportingGroup/AccountReport/ControllingPerson/
Individual/Address/AddressFix/City

IIc. Validation Results

Element Attribute Size Input Type Requirement
ValidationResult csm:ValidationResult_Type Validation

The Validation Result element indicates the result of the validation of the
file and the records contained therein by the Competent Authority receiving
the original CRS message and is composed of:
Element Attribute Size Input Type Requirement
Status csm:FileAcceptanceStatus_ Validation
EnumType

COMMON REPORTING STANDARD STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
 PART A: CRS STATUS MESSAGE XML SCHEMA INFORMATION – 21

The Status element contains the result of the message handling by the
receiver. The possible Status values are:
‒ Accepted - The file has been accepted; or
‒ Rejected - The file has been rejected (for further guidance on
acceptance and rejection rules, see the introduction)
Element Attribute Size Input Type Requirement
ValidatedBy csm:StringMax400Type Validation

The Validated By element specifies the version of the tool(s) used for
carrying out the validation process (e.g. a commonly agreed validation tool
for record validations or a country-specific tool). This element can be
repeated.

COMMON REPORTING STANDARD STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
 ANNEX A. CRS STATUS MESSAGE XML SCHEMA DIAGRAMS – 23

Annex A

CRS Status Message XML Schema Diagrams

COMMON REPORTING STANDARD STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
24 – ANNEX A. CRS STATUS MESSAGE XML SCHEMA DIAGRAMS

Message Header [Section I]

For practical reasons, the Transmitting Country and Receiving Country 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 STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
 ANNEX A. CRS STATUS MESSAGE XML SCHEMA DIAGRAMS – 25

Original Message [Section IIa]

COMMON REPORTING STANDARD STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
26 – ANNEX A. CRS STATUS MESSAGE XML SCHEMA DIAGRAMS

Validation Errors – File Error [Section IIb]

For practical reasons, the Language list is based on the ISO 639-1 language 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 STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
 ANNEX A. CRS STATUS MESSAGE XML SCHEMA DIAGRAMS – 27
Validation Errors – Record Error [Section IIb]

For practical reasons, the Language list is based on the ISO

639-1 language 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 STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
28 – ANNEX A. CRS STATUS MESSAGE XML SCHEMA DIAGRAMS
Validation Results [Section IIc]

COMMON REPORTING STANDARD STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
 ANNEX B. GLOSSARY OF NAMESPACES AND FREQUENTLY USED TERMS – 29

Annex B

Glossary of Namespaces and Frequently Used Terms

CRS Status Message XML Schema Namespaces

Namespace Description Filename

csm CRS Status Message types CrsStatusMessageXM
L_v1.0.xsd
iso ISO types (Country& Language codes) isocsmtypes_v1.0.xsd

COMMON REPORTING STANDARD STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
30 – ANNEX B. GLOSSARY OF NAMESPACES AND FREQUENTLY USED TERMS

Frequently Used Terms

Term Definition
CRS Status The CRS Status Message allows to reports errors found on the
Message previously transmitted CRS Message.
FATCA The file error part of the CRS Status Message is the equivalent
Notification of the FATCA Notification.
XML validation XML validation allows validating CRS XML data file against
the CRS XML Schema.
Additional Additional validation allows providing additional checks that
validation are not performed by the XML Validation. Additional
validations include both file validations and record validations.
File validation File validation verifies if the XML file can be received, read
and validated. When file validation is successful, the record
validation can be performed.

Examples of file validation: Failed to download, decrypt,

decompress, check signature, found viruses or threats , failed
XML Validation, etc.
Record Record validation provides additional validation of the CRS
validation data (which are not already validated by the CRS XML Schema
itself).

Examples of record validation: An invalid ISIN Account

Number, a missing validation field, a missing DocRefID (for
future corrections).
File error A file error allows reporting that a CRS XML file has failed the
file validation.
Record error A record error allows reporting that a CRS XML file has failed
the record validation.
Record For the CRS XML Schema, the term record refers to the
correctable records Account Report and Reporting FI. The
correctable records contain a DocSpec (and a DocRefID), thus
allowing for future corrections.
CTS The Common Transmission System, developed under the
auspices of the Forum on Tax Administration and operated
within the framework the Global Forum.

COMMON REPORTING STANDARD STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
 PART B: CRS STATUS MESSAGE ERROR CODES – 31

Part B

CRS Status Message Error Codes

This second part of the CRS Status Message XML Schema User Guide
contains further guidance on the error codes to be used for indicating a file
or record error within the XML Schema. Only such codes explicitly stated in
this section should be provided in the CRS Status Message XML Schema.

I. Validation process

Record errors
For record errors, only one Status Message should be sent for a specific
MessageRefID (i.e. for a specific CRS Report file).

File errors
For file errors, only one Status Message should be sent for a specific
MessageRefID (i.e. for a specific CRS Report file), but a different
CTSTransmissionID should be provided. For example, the first time a file is
sent the Receiving Competent Authority could return the Failed Decryption
error via the Status Message. In such case, XML validation and other sub-
sequent validations have not been performed since the file could not be
decrypted.

II. File Validations (50 000 – 59 999)

Please note that the File Validations section may be subject to subsequent
change on the basis of the file preparation steps to be agreed upon with the
supplier of the Common Transmission System, once selected.

CRS STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
32 – PART B: CRS STATUS MESSAGE ERROR CODES

II.1 Failed Download (50001)

File error code: 50001

Failed Download
File error description:
The receiving Competent Authority could not download the referenced
file.
Action Requested:
Please resubmit the file.

II.2 Failed Decryption (50002)

File error code: 50002

Failed Decryption
File error description:
The receiving Competent Authority could not decrypt the referenced
file.
Action Requested:
Please re-encrypt the file with a valid key and resubmit the file.

II.3 Failed Decompression (50003)

File error code: 50003

Failed Decompression
File error description:
The receiving Competent Authority could not decompress the
referenced file.
Action Requested:
Please compress the file (before encrypting) and resubmit the file.

II.4 Failed Signature Check (50004)

File error code: 50004

Failed Signature Check
File error description:
The receiving Competent Authority could not validate the digital
signature on the referenced file.

COMMON REPORTING STANDARD STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
 PART B: CRS STATUS MESSAGE ERROR CODES – 33

Action Requested:
Please re-sign the file with the owner’s private key using procedures [as
defined in the context of the CTS].

II.5 Failed Threat Scan (50005)

File error code: 50005

Failed Threat Scan
File error description:
The receiving Competent Authority detected one or more potential
security threats within the decrypted version of the referenced file. Such
threats include but are not limited to hyperlinks, Java script, and
executable files.

Action Requested:
Please scan the file for known threats and viruses, remove all detected
threats and viruses prior to encryption and re-encrypt and resubmit the
file.

II.6 Failed Virus Scan (50006)

File error code: 50006

Failed Virus Scan
File error description:
The receiving Competent Authority detected one or more known viruses
within the decrypted version of the referenced file.

Action Requested:
Please scan the file for known threats and viruses, remove all detected
threats and viruses prior to encryption, and re-encrypt and resubmit the
file.

II.7 Failed Schema Validation (50007)

File error code: 50007

Failed Schema Validation
File error description:
The referenced file failed validation against the CRS XML Schema.

CRS STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
34 – PART B: CRS STATUS MESSAGE ERROR CODES

Action Requested:
Please re-validate the file against the CRS XML Schema, resolve any
validation errors, and re- encrypt and resubmit the file.

II.8 Invalid MessageRefID format (50008)

File error code: 50008

Invalid MessageRefID format
File error description:
The structure of the MessageRefID is not in the correct format, as set
out in the CRS User Guide.
The CRS User guide indicates that the MessageRefID can contain
whatever information the sender uses to allow identification of the
particular report but should 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. FR2013CA123456789).
Action Requested:
Please ensure the MessageRefID follows structure defined in the CRS
User guide, and resubmit the file.

II.9 MessageRefID has already been used (50009)

File error code: 50009

MessageRefID has already been used
File error description:
The referenced file has a duplicate MessageRefID value that was
received on a previous file.

Please do not submit a request to correct or delete any of the records in

this file until you receive a CRS Status Message that this file has been
received as valid (Status is Accepted).

Action Requested:
Please replace the MessageRefID field value with a unique value (not
containing all blanks), and resubmit the file.

COMMON REPORTING STANDARD STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
 PART B: CRS STATUS MESSAGE ERROR CODES – 35

II.10 File Contains Test Data for Production Environment

(50010)

File error code: 50010

File Contains Test Data for Production Environment
File error description:
The referenced file contains one or more records with a DocTypeIndic
value in the range OECD10-OECD13, indicating test data. As a result,
the receiving Competent Authority cannot accept this file as a valid CRS
file submission.

For more information on the DocTypeIndic data element, please consult

the CRS User Guide.

Action Requested:
If this file was intended to be submitted as a valid CRS file, please
resubmit with DocTypeIndic values in the range OECD0-OECD3 (see
CRS User guide). [If this file was intended as a test file, please submit to
the CTS test environment during an agreed test window.]

II.11 File Contains Production Data for Test Environment

(50011)
File error code: 50011
File Contains Production Data for Test Environment
File error description:
The referenced file was received in a test environment with one or more
records having a DocTypeIndic value in the range OECD0-OECD3.
These DocTypeIndic values indicate data in this file may have been
intended as a valid CRS file submission. CRS messages received in test
environments are not accepted by the receiving Competent Authority as
a valid CRS file submission. Submissions to the test environment should
only include records with DocTypeIndic in the range OECD10-
OECD13, indicating test files.

Action Requested:
If this file was intended to be submitted as a valid CRS file, please
resubmit with DocTypeIndic values in the range OECD0-OECD3. If
this file was intended as a test file, please correct the DocTypeIndic for
all records and resubmit to the CTS test link.

CRS STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
36 – PART B: CRS STATUS MESSAGE ERROR CODES

II.12 The received message is not meant to be received by the

indicated jurisdiction (50012)
File error code: 50012
The received message is not meant to be received by the indicated
jurisdiction
File error description:
The records contained in the CRS payload file are not meant for the
receiving Competent Authority, but should have been provided to
another jurisdiction.

Action Requested:
The file is to be immediately deleted by the initial, erroneous receiver
and that receiving Competent Authority will promptly notify the sending
Competent Authority about the erroneous transmission through the CRS
Status Message XML Schema.

II.13 An incorrect AES key size was detected by the receiving

jurisdiction (50013)
File error code: 50013
The AES key size has been detected as incorrect by the receiving
jurisdiction
File error description:
The recipient has detected one or more of the following errors:
‒ Data packet transmitted with ECB cipher mode
(or any cipher mode other than CBC)
‒ Data packet does not include IV in Key File
‒ Data packet key size is not 48 bytes
‒ Data packet does not contain the concatenated key and IV.
Action Requested:
The sending Competent Authority should resend the file (newly
encrypted, with a new unique MessageRefID and with the correct AES
key size).

COMMON REPORTING STANDARD STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
 PART B: CRS STATUS MESSAGE ERROR CODES – 37

III. Record Validations

In the context of the CRS XML Schema, the following validations are to be
applied at record level.

IIIa. Record Validations – CRS data fields (60 000 – 69 999)

All the below elements must be present and filled in the CRS XML Schema.
In case one of the elements is missing, the record error can be notified to the
sending Competent Authority by specifying the corresponding error code in
the CRS Status Message.

Record Validations – CRS data fields

Record Validation name Validation description
Error
Code
60000 Account Number The Account Number must follow the
IBAN IBAN structured number format when the
Account Number type= OECD601 –
IBAN.
60001 Account Number The Account Number must follow the
ISIN ISIN structured number format when the
Account Number type= OECD603 – ISIN.
60002 Account Balance The account balance entered was less than
zero. This amount must be greater than or
equal to zero.
60003 Account Balance The Account Balance must be zero if
and Closed account was indicated as closed in the
account account closed attribute.
60004 Person.Name type Name type selected is invalid, i.e.
invalid corresponds to the value not used for CRS:
OECD201= SMFAliasOrOther

CRS STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
38 – PART B: CRS STATUS MESSAGE ERROR CODES

Record Validations – CRS data fields (Continued)

Record Validation name Validation description
Error
Code
60005 Controlling Person When the Account Holder is an
type must be Organisation and the "Account Holder
omitted Type" is CRS102 or CRS103, the
"Controlling Person Type" must be
omitted. (CRS102= CRS Reportable
Person; CRS103= Passive Non-Financial
Entity that is a CRS Reportable Person)
60006 Controlling Person When the Account Holder is an
must be provided Organisation and the "Account Holder
Type" is CRS101, the "Controlling
Person" must be provided. (CRS101=
Passive Non-Financial Entity with - one or
more controlling person that is a
Reportable Person)
60007 Reporting Group The Reporting Group cannot be repeated.
60008 Sponsor Sponsor cannot be provided.
60009 Intermediary Intermediary cannot be provided
60010 Pool Report Pool Report cannot be provided.
60011 Verify data sorting When the Person is a Controlling Person
Person or an Individual Account Holder, at least
ResCountry Code one of the according ResCountryCodes
must match the Message Receiving
Country Code
60012 Verify data sorting At least one of either the Entity Account
Organisation Holder ResCountryCode or Controlling
ResCountry Code Person ResCountryCode must match the
Message Receiving Country Code.
60013 Verify data sorting ReportingFI.ResCountryCode should
ReportingFI. always be provided and it must match the
ResCountry Code Message Sending Country Code
60014 BirthDate Date of birth should be in a valid range
(e.g. not before 1900 and not after the
current year).

COMMON REPORTING STANDARD STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
 PART B: CRS STATUS MESSAGE ERROR CODES – 39

Record Validations – CRS data fields (Continued)

Record Validation name Validation description
Error
Code
60015 AccountReport AccountReport can only be omitted if
ReportingFI is being corrected/deleted or,
in the case of domestic reporting, if there
is nil reporting. If the ReportingFI
indicates new data or resent, then
AccountReport must be provided.

CRS STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
40 – PART B: CRS STATUS MESSAGE ERROR CODES

IIIb. Record Validations – Missing validation or mandatory

fields (70 000 – 79 999)
The purpose of the validations listed below is to verify that Validation or
Mandatory elements are not missing:
For all Validation fields, an empty value and a blank space are unacceptable.
For all Mandatory fields, in case value is provided, an empty value and a
blank space are unacceptable. If no value is provided, the element should be
omitted.

Record Validations – Missing validation or mandatory fields

Record Element name Validation or
Error Mandatory field
Code
70000 Message.MessageRefID Validation.
70001 Individual Account Holder. TIN Mandatory
70002 Individual Account Holder. Name. Validation
FirstName Note: Use “NFN” for
No First Name.
70003 Individual Account Holder. Name. Validation
LastName
70004 Individual Account Holder. Address. Validation
AddressFix.City If AddressFix is
selected
70005 Individual Account Holder. Address. Validation
AddressFree If AddressFree is
selected
70006 Controlling Person. TIN Mandatory
70007 Controlling Person. Name. FirstName Validation
Note: Use “NFN” for
No First Name.
70008 Controlling Person. Name. LastName Validation
70009 Controlling Person. Address. Validation
AddressFix.City If AddressFix is
selected
70010 Controlling Person. Address. Validation
AddressFree If AddressFree is
selected
70011 Organisation Account Holder.IN Mandatory
70012 Organisation Account Holder.Name Validation

COMMON REPORTING STANDARD STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
 PART B: CRS STATUS MESSAGE ERROR CODES – 41

Record Validations – Missing validation or mandatory fields

(Continued)
Record Element name Validation or
Error Mandatory field
Code
70013 Organisation Account Holder. Validation
Address. AddressFix.City If AddressFix is
selected
70014 Organisation Account Holder. Validation
Address. AddressFree If AddressFree is
selected
70015 ReportingFI .IN Mandatory
70016 ReportingFI.Name Validation
70017 ReportingFI. Address. Validation
AddressFix.City If AddressFix is
selected
70018 ReportingFI. Address. AddressFree Validation
If AddressFree is
selected
70019 AccountNumber Validation
Note: Use “NANUM”
for No Account
Number.

CRS STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
42 – PART B: CRS STATUS MESSAGE ERROR CODES

IIIc. Record Validation – Fields used for the correction

process (80 000 – 89 999)
The record error codes indicate errors that have been detected in the context
of the correction of previously sent records.

Record Validation – Fields used for the correction process

Record Validation Validation description
Error name
Code
80000 DocRefID The DocRefID is already used for another
already used record.
80001 DocRefID The structure of the DocRefID is not in the
format correct format, as set out in the User Guide.
80002 CorrDocRefId The CorrDocRefId refers to an unknown
unknown record.
80003 CorrDocRefId The corrected record is no longer valid
no longer valid (invalidated or outdated by a previous
correction message). As a consequence, no
further information should have been received
on this version of the record.
80004 CorrDocRefId The initial element specifies a CorrDocRefId.
for new data
80005 Missing The corrected element does not specify any
CorrDocRefId CorrDocRefId.
80006 DocSpec. The CorrMessageRefID is forbidden within
CorrMessage the DocSpec_Type.
RefID
80007 MessageSpec. The CorrMessageRefID is forbidden within
CorrMessage the Message Header.
RefID
80008 Resend option The Resend option may only be used with
respect to the Reporting FI element.
80009 Delete The Reporting FI cannot be deleted without
ReportingFI deleting all related Account Reports.
80010 Message A message can contain either new records
TypeIndic (OECD1) or corrections/deletions (OECD2
and OECD3), but should not contain a
mixture of both.

COMMON REPORTING STANDARD STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017
 PART B: CRS STATUS MESSAGE ERROR CODES – 43

Record Validation – Fields used for the correction process (continued)

80011 CorrDocRefID The same DocRefID cannot be corrected or
twice in same deleted twice in the same message.
message
80012 Reporting A message must not contain data for two
Period different Reporting Periods.

IIId. Record Validation – Error codes reserved for future use

(90 000-97 999)
Record Validation name Validation description
Error
Code
90000 TIN structure The TIN structure in invalid
90001 TIN algorithm The TIN is not invalid against the
algorithm
90002 Invalid TIN The TIN does not have a valid semantic
semantic

IIIe. Record Validation – Domestic error codes

(98 000 – 98 999)
These error codes may be used for domestically defined record errors.

IIIf. Record Validation – Custom error (99 999)

The use of the Custom error code must be agreed bilaterally between the
exchange partners.
Record Validation name Validation description
Error
Code
99999 Custom error The received message contains an error for
which no specific error code exists. The
details must specify what the error is.
Please note, a custom error should not cause the file to be rejected, unless
agreed bilaterally between the exchange partners.

CRS STATUS MESSAGE XML SCHEMA: USER GUIDE FOR TAX ADMINISTRATIONS © OECD 2017