Roadmap und aktuelle Konzeptionen

• Themen-Voting durch User
• Systematisches Depot-Balancing
• Releasemanagement
• Major-Releases auf Jahresebene

Themen-Voting durch User

Nicht ohne Relevanz ist für Anwender die Zukunft des eingesetzten Programms. SHAREholder wird in meiner Freizeit vorangetrieben, aus Spaß und Experimentierfreude an der Entwicklung und an der Börse. Hintergrund bei der Arbeit ist immer die eigene persönliche Nutzung des Systems. Dies steht dabei aus meiner Sicht nicht im Widerspruch zur kostenpflichtigen Bereitstellung des Programmpaketes, da Änderungswünsche von Anwendern eingearbeitet, Support geleistet und eine Basisinfrastruktur für Website, Softwarelizenzen und Betrieb finanziert wird. Jede verkaufte Lizenz bestätigt mich dabei, indem was ich tue und motiviert mich weiter zu machen. Einen komplett idealistischen Ansatz fahre ich damit nicht.

Shareholder ist in der Entwicklung vollständig unabhängig von wirtschaftlichen Entwicklungen eines Geschäftsmodells/-betriebes, da es unter dem Motto "Hobby" läuft. Die Entwicklung ist damit allein abhängig von meiner Zeit für das Projekt. Diese besteht jedoch bereits ab 1999, so dass hier eine gewisse Kontinuität auch in der Zukunft vorausgesetzt werden kann.

Grundsätzliches Projektvorgehen

Als Grundvorgehensmodell nutze ich ein SCRUM-Verfahren mittels JIRA. Dabei werden Stories in einem Themenspeicher (Backlog) organisiert und regelmäßig priorisiert. Die Release-Zyklen sind auf mind. einem wichtigen Release pro Monat geplant, wobei Bug-Fixes, auch auf Tagesbasis jederzeit verfügbar gemacht werden können.

Folgende Links können Sie zudem für die Orientierung nutzen:

• Der aktuellen laufenden und geplanten Sprints 

Priorisierungen

Die Weiterentwicklung wird grundsätzlich durch Anwender-Stories bestimmt, d.h. Anfragen, die zu SHAREholder gestellt worden sind. Die hierfür möglichen Klassifizierungen sind immer "Bug" oder "Verbesserung". Die Stories werden in Releases geplant, die so transparent planbar sind. Sie haben in SHAREholder unter Updates / Voting die Möglichkeit für die zukünftig geplanten Aktivitäten Ihre Stimme abzugeben. Bitte nutzen Sie gerne diese Möglichkeit, da dies für mich in der Priorisierung berücksichtigt wird.

Systematisches Depot-Balancing

Problem und Use-Case

Aktuell wird das Depot ohne die Möglichkeit auf spezifische Ausrichtungen von Ziel-Vektoren aufgebaut. Das Programm fehlt ein echtes variables Portfolio-Balancing. Das Portfolio muss gegen Wunsch-Ziel-Vektoren z.B. Branchen/Länder/Asset/Risiko/Nachhaltigskeit-Mix ausgerichtet werden können.

Dabei sind drei Hauptthemen zu adressieren:

• Ziel-Vektoren sind zu pflegen und zu priorisieren. Diese sollten dabei konkrete definierbare Ausprägungen erhalten, die dann nachfolgend in den Titel-Stammdaten spezifisch pro Titel belegt werden können. 
• Einzel-Titel-Stammdaten müssen die spezifischen Ausprägungen (manuell) hinterlegen können z.B. für den Branchen-Mix eines ETFs oder Fonds. Dabei wird nicht eine einfache 1:1 Zuordnung angestrebt, sondern pro Titel müssen die Anteile der Ausprägungen definiert werden können. Als Beispiel hat ein "DWS German Equities Typ O" einen Branchenmix wie dargestellt: 
  

  

  
  
  Die Pflege erfolgt dabei im ersten Schritt händisch später automatisiert, wenn möglich.
• Das Portfolio muss so visuell aufbereitet werden, dass eine Optimierung zwischen IST und SOLL-Ausrichtung unterstützt wird. In Ausbaustufen sollte auch der Positionsaufbau selbst in der Titelauswahl als auch in der Anzahl der Stücke für Kauf/Verkaufspositionen assistiert werden.
• Als Nutzer möchte ich Alarmschwellen nutzen können, die ein Rebalancing des Depots durch den Nutzer triggern sollten. Pro Ziel-Vektor sollten die Alarmschwellen individuell festgelegt werden können. Das Alerting sollte in der ersten Stufe primär visuell in der Anzeige erfolgen, wenn Schwellwerte bzw. die Soll-Ausrichtung inkl. Toleranzschwellen überschritten werden. Beispiele für Alerts könnten sein:
  
  • Zu wenig liquides Kapital
  • Zu hohe Gewichtung in % zu einer Branche 
