€¦ · Web viewCommon Technical Procedures (Based on the TS-AEOI DAC2-1.11 EU Document) Για λόγους διαφάνειας και καλύτερης επικοινωνίας

COMMON TECHNICAL PROCEDURES

(Based on the TS-AEOI DAC2-1.11 EU Document)

Για λόγους διαφάνειας και καλύτερης επικοινωνίας δημοσιεύεται τμήμα των τεχνικών οδηγιών της ΕΕ προς τα κράτη μέλη. Οι οδηγίες αφορούν τη δημιουργία τροποποιητικών αναφορών DAC2/CRS και παραδείγματα τέτοιων υποβολών και εφαρμόζονται κατά την ανταλλαγή στοιχείων μεταξύ των κρατών μελών.

Κατ’ αντιστοιχία και για την ανάγκη απλοποίησης του συστήματος θα ισχύουν και για την υποβολή τροποποιητικών από τα υπόχρεα ελληνικά Χρηματοπιστωτικά Ιδρύματα προς την ΑΑΔΕ. Επειδή οι οδηγίες αφορούν κράτη μέλη σε πολλά σημεία αναφέρεται ως αποστέλλων την αναφορά το SS (Sending Member State). Όσον αφορά τις αναφορές που αποστέλλονται προς την ΑΑΔΕ που SS εννοείται αποστέλλων χρηματοπιστωτικό ίδρυμα. Τα υποδείγματα των αναφορών που αναφέρονται στο συμπιεσμένο αρχείο CorrectionXMLExamples.zip που δημοσιεύεται στον ιστότοπο της ΑΑΔΕ μαζί με το παρών κείμενο.

1 TERMINOLOGY

1.1 ABBREVIATIONS AND ACRONYMS

Definition Meaning

AEOI Automatic Exchange of Information

Art. Article

ASCII American Standard Code for Information Interchange

BOM Byte Order Mark: a Unicode character to signal whether a text file is big or little endian

BR Business Rule

CACT Committee on Administrative Cooperation for Taxation

CCN Common Communication Network

CDE Common Data Element

COA Confirm on Arrival

COD Confirm on Delivery

CRS Common Reporting Standard

CSI Common System Interface

DAC Directive on Administrative Cooperation

DG TAXUD Directorate-General Taxation and Customs Union

DT Data Type

EC European Commission

EU European Union

FA Financial Account

FATCA Foreign Account Tax Compliance Act

FI Financial Institution

FIS FISCALIS Information Systems

FITS FISCALIS Information Technology Services

FITSDEV3 FITS Development

FS Functional Specifications

IBAN International Bank Account Number

ID Identifier

IT Information Technology

ITSM IT Service Management

ISO International Organization for Standardization

LCT Local Client Testing

LDM Logical Data Model

LST Local Server Testing

MB Megabyte

Definition Meaning

MS Member State

MSA MS Administration

MSG Message

N/A Not Applicable

NA National Administration

NFE Non-Financial Entity

OBAN Other Bank Account Number

OECD Organisation for Economic Cooperation and Development

PDM Physical Data Model

PK Primary Key

RCT Remote Conformance Testing

RIT Remote Interoperability Testing

RR Receiving MS - MS receiving a MSG (any type of MSG) whatever the process

SC Specific Contract

SD System Design

SS Sending MS - MS sending a MSG (any type of MSG) whatever the process

TIN Tax Identification Number

ToC Terms of Collaboration

TS Technical Specifications

UTC Coordinated Universal Time

VAT Value Added Tax

VIES VAT Information Exchange System

XML Extensible Mark-up Language

XSD XML Schema Definition

2 COMMON TECHNICAL PROCEDURES

2.1 COMMON APPROACH FOR PASSIVE NFEIn the case of an account held by a Passive NFE that is a reportable Person and that is also identified as having in the same MS, one or more Controlling Persons, that is a reportable person, the SS must report the information related to the Passive NFE and each Controlling Person. The CRS has described two approaches as regards how to report such a situation. The system will accept the two approaches. However in order to improve the communication between MS, and have a common understanding, it is recommended to follow the second approach described in the CRS and also explained in this section.

