Diese Seite wurde maschinell übersetzt. Das englische Original ist maßgeblich. Auf Englisch lesen
Zum Hauptinhalt springen

Volatilitätsoracle

Hypercall verwendet eine implizite Volatilitätsoberfläche für die Optionspreisbildung, Greeks, Mark-to-Market-Bewertung und Margin-Prüfungen. Das Volatilitätsoracle wandelt Optionsmarktdaten in abfragbare IV-Werte nach Basiswert, Ausübungspreis und Verfall um.

Das Ziel ist einfach: Live-Marktvolatilität verwenden, wenn sie verfügbar ist, und im Fehlerfall geschlossen bleiben (fail closed), anstatt Werte zu erfinden, wenn erforderliche Daten fehlen.

Was das Vol-Oracle tut

Für jeden unterstützten Basiswert pflegt Hypercall eine Volatilitätsoberfläche:

  • Strike-Dimension: Die IV variiert je nach Ausübungspreis der Option.
  • Verfalls-Dimension: Die IV variiert je nach Restlaufzeit bis zum Verfall.
  • Interpolation: Wenn ein exakter Punkt aus Ausübungspreis und Verfall nicht verfügbar ist, interpoliert Hypercall über benachbarte gültige Punkte.
  • Aktualitätsprüfungen: Jeder Anbieter hat Aktualitätsregeln. Veraltete Daten werden nicht als live behandelt.

Die IV wird als Dezimalzahl gespeichert. Zum Beispiel wird eine IV von 80 % als 0.80 dargestellt.

Session-bewusstes Modell

Einige Volatilitäts-Quellmärkte können andere Handelszeiten als Hypercall haben. Wenn ein Quellmarkt live und funktionsfähig ist, verwendet Hypercall die aktuelle Quelloberfläche.

Das Modell skaliert die Ausübungspreise der Quelle mithilfe von Live-Spotpreisen in den Strike-Raum der Plattform um:

scale = platform_spot / source_spot
platform_strike = source_option_strike * scale

Beide Spot-Eingaben müssen positiv und aktuell sein. Wenn der Quell-Spot oder der Plattform-Spot fehlt, schlägt die Aktualisierung der Live-Oberfläche fehl, anstatt eine zwischengespeicherte oder statische Skalierung zu verwenden.

Geschlossene Quell-Sessions

Wenn ein Quell-Optionsmarkt geschlossen ist oder die Live-Oberfläche veraltet ist, tut Hypercall nicht so, als wären alte Quelldaten live.

Stattdessen kann das Modell die letzte gültige Quelloberfläche verwenden und sie in den aktuellen Moneyness-Raum der Plattform transformieren:

base_strike = requested_platform_strike * base_spot / current_platform_spot
base_iv = last_good_source_surface(base_strike, expiry)

Dies bewahrt die Sticky-Log-Moneyness. Eine Option, die 5 % aus dem Geld (OTM) ist, wird dem Punkt der Quelloberfläche zugeordnet, der zum Zeitpunkt der Erfassung der Quelloberfläche ebenfalls 5 % aus dem Geld war.

Das Modell fügt dann das Ereignisrisiko der geschlossenen Session als Gesamtvarianz hinzu:

final_iv = sqrt((base_iv^2 * time_to_expiry + event_jump^2) / time_to_expiry)

Dadurch reagieren Optionen mit kurzer Laufzeit empfindlicher auf das Gap-Risiko geschlossener Sessions, was beabsichtigt ist.

Fail-Closed-Bedingungen

Das Vol-Oracle bleibt bei risikoerhöhenden Abfragen geschlossen (fail closed), wenn erforderliche Daten nicht verfügbar sind. Beispiele hierfür sind:

  • kein konfigurierter Volatilitätsanbieter für den Basiswert
  • veraltete Live-Quelle ohne gültigen letzten gültigen Snapshot
  • fehlender oder ungültiger Plattform-Spot
  • fehlender oder ungültiger Quell-Spot während der Konstruktion der Live-Quelle
  • Quell-Snapshot älter als das konfigurierte Zeitfenster für geschlossene Sessions
  • transformierter Ausübungspreis oder Verfall kann nicht interpoliert werden
  • nicht unterstützter Basiswert oder fehlender Punkt auf der Quelloberfläche

Fail-Closed bedeutet, dass das System Berechnungen ablehnt, die von der fehlenden IV abhängen, wie etwa neue risikoerhöhende Orders, die Margin benötigen. Es ist besser, eine Order abzulehnen, als sie mit erfundener Volatilität zu bewerten oder zu marginen.

Was Nutzer erwarten sollten

Wenn die Quellmärkte geöffnet sind und die Datenfeeds funktionsfähig sind, verwenden Preisbildung und Margin implizite Live-Volatilitätsoberflächen.

Wenn ein Quellmarkt geschlossen ist, können betroffene Märkte weiterhin die session-bewusst transformierte Oberfläche verwenden, sofern der letzte gültige Snapshot und der aktuelle Plattform-Spot gültig sind.

Wenn das Modell seine Eingaben nicht validieren kann, können betroffene Orders abgelehnt werden, bis frische Daten oder eine gültige transformierte Oberfläche verfügbar sind.

Siehe auch