Performance eines Wertpapieres wird nicht korrekt berechnet, wenn nachgekauft wird

[ghost]

Wird ein Wertpapier nachgekauft und ist der Kaufkurs höher als der aktuelle Kurs (Ausgeabeaufschlag), wird die Performance (TTWROR) abe diesem Zeitpunkt nicht mehr korrekt berechnet. Die Gesamtperformance des kompletten Portfolios ist für mich nachvollzeihbar.
Da jedoch nur dieses eine Wertpapier enthalten ist, müsst die Gesamtperformance und die des Wertpapieres nahezu gleich sein. Oder habe ich einen Denkfehler?
Anbei 2 Beispieldateien.

Test.zip

[buchen]

Ich werde mir die Datei anschauen.

Da jedoch nur dieses eine Wertpapier enthalten ist, müsst die Gesamtperformance und die des Wertpapieres nahezu gleich sein.

Wenn das Gesamtportfolio nur dieses Wertpapier enthält, dann sollte die Performance gleich sein.

Hast du noch ein Referenzkonto erfasst? Eine Cashposition auf dem Referenzkonto "dämpft" natürlich die Performance, da Cash um die 0 Prozent bringt.

Und natürlich will ich nicht ausschliessen dass es auch Bugs gibt 😉

[ghost]

Es gibt ein Referenzkonto, auf das jedoch 1 Tag vor dem Kauf die jeweilige Summe eingebucht wurde (Einlage) die zum Kauf verwendet wurde; Ansonsten befinden sich nur die Dividenden darauf.
Mich wundert, dass die Gesamtperformance besser ist als die des Wertpapiers. Die Gesamtperformance kann ich rechnerisch nachvollziehen und ist meiner Meinung nach richtig. Anbei ein Bild von Test02.xml.

Zum Test habe ich ein Wertpapier mit einer Kurssteigerung von 1% por Jahr kreiert. Am Jahresende wird die Dividende in Höhe der Wertsteigerung ausgezahlt und der Kurs fällt auf den Anfangswert (100,- €) zurück. Das ergibt eine Performance von 1% pro Jahr.
Das oben beschriebene Verhalten ist mir bein einem realen Immobilienfonds aufgefallen.

[buchen]

Hi @hendrikm78,

ich habe mir jetzt die Datei "Test02.xml" angeschaut --> also die Frage, warum sich die Performance von dem Gesamtportfolio und "Test 1%" unterscheiden.

Es ist das selbe Problem wie hier im Forum beschrieben: Aktuell wird die Performance eines Tages bereits investierten Kapital zugeordnet.

In Deinem Fall kaufst Du das Wertpapier zu 101:

Der Kurs am Ende des Tages ist aber drunter:

Dieser Verlust wird dem bisherigen Kapital zu geordnet.

In dem "Gesamtportfolio" tritt das nicht auf, weil bei der Betrachtung des Gesamtportfolios der Mittelzufluss ja schon einen Tag vorher auftritt. Wenn Du die Einzahlung auf den selben Tag legst, dann sind die Kurven (fast) identisch (ich denke die kleine Cashposition macht den Unterschied):

Ich habe vor diese Berechnung zu ändern, aber leider bin ich noch nicht dazugekommen. In der Literatur gibt es den midday-cashflow, aber auch hier bleiben noch Abweichungen. Ich überlege die Performance des Zukaufs separat zu rechnen und dann mit der Performance des restlichen Investments zu verrechnen. Ich bin noch nicht dazu gekommen. 😐

[ghost]

Hi @buchen,
alles klar, so etwas ähnliches habe ich mir schon fast gedacht. Wenn man mehrere Nachkäufe hat, so kann es passieren, dass die Performance <0% ist, der IZF jedoch >0% und Betragsmäßig auch ein Wertzuwachs festzustellen ist.
Wäre es nicht sinnvoller, wenn sich direkt ab dem Kauf die Performance auf die Summe des investierten Geldes und des Kaufbetrages bezieht?

[buchen]

Aus dem Wertpapier Forum:

