The OECD Common Reporting Standard

If so, they might have learnt, that Kosovo has been recognized by FIFA, the Fédération Internationale de Football Association. 

If Kosovo is going to receive statehood, no accounts, no information will ever leave that country, for purposes of CRS. In fact, any information by definition is considered non-compliant with the common reporting standard.

How come ? In my previous post I deplored that the CRS is slow in adapting to political changes. This is a result of prescribing a finite set of values for certain information like currencies or country codes. If your country is not on that list, you cannot report.

Is the OECD going to modify the Common Reporting Standard. Kosovo seems a little small for that, hence, the moment Kosovo has obtained its two letter ISO country code, no information will be reported for some time.

Is it now “GOOOL, GOOOOL, GOOOL” or autogoal ;( ?

The OECD has published its Common Reporting Standard, dutifully signed by 50 to 80 nations, which provides for how the signatories are going to inform each other on tax cheats, i.e.  taxpayers who maintain bank accounts in other jurisdictions.

The undertaking is predictably huge, however, the legal and technical basis are intricate, formalistic and difficult to comprehend. This is an attempt to come to grips with the Common Reporting Standard.

The CRS User Guide expects that Account Reports always have to be sub­mit­ted. How­ever, in minus­cule sub clauses and allu­sions rem­i­nis­cent of sooth­say­ers, the CRS User Guide allows a finan­cial insti­tu­tion to send infor­ma­tion but not men­tion any account bal­ances. Under which cir­cum­stances should it be allowed that the core infor­ma­tion of the CRS, the account report, be omitted ?

On the one hand the User Guide sug­gests that banks, only for sta­tis­ti­cal pur­poses, Sub­mit infor­ma­tion show­ing that there is noth­ing to report. This infor­ma­tion is not for­warded to other coun­tries, but is meant as a check list for the domes­tic tax author­i­ties that this finan­cial insti­tu­tion ful­filled its report­ing duties. If there is noth­ing to report, there is noth­ing to report and the account infor­ma­tion need not be included in the message.

A sim­i­lar sit­u­a­tion arises when the finan­cial insti­tu­tion intends to delete a whole mes­sage con­tain­ing many account reports. This oper­a­tion, i.e. dele­tion of a mes­sage, seems to be nec­es­sary since some finan­cial insti­tu­tions have been unable to prop­erly track what has been trans­mit­ted and were look­ing for a fresh start. Instead of com­pelling these frest start insti­tu­tions to delete every account indi­vid­u­ally, the CRS drafters in wise fore­bod­ings have allowed finan­cial insti­tu­tions to delete whole mes­sages by pop­u­lat­ing the field Cor­rMes­sageRe­fID. Admit­tedly this is clumsy on sev­eral lev­els (seman­ti­cally we enter the realm were a dele­tion is deemed to be a cor­rec­tion), but prac­ti­cally very much required. Under these cir­cum­stances as well, a bank might be allowed to omit Account Reports.

When a bank tries to cor­rect infor­ma­tion relat­ing to itself, i.e. it changes its name, cor­rects its address, the bank account infor­ma­tion is not affected. The CRS User Guide when pro­vid­ing an exam­ple of such an oper­a­tion (see page 258 of the Pur­ple Book), men­tions en pas­sant that an account report needed not to be included. This type of cor­rec­tion of course leads to a flurry of activ­ity at the com­pe­tent author­ity which has to con­vert this dele­tion of mes­sage into a dele­tion of accounts (see pre­vi­ous arti­cle), but this is a minor cost of such a use­ful instrument.

  There you have it: Three instances when a finan­cial insti­tu­tion may omit an account report noth­ing to report mes­sage, dele­tion of mes­sage, and cor­rec­tion of infor­ma­tion per­tain­ing to a report­ing finan­cial institution.

The EU has for some time delib­er­ated ” a Reg­u­la­tion of the Euro­pean Par­lia­ment and of the Coun­cil on the pro­tec­tion of indi­vid­u­als with regard to the pro­cess­ing ofper­sonal data and on the free move­ment of such data (Gen­eral Data Pro­tec­tion Reg­u­la­tion)” see eg http://data.consilium.europa.eu/doc/document/ST-9565–2015-INIT/en/pdf

This reg­u­la­tion is sup­posed to pro­tect harm­less EU cit­i­zens from the likes of face­book, google and twit­ter. The EU promises to strengthen data pro­tec­tion and give data sub­jects (that´s us) “more con­trol over their per­sonal data”:

Sub­jects will enjoy

–eas­ier access to their data, –more detailed infor­ma­tion about what hap­pens to their per­sonal data once they decide to share it, –a right to era­sure of per­sonal data and “to be for­got­ten”, –a right to porta­bil­ity enabling eas­ier trans­mis­sion of per­sonal data from one ser­vice provider to another –lim­its to the use of ‘pro­fil­ing’. The ques­tion is whether this also affects the abil­ity of finan­cial insti­tu­tions to for­ward cus­tomer infor­ma­tion to tax author­i­ties. Instead of ask­ing google to be for­got­ten, I will ask Deutsche Bank to erase me from their dig­i­tal mem­o­ries (oblig­a­tion to erase per­sonal data with­out undue delay see Arti­cle 17).

The knee jerk reflex would be to say, of course can gov­ern­ments tax their cit­i­zens and col­lect data for this pur­pose. How­ever, this desired result is not entirely obvi­ous from the text. Arti­cle 1:

“This Reg­u­la­tion lays down rules relat­ing to the pro­tec­tion of indi­vid­u­als with regard to the pro­cess­ing of per­sonal data and rules relat­ing to the free move­ment of per­sonal data applies to any per­sonal data, ie any infor­ma­tion relat­ing to an iden­ti­fied or iden­ti­fi­able nat­ural per­son (‘data subject’, )”

whether such infor­ma­tion is stored by finan­cial insti­tu­tions or social net­works. Arti­cle 2 exempts from this data pro­tec­tion “The col­lec­tion of data by com­pe­tent (…) author­i­ties for the pur­poses of pre­ven­tion, inves­ti­ga­tion, detec­tion or pros­e­cu­tion of crim­i­nal offences, the exe­cu­tion of crim­i­nal penal­ties or the safe­guard­ing against and the pre­ven­tion of threats to pub­lic secu­rity.” Col­lec­tion of tax infor­ma­tion is miss­ing from the list.

Any­one want­ing to be for­got­ten should refrain from giv­ing ” unam­bigu­ous con­sent to the pro­cess­ing of their per­sonal data” (Arti­cle 6 Law­ful pro­cess­ing). But, Deutsche Bank may process the infor­ma­tion in order to com­ply with a legal oblig­a­tion (see  Arti­cle 6 Law­ful­ness of pro­cess­ing: Pro­cess­ing of per­sonal data shall be law­ful only if and to the extent that at least one of the fol­low­ing applies:.. pro­cess­ing is nec­es­sary for com­pli­ance with a legal oblig­a­tion to which the con­troller is subject)

Deutsche Bank is oblig­ated to com­ply with DAC2 and the Ger­man national law imple­ment­ing the MCAA (sched­uled to be enacted Q3 2015). Thus dou­bly oblig­ated, Deutsche Bank can­not sim­ply for­get about their cus­tomers (even though they con­tribute so lit­tle to the bot­tom line).

In the con­text of the com­mon report­ing stan­dard, tax author­i­ties are often viewed as a mere mail­man: They receive data from the finan­cial insti­tu­tions and pass the same data on to tax author­i­ties of other CRS mem­ber states. This view how­ever is wrong, as a few exam­ples will illustrate.

Case1 Imag­ine a Finan­cial Insti­tu­tion that deletes a pre­vi­ously sub­mit­ted mes­sage that has already been for­warded to the tax author­ity of another coun­try. Dele­tion of a com­plete mes­sage may be achieved by set­ting the Cor­rMes­sageRe­fID. This is the only and rather weak indi­ca­tion that a pre­vi­ously sub­mit­ted mes­sage should be deleted. The CRS guide pro­vides no other indi­ca­tor , except for set­ting the Cor­rMes­sageRe­fID, to delete a mes­sage with poten­tially mil­lions of account records attached. In this case the com­pe­tent author­ity has to gen­er­ate a new mes­sage that deletes the account records individually.

In our case R1’, R2’ and R3’ are records whose Doc­TypeIndic is “OECD3= Dele­tion of Data” which leads to a dele­tion of Account Records R1, R2, and R3. One could con­sider pass­ing on the delet­ing mes­sage; how­ever, the national com­pe­tent author­ity has dis­as­sem­bled the mes­sages from the finan­cial insti­tu­tions and recom­piled with the mes­sages of other finan­cial insti­tu­tions to cre­ate mes­sages on a coun­try by coun­try basis. Send­ing a delet­ing mes­sage would delete account records from other finan­cial insti­tu­tions that are still valid.Forget about being a mail­man, the com­pe­tent tax mail­man has to write some of the let­ters him– or herself.

Alter­na­tive 1 A Finan­cial Insti­tu­tion cor­rects new data and the com­pe­tent author­ity sub­mits new and cor­rected data to a CRS mem­ber state. After the cor­rec­tion has arrived in the for­eign coun­try the finan­cial insti­tu­tion deletes the cor­rect­ing mes­sage. The ques­tion is whether the dele­tion of the cor­rec­tion auto­mat­i­cally leads to a res­ur­rec­tion of the first mes­sage that pur­ported to pro­vide New Data. In order to avoid any ambi­gu­ity some com­pe­tent author­i­ties con­sider send­ing a cor­rec­tion mes­sage, which recon­firms the orig­i­nal submission.

This idea is con­sis­tent with the prin­ci­ple (pre­vi­ously dis­cussed), that a dele­tion of an account record deletes the entire chain from New Data to any sub­se­quent dele­tion and cor­rec­tion. As an aside, the ref­er­ence in the pre­vi­ous para­graph to a pre­vi­ous post, shows how all these top­ics are inter­con­nected. This inter­re­lat­ed­ness is what Rich Hickey refers to as complexity.

Alter­na­tive 2 A finan­cial insti­tu­tion sends three mes­sages, the first con­tains new data, the sec­ond a cor­rec­tion, the third a dele­tion of the cor­rect­ing mes­sage. All three mes­sages are trans­mit­ted to a for­eign com­pe­tent author­ity by the domes­tic Com­pe­tent author­ity. Then, the Finan­cial Insti­tu­tion sends a delet­ing mes­sage (i.e. the Cor­rDocRe­fID is cor­rectly set) which ref­er­ences the pre­vi­ous mes­sage that deleted cer­tain account records. In this case the ques­tion arises what the result of a dele­tion of a dele­tion is (also see pre­vi­ous post).

To ensure data qual­ity, some juris­dic­tions will gen­er­ate a cor­rect­ing datarecord that con­firms the cor­rec­tion to the new data. Again, this approach is con­sis­tent with the idea that a dele­tion of an account record (which needs to be dis­tin­guished from the dele­tion of a mes­sage), deletes the whole chain. One major prob­lem is the dele­tion of a com­plete mes­sage by a finan­cial insti­tu­tion. On the one hand it is ill defined by the CRS stan­dard, on the other hand, expe­ri­ence with finan­cial insti­tu­tions in the past ( I will not men­tion any names) has shown that the dele­tion of a com­plete mes­sage is a prac­ti­cal neces­sity that the OECD or the EU should not attempt to fix.

Finan­cial Insti­tu­tions are moan­ing under the com­pli­ance bur­den. Tax author­i­ties are in the same boat. Hope­fully, both sides will dia­logue to fix these problems.

What hap­pens when you delete the infor­ma­tion relat­ing to a finan­cial insti­tu­tion? Sud­denly all your account infor­ma­tion is use­less. You know that Tony Blair has mil­lions of mil­lions of pounds of cam­paign con­tri­bu­tions stacked away in a Swiss bank, but you do not know which one, because the infor­ma­tion regard­ing the address, name, iden­ti­fi­ca­tion num­ber of the finan­cial insti­tu­tion have been extinguished.

The CRS in its lib­er­tar­ian approach to data qual­ity allows any­thing and many sig­na­to­ries of the MCAA will fol­low this approach:

“I am just a mail­man. I receive data which I then pass on. ”

How­ever, this is a typ­i­cal exam­ple of a dele­tion that can­not be allowed and needs to be pre­vented. The com­pe­tent author­i­ties need to imple­ment a test that dele­tions of report­ing finan­cial insti­tu­tions is not allowed.

Trick ques­tion: Does this also apply when the finan­cial insti­tu­tion only reports that it has noth­ing to report, a mes­sage which is not being for­warded to a for­eign coun­try ? That might be a ques­tion for domes­tic sta­tis­ti­cians who want to keep track of which finan­cial insti­tu­tion has ful­filled its report­ing duties. If these sta­tis­ti­cians are eager, they will insist on reports and will not allow, that a finan­cial insti­tu­tion deletes its “noth­ing to report” message.

For me it is amaz­ing that these rather pedes­trian ques­tions can only be resolved through ref­er­ence to prin­ci­ples and con­sid­er­a­tions out­side the scope of the CRS. This of course means, that we will see more than 50 shades of pitch black (black being the color of despair and masochism and the gen­eral idea of pro­found igno­rance never to be enlightened).

All those com­pe­tent author­i­ties who think they are done imple­ment­ing the CRS: Back to the draw­ing board.

August is the month of cor­rec­tion for us. We will deal with cor­rec­tions and dele­tions of mes­sages and records sub­mit­ted under the com­mon report­ing stan­dard. In a pre­vi­ous post we asked what hap­pens when you delete a cor­rec­tion. Today we will ven­ture into the dan­ger­ous swamps of cor­rec­tion of a deletion.

When you cor­rect a mes­sage, the CRS schema asks you to inform the recip­i­ent WHAT you want to cor­rect. This wis­dom is encap­su­lated in the CRS schema tag “Cor­rDocRe­fID” which is meant to con­tain a ref­er­ence to the DocRe­fID of the dataset to be corrected.

Exam­ple: You want to cor­rect a pre­vi­ously deleted mes­sage. Which dataset are you going to ref­er­ence in your Cor­rDocRe­fID: The first mes­sage or the mes­sage that deleted the first mes­sage. The right answer seems to be to ref­er­ence the lat­est instance of a dataset in a chain of cor­rec­tions. The sec­ond ques­tion is whether you can cor­rect a deleted mes­sage at all.  The cor­rect approach seems to be: let those damn (in)competent tax author­i­ties (CA) deal with it, I do not care.

How­ever, if the CA decided that a dele­tion deletes every­thing, a cor­rec­tion that points to a no longer exist­ing dataset might be rejected play­ing the ball back into the FI court. Tax author­i­ties are equally con­fused by the silence of the CRS User Guide. The only solu­tion is to work together, i.e. exchange infor­ma­tion IN A TIMELY MANNER what is being imple­mented, why and how.

So far my impres­sion is that tax author­i­ties and finan­cial insti­tu­tions are sched­uled to exchange bank account infor­ma­tion in the mil­lions, how­ever, they have not yet learnt how to pick up a phone.

Tac­i­turn cod­ing will ben­e­fit no one, but, who is listening ?

The CRS XML schema allows finan­cial insti­tu­tions to delete or cor­rect account infor­ma­tion and the infor­ma­tion per­tain­ing to the finan­cial insti­tu­tion itself. In par­tic­u­lar, the CRS User Guide pro­vides the field Doc­TypeIndic which allows the entries: OECD1= New Data OECD2= Cor­rected Data OECD3= Dele­tion of Data. What hap­pens if you delete a cor­rec­tion, did you delete the whole chain of information ?

Delet­ing the whole chain of infor­ma­tion would be com­pa­ra­ble to  writ­ing letterofresignationversion2 and sav­ing it as letterofresignationversion1. Letterofresignationversion1 is irre­triev­ably gone and if there was some­thing in there that needed to be told to the world, you have to rewrite it.

Equally pos­si­ble is it to assume that if you delete a cor­rec­tion it is like an undo oper­a­tion in Microsoft Word. You undo and redo to your heart´s delight chang­ing the salu­ta­tion from “You filthy bas­tard” to “Dear John”.

For CRS the ques­tion is: Is the New Data that you pre­vi­ously sub­mit­ted lost for­ever so that you have to resub­mit it ? Or did you only undo the cor­rec­tion so that the New Data is still safe and sound and needs no more be tin­kered with. The CRS User Guide does not offer any hints and the EU is busy rewrit­ing the rules of correction.

The mil­lion dol­lar ques­tion  is, whether  a sane cor­rec­tion mech­a­nism can be imple­mented with­out mon­key­ing with the OECD schema ? One argu­ment might be that the dele­tion of a whole mes­sage only deletes that mes­sage. For pur­poses of san­ity this could lead to a deci­sion to do it the same way, i.e. the dele­tion of a cor­rec­tion only affects the cor­rec­tion instance of the dataset.

For pur­poses of expand­ing your toolkit one might decide to delete the whole chain of mes­sages: once you hit the delete but­ton, every­thing is gone if it related to a dataset instead of a mes­sage. You are so con­fused that you no longer under­stand what you sent in the long chain of cor­rec­tions and want to restart afresh. (The last thought is only a mod­er­ately bright idea, since a cor­rec­tion needs to con­tain all the data pre­vi­ously sub­mit­ted, hence no doubt as to the state of infor­ma­tion exists).

All mere mor­tals can do is await the wis­dom that there lies in Brus­sels and Paris. (Wait for part 2 when we ask how to cor­rect a deletion).

An account main­tained by bank X res­i­dent in mem­ber state 1 is held jointly by three persons:

1) Nat­ural per­son A, res­i­dent for tax pur­poses in mem­ber state 1 and mem­ber state 2 (MS1, MS2)

