How to enter your address in a CRS form

The CRS wants not only to know who owns an account, but also where the account holder can be found. Address is so important that it is a must field. Without it, a financial institution did not properly report. To locate an Account Holder we can enter several addresses indicating the type of address as:

residentialOrBusiness, residential, business, registeredOffice, or unspecified.

Imagine the world as a big and scary place, where it is not enough to list Street, BuildingIdentifier, SuiteIdentifier, FloorIdentifier, DistrictName, POB, PostCode, City and CountrySubentity but something like: after the third tree behind the third bush under the third rock.

This troglodyte could not be caught if we had to enter the address in the previously introduced  structured address field. Troglodytes have to pay taxes like everyone else and hence the OECD offers us a free address where the text flows as freely as the wind blows around our paradisical dwelling.

Whereas under the structured form field the field City was mandatory (nothing else), the free form field´s requirements are met under the CRS XML schema, if an entry was made with length zero. John Doe, residing at “”.

I for my part are saving my cash to acquire an abode at an address of type unspecified which does not fit into a structured address field and hence is reported in the free address field in a length of zero characters, if not for tax avoidance purposes but at least for the good weather.

The post How to enter your address in a CRS form appeared first on Common Reporting Standard.

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

CRS Confusion: Correcting a deletion

August is the month of correction for us. We will deal with corrections and deletions of messages and records submitted under the common reporting standard. In a previous post we asked what happens when you delete a correction. Today we will venture into the dangerous swamps of correction of a deletion.

When you correct a message, the CRS schema asks you to inform the recipient WHAT you want to correct. This wisdom is encapsulated in the CRS schema tag “CorrDocRefID” which is meant to contain a reference to the DocRefID of the dataset to be corrected.

Example: You want to correct a previously deleted message. Which dataset are you going to reference in your CorrDocRefID: The first message or the message that deleted the first message. The right answer seems to be to reference the latest instance of a dataset in a chain of corrections. The second question is whether you can correct a deleted message at all.  The correct approach seems to be: let those damn (in)competent tax authorities (CA) deal with it, I do not care.

However, if the CA decided that a deletion deletes everything, a correction that points to a no longer existing dataset might be rejected playing the ball back into the FI court. Tax authorities are equally confused by the silence of the CRS User Guide. The only solution is to work together, i.e. exchange information IN A TIMELY MANNER what is being implemented, why and how.

So far my impression is that tax authorities and financial institutions are scheduled to exchange bank account information in the millions, however, they have not yet learnt how to pick up a phone.

Taciturn coding will benefit no one, but, who is listening ?

The post CRS Confusion: Correcting a deletion appeared first on Common Reporting Standard.

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

CRS: how to delete a correction

The CRS XML schema allows financial institutions to delete or correct account information and the information pertaining to the financial institution itself. In particular, the CRS User Guide provides the field DocTypeIndic which allows the entries: OECD1= New Data OECD2= Corrected Data OECD3= Deletion of Data. What happens if you delete a correction, did you delete the whole chain of information ?

Deleting the whole chain of information would be comparable to  writing letterofresignationversion2 and saving it as letterofresignationversion1. Letterofresignationversion1 is irretrievably gone and if there was something in there that needed to be told to the world, you have to rewrite it.

Equally possible is it to assume that if you delete a correction it is like an undo operation in Microsoft Word. You undo and redo to your heart´s delight changing the salutation from “You filthy bastard” to “Dear John”.

For CRS the question is: Is the New Data that you previously submitted lost forever so that you have to resubmit it ? Or did you only undo the correction so that the New Data is still safe and sound and needs no more be tinkered with. The CRS User Guide does not offer any hints and the EU is busy rewriting the rules of correction.

The million dollar question  is, whether  a sane correction mechanism can be implemented without monkeying with the OECD schema ? One argument might be that the deletion of a whole message only deletes that message. For purposes of sanity this could lead to a decision to do it the same way, i.e. the deletion of a correction only affects the correction instance of the dataset.

For purposes of expanding your toolkit one might decide to delete the whole chain of messages: once you hit the delete button, everything is gone if it related to a dataset instead of a message. You are so confused that you no longer understand what you sent in the long chain of corrections and want to restart afresh. (The last thought is only a moderately bright idea, since a correction needs to contain all the data previously submitted, hence no doubt as to the state of information exists).

All mere mortals can do is await the wisdom that there lies in Brussels and Paris. (Wait for part 2 when we ask how to correct a deletion).

The post CRS: how to delete a correction appeared first on Common Reporting Standard.

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

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 whether 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 country 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