Hast du denn mal in Erwägung gezogen, Mittelzuflüsse grundsätzlich am Tagesanfang und Mittelabflüsse am Tagesende anzuwenden? Das ist keine große Änderung der bestehenden Formel und die Performance eines Cashflows wird in beide Richtungen korrekt angewendet: Bei einem Kauf werden Kaufkosten und Kursunterschiede des Tages nach Mittelzufluss (auf den Bestand nach Kauf) angewendet. Bei einem Verkauf werden Verkaufskosten vor Mittelabfluss (auf den Bestand vor Verkauf) angewendet (Kursänderungen können nicht mehr stattfinden, wenn die Position geschlossen ist).

(Vt - Cut) / (Vs + CIt)

Vt = Bewertung am Zeitpunkt (Tag) t
Vs = Anfangsbewertung
CO = Cash flow out
CI = Cash flow in

[ghost]

Sieht gut aus.

[michaellass]

(Vt - Cut) / (Vs + CIt)

Vt = Bewertung am Zeitpunkt (Tag) t
Vs = Anfangsbewertung
CO = Cash flow out
CI = Cash flow in

Das sah mir nach keiner großen Änderung aus, daher habe ich versucht, es zu implementieren (siehe verlinkter Commit). Allerdings hat das als Seiteneffekt, dass Einlagen nicht mehr performance-neutral sind.

Gibt es überhaupt eine Möglichkeit, dieses Problem zu beheben, ohne eine Reihe anderer zu schaffen?

[michaellass]

Ich habe noch einen zweiten Versuch unternommen, das Problem anzugehen, indem nur Steuern und Gebühren in Relation zu den Einlagen des jeweiligen Tages berechnet werden und der Rest nach wie vor nur in Relation zum Gesamtwert des Vortages. Das löst Probleme mit einigen Testfällen, aber nicht mit allen.

An dieser Stelle steige ich ersteinmal aus, da ich unsicher bin, was genau hier ein gewünschtes Verhalten ist und ob ein paar der Tests entsprechend angepasst werden müssten. Auch was alles zu den Einlagen zählen sollte ist mir nicht klar (z.B. auch Steuerrückzahlungen?).

[ghost]

Hi @michaellass ,

die Formel aus dem Wertpapierforum stammt ursprünglich von mir. Vielleicht ist diese Erläuterung dazu hilfreich.

Zunächst hat die Variable COt (Copy und paste hat oben scheinbar daraus ein "Cut" gemacht) als "Cash flow out" ein negatives Vorzeichen, insofern ist die folgende Schreibweise eindeutiger:

(V^t + Abs(CO^t)) / (V^s + CI^t)

V = Bewertung der Position zu einem Zeitpunkt
^s = Start (Zeitpunkt vor dem Mittelfluss, d.h. hier am Ende des Vortags)
^t = Messpunkt (Zeitpunkt nach Mittelfluss und Gebühren), d.h. jetzt oder am Ende des Tages des Mittelflusses- was immer davon früher ist)
CO = Mittelabfluss ohne Gebühren und sonstige damit verbundenen Kosten
CI = Mittelzufluss ohne Gebühren und sonstige damit verbundenen Kosten

V^t ist immer die Bewertung der Position nach Gebühren und Mittelflüssen.

Korrekt angewendet ist eine Einlage nach dieser Formel performanceneutral, wie das folgende Beispiel zeigt:

Eine Position enthält 1 Stück zum Preis von 10,00 Euro (V^s = 10,00 Euro). Nun kaufen wir 10 Stück zum Preis von 10,00 Euro (CI^t = 100,00 Euro). Bleibt der Kurs gleich, sollte die Rechnung also performanceneutral sein:

(110,00) / (10,00 + 100,00) * 100 - 100 = 0%

Perfekt! Jetzt simulieren wir zusätzliche eine Kursänderung von -10% zum Kaufzeitpunkt:

(99,00) / (10,00 + 90,00) * 100 - 100 = -1%

Die Performance sinkt, allerdings nicht um -10% sondern nur marginal, da wir die 10 Stück erst nach dem Kursrutsch gekauft haben. Das ist der große Unterschied zur bisherigen Implementierung!