2)Natural per­son B, res­i­dent for tax pur­poses in MS2 and MS3

3) Pas­sive non finan­cial entity C, a res­i­dent for tax pur­poses of MS3 and MS4. C has two con­trol­ling per­sons: a) D, a res­i­dent for tax pur­poses of MS4 and MS5 b) E, a res­i­dent for tax pur­poses of MS5 and MS6.

To sum­ma­rize drama­tis personae

Name Type Tax res­i­dent where X Finan­cial Institution MS1 A Nat­ural Person MS1, MS2 B Nat­ural Person MS2, MS3 C Pas­sive Non Finan­cial Entity MS3, MS4 D Nat­ural Person MS4, MS5 E Nat­ural Person MS5, MS6

  We did not call C a legal per­son, because not all legal per­sons are Reportable Per­sons, i.e. pub­licly traded com­pa­nies or gov­ern­ment enti­ties are exempted. Fur­ther­more, only enti­ties that receive pas­sive income (what­ever that is) need to be reported.

How does the bank know where an Account Holder is res­i­dent for tax pur­poses or whether a non-financial entity con­ducts and active busi­ness? Self-certification by the Account Holder. The bank will ask its account hold­ers: where are you a tax res­i­dent and do you con­duct an active busi­ness and will report the Account Holder depend­ing on the response.

