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

Who should check the taxpayer ID under CRS

Millions of taxpayer records are going to be collected by banks and distributed across the globe by tax authorities to enforce tax laws. One question on everyone´s mind is how to ensure that the data collected by banks are useable for taxation. A bank account information that cannot be attributed to an individual however is useless. This problem is compounded by the fact that the tax payer identification number is an optional field.  Financial Institutions are not compelled to provide tax payer identification numbers.

Financial institutions do not have an incentive to provide usable data, except when faced with fines. When rejecting or admonishing financial institutions to deliver more and better data, the response simply might be that any efffort  beyond compliance with the CRS will be billed at an hourly rate of X.The interest of the sending competent authority is comparatively aligned with this attitude, since no additional revenue to the coffers can be expected by delivering squeaky clean data.

Hence, the entity that has the highest interest in the process is the receiving authority which is the only institution equipped to validate TINs.After all the Financial Institution provides information regarding taxpayers also resident in the jurisdiction of the receiving authority.

Valid Taxpayer ID and the OECD portal

Without a valid taxpayer ID (TIN) all account information is useless. To improve the understanding how a jurisdiction generates TINs, the OECD has established a web portal . I am highly doubtful that all of the OECD published TIN information will be usable for validation purposes. Among 80 signatories there will be several who can only describe in vague terms what the components of their domestic TINs are. Imagine a small country that randomly allocates a 15 digit number to its citizens; the only check being made is that it has not been previously issued. Maybe, in an attempt to confuse illegal immigrants, certain parts of the number are a check number; however, this information is not publicly disclosed as not to alert criminals. A check against such a validation rule would be rather meaningless. The issue might be complicated by introduction of new and improved TIN schemes (now your welfare benefit/health benefits and your tax ID are linked …).

Attempts to implement a validation scheme based on the OECD portal information is a major undertaking, since 80 schemes, one for each signatory, need to be maintained. Software engineers always have questions; in this case however, no one will be able to provide additional advice beyond what is published on the website.The OECD does not really know and further contact information is not provided.

Once a signatory has received information purportedly relating to a tax dodging individual it will attempt to ascertain who the individual is. Failing the TIN validation it now needs to go back to the sending Competent Authority to request additional information. If this is done in an automated fashion, which an automated exchange of data certainly suggests doing, the sending CA will be swamped with requests for administrative assistance. The ensuing red tape for the chain CA->FI->customer can only be hinted at.

The problem of TIN verification is by no means simple and I consider it one of the weaker points of CRS. Unfortunately, no easy fix is discernible which means that the TIN probably is going to be checked by the receiving competent authority. In case the receiving competent authority cannot validate the TIN, only under exceptional circumstances additional steps will be undertaken.

FATCA imposed order by the mere might of the US government. This advantage  is however lacking in a multilateral agreement like the CRS.

The post Who should check the taxpayer ID under CRS appeared first on Common Reporting Standard.

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