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

Is a constructive trust a trust for purposes of the CRS ?

A constructive trust according to Wikipedia is an equitable remedy resembling a trust (implied trust) imposed by a court to benefit a party that has been wrongfully deprived of its rights due to either a person obtaining or holding legal right to property which they should not possess due to unjust enrichment or interference.(That was a mouthful). More simply: Is a constructive trust a trust as this term is used in the common reporting standard ? Does the little attribute “constructive” make a big difference ?

The word constructive might mislead the unwary; the construction taking place here is that of lawyers who chip off blocks of the trust to make it fit a rather atypical set of circumstances. Many know this type of legal construction from employment law where a constructive dismissal is the interpretation that an employee who quits his job actually has been fired.How come to such a conclusion: the boss treated the employee badly so that the employee did not have a choice but leave.

That Wikipedia (which provided the introductory sentence) is not far off in regards to the interpretation of the law can be seen by recent decisions of US courts which define a constructive trust as “a relationship, with respect to property, subjecting the person who holds title to the property to an equitable duty to convey it to another on the ground that his or her acquisition or retention of the property would constitute unjust enrichment”.  Other jurisdictions will treat fact patterns as those described by the Nebraska court by applying concepts of unjust enrichment. Even though multiple natural persons might be involved in such a transaction, with potentially fiduciary duties running among them, the label “constructive“ indicates semantic lawyerly wrangling that leave the original word and its meaning in the dust. The view that constructive trusts are not trusts is supported by legislatures as e.g. the California Probate Code , which specifically excludes constructive trusts from the definition of a trust (see section 82). (See also MATTER OF HSBC BANK USA, NA, 96 AD 3d 1655 — NY: Appellate Div., 4th Dept. 2012).

The little lawyerly construction seems to indicate that constructive trusts are not trusts for purposes of the common reporting standard. The alternative would be rather ridiculous, since any claim for unjust enrichment needed to be reported under CRS.

 

The post Is a constructive trust a trust for purposes of the CRS ? appeared first on Common Reporting Standard.

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

CRS, Grexit and the time it takes to adapt to new events

The CRS is a tax information exchange among countries who collect information from their financial institutions and pass them on to other countries who would check whether the person reported has paid their taxes. Greece is a signatory of the CRS and supposed to send and receive tax information starting 2017. However, if the Greek government exited the EURO it would be technically impossible to exchange data.

The CRS, unlike other conventions, does not only prescribe the legal obligations of the signatories, but also in great detail, how to exchange the account data. For that purpose, the OECD has developed an XML schema which clearly defines how and what to report. This schema however does not know the Drachma which the Greek government might introduce after a grexit. The information, the Greek finance ministry delivered to another government, would be rejected as not compliant with the XML schema.

Even without plans for a modification of the XML schema, eventually the OECD will need to update it. Similar needs to update might arise not only when a country introduces a new currency, but also when countries split up. Scotland comes to mind. Assuming that the Scots are taking over the task of reporting accounts according to the CRS, their reports equally would be rejected, since the country code for Scotland is not part of the XML schema. Taxpayers trying to avoid reporting under CRS might consider buying gold in the hope that gold is not a currency that could not be reported. Unfortunately the OECD has foreseen codes for the reporting of gold directly without conversion into dollars. If there is a third world country that holds accounts in livestock, CRS reporting might be challenging. Short of cows, the OECD has only excluded bitcoins from the list of available currencies. The OECD needs to adapt the XML schema at one point, the question is when.

At this point, if Greece introduced the Drachma or the Scots voted to become independent, technology as prescribed by the OECD prevented any reporting. Let’s see how many tax evaders are flocking to Scotland or the warmer climes of Greece.

The post CRS, Grexit and the time it takes to adapt to new events appeared first on Common Reporting Standard.

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

In CRS Reporting: Does a corrected Account Balance have to show a corrected FI ?

FIs are supposed to report their customers´ account balance. The Competent Authorities of the signatories collect this information and transmit it via an XML scheme as detailed in the CRS User Guide. This User Guide, even though basically a copy of the FATCA XML schema, has some shortcomings which are exemplified by the title question: When a bank wants to correct an account balance, does it have to resend the all the information pertaining to itself ?

The XML User Guide requires that each report must contain information pertaining to a FI. The field Reporting FI is mandatory (the requirement of this field is “validation” in the parlance of the CRS, which means that it has to exist or otherwise the message will fail validation). Even a correction hence needs to resend all the information previously transmitted. The CRS User Guide addresses this issue specifically for Account Reports:

“For a Correction, the whole AccountReport must be resent with all its information.“

This statement is slightly ambiguous since when explaining how to correct messages, the User Guide specifies:

”Since no data in AccountReport needs to be corrected, only the ReportingFI is sent as the correction.”

This seems to contradict another statement in the User Guide: AccountReport is mandatory under CRS. The reader is left puzzled as to whether the AccountReport is mandatory or not. An enigma wrapped in a riddle …

Once an AccountReport is being indicated as corrected, how should the information regarding the accompanying FI be labeled: New, Corrected, or Deleted? Other options are not available. None of the three available options truly captures the idea that previously submitted data is to be resent.

CRS has a mechanism to label  information as “Resend Data”, however, the current scheme provides that this field is “not used for CRS reporting”.

Maybe this discussion is overblown, since even if the information regarding the FI is labeled as “new”, the competent authority will use it and check the account holder’s tax information. The same applies to the label corrected or deleted data.

A tax payer wanting to avoid being reported should convince his financial institution to transmit the corrected information only after several corrections and some deletions. The CRS schema allows many interpretation which will lead to inconsistent implementations which in turn increase the chance that such information will simply be forgotten or discarded.

The post In CRS Reporting: Does a corrected Account Balance have to show a corrected FI ? appeared first on Common Reporting Standard.

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