Bank X will send one report to its domes­tic com­pe­tent author­ity. This report will con­tain four Account Reports each report detail­ing the Account Num­ber with the account bal­ance as of Decem­ber 31, as well as inter­ests and div­i­dends received and pro­ceeds of sales and redemp­tions of Finan­cial Assets.

The Account Report will fur­ther con­tain the Account Bal­ances  as well as the Account Hold­ers A, B, C, and C.

That C is reported twice seems odd. The first time C is being reported as an entity, the sec­ond time C is being reported as being con­trolled by D and E. The OECD Com­men­tary to the CRS how­ever allows that the account bal­ance be attrib­uted to the NFE and to the per­sons con­trol­ling the NFE. This is the approach man­dated for the EU. Hence, C as a pas­sive NFE is being reported twice.

As an aside: Each account holder will be reported sep­a­rately and not as one of the many own­ers of one Bank Account, i.e. the FI can­not send one Account Report list­ing all the Account Hold­ers, rather, each Account Holder will be reported in a sep­a­rate Account Report. The domes­tic com­pe­tent author­ity will extract 8 mes­sages from the report pro­vided by bank X. One to each of the 6 mem­ber states for nat­ural per­sons A, B, D, E and two for pas­sive NFE C, which will be deliv­ered to MS3 and MS4.