The approach consists of reporting the account:

as an account held by a passive NFE with one or more controlling person that is a reportable person where the element AcctHolderType of the element AccountHolder (see section Error: Reference source not found) must be set to CRS101;

and also as an account held by a passive NFE that is a reportable person where the element AcctHolderType of the element AccountHolder (see section Error:Reference source not found) must be set to CRS103.

The Table 1 describes all the possible values for the element AcctHolderType for a Passive NFE with one or more controlling persons and the recommended approach is highlighted in light green.

Passive NFE

Is a reportable person Is NOT a reportable person

Con

trol

ling

Pers

on

Is a reportable person

Two records: CRS101; CRS103.

One record: CRS10

1.

One record: CRS101.

Is NOT a reportable person

One record: CRS103.

Not Applicable

Table 1: Account holder type to use for a Passive NFE

2.1.1 EXAMPLE

The example relies on the schema defined in section Error: Reference source not found.

It covers the following scenario:

A Financial Institution in MS A has an account held by a Passive NFE, MS B resident, with three controlling persons: two of them are MS B residents and the third is MS C resident.

The Financial Institution reports to his competent authority this Financial Account information;

In this case the SS sends two Initial messages, one for MS B and another for MS C. The message towards MS C contains one account including the Passive NFE as holder of type CRS101 and the MS C controlling person. The message towards MS B contains two accounts. The first one contains only the Passive NFE as holder of type CRS103 and the second one contains the Passive NFE as holder CRS101 with the two MS B controlling persons. Figure 11 highlights this.

1 The figure omits most of the data, and only highlights the main areas of interest.

<CRS_OECD>

Initial message - MS B

<CrsBody>

<ReportingFI>

<ReportingGroup>

<AccountReport>

<ControllingPerson>

<ControllingPerson>

Initial message - MS C

<ResCountryCode> = MS B


<AccountReport>

<AccountHolder>

<Organisation>


<AcctHolderType>=CRS103

<AccountHolder>

<Organisation>



<CRS_OECD>

<CrsBody>

<ReportingFI>

<ReportingGroup>

<AccountReport>

<ControllingPerson>

<ResCountryCode> = MS C

<AccountHolder>

<Organisation>



Figure 1: Re-send all child elements

The following example files, in the order they are presented, provide concrete messages for this scenario:

NFE-Example-Init-MSB.xml NFE-Example-Init-MSC.xml

2.2 MODIFICATIONS TO SENT DATA

In the course of the exchange of messages, the SS may need to amend data previously sent. The section describes how the system should specify these changes through the correction mechanism (section 2.2.1) and how corrections and deletions can be used together (section 2.2.2).

The message is just an envelope, for a specific reporting period, which contains a set of records. The message has no business meaning. Concretely, this means that all the records

of the message concern the same reporting period and the message is accepted or rejected as a unit of work.

2.2.1 CORRECTION MECHANISM

The system supports corrections. This section describes the possible situations and presents how to handle them.

2.2.1.1 REASONS FOR CORRECTION

The following kinds of error may justify the need for a correction:

Invalid syntax: the structure of the received file is not valid. For example, the file is not in XML format, is not well-formed XML or does not match the schema described in this document;

Invalid semantic: the received file contains errors related to business rules that are not checked by the XSD (for example, the format of the Account Number), or related to other unexpressed business rules (for example, a person residing in Valencia, Italy while Valencia is actually in Spain). These rules can further be divided in the following categories:

o The error is picked up automatically by the validation module;o The error is found by a member of the RR MSA after the system has

processed and integrated the message;o The error is found by the SS but not yet by the RR.

