Handelsplattform Plan
Ein Depot hat einen Handelsplattform Plan aus folgenden Gründen:
- Er steuert die korrekte Zuordnung der Importvorlagen zu einem Depot.
- Es kann ein Gebührenmodell definiert werden, um Transaktionskosten für hypothetische Trades abzuschätzen. So kann GT bei der Simulation der hypothetischen Glattstellung von Positionen realistische Ergebnisse liefern.
Im folgenden Entity-Relationship-Diagramm sind die Beziehungen dargestellt:
erDiagram
Depot }o--|| Handelsplattform-Plan : hat
Handelsplattform-Plan }o--o| Vorlagengruppe : hat
Vorlagengruppe ||--o{ Importvorlage : hat
Gebührenmodell
Das Gebührenmodell ermöglicht es, Transaktionskostenregeln als YAML auf einem Handelsplattform Plan zu definieren. Jede Regel besteht aus einer Bedingung und einem Gebührenausdruck, beide in EvalEx-Ausdrücken formuliert. Das Gebührenmodell wird in einem eigenen Dialog bearbeitet, der über das Kontextmenü der Handelsplattform-Plan-Tabelle geöffnet wird: Rechtsklick auf einen Handelsplattform Plan → Gebührenmodell bearbeiten…. Der Dialog enthält einen Monaco-Editor mit schemabasierter Autovervollständigung und Hover-Dokumentation für das YAML.
Depotspezifische Überschreibung
Einzelne Depots können ein eigenes Gebührenmodell-YAML definieren, das dieses Plan-Modell überschreibt. Der gleiche Gebührenmodell-Editor kann auch über das Kontextmenü des Depots im Navigationsbaum geöffnet werden → Gebührenmodell bearbeiten…. Wenn ein Depot ein eigenes Gebührenmodell hat, hat dieses Vorrang vor dem Modell dieses Handelsplattform Plans.
Aktueller Stand
Die Simulationsumgebung dient vorerst ausschliesslich zu Simulationszwecken. Sie wird derzeit noch nicht für die Berechnung offener Positionen verwendet — hypothetische Transaktionen berücksichtigen die Transaktionskosten also noch nicht.
Regeln werden von oben nach unten ausgewertet — die erste Regel, deren Bedingung true ergibt, bestimmt die Transaktionskosten. Verwenden Sie "true" als Bedingung für eine Auffangregel.
Es gibt zwei sich gegenseitig ausschliessende YAML-Formate auf der obersten Ebene:
Flache Regeln (ohne Datumseinschränkung)
Verwenden Sie das rules-Array auf oberster Ebene, wenn sich das Gebührenmodell zeitlich nicht ändert. Beispiel für einen Schweizer Broker:
Zeitbasierte Perioden mit verschachtelten Regeln
Verwenden Sie das periods-Array auf oberster Ebene, wenn sich das Gebührenmodell im Laufe der Zeit ändert. Jede Periode hat ein validFrom-Datum, ein optionales validTo-Datum und ein eigenes rules-Array. Die erste Periode, die zum Transaktionsdatum passt, wird verwendet. Fehlt validTo, gilt die Periode unbefristet.
Gegenseitig ausschliessend
Ein Gebührenmodell-YAML muss entweder rules oder periods auf der obersten Ebene enthalten, nie beides.
JSON-Schema
Das YAML muss dem folgenden JSON-Schema entsprechen. Es kann auch als Kontext für ein LLM verwendet werden, um gültiges Gebührenmodell-YAML zu generieren.
Variablenreferenz
Die folgenden Variablen stehen in Bedingungen und Ausdrücken zur Verfügung:
| Variable | Typ | Beschreibung |
|---|---|---|
tradeValue | Numerisch | Gesamtbetrag des Trades (Preis × Anzahl) |
units | Numerisch | Anzahl der Anteile/Stücke |
instrument | String | Finanzinstrumenttyp, z.B. "DIRECT_INVESTMENT", "ETF", "MUTUAL_FUND", "PENSION_FUNDS", "CFD", "FOREX", "ISSUER_RISK_PRODUCT" |
assetclass | String | Anlageklasse, z.B. "EQUITIES", "FIXED_INCOME", "MONEY_MARKET", "COMMODITIES", "REAL_ESTATE", "MULTI_ASSET", "CONVERTIBLE_BOND", "CREDIT_DERIVATIVE", "CURRENCY_PAIR" |
mic | String | MIC-Code der Börse, z.B. "XSWX", "XNYS" |
currency | String | ISO-Währungscode, z.B. "CHF", "USD" |
fixedAssets | Numerisch | Gesamtwert des Portfolios |
tradeDirection | Numerisch | 0 = Kauf, 1 = Verkauf |
transactionDate | Datum | Relevant für das Periodenformat — bestimmt, welche Periode gilt |
Zusätzlich stehen die numerischen Legacy-Variablen specInvestInstrument und categoryType als ordinale Byte-Werte der Instrument- bzw. Anlageklassen-Enums zur Verfügung.
EvalEx-Funktionen
Bedingungen und Ausdrücke unterstützen die Standard-EvalEx-Funktionsbibliothek. Häufig verwendete Funktionen sind:
MAX(a, b)undMIN(a, b)— gibt den grösseren bzw. kleineren Wert zurückIF(bedingung, dannWert, sonstWert)— bedingter AusdruckABS(wert)— AbsolutwertROUND(wert, dezimalstellen)— Rundung- Arithmetische Operatoren:
+,-,*,/ - Vergleiche:
==,!=,>,<,>=,<= - String-Gleichheit:
instrument == "ETF"
Gebührenschätzung testen
Im Gebührenmodell-Dialog befindet sich unterhalb des YAML-Editors ein einklappbares Panel Gebührenschätzung testen. Damit können Sie überprüfen, ob Ihre Regeln die erwarteten Kosten liefern. Die Testparameter verwenden Dropdown-Auswahlfelder, wo immer möglich, so dass Sie z.B. eine Börse oder Währung bequem aus einer Liste wählen können.
| Feld | Beschreibung |
|---|---|
| Handelswert | Gesamtbetrag des Trades (Preis × Anzahl) |
| Anzahl Position | Anzahl der gehandelten Anteile/Stücke |
| MIC | Börse als Dropdown (z.B. «Euronext Lisbon - XLIS») |
| Währung | Handelswährung als Dropdown (z.B. CHF, USD) |
| Depotwert | Gesamtwert des Portfolios/Depots |
| Finanzinstrument | Instrumenttyp als Dropdown (z.B. ETF, Direktanlage, Investmentfonds) |
| Anlageklasse | Anlageklasse als Dropdown (z.B. Aktien, Obligationen, Rohstoffe) |
| Handelsrichtung | Dropdown mit Kaufen / Verkaufen |
| Transaktionsdatum | Datumswähler — relevant für das Periodenformat |
- Füllen Sie die gewünschten Testparameter aus.
- Klicken Sie auf Gebührenschätzung testen. Dabei wird das YAML zunächst automatisch gespeichert und danach die Schätzung gegen das gespeicherte Modell durchgeführt.
- Das Ergebnis zeigt die geschätzten Kosten und den Namen der zutreffenden Regel an, oder eine Fehlermeldung, falls keine Regel zutraf.
- Um das YAML ohne Test zu speichern, verwenden Sie die Schaltfläche Speichern.
Vergleich mit realen Transaktionskosten
Während das Testpanel oben einzelne hypothetische Transaktionen validiert, vergleicht der Gebührenmodellvergleich im Transaktionskosten-Report die geschätzten Kosten des Gebührenmodells mit den tatsächlich erfassten Kosten aller Kauf-/Verkaufstransaktionen eines Depots. Er liefert statistische Kennzahlen (mittlerer absoluter Fehler, mittlerer relativer Fehler, RMSE), um die Gesamtgenauigkeit des Gebührenmodells zu bewerten.