How to keep infor­ma­tion unique under CRS Mil­lions of mes­sages con­tain­ing bank account infor­ma­tion of sev­eral account hold­ers will be exchanged. All these mes­sages and account reports need to be iden­ti­fied 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 mak­ing sure, that mes­sages and bank account infor­ma­tion are truly unique ?

The CRS User Guide defines Mes­sageRe­fID as a manda­tory data ele­ment that ”is a free text field cap­tur­ing the sender’s unique iden­ti­fy­ing num­ber (cre­ated by the sender) that iden­ti­fies the par­tic­u­lar mes­sage being sent.” [Pur­ple book p.234] Hav­ing each finan­cial insti­tu­tion and com­pe­tent author­i­ties gen­er­ate a ran­dom Mes­sageRe­fID might lead to col­li­sion, i.e. the same num­ber is gen­er­ated sev­eral times. The pro­vi­sions of the CRS regard­ing the gen­er­a­tion of unique ID is phrased in very soft language:

For exchanges between Com­pe­tent Author­i­ties, the first part should be the coun­try code of the send­ing juris­dic­tion, the sec­ond part the year to which the data relates and the third part the receiv­ing coun­try code, before a unique iden­ti­fier cre­ated by the send­ing juris­dic­tion (the “national part”).

The EU pro­posal sim­i­larly abstains from com­pul­sion when sug­gest­ing the fol­low­ing format:

MemberStateX_20161231_9999_20170430235959.

The EU rec­om­mends that the var­i­ous fields be sep­a­rated by an under­score for eas­ier read­ing. Mem­ber­Sta­teX is the coun­try code of the juris­dic­tion receiv­ing a domes­tic report. The coun­try code could be entered accord­ing to the OECD schema (isocrstypes_v1.0.xsd ) which mir­rors ISO 3166. “20161231” des­ig­nates the date of the last day of the tax­able year to which the mes­sage relates. In our exam­ple the Mes­sageRe­fID shows 2016 as the report­ing period. The 9999 is a unique iden­ti­fier for the finan­cial insti­tu­tion and the 20170430235959 is a unique iden­ti­fier for mes­sages sent by finan­cial insti­tu­tion 9999. The EU sug­gests a time stamp which in this case would show that bank 9999 sent the mes­sage on April 30, one sec­ond before midnight.