If the validation module encounters one or more syntax errors, the RR ignores the received file and returns a status message with the found errors (see section Error: Reference sourcenot found). The SS must then correct its implementation and send back the message. Since the first message was ignored, a correction message is not needed (unless the file was already a correction, in which case the new file remains of the same type). For traceability purposes, the new message must have a different MessageRefId than the rejected one, even if it mostly holds the same content.

If the validation module encounters one or more semantic or technical errors (see section Error: Reference source not found), the RR can decide how it wishes to proceed. If the error is deemed grave enough, it rejects the message, and it and the SS proceeds as if there was a syntax error (i.e. the RR ignores the file and the SS must send a new one). If the errors are not considered as grave, the RR integrates the data in its national system and sends a Status message indicating acceptance of the received message, but mentioning the detected errors. Note that the RR must accept or reject the message as a whole, and cannot integrate only part of the data while indicating an error.

Whenever possible, the RR should reply with as many errors as possible, not stopping at the first one (e.g. two business rule errors would lead to a single Status message with two errors). However, since an error in message syntax compromises the parsing of all data after the location of the error, it may be that only part of the errors can be reported during a first pass through the message. Further errors would then be detected once the first ones have been corrected.

If a semantic error is found after the system has processed and integrated the message into the database, the SS should spontaneously send a correction message as described in the following sections.

2.2.1.2 CORRECTABLE ELEMENTS

Only the top-level element is correctable. In the XSD, there are two top-level elements, the ReportingFI and the AccountReport. The system must consider these two top-level elements separately. The correction of one of the two top-level elements must not impact the other related top-level element.

If a correction targets a previously sent child element of a top-level element, the system must re-send the related parent top-level element and all its children. This is applicable for ReportingFI and AccountReport. This results in a waste of space when the correction concerns only part of the information, but it has the following advantages:

Since the top-level element is self-contained, the validation does not need access to the database in order to check that the correction does not violate business rules;

The SS can generate the correction with only minor changes to the routines already used to generate the Initial messages;

The RR can easily integrate the correction by invalidating separately for each top-level element the previously recorded information, and then call the routines already used to integrate the Initial messages;

This procedure does not require a specific XSD for the sake of corrections.

In order to be able to identify the elements to correct, the definition of these top-level elements includes an element of type Error: Reference source not found, which include elements named DocTypeIndic, DocRefId and CorrDocRefId. For a Correction message, the system allows the following combinations of DocTypeIndic for the correctable elements, taking into account that the AccountReport element is not mandatory:

w/o AccountRepo

rtAccountReport

- OECD1 OECD2 OECD3 OECD0

ReportingFI

OECD1

OECD2 OK OK OK

OECD3 OK OK

OECD0 OK OK

Table 2: Combinations of DocTypeIndic for the correctable elements within a Correction message

When a correction targets only the AccountReport element and there is no modification of the related ReportingFI, the DocTypeIndic “OECD0-Resend Data” is used for the ReportingFI element. This type is only allowed for ReportingFI element.

If the validation module encounters another combinations than these presented above, the RR ignores the received file and returns a status message with the relevant technical error code (see section Error: Reference source not found).

2.2.1.3 STRUCTURE OF A CORRECTION MESSAGE

A correction message has essentially the same structure as an Initial message, as it follows the same schema. There is only a minor difference in the Header: the MessageTypeIndic must be set to CRS702.

There are also three differences in the Body:

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

Regarding the ReportingFI, the DocTypeIndic will have for value OECD2/OECD3 if it has been modified/deleted since the previous sending, OECD0 if the ReportingFI was not modified (split of message or late reporting for example);

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 (section Error: Reference source not found), 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 and also resent ReportingFIs (OECD0) but not new data (OECD1).

2.2.2 RELATIONSHIP BETWEEN MESSAGES

This section describes how messages exchanged through the correction mechanism described above interact with one another.

Since messages specify the reporting period for which it relates, a correction message may correct records originating from any previous Initial or Correction messages for the same reporting period.

