-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathChapter05.html
More file actions
1770 lines (1737 loc) · 254 KB
/
Copy pathChapter05.html
File metadata and controls
1770 lines (1737 loc) · 254 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Chapter 5 — Funds, Sub-Funds, and Share Classes</title>
<link rel="icon" type="image/png" href="FundsXML-Logo.png">
<style>
:root {
--ink: #1a1a1a;
--ink-soft: #444;
--ink-muted: #6b7280;
--accent: #0b5394;
--accent-soft: #e3ecf6;
--accent-hover: #083d73;
--rule: #d0d7de;
--rule-soft: #e8ecf1;
--bg: #fbfbf8;
--paper: #ffffff;
--callout: #f3f6fb;
--row-alt: #f6f8fa;
--code-bg: #f4f6f9;
--code-ink: #22272e;
--tok-tag: #0b5394;
--tok-attr: #1a7f4b;
--tok-string: #a8410a;
--tok-comment: #6b7280;
--tok-decl: #7048c4;
--tok-punct: #6b7684;
--tip: #1a7f4b;
--tip-bg: #effaf3;
--warn: #a85a00;
--warn-bg: #fff5e6;
--example: #5b4ab3;
--example-bg: #f1eefb;
--shadow-sm: 0 1px 2px rgba(15,23,42,0.04);
--shadow-md: 0 2px 8px rgba(15,23,42,0.08);
}
html[data-theme="dark"] {
--ink: #e6e8eb;
--ink-soft: #b1b6bd;
--ink-muted: #858a93;
--accent: #79b8ff;
--accent-soft: #17304b;
--accent-hover: #a8d0ff;
--rule: #2e333b;
--rule-soft: #24282f;
--bg: #101214;
--paper: #191c1f;
--callout: #1b2432;
--row-alt: #171a1e;
--code-bg: #161a1f;
--code-ink: #d9dde3;
--tok-tag: #7cb7f5;
--tok-attr: #7fd0a3;
--tok-string: #e0966a;
--tok-comment: #8a919c;
--tok-decl: #c3aef2;
--tok-punct: #9aa2ad;
--tip: #6bd494;
--tip-bg: #122820;
--warn: #e7a76b;
--warn-bg: #2b1f12;
--example: #b4a6f4;
--example-bg: #231d37;
--shadow-sm: 0 1px 2px rgba(0,0,0,0.3);
--shadow-md: 0 2px 10px rgba(0,0,0,0.45);
}
html[data-theme="dark"] img { filter: brightness(0.92) contrast(1.05); }
html {
-webkit-text-size-adjust: 100%;
scroll-behavior: smooth;
}
body {
font-family: "Source Serif Pro", "Source Serif 4", Georgia, "Times New Roman", serif;
font-size: 18px;
line-height: 1.65;
color: var(--ink);
background: var(--bg);
max-width: 46em;
margin: 3em auto;
padding: 0 1.5em;
hyphens: auto;
hyphenate-limit-chars: 7 3 3;
text-rendering: optimizeLegibility;
-webkit-font-smoothing: antialiased;
font-feature-settings: "kern", "liga", "calt";
}
::selection { background: var(--accent-soft); color: var(--ink); }
h1, h2, h3, h4 {
font-family: "Inter", -apple-system, "Helvetica Neue", Arial, sans-serif;
color: var(--ink);
line-height: 1.25;
margin-top: 2em;
scroll-margin-top: 1.5em;
font-feature-settings: "kern", "liga";
letter-spacing: -0.005em;
}
h1 {
font-size: 2.1em;
border-bottom: 3px solid var(--accent);
padding-bottom: 0.3em;
margin-top: 0;
letter-spacing: -0.015em;
}
h1 .subtitle {
display: block;
font-size: 0.55em;
font-weight: 400;
font-style: italic;
color: var(--ink-soft);
margin-top: 0.4em;
letter-spacing: 0;
}
h2 {
font-size: 1.45em;
margin-top: 2.4em;
border-bottom: 1px solid var(--rule);
padding-bottom: 0.2em;
}
h3 { font-size: 1.15em; color: var(--accent); }
h4 { font-size: 1em; color: var(--ink-soft); }
p {
margin: 0.9em 0;
text-align: justify;
text-justify: inter-word;
orphans: 2;
widows: 2;
}
ul, ol { padding-left: 1.4em; }
li { margin: 0.35em 0; }
li::marker { color: var(--accent); }
strong { color: var(--ink); font-weight: 600; }
em { color: var(--ink-soft); }
hr {
border: none;
border-top: 1px solid var(--rule);
margin: 2.4em 0;
}
a {
color: var(--accent);
text-decoration: underline;
text-decoration-thickness: 1px;
text-decoration-color: rgba(11, 83, 148, 0.35);
text-underline-offset: 0.18em;
transition: color 0.15s ease, text-decoration-color 0.15s ease;
}
a:hover {
color: var(--accent-hover);
text-decoration-color: var(--accent);
}
a:focus-visible {
outline: 2px solid var(--accent);
outline-offset: 2px;
border-radius: 2px;
}
html[data-theme="dark"] a { text-decoration-color: rgba(121, 184, 255, 0.4); }
table {
border-collapse: collapse;
width: 100%;
margin: 1.8em 0;
font-size: 0.92em;
font-family: "Inter", -apple-system, sans-serif;
font-variant-numeric: tabular-nums lining-nums;
background: var(--paper);
border-radius: 4px;
overflow: hidden;
box-shadow: var(--shadow-sm);
}
caption {
caption-side: bottom;
text-align: left;
color: var(--ink-soft);
font-family: "Inter", sans-serif;
font-size: 0.9em;
font-style: italic;
padding: 0.6em 0.2em 0;
}
th, td {
text-align: left;
padding: 0.6em 0.85em;
border-bottom: 1px solid var(--rule-soft);
vertical-align: top;
}
th {
background: var(--callout);
border-bottom: 2px solid var(--accent);
font-weight: 600;
color: var(--ink);
}
tbody tr:nth-child(even) { background: var(--row-alt); }
tbody tr:hover { background: var(--accent-soft); }
tbody tr:last-child td { border-bottom: none; }
blockquote {
margin: 1.4em 0;
padding: 1em 1.2em;
background: var(--callout);
border-left: 4px solid var(--accent);
color: var(--ink-soft);
font-size: 0.95em;
border-radius: 0 4px 4px 0;
}
blockquote p { margin: 0.4em 0; }
blockquote p:first-child { margin-top: 0; }
blockquote p:last-child { margin-bottom: 0; }
blockquote.tip { background: var(--tip-bg); border-color: var(--tip); }
blockquote.warning { background: var(--warn-bg); border-color: var(--warn); color: var(--ink); }
blockquote.example { background: var(--example-bg); border-color: var(--example); }
code {
font-family: "JetBrains Mono", "Source Code Pro", "SF Mono", Menlo, Consolas, monospace;
font-size: 0.9em;
background: var(--code-bg);
color: var(--code-ink);
padding: 0.1em 0.35em;
border-radius: 3px;
font-feature-settings: "liga" 0, "calt" 0;
word-break: break-word;
}
pre {
font-family: "JetBrains Mono", "Source Code Pro", "SF Mono", Menlo, Consolas, monospace;
font-size: 0.85em;
line-height: 1.55;
background: var(--code-bg);
color: var(--code-ink);
border-left: 3px solid var(--accent);
padding: 1em 1.2em;
margin: 1.4em 0;
overflow-x: auto;
hyphens: none;
tab-size: 2;
border-radius: 0 4px 4px 0;
box-shadow: var(--shadow-sm);
font-feature-settings: "liga" 0, "calt" 0;
}
pre code {
background: none;
padding: 0;
border-radius: 0;
font-size: 1em;
word-break: normal;
}
pre .tok-tag { color: var(--tok-tag); }
pre .tok-attr { color: var(--tok-attr); }
pre .tok-string { color: var(--tok-string); }
pre .tok-comment { color: var(--tok-comment); font-style: italic; }
pre .tok-decl { color: var(--tok-decl); }
pre .tok-punct { color: var(--tok-punct); }
figure { margin: 1.6em 0; text-align: center; }
figure img { max-width: 100%; height: auto; border-radius: 4px; box-shadow: var(--shadow-sm); }
figcaption {
font-family: "Inter", sans-serif;
font-size: 0.88em;
color: var(--ink-soft);
margin-top: 0.6em;
font-style: italic;
}
img { max-width: 100%; height: auto; }
.chapter-meta {
font-family: "Inter", sans-serif;
font-size: 0.85em;
text-transform: uppercase;
letter-spacing: 0.08em;
color: var(--accent);
font-weight: 600;
margin-bottom: 0.6em;
}
.lead { font-size: 1.08em; color: var(--ink-soft); font-style: italic; }
.glossary-entry { margin: 0.6em 0; }
.glossary-entry strong { color: var(--accent); }
.idx { line-height: 1.55; margin: 0.15em 0; }
.idx strong { color: var(--ink); }
.index-note { font-size: 0.9em; color: var(--ink-soft); margin-bottom: 1em; }
/* --- sticky chapter nav --- */
#toc-nav {
position: fixed;
top: 0;
left: 0;
width: 18em;
max-height: 100vh;
overflow-y: auto;
background: var(--bg);
border-right: 1px solid var(--rule);
padding: 1em 0.8em 1.5em 0.8em;
font-family: "Inter", -apple-system, "Helvetica Neue", Arial, sans-serif;
font-size: 0.72em;
line-height: 1.4;
z-index: 1000;
box-shadow: 2px 0 8px rgba(0,0,0,0.06);
transition: transform 0.25s ease;
scrollbar-width: thin;
scrollbar-color: var(--rule) transparent;
}
#toc-nav::-webkit-scrollbar { width: 6px; }
#toc-nav::-webkit-scrollbar-thumb { background: var(--rule); border-radius: 3px; }
#toc-nav::-webkit-scrollbar-track { background: transparent; }
#toc-nav.collapsed { transform: translateX(-100%); box-shadow: none; }
#toc-nav .toc-title {
font-weight: 700;
color: var(--accent);
margin-bottom: 0.8em;
padding-bottom: 0.4em;
font-size: 1.05em;
letter-spacing: 0.03em;
border-bottom: 1px solid var(--rule-soft);
}
#toc-nav ul { list-style: none; padding: 0; margin: 0; }
#toc-nav li { margin: 0.2em 0; }
#toc-nav li.toc-h1 {
font-weight: 700;
margin-top: 0.7em;
color: var(--accent);
}
#toc-nav a {
color: var(--ink-soft);
text-decoration: none;
display: block;
padding: 0.2em 0.5em;
border-radius: 3px;
border-left: 2px solid transparent;
transition: background 0.15s, color 0.15s, border-color 0.15s;
white-space: nowrap;
overflow: hidden;
text-overflow: ellipsis;
}
#toc-nav a:hover { background: var(--callout); color: var(--accent); }
#toc-nav a.active {
background: var(--callout);
color: var(--accent);
border-left-color: var(--accent);
font-weight: 600;
}
#toc-toggle {
position: fixed;
top: 0.5em;
left: 0.5em;
z-index: 1001;
width: 2.1em;
height: 2.1em;
border: 1px solid var(--rule);
border-radius: 4px;
background: var(--bg);
color: var(--accent);
font-size: 1.1em;
cursor: pointer;
display: flex;
align-items: center;
justify-content: center;
box-shadow: var(--shadow-sm);
transition: left 0.25s ease, transform 0.15s;
font-family: "Inter", sans-serif;
}
#toc-toggle:hover { transform: scale(1.05); }
#toc-toggle:focus-visible { outline: 2px solid var(--accent); outline-offset: 2px; }
#toc-toggle.open { left: 18.5em; }
/* --- heading anchor links --- */
.heading-anchor {
color: var(--rule);
text-decoration: none;
font-weight: 400;
margin-left: 0.35em;
opacity: 0;
transition: opacity 0.15s;
font-size: 0.72em;
vertical-align: middle;
}
h1:hover .heading-anchor,
h2:hover .heading-anchor,
h3:hover .heading-anchor,
h4:hover .heading-anchor { opacity: 1; color: var(--accent); }
.heading-anchor:hover { color: var(--accent-hover); }
.heading-anchor:focus-visible {
opacity: 1;
outline: 2px solid var(--accent);
outline-offset: 2px;
border-radius: 2px;
}
/* --- back-to-top button --- */
#top-btn {
position: fixed;
bottom: 1.5em;
right: 1.5em;
padding: 0.6em 1em;
background: var(--accent);
color: #fff;
border: none;
border-radius: 999px;
font-family: "Inter", -apple-system, sans-serif;
font-size: 0.85em;
font-weight: 600;
letter-spacing: 0.03em;
cursor: pointer;
opacity: 0;
pointer-events: none;
transform: translateY(6px);
transition: opacity 0.2s ease, transform 0.2s ease, background 0.15s;
box-shadow: var(--shadow-md);
z-index: 999;
}
#top-btn.visible { opacity: 0.95; pointer-events: auto; transform: translateY(0); }
#top-btn:hover { opacity: 1; background: var(--accent-hover); }
#top-btn:focus-visible { outline: 2px solid #fff; outline-offset: 2px; }
/* --- per-chapter navigation bar (standalone pages only; stripped from
the concatenated complete book by build_complete.sh) --- */
.chapter-nav {
display: flex;
align-items: center;
justify-content: space-between;
gap: 1em;
margin: 2.5em 0;
padding: 0.9em 0;
border-top: 1px solid var(--rule);
border-bottom: 1px solid var(--rule);
font-family: "Inter", -apple-system, sans-serif;
font-size: 0.85em;
font-weight: 600;
letter-spacing: 0.02em;
}
.chapter-nav:first-child { margin-top: 0; }
.chapter-nav a {
color: var(--accent);
text-decoration: none;
padding: 0.35em 0.2em;
transition: color 0.15s;
}
.chapter-nav a:hover { color: var(--accent-hover); }
.chapter-nav .cn-toc { color: var(--ink-muted); font-weight: 500; }
.chapter-nav .cn-disabled { color: var(--rule); cursor: default; }
.chapter-nav .cn-next { text-align: right; }
/* --- theme toggle --- */
#theme-btn {
position: fixed;
top: 0.5em;
right: 0.5em;
width: 2.1em;
height: 2.1em;
border-radius: 50%;
border: 1px solid var(--rule);
background: var(--paper);
color: var(--accent);
font-size: 1em;
line-height: 1;
cursor: pointer;
display: flex;
align-items: center;
justify-content: center;
box-shadow: var(--shadow-sm);
transition: transform 0.15s ease, background 0.15s, border-color 0.15s;
font-family: "Inter", -apple-system, sans-serif;
z-index: 1001;
}
#theme-btn:hover { transform: scale(1.05); border-color: var(--accent); }
#theme-btn:focus-visible { outline: 2px solid var(--accent); outline-offset: 2px; }
#theme-btn .icon-sun { display: none; }
#theme-btn .icon-moon { display: inline; }
html[data-theme="dark"] #theme-btn .icon-sun { display: inline; }
html[data-theme="dark"] #theme-btn .icon-moon { display: none; }
/* --- feedback (report an issue) --- */
#feedback-btn {
position: fixed;
top: 3.1em;
right: 0.5em;
width: 2.1em;
height: 2.1em;
border-radius: 50%;
border: 1px solid var(--rule);
background: var(--paper);
color: var(--accent);
font-size: 1em;
line-height: 1;
cursor: pointer;
display: flex;
align-items: center;
justify-content: center;
box-shadow: var(--shadow-sm);
transition: transform 0.15s ease, background 0.15s, border-color 0.15s;
font-family: "Inter", -apple-system, sans-serif;
z-index: 1001;
}
#feedback-btn:hover { transform: scale(1.05); border-color: var(--accent); }
#feedback-btn:focus-visible { outline: 2px solid var(--accent); outline-offset: 2px; }
#feedback-pop {
position: absolute;
display: none;
z-index: 1002;
}
#feedback-pop button {
padding: 0.45em 0.9em;
background: var(--accent);
color: #fff;
border: none;
border-radius: 999px;
font-family: "Inter", -apple-system, sans-serif;
font-size: 0.8em;
font-weight: 600;
letter-spacing: 0.02em;
cursor: pointer;
box-shadow: var(--shadow-md);
}
#feedback-pop button:hover { background: var(--accent-hover); }
/* --- download link (pill, visible only on screen) --- */
.download-link {
display: inline-block;
padding: 0.55em 1.1em;
background: var(--accent);
color: #fff;
text-decoration: none;
font-family: "Inter", -apple-system, sans-serif;
font-weight: 600;
font-size: 0.9em;
letter-spacing: 0.02em;
border-radius: 999px;
box-shadow: var(--shadow-sm);
transition: background 0.15s, transform 0.15s;
}
.download-link:hover {
background: var(--accent-hover);
color: #fff;
transform: translateY(-1px);
box-shadow: var(--shadow-md);
text-decoration: none;
}
.download-link:focus-visible { outline: 2px solid var(--accent); outline-offset: 3px; }
.download-link::before {
content: "↓";
display: inline-block;
margin-right: 0.4em;
font-weight: 700;
}
/* --- medium viewports: push body right so the sidebar doesn't
overlap the first characters of each line --- */
@media (min-width: 901px) and (max-width: 1400px) {
body:has(#toc-nav:not(.collapsed)) {
padding-left: 18em;
}
}
/* --- small screens --- */
@media (max-width: 900px) {
body { margin: 2em auto; padding: 0 1em; }
#toc-nav { width: 82%; max-width: 20em; }
#toc-toggle.open { left: calc(82% + 0.5em); }
}
/* --- reduced motion --- */
@media (prefers-reduced-motion: reduce) {
*, *::before, *::after {
animation-duration: 0.001ms !important;
transition-duration: 0.001ms !important;
scroll-behavior: auto !important;
}
}
/* --- print --- */
@page { size: A4; margin: 22mm 18mm 20mm 18mm; }
@page :first { margin-top: 0; }
@media print {
html[data-theme="dark"] { /* force light theme in PDF regardless of user toggle */
--ink: #000; --ink-soft: #333; --ink-muted: #5a5f66;
--accent: #0b5394; --accent-soft: #e3ecf6; --accent-hover: #083d73;
--rule: #cfd4d9; --rule-soft: #e8ecf1;
--bg: #fff; --paper: #fff; --callout: #f5f7fb; --row-alt: #f7f9fc;
--code-bg: #f4f6f9; --code-ink: #22272e;
--tok-tag: #0b5394; --tok-attr: #1a7f4b; --tok-string: #a8410a;
--tok-comment: #6b7280; --tok-decl: #7048c4; --tok-punct: #6b7684;
}
:root {
--bg: #fff; --paper: #fff;
--ink: #000; --ink-soft: #333;
--rule: #cfd4d9; --callout: #f5f7fb; --row-alt: #f7f9fc;
}
#toc-nav, #toc-toggle, #top-btn, #theme-btn, #feedback-btn, #feedback-pop,
.chapter-nav, .heading-anchor, .download-link { display: none !important; }
body {
font-size: 10.5pt;
max-width: none;
margin: 0;
padding: 0;
line-height: 1.5;
background: #fff;
color: #000;
-webkit-print-color-adjust: exact;
print-color-adjust: exact;
}
h1 { font-size: 1.8em; }
h2 { font-size: 1.3em; page-break-after: avoid; }
h3, h4 { page-break-after: avoid; }
p, li { orphans: 3; widows: 3; }
table, blockquote, figure { page-break-inside: avoid; }
pre { page-break-inside: auto; white-space: pre-wrap; word-wrap: break-word; }
th, tbody tr:nth-child(even), .pages, h2.part-title {
-webkit-print-color-adjust: exact;
print-color-adjust: exact;
}
a { color: var(--accent); text-decoration: none; }
}
</style>
<script id="theme-preload">(function(){try{var t=localStorage.getItem('fundsxml-theme');if(t==='dark')document.documentElement.setAttribute('data-theme','dark');}catch(e){}})();</script>
</head>
<body>
<nav class="chapter-nav" aria-label="Chapter navigation"><a class="cn-prev" href="Chapter04.html">‹ Chapter 4</a><a class="cn-toc" href="index.html">Contents</a><a class="cn-next" href="Chapter06.html">Chapter 6 ›</a></nav>
<img src="FundsXML-Logo.png" alt="FundsXML" style="height:28px;width:auto;display:block;margin:0 0 1.5em 0;">
<h1>Funds, Sub-Funds, and Share Classes<span class="subtitle">Static and dynamic fund information</span></h1>
<hr>
<h2>5.1 Setting the Scene: Inside the Envelope</h2>
<p>At the end of Chapter 4 we had a ControlData block for the Europa Growth Fund's month-end delivery on 31 March 2026. We knew who had sent it, whom it was meant for, which day it referred to, and that it was the first delivery of its stream. What we did not know was anything about the fund itself. This chapter fills that gap. It is the longest chapter in the book — forty pages — because the <code>Fund</code> element is the element about which everything else in a FundsXML delivery eventually revolves, and because it is also the element where newcomers most often get lost.</p>
<p>Before we begin, one pedagogical decision deserves to be stated up front. The Europa Growth Fund, as we learned in Chapter 1, is a European UCITS equity fund distributed across eleven countries. In reality it has three distinct share classes: a retail euro-denominated accumulating class, a retail Swiss-franc-denominated currency-hedged accumulating class, and an institutional euro-denominated distributing class. Every field we discuss in this chapter exists at one of two levels: either at the level of the fund as a whole, or at the level of an individual share class. The two levels are easy to mix up, and a reader who has to track both at once while also learning about identifiers, classification, and fees is going to struggle.</p>
<p>We therefore take the chapter in four parts. <strong>Part I</strong> (§5.2 to §5.7) pretends the Europa Growth Fund has exactly one share class and treats every topic as though it lived cleanly on the fund element. <strong>Part II</strong> (§5.8 to §5.11) relaxes the pretence, puts the three share classes back, and walks through the topics on which the fund-level picture branches. <strong>Part III</strong> (§5.12 and §5.13) treats the dynamic data — NAVs, total net assets, performance figures — in the light of the share-class structure we have just built. <strong>Part IV</strong> (§5.14 to §5.17) covers umbrella funds, assembles the complete <code>Fund</code> element, lists the common pitfalls, and summarises the chapter. By the end of Part I the reader should feel comfortable reading a fund's identity; by the end of Part II the reader should be able to talk fluently about share classes; by the end of the chapter the reader should be able to read a complete <code>Fund</code> element on sight and know which of the remaining chapters of Part II of the book each fragment of it belongs to.</p>
<p>By the end of this chapter, you should be able to:</p>
<ul>
<li>identify which information in FundsXML belongs to a fund and which belongs to a share class;</li>
<li>produce and populate every mandatory field of the <code>Fund</code> element for a realistic European UCITS;</li>
<li>choose the right identifier for every jurisdiction in which a fund is distributed;</li>
<li>model multilingual fund data without duplicating documents per language;</li>
<li>distinguish fund-level, share-class-level, and regulatory-level representations of fees and risk indicators;</li>
<li>read a complete <code>Fund</code> element with multiple share classes on sight and point at the pieces each later chapter of the book treats in depth.</li>
</ul>
<hr>
<h2>5.2 The Fund Element in Context</h2>
<p>Inside every FundsXML delivery, immediately after the ControlData envelope, sits a <a href="https://fundsxml.github.io/index.html?xpath=/FundsXML4/Funds" target="_blank"><code><Funds></code></a> container. The container is a simple list: it contains one or more <a href="https://fundsxml.github.io/index.html?xpath=/FundsXML4/Funds/Fund" target="_blank"><code><Fund></code></a> elements, each representing a single fund. The list is the schema's way of saying that one delivery may describe more than one fund at a time.</p>
<p>Two production patterns dominate in practice. The first pattern, <strong>one fund per file</strong>, is the one we have been assuming so far: the Europa Growth Fund is delivered in its own FundsXML file, the <code><Funds></code> container holds exactly one <code><Fund></code>, and the distributor's dispatcher routes the file by looking at the DataSupplier and the fund's ISIN. This pattern is common when the producer wants fine-grained control over who receives which fund — particularly where distribution agreements vary by country or share class. The second pattern, <strong>several funds per file</strong>, is more common in fund-administrator batches: a single file carries every fund the administrator serves for a given asset-management client, often several dozen at a time. The container form of <code><Funds></code> exists precisely so that the second pattern does not require a wrapper document of its own. Both patterns are valid FundsXML; the choice between them is a pipeline design decision, not a schema decision, and Chapter 12 will come back to it when it discusses integration into system landscapes.</p>
<p>Whichever pattern is used, each <code><Fund></code> element has the same shape. Four elements are mandatory and appear at the very top of every <code><Fund></code>; the rest follow the separation of static and dynamic data that we named in Chapter 3 as design principle 1, and are wrapped into an optional <a href="https://fundsxml.github.io/index.html?xpath=/FundsXML4/Funds/Fund/SingleFund" target="_blank"><code><SingleFund></code></a> container (for non-umbrella funds) or a <code><Subfunds></code> container (for umbrella structures, §5.14):</p>
<pre><code><span class="tok-punct"><</span><span class="tok-tag">Fund</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">Identifiers</span><span class="tok-punct">></span>
<span class="tok-comment"><!-- LEI of the fund and any other fund-level identifier --></span>
<span class="tok-punct"></</span><span class="tok-tag">Identifiers</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">Names</span><span class="tok-punct">></span>
<span class="tok-comment"><!-- OfficialName, optionally MarketingName, ShortName, LanguageNames --></span>
<span class="tok-punct"></</span><span class="tok-tag">Names</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">Currency</span><span class="tok-punct">></span>EUR<span class="tok-punct"></</span><span class="tok-tag">Currency</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">SingleFundFlag</span><span class="tok-punct">></span>true<span class="tok-punct"></</span><span class="tok-tag">SingleFundFlag</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">FundStaticData</span><span class="tok-punct">></span>
<span class="tok-comment"><!-- domicile, legal structure, classifications, benchmarks, ongoing costs, ... --></span>
<span class="tok-punct"></</span><span class="tok-tag">FundStaticData</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">FundDynamicData</span><span class="tok-punct">></span>
<span class="tok-comment"><!-- fund-level total net assets, portfolio, fund-level benchmark values, ... --></span>
<span class="tok-punct"></</span><span class="tok-tag">FundDynamicData</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">SingleFund</span><span class="tok-punct">></span>
<span class="tok-comment"><!-- SingleFundStaticData and the list of ShareClasses --></span>
<span class="tok-punct"></</span><span class="tok-tag">SingleFund</span><span class="tok-punct">></span>
<span class="tok-punct"></</span><span class="tok-tag">Fund</span><span class="tok-punct">></span>
</code></pre>
<p>The shape deserves two observations. First, <code>Identifiers</code>, <code>Names</code>, <code>Currency</code>, and <code>SingleFundFlag</code> are <strong>mandatory</strong> and appear before the static/dynamic split. They establish the fund's identity before anything else; a <code><Fund></code> element that omits them is not schema-valid. Second, the static/dynamic split is not cosmetic. Many real pipelines ship <a href="https://fundsxml.github.io/index.html?xpath=/FundsXML4/Funds/Fund/FundStaticData" target="_blank"><code>FundStaticData</code></a> only when something has changed — perhaps once a month, perhaps only when a new share class is launched or a fee is revised — while shipping a fresh <a href="https://fundsxml.github.io/index.html?xpath=/FundsXML4/Funds/Fund/FundDynamicData" target="_blank"><code>FundDynamicData</code></a> block every valuation day. Doing so is entirely legal: both <code>FundStaticData</code> and <code>FundDynamicData</code> are optional, a delivery may contain one, the other, or both, and consumers are expected to maintain the last-known state of each half independently. The DataOperation semantics of Chapter 4 apply to whichever half is present.</p>
<p>The <code><SingleFund></code> wrapper is where the share-class structure lives. Newcomers often expect <a href="https://fundsxml.github.io/index.html?xpath=/FundsXML4/Funds/Fund/SingleFund/ShareClasses" target="_blank"><code><ShareClasses></code></a> to hang off <code>FundStaticData</code>, but the schema puts them one level higher: <code>Fund/SingleFund/ShareClasses</code>, as a sibling of the static/dynamic blocks rather than a child of the static one. The reason is that <code><SingleFund></code> is one of two alternatives — the other being <code><Subfunds></code> for umbrella structures — and making the choice a first-class sibling keeps the two cases symmetric. We take <code><SingleFund></code> as the running case for the whole chapter and return to <code><Subfunds></code> in §5.14.</p>
<p><strong>Figure 5.1 — <code>Funds</code> as a list</strong></p>
<pre><code> <span class="tok-punct"><</span><span class="tok-tag">Funds</span><span class="tok-punct">></span>
│
┌──────────────┼──────────────┬──────────────┐
│ │ │ │
<span class="tok-punct"><</span><span class="tok-tag">Fund</span><span class="tok-punct">></span> <span class="tok-punct"><</span><span class="tok-tag">Fund</span><span class="tok-punct">></span> <span class="tok-punct"><</span><span class="tok-tag">Fund</span><span class="tok-punct">></span> <span class="tok-punct"><</span><span class="tok-tag">Fund</span><span class="tok-punct">></span>
│ │ │ │
Static Static Static Static
Dynamic Dynamic Dynamic Dynamic
</code></pre>
<p>Each of the <code><Fund></code> boxes is structurally independent of the others: a consumer that cares only about one fund can read that fund and stop without loss of correctness. The AssetMasterData library (Chapter 6) lives outside the <code><Funds></code> container, as we saw in Chapter 3, so that instruments shared between several funds in the same delivery can be described once and referenced many times. That cross-fund sharing is the subject of Chapter 6, not this one; Chapter 5 treats each <code><Fund></code> as though it were the only fund in the file.</p>
<hr>
<h2>5.3 FundStaticData vs FundDynamicData Revisited</h2>
<p>Chapter 3 introduced the static/dynamic split as design principle 1. Now that we are about to populate each half, it is worth pausing to ask a more operational question: <em>which field goes where?</em> The principle is intuitive in the limit — a fund's legal name is static, its NAV is dynamic — but the middle is less obvious. Is the <em>launch date</em> of the fund static or dynamic? It never changes, so it sounds static, but many reference systems store it alongside performance data for historical calculations, which makes it feel dynamic. Is the fund's <em>ongoing charges</em> figure static? It is published once a year and does not move between publications, so it is static by default, but a producer that recomputes it on demand at every delivery could reasonably place it in the dynamic half. FundsXML takes a position on each of these questions, and the position is worth understanding because it is the organising principle of every <code>Fund</code> element in the book.</p>
<p>The rule of thumb is straightforward. A field belongs in <code>FundStaticData</code> if, in the ordinary course of operating a fund, it would <em>not</em> need to be re-transmitted to downstream consumers on every valuation day. A field belongs in <code>FundDynamicData</code> if, in the ordinary course of operating a fund, it <em>would</em>. Table 5.1 summarises where the commoner fields land.</p>
<p><strong>Table 5.1 — Where the commoner fields of a fund live</strong></p>
<table>
<thead>
<tr>
<th>Mandatory header</th>
<th><code>FundStaticData</code></th>
<th><code>FundDynamicData</code></th>
<th><code>SingleFund</code> / <code><ShareClass></code></th>
</tr>
</thead>
<tbody>
<tr>
<td><code>Identifiers/LEI</code> (fund-level)</td>
<td><code>DomicileCountry</code></td>
<td>Fund-level <code>TotalAssetValues</code></td>
<td>Per-class <code>Identifiers</code> (ISIN, GermanWKN, SwissValorenCode)</td>
</tr>
<tr>
<td><code>Names</code></td>
<td><code>ListedLegalStructure</code></td>
<td>Fund-level benchmark values</td>
<td>Per-class <code>Names</code>, <code>Currency</code>, <code>ShareClassType</code></td>
</tr>
<tr>
<td><code>Currency</code></td>
<td><code>InceptionDate</code> (fund)</td>
<td>Portfolio composition <em>(→ Chapter 6)</em></td>
<td><code>SubscriptionRestrictions</code>, <code>CurrencyHedgedFlag</code></td>
</tr>
<tr>
<td><code>SingleFundFlag</code></td>
<td><code>FundTexts</code> (strategy, risk, …)</td>
<td></td>
<td><code>Prices</code> and per-class <code>TotalAssetValues</code></td>
</tr>
<tr>
<td></td>
<td><code>Classifications</code></td>
<td></td>
<td><code>Fees</code>, <code>Distributions</code>, <code>Flows</code> <em>(→ Chapter 7)</em></td>
</tr>
<tr>
<td></td>
<td><code>Benchmarks</code> (static)</td>
<td></td>
<td><code>PerformanceFigures</code></td>
</tr>
<tr>
<td></td>
<td><code>OngoingCosts</code></td>
<td></td>
<td><code>HighWatermark</code>, <code>InceptionDate</code> (per class)</td>
</tr>
<tr>
<td></td>
<td><code>SFDRProductType</code></td>
<td></td>
<td><code>RegistrationCountries</code></td>
</tr>
</tbody>
</table>
<p>Three lines of the table need commentary. <strong>Portfolio composition</strong> lives inside <code>FundDynamicData/Portfolios</code> — that is the reason the table lists it in the third column — but it is a large enough topic to deserve its own chapter, and this chapter does not treat it. Chapter 6 walks through every asset class and every position-level field. <strong>Transactions</strong> (subscriptions, redemptions, distributions, corporate actions) live at the share-class level: subscriptions and redemptions under <code>ShareClass/Flows</code>, dividend events under <code>ShareClass/Distributions</code>. They are the subject of Chapter 7. Sections §5.12 and §5.13 of this chapter will cover per-class NAVs, fund-level totals, and performance figures, and will elide portfolio and flow detail when we get there.</p>
<p>A fourth observation is worth stating while the table is in view. <strong>Per-class dynamic data lives on each class, not in <code>FundDynamicData</code>.</strong> NAV per unit, shares outstanding, per-class total net assets, per-class performance, per-class cash flows and distributions, and per-class portfolios all live inside the individual <code><ShareClass></code> element under <code>SingleFund/ShareClasses</code>. <code>FundDynamicData/TotalAssetValues</code> carries a single aggregate figure for the whole fund, and <code>FundDynamicData/Portfolios</code> carries a shared fund-level portfolio where classes are backed by a common asset pool. The split is not always intuitive at first reading; §5.12 returns to it with concrete examples.</p>
<p>The operational consequence of the split is worth stating plainly. In a pipeline designed with static/dynamic separation in mind, the producer's batch job runs in two phases. The first phase, triggered only when something in the fund's identity changes, emits a <code>FundStaticData</code> update — a new share class was launched, a fee was revised, a benchmark was switched. The second phase, triggered on every valuation day, emits a <code>FundDynamicData</code> update — today's NAVs, today's shares outstanding, today's portfolio, today's transactions. The two streams flow through the same FundsXML documents, are sequenced by the same DataOperation mechanics from Chapter 4, and are reconciled by the consumer into a single current-state picture. It is perfectly legal under the schema to ship both halves in every delivery — and many producers do, because the redundancy is cheap and the operational simplification is real. But the ability to split them is available when it matters.</p>
<hr>
<h2>5.4 Fund Identifiers — ISIN, WKN, LEI, Valor, and Friends</h2>
<p>The first substantive field group of the chapter is the one most likely to trip up a first-time implementer. FundsXML carries <em>several</em> identifiers for each fund, and the reason is that no single identifier universe covers all of the jurisdictions and all of the consumers that European fund data touches. A German investor needs a WKN. A Swiss investor needs a Valor. A regulator needs an LEI. A cross-border distribution agreement is written around ISINs. A legacy Bloomberg terminal may only accept its own proprietary ticker. All of these identifiers coexist, none of them is individually sufficient, and the schema supports all of them at once.</p>
<h3>5.4.1 The Hierarchy of Identifiers</h3>
<p>Identifiers in FundsXML live at two levels, and both levels use exactly the same container: a <a href="https://fundsxml.github.io/index.html?xpath=/FundsXML4/Funds/Fund/Identifiers" target="_blank"><code><Identifiers></code></a> element (of schema type <code>IdentifiersType</code>) that carries a fixed set of named children — <code>ISIN</code>, <code>Bloomberg</code>, <code>CUSIP</code>, <code>GermanWKN</code>, <code>LEI</code>, <code>MexID</code>, <code>ReutersRIC</code>, <code>SEDOL</code>, <code>SwissValorenCode</code>, <code>SwiftBIC</code> — plus a repeatable <code>OtherID</code> escape hatch for everything the schema does not name. One <code><Identifiers></code> block sits at the top of the <code><Fund></code> element and carries the fund-level identifiers; a separate <code><Identifiers></code> block sits at the top of each <code><ShareClass></code> element and carries the share-class-level identifiers. The two use the same vocabulary but populate different fields.</p>
<p>Some identifiers — principally the <strong>LEI</strong>, together with any regulator-issued fund number — identify the fund as a legal entity. These are <em>fund-level</em> identifiers; they exist once per fund and do not care how many share classes the fund has, and they sit inside the fund's own <code><Identifiers></code> container. Others — <strong>ISIN</strong>, <strong>GermanWKN</strong>, <strong>SwissValorenCode</strong>, <strong>CUSIP</strong>, <strong>Bloomberg ticker</strong> — identify a separately investable unit, which in practice means a single share class. These are <em>share-class-level</em> identifiers; a fund with three share classes has three <code><Identifiers></code> blocks, one per class, each populated with the instrument codes of its own class.</p>
<p>For the remainder of Part I we are pretending that the Europa Growth Fund has exactly one share class, so the distinction does not yet matter for narrative purposes: whenever we talk about <em>the fund's ISIN</em> in this part, what we really mean is <em>the ISIN of its only share class</em>. Part II (§5.9) will put the share-class-level identifiers in their proper place inside each <code><ShareClass></code>. The only identifier that actually <em>belongs</em> at the fund level is the LEI, and it will remain there throughout. Note that <strong>FundsXML uses the name <code>GermanWKN</code> for what German market participants usually call a WKN</strong>, and <strong><code>SwissValorenCode</code> for what the Swiss call a Valor</strong>. The rest of this chapter uses the short names <em>WKN</em> and <em>Valor</em> in prose and the schema names in XML fragments; readers writing code against the schema should prefer the long forms.</p>
<p>One point deserves to be made now, even before we look at any single identifier in detail: the <strong>LEI of the fund is not the LEI of its asset manager</strong>. Chapter 4 introduced the LEI of <em>Europa Asset Management S.A.</em> (<code>529900T8BM49AURSDO55</code>) as part of the <code>DataSupplier</code> block. The Europa Growth Fund itself, as a separate legal entity, has its own LEI — <code>549300ABCDEFGHIJKL34</code> — and it is this second identifier that appears in <code>Fund/Identifiers/LEI</code>, not the first. Confusing the two is a surprisingly common mistake among producers who have built their pipelines around a single "company LEI" and forgotten that a fund is a legal entity in its own right.</p>
<h3>5.4.2 The Core Identifiers in Detail</h3>
<p>We take the five most important identifier families in turn. Each entry below gives the structure of the identifier, its issuing body, the level at which FundsXML carries it, and the single most important operational rule associated with it.</p>
<p><strong>ISIN</strong> (International Securities Identification Number) is a twelve-character alphanumeric code defined by ISO 6166. The first two characters are the country of issue, the next nine are a national identifier, and the twelfth is a check digit computed by the Luhn-like algorithm of the standard. ISINs are issued by national numbering agencies — in Luxembourg, the <em>Clearstream Banking</em> numbering agency — and are the primary key of cross-border fund distribution in Europe. Every separately investable share class has its own ISIN; a fund with three share classes has three ISINs. At the fund level, strictly speaking, there is no single ISIN — only the collection of its share classes' ISINs — but many producers expose the principal class's ISIN at <code>FundStaticData</code> level as a shortcut for display purposes. The schema tolerates this as long as the same ISIN also appears on its owning share class.</p>
<p><strong>WKN</strong> (Wertpapierkennnummer) is a six-character alphanumeric code assigned by the German central numbering agency. It predates the ISIN by several decades and remains mandatory in German fact sheets, German regulator filings, and the displays of German retail broker systems. Every German-distributed share class has a WKN in addition to its ISIN; the two coexist and the same share class carries both. Producers who serve German consumers at any volume populate WKN for every distributed share class automatically.</p>
<p><strong>Valor</strong> is a five- to nine-digit numeric code issued by SIX Financial Information in Switzerland. It is the Swiss counterpart to WKN: mandatory for distribution into Switzerland, mandatory for Swiss stock-exchange listings, and expected by every Swiss consumer of fund data. The Europa Growth Fund, which is distributed into Switzerland, carries Valor numbers on its CHF-hedged share class (and often on its EUR classes as well, since Valor can identify any security that a Swiss intermediary may hold on behalf of a client).</p>
<p><strong>LEI</strong> (Legal Entity Identifier) is a twenty-character alphanumeric code defined by ISO 17442, issued by local operating units of the Global Legal Entity Identifier Foundation (GLEIF). Unlike ISIN, WKN, and Valor, the LEI identifies a <em>legal entity</em>, not a financial instrument. At the fund level, the LEI uniquely identifies the fund itself; at the umbrella level (which we will come to in §5.14), each sub-fund under the umbrella carries its own LEI and the umbrella carries another. LEIs are required for regulatory reporting under MiFID II, EMIR, AIFMD Annex IV, and SFDR, and producers who forget to populate them will find their deliveries rejected by regulator-facing consumers. Unlike the instrument identifiers, the LEI is also stable across corporate events — a rebranding, a merger, a translation of a legal name — which is why Chapter 4 recommended matching allowlists on LEI rather than on name.</p>
<p><strong>CUSIP</strong> (nine-character, North-American) and <strong>SEDOL</strong> (seven-character, British) appear occasionally on European funds that are marketed to international investors or listed outside Europe. They are less common than the first four, and FundsXML carries them as optional fields when they apply.</p>
<p><strong>Table 5.2 — Fund identifier families</strong></p>
<table>
<thead>
<tr>
<th>Schema element</th>
<th>Issuer</th>
<th>Level</th>
<th>Typical use</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>ISIN</code></td>
<td>National numbering agencies (ISO 6166)</td>
<td>Share class</td>
<td>Cross-border distribution, trading, reference data</td>
</tr>
<tr>
<td><code>GermanWKN</code></td>
<td>German WM-Datenservice</td>
<td>Share class</td>
<td>German factsheets, retail broker systems, BaFin filings</td>
</tr>
<tr>
<td><code>SwissValorenCode</code></td>
<td>SIX Financial Information (Switzerland)</td>
<td>Share class</td>
<td>Swiss distribution, SIX Swiss Exchange listings</td>
</tr>
<tr>
<td><code>LEI</code></td>
<td>GLEIF local operating units</td>
<td>Fund / sub-fund</td>
<td>Regulatory reporting under MiFID II, EMIR, AIFMD, SFDR</td>
</tr>
<tr>
<td><code>CUSIP</code></td>
<td>CUSIP Global Services (US/Canada)</td>
<td>Share class</td>
<td>Funds marketed to North-American investors</td>
</tr>
<tr>
<td><code>SEDOL</code></td>
<td>London Stock Exchange (UK)</td>
<td>Share class</td>
<td>British listings and broker systems</td>
</tr>
</tbody>
</table>
<h3>5.4.3 OtherID — the Escape Hatch</h3>
<p>No schema can enumerate every identifier that every consumer in every jurisdiction will ever need, and FundsXML does not try. For everything that the schema does not define explicitly — internal fund-administrator reference codes, national regulator codes, proprietary distributor identifiers, Morningstar fund IDs — there is the <strong><code>OtherID</code></strong> mechanism. An <code>OtherID</code> element sits inside <code><Identifiers></code> alongside the named children, carries a text value, and takes one of two attributes: <code>ListedType</code>, whose value is drawn from a long enumeration of recognised schemes (among them <code>INTERNAL FUND CODE</code>, <code>CSSF FUND CODE</code>, <code>BAFIN ID</code>, <code>AUSTRIAN FUND CODE</code>, <code>CNMV CODE</code>, <code>INAV BLOOMBERG LISTING CODE</code>, <code>REUTERS LISTING CODE</code>, and many others), or <code>FreeType</code>, an open string for schemes the enumeration does not cover. Consumers read the attribute to decide whether they recognise the scheme and, if so, how to interpret the value.</p>
<p>The escape hatch is valuable precisely because it is structured: unlike a generic "extra fields" blob, <code>OtherID</code> forces the producer to declare the scheme of every extra identifier, so that a consumer can decide field by field whether it knows what to do with each one. A typical production <code><Identifiers></code> block at the fund level carries the LEI and one or two <code>OtherID</code> entries — the producer's internal fund code under <code>ListedType="INTERNAL FUND CODE"</code>, perhaps the national regulator's fund code under <code>ListedType="CSSF FUND CODE"</code> for a Luxembourg fund. For producer-internal reference codes, <code>OtherID ListedType="INTERNAL FUND CODE"</code> is the idiomatic way to transport what some producers historically called a <em>DataSupplierFundID</em>; there is no dedicated element with that name in the schema.</p>
<p>The rule of discipline that matters is that an <code>OtherID</code> must <strong>never</strong> be used for an identifier that has a dedicated field. Writing the ISIN into an <code><OtherID ListedType="...">ISIN</OtherID></code> element instead of into the proper <code><ISIN></code> element is a recurring mistake — often the result of a mechanical generator that was configured before the producer learned about the dedicated element — and it breaks downstream consumers who look for ISIN at its expected location. The symptom is a consumer that "cannot find" the ISIN of a fund even though it is right there in the document; the fix is to move the identifier into its proper place and, often, to audit the producer for the same mistake on other fields.</p>
<hr>
<h2>5.5 Multilingual Names and Descriptions</h2>
<p>Design principle 4 from Chapter 3 — <em>multi-language by design</em> — meets the practicalities of European fund distribution in this section. A single UCITS may be sold in eleven countries under the same ISIN with the same portfolio and the same investment policy, but with eleven different marketing names, eleven translations of its investment objective, and eleven versions of its risk-and-reward narrative. Producing eleven separate FundsXML documents, one per language, would defeat the point of a standard; FundsXML therefore allows every textual field to carry several language variants side by side, so that a single delivery can serve every distribution country at once.</p>
<h3>5.5.1 The <code>Names</code> Container and the Language Attribute</h3>
<p>FundsXML models fund names through a single <a href="https://fundsxml.github.io/index.html?xpath=/FundsXML4/Funds/Fund/Names" target="_blank"><code><Names></code></a> container (schema type <code>NamesType</code>) whose children are <strong>named</strong> rather than polymorphic. A producer that wants several language variants does <em>not</em> repeat a generic <code><Name></code> element with different <code>language</code> attributes at the top of <code><Names></code>. Instead, <code><Names></code> holds a sequence of specifically named children — <code>OfficialName</code>, <code>FullName</code>, <code>MarketingName</code>, <code>ShortName</code>, <code>PreviousName</code>, <code>DynLenNames</code>, <code>LanguageNames</code> — and only the last of these, <code>LanguageNames</code>, is a repeatable container in which individual <code><Name></code> elements each carry a <code>language</code> attribute. The design keeps the single-language fast path simple (one <code><OfficialName></code> and done) and concentrates the multilingual machinery in one place.</p>
<p>A complete Europa Growth Fund <code><Names></code> block therefore looks like this:</p>
<pre><code><span class="tok-punct"><</span><span class="tok-tag">Names</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">OfficialName</span><span class="tok-punct">></span>Europa Asset Management Investments — Europa Growth Sub-Fund<span class="tok-punct"></</span><span class="tok-tag">OfficialName</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">MarketingName</span><span class="tok-punct">></span>Europa Growth Fund<span class="tok-punct"></</span><span class="tok-tag">MarketingName</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">ShortName</span><span class="tok-punct">></span>EGF<span class="tok-punct"></</span><span class="tok-tag">ShortName</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">LanguageNames</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">Name</span> <span class="tok-attr">language</span><span class="tok-punct">=</span><span class="tok-string">"de"</span><span class="tok-punct">></span>Europa Wachstumsfonds<span class="tok-punct"></</span><span class="tok-tag">Name</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">Name</span> <span class="tok-attr">language</span><span class="tok-punct">=</span><span class="tok-string">"fr"</span><span class="tok-punct">></span>Europa Fonds de Croissance<span class="tok-punct"></</span><span class="tok-tag">Name</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">Name</span> <span class="tok-attr">language</span><span class="tok-punct">=</span><span class="tok-string">"it"</span><span class="tok-punct">></span>Europa Fondo di Crescita<span class="tok-punct"></</span><span class="tok-tag">Name</span><span class="tok-punct">></span>
<span class="tok-punct"></</span><span class="tok-tag">LanguageNames</span><span class="tok-punct">></span>
<span class="tok-punct"></</span><span class="tok-tag">Names</span><span class="tok-punct">></span>
</code></pre>
<p>Three things about this block are worth stating explicitly. First, the <code><OfficialName></code> is <strong>mandatory</strong> — every <code><Names></code> container must have exactly one, and it is the only element inside <code><Names></code> that is required. It carries the fund's primary canonical name in the producer's canonical language, typically the language of the governing jurisdiction. Second, <code><MarketingName></code> and <code><ShortName></code> are optional fields for the public-facing name and its compact abbreviation; when they are present they apply <em>across languages</em>, because a single marketing name and a single short code are what distributors and broker systems actually display. Third, the <code>language</code> attribute inside <code><LanguageNames></code> takes an ISO 639-1 code — <em>en</em>, <em>de</em>, <em>fr</em>, <em>it</em>, <em>es</em>, <em>nl</em>, and so on — and each <code><Name language="xx"></code> element carries exactly one translation.</p>
<p>A consumer that needs a localised variant picks the matching <code>LanguageNames/Name</code>; if no variant matches its preferred locale, it falls back to the <code><MarketingName></code> (for display purposes), to the <code><OfficialName></code> (for legal purposes), or to a configured default language. The fallback discipline is a consumer-side concern; the producer's job is simply to populate as many language variants as the fund's distribution agreements require, and to populate them consistently. Producers should populate <em>all</em> relevant languages in every delivery, not only the language of the intended recipient. A single FundsXML file routed to a French distributor should still carry the German and Italian names alongside the French one, because downstream the distributor may feed the same file into a factsheet engine that renders in any of those languages. Filtering to a single language on the producer side is tempting and wrong.</p>
<h3>5.5.2 Types of Names</h3>
<p>The children of <code><Names></code> come in several shades, and they mean subtly different things. Confusing them is a routine cause of factsheets that display the wrong text.</p>
<p><strong><code>OfficialName</code></strong> is the fund's full legal name as it appears in the prospectus and in any court or regulatory filing. It is mandatory, and it is the only name that the producer is obliged to populate. For the Europa Growth Fund the official name is <em>Europa Asset Management Investments — Europa Growth Sub-Fund</em>, reflecting the sub-fund relationship even in the standalone-looking listings of this chapter. The official name is typically held in a single canonical language matching the governing jurisdiction; when a jurisdiction requires translations of the legal name, the translations go into <code>LanguageNames</code> alongside the marketing translations.</p>
<p><strong><code>FullName</code></strong> is an optional longer form that is used in umbrella structures to disambiguate a sub-fund from its umbrella. When a producer prefers to keep <code>OfficialName</code> as just the sub-fund's own name — <em>Europa Growth Sub-Fund</em> — the fully qualified <em>Umbrella SICAV — Europa Growth Sub-Fund</em> form goes into <code>FullName</code>. The two coexist and serve different display contexts.</p>
<p><strong><code>MarketingName</code></strong> is the marketing or commercial name of the fund — the name that appears on fact sheets, client portals, and advertising. For the Europa Growth Fund this is simply <em>Europa Growth Fund</em>. It is the name the producer wants end-users to see; it is typically shorter and friendlier than the legal name and may differ from it substantially.</p>
<p><strong><code>ShortName</code></strong> is an abbreviation or short code, used in compact displays such as tables and trading screens. For the Europa Growth Fund it is <em>EGF</em>. The short name is <em>not</em> intended to be multilingual: short codes are typically culturally neutral, and a single string serves all languages.</p>
<p><strong><code>PreviousName</code></strong> carries the most recent previous name of the fund after a rebranding, along with an <code>@until</code> attribute that names the date on which the previous name ceased to apply. Consumers that maintain historical reference-data joins read the previous name alongside the current one so that older data with the old name can still be matched to the fund.</p>
<p><strong><code>DynLenNames</code></strong> carries several length-constrained variants of the current name for display systems that truncate at fixed widths — a 16-character short form, a 32-character medium form, a 64-character long form. Producers use it when their consumers include legacy terminals that would otherwise butcher the marketing name. It is optional and rarely populated in modern deliveries.</p>
<p><strong><code>LanguageNames</code></strong> is the container for translated variants, as we saw in §5.5.1. Each <code><Name></code> child inside it carries a two-letter ISO 639-1 <code>language</code> attribute and one translation.</p>
<p>Producer-internal reference codes — what some producers historically called a <em>DataSupplierFundID</em> — do <strong>not</strong> live inside <code><Names></code>. They live inside <code><Identifiers></code> as an <code>OtherID</code> entry with <code>ListedType="INTERNAL FUND CODE"</code>, as §5.4.3 described. This is worth saying twice because the historical name of the field misled an entire generation of integrators into looking for it in the wrong place.</p>
<h3>5.5.3 <code>FundTexts</code> — Investment Objectives, Policies, and Narratives</h3>
<p>Longer textual fields — <em>investment objective</em>, <em>investment policy</em>, <em>risk profile narrative</em>, <em>investor profile description</em> — do not live inside <code><Names></code>. They live in a separate container, <code>FundStaticData/FundTexts</code>, whose <code><FundText></code> children each carry one piece of free-form text alongside its metadata. These are the fields that feed factsheet generators and client-portal descriptions, and their quality determines whether a fund reads like a carefully prepared product or like a machine translation.</p>
<p>Each <code><FundText></code> element has the following shape. A <code><Language></code> child (mandatory) names the language of the content using an ISO 639 code. A <code><Date></code> child (mandatory) names the date on which the text is valid — important because investment-policy wording is revised periodically and consumers need to know which version they are reading. One of <code><ListedType></code> or <code><UnlistedType></code> (a mandatory choice) names the kind of text: the listed enumeration covers the most common regulated categories — <code>INVESTMENT STRATEGY</code>, <code>INVESTOR PROFILE</code>, <code>RISK DESCRIPTION</code>, <code>RISK MANAGEMENT</code>, <code>FEES</code>, <code>BENCHMARK</code>, <code>SUBS REDS</code>, <code>LEGAL INFORMATION</code>, <code>TAX INFORMATION</code>, <code>ANNUAL REPORT</code>, <code>SEMI ANNUAL REPORT</code> — and <code><UnlistedType></code> takes a short free-form label for text categories that the enumeration does not cover. An optional <code><Title></code> supplies a display title in the chosen language. A <code><Content></code> element (mandatory) carries the text itself. An optional <code><CountriesWhereApplicable></code> lists the distribution countries in which this text variant is permitted, for producers that ship jurisdiction-specific wording.</p>
<p>A fund that carries an investment objective in English and German therefore emits two <code><FundText></code> elements as siblings inside <code><FundTexts></code>, one per language, each with the same <code><ListedType>INVESTMENT STRATEGY</ListedType></code> and the same <code><Date></code>. A fund that additionally carries a risk description emits further <code><FundText></code> elements with <code><ListedType>RISK DESCRIPTION</ListedType></code>. A single <code><FundTexts></code> block in a realistic delivery typically contains between six and twenty entries, covering the main text categories in the main distribution languages.</p>
<p>Two rules of practice are worth following.</p>
<p>First, <strong>the first sentence of <code><Content></code> must stand alone</strong>. Many downstream consumers — compact fact-sheet templates, distributor search results, one-line product cards — truncate longer descriptions after a fixed number of characters, typically one hundred and fifty to two hundred. A description whose first sentence only makes sense in the context of the second will look mangled in every such consumer. Producers should write the first sentence as a self-contained summary and use the remaining sentences for elaboration.</p>
<p>Second, <strong>do not embed HTML or other markup</strong> in <code><Content></code>. Some consumers escape the markup, some pass it through, and some strip it entirely, and the resulting inconsistency is a well-known source of visible bugs. If a description needs formatting, handle the formatting on the consumer side, or use the root-level <code><Documents></code> section (Chapter 9) to deliver a separate rich-text version as a PDF or as structured <code><BinaryData></code>.</p>
<p>One interaction is worth noting here for later reference. Chapter 8 treats the FinDatEx regulatory templates (EMT, EPT, EET), and these templates define their own normalised text fields for certain regulated disclosures — the PRIIPs risk narrative, the SFDR sustainability statement, the MiFID target-market description. Where a regulated text field exists, its regulatory version <em>overrides</em> the informal <code><FundText></code> entries for the purpose of regulatory consumers, but the informal version continues to serve unregulated consumers such as marketing factsheets. Producers should populate both consistently; consumers should read whichever is appropriate to their use case.</p>
<hr>
<h2>5.6 Fund Classification</h2>
<p>Every fund in FundsXML carries a set of classification fields that describe what the fund <em>is</em> — in legal, geographic, and investment terms. The classification fields are not the same as the regulatory templates of Chapter 8; they are the fund's own self-description, used by factsheet engines, by distributor search and filter tools, and by internal reference systems. We treat them in three groups: legal form and origin, investment characteristics, and risk-and-benchmark indicators. Almost everything in this section lives inside <code>FundStaticData</code>, at the fund level; registration countries are the one exception and belong to each individual share class (§5.10).</p>
<h3>5.6.1 Legal Form, Domicile, and Inception</h3>
<p>The first group answers the question <em>where does this fund come from, and under what legal form?</em></p>
<p><strong><code>DomicileCountry</code></strong> is the ISO 3166-1 alpha-2 code of the jurisdiction in which the fund is legally domiciled, carried as the very first child of <code>FundStaticData</code>. For the Europa Growth Fund this is <code>LU</code> — Luxembourg, the European fund domicile of choice for cross-border UCITS. The domicile determines which supervisor regulates the fund, which legal form it can take, and which tax regime applies at the fund level.</p>
<p><strong>Registration countries are not a fund-level field.</strong> A fund may be domiciled in one country and <em>registered for distribution</em> in several others; in fact, cross-border distribution is the whole point of the UCITS regime. The Europa Growth Fund is domiciled in Luxembourg and registered for distribution in eleven countries: Luxembourg itself, France, Germany, Italy, Spain, the Netherlands, Austria, Belgium, Portugal, Switzerland, and Sweden. A natural first instinct is to model this as a list of <code>CountryOfRegistration</code> children on the fund, but the schema puts the list one level lower: <code>ShareClass/RegistrationCountries/RegistrationCountry</code>, with each entry naming a country code and an operational status (<code>Registered</code> or <code>De-registered</code>). The reason is that two share classes of the same fund may be registered in different countries — the institutional class may be authorised in fewer jurisdictions than the retail class — and a single fund-level list cannot express that. §5.10 returns to this.</p>
<p><strong>Legal structure</strong> is expressed through a choice between <code>ListedLegalStructure</code> (an enumerated field covering the common European vehicle types) and <code>UnlistedLegalStructure</code> (a free-text fallback). Both alternatives are declared with <code>minOccurs="0"</code>, which means the schema accepts a <code>FundStaticData</code> block that omits the legal structure entirely — producers may do so for funds whose legal nature is carried in country-specific extensions instead. In practice every realistic European fund populates one of the two, and for the Europa Growth Fund we always pick <code>ListedLegalStructure</code>. The enumeration is specific and combines the regulatory regime with the corporate form in single values: <code>UCITS</code>, <code>UCITS - SICAV</code>, <code>UCITS - SICAF</code>, <code>UCITS - CONTRACTUAL TYPE</code>, <code>AIF</code>, <code>AIF - HEDGE FUND</code>, <code>AIF - PRIVATE EQUITY FUND</code>, <code>AIF - VENTURE CAPITAL FUND</code>, <code>AIF - REAL ESTATE FUND</code>, <code>AIF - REIT</code>, <code>AIF - INFRASTRUCTURE FUND</code>, <code>AIF - COMMODITY FUND</code>, <code>AIF - SOVEREIGN WEALTH FUND</code>, <code>AIF - ELTIF</code>, <code>AIF - EUVECA</code>, <code>AIF - EUSEF</code>, and <code>SPV</code>. Because the values already combine regime and corporate form, a producer does <strong>not</strong> emit two separate entries for <em>UCITS</em> and <em>SICAV</em>: the Europa Growth Fund, which is a UCITS operating as a SICAV, is represented by a single <code><ListedLegalStructure>UCITS - SICAV</ListedLegalStructure></code>. The enumeration is the tricky part of this field — producers that try to model the regulatory regime and the corporate form as two independent fields invariably drift away from the schema, and consumers that try to parse the enumerated value into its two halves regret the effort.</p>
<p><strong><code>InceptionDate</code></strong>, a direct child of <code>FundStaticData</code>, is the date on which the fund first opened for subscription. It is a single <code>xs:date</code> value, and it never changes once the fund is live. The inception date is the anchor for every <em>since-launch</em> performance figure, and consumers that compute annualised returns rely on it. One subtlety deserves an early mention: the fund-level inception date may be earlier than the inception dates of some of the fund's <em>share classes</em>, because share classes can be added to an existing fund long after the fund itself was launched. Every <code><ShareClass></code> element therefore also carries its own <code><InceptionDate></code>, and Part II (§5.10.3) will treat share-class-level inception in detail.</p>
<p>The schema also carries a handful of adjacent date and status fields that a full <code>FundStaticData</code> block is likely to populate: <code>StartOfFiscalYear</code> and <code>EndOfFiscalYear</code> (as a <code>DayMonthType</code> pair), <code>OpenClosedEnded</code> (<code>OPEN</code> or <code>CLOSED</code>), <code>ClosedType</code> (<code>HARD</code> or <code>SOFT</code>) for funds that have stopped accepting new subscriptions, and <code>MaturityDate</code>/<code>LiquidationDate</code>/<code>LiquidationReason</code> for funds with a planned end. These are all optional, and we do not populate them for the Europa Growth Fund, which is an open-ended UCITS with no fixed maturity and no liquidation date in sight.</p>
<h3>5.6.2 Investment Classification via <code>Classifications</code></h3>
<p>The second group of classification fields describes <em>what</em> the fund invests in. Here the schema takes a deliberately indirect approach: instead of defining a single closed vocabulary for asset class, geography, sector, and management style — which would drift out of date every time an industry body published a new taxonomy — FundsXML lets producers declare their classifications in terms of <strong>external classification systems</strong>. The container is <code>FundStaticData/Classifications</code>, and each child <code><Classification></code> carries the source of the classification, its internal type, a language, and one or more values, optionally tagged with a level attribute for hierarchical taxonomies.</p>
<p>The structure of each <code><Classification></code> is:</p>
<ul>
<li>a choice between <code><ListedGroup></code> (a known classification provider, drawn from an enumeration that includes <code>EFAMA</code>, <code>MORNINGSTAR</code>, <code>LIPPER</code>, <code>BLOOMBERG</code>, <code>MIFID</code>, <code>BVI</code>, <code>VOEIG</code>, <code>ESMA</code>, <code>AMF</code>, <code>WM</code>, <code>GERMAN CBCL</code>, <code>CIC</code>, and <code>CFI</code>) and <code><UnlistedGroup></code> (a free-text fallback for classifications from bodies the enumeration does not cover);</li>
<li>an optional <code><Type></code> giving the specific taxonomy within the provider (for EFAMA, for example, <em>EFC</em> for the European Fund Classification; for Morningstar, <em>Global Category</em>);</li>
<li>an optional <code><Language></code> attributing the language of the value strings;</li>
<li>one or more <code><Value></code> elements, each with the classification label and an optional <code>level</code> attribute for hierarchies.</li>
</ul>
<p>The Europa Growth Fund carries two classifications in parallel — one from EFAMA and one from Morningstar:</p>
<pre><code><span class="tok-punct"><</span><span class="tok-tag">Classifications</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">Classification</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">ListedGroup</span><span class="tok-punct">></span>EFAMA<span class="tok-punct"></</span><span class="tok-tag">ListedGroup</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">Type</span><span class="tok-punct">></span>EFC<span class="tok-punct"></</span><span class="tok-tag">Type</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">Language</span><span class="tok-punct">></span>en<span class="tok-punct"></</span><span class="tok-tag">Language</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">Value</span> <span class="tok-attr">level</span><span class="tok-punct">=</span><span class="tok-string">"1"</span><span class="tok-punct">></span>Equity<span class="tok-punct"></</span><span class="tok-tag">Value</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">Value</span> <span class="tok-attr">level</span><span class="tok-punct">=</span><span class="tok-string">"2"</span><span class="tok-punct">></span>Equity Europe<span class="tok-punct"></</span><span class="tok-tag">Value</span><span class="tok-punct">></span>
<span class="tok-punct"></</span><span class="tok-tag">Classification</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">Classification</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">ListedGroup</span><span class="tok-punct">></span>MORNINGSTAR<span class="tok-punct"></</span><span class="tok-tag">ListedGroup</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">Type</span><span class="tok-punct">></span>Global Category<span class="tok-punct"></</span><span class="tok-tag">Type</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">Language</span><span class="tok-punct">></span>en<span class="tok-punct"></</span><span class="tok-tag">Language</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">Value</span><span class="tok-punct">></span>Europe Large-Cap Growth Equity<span class="tok-punct"></</span><span class="tok-tag">Value</span><span class="tok-punct">></span>
<span class="tok-punct"></</span><span class="tok-tag">Classification</span><span class="tok-punct">></span>
<span class="tok-punct"></</span><span class="tok-tag">Classifications</span><span class="tok-punct">></span>
</code></pre>
<p>The advantage of this approach is that it lets each consumer read the classification it recognises. A European distributor that drives its product universe from EFAMA categories reads the <code>EFAMA</code> entry and ignores the Morningstar one; a research analyst whose watchlists are organised by Morningstar category reads the Morningstar entry and ignores the EFAMA one. A consumer that recognises neither can fall back to inspecting <code>OfficialName</code> or <code>Fund/Currency</code> as a last resort, but the <code>Classifications</code> block is what exists for the purpose. The cost is that a reader cannot simply ask <em>"is this an equity fund?"</em> with a single schema-level field: the answer depends on which classification system they read. That trade-off is deliberate, and it reflects the reality of European fund distribution, where no single classification taxonomy has ever achieved the status of the canonical one.</p>
<p>A handful of related flags live one level deeper, under <code>SingleFund/SingleFundStaticData</code>, because they describe the fund as a <em>single</em> (non-umbrella) vehicle: <code>ExchangeTradedFlag</code>, <code>FundOfFundFlag</code>, <code>SocialResponsibleFlag</code>, and — most importantly for classification purposes — <code>ManagementType</code>, which takes the two values <code>ACTIVE</code> and <code>PASSIVE</code>. The Europa Growth Fund is <code>ACTIVE</code>. Producers that want to express finer distinctions such as <code>EnhancedIndex</code> or <code>IndexTracking</code> do so through the <code>Classifications</code> block with an appropriate <code><ListedGroup></code> entry.</p>
<h3>5.6.3 Risk Indicators and Benchmarks</h3>
<p>The third group of classification fields quantifies risk and names the benchmark against which the fund measures itself.</p>
<p><strong><code>SFDRProductType</code></strong> is a fund-level field inside <code>FundStaticData</code> that names the SFDR (Sustainable Finance Disclosure Regulation) regime under which the fund is classified. It takes integer values <code>0</code>, <code>6</code>, <code>8</code>, or <code>9</code>: <em>6</em> for a fund that qualifies under Article 6 (no sustainability characteristics), <em>8</em> for an Article 8 fund (promotes environmental or social characteristics), <em>9</em> for an Article 9 fund (has sustainable investment as its objective), and <em>0</em> for funds that do not fall under SFDR at all. The Europa Growth Fund is a conventional Article 6 product and therefore carries <code><SFDRProductType>6</SFDRProductType></code>. The SFDR classification is the single most consequential ESG-related field in modern European fund disclosure, and consumers that drive ESG product filters read it directly.</p>
<p>The PRIIPs <strong>Summary Risk Indicator</strong> — the 1-to-7 scale familiar from KIDs and factsheets — does <em>not</em> live at the fund level as a dedicated element in the main schema. The reason is that the SRI is properly a share-class-level figure (different share classes of the same fund can sit at different SRI values, because hedging changes risk characteristics), and the regulated version of the SRI is expressed through the FinDatEx regulatory templates that Chapter 8 treats. Where producers want to carry the SRI alongside <code>FundStaticData</code> for legacy reasons, they do so through <code>CustomAttributes</code> with a name such as <em>SRI</em> and a numeric value. Consumers that need the authoritative SRI read the EMT or the PRIIPs-KID from the <code><Documents></code> section.</p>
<p><strong>Benchmark identification</strong> lives in <code>FundStaticData/Benchmarks/Benchmark</code>, as a repeatable element whose content follows <code>BenchmarkStaticDataType</code>. Each benchmark entry carries a <code><BenchmarkID></code> (an internal key used to link the static description to the dynamic values in <code>FundDynamicData/Benchmarks</code>), a mandatory <code><Name></code> and <code><Currency></code>, an optional <code><Provider></code> (a <code>CompanyType</code> subclass with its own <code><Identifiers></code> and <code><Name></code>), an optional <code><BenchmarkType></code> drawn from an enumeration (<code>Market Index</code>, <code>Blended Benchmark</code>, <code>Custom</code>, <code>Peer Groups and Universes</code>, and others), and an optional <code><BenchmarkComponents></code> block for composite benchmarks. The Europa Growth Fund carries a single benchmark entry:</p>
<pre><code><span class="tok-punct"><</span><span class="tok-tag">Benchmarks</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">Benchmark</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">BenchmarkID</span><span class="tok-punct">></span>MSCI-EUR-NR<span class="tok-punct"></</span><span class="tok-tag">BenchmarkID</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">Name</span><span class="tok-punct">></span>MSCI Europe Net Total Return EUR<span class="tok-punct"></</span><span class="tok-tag">Name</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">Currency</span><span class="tok-punct">></span>EUR<span class="tok-punct"></</span><span class="tok-tag">Currency</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">Provider</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">Identifiers</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">LEI</span><span class="tok-punct">></span>549300YZUBM5UFHQKY25<span class="tok-punct"></</span><span class="tok-tag">LEI</span><span class="tok-punct">></span>
<span class="tok-punct"></</span><span class="tok-tag">Identifiers</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">Name</span><span class="tok-punct">></span>MSCI Limited<span class="tok-punct"></</span><span class="tok-tag">Name</span><span class="tok-punct">></span>
<span class="tok-punct"></</span><span class="tok-tag">Provider</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">BenchmarkType</span><span class="tok-punct">></span>Market Index<span class="tok-punct"></</span><span class="tok-tag">BenchmarkType</span><span class="tok-punct">></span>
<span class="tok-punct"></</span><span class="tok-tag">Benchmark</span><span class="tok-punct">></span>
<span class="tok-punct"></</span><span class="tok-tag">Benchmarks</span><span class="tok-punct">></span>
</code></pre>
<p>The <code><BenchmarkID></code> is not itself a public identifier — it is a producer-chosen string that a later <code>FundDynamicData/Benchmarks/Benchmark</code> entry will reuse to tie dynamic level data to the static description. The schema enforces this relationship as a <code>key</code>/<code>keyref</code> pair: a dynamic benchmark block whose <code>BenchmarkID</code> does not match a static one is a schema violation, which is the schema's way of preventing a category of reference errors.</p>
<p>A consumer that computes relative performance — alpha, tracking error, information ratio — reads the benchmark's name and currency from the static block and joins against its own market-data source. §5.13 will pick up the dynamic side, where the actual benchmark level on 31 March 2026 is transported inside <code>FundDynamicData/Benchmarks</code> as a <code><Value></code> per date.</p>
<p>One forward pointer is worth placing here. Chapter 8 treats the regulatory templates that the fund embeds in the <code><RegulatoryReportings></code> root element, and EMT/EPT contain their own versions of the risk indicators, the cost aggregates, and the benchmark references that we are discussing now. Where both layers exist in the same delivery, the regulatory-template version takes precedence for regulatory consumers and the fund-level version serves everyone else. Producers populate both consistently. Consumers read whichever is appropriate to their use case and never try to reconcile one against the other at the millisecond level.</p>
<h3>5.6.4 Country-Specific Extensions</h3>
<p>A final word on classification: FundsXML is a pan-European standard, but European fund distribution is full of national idiosyncrasies that no single taxonomy can cover gracefully. The schema handles this through <strong><code>CountrySpecificData</code></strong>, an extension container that appears at two levels of a delivery. Inside <code>FundStaticData</code>, a <code><CountrySpecificData></code> element carries national reporting extensions that apply to the fund as a whole — Austrian OeNB reporting codes, French AMF sub-classifications, German BVI internal categories, and so on. The national schemas are maintained in separate files (<code>FundsXML4_CountrySpecificData_xx.xsd</code>) that follow the main schema's release cycle. A similar mechanism exists on each individual share class for class-level national extensions. The companion root-level <code><CountrySpecificData></code> element, which is a sibling of <code><Funds></code> rather than a child, carries country-specific content that is not structurally tied to a single fund. We do not populate <code>CountrySpecificData</code> for the Europa Growth Fund in this chapter — the running example deliberately stays inside the core schema — but producers that serve regulated pipelines in any one European country will almost always end up populating the relevant national extension, and the reader who meets such a block in a real delivery should recognise it as an extension point rather than as data the core schema has somehow mis-named.</p>
<hr>
<h2>5.7 Fund-Level Costs and Key Figures</h2>
<p>The last section of Part I treats the costs that a fund charges its investors, to the extent that they apply at the fund level rather than at the share-class level. FundsXML splits the cost story into two places. <strong>Fund-level aggregate figures</strong> — the retrospective per-annum ongoing charges and transaction costs that regulators require on KIDs and factsheets — live in <code>FundStaticData/OngoingCosts</code>. <strong>Per-class detailed fees</strong> — management fees and other charges that differ between share classes — live inside each <code><ShareClass></code> element under <code>Fees/Fee</code>. We introduce the fund-level side here; §5.10 will pick up the per-class side once the share-class structure is in place.</p>
<h3>5.7.1 Types of Costs</h3>
<p>European fund costs come in several flavours, and the vocabulary has accumulated enough layers over the years that it is worth naming them precisely before we model them.</p>
<p><strong>Management fee</strong> is the annual percentage charged by the asset manager for managing the portfolio. It is expressed as a fraction of the fund's net assets and is typically deducted daily in arrears. For a European equity UCITS aimed at retail investors the management fee might be 1.50% per annum; for an institutional class of the same fund it might be 0.75%. Management fees almost always differ between share classes and therefore live on the class.</p>
<p><strong>Administration fee</strong> and <strong>depositary fee</strong> are the charges levied by the fund's administrator and by its custodian bank, respectively. They are often bundled under a single "administration" line in marketing material but are structurally distinct in the fund's cost ledger. They are typically uniform across share classes, and producers can either absorb them into the fund-level ongoing charges figure or carry them as separate fee entries on each class, depending on whether the underlying contracts actually differ between classes.</p>
<p><strong>Performance fee</strong>, where it applies, is the share of the fund's out-performance that the asset manager retains as an incentive payment. A typical structure is <em>"20% of out-performance above benchmark, subject to a high watermark, crystallised annually"</em>. The three main parameters — rate, hurdle, and the high watermark — together define a complete performance-fee model. FundsXML handles the high watermark explicitly through <code>ShareClass/HighWatermark</code>, and the rate and basis through a fee entry whose <code>Type</code> names the performance fee structure. Producers that omit either the watermark or the fee entry leave consumers unable to reconstruct the actual charge.</p>
<p><strong>TER</strong> (Total Expense Ratio) and <strong>Ongoing Charges</strong> are the retrospective aggregate figures that sum the annual cost of running the fund — management fee, administration, depositary, audit, legal, and every other charge that the fund's investors collectively pay. The two terms are often used interchangeably; strictly speaking, <em>Ongoing Charges</em> (under UCITS KIID and PRIIPs) is slightly narrower than <em>TER</em> (the older EFAMA definition) in that it excludes performance fees, but the numeric values are usually similar. FundsXML carries the value through the <code>OngoingCosts/OngoingCost</code> structure described below, whose <code><CostType></code> field names which of the two variants the value represents.</p>
<p><strong>Entry load</strong> and <strong>exit load</strong>, when they apply, are one-time charges levied when an investor buys into or sells out of the fund. They are almost always set at the share-class level — one class of the same fund may charge a 3% entry load while another charges none — and we will return to them in §5.10.</p>
<h3>5.7.2 How Fund-Level Costs Are Modelled</h3>
<p>The fund-level cost block lives at <code>FundStaticData/OngoingCosts</code> and contains one or more <code><OngoingCost></code> children. Each child has a fixed shape: a mandatory <code><CostType></code> drawn from a short enumeration (<code>Ongoing Costs</code>, <code>Ongoing Charges</code>, <code>Performance Fee</code>, <code>Transaction Costs</code>), a mandatory <code><PublicationDate></code> (the date the figure was computed and published), optional <code><ValidFrom></code> and <code><ValidTo></code> dates for the period to which the value applies, a mandatory <code><Percentage></code> (the value itself, expressed as a decimal percentage — <code>1.85</code> means 1.85%, <em>not</em> 0.0185), and an optional <code><YearlyAmount></code> for the absolute amount per 10,000 units of investment in the fund's currency. A typical block for a fund whose annual ongoing charges have just been refreshed at the start of the new fiscal year looks like this:</p>
<pre><code><span class="tok-punct"><</span><span class="tok-tag">OngoingCosts</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">OngoingCost</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">CostType</span><span class="tok-punct">></span>Ongoing Charges<span class="tok-punct"></</span><span class="tok-tag">CostType</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">PublicationDate</span><span class="tok-punct">></span>2025-06-30<span class="tok-punct"></</span><span class="tok-tag">PublicationDate</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">ValidFrom</span><span class="tok-punct">></span>2025-07-01<span class="tok-punct"></</span><span class="tok-tag">ValidFrom</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">ValidTo</span><span class="tok-punct">></span>2026-06-30<span class="tok-punct"></</span><span class="tok-tag">ValidTo</span><span class="tok-punct">></span>
<span class="tok-punct"><</span><span class="tok-tag">Percentage</span><span class="tok-punct">></span>1.85<span class="tok-punct"></</span><span class="tok-tag">Percentage</span><span class="tok-punct">></span>
<span class="tok-punct"></</span><span class="tok-tag">OngoingCost</span><span class="tok-punct">></span>
<span class="tok-punct"></</span><span class="tok-tag">OngoingCosts</span><span class="tok-punct">></span>
</code></pre>
<p>A fund that also discloses a separate transaction-costs figure (common for PRIIPs-KID purposes) would add a second <code><OngoingCost></code> entry with <code><CostType>Transaction Costs</CostType></code> and its own percentage. The structure is deliberately flat: there is no place for hurdle rates or fee-waiver schedules at this layer, because the layer is designed to carry headline figures that feed factsheets and KIDs, not the full computational machinery behind a fee.</p>
<p>One observation about <code>OngoingCost</code> is worth making explicitly. The <code>Percentage</code> value is given in <strong>human-readable percent notation</strong>: <code>1.85</code> means 1.85 per cent per annum. This matches every other percentage in the schema (type <code>PercentageType</code>), and consumers that treat the value as a fraction (0.0185) will be off by a factor of a hundred — a spectacular error and, unfortunately, a recurring one. The rule of thumb is: if the number in <code><Percentage></code> looks like a reasonable management fee when you read it as a percent, it probably is; if it looks like a reasonable management fee after you divide by 100, you are about to make a mistake.</p>
<p>The fund-level block we have just assembled is the producer's own representation of its headline costs — the representation that feeds factsheet engines and distributor search tools. Chapter 8 treats the EMT (European MiFID Template), which defines a <em>different</em> and more detailed representation of the same charges, designed specifically for cost disclosure to retail investors under MiFID II. The EMT version is the definitive one for regulatory purposes; <code>OngoingCosts</code> in <code>FundStaticData</code> is the fund's operational view. Both exist in the same delivery, are populated consistently, and serve different consumers. The per-share-class detailed fee structure — <code>ShareClass/Fees/Fee</code> with its <code>ShareClassFeeType</code> — is the third layer, covered in §5.10, and it is where management fees and any class-specific surcharges actually live.</p>
<hr>
<h2>5.8 From One Share Class to Many</h2>
<p>So far we have pretended that the Europa Growth Fund has exactly one share class. It does not. It has three, and they are different enough from each other that treating them as one would hide most of what makes real European fund distribution interesting. Part II relaxes the pretence and walks through the topics on which the fund-level picture branches.</p>
<p>The three share classes of the Europa Growth Fund are worth introducing by name, because we will use all three for the rest of the chapter and again in every subsequent chapter of Part II:</p>
<ul>
<li><strong>R-EUR-ACC</strong> — the retail euro-denominated accumulating share class. Sold to individual investors across the eleven distribution countries, priced in EUR, and thesaurising all income into the NAV rather than paying dividends.</li>
<li><strong>R-CHF-ACC-HEDGED</strong> — the retail Swiss-franc-denominated currency-hedged accumulating share class. Aimed at Swiss retail investors who want exposure to European equities but do not want the EUR/CHF currency risk that would come with holding the ordinary euro class. The portfolio is the same as the R-EUR-ACC class; the difference is a currency overlay that hedges the EUR exposure into CHF.</li>
<li><strong>I-EUR-DIST</strong> — the institutional euro-denominated distributing share class. Aimed at pension funds, insurance companies, and other institutional investors who want predictable income distributions and who qualify for a lower fee schedule because of their minimum investment size.</li>
</ul>
<p>All three of these share classes belong to the same fund, hold the same portfolio, follow the same investment policy, are managed by the same team, and share the same benchmark. In everything we covered in Part I — legal form, domicile, investment classification, benchmark — they are identical. What differs between them is a specific set of fields that we now need to place inside individual <code><ShareClass></code> elements rather than on the fund itself.</p>
<p>The rule that organises the placement is straightforward: <strong>anything that differs between share classes lives on the <code><ShareClass></code> element; anything that is common to all classes stays on <code><Fund></code> and <code><FundStaticData></code></strong>. Table 5.3 shows where the main topics land when the rule is applied, using the schema names that actually appear in the XSD.</p>
<p><strong>Table 5.3 — Where the main fields live once share classes are in play</strong></p>
<table>
<thead>
<tr>
<th>Stays on <code><Fund></code> / <code>FundStaticData</code></th>
<th>Lives inside each <code><ShareClass></code></th>
</tr>
</thead>
<tbody>
<tr>
<td><code>Fund/Identifiers/LEI</code> (fund LEI)</td>
<td><code>ShareClass/Identifiers/ISIN</code>, <code>GermanWKN</code>, <code>SwissValorenCode</code></td>
</tr>
<tr>
<td><code>Fund/Currency</code> (fund base currency)</td>
<td><code>ShareClass/Currency</code> (class currency)</td>
</tr>
<tr>
<td><code>FundStaticData/DomicileCountry</code>, <code>ListedLegalStructure</code></td>
<td><code>ShareClass/RegistrationCountries/RegistrationCountry</code></td>
</tr>
<tr>
<td><code>FundStaticData/InceptionDate</code> (fund inception)</td>
<td><code>ShareClass/InceptionDate</code> (class inception)</td>
</tr>
<tr>
<td><code>FundStaticData/FundTexts</code> (investment strategy, risk)</td>
<td><code>ShareClass/ShareClassType</code> (<code>Code</code>, <code>EarningUse</code>)</td>
</tr>
<tr>
<td><code>FundStaticData/Classifications</code>, <code>Benchmarks</code></td>
<td><code>ShareClass/SubscriptionRestrictions/MinSubscriptionAmount</code></td>
</tr>
<tr>
<td><code>FundStaticData/OngoingCosts</code> (headline costs)</td>
<td><code>ShareClass/Fees/Fee</code> (per-class management fees, …)</td>
</tr>
<tr>
<td><code>FundStaticData/SFDRProductType</code></td>
<td><code>ShareClass/CurrencyHedgedFlag</code></td>
</tr>
<tr>
<td><code>FundDynamicData/TotalAssetValues</code> (fund aggregate)</td>
<td><code>ShareClass/Prices/Price</code> (NAV per unit)</td>
</tr>
<tr>
<td><code>FundDynamicData/Portfolios</code> <em>(→ Chapter 6)</em></td>
<td><code>ShareClass/TotalAssetValues</code> (class-level TNAV, shares outstanding)</td>
</tr>
<tr>
<td><code>FundDynamicData/Benchmarks</code> (dynamic benchmark values)</td>
<td><code>ShareClass/PerformanceFigures</code> (per-class returns)</td>