The exam­ple is slightly off, since the time­stamp needs to be included in the mes­sage. Hence the com­pi­la­tion of the data sup­pos­edly suc­ceeded one sec­ond before mid­night, how­ever, the com­pres­sion and encryp­tion and send­ing made bank 9999 miss the dead­line of April 30.

This scheme attempts to avoid dupli­cate Mes­sageRe­fIDs by using a time­stamp. The tech­ni­cal imple­men­ta­tion of this time­stamp how­ever might not be as unam­bigu­ous as desired. A bank col­lect­ing time­stamps at the start of the gen­er­at­ing process might ini­ti­ate sev­eral par­al­lel processes at the same time and thus allo­cate the same time­stamp and hence the same Mes­sageRe­fIDs to dif­fer­ent mes­sages. Heisen­bugs are an intel­lec­tual chal­lenge; more pedes­trian admin­is­tra­tors who just want to get it done might add a salt, ran­dom num­ber, etc. to the time­stamp. If a com­pe­tent author­ity trans­mits infor­ma­tion to another com­pe­tent author­ity the schema is expanded to include the coun­try code of the receiv­ing CA after the Report­ing Period:

MemberStateX_20161231_MemberStateY_9999_20170430235959.

The DocRe­fIDs can relate to finan­cial insti­tu­tions and to account reports. Regard­ing finan­cial insti­tu­tions the EU sug­gests the fol­low­ing format:

MemberStateX_200161231_9999_FI_1

Mem­ber­Sta­teX des­ig­nates the juris­dic­tion to whose com­pe­tent author­ity a finan­cial insti­tu­tion sub­mits its data. The 1 is meant to ref­er­ence the first account report. This sug­ges­tion is how­ever not thought through since each CRS body has to con­tain one FI and can con­tain mil­lions of Account Reports. Is an FI to ref­er­ence the first or the sec­ond or the mil­lionth Account Report, or is it sup­posed to send one mes­sage with one Account Report ?

Instead of the EU pro­posed scheme the FI should rather incre­ment a vari­able at  the end of the DocRe­fID , how­ever, this vari­able should relate to the times an FI has sub­mit­ted Account Reports.

Once the CA for­wards the Accoun­tRe­port to a mem­ber sig­na­tory CA, it needs to mod­ify the DocRe­fID to make it unique. The EU sug­gests to sim­ply add the coun­try code of the recip­i­ent CA: Example:

MemberStateX_200161231_9999_FI_1_MemberStateY

where memer­StateY is the recip­i­ent. When mod­i­fy­ing the orig­i­nal DocRe­fID the com­pe­tent author­ity has to ensure that cor­rec­tions that ref­er­ence a DocRe­fID are trans­lated to ref­er­ence the new DocRe­fID gen­er­ated by the send­ing CA.

In multi­na­tional enter­prises spe­cial­ized trea­sury func­tions like cash pool­ing are often con­cen­trated in one entity. The ques­tion is whether these cash pool enti­ties will be con­sid­ered finan­cial insti­tu­tions under the CRS and need to report account bal­ances and inter­ests for all related enti­ties as con­trol­ling persons.

Cash pool­ing serves to man­age liq­uid­ity in a group of related com­pa­nies and reduce financ­ing costs, notional cash pool­ing means that no phys­i­cal trans­fer of funds occurs, rather the cash pool­ing entity man­ages all funds by ledger entries. Other types of cash pool­ing that involve phys­i­cal trans­fers of cash are zero bal­anc­ing cash pools, where related enti­ties empty their accounts at the end of each day and trans­fer the money to a bank account of the group’ s cash pool­ing entity.

In the lan­guage of the CRS the ques­tion is whether a cash pool­ing entity is a “Depos­i­tory Insti­tu­tion” that accepts deposits in the ordi­nary course of a bank­ing or sim­i­lar busi­ness. (see Sec­tion VIII A 5 CRS). One ques­tion is whether notional cash pool­ing, i.e. enter­ing num­bers in a spread­sheet at the cash pool­ing entity, cre­ates a deposit. The dif­fer­ence to a bank account is not that great since even at a bank, accounts are main­tained elec­tron­i­cally; thus it seems an exer­cise of hair­split­ting to dis­tin­guish deposits under notional cash pool­ing from “typ­i­cal” deposits.

Def­i­n­i­tions of deposit are often use­less (see e.g. bank deposit — money deposited in a bank or some sim­i­lar insti­tu­tion) and even in the con­text of bank­ing law rather not elu­ci­dat­ing for the ques­tion at hand (UK bank­ing act of 1987):

a sum of money paid on terms under which it will be repaid, with or with­out inter­est or a premium.

To dis­tin­guish between enti­ties that engage in cash pool­ing activ­i­ties on behalf of related enti­ties or unre­lated enti­ties equally does not seem fruit­ful. Even related enti­ties may main­tain deposits with each other. All this leaves us to con­clude that a cash pool­ing entity takes deposits and is con­se­quently a finan­cial insti­tu­tion for pur­poses of the CRS.

How­ever, the CRS attempts to exempt financ­ing and hedg­ing trans­ac­tions with, or for, Related Enti­ties from the report­ing require­ments. It unfor­tu­nately does so in a cir­cu­lar way. The CRS provides:

The term “Active NFE” means any NFE that meets any of the fol­low­ing cri­te­ria: the NFE pri­mar­ily engages in financ­ing and hedg­ing trans­ac­tions with, or for, Related Enti­ties that are not Finan­cial Insti­tu­tions, and does not pro­vide financ­ing or hedg­ing ser­vices to any Entity that is not a Related Entity, pro­vided that the group of any such Related Enti­ties is pri­mar­ily engaged in a busi­ness other than that of a Finan­cial Institution.

