#docrefid

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.