Zaawansowane zagadnienia dotyczące komponentów planu
Komponenty planu: definicja i dlaczego zaawansowani użytkownicy zwracają na nie uwagę
Komponenty planu to odrębne, nazwane elementy, które razem opisują, jak działa plan handlowy. W kontekście informacyjnym można o nich myśleć jak o „zasadach roboczych” planu (na przykład: warunki wejścia, logika określania wielkości pozycji, zasady zarządzania transakcją oraz to, co zatrzymuje plan). Zaawansowane zagadnienie nie dotyczy istnienia tych części, ale tego, czy są one wewnętrznie spójne i wykonalne w realistycznych warunkach.
Kluczową kwestią jest zależność: wiele komponentów planu opiera się na tych samych założeniach—takich jak czas (kiedy próbkowane są ceny), jednostki (jak mierzone jest ryzyko) i ograniczenia (co może, a co nie może się wydarzyć). Gdy założenia jednego komponentu po cichu różnią się od założeń innego, plan może zachowywać się w nieprzewidywalny sposób, nawet jeśli każda część wydaje się rozsądna w izolacji.
Prosty model zależności między komponentami
Praktycznym sposobem myślenia o komponentach planu jest modelowanie ich jako łańcucha wejście-wyjście.
- Dane wejściowe: informacje, których używasz (ceny, limity ryzyka, wielkość konta, charakterystyka instrumentu), mierzone w określonych momentach.
- Logika decyzyjna: zasady, które określają, czy działanie jest dozwolone (na przykład, czy transakcja jest dozwolona) i jak duże może być.
- Zasady zarządzania: zasady dotyczące tego, co dzieje się po wejściu (na przykład, jak określane są wyjścia lub korekty).
- Ograniczenia: limity, które muszą obowiązywać niezależnie od wyników (na przykład maksymalna ekspozycja lub warunki, w których plan jest wstrzymywany).
Zaawansowana praca koncentruje się na tym, jak te części się łączą.
Wspólne założenia muszą być jawnie spójne
Jeśli określanie wielkości pozycji opiera się na „ryzyku na transakcję”, plan musi definiować, co oznacza „ryzyko” (strata od jakiej ceny odniesienia do jakiego poziomu wyjścia) oraz czy odniesienie i wyjście są mierzone w ten sam sposób i w tym samym czasie. Jeśli logika ryzyka w planie zakłada jedno zachowanie wykonania (na przykład realizację po wyświetlonej cenie), ale rzeczywiste wykonanie może się różnić (na przykład poślizg), komponent określania wielkości pozycji staje się niedopasowany do komponentu zarządzania.
Ponieważ nie zakłada się tutaj żadnych danych rynkowych w czasie rzeczywistym, etap weryfikacji ma charakter koncepcyjny: powinieneś być w stanie wymienić każde założenie użyte w dowolnym obliczeniu, a następnie sprawdzić, czy to założenie jest stabilne w scenariuszach, które Cię interesują.
Stabilna mechanika a zmienne warunki
Oddziel komponenty, które są „mechanicznie stabilne”, od tych wrażliwych na zmieniające się warunki:
- Bardziej stabilna mechanika: zależności matematyczne i logika reguł, takie jak sposób obliczania wielkości pozycji z budżetu ryzyka.
- Bardziej zmienne warunki: wszystko, na co wpływają mikrostruktura rynku, jakość wykonania, opłaty i czas. Nawet bez danych na żywo możesz zidentyfikować, które części planu zależą od tych zmiennych czynników.
To rozdzielenie pomaga dostrzec, gdzie wymagana jest odporność. Na przykład, jeśli wynik komponentu w dużej mierze zależy od czasu i jakości wykonania, traktujesz go jako element wrażliwy, który wymaga jawnych ograniczeń.
Dowody i przykłady poprzez przypadki brzegowe wdrożenia
Żaden samodzielny przykład nie gwarantuje skuteczności, ale konkretne przypadki brzegowe wyjaśniają, jak komponenty planu mogą zawieść.
Przypadek brzegowy 1: obliczenia ryzyka wykorzystują niedopasowane jednostki
Załóżmy, że plan deklaruje ograniczenie strat poprzez użycie „kwoty ryzyka” wyrażonej w walucie konta. Plan wykorzystuje następnie instrument o innej strukturze kwotowania. Jeśli logika planu nie określa, w jaki sposób przeprowadzane są konwersje (i w jakim czasie), dwie różne implementacje mogą obliczyć różne ryzyko dla tego samego scenariusza.
Podejście weryfikacyjne jest następujące: każde obliczenie musi określać swoje jednostki i etapy konwersji. Jeśli plan pozostawia te etapy niejawnymi, nie może być niezależnie zweryfikowany.
Przypadek brzegowy 2: zasady komponentów są sprzeczne w wyjątkowych sytuacjach
Komponenty planu często określają, co dzieje się w normalnych warunkach, ale zaawansowani użytkownicy sprawdzają również wyjątki:
- Co jeśli warunek wejścia w planie zostanie spełniony, a późniejsze ograniczenie stanie się aktywne natychmiast po tym (na przykład dzienny limit)?
- Co jeśli zasada zarządzania wymaga aktualizacji wyjścia, ale odniesienie danych w planie jest nieaktualne lub opóźnione?
Nawet w czysto koncepcyjnym planie należy określić pierwszeństwo: gdy wiele zasad może mieć zastosowanie w tym samym czasie, która z nich wygrywa i jak plan przechodzi do następnego stanu.
Przypadek brzegowy 3: ukryte koszty zmieniają rzeczywiste ryzyko planu
Wiele planów koncentruje się na ruchu ceny, ale prawdziwy handel obejmuje koszty, takie jak opłaty i efekty związane ze spreadem. Plan koncepcyjny powinien określać, gdzie te koszty wchodzą do obliczeń, ponieważ w przeciwnym razie „ryzyko na transakcję” w planie może nie odzwierciedlać rzeczywistej straty.
Zaawansowane zagadnienie nie dotyczy konkretnej kwoty kosztów, ale ich umiejscowienia w logice: zdefiniuj, czy koszty są modelowane jako część odniesienia wejścia, odniesienia wyjścia, czy potrącane osobno z budżetu ryzyka.
Przypadek brzegowy 4: wyrównanie czasowe między komponentami
Jeśli jeden komponent używa ceny próbkowanej w czasie T1, a inny komponent używa ceny próbkowanej w czasie T2, należy rozważyć, czy różnica ma znaczenie. W szybko zmieniających się warunkach małe niedopasowania czasowe mogą powodować duże różnice w obliczonym ryzyku i ocenie zasad.
Etap weryfikacji polega na sporządzeniu harmonogramu dla planu: kiedy każdy komponent obserwuje dane wejściowe, kiedy wydaje decyzje i kiedy zakłada zmiany stanu.
Ograniczenia i ryzyka: co może pójść nie tak i jak to zweryfikować
Istotne ograniczenie: wyniki różnią się w zależności od warunków rynkowych i wdrożenia
Nawet logicznie spójny zestaw komponentów planu może dawać różne wyniki w różnych reżimach rynkowych. Historyczne zależności nie stanowią podstawy do przewidywania przyszłych wyników, a rzeczywiste zachowanie planu zależy od warunków rynkowych, kosztów, jakości wykonania i jurysdykcji.
Tryb awarii: zasady, które nie są faktycznie wykonalne
Plan może zawierać złożone warunki, które nie są wiarygodnie obserwowalne w docelowym środowisku. Zaawansowani użytkownicy traktują wykonalność jako wymóg: każdy komponent musi być testowalny przy użyciu danych wejściowych dostępnych planowi w wymaganych momentach.
Tryb awarii: weryfikacja przeprowadzana jest na niewłaściwym poziomie szczegółowości
Sprawdzanie tylko końcowego wyniku całego planu ukrywa problemy z komponentami. Niezależna weryfikacja powinna badać każdy komponent pod kątem:
- Danych wejściowych: jakich informacji wymaga.
- Założeń: co musi być spełnione, aby logika odpowiadała zamierzonemu znaczeniu.
- Znaczenia wyniku: jaką zmianę stanu tworzy.
- Kompatybilności: jak łączy się z założeniami innych komponentów.
Co możesz niezależnie zweryfikować (bez polegania na prognozach)
Możesz zweryfikować następujące elementy faktyczne bez danych w czasie rzeczywistym:
- Wewnętrzną spójność planu: czy jednostki i punkty odniesienia każdej zasady są zgodne między komponentami.
- Zasady pierwszeństwa: co się dzieje, gdy ograniczenia i zasady decyzyjne nakładają się.
- Przejrzystość obliczeń: czy jakakolwiek matematyka dotycząca wielkości pozycji lub ryzyka jest w pełni określona.
- Odporność na wyjątki: czy plan określa zachowanie, gdy wymagane informacje są nieobecne lub opóźnione.