A cash pool­ing entity cer­tainly engages in a financ­ing activ­ity with or for Related Enti­ties and hence would qual­ify for the label of “Active NFE”, that is an active non-financial entity. The prob­lem is that we just decided that cash pools are finan­cial insti­tu­tions whereas the sec­tion quoted relates only to non finan­cial enti­ties. Hence, it seems that the drafters of the CRS shot them­selves in the foot when attempt­ing to exempt cash pools. The exemp­tion only applies to non-financial enti­ties, a cash pool how­ever is a finan­cial entity.

Con­se­quently, a cash pool needs to report the account bal­ances of all related enti­ties whose cash it admin­is­ters to the com­pe­tent author­ity. Hope­fully, no major soft­ware pack­age is needed for report­ing. Rumour has it that var­i­ous juris­dic­tions will offer a man­ual input of data via a web interface.

In the famous words spo­ken to Oscar win­ner Lau­rel by his seem­ingly more intel­li­gent sidekick:

This is another fine mess you´ve got­ten me into.

A con­struc­tive trust accord­ing to Wikipedia is an equi­table rem­edy resem­bling a trust (implied trust) imposed by a court to ben­e­fit a party that has been wrong­fully deprived of its rights due to either a per­son obtain­ing or hold­ing legal right to prop­erty which they should not pos­sess due to unjust enrich­ment or interference.(That was a mouth­ful). More sim­ply: Is a con­struc­tive trust a trust as this term is used in the com­mon report­ing stan­dard ? Does the lit­tle attribute “con­struc­tive” make a big difference ?

The word con­struc­tive might mis­lead the unwary; the con­struc­tion tak­ing place here is that of lawyers who chip off blocks of the trust to make it fit a rather atyp­i­cal set of cir­cum­stances. Many know this type of legal con­struc­tion from employ­ment law where a con­struc­tive dis­missal is the inter­pre­ta­tion that an employee who quits his job actu­ally has been fired.How come to such a con­clu­sion: the boss treated the employee badly so that the employee did not have a choice but leave.

That Wikipedia (which pro­vided the intro­duc­tory sen­tence) is not far off in regards to the inter­pre­ta­tion of the law can be seen by recent deci­sions of US courts which define a con­struc­tive trust as “a rela­tion­ship, with respect to prop­erty, sub­ject­ing the per­son who holds title to the prop­erty to an equi­table duty to con­vey it to another on the ground that his or her acqui­si­tion or reten­tion of the prop­erty would con­sti­tute unjust enrich­ment”.  Other juris­dic­tions will treat fact pat­terns as those described by the Nebraska court by apply­ing con­cepts of unjust enrich­ment. Even though mul­ti­ple nat­ural per­sons might be involved in such a trans­ac­tion, with poten­tially fidu­ciary duties run­ning among them, the label “con­struc­tive“ indi­cates seman­tic lawyerly wran­gling that leave the orig­i­nal word and its mean­ing in the dust. The view that con­struc­tive trusts are not trusts is sup­ported by leg­is­la­tures as e.g. the Cal­i­for­nia Pro­bate Code , which specif­i­cally excludes con­struc­tive trusts from the def­i­n­i­tion of a trust (see sec­tion 82). (See also MATTER OF HSBC BANK USA, NA, 96 AD 3d 1655 — NY: Appel­late Div., 4th Dept. 2012).

The lit­tle lawyerly con­struc­tion seems to indi­cate that con­struc­tive trusts are not trusts for pur­poses of the com­mon report­ing stan­dard. The alter­na­tive would be rather ridicu­lous, since any claim for unjust enrich­ment needed to be reported under CRS.

The CRS is a tax infor­ma­tion exchange among coun­tries who col­lect infor­ma­tion from their finan­cial insti­tu­tions and pass them on to other coun­tries who would check whether the per­son reported has paid their taxes. Greece is a sig­na­tory of the CRS and sup­posed to send and receive tax infor­ma­tion start­ing 2017. How­ever, if the Greek gov­ern­ment exited the EURO it would be tech­ni­cally impos­si­ble to exchange data.

The CRS, unlike other con­ven­tions, does not only pre­scribe the legal oblig­a­tions of the sig­na­to­ries, but also in great detail, how to exchange the account data. For that pur­pose, the OECD has devel­oped an XML schema which clearly defines how and what to report. This schema how­ever does not know the Drachma which the Greek gov­ern­ment might intro­duce after a grexit. The infor­ma­tion, the Greek finance min­istry deliv­ered to another gov­ern­ment, would be rejected as not com­pli­ant with the XML schema.

Even with­out plans for a mod­i­fi­ca­tion of the XML schema, even­tu­ally the OECD will need to update it. Sim­i­lar needs to update might arise not only when a coun­try intro­duces a new cur­rency, but also when coun­tries split up. Scot­land comes to mind. Assum­ing that the Scots are tak­ing over the task of report­ing accounts accord­ing to the CRS, their reports equally would be rejected, since the coun­try code for Scot­land is not part of the XML schema. Tax­pay­ers try­ing to avoid report­ing under CRS might con­sider buy­ing gold in the hope that gold is not a cur­rency that could not be reported. Unfor­tu­nately the OECD has fore­seen codes for the report­ing of gold directly with­out con­ver­sion into dol­lars. If there is a third world coun­try that holds accounts in live­stock, CRS report­ing might be chal­leng­ing. Short of cows, the OECD has only excluded bit­coins from the list of avail­able cur­ren­cies. The OECD needs to adapt the XML schema at one point, the ques­tion is when.

At this point, if Greece intro­duced the Drachma or the Scots voted to become inde­pen­dent, tech­nol­ogy as pre­scribed by the OECD pre­vented any report­ing. Let’s see how many tax evaders are flock­ing to Scot­land or the warmer climes of Greece.

