Vorschlag: Exposure-Ansicht und erweiterte Unterstützung für Derivate

Deutsch Auswertungen
1

Vorschlag: Exposure-Ansicht und erweiterte Unterstützung für Derivate

Ich nutze PortfolioPerformance inzwischen auch für Portfolios, in denen neben Aktien, Anleihen und Fonds zunehmend Derivate eingesetzt werden. Dabei ist mir insbesondere eine Information aufgefallen, die mir für die Beurteilung eines Portfolios fehlt: das tatsächliche Exposure der einzelnen Positionen und des Gesamtportfolios.

Bei klassischen Wertpapieren liegen Marktwert und wirtschaftliches Exposure häufig relativ nah beieinander. Bei Derivaten ist das dagegen nicht der Fall. Ein Future, eine Option oder ein Knock-out-Zertifikat kann beispielsweise nur einen vergleichsweise kleinen Marktwert haben, gleichzeitig aber ein wesentlich größeres Exposure gegenüber einem Basiswert erzeugen.

Aus diesem ursprünglichen Wunsch nach einer Exposure-Ansicht ist bei mir daher ein etwas umfassenderer Proof of Concept zur Abbildung von Derivaten in PortfolioPerformance entstanden.

1. Exposure als zusätzliche Portfoliosicht

Neben Marktwerten könnten Positionen zusätzlich nach ihrem Exposure ausgewertet werden.

Sinnvoll erscheinen insbesondere zwei Größen:

  • Nominal Exposure – Exposure ohne Deltaanpassung
  • Delta-adjusted Exposure – insbesondere für Optionen

Damit können Long- und Short-Exposures getrennt dargestellt sowie Brutto- und Nettoexposures eines Portfolios ermittelt werden.

Im aktuellen Proof of Concept gibt es dafür eine eigene Ansicht unter Berichte → Vermögensaufstellung → Exposuremanagement.

Dort können unter anderem betrachtet werden:

  • Exposure nach Basiswert
  • Exposure nach Trading Symbol
  • Exposure nach Fälligkeit
  • Long-/Short-Aufteilung
  • Gross Exposure
  • Net Exposure
  • Nominal vs. Delta-adjusted Exposure
  • zeitliche Entwicklung des Exposures

Gerade bei Portfolios mit Optionen, Futures oder gehebelten Produkten halte ich diese zweite Sicht neben dem reinen Marktwert für hilfreich.

2. Derivate-spezifische Stammdaten

Damit diese Berechnungen möglich sind, habe ich die Wertpapierstammdaten optional um Derivateinformationen erweitert.

Für Optionen beispielsweise:

  • Put / Call
  • Strike
  • Expiration Date
  • Exercise Style
  • Multiplikator
  • Delta
  • Basiswert / Underlying

Für Futures beispielsweise:

  • Contract Month
  • First Trading Day
  • Last Trading Day
  • Multiplikator
  • Basiswert / Underlying
  • Settlement-Art

Die zusätzlichen Informationen sind nur relevant, wenn das Wertpapier als entsprechender Derivatetyp verwendet wird.

3. Knock-out-Zertifikate

Zusätzlich habe ich Knock-out-Produkte berücksichtigt.

Dafür stehen unter anderem folgende Informationen zur Verfügung:

  • Initiales K.O.-Level
  • aktuelles K.O.-Level
  • Bezugsverhältnis
  • Emittent
  • Emittenten-Produkt-ID
  • Exposure Currency

Gerade bei Open-End-Knock-outs ist das aktuelle K.O.-Level keine statische Eigenschaft und kann deshalb separat gepflegt werden.

Für bestimmte Vontobel-Produkte existiert im Proof of Concept außerdem bereits ein automatischer Stammdatenabruf.

4. Marktwert und Exposure sind unterschiedliche Größen

Ein wichtiger Punkt der Umsetzung ist die Trennung zwischen Marktwert und Exposure.

Bei Optionen ist der Marktwert beispielsweise typischerweise:

Marktwert = Anzahl × Optionspreis × Multiplikator × FX

Das wirtschaftliche Exposure ergibt sich dagegen aus dem Basiswert und – beim delta-adjusted Exposure – zusätzlich aus dem Delta.

Bei Futures wiederum ist als Marktwert der Position insbesondere die offene bzw. unrealisierte P&L relevant, während der Nominalwert des Kontrakts für die Exposure-Betrachtung herangezogen werden kann.

Damit beantwortet PortfolioPerformance zwei unterschiedliche Fragen:

„Was ist meine Position heute wert?“

und zusätzlich:

„Welche Marktposition steckt wirtschaftlich dahinter?“

5. Import und automatische Erkennung

Ein weiterer Teil des Proof of Concept ist die automatische Erkennung bestimmter Optionssymbole.

US-Optionssymbole wie beispielsweise

IAG260918C00017000

enthalten bereits Informationen über:

  • Basiswert
  • Fälligkeit
  • Put/Call
  • Strike

Diese Informationen können automatisch in die Derivate-Stammdaten übernommen werden.

Zusätzlich habe ich die Erkennung bestimmter Interactive-Brokers-/Eurex-Symbole ergänzt, beispielsweise:

CSIE20260821305M

Ziel des Vorschlags

Mir geht es ausdrücklich nicht darum, PortfolioPerformance zu einem vollständigen Derivate- oder Risikomanagementsystem auszubauen.

Der wesentliche Nutzen wäre aus meiner Sicht vielmehr, dass PortfolioPerformance bei einem Portfolio mit Derivaten zusätzlich beantworten kann:

„Welchem Markt bin ich in welcher Größenordnung tatsächlich ausgesetzt?“

Die bestehende Vermögensaufstellung beantwortet sehr gut:

„Was ist mein Portfolio heute wert?“

Eine Exposure-Sicht ergänzt diese um die wirtschaftliche Perspektive.

Proof of Concept / GitHub

Ich habe hierzu bereits einen funktionierenden Proof of Concept auf Basis von PortfolioPerformance umgesetzt.

Der derzeitige Referenzstand ist:

  • PortfolioPerformance-Basis: 0.87.0
  • Feature Build: #84
  • Status: success
  • Commit: 6dd92ff372feab24302442006e641a7acaf9a15e

Build #84:

Referenz-Commit:

Stabiler Snapshot des Proof of Concept:

Aktueller Entwicklungsbranch:

Die Implementierung soll ausdrücklich nicht als fertiger Pull Request verstanden werden, sondern als technische Referenz und Diskussionsgrundlage. Datenmodell, UI und Berechnungslogik können selbstverständlich an die Architektur und Konventionen des PortfolioPerformance-Projekts angepasst werden.

Kleine Testdatei

Für einen möglichst einfachen Test habe ich zusätzlich eine kleine synthetische PortfolioPerformance-XML-Datei erstellt.

Sie enthält ausschließlich Demonstrationsdaten, unter anderem:

  • 3 Aktien
  • mehrere zugehörige Underlyings
  • 3 klassische Optionen
  • 3 Knock-out-Zertifikate
  • Beispielpositionen zur Darstellung der Exposure-Berechnung

Die Datei enthält keine persönlichen Portfolio- oder Kontodaten.

Testdatei:

Damit sollten sich Stammdaten, Marktwertberechnung und Exposure-Ansicht mit dem oben genannten Build relativ schnell nachvollziehen lassen.

Ich würde mich über Feedback insbesondere dazu freuen, ob eine solche Exposure-Sicht grundsätzlich als sinnvolle Ergänzung für PortfolioPerformance angesehen wird und welche Teile davon aus Sicht des Projekts interessant wären.

2

Hallo @Sven_X,

Vielen Dank für den Post.