• Das Balancing in der SOLL-Aufteilung kann sich verändern je nach Großwetterlage bzw. Konjunktur- und /oder Börsenphase. Im zweiten/dritten Schritt können daher die Soll-Werte nicht nur fest vom Nutzer hinterlegt werden, sondern systematisch durch Makro-Ökonomische Wertsetzungen beeinflusst werden. Auch die interne Marktanalyse kann hierfür genutzt werden.

Balancing-Vektoren

Die Vektoren beschreiben die Einfluss-Vektoren, die für die Ausrichtung eines Depots relevant sind. Die Vektoren verändern sich dabei über die Zeit und sind nicht lebenslang gültig für einen Anleger. Es hängt dabei z.B. von der eigenen Risiko-Neigung und dem Anlagehorizont und Lebenssituation ab, welche Vektoren welchen konkreten Zielwert erhalten. Wird beispielsweise die Assetklasse als Ausrichtungsvektor genommen kann z.B. 60% Aktien, 20% Immobilien und 20% Edelmetalle verwendet werden. Dieser Wert verschiebt sich aber über die Lebenszeit des Anlegers gewöhnlich in Richtung sicherer Assetklassen, da im Alter der Vermögenserhalt im Vordergrund steht.

Grundsätzlich kann jedes Attribut und jede Kennzahl eines Titels als Vektor genutzt werden. Dabei ist zwischen einem frei zu benennenden Vektor und einem Vektor mit einem eindeutigen Funktionsindex aus den Stammdaten zu unterscheiden. So können die Landeszuordnungen aus den bisherigen Stammdaten genutzt werden ohne erneut als  Vektor beschrieben werden zu müssen (=Funktionsindex). Ich kann aber beispielsweise die Risikogruppe als eigenen Vektor hinterlegen, der bisher nicht abgebildet wurde. Diese sollte aber dennoch erfassbar und genutzt werden können z.B. mit einem Rating-Ansatz 1..5 Sterne. Als Nutzer muss man damit die gewünschten zu nutzenden Vektoren selbst aufbauen, benennen und priorisieren können. Mindestvoraussetzung ist dabei, dass die Ausprägungen sich tatsächlich gruppieren lassen. Wenn jeder Titel einen eigenen Wert besitzt, ist dieser Vektor sinnlos. Ein Ziel-Vektor nach ISIN wäre ein derartiger unsinniger Fall.

Welche Vektoren sind beispielsweise sinnvoll:

Anforderungen für die Umsetzung

Auswahl und Auswertung der Balancing-Vektoren für das aktuelle Portfolio

Auswahl der Ziel-Vektoren

Die Vektoren sind vom Nutzer in einer gewünschten Reihenfolge in dem Reiter "Portfolio-Balancing" auszuwählen, so dass sich daraus die spätereren Hierarchien ableiten. Es können dabei 1 .. n der Vektoren ausgewählt werden. Die Vektoren wurden dabei zuvor durch den Nutzer selbst definiert (Name, Mögliche Ausprägungen, Soll-Werte).

Darstellung der Ziel-Vektoren in einer Hierarchie

Die Depotwerte werden nachfolgend entsprechend der Reihenfolge in einer Baumhierarchie dargestellt. Die Soll-Balancing-Spalte verfärbt sich dabei mit Farbcodes, je nachdem ob die Zielstruktur erreicht wurde. Bei orangen Werten wird der Zielwert überschritten oder unterschritten, bei grünen Werten liegt es zwischen Min und Max % Wert. Gelbe Werte könnten in einem Toleranzbereich von +-5% liegen.

Hier als angedeutete Mockup-Implementierung:

Wertermittlung für die IST-Wert-Betrachtung

Die IST/SOLL-Balancing-Werte orientieren sich dabei immer am aufsummierten aktuellen Wert-Volumen der Depot-Währung oder am Kaufvolumen in der Depot-Währung.

Die IST-Werte können damit schwanken mit dem tagesaktuellen Kurswert, wenn das Wert-Volumen genutzt wird. Dies würde aber auch dazu führen, dass gut laufende Titel im Balancing "rot" angezeigt werden, was die falsche Wirkung haben kann. Daher soll bewusst auch nur das Kaufvolumen genutzt werden können und somit das Balancing insb. bei Neukauf von Titel unterstützend wirken. Das RE-Balancing kann dann periodisch z.B. alle 6 Monate genutzt werden, um "Wert-Cluster" deutlich über der Norm wieder anzupassen oder abzugleichen. 