Nehmen wir alternativ einmal an, dass der Kurs gleich bleibt und Kosten von 10,00 Euro für den Kauf von 10 Stück angefallen wären:

(100) / (10,00 + 100,00) * 100 - 100 = -9,1%

Wir haben einen Vermögenswert von 10,00 Euro, tätigen dann einen Kauf mit sofortigem Verlust von 10% durch Kaufkosten und die Gesamtperformance sinkt um -9,1%, weil der Verlust nur auf das Tagesgeschäft angewendet wird.

Nebenbei: Persönliche Steuern wie die Kapitalertragssteuer haben meiner Meinung nach in der Performanceberechnung nichts zu suchen, weil sie die Vergleichbarkeit der Messung unmöglich machen.

[buchen]

@imagine-ecommerce - Danke für das ausführliche vorrechnen.

@michaellass - ich hatte auch schon mal angefangen, bin aber auch an existierenden Testfällen hängen geblieben 😄 Aktuell sammele ich die Mittelzuflüsse/-abflüsse in einer Variable. In einem ersten Schritt würde ich das erst mal aufteilen in "inbound" und "oubound cash flows". Wenn Du das hast, check pushe den Code doch gerne noch mal hoch. Die weiteren Testfälle kann ich mir anschauen.

[michaellass]

Ich bin bisher noch nicht zu einem weiteren Anlauf gekommen, habe es aber noch auf dem Schirm.

Bei der Gelegenheit wäre die Frage, ob man das Einbeziehen von Gebühren und/oder Steuern in die Performance konfigurierbar machen möchte. @imagine-ecommerce hat ja die persönlichen Steuern schon angesprochen und ich meine mich zu erinnern, dass auch schon diskutiert wurde, ob die Gebühren mit einfließen sollen. @buchen, was meinst du?

Persönlich fände ich das gar nicht schlecht. So könnte man gut sehen, wie viel der persönlichen Performance durch Gebühren aufgefressen wird.

[buchen]

Bei der Gelegenheit wäre die Frage, ob man das Einbeziehen von Gebühren und/oder Steuern in die Performance konfigurierbar machen möchte.

Aktuell wird die Performance unter Einbeziehung von Gebühren und Steuern berechnet. Ich würde auch in einem ersten Schritt die Rechnung erst mal so ändern, dass Zu/Abflüsse besser verrechnet werden.

Ein zweiter Schritt (separater Change) ist dann die Konfiguration. Vermutlich würde man in den Auswahldialog für die Datenreihen noch mehr einfügen (quasi verdoppeln).

[ghost]

Die Berechnung von @imagine-ecommerce finde ich richtig und nachvollziehbar.

In der aktuellen Version ist es so, dass Gebühren und Dividenden auf die Performance des einzelnen Wertpapiers angerechnet werden.
Die Steuern werden nicht bei Betrachtung eines einzelnen WPs in der Performance berücksichtigt. Dies würde ich auch so belassen, da Steuern sehr individuell sind und die Performance eines WP verfälschen, z. B. könnte es vorkommen das Gewinne aus Verkäufen zu Anfang des Jahres noch steuerfrei sind (Freibetrag), am Ende des Jahres jedoch besteuert werden. Somit wäre ein Vergleich der Performance von einzelnen WPs deutlich erschwert.
Bei Auswertung des Deopts, Depot+Konto oder des Gesamtportfolios werden die Steuern ebenfalls berücksichtigt.

Ein- und Auslieferungen sind Performance-neutral, das ist soweit richtig.

Leider bin ich nicht fit in github, daher meine Änderungen am aktuellen Snapshot (0.26.6) hier als diff-Files.
Performance-Issue-01_HMR.zip

[buchen]

Ich habe basierend auf dem Change von @hendrikm78 PP jetzt angepasst.

Das aufwändigste war die Performance Berechnung von Kategorien. Vorher habe ich der Einfachheit halber alle Umbuchungen, Käufe, etc. in Einlagen / Auslieferungen umgewandelt. Die transferals haben sich ja wieder aufgehoben. Da jetzt inbound und outbound transferals separat betrachtet werden, hatte das plötzlich einen Performanceeffekt.

