Wednesday, August 5, 2015

CRS tax information exchange: an example

An account maintained by bank X resident in member state 1 is held jointly by three persons:

1) Natural person A, resident for tax purposes in member state 1 and member state 2 (MS1, MS2)

2)Natural person B, resident for tax purposes in MS2 and MS3

3) Passive non financial entity C, a resident for tax purposes of MS3 and MS4. C has two controlling persons:
a) D, a resident for tax purposes of MS4 and MS5
b) E, a resident for tax purposes of MS5 and MS6.

To summarize dramatis personae

Name Type Tax resident where
X Financial Institution MS1
A Natural Person MS1, MS2
B Natural Person MS2, MS3
C Passive Non Financial Entity MS3, MS4
D Natural Person MS4, MS5
E Natural Person MS5, MS6

 

We did not call C a legal person, because not all legal persons are Reportable Persons, i.e. publicly traded companies or government entities are exempted. Furthermore, only entities that receive passive income (whatever that is) need to be reported.

How does the bank know where an Account Holder is resident for tax purposes or wind2whether a non-financial entity conducts and active business? Self-certification by the Account Holder. The bank will ask its account holders: where are you a tax resident and do you conduct an active business and will report the Account Holder depending on the response.

Bank X will send one report to its domestic competent authority. This report will contain four Account Reports each report detailing the Account Number with the account balance as of December 31, as well as interests and dividends received and proceeds of sales and redemptions of Financial Assets.

The Account Report will further contain the Account Balances  as well as the Account Holders A, B, C, and C.

That C is reported twice seems odd. The first time C is being reported as an entity, the second time C is being reported as being controlled by D and E. The OECD Commentary to the CRS however allows that the account balance be attributed to the NFE and to the persons controlling the NFE. This is the approach mandated for the EU. Hence, C as a passive NFE is being reported twice.

As an aside: Each account holder will be reported separately and not as one of the many owners of one Bank Account, i.e. the FI cannot send one Account Report listing all the Account Holders, rather, each Account Holder will be reported in a separate Account Report. The domestic competent authority will extract 8 messages from the report provided by bank X. One to each of the 6 member states for natural persons A, B, D, E and two for passive NFE C, which will be delivered to MS3 and MS4.

How to keep information unique under CRS Millions of messages containing bank account information of several account holders will be exchanged. All these messages and account reports need to be identified by tags that are unique in time and space, i.e. they are only allowed to exist once. How does the CRS, the EU and the OECD go about making sure, that messages and bank account information are truly unique ?

The CRS User Guide defines MessageRefID as a mandatory data element that ”is a free text field capturing the sender’s unique identifying number (created by the sender) that identifies the particular message being sent.” [Purple book p.234] Having each financial institution and competent authorities generate a random MessageRefID might lead to collision, i.e. the same number is generated several times. The provisions of the CRS regarding the generation of unique ID is phrased in very soft language:

For exchanges between Competent Authorities, the first part should be the 000000country code of the sending jurisdiction, the second part the year to which the data relates and the third part the receiving country code, before a unique identifier created by the sending jurisdiction (the “national part”).

The EU proposal similarly abstains from compulsion when suggesting the following format:

MemberStateX_20161231_9999_20170430235959.

The EU recommends that the various fields be separated by an underscore for easier reading. MemberStateX is the country code of the jurisdiction receiving a domestic report. The country code could be entered according to the OECD schema (isocrstypes_v1.0.xsd ) which mirrors ISO 3166. “20161231” designates the date of the last day of the taxable year to which the message relates. In our example the MessageRefID shows 2016 as the reporting period. The 9999 is a unique identifier for the financial institution and the 20170430235959 is a unique identifier for messages sent by financial institution 9999. The EU suggests a time stamp which in this case would show that bank 9999 sent the message on April 30, one second before midnight.

The example is slightly off, since the timestamp needs to be included in the message. Hence the compilation of the data supposedly succeeded one second before midnight, however, the compression and encryption and sending made bank 9999 miss the deadline of April 30.

This scheme attempts to avoid duplicate MessageRefIDs by using a timestamp. The technical implementation of this timestamp however might not be as unambiguous as desired. A bank collecting timestamps at the start of the generating process might initiate several parallel processes at the same time and thus allocate the same timestamp and hence the same MessageRefIDs to different messages. Heisenbugs are an intellectual challenge; more pedestrian administrators who just want to get it done might add a salt, random number, etc. to the timestamp. If a competent authority transmits information to another competent authority the schema is expanded to include the country code of the receiving CA after the Reporting Period:

MemberStateX_20161231_MemberStateY_9999_20170430235959.

The DocRefIDs can relate to financial institutions and to account reports. Regarding financial institutions the EU suggests the following format:

MemberStateX_200161231_9999_FI_1

MemberStateX designates the jurisdiction to whose competent authority a financial institution submits its data. The 1 is meant to reference the first account report. This suggestion is however not thought through since each CRS body has to contain one FI and can contain millions of Account Reports. Is an FI to reference the first or the second or the millionth Account Report, or is it supposed to send one message with one Account Report ?

Instead of the EU proposed scheme the FI should rather increment a variable at  the end of the DocRefID , however, this variable should relate to the times an FI has submitted Account Reports.

Once the CA forwards the AccountReport to a member signatory CA, it needs to modify the DocRefID to make it unique. The EU suggests to simply add the country code of the recipient CA: Example:

MemberStateX_200161231_9999_FI_1_MemberStateY

where memerStateY is the recipient. When modifying the original DocRefID the competent authority has to ensure that corrections that reference a DocRefID are translated to reference the new DocRefID generated by the sending CA.

 

The post CRS tax information exchange: an example appeared first on Common Reporting Standard.



from WordPress http://ift.tt/1gLaYq2

No comments:

Post a Comment