Kurz-Handbuch

Transcription

Kurz-Handbuch

WMS
Kurz-Handbuch
Version 1.0
Wertpapier Mitteilungen
Düsseldorfer Strasse 16
D - 60329 Frankfurt am Main
Frankfurt, Februar 2004
© 2004 WM-Gruppe
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Dokument berechtigt auch ohne besondere Kennzeichnung nicht zur Annahme, dass solche Namen im
Sinne der Warenzeichen- und Markenschutzgesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürfen.
FOF / Kurz-Handbuch Version 1.0
Inhaltsverzeichnis
Abbildungsverzeichnis ..................................................................................................................... 6
1. Einleitung ..................................................................................................................................... 7
2. Feed-Strukturen ........................................................................................................................... 8
2.1. Allgemeines......................................................................................................................... 8
2.2. Top-Level-Object-Ebene...................................................................................................... 8
2.3. Fachliche Ebene................................................................................................................... 9
3. Instrumente .................................................................................................................................10
3.1 Definition Finanzinstrument.................................................................................................10
3.2. Instrument-Identifikation.....................................................................................................10
3.3. Instrumenten-Gruppe ..........................................................................................................12
3.4 Cashflows ............................................................................................................................10
3.4.1. Typisierung von Zahlungen..................................................................................11
3.4.2. Einfache Zahlungen .............................................................................................11
3.5 Steuern ................................................................................................................................14
3.6 Handel .................................................................................................................................12
3.7 Instrumenten-Rating ............................................................................................................12
3.8 Instrumenten-Registrierung..................................................................................................12
3.9 Instrumenten-Kapital ...........................................................................................................12
3.10 Strukturierungen und Abhängigkeiten ................................................................................13
3.10.1. Zusammengesetzte Instrumente..........................................................................15
3.10.2. Abhängigkeiten unter Finanzinstrumenten..........................................................15
3.10.3. Mengen von Finanzinstrumenten........................................................................16
3.11 Meldewesen.......................................................................................................................13
3.12. Instrumentenbezogene Branchenzuordnung.......................................................................16
4. Institutionen ................................................................................................................................15
4.1 Definition Institution............................................................................................................15
4.2. Institutions-Identifikation....................................................................................................15
FOF / WMS
3/26
4.3. Institutions-Gruppen ...........................................................................................................15
4.4. Versammlungen..................................................................................................................15
4.5. Allgemeine Eigenschaften von Gesellschaftsereignissen .....................................................16
4.6. Institutions-Kapital .............................................................................................................17
4.7. Institutions-Registrierung....................................................................................................17
4.8. Institutions-Rating ..............................................................................................................17
4.9. Institutionsbezogene Branchenzuweisung ...........................................................................17
4.10. Stukturierungen und Abhängigkeiten ................................................................................17
4.10.1. Rollenverteilungen zwischen Institutionen .........................................................17
4.10.2. Abhängigkeiten zwischen Institutionen ..............................................................18
4.11. Zuweisung als Service-Dienstleistung ...............................................................................18
5. Feed - technische Übersicht ........................................................................................................19
5.1. Currency.............................................................................................................................21
5.2. Date, DailyTime, Timestamp, DayMonth............................................................................21
5.3. Enumeration .......................................................................................................................21
5.4. Flag....................................................................................................................................22
5.5. Numer, Size........................................................................................................................22
5.6. Amount, SignedValue, NormValue, Percentage ..................................................................22
5.7. InstrumentKey, InstitutionKey, InstrumentServiceKey, GeographicUnitKey.......................22
5.8. Symbol, Name, Description ................................................................................................22
5.9. ShortName, LongName, ShortDescr, LongDescr ................................................................22
6. Datenbereitstellung .....................................................................................................................23
6.1. Initial Load, tägliche Updates .............................................................................................23
6.2. Neartime Bereitstellung von Daten .....................................................................................23
6.3. Mehrsprachigkeit................................................................................................................23
7. Konzepte und wichtige Mechanismen ........................................................................................24
7.1. Top Level Object................................................................................................................24
7.2. Referenzdaten.....................................................................................................................25
7.3. Typisierung (Classification)................................................................................................26
7.4. Identifikationen ..................................................................................................................26
7.5. Technische Klassen (inkl. Reference Data Owner) ..............................................................26
7.6. 'Unbundling' .......................................................................................................................27
4/26
FOF / WMS
FOF / WMS
5/26
Abbildungsverzeichnis
Abbildung 1: Top-Level-Obejct-Ebenen ............................................................... 9
Abbildung 2: Grobe fachliche Gruppierungsübersicht ......................................... 11
Abbildung 3: TopLevelObject und seine Unterklassen ........................................ 24
Abbildung 4: Wertpapier-Management-System (WMS) ...................................... 28
6/26
FOF / WMS
1. Einleitung
Asset Backed Securities, Credit Linked Notes oder Zertifikate mit ihren diversen Underlyings
und/oder Knock Out-Charakter – die Komplexität dieser Produkte macht eine differenzierte
Strukturierung der Information notwendig. Aber auch einfache Instrumente benötigen in dem
immer dichter werdenden Netz des Reportings und Managementwesens eine klar strukturierte
Datenbankgrundlage.
Managemententscheidungen unter Mikro- und Makro-ökonomischen Aspekten und unter Berücksichtung der Anforderungen durch nationale aber auch länderübergreifende Einrichtungen
(BaFin, EU, EZB) verlangen eine effiziente und strukturierte Datengrundlage mit hoher Funktionalität. Diese Datengrundlage wird dann im Risiko- oder Asset-Management aber auch im
Reporting zur Entscheidungsvorbereitung und -findung herangezogen.
Mit dem WMS (Wertpapier-Management-System) ist es möglich, diese modernen Finanzdaten für das Management abzubilden (Abb. 1 auf S. Ende). Die Struktur dieser Datenbank lässt
auch eine differenzierte Nutzung dieses Systems zu. So kann der Anwender im Rahmen eines
Datenfeeds aus diesem System an der objektorientierten Datenbankstruktur partizipieren, ohne
das komplette System zu integrieren.
Grundlage für dieses System ist dass FIOM (Financial Instrument Object Model). Beim
FIOM-Modell handelt es sich um ein konzeptionelles Datenmodell, das mit mehr als 360
Klassen und mehr als 1950 Attributen alle bestehenden und zukünftigen Finanzinstrumente
und deren Zusammenhänge mit Institutionen oder Dienstleistungen (InstrumentService) abbilden kann.
Mit dem Datenfeed (Financial Object Feed, kurz: FOF) ist es möglich, einen oder mehrere
fachlich oder operationell zusammenhängende Themenbereiche, wie z. B. die eines Finanzinstrumentes, in einer objektorientierten Modellstruktur zusammenzufassen. Das Objekt wird in
seine einzelnen Bestandteile zerlegt und somit klar strukturiert. Damit können Informationen
für die Analyse, aber auch für das entsprechende Reporting, Trading, Clearing und Settlement
schneller und effizienter den Anwendungsprozessen zugeführt werden.
Diese logisch aufgebaute Modellstruktur, aus der der FOF generiert wird, lässt eine einfache
Darstellung der sehr komplexen Vorgänge zu. Eine historisch gewachsene Datenstruktur wird
durch eine auf die modernen Ansprüchen ausgerichtete Modellarchitektur ergänzt und ausgebaut.
Dieses Handbuch richtet sich gleichermassen an Personen, die als Bankfachleute den Inhalt
eines Feeds verstehen und beurteilen müssen, wie an Personen, die als Softwareentwickler
Programme erstellen müssen.
Im vorliegenden Dokument werden in den nächsten beiden Kapiteln die einzelnen Selektionsmöglichkeiten und Gruppierungen dargestellt. In Abschnitt 5 werden technische Details
erklärt sowie nähere Informationen über den Datentransfer geliefert. Kapitel 6 gibt dann einen
kurzen Überblick über die allgemeinen Strukturen des zugrundeliegenden Modells.
FOF / WMS
7/26
2. Feed-Strukturen
2.1. Allgemeines
Bei der Entwicklung des zugrundeliegenden Datenmodells wurden verschiedene Grundregeln
beachtet, welche auch für den Feed gelten:
bestimmte Eigenschaften, die ein Objekt aus der Finanzwelt beschreiben,
werden zu Klassen zusammengefasst
zur weiteren Strukturierung des Modells werden Beziehungen zwischen den
Klassen definiert
die entsprechenden Eigenschaften einer Klasse werden Attribute genannt
jedem Attribut wird ein bestimmter Wertebereich bzw. Domain zugeordnet
Eine Strukturierung des fachlichen Sachverhaltes wird durch entsprechende Namensgebungen
vorgenommen. So sind z. B. Haupteinstiegspunkte als "TopLevelObjecte", Gruppierungen in
"Group"-Klassen, Identifikationen in "Schemata"- und "ID"-Klassen zusammengeführt.
Nachfolgend werden die Möglichkeiten aufgezeigt, auf welcher Ebene Selektionen vorgenommen werden können:
a. Top-Level-Object Ebene (Kap. 2.2.)
b. Fachliche Ebene (Kap. 2.3.)
2.2. Top-Level-Object-Ebene
Für den "FOF" gilt, dass die Einstiegsmöglichkeiten in den Datenhaushalt über die folgenden
Bereiche (Top-Levels) möglich sind:
Instrument
Institution
InstrumentService
Abbildung 1: Top-Level-Object-Ebenen
Diese Einstiegsmöglichkeiten ergeben dann die verschiedenen Aspekte der Datensicht. Sollten
also Daten für ein Finanzinstrument benötigt werden, macht es sicherlich keinen Sinn, den
Einstieg über die Institution zu suchen und umgekehrt.
8/26
FOF / WMS
Instrument und Institution werden in den Kapiteln 3 und 4 detaillierter dargestellt. InstrumentService wird im nachfolgenden kurz erläutert.
InstrumentService
Unter InstrumentService sind Dienstleistungen zu verstehen, die von einer Institution im Zusammenhang mit einem Finanzinstrument übernommen werden. Die Typisierung der verschiedenen Dienstleistungen wird in folgenden Klassen abgebildet:
TradingPlace (Handelsplätze)
Clearing (Abwicklung)
FixingService
CustodyDepositary (Verwahrung)
MiscellaneousInstrumentService
2.3. Fachliche Ebene
Diese Gruppierungen der fachlichen Ebenen ermöglichen es dem Kunden, spezielle FeedAnforderungen zu stellen. Hier werden relevante Zusatzinformationen je nach Einstiegspunkt
hinzugefügt, damit eine fachliche Zuordnung zu dem entsprechenden Thema vorgenommen
werden kann.
Institution
Branchen/
Identifikation/
Gruppierung
Sektoren
Instrument
Identifikation/
Gruppierung
Listing /
Quotes
Versammlungen
CompanyEvent
Meldewesen/
Reporting
Rating
CorporateAction
CashFlow/
Payment
Portfolio
Steuern
Clearing/
PhysicalSec.
Abbildung 2: Grobe fachliche Gruppierungsübersicht
FOF / WMS
9/26
3. Instrumente
Ziel von Kapital 3 und 4 (Institution) ist es, einen Überblick über die möglichen Sachgebiete
zu liefern. Hierbei werden einige Begriffe näher dargestellt als andere. Dies soll lediglich einen ersten Eindruck vermitteln. Detailliertere Informationen werden in weiterführenden Dokumentationen gegeben.
3.1. Definition Finanzinstrument
Finanzinstrumente im Sinne des Modells sind von einer Institution ausgegebene, fungible
Vermögenswerte, die hauptsächlich oder ausschließlich finanzielle Ansprüche repräsentieren.
Zu den Finanzinstrumenten zählen aber auch alle weiteren Vermögenswerte, rechnerischen
Größen und weitere Rahmenbedingungen, welche in der Welt eine ähnliche Rolle wahrnehmen. Dazu gehören insbesondere Basiswerte, resp. Underlyings wie Indizes, Zinssätze und
Waren oder auch Edelmetalle. Aber auch Währungen sind Finanzinstrumente, da diese ebenfalls gegen andere Währungen gehandelt werden können und sie ebenfalls als Underlying für
z.B. Währungsoptionsscheine dienen können.
3.2. Instrument-Identifikation
I.d.R. werden für Finanzinstrumente spezifische Kennnummern vergeben. Diese dienen der
eindeutigen Identifizierung zwischen den Marktteilnehmern. Diese Kennnummern werden von
zentralen, nationalen Stellen wie z.B. WM, Telekurs, Reuters etc. vergeben, aber auch von
Börsen oder ähnlichen Institutionen. Dadurch ist es möglich, für ein Finanzinstrument beliebige Identifikationen festzuhalten.
3.3. Instrumenten-Gruppe
Der Bereich Instrumenten-Gruppen wird für spezifische Typisierungen von Instrumenten (z.B.
CFI) verwendet, welche entweder Provider-spezifisch oder von offiziellen Gremien (ANNA,
ISO etc.) vorgenommen werden.
3.4. Cashflows
Viele Finanzinstrumente vermitteln dem Inhaber Ansprüche auf definierte zukünftige Leistungen. Derartige Ansprüche können entweder unbedingte Zahlungen in einer bestimmten Währung, unbedingte Übertragungen anderer Finanzinstrumente oder Options- und Wandelrechte
zum Inhalt haben. Die wichtigsten derartigen Ansprüche sind diejenigen auf Zins-, Dividenden- und Rückzahlungen. Finanzinstrumente, die Ansprüche aufweisen, werden in der Klasse
InstrumentWithCF geführt und innerhalb dieses Typs weiter untergliedert. Für ein Instrument der Klasse InstrumentWithCF ist es massgeblich, ob es in einer beliebigen Phase seines
Lebenszyklus Ansprüche aufweisen kann, nicht ob es aktuell schon welche aufweist. Zahlungen sind meist schon bei Emission geplant. Bei Aktien und Anteilscheinen werden sie jedoch
erst kurz vor Ausschüttung bekannt.
10/26
FOF / WMS
Neben den allgemeinen Eigenschaften von Zahlungen oder Ansprüchen gibt es eine ganze
Reihe von Eigenschaften, die in mehr oder weniger häufigen Fällen vorkommen. Diese können entweder die Zahlung überhaupt, das Zahlungsinstrument, die Zahlungshöhe oder den
Zahlungszeitpunkt betreffen.
3.4.1. Typisierung von Zahlungen
In der Klasse CFDefinition werden alle gemeinsamen Eigenschaften einer Zahlung zusammengefasst. Zahlungen können dabei als Einzelzahlung wie auch als ein Bündel von Zahlungen auftreten. Die Einzelzahlungen werden in der Klasse CFReal festgehalten, alle Bündel
von einzelnen Zahlungen werden in der Klasse CFSet zu Strukturen verknüpft. Anschliessend
erfolgt eine weitere Typisierung von Cashflows. Zinszahlungen, Dividendenzahlungen, gesamtfällige Rückzahlungen usw. werden in der Klasse CFCommon erfasst. Vorzeitige Gesamtrückzahlungen und Tilgungen, die nur einen Teil der Exemplare eines Finanzinstruments
betreffen, werden in der Klasse Repayment dargestellt. Die Definition des effektiven Zahlungsbetrages erfolgt eine Stufe tiefer in der Klasse Payment, die ihrerseits fünf Ausprägungen
für die Typisierung von Payments enthält.
3.4.2. Einfache Zahlungen
Als einfache Zahlungen, die zu einem Finanzinstrument gehören, werden im FIOM alle diejenigen bezeichnet, die für jedes einzelne Exemplar eines Finanzinstruments gezahlt werden
bzw. jedem Inhaber des entsprechenden Finanzinstruments zustehen. Ausgeschlossen sind
vorzeitige, vollständige Rückzahlungen, bei denen alle zu einem späteren Zeitpunkt geplanten
Zahlungen ausfallen, sowie Zahlungen, die nur für einen Teil der Exemplare eines Finanzinstruments gelten. Beispiele für einfache Zahlungen sind: Zinszahlungen, endfällige Rückzahlungen, Annuitätentilgungen, Dividenden, Optionszahlungen. Diese einfachen Zahlungen werden mit der Klasse CFCommon abgebildet.
3.5. Steuern
Im FIOM werden nur sächliche, d.h. das Finanzinstrument betreffende Steuern und keine persönlichen Steuern abgebildet. Die verschiedenen Möglichkeiten der Besteuerung von Finanzinstrumenten seien im Folgenden am Beispiel von Deutschland aufgezeigt:
Quellensteuer
Fiktive Quellensteuer
Kapitalertragssteuer
Körperschaftssteuer
Zinsabschlagssteuer
FOF / WMS
11/26
3.6. Handel
Der Bereich Märkte des FIOM umfasst alle Informationen zur Handelbarkeit von Finanzinstrumenten an den jeweiligen Handelsplätzen/-systemen. Dazu gehört zunächst die Angabe,
welches Finanzinstrument zu welchen Bedingungen an welchem Handelsplatz gehandelt werden kann. Diese Information ist in der Klasse Listing zusammengefasst. Ein Handelsplatz ist
ein Service einer Gesellschaft und wird in einem separaten Kapitel behandelt. Die Konditionen, zu denen ein Finanzinstrument an einem Handelsplatz gehandelt werden kann, werden im
Bereich Märkte modelliert und unter dem Titel Handelsbedingungen zusammengefasst.
3.7. Instrumenten-Rating
Werden nur die Finanztitel, wie z. B. Bankschuldverschreibungen, Bundesanleihen, Geldmarkt- oder Rentenfonds oder Industrieobligationen geratet, handelt es sich um Emissionsratings.
3.8. Instrumenten-Registrierung
Grundsätzlich ist die rechtliche Grundlage als Beschreibung an der entsprechenden Institution
festgehalten. Die rechtlichen Grundlagen zu einem Finanzinstrument können jedoch von denen des Emittenten unterschiedlich sein. So ist das anwendbare Recht von ADRs nicht an das
Land des Emittenten gebunden.
3.9. Instrumenten-Kapital
Im Instrumentenkapital wird für Forderungs- und Beteiligungspapiere pro Kapitalart das Kapital respektive bei Beteiligungspapieren die Stückzahl pro Kapitalart geführt. Pro Änderung in
der Zukunft oder in der Vergangenheit werden die Zustände mit dem entsprechenden Gültigkeitsdatum zur Verfügung gestellt.
Das Instrumentenkapital wird benötigt:
12/26
um festzustellen, ab welcher Höhe Positionen meldepflichtig sind (z.B. sobald eine Position eine gewisse Höhe des umlaufenden Kapitals erreicht,
muss die Börse benachrichtigt werden)
für Auskunftszwecke bezüglich der Liquidität eines Wertpapiers (Analyse,
Anlageberatung)
um die Kapitalstruktur einer Gesellschaft errechnen zu können
um die Entwicklung der Kapitalstruktur nachzuzeichnen und besonders bei
Aktien auch auf die jeweiligen Kapitalereignisse zurückzuführen.
FOF / WMS
3.10. Strukturierungen und Abhängigkeiten
Finanzinstrumente können untereinander in unterschiedlichen Beziehungen stehen. Im FIOMDatenmodell können grundsätzlich drei Typisierungen derartiger Beziehungen vorgenommen
werden:
3.10.1. Zusammengesetzte Instrumente
Diese Finanzinstrumente setzen sich aus mehreren anderen Finanzinstrumenten zusammen.
Dabei ist es unerheblich, ob es sich bei diesen Instrumenten um echte Papiere oder nur um
synthetische Konstrukte handelt. Diese Teilinstrumente sind meist sofort oder während eines
bestimmten Zeitraumes voneinander trennbar und können nach Trennung in ihre Bestandteile
einzeln gehandelt werden. Als Beispiel dient hier die Optionsanleihe, bei der der Optionsschein wie die Anleihe sowohl zusammen als auch separiert gehandelt werden kann. Als synthetisches Konstrukt kann ein Basket bezeichnet werden. Die Zusammensetzung von Finanzinstrumenten geschieht durch Zuordnung der einzelnen Teile über die Klasse ComponentInstrumentProperties
3.10.2. Abhängigkeiten unter Finanzinstrumenten
Abhängigkeiten unter Finanzinstrumenten im Sinne des FIOM sind Konstellationen, bei denen
ein oder mehrere Instrument/-e von einem anderen abhängt. Als Beispiel kann hier die junge
Aktie angeführt werden, die in Abhängigkeit zur alten resp. Originalaktie steht. Die Zuordnung der Finanzinstrumente, die in Abhängigkeit zueinander stehen, geschieht über die Klasse
DependentInstrumentProperties.
3.10.3. Mengen von Finanzinstrumenten
Einige Finanzinstrumente gehören aus irgendwelchen Gründen zusammen. Das ist der Fall bei
einem sogenannten Umbrella-Fonds, der aus mehreren Subfonds bestehen kann. Während der
Umbrella das eigentliche rechtliche Gebilde darstellt, stellen die Unterfonds das Sondervermögen dar. Die Zusammensetzung dieser Fonds unter ein Umbrella-Konstrukt geschieht in der
Klasse ComponentTrustProperties. Dieser Fall wird in einem eigenen Kapitel gesondert behandelt.
3.11. Meldewesen
Für die im internationalen Geschäft tätigen Banken ist ein internationales und flexibles Meldewesen eine Grundvoraussetzung um ihre Geschäftstätigkeit gegenüber den nationalen/internationalen Meldebehörden sowie der Muttergesellschaft zu melden.
FOF / WMS
13/26
In Deutschland existieren aktuell u.a. folgende Meldetypen:
Wertpapierhandelsgesetz (WphG)
Außenwirtschaftsgesetz (AWV)
Risikoaktiva gemäß KWG
Bilanzstatistik (Bista)
InvestmentSteuerGesetz (InvStG)
3.12. Instrumentenbezogene Branchenzuordnung
Analog zur Gesellschaft kann auch ein Finanzinstrument einer bestimmten Branche zugeordnet werden. Während jedoch ein Unternehmen in mehreren Branchen tätig sein kann, so ist ein
Finanzinstrument genau einer Branche zuzuordnen.
14/26
FOF / WMS
4. Institutionen
4.1. Definition Institution
Eine Institution im allgemeinen ist eine einem bestimmten Bereich zugeordnete staatliche oder
öffentliche Einrichtung. Die drei grossen Klassen sind natürliche Personen, Gesellschaften,
wie z.B. Körperschaften, Vereine, Kapitalgesellschaften, Gesellschaften mit beschränkter Haftung u.a. sowie staatliche Institutionen, die Gebietskörperschaften repräsentieren wie z.B. die
Schweizerische Eidgenossenschaft.
Dazu gehören auch Gesellschaften, die als Emittenten von Finanzinstrumenten auftreten, als
Zahlstelle, Umtauschstelle, Verwahrstelle etc. fungieren, Regierungsstellen und andere mit
steuernden Befugnissen ausgestatteten Stellen, wie Handelsplätzen usw. Zu den Institutionen
gehören auch Produkte und Dienstleistungen wie Handelssysteme der Börsen und Informationssysteme der Datenanbieter.
4.2. Institutions-Identifikation
Zur Identifikation von Institutionen können spezielle Bezeichnungen geführt werden. Dies erfolgt durch die Definition eines Schemas und einer Identifikation.
4.3. Institutions-Gruppen
Der Bereich Institutionen-Gruppen wird für spezifische Typisierungen von Institutionen verwendet, welche entweder providerspezifisch oder von offiziellen Gremien vorgenommen werden. Diese Gruppierungen erlauben es, Institutionen aufgrund der Typisierungen vergleichen
zu können.
Die unterschiedlichen Gruppierungsansätze werden als separate Schemata für eine Gruppierung im Modell gehalten. So sollte z.B. für den von einem Provider publizierten InstitutionsGruppe ein separates InstitutionGroupScheme gehalten werden, um die dazugehörigen möglichen Institutionsgruppierungen in der Klasse InstitutionGroup festzuhalten. Die Zuordnung
der Institutionen zur jeweiligen Gruppierung erfolgt über die Klasse InstitutionGroupKey.
4.4. Versammlungen
Die Versammlung ist das oberste Organ einer Gesellschaft. Sie fasst sämtliche Beschlüsse,
soweit der Gesellschaftsvertrag nichts anderes vorsieht. Eine Versammlung kann abhängig
von ihrer Art (z.B. ordentliche Hauptversammlung, Gläubigerversammlung, Pressekonferenz)
laut Statuten an fest definierten Terminen oder aus Aktualitätsgründen jederzeit einberufen
werden
FOF / WMS
15/26
4.5. Allgemeine Eigenschaften von Gesellschaftsereignissen
Ausgehend von einer betroffenen respektive auslösenden Institution wird ein Gesellschaftsereignis angelegt. Die Darstellung eines Gesellschaftsereignisses erfolgt nach der Drei-EbenenPhilosophie, wobei direkt in den betroffenen Klassen Bezug darauf genommen wird. Zusätzlich werden die an einem Gesellschaftsereignis beteiligten Institutionen mit einer entsprechenden Rolle, die sie im Ereignis innehaben, versehen. Zum Beispiel sind bei einem Übernahmeangebot immer mindestens zwei Firmen beteiligt, der Übernahmekandidat und die übernahmewillige Gesellschaft.
Das FIOM Datenmodell kennt bis zu vier Typen von Teilereignissen (Gerichtsverfahren, Aktionärsumfragen, Institutions Stammdaten Änderungen und Kapitalereignisse). Das Teilereignis Kapitalereignis wird nachfolgend nähere erläutert.
Das FIOM unterscheidet drei Haupttypen von Kapitalereignissen. Solche, welche in eine Zahlung von zusätzlichen Mitteln resultieren (Cash Flow) und andere, die als Transformation dargestellt werden. Daneben kommen Ereignisse vor, die lediglich den Nominalwert des betroffenen Instruments verändern. Die Unterscheidung zwischen diesen beiden Klassen erfolgt in
der Form, ob die am Ereignis beteiligten Instrumente nach dem Gesellschaftsereignis fortbestehen oder dabei untergehen. Vorgänge, bei denen Instrumente untergehen, werden in der
Klasse Transformation dargestellt, Vorgänge, bei welchen nach deren Ablauf die am Ereignis
involvierten Instrumente weiterbestehen, werden in der Klasse CECashflow abgebildet.
Transformation
Unter einer Transformation werden die Aktionen beschrieben, die ein Aus- und Einbuchen unter einem veränderten Finanzinstrument zum Ziel haben. Dies können dementsprechend auch
Angebote sein, die eine Fusion betreffen, wobei der Erfolg nicht massgeblich ist.
CashFlow
Anhand eines Beispiels einer Kapitalerhöhung aus Gesellschaftsmitteln soll ein Gesellschaftsereignis im Sinne eines CECashflows nähergebracht werden. Im Zuge dessen werden alle involvierten Klassen kurz behandelt. Die genauen Beschreibungen erfolgen explizit in den einzelnen Klassen. Dieses Beispiel soll stellvertretend für alle Gesellschaftsereignistypen, die in
der Klasse CECashflow behandelt werden, gelten.
Ausgehend von der Klasse CapitalEvent wird definiert, dass es sich um eine Zahlung resultierend aus einem Gesellschaftsereignis handelt. Weiterhin wird in der Klasse CECashflow
angegeben, dass es sich um eine Kapitalerhöhung handelt, die wiederum aus Gesellschaftsmitteln erbracht wird. In der Klasse CapitalEventCashflow wird angegeben, dass es hier zu einer
Zuteilung von zusätzlichen Instrumenten kommt. Die Beziehung zum Ausgangsinstrument
dieses Ereignisses wird über die Klasse CompanyEventInstrument hergestellt. Die Beziehung zwischen den Klassen CapitalEventCashflow und CompanyEventKey stellt schließlich
den Einstiegspunkt in die Zahlung dar. Weiter wird in der Klasse CFDefinition die genaue
Zahlungsfunktion festgehalten, in diesem Fall „Gesellschaftsereignis“. Die Höhe der Zahlung
wird durch die Klasse Payment beschrieben. Die Nummer des Kupons, der zum Bezug der Instrumente berechtigt, die ausgeschüttet werden, wird in der Klasse CFValidationProperties
festgehalten.
16/26
FOF / WMS
Nominalveränderungen / Vorrechtszeichungen
Unter einer Nominalveränderung werden die Aktionen beschrieben, die lediglich eine Korrektur des betreffenden Finanzinstrumentes zum Ziel haben.
Unter einer Vorrechtszeichnung werden die Aktionen beschrieben, die für einen Altaktionär
eine besondere Behandlung vorsehen.
4.6. Institutions-Kapital
Es wird das Institutionskapital in seiner Historie wie auch in seiner geplanten Entwicklung beschrieben. Das aktuelle ausgegebene Kapital ist aus den entsprechenden Angaben der einzelnen Finanzinstrumente abzuleiten.
4.7 Institutions-Registrierung
Die rechtlichen Grundlagen einer Institution werden in den landesspezifischen Möglichkeiten
beschrieben. Dies umfasst den Gerichtsstand wie auch die rechtliche Ausgestaltung der
Institution.
4.8 Institutions-Rating
Wenn Ratings sich auf emittierende Organisationen wie z. B. Staaten, Länder, Industrieunternehmen oder Banken beziehen, spricht man von Emittentenrating.
4.9 Institutionsbezogene Branchenzuweisung
Innerhalb jedes Branchenverzeichnisses werden die Gesellschaften bestimmten Branchen zugeordnet. Dabei ist es für gewisse Verzeichnisse sinnvoll, jede Gesellschaft nur genau einer
Branche zuzuordnen. Es ist aber auch möglich, die Aktivitäten der Gesellschaft differenzierter
darzustellen, indem die verschiedenen Branchen zugeordnet werden und dabei eine Gewichtung vorgenommen wird.
4.10. Strukturierungen und Abhängigkeiten
Zwei oder mehrere Institutionen können einerseits bestimmte Rollen untereinander einnehmen, andererseits können Institutionen einer hierarchischen Struktur unterliegen. In welchen
Abhängigkeiten mehrere Institutionen zueinander stehen, wird in den Klassen RolePlayerProperties und DependentInstitutionProperties definiert.
4.10.1. Rollenverteilungen zwischen Institutionen
Eine zwischen verschiedenen Institutionen mögliche Rollenverteilung wie eine Prüfungsgesellschaft zu einer geprüften Gesellschaft oder eine Depotbank zu einer Kapitalanlagegesellschaft kann hier festgehalten werden.
FOF / WMS
17/26
4.10.2. Abhängigkeiten zwischen Institutionen
Die Zusammensetzung einer Institution stellt z. B. das Verhältnis zwischen einer Mutter/Tochter - Situation oder die Struktur einer Holding dar.
4.11. Zuweisung als Service-Dienstleistung
Bietet eine Institution eine Dienstleistung an, die für mehrere Finanzinstrumente ermöglicht
wird, kann über diese Verbindungsklasse eine entsprechende Dienstleistung verbunden werden.
18/26
FOF / WMS
5. Feed - technische Übersicht
Im nachfolgenden werden Angaben über technische Ausprägungen der verschiedenen Datentypen dargestellt.
5.1. Currency
Attribute dieses Typs identifizieren eine Währung über das Datenbankattribut InstrumentID
(z.B. eine spezielle ID für die Währung EUR, wobei der Wert "EUR" im Attribut idSymbol
der Klasse InstrumentID zu entnehmen ist, oder aber USD, CHF, usw.).
5.2. Date, DailyTime, Timestamp, DayMonth
Attribute dieses Typs enthalten eine Datumsangabe (Date; Darstellung JJJJMMTT), eine Uhrzeit (DailyTime; Darstellung HHMMSSss), sowohl Datum als auch Uhrzeit (Timestamp; Darstellung JJJJMMTTHHMMSSss) oder nur Monat und Tag (DayMonth; Darstellung MMTT).
5.3. Enumeration
Attribute dieses Typs enthalten einen Domainwert. «Enumeration» ist dabei nur Platzhalter für
alle im FIOM verwendeten Aufzählungstypen. Beispiele: QuotationType, PaymentFunctionType, …
Im Modell sind jeweils die konkreten Aufzählungstypen als Typ enthalten (z.B. QuotationType). Die Aufzählungstypen enthalten jeweils eine vorgegebene Anzahl von verfügbaren Domainwerten. Nur diese Domainwerte stehen für Attribute des entsprechenden Typs zur Auswahl.
5.4. Flag
Attribute dieses Typs enthalten einen Wert 1 für TRUE und einen Wert 0 für FALSE.
5.5. Number, Size
Attribute dieses Typs enthalten einen ganzzahligen Wert zwischen –32768 und +32767
(Number, 16 Bit) bzw. –2147483648 bund +2147483647 (Size, 32 Bit).
5.6. Amount, SignedValue, NormValue, Percentage
Attribute dieses Typs enthalten Fliesskommazahlen.
FOF / WMS
19/26
5.7. InstrumentKey, InstitutionKey, InstrumentServiceKey, GeographicUnitKey
Attribute dieses Typs enthalten die Identifikation eines fachlichen Objektes (Instrument = InstrumentID, Institution = InstitutionID, InstrumentService = InstrServiceID oder GeographicUnit = GeoUnitID).
Siehe hierzu auch Beschreibung "Currency"!.
5.8. Symbol, Name, Description
Attribute dieses Typs enthalten Texte. Symbol ist konzeptionell auf 30 Zeichen, Name auf 256
und Description auf 2000 Zeichen limitiert (Implementation kann hinsichtlich der Textlängen
abweichen).
5.9. ShortName, LongName, ShortDescr, LongDescr
Attribute dieses Typs enthalten mehrsprachige Texte. Es sind die 5 Sprachen Deutsch, Englisch, Französich, Italienisch und Native vorgesehen. Die Textlänge ist pro Sprache auf 256
(ShortName, ShortDescr) bzw. 2000 (LongName, LongDescr) Zeichen limitiert (Implementation kann hinsichtlich der Textlängen abweichen).
20/26
FOF / WMS
6. Datenbereitstellung
6.1. Initial Load und tägliche Update-Files
Die Daten werden im Format XML bereitgestellt. Die Datenbereitstellung erfolgt i.d.R. in
zwei Schritten:
A. Selektion einer Grundausstattung (Initial Load)
Gemäss Kundenvorgaben wird ein individuelles Datenprofil selektiert und via Datenträger ausgeliefert. Diese Grundausstattung stellt die Grundlage für die dann folgenden Tagesupdates dar.
B. Bereitstellung der täglichen Updates
Die täglichen Update-Files werden über ein Passwort-geschützten FTP-Account zur
Verfügung gestellt. Der Anwender entscheidet, wann er die Daten abruft.
6.2. Neartime Bereitstellung der Daten
Die Datenbereitstellung erfolgt neartime. D.h. die täglichen Datenfeeds werden untertägig in
mehreren Tageslieferungen. Die Frequenz der Datenbereitstellung kann individuelle konfiguriert werden. Es besteht somit die Möglichkeit entweder einmal am Tag einen Batchfile herunterzuladen oder mehrere Datenfeeds über den Tag verteilt in das System einzuspielen.
Um eine eindeutige Zuordnung aller gelieferten Q-Files zu gewährleisten, werden sie mit folgender Namenskonvention ausgeliefert:
WMJJJJMMTTXXXXX
WM
konstanter String WM
JJJJ
Jahr, vierstellig
MM
Monat, 01 – 12
TT
Tag, 01 – 31
XXXXX
fortlaufende Nummer, 5-stellig, mit führenden Nullen
Alle zu einer Lieferung gehörenden Q-Files werden in einer Tar-Datei zusammengefasst. Diese wird anschließend mit GNU-Zip komprimiert.
6.3. Mehrsprachigkeit
Die Daten werden in deutscher und nach Möglichkeit auch in englischer Sprache bereitgestellt.
FOF / WMS
21/26
7. Konzepte und wichtige Mechanismen
7.1. Top Level Object
Als «Top Level Object» werden alle Objekte im FIOM bezeichnet, die eine separat lebensfähige Informationseinheit darstellen. Dazu gehören Instrumente, Institutionen, InstrumentServices und Referenzdaten. Dazu gehören nicht Teilobjekte wie Stückelungen (Denomination),
Zahlungen (CFDefinition, Payment, …), Adressen (InstitutionAddress) etc. Teilobjekte sind
nur im Kontext ihres jeweiligen Top Level Objektes sinnvoll. Eine bestimmte Dividende gehört z.B. fest zu einem zugehörigen Instrument und kann ohne es nicht existieren. Im FIOM
sind Top Level Objekte dadurch gekennzeichnet, dass sie von der Klasse TopLevelObject abgeleitet sind.
TopLevelObject
Instrument
Institution
InstrumentGroup
0..1
vdpsInformation
InstrumentService
Industry
VDPSInformation
InstrumentSet
...
Abbildung 3: TopLevelObject und seine Unterklassen
In der Klasse TopLevelObject sind all diejenigen Eigenschaften modelliert, die alle Top Level
Objekte gemeinsam haben. Dies beinhaltet insbesondere die Klasse VDPSInformation, die
hauptsächlich technische Zusatzinformation zum fachlichen Top Level Objekt beinhaltet, z.B.:
•
•
•
•
•
•
22/26
Informationen, wer das Objekt wann erzeugt bzw. zuletzt abgeändert hat (createUserID, updateUserID, createTimestamop, updateTimestamp)
Interne
Verarbeitungsinformation
(historyID,
revisionNo,
messageInfo,
hasFutureMessages, …)
Informationen zur Typisierung des fachlichen Objektes, wie der fachliche Objekttyp
(foType, z.B. CommonStock, PreferredStock, StraightBond, …), der verwendete Verfahrensstandard zur Prüfung (vstName, vstVersion), etc.
Relevanzflag und Steuerungsinformation für die Steuerung der Prüfung (isRelevant,
fotWizardIsDisabled, isFastInsertion, isChecked, blockingCodeType)
Den bei der Prüfung erreichten Qualitätslevel (vstQuality, newVstQuality, vstMaximumQuality, vstRequiredQuality).
Möglichkeit zur Abspeicherung «generischer» Zusatzinformation (Beziehung genericInformation).
FOF / WMS
Neben der Beziehung zu VDPSInformation sind zu TopLevelObject noch weitere Beziehungen vorhanden, die zur Darstellung von Prüfergebnissen benötigt werden (Klassen CheckingResult, CheckingResultLimits), bzw. die im Fall von Pendenzen Verwendung finden
(Beziehungen pendingChange und pendingActivity).
7.2. Referenzdaten
Referenzdaten unterscheiden sich von anderen fachlichen Objekten dadurch, dass sie weitgehend statisch sind und sich daher fast nie ändern. Das FIOM kennt folgende Referenzdatenklassen:
Referenzdaten sind im FIOM im Prinzip vollwertige TopLevel-Objekte wie Instrumente und
Institutionen. Sie interessieren jedoch aus fachlicher Sicht selten als solche. Interessant ist
meist nur die Zuordnung von Referenzdaten zu anderen fachlichen Objekten (Instrumenten,
Institutionen, InstrumentService etc.).
Beispiele:
Durch die Referenzierung von Industry-Objekten wird die Branche von Institutionen festgelegt. Das Domizil einer Instituion wird über eine Beziehung zu einem LocationReferenzdatenobjekt bestimmt. Über die Zuweisung von InstrumentGroup-Objekten kann eine
Klassifizierung von Instrumenten nach verschiedensten Gesichtspunkten vorgenommen werden.
Die Referenzdaten haben in etwa den Character von Codes, die einem fachlichen Objekt zugewiesen werden können, z.B. Branchencode «Chemieindustrie» für Roche entspricht der
Zuweisung des entsprechenden Industry Objektes «Chemieindustrie». In den Referenzdaten
selbst sind Beschreibungen und Zusatzinformation zu dem «Code» enthalten. Gegenüber einfachen Codes haben Referenzdaten folgende abweichende Eigenschaften:
Codes sind «flach», d.h. es ist keine Verknüpfung zwischen verschiedenen Codes möglich.
Bei Referenzdaten können dagegen beliebige Strukturen realisiert werden. Beispiel dafür sind
die InstrumentGroup Objekte: Dort besteht über InstrumentGroupStructure die Möglichkeit,
ganze Strukturierungsgeflechte zwischen verschiedenen Gruppen zu definieren.
Codes haben vordefinierte, einheitliche Zusatzinformation (im Wesentlichen Code, idSymbol). Referenzdaten haben dagegen massgeschneiderte Dateninhalte, die weit über einen Code
und eine Beschreibung hinausgehen können. Beispiel: Die Referenzdatenklasse BorrowingLimitation, die Beleihungshöhen für Lombardkredite darstellt, kann eine ganze Liste von
Belehnungsgrenzen mit entsprechenden Gültigkeitsperioden beinhalten.
Referenzdaten können über die Zuweisung von Schemata eine Vielzahl von unterschiedlichen
Aspekten beleuchten. Beispielsweise kann bei Ratings über das Schema zwischen Moody´s
Ratings, S&P Ratings, long term / short term ratings etc. ausgewählt werden.
Referenzdaten sind flexibler erweiterbar als Codes. Codes sind im FIOM quasi als Modellbestandteil anzusehen während Referenzdaten Datencharakter haben. Daten können leichter erweitert werden, als das Modell.
FOF / WMS
23/26
7.3. Typisierung (Classification)
Das Datenmodell soll es ermöglichen, alle Wertpapiergeschäfte umfassend maschinell abzuwickeln. Dadurch wurde das gesamte Datenmodell mit dem Konzept der Typ-Darstellung die
Art und das Wesen beschrieben.
Das gesamte Modell besteht aus den Typisierungsebenen. Das beinhaltet schon bei der Einteilung der Finanzinstrumente in ihre fachlichen Bereiche Typisierungen, die sogenannten Finanzobjecttypen (den FOType). Sollten Tabellenklassen die Definition von typisierten Aussagen ermöglichen, so wählt man eine "Type"-Klasse als Referenzdatenklasse, wie nachfolgend
erläutert.
7.4. Identifikationen
Durch ein Identifikationssymbol mit dem entsprechenden Schematasymbol gekoppelt identifizieren sich im Datenmodell die unterschiedlichsten Klassen und trennen so sachliche Sichtweisen.
7.5. Technische Klassen (inkl. Reference Data Owner)
Im FIOM sind einige technische Klassen enthalten, die aus fachlicher Sicht keine Bedeutung
haben. Sie werden nur für die interne Verarbeitung in VDPS / WMS benötigt. Auf eine vollständige Erklärung der technischen Klassen wird an dieser Stelle deshalb verzichtet. Einige
der technischen Klassen haben aber auch für fachliche Benutzer des FIOM Bedeutung und
werden daher genauer dargestellt:
FIOMObject
Die providerIDs in der Oberklasse FIOMObjekt werden von allen FIOM-Objekten geerbt. Sie
werden zur Identifikation der «richtigen» Teilobjekte innerhalb eines fachlichen Objektes benötigt. Beispiel: Ein Instrument hat 354 Cashflows. Über eine Feedmeldung soll einer der 354
Cashflows verändert werden. Um dies erreichen zu können, muss der zu ändernde CashFlow
in der Feedmeldung eindeutig identifiziert werden. Die providerIDs enthalten die dafür notwendigen Identifikationen.
ReferenceDataOwner
Referenzdaten können allgemeine Gültigkeit haben (z.B. sind Ratings von Moody’s fest vorgegeben) oder providerspezifisch sein (z.B. Branchenzuordnung). Um diese Unterscheidung
im FIOM darstellen zu können, wurde die Referenzdatenklasse ReferenceDataOwner eingeführt. Damit können ReferenceDataOwner-Objekte definiert werden, mit Hilfe derer andere
Referenzdaten einem Provider zugeordnet werden können. Diese Möglichkeit ist allerdings
auf solche Referenzdaten beschränkt, bei denen ein Schema angegeben werden kann. Jede
Schema-Klasse (InstrumentIDScheme, RatingScheme, InstrumentGroupScheme, etc.) hat einen Verweis auf ReferenceDataOwner.
24/26
FOF / WMS
Beispiel:
Wenn das InstrumentGroupScheme «XYZ» einen Verweis auf das ReferenceDataOwner Objekt «A» hat, sind alle Gruppen des Schemas «XYZ» spezifisch für den Provider «A».
Über die ReferenceDataOwner-Zuordnung kann nicht nur festgehalten werden, wenn Referenzdaten providerspezifisch sind, sondern es können z.B. auch mandantenspezifische Referenzdaten angelegt werden.
7.6. 'Unbundling'
Jedes Finanzinstrument kann in seine „Bausteine“ zerlegt werden und wird daher als Unbundling bezeichnet. Die Bündelung der Bausteine erfolgt im FIOM auf drei Ebenen.
Auf der ersten Unbundling-Ebene stehen die Finanzinstrumente. Auf dieser Stufe können zusammengesetzte Finanzinstrumente, wie z.B. Optionsanleihen, in ihre Bestandteile zerlegt
werden.
Auf der zweiten Unbundling-Ebene werden die einzelnen Ansprüche identifiziert, zu denen
Finanzinstrumente berechtigen. Unter dem Begriff Anspruch werden im FIOM alle Arten von
Zahlungen und Übertragungen von Finanzinstrumenten verstanden.
Während das ausbezahlte Finanzinstrument sowie Termine oder Fristen in der Regel eindeutig
angegeben werden können, ist die Höhe von Zahlungen bzw. Ansprüchen häufig nicht als fixe
Zahl, sondern nur durch komplexere Regeln bzw. durch eine Payoff-Funktion zu beschreiben.
Auf der dritten Unbundling-Ebene wird die Höhe des Anspruchs mittels einer kleinen Anzahl
von additiven Payoff-Funktionen beschrieben. Eine Payoff-Funktion beschreibt erstens die
Höhe einer Zahlung und kann zweitens in Abhängigkeit vom Unter- oder Überschreiten eines
bestimmten Schwellenwerts sein. Eine Sonderform nehmen Naturalzahlungen ein. Um die
verschiedenen Zahlungsmuster abzubilden, werden im FIOM fünf verschiedene Zahlungstypen definiert. Sie bilden die feinsten Bausteine des Unbundling-Ansatzes. Sie können wie
folgt charakterisiert werden:
Fixe Beträge: Solche stehen zum Zeitpunkt der Emission fest. Zu diesen Zahlungen gehören
alle festen Zinszahlungen sowie alle ordentlichen Rückzahlungen von Anleihen.
Latente Beträge: Solche Beträge werden nicht zum Zeitpunkt der Emission, sondern erst zu
einem späteren Zeitpunkt festgelegt. Typischer Vertreter dieser Art Beträge ist die Dividende
einer Aktie.
Linear abhängige Beträge: Der Betrag hängt vom Preis einer Bezugsgröße ab. Typische Beispiele sind variable Zinszahlungen in Abhängigkeit von einem Referenzzinssatz (z.B.LIBOR).
Optionsartige Beträge: Der Wert des Anspruchs hängt linear von einer Bezugsgröße ab unter
der Bedingung, dass ein Schwellenwert über- oder unterschritten wird. Charakteristisch ist der
Break-Even in der Payoff-Funktion: Bis zu einem bestimmten Wert eines Underlyings sind sie
wertlos, darüber oder darunter steigt ihr Wert mit dem Wert des zugrunde liegenden Basisinstruments. Diese Form der Zahlung ist typisch für fast alle derivativen Finanzinstrumente.
Naturalzahlungen: Bei diesen Ausschüttungen können nur Gegenwerte angegeben werden; sie
werden wie fixe oder latente Zahlungen behandelt. Sie kommen als Fluggutscheine oder Tageskarten für Skilifte vor und ersetzen in der Regel eine Dividende ganz oder zum Teil.
FOF / WMS
25/26
Durch Kombination dieser Payoff-Funktionen lassen sich alle stückweise linearen PayoffStrukturen abbilden. Die einzelnen Payoff-Funktionen zur Bestimmung der Zahlungsbeträge
werden mit der Klasse Payment und dessen abgeleiteten Subklassen abgebildet.
Ansprüche können auch auf der Stufe Cashflow weiter kombiniert werden, wenn sie entweder
nur zusammen oder nur alternativ geltend gemacht werden können. Nur zusammen geltend zu
machende Ansprüche kommen dann vor, wenn gleichzeitig unterschiedliche Finanzinstrumente gezahlt werden, so dass sich der gesamte Cashflow nicht als Zusammensetzung einzelner
Payments ergibt. Bei alternativen Cashflows ist jeder einzelne beliebig komplex aus Payments
zusammengesetzt. Da aber nur der eine oder andere geltend gemacht werden kann, müssen sie
separat erfasst und der Zusammenhang als darüberliegende Struktur festgehalten werden.
Abbildung 4: Das Wertpapier Managementsystem (WMS) mit Zusatztools
26/26
FOF / WMS

Kurz-Handbuch

Transcription

Similar documents

Anleihe - Stendal

Professionelles E-Banking – effizient und verlässlich

druckerfreundliches Hochformat - guenther

sedo.nl

Datenmanagement,ggplot2 - Technische Universität Kaiserslautern

Einführung inR - Technische Universität Kaiserslautern

Formelsammlung zur Tilgungsrechnung

2015 Annual Report