Last modified by Artur K. on 2026/05/29 14:28

From version 3.6
edited by Helena K.
on 2026/01/27 13:18
Change comment: There is no comment for this version
To version 3.8
edited by Helena K.
on 2026/01/27 13:20
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -128,34 +128,30 @@
128 128  
129 129  The CONF_REDIST attribute defines the secondary recipient(s) to whom the sender allows the primary recipient to forward confidential data. It is recommended to be an optional attribute at observation level. Ideally it should reference a shared code list containing standard organisation codes. To allow several secondary recipients there are these possibilities:
130 130  
131 -Use a code that represents multiple organisations, or;
131 +1. Use a code that represents multiple organisations, or;
132 +1. Use several CONF_REDIST attributes to portray the multiple recipients. Each attribute represents one recipient and references the same codelist. This implementation is cleaner than the above point 1, though this will require adding as many attributes to your DSD as there are potential recipients of the redistributed confidential data.
132 132  
133 -Use several CONF_REDIST attributes to portray the multiple recipients. Each attribute represents one recipient and references the same codelist. This implementation is cleaner than the above point 1, though this will require adding as many attributes to your DSD as there are potential recipients of the redistributed confidential data.
134 -
135 135  If the EMBARGO_TIME and CONF_REDIST attributes are both used:
136 136  
137 137  1. Data is available only to the organisations in CONF_REDIST until EMBARGO_TIME
138 138  1. Data is available to the public after EMBARGO_TIME
139 139  
140 -|(% colspan="3" %)(((
139 +(% style="width:768.957px" %)
140 +|(% colspan="3" style="width:766px" %)(((
141 141  (% class="wikigeneratedid" id="HPrivilegedAccess" %)
142 -Privileged Access
142 +**Privileged Access**
143 143  )))
144 -|**Use case**|**No forwarding**|**Forwarding**
145 -|**Embargo**|(((
144 +|(% style="width:202px" %)**Use case**|(% style="width:207px" %)**No forwarding**|(% style="width:357px" %)**Forwarding**
145 +|(% style="width:202px" %)**Embargo**|(% style="width:207px" %)(((
146 146  CONF_STATUS: E
147 -
148 148  EMBARGO_TIME
149 -)))|(((
148 +)))|(% style="width:357px" %)(((
150 150  CONF_STATUS: E
151 -
152 152  EMBARGO_TIME
153 -
154 154  CONF_REDIST
155 155  )))
156 -|**No embargo**|CONF_STATUS: N|(((
153 +|(% style="width:202px" %)**No embargo**|(% style="width:207px" %)CONF_STATUS: N|(% style="width:357px" %)(((
157 157  CONF_STATUS:N
158 -
159 159  CONF_REDIST
160 160  )))
161 161  
... ... @@ -168,17 +168,15 @@
168 168  * The national statistical institutes send data to Eurostat, and allow the data to be shared with the ECB for statistical coproduction
169 169  * The data may only be shared with the public on the next day
170 170  
171 -**CONF_STATUS:**E**;**
167 +* **CONF_STATUS:**E**;**
168 +* **CONF_REDIST: **ECB**;**
169 +* **EMBARGO_TIME=<**T+1 day**, **e.g.** **2017-12-15T10:00:00Z>
172 172  
173 -**CONF_REDIST: **ECB**;**
174 -
175 -**EMBARGO_TIME=<**T+1 day**, **e.g.** **2017-12-15T10:00:00Z>
176 -
177 177  The solutions suggested above aim at covering the most common confidentiality and embargo use cases within a single transmission from the primary reporter to the primary recipient. However, for some more complex scenarios it might still be required to make multiple transmissions.
178 178  
179 179  It is strongly recommended that use cases are specified in an agreement between organisations involved in regular transmissions up-front in order to avoid unnecessary delay in data publication or – much worse – confidentiality breaches.
180 180  
181 -**Annex 1: SDMX Representation of the confidentiality use cases**
175 += Annex 1: SDMX Representation of the confidentiality use cases =
182 182  
183 183  |(((
184 184  (% class="wikigeneratedid" id="HUsecase" %)
© Semantic R&D Group, 2026