2.2.2.1 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 was not correct (from a technical point or business point of view), or to delete elements from the Initial message.

A unique MessageRefId is created respecting the format defined in the section Error:Reference source not found.

A new DocRefId is created for each correctable element and should follow the format described in section Error: Reference source not found.

The CorrDocRefId must reference the DocRefId of the elements to be corrected / deleted from the Initial message.

2.2.2.2 CORRECTION OF A CORRECTION MESSAGE

Corrections of corrections are legitimate. In that case, the CorrDocRefId of the second correction of the entity must reference the DocRefId of the first correction.

This is required in order to determine uniquely the order in which the RR system must apply the corrections. Suppose two corrections reference the same entity and, for some technical reason (e.g. infrastructure or architecture constraints), arrive out of order2. The RR system would first integrate the second correction, then the first one, effectively dismissing the second (and most recent) correction.

If the RR 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 some time later3. If such a message does not arrive, it should contact the SS using the Send (Technical) Query Operational Procedure defined in the Terms of Collaboration [Error: Reference source not found].

2.2.2.3 ERROR HANDLING

If the SS does not respect any of the above constraints, the RR must reply with a Status message mentioning that the corrected entity is not known or not valid anymore (see section Error: Reference source not found), depending on the available information.

2.2.3 EXAMPLES

The following sections provide examples of concrete correction scenarios, and highlight correction rules applicable to each of them. The examples rely on the schema defined in section Error: Reference source not found.

Each example presents one or more figures to illustrate the situation. These figures omit most of the data, and only highlight the main areas of interest.

Each example is illustrated by one or more XML messages. The Table 3 lists the XML messages annexed to this document, and indicates to which section they relate.

# File Section(s)

1 Correction-Example-Init-2AR1FI.xml 2.2.3.1, 2.2.3.2, 2.2.3.8

2 Correction-Example-Corr-TwoSuc-1.xml 2.2.3.1, 2.2.3.2

3 Correction-Example-Corr-TwoSuc-2.xml 2.2.3.1

4 Correction-Example-Corr-TwoSuc-3.xml 2.2.3.2

5 Correction-Example-Init-MultiCP-1.xml 2.2.3.5

2 CCN, for example, does not offer a guarantee that messages will be delivered in order.3 The actual effort to put in this procedure is left at the appreciation of the MS. Since this event is possible but very unlikely, it is probably not useful to build a complex automated system to resolve this issue.

# File Section(s)

6 Correction-Example-Init-MultiCP-2.xml 2.2.3.5

7 Correction-Example-Corr-MultiCP-1.xml 2.2.3.5

8 Correction-Example-Corr-MultiCP-2.xml 2.2.3.5

9 Correction-Example-Init-1AR1FI.xml 2.2.3.3, 2.2.3.6, 2.2.3.9, 2.2.3.10, Error: Reference source not found

10 Correction-Example-Corr-CorrChild.xml 2.2.3.3

11 Correction-Example-Init-2AR1FI-2.xml 2.2.3.4

12 Correction-Example-Corr-2CorrElement.xml 2.2.3.4

13 Correction-Example-Init-2AR1FI-3.xml 2.2.3.7, Error: Reference source not found

14 Correction-Example-Corr-RemChild-FI.xml 2.2.3.7

15 Correction-Example-Corr-RemTopLevel.xml 2.2.3.8

16 Correction-Example-Corr-AddChild.xml 2.2.3.9

17 Correction-Example-Init-1AR1FI-2.xml 2.2.3.10

Table 3: Annexed XML messages

In the examples below the following convention has been used to highlight the elements that need to be corrected or just resent:

The green colour is used when the ReportingFI 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 ReportingFI and the code OECD0 is used. It is worth to note that the RR must not persist the information related to the ReportingFI;

The red colour is used to identify the elements that require to be corrected (Initial message) or are corrected (Correction message).