Justierung im Balancing

Beim Balancing kann auch bewusst der Einfluss von Faktoren angepasst werden d.h. nicht nur das Depot in Richtung der SOLL-Werte angepasst werden, sondern auch die SOLL-Werte auf Basis der aktuellen Depotentwicklung um insb. gut laufende Titel hier zu justieren.

Pflege der Balancing-Vektoren

Definition

Es werden Definitions-Masken benötigt, die festlegen welche Vektoren gewünscht sind und wie diese sich aus den Daten (automatisch) ableiten lassen.  
Dabei können die Werte manuell gesetzt werden, wie hier oder automatisch aus bereits vorhandenen gepflegten Stammdaten z.B. für Assetklassen, Branchen, Länder etc.

Wird eine Funktion benutzt, erfolgt die Vorbelegung der möglichen Werte auf Basis der vorhandenen Ausprägungen über alle Titel (Funktions-Ziel-Vektor). Die Min-Soll auf das % zu verteilende Gesamtvolumen der Anlage, ebenso wie der Max-Soll % Wert muss immer hinterlegt werden, unabhängig ob die Werte manuell oder automatisch generiert worden sind.

Es sollte dabei möglich sein eine bewusste selektive Übernahme von Werten aus den Stammdaten vorzunehmen. Eine pauschale Übernahme aller vorhandenen Ausprägungen wird nicht sinnvoll sein ohne gleichzeitig auch die Min/Max-Soll % Werte festlegen zu wollen. Es muss eine selektive Vorauswahl erfolgen.

Sonderposition Sonstiges

Damit wird am Ende nie eine komplette Funktionsabbildung verwendet, sondern eine automatische "Übernahme" unterstützt. Werte z.B. für Branchen die nicht zugeordnet sind, werden unter "Sonstiges" geführt. Der Wert "Sonstiges" wird automatisch eingetragen und kann auch eigene SOLL-Werte erhalten. Die Funktionsabbildung besitzt in der Ziel-Vektor-Definition damit keine Auflösung zur Laufzeit! Die Funktionsindexe werden nur in der Ausprägung pro Titel nur automatisch aufgelöst.

Gesamtabbildung und Toleranzen

Die Gesamtsumme der Werte sollte dabei inkl. Toleranz in der Theorie nicht mehr als 100 % umfassen.
Leider wird ein Depot aber selten vollständig bei hoch differenzierten Abbildungen alle Einzelausprägungen umfassen, daher soll es möglich sein bewusst eine Einzelwert-Sicht zu definieren unabhängig ob damit die Gesamtsumme der % Verteilung mehr als 100% umfasst.

Hier in einer optimierten Detail-Ansicht:

Pflege der Ausprägungen pro Titel

Für den ersten Entwurf muss es möglich sein die Ausprägungen pro Titel  (Aktie, Fonds ...) festzulegen z.B. die Branchenverteilung mit den IST-Werten zu hinterlegen.
Nachfolgend wieder am Beispiel der Branchenstruktur.

 

 

Die Eingabe ist nur dort notwendig, wo Vektoren genutzt werden, die manuelle Werte erfordern und nicht durch die eine einfache "Funktion" berechnet werden kann z.B. durch Übernahme aus den Standard-Stammdaten. Für die Startphase wird das Balancing hohe manuelle Aufwände produzieren, da die Werte manuell zu hinterlegen sind. In späteren Ausbaustufen soll/kann dies automatisch erfolgen. % Werte sollten grafisch visualisiert dargestellt werden.

In der Eingabe sollte zwischen den Einzel-Vektoren mit Tabs (hier noch nicht berücksichtigt) umgeschaltet werden können.

Überlegungen für die erweiterte Nutzung in Handelsstrategien

Um Handelsstrategien zu nutzen (siehe AddOns für ShareHolder) werden diese mit Parametern gestartet und liefern automatisiert Ergebniswerte mit einer Sortierung nach Ranking. Wird ein Balancing-Setup verwendet, sollte es nun möglich sein, den "Fit" eines Titels in der Zielstruktur des Portfolios einzeln zu bewerten. Dabei wird versucht entsprechend dem Ranking der Titel aus einer Strategie der "Fit-Score" der Reihe nach zu berechnen d.h. verbessert sich das Balancing durch Aufnahme des Titels oder verschlechtert sich das Portfolio entsprechend der Zielstruktur eher.

Beispiel-Prozess zur Abbildung:

