Fremdwährung für Asset Manager im internationalen Umfeld
In Teil 1 des Beitrages hatte ich die Behandlung von einzelnen Fremdwährungstransaktionen beschrieben. Heute geht es weiter mit der späteren Darstellung in Reports, Dashboards und anderen Extrakten in denen einzelne Transaktionen kumulierte verarbeitet werden.
Fremdwährungsberechnung irgendwann nach Valutierung z.B. in Dashboards
Die Zeilen-/ Spaltenkombination der Matrix bis auf die Spalte mit der Transaktion gleich bleiben. Die Transaktionswährung habe ich weggelassen, da sie für die meisten der gängigen Reports keine Rolle spielt. Eine mögliche Ausnahme wäre ein Zahlungskontenabgleich.
| # | Kategorie | Instrument (Security) | Fonds (Investee) | |
| Abkürzung | INS | FON | ||
| 1 | Commitment | CMT | ||
| 1.1 | Gezeichnet | GEZ | INS_GEZ | FON_FUN + INS_UFU * afx – INS_RED * afx |
| 1.2 | Funded | FUN | INS_FUN | FON_FUN |
| 1.3 | Unfunded | UFU | INS_UFU | INS_UFU * afx |
| 1.4 | Redrawable | RED | INS_RED | INS_RED * afx |
| 2 | Cashflow | CF | ||
| 2.1 | Contribution | CON | INS_CON | FON_CON |
| 2.2 | Distribution | DIS | INS_DIS | FON_DIS |
| 3 | Valuation | VAL | ||
| 3.1 | NAV | NAV | INS_NAV | INS_NAV * afx |
| 3.2 | adjusted NAV | ANV | INS_ANV | INS_ANV * afx |
Die Berechnungsformeln in der Matrix haben sich teils signifikant geändert.
Alle Beträge in Instrumentwährung ergeben sich aus den einzelnen Events und dem Einfluss der dort benutzten Felder auf die Kalkulation. Hierauf bin ich schon an anderer Stelle im Blog eingegangen. Schauen wir uns gemeinsam die Spalte Fonds (Investee) an und was hier wie berechnet wird. Es sollte klar sein, dass es sich in der Auswertung um kumulierte Beträge aus einzelnen Events handelt.
1.1 Commitment (gezeichnet)
FON_FUN + INS_UFU * afx – INS_RED * afx
FON_FUN
Ich berechne hier kumulierter Betrag in Fondswährung aus dem Commitment (funded). Es erfolgt keine Umrechnung von der Instrumentwährung, da funded auch bedeutet, dass der Betrag zu bestimmten Stichtagen realsiert wurde. Ich benötige die Beträge mit den historischen Umrechnungskursen. Um nicht jedes mal die Berechnungsschleife neu starten zu müssen, empfehle ich diese Werte bei jedem einzelnen Event kalkuliert zu hinterlegen. Ist dies der Fall, reicht eine einfache Addition.
+ INS_UFU * afx
Nun rechne ich hinzu ausgehend von der Instrumentwährung umgerechnet zum aktuellen Kurs (afx) den Teil des Commitments (unfunded). Ich benutze hier die Umrechnung, da dieser Betrag erst zukünftig abgerufen wird und ich daher ein aktuelles Bild benötige.
– INS_RED * afx
Was macht er jetzt? Die Erklärung ist simple, wenn die Zusammensetzung des Commitment (unfunded) klar ist. Es ist nämlich so, dass der wiederziehbare Betrag dem Commitment (unfunded) zugeschlagen wird. Da dies allerdings ein zusätzlicher Betrag ist muss er bei der Ermittlung des gezeichneten Commitments wieder abgezogen werden. Da auch dieser Betrag in der Zukunft abgerufen wird, erfolgt eine Umrechnung von Instrumentwährung zum aktuellen Währungskurs.
1.2 Commitment (funded)
FON_FUN
Die Erklärung habe ich schon beim gezeichneten Commitment gegeben. Der Betrag setzt sich zusammen aus der Addition aller realisierten das Commitment berührenden Beträge. Da realisiert kann eine Addition in Fondswährung erfolgen und es ist keine Umrechnung aus der Instrumentwährung notwendig.
1.3 Commitment (unfunded)
INS_UFU * afx
Dieser Teil des Commitments wurde noch nicht in Anspruch genommen, daher erfolgt eine Umrechnung aus der Instrumentwährung welche hier im Lead ist.
2 Cashflow (Contribution und Distribution)
FON_CON
FON_DIS
Diese Beträge sind realisiert. Hier gilt dieselbe Empfehlung wie beim Commitment (funded). Hinterlege die Werte zu historischen Kursen, dann brauchst du nur eine Addition vorzunehmen. Da diese Beträge realsiert wurden, macht es keinen Sinn sie ausgehend von der Instrumentwährung zum aktuellen Kurs umzurechnen. Du solltest auf keinen Fall die Beträge in Instrumentwährung addieren und mit dem aktuellen Kurs multiplizieren. Dies würde das Ergebnis total verfälschen.
3.1 NAV
INS_NAV * afx
Es sollte sich bei dem Betrag um den letzten übermittelten offiziellen NAV handelt. Dies wird manchmal anders gehandhabt. Es gibt Manager die benutzen hier den FON_NAV. Ich persönlich bevorzuge die Umrechnung aus der Instrumentwährung heraus, da ich so die Bewegung aus den Währungskursschwankungen heraus aufzeige. Letztendlich denke ich ist es eine Sache der Beschreibung und Erklärung gegenüber Investoren und Prüfern. Auch der Zweck der Auswertung spielt eine Rolle. Solltest du wirklich die am Bewertungsstichtag in Fondswährung umgerechnete Bewertung benötigen, dann wäre FON_NAV die richtige Wahl.
3.2 adjusted NAV
INS_ANV * afx
Anders als beim NAV habe ich hier eine klare Vorstellung. Der adjusted NAV basiert auf dem zuletzt reporteten NAV und den Veränderungen im Zeitraum danach. Mein Anker ist die Instrumentwährung und ich möchte den aktuellen Zeitwert angegeben. Daher muss ich ausgehend von der Instrumentwährung eine Umrechnung zum aktuellen Währungskurs vornehmen.
Fazit
Das war es auch schon. Sicherlich keine leicht verdauliche Kost obwohl ich das Thema Fremdwährung hier nur angerissen habe. Meine Idee war es, ein Grundverständnis zum Thema Währungstransaktionen zu erzeugen. Wie schone gesagt, ein klar definiertes Schema mit einer Währung als Ankerpunkt sind für mich die Erfolgsfaktoren. Bitte bedenke auch immer, es muss alles wartbar bleiben, da ansonsten früher oder später bei noch so ausgeklügelten Systemen schnell unerwünschte Effekte eintreten können.
Für die Währungskalkulation nutze ich 3 Betragstypen. Diese sind:
- Realsierte Beträge, welche später keine Umrechnung aus der Ankerwährung heraus erfordern. dies sind z.B. Contributions und Distributions.
- Unrealisierte Beträge, welche stets aus der Ankerwährung heraus mit dem aktuellen Kurs berechnet werden sollten. Hier spreche ich z.B. vom adjusted NAV oder Commitment (unfunded).
- Hybride Beträge, z.B. das Commitment (gezeichnet), welches sich aus der Summe von realisierten und unrealisierten Beträgen zusammensetzt. Dieser Typ verlangt technische Hilfestellung. Aber einmal klar definiert, sollte dies zu meistern sein.
All diese Kalkulationen kann man über Excel darstellen, sollte man aber nicht wenn man auditkonform und professionell arbeiten möchte. Ich setze Excel zur Generierung von Simulationen und Vergleichsschemen ein, welche ich für die Validierung von Asset-Management-Lösungen nutze. Dies sind aber keine Produktions-, sondern reine Testdaten. Der Einsatz der neuen Power Query Funktionalität in Excel erleichtert mir hier vieles.
Ich arbeite mit einem generischen Grundschema, welches ich kundenspezifisch anpasse. Mein Schema beinhaltet den Life Cycle eines Fonds mit den verschiedenen Währungen unter Aneinanderreihung aller erdenklichen Events in logischer Folge. Nach Bestätigung durch meinen Mandanten baue ich mir einen Transformations-Layer, welcher die Kundenlogik in die Logik des jeweils im Fokus stehenden Systems übersetzt.
Der große Vorteil ist, dass die einmal für den Mandanten dokumentierte Logik für mehrere Zielsysteme eingesetzt werden kann. Ist die Transformation getan und Schnittstellen sind vorhanden, können die Daten in das Zielsystem geladen werden und mit den Auswertungen meines Kalkulationsschemas verglichen werden. Du glaubst gar nicht, welche ein oder andere Überraschung bei den sündhaft teuren Lösungen zu tage. Ich lege jedem in der Branche ans Herz, investiere die Zeit und baue ein Referenzschema auf. Fundierte Tests vor dem finalen Erwerb eines Systems werden die eine Menge Ärger ersparen. Eine solche Dokumentation ist immer zu gebrauchen und regt neue Gedanken über eigene Abläufe in der Organisation an.