The CRS wants not only to know who owns an account, but also where the account holder can be found. Address is so impor­tant that it is a must field. With­out it, a finan­cial insti­tu­tion did not prop­erly report. To locate an Account Holder we can enter sev­eral addresses indi­cat­ing the type of address as:

res­i­den­tialOr­Busi­ness, res­i­den­tial, busi­ness, reg­is­tered­Of­fice, or unspecified.

Imag­ine the world as a big and scary place, where it is not enough to list Street, BuildingI­den­ti­fier, Suit­eI­den­ti­fier, FloorI­den­ti­fier, Dis­trict­Name, POB, Post­Code, City and Coun­try­Suben­tity but some­thing 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 pre­vi­ously intro­duced  struc­tured address field. Troglodytes have to pay taxes like every­one else and hence the OECD offers us a free address where the text flows as freely as the wind blows around our par­a­dis­i­cal dwelling.

Whereas under the struc­tured form field the field City was manda­tory (noth­ing else), the free form field´s require­ments are met under the CRS XML schema, if an entry was made with length zero. John Doe, resid­ing at “”.

I for my part are sav­ing my cash to acquire an abode at an address of type unspec­i­fied which does not fit into a struc­tured address field and hence is reported in the free address field in a length of zero char­ac­ters, if not for tax avoid­ance pur­poses but at least for the good weather.

Names need to be called, reported, and more. Legal and nat­ural per­sons are not sup­posed to be name­less. How do names have to be reported under the Com­mon Report­ing Stan­dard. Finan­cial Insti­tu­tions, Account Hold­ers, Con­trol­ling Per­sons all have names and in order to truly cap­ture the names, CRS offers the fol­low­ing distinctions.

We have first and last and mid­dle names (eg John J. Doe) and with the addi­tion of the “Title” iden­ti­fier we may call John a “mis­ter”. The con­cern is that His Excel­lency might not be prop­erly iden­ti­fied when sim­ply iden­ti­fied thusly and hence CRS offers a “Pre­ced­ing Title”. This how­ever leaves out John Doe junior who will be iden­ti­fied by his “Gen­er­a­tionIden­ti­fier”. Since His Excel­lency John J. Doe junior has a PhD we offer him to include this aca­d­e­mic achieve­ment as a “suf­fix”. Once he retires he adds the “Gen­eral Suf­fix” “retired”. His cousin from Hol­land John J. van Doe is allowed to squeeze the van into the “Name Prefix”.

One should think that this much infor­ma­tion is enough to iden­tify any­body. But tax evaders and their silk are slip­pery; hence, we can add more names like maiden name, father’s name, nick name, aka, dba, etc which would qual­ify the names pro­vided. Now finally we prop­erly can search for His Excel­lency Mr. John J. Doe junior, PhD, retired, nick­name “theguy­with­the­un­speak­able­long­name”, “father´s name” Doe, “maiden name” Doe and make him pay his taxes.

The EU has been fight­ing tax eva­sion for some time, nam­ing the fol­low­ing coun­tries as wor­thy of a crackdown:

Andorra, Liecht­en­stein, Guernsey, Monaco, Mau­ri­tius, Liberia, Sey­chelles, Brunei, Hong Kong, Mal­dives, Cook Islands, Nauru, Niue, Mar­shall Islands, Van­u­atu, Anguilla, Antigua and Bar­buda, Bahamas, Bar­ba­dos, Belize, Bermuda, British Vir­gin Islands, Cay­man Islands, Grenada, Montser­rat, Panama, St Vin­cent and the Grenadines, St Kitts and Nevis, Turks and Caicos, US Vir­gin Islands.

  To make it on the list, EU mem­ber coun­tries nom­i­nated non EU coun­tries and eval­u­ated their behav­ior accord­ing to cri­te­ria as “Absence of harm­ful tax mea­sures, Com­pli­ance with trans­parency and exchange of infor­ma­tion stan­dards, other criterion”.

The efforts to con­vince these tax havens to report the account Hold­ers and their bal­ances accord­ing to the Com­mon Report­ing Stan­dard has only be par­tially suc­cess­ful, since

Andorra, Monaco, Liberia, Brunei, HongKong, Mal­dives, Cook Islands, Nauru, Niue, Marschall Islands, Van­u­atu, Antigua and Bar­ba­dos, Belize, Grenada, Panama, St. Vin­cent and the Grenadines, and the US Vir­gin Islands have so far not signed the CRS.

It will be inter­est­ing to see whether these non-signatory juris­dic­tions will receive sub­stan­tial eco­nomic ben­e­fits from their absen­teeism from CRS.

CRS defines the term “Entity” to mean

“a legal per­son or a legal arrange­ment, such as a cor­po­ra­tion, part­ner­ship, trust, or foundation.”

At first view, a cor­po­ra­tion seems to be con­sid­ered a legal arrange­ment and not  a legal per­son. The exam­ples “cor­po­ra­tion, part­ner­ship, trust” how­ever relate to both legal per­son and legal arrange­ment. CRS doest not dis­tin­guish between legal per­son and legal arrange­ment because  dif­fer­ent juris­dic­tions will clas­sify part­ner­ships and trusts dif­fer­ently, i.e. some­times an entity, some­times a legal arrangement.

On the ques­tion of what is an entity, the com­men­tary on the CRS enlight­ens as follows:

“This term is intended to cover any per­son other than an indi­vid­ual (i.e. a nat­ural per­son), in addi­tion to any legal arrange­ment. Thus, e.g. a cor­po­ra­tion, part­ner­ship, trust, fide­icomiso, foun­da­tion ( fon­da­tion, Stiftung), com­pany, co-operative, asso­ci­a­tion, or aso­ciación en par­tic­i­pación, falls within the mean­ing of the term “Entity”.”