2.2.3.1 TWO SUCCESSIVE CORRECTIONS OF THE SAME ACCOUNT

This example covers the following scenario:

The SS sends an Initial message with one financial institution and two accounts; It then sends a first Correction message correcting the payment amount of the first

account; It finally sends a second Correction message, correcting the account balance yet

again for the first account.

There are four areas of interest here highlighted by Figure 2:

The CorrDocRefId of the account refers to the immediately preceding entity, not to any preceding one (in particular, not systematically to the first one);

The DocTypeIndic of the account is set to OECD1 within an Initial message and to OECD2 within a Correction message;

The SS must always resend the financial institution (according to the XSD, see section Error: Reference source not found) associated to the account 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 entity;

The SS must only resend the corrected account. The second one, which does not require corrections, is not part of the Correction message.

Figure 2: Two successive corrections of the same account.


Correction-Example-Init-2AR1FI.xml; Correction-Example-Corr-TwoSuc-1.xml; Correction-Example-Corr-TwoSuc-2.xml.

2.2.3.2 TWO SUCCESSIVE CORRECTIONS OF DATA FROM THE SAME MESSAGE


The SS sends an Initial message with one financial institution and two accounts; It then sends a first Correction message correcting the address of the financial

institution; It finally sends a second Correction message, correcting the first account (new

account payment).

Figure 3 highlights the three areas of interest:

The SS must always resend the financial institution (according to the XSD, see section Error: Reference source not found) associated to the account 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 entity;

The SS must only resend the corrected account. The other one, which does not require corrections, is not part of the Correction message;

The SS can send the corrected financial institution without the accounts if they do not require corrections.

Figure 3: Two successive corrections of data from the same message


Correction-Example-Init-2AR1FI.xml; Correction-Example-Corr-TwoSuc-3.xml; Correction-Example-Corr-TwoSuc-1.xml.

2.2.3.3 CORRECTION OF A CHILD ELEMENT OF THE ACCOUNTREPORT ELEMENT


The SS sends an Initial message with a financial institution, and an account composed of a number, an holder, two controlling persons residing within the same country and a balance;

It then wants to correct the address of the first controlling person.

In this case, the SS must correct the account from the Initial message, and send it back with the corrected controlling person data. It must also include the financial institution since this element is mandatory, as well as the second controlling person, the number, the holder and the balance; even though they did not require modifications (omitting it would lead to confusion with the example from section 2.2.3.4). Figure 4 highlights this.

Figure 4: Re-send all child elements


Correction-Example-Init-1AR1FI.xml; Correction-Example-Corr-CorrChild.xml.

2.2.3.4 CORRECTION OF TWO CORRECTABLE ELEMENTS WITHIN THE SAME MESSAGE


The SS sends an Initial message containing two accounts and the associated financial institution. The first account is composed of a number, an holder, a controlling person and a balance. The second account is composed of a number, an holder and a balance. The financial institution is composed of a name and an address;

It then wants to correct the address of the financial institution and the balance of the first account.

In this case, the SS must correct the financial institution and the first account from the Initial message. The financial institution must contain the corrected address as well as the name. The first account must contain the corrected balance, as well as the number, the holder and the controlling person. The second account is not re-sent. Figure 5 highlights this.

Figure 5: Correction of the two correctable elements within the same message


Correction-Example-Init-2AR1FI-2.xml; Correction-Example-Corr-2CorrElement.xml.

2.2.3.5 CORRECTION OF A PERSON CONTROLLING AN ORGANISATION TOGETHER WITH PERSONS FROM OTHERS MSS.


The financial institution reports to his competent authority, an account whose holder is a Passive NFE with two controlling persons from different MSs. Both controlling persons are reportable persons;

Then the SS sends two Initial messages, one per country of residence for tax purposes of the controlling persons;

Finally the financial institution reports a corrected controlling person for the account sent initially.