Zunächst finde ich die Idee gut auch den Aspekt “Exposure” zu betrachten. Wenn man Exposure etwas weiter als Derivate fasst, dann fängt das damit an, die Wertpapiere in dem ETF zu kennen. Ich denke nicht vielen ist klar wie groß Ihre Exposure zu Nvidia ist… Heute kann man das über Klassifikationen lösen - und per Skript die Daten füttern (siehe z.B. Automatic import of classifications - #360 by Alfons1Qvor12) - aber da gibt es noch Verbesserungspotential. Dazu kommt die Frage woher man die Daten für die ETFs bekommt.

Bezüglich der Derivate: Ich bin gespannt welche weiteren Rückmeldungen es dazu hier im Forum geben wird.

Was ich aber sehe ist, dass es echt nicht einfach ist das Datenmodell von PP selber zu erweitern. Mit den Coding Agents wird es einfacher Code zu schreiben, aber (noch) nicht zu reviewen oder in die Zukunft zu betreuen und aktuell zu halten. PP hat nie ein erweiterteres API bekommen mit dem man Erweiterungen schreiben könnte ohne direkt am Kernmodell Änderungen vorzunehmen. Dann könnte man Ergänzungen zur den Derivaten so vornehmen (und Delta ist ja nicht das Ende - Gamma, Vega, Theta …).

Weil Du jetzt die Erweiterung ausprobiert hast - schreib mir doch mal eine Email welches API Du bräuchtest um eine solche Ergänzung zu bauen.

3

Hallo Andreas,

vielen Dank für den Austausch neulich. Der Vorschlag, die Derivatefunktionen möglicherweise als optionale Erweiterung umzusetzen erscheint mir auch sinnvoll. Insbesondere weil sich die Weiterentwicklung, Wartung und Fehlerbehebung dann weitgehend vom Portfolio-Performance-Kern trennen ließen.

Ich fasse mal mein Verständnis zusammen:

Nach den bisherigen Anpassungen würde ich zwischen wenigen allgemeinen Änderungen an der Kernanwendung und der eigentlichen Derivate-Erweiterung unterscheiden.

Aus meiner Sicht sollten folgende Punkte in die Kernanwendung übernommen werden:

  1. Multiplikator

Der Multiplikator sollte als allgemeines Feld eines Wertpapiers beziehungsweise Finanzinstruments in das Datenmodell von Portfolio Performance aufgenommen werden. Er ist zwar insbesondere für Optionen und Futures erforderlich, kann aber perspektivisch auch für Anleihen, Zertifikate oder andere Instrumente relevant sein.

Zusätzlich sollte der bei einer Buchung verwendete Multiplikator in der Transaktion gespeichert werden. Dadurch bleibt eine historische Buchung auch dann unverändert nachvollziehbar, wenn der Multiplikator später in den Stammdaten geändert wird.

Der Standardwert sollte 1 sein. Damit bliebe das Verhalten für bestehende Wertpapiere und Dateien unverändert.

  1. Order- beziehungsweise Buchungsmaske

Die Ordermaske sollte ebenfalls in der Kernanwendung um den Multiplikator ergänzt werden. Beim Anlegen einer Buchung würde das Feld mit dem Multiplikator aus den Wertpapierstammdaten vorbelegt, könnte für die konkrete Transaktion aber angepasst werden.

Die Berechnung des Buchungswerts wäre dann grundsätzlich:

Stückzahl × Kurs × Multiplikator

Auch dies wäre keine ausschließlich derivatespezifische Änderung, sondern eine allgemeine Erweiterung der Transaktionslogik.

Die übrigen Funktionen könnten meines Erachtens weitgehend in ein optionales Derivate-Add-on ausgelagert werden. Dazu gehören insbesondere:

  • zusätzliche Stammdaten wie Produkttyp, Put/Call, Strike, Delta, Underlying, Ausübungsart sowie Fälligkeits- und Settlementinformationen,
  • die spezielle Marktwertberechnung für Optionen, Futures und KO-Zertifikate,
  • die Berechnung von nominalem und deltaadjustiertem Exposure,
  • die Exposuremanagement-Berichte und Diagramme,
  • das Mapping von US- und EUREX-Optionssymbolen,
  • Stammdatenprovider für Emittenten wie Vontobel,
  • derivatespezifische CSV-Importfelder und Plausibilitätsprüfungen.

Für diese Auslagerung bräuchte das Add-on dann allerdings geeignete Schnittstellen der Kernanwendung. Über die Punkte bin ich aktuell am nachdenken. Ich kann momentan noch nicht abschließend beurteilen, welche Erweiterungspunkte Portfolio Performance bereits anbietet und welche neu geschaffen werden müssten.

Nach meinem bisherigen Verständnis wären vor allem Schnittstellen für folgende Bereiche erforderlich:

  • zusätzliche Bereiche und Felder im Wertpapiereditor,
  • zusätzliche Berichtsansichten,
  • alternative Marktwert- und Exposureberechnungen für bestimmte Instrumente,
  • zusätzliche Stammdatenprovider und Symbol-Resolver,
  • zusätzliche CSV-Importfelder,
  • Benachrichtigungen bei Änderungen von Kursen, Transaktionen und Stammdaten,
  • persistente Speicherung optionaler Add-on-Daten in der Portfolio-Performance-Datei.

Wichtig wäre dabei, dass eine Datei auch ohne installiertes Add-on weiterhin geöffnet und gespeichert werden kann, ohne dass die zusätzlichen Derivatedaten verloren gehen.

Auf Basis dieser Überlegungen erscheint mir folgendes Vorgehen sinnvoll:

  1. Multiplikator und dessen Verwendung in der Ordermaske als allgemeine Erweiterung der Kernanwendung aufsetzen.
  2. Die übrigen Änderungen des bisherigen Forks danach einteilen, ob sie bereits über bestehende Schnittstellen ausgelagert werden können oder einen zusätzlichen Extension Point benötigen.
  3. einen weiteren kleinen Proof of Concept erstellen, beispielsweise mit der Exposuremanagement-Ansicht als eigenständigem Add-on.
  4. Anschließend Stammdatenfelder, Provider und Berechnungslogik schrittweise aus dem Fork in das Add-on überführen.

Ich spiele die Tage mal ein bischen mit meinem Code rum, mal sehen was geht und was nicht…

Viele Grüße und ein schönes WE

Sven

4

Ich kann momentan noch nicht abschließend beurteilen, welche Erweiterungspunkte Portfolio Performance bereits anbietet und welche neu geschaffen werden müssten.

Sagen wir mal so: es gibt nur ganz wenige - z.B. könnte man über die Service Locator weitere Kurslieferanten einbinden - aber das hilft auch nur bedingt, weil der Konfigurationsdialog das nur eingeschränkt unterstützt.

Aber, und das gute, Eclipse kennt all diese Konzepte. Die ganze Eclipse IDE besteht aus Plugins (oder Add-ons), die Erweiterungen anbieten. Man müsste also zum Beispiel einen extension Type “Report View” definieren. Den kann dann ein weiteres Plug-in anbieten. Wenn ich das sehen, bräuchte man mindestens mal: Berichte beitragen, Spalten zu Tabellen beitragen, Reiter im Wertpapier-Editor beitragen, Daten in den Wertpapierstammdaten speichern. Vor allem aber bräuchte man einen Mechanismus wie man das Add-on in seine Installation bekommt (und ggf. auch wieder rausbekommt). Alles nicht trivial.

Es ist sicherlich so dass PP die letzten 15 Jahre nicht für diesen Fall entwickelt wurde. Insofern müsste man überlegen wo man eine Schnittstelle einfügt und wo nicht. Ich glaube, es wird schwierig App und Add-on komplett unabhängig zu entwickeln - da gibt es zu viele APIs die ich gar nicht stabil halten kann - aber separat installieren und aktualisieren ist eine andere Nummer.

Der Multiplikator sollte als allgemeines Feld eines Wertpapiers beziehungsweise Finanzinstruments in das Datenmodell von Portfolio Performance aufgenommen werden.

Hier brauche ich glaube ich noch mehr Argumente. Ich denke der multiplier kann Sinn machen für bestimmte Instrumente (Optionen, Future, …) aber bei Anleihen weiß ich nicht ob das nicht etwas überlädt. Leider kann ich aktuell keinen Instrument-Typ unterscheiden. Aber das an alle Instrumente dranhängen, ist auch eine große Sache. Zumindest müsste man es unsichtbar machen können. Die zweite Frage ist, ob das an der einzelnen Buchung hängen muss. Ist das nicht eher ein “contract multiplier”. Oder aber wenn es an der Buchung hängt, warum dann noch mal am Instrument?

Warum kann der Multiplier nicht im Add-on “leben”? Sprich: einen Extension-point im Stammdaten-Modell haben und dann einen extension Point im Editor haben (der dann erlaubt die Daten zu editieren).

5

Hallo Andreas,

sorry ich war ein bischen Land unter die letzten Tage.

fyi, ich spiele diese Woche mal ein bischen rum um ein Add-on zu erzeugen. Mal sehen was dabei heraus kommt…

viele Grüße

Sven

6

@Sven_X
Vielleicht hilft dir GitHub - MelleD/portfolio-performance-vorabpauschale · GitHub, wie unabhängige Plugin’s in PP integriert werden können.

7

sieht ganz vielversprechend aus soweit, ich brauche aber noch ein paar Tage, da ich am Wochenende unterwegs bin. I keep you updated…

8

Ich habe noch ein ZIP file mit einem kleinen Video zur Erklärung hochgeladen Release Derivatives & Exposure Management PoC – Bridge 19 / Build 111 · tauchersven1/portfolio · GitHub Das Orginial Video ist etwa 4:30 lang und >640MB, daher musste ich das komprimieren

9

Hallo zusammen,

wie angekündigt habe ich den Proof of Concept weitergeführt und dabei versucht zwei Dinge getrennt zu betrachten:

  1. einen vollständigen, integrierten Referenzstand, mit dem sich die fachlichen Funktionen testen lassen;
  2. einen separaten Add-on-Prototyp, mit dem sich die notwendigen Extension Points untersuchen lassen.

Der aktuelle Downloadstand ist ausschließlich Bridge 19 / Feature Build 111 auf Basis von Portfolio Performance 0.87.0. Das Windows-ZIP enthält den vollständigen, bis Build 111 entwickelten integrierten Funktionsstand.

Build 111 enthält insbesondere:

  • Derivate-Stammdaten für Optionen, Futures und KO-Zertifikate direkt am Wertpapier;
  • datumsabhängige Reihen für Multiplikator, Delta und KO-Level;
  • Berücksichtigung des Multiplikators in Transaktionen, Bewertungen und historischen Berechnungen;
  • Symbolerkennung für OCC-/US-Optionen sowie ausgewählte IB-/Eurex-Symbole;
  • Exposure Management mit Marktwert, Nominal und delta-adjustiertem Exposure;
  • Gross-, Net-, Long- und Short-Exposure sowie Gruppierungen nach Underlying, Handelssymbol und Fälligkeit;
  • Exposure-Spalten in der Vermögensaufstellung und ergänzende Diagramme;
  • KO- und FX-Exposure sowie einen ersten Vontobel-Stammdatenprovider;
  • eine synthetische Demo-Datei für die wesentlichen Testfälle.

Neu beziehungsweise zuletzt ergänzt wurde die Gruppierung nach dem Basiswert-Symbol: Eine Microsoft-Aktie mit dem Symbol MSFT und die Option MSFT260918C00490000 werden in Exposure by Trading Symbol nun gemeinsam unter MSFT dargestellt. Dafür wird zunächst ein explizit verknüpfter Basiswert verwendet; ersatzweise wird bei erkennbaren Optionssymbolen das Underlying aus dem Kontraktsymbol abgeleitet.

Parallel dazu habe ich einen eigenständigen Eclipse/OSGi-Add-on-Prototyp gebaut. Dieser wird als separates Feature mit eigener p2 Update Site erzeugt und trägt Exposure-Berichte über einen kleinen Navigation Extension Point bei. Dadurch muss das Add-on nicht auf interne Klassen der Navigation zugreifen.

Der Add-on-Prototyp zeigt derzeit insbesondere:

  • Registrierung eigener Berichtsansichten über name.abuchen.portfolio.ui.navigation;
  • einen kleinen öffentlichen View-Vertrag (AddonView und AddonViewContext);
  • eine vom Add-on besessene Exposure-Ansicht;
  • separate Paketierung als OSGi-Feature und Update Site.

Wichtig ist die Abgrenzung: Der separat paketierte Add-on-Prototyp hat noch nicht den Funktionsumfang des integrierten Build 111. Der vollständige Referenzstand enthält weiterhin Core-Anpassungen für Datenmodell, Persistenz, derivatespezifische Bewertung, Wertpapiereditor, Transaktionen, Imports und Exposure-Berechnung.

Aus der bisherigen Arbeit ergeben sich aus meiner Sicht folgende sinnvolle Extension Points für Portfolio Performance:

  • Berichtsansichten und Navigation;
  • zusätzliche Reiter beziehungsweise Bereiche im Wertpapiereditor;
  • zusätzliche Spalten in vorhandenen Tabellen;
  • Bewertungs- und Exposure-Strategien für bestimmte Instrumente;
  • Stammdatenprovider und Symbol-Resolver;
  • CSV-Felder und Validierungen;
  • Modelländerungsereignisse;
  • persistente Add-on-Daten, die auch ohne installiertes Add-on verlustfrei erhalten bleiben.

Der aktuelle Stand bestätigt damit beide Seiten der bisherigen Diskussion: Die fachliche Exposure-Funktion lässt sich umsetzen, aber eine saubere Trennung vom Kern benötigt einige bewusst definierte, möglichst kleine Schnittstellen. Eine vollständige Unabhängigkeit von App und Add-on halte ich ebenfalls nicht für realistisch; eine separate Installation und Aktualisierung bei klar versionierten Verträgen erscheint aber grundsätzlich machbar.

Für einen einfachen Test enthält die Veröffentlichung:

  • PortfolioPerformance-Bridge19-Windows-x86_64-Build111.zip mit gebündelter Java-Laufzeit;
  • Derivatives_AddIn_Demo.xml als synthetische Demo-Datei;
  • technische Dokumentation zu Core-Änderungen, Extension Points und Add-on-Prototyp;
  • eine SHA-256-Prüfsumme.

Die Demo-Datei enthält keine persönlichen Portfolio- oder Kontodaten.

Download und technische Dokumentation:

siehe auch:

Der Code ist ausdrücklich weiterhin ein Proof of Concept und kein fertiger Upstream-Pull-Request. Happy to discuss…

Viele Grüße

Sven