This expla­na­tion leaves the reader with the sorry task of try­ing to find out what legal arrange­ments will be enti­ties. A legal arrange­ment is broader than a con­tract, since trust deeds are typ­i­cally not con­sid­ered to be con­tracts. A legal arrange­ment hence encom­passes con­tracts and uni­lat­eral declarations.

We will approach this topic by look­ing to the fideo­comiso, a con­struct of nowa­days Latin Amer­i­can law, although, pre­vi­ously known by Roman and Ger­man law. Wikipedia explains:

A trust or fidecomiso1 (Latin fide­icom­mis­sum fides, “faith” and com­mis­sus, “com­mis­sion”) is a con­tract under which one or more per­sons trans­mits goods, money or rights, present or future, of his prop­erty to another per­son (a nat­ural or legal per­son) so that it admin­is­ters or invests the assets for their own ben­e­fit or for the ben­e­fit of a third party called beneficiary.

Cer­tainly all escrows would fall under that def­i­n­i­tion of fiedi­comiso. How­ever, it is not clear to me whether a reten­tion of title, a lien or pledge that neces­si­tates pos­ses­sion of the cred­i­tor would be con­sid­ered an Entity for pur­poses of the CRS. In all those legal insti­tutes one party has pos­ses­sion of prop­erty owned by another party. The pos­sess­ing party has to man­age the prop­erty in ways that honor the own­er­ship of another.  Since the ambi­tion of the CRS is so grand –catch all those tax evaders—it seems rea­son­able to assume that even a reten­tion of title is a fide­comiso and hence an Entity.

The prac­ti­cal impli­ca­tions are enor­mous. Any­one grant­ing credit against col­lat­eral, be it reten­tion of title of pledge, may be deemed an entity, with the result that they have to report their cus­tomers. (No good time to be a pawnbroker.)

It is once again vex­ing that the law and the CRS do not oper­ate with clar­ity so that pre­sum­ably inno­cent bystanders to tax eva­sion are caught in a whirl­wind of red tape.

One ques­tion remains: Are power of attor­neys con­sid­ered enti­ties for CRS pur­poses. It seems far-fetched since the def­i­n­i­tion of fide­icomi­sio talks about the trans­fer of prop­erty whereas a power of attor­ney typ­i­cally does not com­prise such trans­fer. How­ever, the fide­icomi­sio includes future transfers.

Lawyers who do not want to take a posi­tion on the ques­tion whether a power of attor­ney is an entity might say the clas­si­fi­ca­tion depends on the facts and cir­cum­stances. The facts and cir­cum­stances to con­sider will be how close the power of attor­ney is to a sta­ple fide­icomiso. The cri­te­ria I can imag­ine are how clearly fidu­ciary duties are spelled out or dis­cernible from the con­text. The more fidu­ciary duties are spelled out, the more likely the con­tract or legal arrange­ment will be clas­si­fied as an entity for CRS purposes.

Overly broad def­i­n­i­tions of the CRS ren­der much of the stan­dard absurd. That a reten­tion of title or a power of attor­ney are deemed Enti­ties is a view clearly based on the lan­guage of the CRS. How courts are going to fix this mess remains a mystery.

FIs are sup­posed to report their cus­tomers´ account bal­ance. The Com­pe­tent Author­i­ties of the sig­na­to­ries col­lect this infor­ma­tion and trans­mit it via an XML scheme as detailed in the CRS User Guide. This User Guide, even though basi­cally a copy of the FATCA XML schema, has some short­com­ings which are exem­pli­fied by the title ques­tion: When a bank wants to cor­rect an account bal­ance, does it have to resend the all the infor­ma­tion per­tain­ing to itself ?

The XML User Guide requires that each report must con­tain infor­ma­tion per­tain­ing to a FI. The field Report­ing FI is manda­tory (the require­ment of this field is “val­i­da­tion” in the par­lance of the CRS, which means that it has to exist or oth­er­wise the mes­sage will fail val­i­da­tion). Even a cor­rec­tion hence needs to resend all the infor­ma­tion pre­vi­ously trans­mit­ted. The CRS User Guide addresses this issue specif­i­cally for Account Reports:

“For a Cor­rec­tion, the whole Accoun­tRe­port must be resent with all its information.“

This state­ment is slightly ambigu­ous since when explain­ing how to cor­rect mes­sages, the User Guide specifies:

”Since no data in Accoun­tRe­port needs to be cor­rected, only the Report­ingFI is sent as the correction.”

This seems to con­tra­dict another state­ment in the User Guide: Accoun­tRe­port is manda­tory under CRS. The reader is left puz­zled as to whether the Accoun­tRe­port is manda­tory or not. An enigma wrapped in a riddle …

Once an Accoun­tRe­port is being indi­cated as cor­rected, how should the infor­ma­tion regard­ing the accom­pa­ny­ing FI be labeled: New, Cor­rected, or Deleted? Other options are not avail­able. None of the three avail­able options truly cap­tures the idea that pre­vi­ously sub­mit­ted data is to be resent.

CRS has a mech­a­nism to label  infor­ma­tion as “Resend Data”, how­ever, the cur­rent scheme pro­vides that this field is “not used for CRS reporting”.

Maybe this dis­cus­sion is overblown, since even if the infor­ma­tion regard­ing the FI is labeled as “new”, the com­pe­tent author­ity will use it and check the account holder’s tax infor­ma­tion. The same applies to the label cor­rected or deleted data.

A tax payer want­ing to avoid being reported should con­vince his finan­cial insti­tu­tion to trans­mit the cor­rected infor­ma­tion only after sev­eral cor­rec­tions and some dele­tions. The CRS schema allows many inter­pre­ta­tion which will lead to incon­sis­tent imple­men­ta­tions which in turn increase the chance that such infor­ma­tion will sim­ply be for­got­ten or discarded.