In this case, the SS must correct the account with the corrected controlling person. Since the ControllingPerson is not a correctable element, the system cannot determine directly in the information received if there was a change. Therefore the SS must send the account to all countries who received it initially even if the controlling person does not require modification. The financial institution is also included since this element is mandatory. Figure 6 highlights this.

Figure 6: Controlling Persons from different MSs


Correction-Example-Init-MultiCP-1.xml Correction-Example-Init-MultiCP-2.xml Correction-Example-Corr-MultiCP-1.xml Correction-Example-Corr-MultiCP-2.xml

2.2.3.6 REMOVAL OF A CHILD ELEMENT OF THE ACCOUNTREPORT


The SS sends an Initial message with a financial institution, and an account composed of a number, an holder, two controlling persons and a balance;

It then wants to remove the first controlling persons.

In this case, the SS must correct the account from the Initial message, and send it back without the deleted controlling person but with the other controlling person, the number, the holder, the balance and the financial institution since this element is mandatory. Figure 7 highlights this.

Figure 7: AccountReport-Omit removed children


Correction-Example-Init-1AR1FI.xml; Correction-Example-Corr-RemChild.xml.

2.2.3.7 REMOVAL OF A CHILD ELEMENT OF THE REPORTINGFI


The SS sends an Initial message with two accounts and the associated financial institution having a name and two addresses;

It then wants to remove the second address of the financial institution.

In this case, the SS must correct the financial institution from the Initial message, and send it back without the deleted address but with the other address, and the name. The accounts are not re-sent. Figure 8 highlights this.

Figure 8: ReportingFI-Omit removed children


Correction-Example-Init-2AR1FI-3.xml; Correction-Example-Corr-RemChild-FI.xml.

2.2.3.8 REMOVAL OF A TOP-LEVEL ELEMENT


The SS sends an Initial message with two accounts and the associated financial institution. Each account is composed of a number, an holder and a balance;

It then wants to remove the first account.

In this case, the SS must correct the first account indicating that it must be deleted (DocTypeIndic is set to OECD3), omit the second account since it does not require corrections, and send it back with the child elements of the corrected account as well as the financial institution since this element is mandatory. Figure 9 highlights this.

Figure 9: AccountReport-Removal top-level element


Correction-Example-Init-2AR1FI.xml; Correction-Example-Corr-RemTopLevel.xml.

An exception can occur for the removal of a Top-level element if the correction message removes only the financial institution without the associated accounts. In this case, the system must not allow this operation because it does not make sense to keep the account(s) without the corresponding financial institution. The system must thus answer with a rejection Status message, using the appropriate error code (section Error: Reference source not found).

It is also worth to note that the removal of a financial institution is persisted only if all the associated accounts have been already removed.

2.2.3.9 CREATION OF A CHILD ELEMENT


The SS sends an Initial message containing an account and the associated financial institution. The account is composed of a number, an holder and a balance;

It then wants to add a payment to that account.

In this case, the SS must correct the account from the Initial message specifying a new payment and send it back with the number, the holder, the balance and the financial institution since this element is mandatory. Figure 10 highlights this.

Figure 10: Create a child element


Correction-Example-Init-1AR1FI.xml; Correction-Example-Corr-AddChild.xml.

2.2.3.10 CREATION OF A NEW TOP-LEVEL ELEMENT FOR THE ACCOUNTREPORT


The SS sends an Initial message with one account and the associated financial institution;

It then wants to send another account.

In this case, the SS creates a new Initial message, with only the new account and the already sent financial institution.. Figure 11 highlights this.

Figure 11: Creation of a new top-level element for the AccountReport


Correction-Example-Init-1AR1FI.xml; Correction-Example-Init-1AR1FI-2.xml.

This scenario does occur only in specific circumstances such as late reporting or in the case of split messages.

Documents

€¦ · Web viewCommon Technical Procedures (Based on the TS-AEOI DAC2-1.11 EU Document) Για λόγους διαφάνειας και καλύτερης επικοινωνίας