1. Nach Ausführen der Strategie über einen definierten Markt liegt eine Sortierung entsprechend der Strategie vor z.B. nach Ranking-Score-Werten
2. Nun wird geprüft, welche der ersten 20 bis 30 Aktien valide sind d.h. für welche man ein "gutes Gefühl" hat
3. Die Guten wählt man zunächst z.B. über Checkboxen aus für die weitere Betrachtung
4. Es wird nun ein Ziel-Portfolio gewählt, wo entsprechend der Ziel-Balancing-Struktur ein ausbalanciertes Depot gebildet werden soll. Im Default ist es das aktuell gerade aktive Portfolio.
5. Nun vergleicht der Algorithmus, welche sind dazu gekommen und welche kommen nicht mehr vor ebenfalls wird dargestellt, wieviel muss ich von welcher Aktie nachkaufen um eine Target-Verteilung zu haben
   (z.Bsp.: Gleichverteilt oder nach Sektoren gewichtet wie in meinem Excel oder nach Momentum gewichtet....)

Anforderungen für interne Berechnungs-Features zum Balancing

Abgeleitet insb. für die Nutzung im Zusammenspiel mit Handelsstrategien ergeben sich einige notwendige Berechnungsfunktionen:

• Funktion: Balancing-Score-BuyVolume: Double + Balancing-Score-MarketVolume: Double
  Es muss möglich sein für ein Portfolio ein Balancing-Score-Wert zu berechnen. Dabei wird praktisch eine gewichteter Delta-Wert zwischen SOLL-Wert und dem aktuellen IST-Wert berechnet.
  
  
• Funktion: Balancing-Score( pStock: TStock; pBuyVolume: Double ): Double
  Gleichzeitig muss in einer Art Simulation ein Balancing-Score-Wert mit einem simulierten Kauf des Titels berechnet werden können. Dabei wird ein Auftragsvolumen für ein Titel parametisiert angenommen. Konkret: Wie ist der Portfolio-Score nach Kauf von Amazon-Aktien im Wert von 2000€. Wird beispielsweise bereits 40% eCommerce als Branchen-Soll-Mix angegeben und es sind bereits 39% im aktuellen Portfolio vorhanden, kann der Portfolio-Score schlechter als der bisherige Score-Wert werden, weil durch die Delta-Betrachtung zwischen IST und SOLL eine Übergewichtung festgestellt wird.
  
• Funktion: Balancing-Score-Volume-Recommendation( pStock: TStock ): Double
  Daraus ergibt sich indirekt auch die Anforderung, dass ich für einen Titel rückwärts eine Empfehlung für das sinnvolle Kaufvolumen bei Aufnahme eines neuen Titels berechnet werden können muss. Die heutige Implementierung macht dies allein auf Basis der vorhandenen Liquidität und berücksichtigt derartige Balancing-Anforderungen nicht. Die Integration muss dabei innerhalb des Transaktionsformulars erfolgen. 

Releasemanagement

Shareholder wird nach festen Regeln im Releasemanagement aktualisiert. Folgende Regeln sind definiert und angewendet. Bei einer angenommenen Release 20.8.3.0 ist folgende Semantik anzuwenden:

<MajorRelease><ModulReleases><SecondReleases><SubRelease>

• Major-Release: Grundsätzliche Änderungen in der Architektur, wie Änderungen des Objektmodells, Speichermodell. Das Release orientiert sich hier immer am Kalenderjahr.
• Modul-Releases: Neue Module wie Dynamic Filter, Neuronale Kursprognose, Handelssystem werden mit einem eigenen ModulRelease hochgezählt. Da pro Monat ein wesentliches Release veröffentlicht wird, orientiert sich auch diese Modul-Release-Nummer grob am Monat.
• Second-Releases: Bedeutende Änderungen an Modulen, Techniken usw. ohne Einführung eines neuen Modules
• Sub-Releases: Bugfixing, Programmpflege

Im Minimum wird das SubRelease aktualisiert mit jeder veröffentlichten Programmversion.

Veröffentlichung

Neue Versionen werden über die Website: "Releases" unter https://www.shareholder24.de/ veröffentlicht.

Eine einfache Kontrolle der aktuellen Version kann im Programm über das Menü erfolgen über "Prüfe Version". Dies wird auch beim Programmstart automatisch ausgeführt, kann aber auch in den Programmeinstellungen deaktiviert werden.

Normale Release-Zyklen für SubReleases sind aktuell 2 Wochen. Für SecondReleases jeden Monat.

Major-Releases auf Jahresebene

Entwicklungen auf Jahresebene verdichtet von 1999 bis 2020