Ich habe eine Testversion hier hochgeladen - @hendrikm78 @michaellass @imagine-ecommerce - Zeit zu testen?
Win 64bit | Win 32bit | macOS

[michaellass]

Ich habe eben den aktuellen Stand des feature_perf_calculation Branches kurz angetestet (bin aktuell unter Linux). Das sieht sehr gut aus!

Mir ist aufgefallen, dass in einem Portfolio, wo ich mit einem Sparplan einem einzelnen Wertpapier folge, die Performance nun nicht mehr genau dem Wertpapier entspricht. Aber ich schätze, das ist zu erwarten, wie der hinzugefügte Kommentar in testThatPerformanceOfAnInvestmentIntoAnIndexIsIdenticalToIndex() sagt:

performance is only identical if the capital invested
additionally has the identical performance on its first day -->
use the closing quote of the previous day

Das hatte mich damals bei meinen Versuchen etwas verunsichert.

[buchen]

Mir ist aufgefallen, dass in einem Portfolio, wo ich mit einem Sparplan einem einzelnen Wertpapier folge, die Performance nun nicht mehr genau dem Wertpapier entspricht.

Bei meinem echte Portfolio unterscheiden sich die Performance Kennzahlen für das Gesamtportfolio oder grosse Kategorien (Asset Allocation) nur in der zweiten Nachkommastellen. Bei einzelnen Wertpapier sieht das teilweise anders aus. Da hat sich sich auch einmal um 0.5 geändert.

[michaellass]

Ja, das deckt sich zahlenmäßig gut mit meinen Beobachtungen. Der Effekt ist sehr klein und gleicht sich vermutlich über die Zeit und über mehrere Wertpapiere hinweg aus. Insgesamt finde ich, wird die Performance mit dieser Änderung deutlich besser abgebildet - insbesondere eben in der Anfangszeit eines sich aufbauenden Portfolios, wo dieser Bug stark zum Tragen kam. 👍

[ghost]

Ich habe die Testversion ausprobiert. So wie ich das sehe, sind die Ergebnisse jetzt wie erwartet.
Die Unterschiede im TTWROR entstehen dadurch, dass hier zum einen die Einlagen in das Gesamtportfolio und ein vorhandener Spread/Ausgebeaufschlag korrekt berücksichtigt werden.

• Bis jetzt war es so, dass Einlagen immer einen Tag vor dem Kauf des WPs gebucht werden mussten, damit diese richtig erfasst wurden.
• Bei Kauf eines WP wird jetzt der Verlust durch den Spread/Ausgabeaufschlag auf die Summe aus Depowert vor Kauf und den Kaufpreis bezogen. Der Differenz zwischen den beiden Programmversionen ist um so größer, je höher der Spread/Ausgabeaufschlag ist.
  Hier mal ein Extrembeispiel:
  Demo_Immo_Global.zip
  Die Wertentwicklung in € ist positiv, jedoch wurde ein negatives TTWROR errechnet (alte Version), richtig müsste es aber positiv sein (Testversion).
  Ich denke in diesem Zusammenhang sollte auch Performance Diagram trotz gestiegener Kurse negativ #61 gelöst sein.

[buchen]

Mit der neuen Version sind die beiden absolut identisch.

im Gegensatz zu (alter Version):

So ganz gesund sieht der Graph trotzdem noch nicht aus.

Wenn alles gut geht, werde ich gleich die neue Version bauen und veröffentlichen.

[ghost]

Die Peaks kommen daher, das ich den Eingang der Dividenden einen Tag früher als in der Realität gebucht habe, zu diesem Zeitpunkt hat der Kurs des WP den entsprechenden Rückgang noch nicht vollzogen. Dies erfolgt einen Tag später.
Ich habe gerade mal testweise für 2016 das Datum korrigiert, dann verschwindet auch der Peak, das ist kein Programmfehler.
Ab Mitte 2016 hat sich die Quelle für die Kurse geändert. Vorher waren es die Werte von der Fondsgesellschaft, jetzt sind es Werte von Onvista von einem Börsenplatz. Dies sollte den Unterschied ab diesem Zeitpunkt erklären.