IBKRTrader/docs/Kapital-und-Buchmodell.md

Kapital- und Buchmodell

Status: Konzept (2026-08-03) – noch nicht implementiert. Dieses Dokument beschreibt, wie mehrere Strategien gleichzeitig auf einem IBKR-Konto mit einem Guthaben arbeiten können, ohne sich gegenseitig zu stören, und wie das gegen die steuerliche Buchführung abgegrenzt ist. Es dient als Referenz, gegen die die spätere Umsetzung geprüft wird.

0. Problemstellung und Abgrenzung

TWS lässt sich pro Rechner nur einmal betreiben – wir sind an ein Konto mit einem Guthaben gebunden. Trotzdem sollen mehrere Strategie-Module parallel handeln. Daraus folgen vier Anforderungen:

1. Jedes Modul bekommt eine klar begrenzte Kapitalmenge, die es binden darf.
2. Jede Position hat einen eindeutigen Eigentümer. Kein Modul darf die Position eines anderen Moduls oder eine manuell angelegte Position anfassen.
3. Das Konto darf durch Modul-Handel niemals ins Minus oder in Margin laufen.
4. Die steuerliche Buchführung ist davon vollständig unabhängig und muss zu 100 % stimmen.

Nicht Gegenstand dieses Dokuments: Strategielogik, Signalerzeugung, Marktdatenversorgung.

---

1. Die drei Wahrheiten

Es gibt drei Datenquellen mit unterschiedlicher Autorität. Sie dürfen sich nicht vermischen.

Ebene	Quelle	Autoritativ für	Latenz
Steuerbuch (acc_)	Flex Query	Geld, Steuer, GuV – alles gegenüber der Steuerbehörde	T+1
Depot-Ist	TWS-API-Snapshot	Was jetzt real im Konto liegt	Sekunden
Managementbuch (core_)	eigene Order-Events + Abgleich	Zuordnung von Positionen zu Büchern	live

Harte Regel: Das Managementbuch beeinflusst das Steuerbuch niemals – weder korrigierend noch ergänzend. Der Accounting-Ingest liest Flex Query, klassifiziert und bucht; ob dabei eine BookId bekannt ist, ist ihm gleichgültig. Die Modulzuordnung ist eine optionale, nicht-autoritative Beistelltabelle (Flex-Trade-ID ↔ BookId). Fehlt sie oder ist sie falsch, ändert sich am Steuerergebnis exakt nichts.

Umgekehrt gilt: Das Managementbuch bezieht Korrekturen aus dem Steuerbuch (Gebühren, Dividenden, Splits), nie andersherum.

---

2. Bücher (Books)

Ein Buch ist ein Kapitaltopf mit zugeordneten Positionen. Bücher sind:

Buch	Bedeutung	Handelt	Limits gelten
je Strategie (CT, …)	ein Modul, ggf. ein Parametersatz	ja	ja
MANUAL	von Hand in TWS/IBKR angelegt	nein (nur extern)	nein, zählt aber mit
UNASSIGNED	am Broker gefunden, keinem Buch zugeordnet	nein	zählt mit
HOUSE	nicht allokierte Reserve, FX, Ausgleichsposten	nein	–

BookId ist ein eigenes Konzept, nicht der Modulname. Default BookId == Modulname, aber die Trennung erlaubt später mehrere Bücher desselben Moduls und macht MANUAL/UNASSIGNED/HOUSE sauber modellierbar. Jetzt kostenlos, später teuer nachzurüsten.

Eigentumsregeln (im Core erzwungen, nicht per Konvention)

1. Ein Verkaufssignal von Buch b kann nur Positionen von b reduzieren, gedeckelt auf Menge(b, Symbol). Darüber hinaus wird gekappt – niemals wird ein Short erzeugt.
2. MANUAL und UNASSIGNED senden keine Signale und empfangen keine.
3. Ein Modul kann seine BookId nicht selbst wählen. Sie stammt aus der Modul-Registrierung und wird serverseitig gesetzt; TradeSignal.SourceModule aus dem Modul ist nicht vertrauenswürdig.
4. Module bekommen IBrokerClient nicht per DI – ausschließlich IExecutionService. Sonst ist die gesamte Buchführung umgehbar.
5. Ein Kill-Switch/Supervisor darf alles liquidieren – als explizite Core-Autorität mit eigener Konfiguration, standardmäßig unter Ausschluss von MANUAL.

---

3. Kapitalmodell: ein Pool, Obergrenzen

Es gibt keinen Kapitaltransfer zwischen Büchern. Kein Buch-Cash, keine Rebalancing-Läufe, keine Ausgleichsforderungen. Stattdessen ein gemeinsamer Cash-Pool und pro Buch eine Obergrenze:

Verteilbar   = FreiesCash(gehaircuttet) + Σ Modul-Positionswert − HouseReserve

Cap(b)       = konfigurierter Anteil × Verteilbar        (Default: Gleichverteilung)
Gebunden(b)  = Marktwert der Positionen von b + offene Reservierungen von b
Headroom(b)  = min( Cap(b) − Gebunden(b),  freies Pool-Cash )

Eigenschaften, die bewusst so sind

• Gewinne verteilen sich von selbst. Realisiert ein Buch einen Gewinn, wächst der gemeinsame Pool; da alle Caps aus Verteilbar abgeleitet werden, steigt der Headroom aller Bücher. Diversifikation ohne einen einzigen Zwangsverkauf.
• Ein Buch darf über seinem Cap liegen. Steigen die Positionen im Wert, passiert nichts – außer dass nicht mehr nachgekauft werden darf. Der Zustand „über Cap" ist legal, wird angezeigt und gemeldet, aber nie geheilt. Es wird niemals eine Position geschlossen, nur um eine Zielquote herzustellen.
• Σ Caps ≤ 100 % − Reserve wird beim Start validiert. Sonst könnte ein schnelles Buch ein langsames aushungern („wer zuerst kommt").
• Die Modul-Welt sieht nie den NAV, sondern nur ihr eigenes Kapital plus freies Cash. Manuelle Positionen – auch kreditfinanzierte – sind eine Black Box, die nur über das freie Cash wirkt.

Kapitalführung ≠ Performance-Messung

Die Kapitalführung ist ein Pool plus Caps. Die GuV pro Buch ist eine reine Auswertung über die Trade-Historie (für Supervisor und Reporting) und steuert nichts. Diese Entkopplung ist beabsichtigt.

---

4. Keine Margin – die Sperre

Modul-Handel ist strikt cash-only. Manueller Handel darf Margin nutzen. Der Kontotyp ist Cash-Konto; brokerseitig kann trotzdem Margin verfügbar sein, deshalb ist die Software-Sperre zwingend und testpflichtig.

Schicht A – richtige Bemessungsgrundlage

BuyingPower und AvailableFunds sind auf einem Margin-Konto bereits gehebelt gerechnet und als Basis unbrauchbar. Maßgeblich ist:

FreiesCash = min(TotalCashValue, AvailableFunds) − HouseReserve − Σ offene Reservierungen

TotalCashValue ist das echte Bargeld. Eröffnest du manuell eine Margin-Position, sinkt es, und die Modul-Kaufkraft schrumpft automatisch mit. Bei TotalCashValue ≤ 0 ist die Modul-Kaufkraft null – ohne Sonderlogik. Module können einen manuellen Kredit strukturell nicht ausweiten.

Schicht B – kein Short

Verkäufe werden auf die Buchmenge gekappt. Shorts sind implizit Margin.

Schicht C – Währung

Ein Kauf in Währung X darf nur aus Cash in Währung X finanziert werden. Andernfalls entsteht ein Sollsaldo in X – ein Margin-Kredit, auch wenn das Konto in Summe positiv aussieht. Buch-Cash und Reservierungen werden deshalb pro Währung geführt (siehe Abschnitt 7).

Schicht D – Watchdog

Ein Hosted Service prüft Cash und Margin-Kennzahlen laufend. Bei Unterschreitung: globaler Kauf-Stopp + Alarm – und niemals automatisches Verkaufen zur Heilung. Ein Selbstheilungs-Amoklauf ist gefährlicher als der Zustand, den er beheben soll.

---

5. Reservierungen (Order-Lebenszyklus)

Verhindert, dass zwei Module gleichzeitig dasselbe Geld ausgeben. Persistent in der DB, nicht im RAM.

INTENT → RESERVED → SUBMITTED → FILLED | PARTIAL | CANCELLED | REJECTED | EXPIRED

• Reservierungshöhe: Menge × Referenzpreis × (1 + Puffer) + geschätzte Kommission. Puffer klein bei Limit-Orders (das Limit ist die Obergrenze), größer bei Market (Slippage), zusätzlich FX-Puffer bei währungsübergreifenden Vorgängen.
• Atomar gegen Buch-Headroom und Pool-Cash, in einer DB-Transaktion hinter einem globalen Order-Lock. Bei einer TWS-Verbindung reicht ein einfacher SemaphoreSlim; feingranulare Locks wären hier nur eine zusätzliche Fehlerquelle.
• Freigabe beim Terminalzustand; Differenz zwischen Reservierung und echtem Fill fließt zurück.
• TTL zwingend. Erreicht eine Reservierung ohne Terminalzustand ihr Ablaufdatum oder den Handelsschluss → Alarm, keine stille Freigabe. Eine hängende Order, deren Reservierung freigegeben wird, gibt das Geld zweimal aus.
• Idempotenz über SignalId bzw. eine Client-Order-ID, damit ein Reconnect keine Doppelorder erzeugt.
• Crash-Recovery: beim Start alle nicht-terminalen Reservierungen gegen die offenen Broker-Orders abgleichen; Waisen → Quarantäne + Alarm.

---

6. Limits und Feedback an die Module

Konzentrationslimit pro Einzelwert

SymbolExposure(s) = Σ_b Marktwert(b, s)              ← über ALLE Bücher, inkl. MANUAL
Prüfung: SymbolExposure(s) + geplanter Kauf ≤ MaxSymbolPercent × NAV

• NAV als Nenner, nicht der Positionswert – sonst wird das Limit bei viel Cash absurd eng und bei wenig Cash absurd weit.
• MANUAL ist von der Prüfung befreit, zählt aber voll in den Zähler. Hältst du 50 % AAPL von Hand, sind die Module bei AAPL vollständig gesperrt. So gewollt.
• Verkäufe sind nie limitiert. Ein Limit darf niemals das Schließen einer Position verhindern.

Feedback-Kontrakt

Das Gate ist hart. Das Modul entscheidet nur, wie es auf die Ablehnung reagiert – nicht, ob das Limit gilt. Ein erneut gesendetes zu großes Signal wird wieder abgelehnt. Der Core trimmt nicht selbstständig; die Entscheidung liegt auf Strategieebene.

record LimitBreach(
    LimitKind Kind,        // SymbolConcentration | BookCap | CashAvailable
                           // | FxBuffer | CurrencyNotAllowed | VenueNotAllowed
    string    Scope,       // "AAPL" | "CT" | "USD"
    decimal   Current,
    decimal   Limit,
    int       MaxQuantity, // was jetzt noch ginge
    decimal   MaxNotional);

Ergänzend eine Vorab-Query GetHeadroom(book, symbol), damit ein gut gebautes Modul gar nicht erst gegen die Wand fährt und seine Order gleich richtig dimensioniert.

Drossel: Ein Modul, das dasselbe Signal wiederholt gegen dieselbe Wand schickt, wird nach N Versuchen pro SignalId gedämpft und protokolliert. Sonst produziert eine schlecht geschriebene Strategie Logfluten und TWS-Last.

---

7. Währungen und Handelsplätze

Kontobasiswährung: konfigurierbar, bei Ersteinrichtung festgelegt, danach gesperrt (siehe Abschnitt 11 – eine Änderung nach dem ersten Trade macht alle historischen Bewertungen, Caps und GuV-Zahlen ungültig).

• Produktion (US LLC): USD
• Test/Paper (EU): EUR

Contract-Auflösung ist Pflicht

Eine Order mit nacktem Symbol-String über SMART kann bei mehrdeutigen Tickern still an einer Börse in einer anderen Währung landen. Deshalb:

• Vor jeder Order wird der Contract über reqContractDetails aufgelöst; currency, exchange, primaryExchange und conId werden geprüft.
• Whitelist auf zwei Achsen: Währung ∈ AllowedCurrencies und Handelsplatz ∈ konfigurierter Liste. Verstoß → harte Ablehnung, unabhängig vom Modul.
• Das Ergebnis wird gecacht; die conId wird in der Position gespeichert. Sie ist IBKRs eindeutige Instrumenten-ID und deutlich sicherer als ein Ticker.

FX-Marge als Sicherheitspuffer, nicht als Exposure-Deckel

Bei überwiegendem Handel in Kontobasiswährung wäre ein FX-Exposure-Limit meist verletzt und damit nutzlos. Sinnvoll wirkt die Marge an drei anderen Stellen:

1. Bewertungs-Haircut: Fremdwährungs-Cash geht mit Abschlag in Verteilbar ein → das eigene Kapital wird nie überschätzt.
2. Reservierungspuffer bei währungsübergreifenden Käufen, zusätzlich zum Slippage-Puffer.
3. FX-Exposure als Kennzahl mit Alarmschwelle – sichtbar und meldepflichtig, ohne Handelssperre.

Kein Auto-FX im Order-Pfad

Fehlt Cash in der Zielwährung, scheitert der Modul-Kauf mit LimitKind.CashAvailable. Konvertiert würde der Order-Pfad selbst, könnte ein Modul indirekt FX-Kosten und FX-Timing auslösen, und die Reservierungslogik müsste zwei Währungen gleichzeitig sperren. FX bleibt ein expliziter Vorgang auf HOUSE-Ebene.

---

8. Abgleich (Reconciliation)

Weil jederzeit manuell in TWS eingegriffen werden kann, ist der Abgleich kein Zusatz, sondern das Fundament. Zwei Stufen:

Stufe 1 – Ledger ↔ TWS (minütlich): Handelssicherheit. Stimmen Stückzahlen und Cash?

Befund	Bedeutung	Reaktion
Broker > Ledger	manuell gekauft, oder ein Fill kam nach	Überschuss → UNASSIGNED
Broker < Ledger	manuell verkauft / Corporate Action	Break: betroffene Bücher und Symbol für neue Orders sperren, Alarm
Cash weicht ab	Gebühren, Zinsen, FX	Differenz gegen HOUSE, ab Schwelle Break

Bei „Broker < Ledger" wird bewusst nicht automatisch korrigiert. Anteiliges Wegkürzen zerstört die Zurechenbarkeit – Halt-and-alert, der Mensch entscheidet.

Stufe 2 – Ledger ↔ Flex Query (täglich, nach Ingest): Qualitätssicherung. Hier kommen Gebühren, Dividenden, Quellensteuer, FX-Differenzen und Splits an – Dinge, die die TWS-API gar nicht oder schlecht liefert.

Gebühren gehören dem verursachenden Buch. Sonst subventioniert HOUSE die vieltradenden Module und die Performance-Zahlen lügen. Beim Fill wird geschätzt, beim Flex-Abgleich exakt nachjustiert.

---

9. Unzugeordnete Positionen und Eskalation

Zustände: New → Notified → Acknowledged → Assigned(Book), mit DetectedAt-Zeitstempel.

• Ein Watchdog meldet alles, was länger als 30 Minuten unbearbeitet liegt.
• Backoff: nach 30 min, dann 2 h, dann täglich – sonst wird der Kanal unbrauchbar.
• Abgestufte Sperrwirkung: Eine UNASSIGNED-Position zählt voll in Exposure und Konzentrationslimit, bremst die Module also automatisch, sperrt aber nicht hart. Hart gesperrt wird nur der gefährliche Fall aus Abschnitt 8 (Broker < Ledger).

---

10. Benachrichtigungen

Im Code existiert derzeit kein Benachrichtigungssystem (die Treffer zu „Notification" im Supervisor-MCP sind JSON-RPC-Notifications, etwas anderes). Sauberer Start.

INotificationSink     Name, SendAsync(Notification, ct)
Notification          Severity, Category, Title, Body, DedupKey, Data
NotificationService   Fan-out über alle registrierten Sinks

Drei Eigenschaften müssen von Anfang an drin sein, weil sie später schwer nachzurüsten sind:

• Outbox in der DB (core_notification): erst persistieren, dann zustellen, Retry bei Fehler. Solange kein Zielkanal existiert, sammeln sich Meldungen sichtbar an und werden zugestellt, sobald ein Sink da ist. Nichts geht verloren.
• Dedup/Throttling über DedupKey (z. B. unassigned:AAPL).
• Severity-Routing: Info → Log/UI, Warning → Chat, Critical → alle Kanäle.

Ausbaureihenfolge: LogSink + UiSink sofort → MatrixSink, sobald der Server steht → TelegramSink optional als Backup.

Matrix ist reines HTTP, keine Library nötig: PUT /_matrix/client/v3/rooms/{roomId}/send/m.room.message/{txnId} mit dem Access-Token eines Bot-Users. Die txnId ist Matrix' eingebauter Idempotenz-Schlüssel und passt exakt auf die Outbox-ID. Das Token gehört in SecretProtection.

---

11. Steuerbuch: Jurisdiktionsprofil

Pro Deployment gibt es genau eine Jurisdiktion, und sie wechselt nie. Ein Kontowechsel zwischen Ländern findet nicht statt – die Option „später auch in Deutschland" bedeutet ausdrücklich: anderer Server, andere Datenbank, anderes IBKR-Konto. Daraus folgt: keine Migration, keine Mehrmandantenfähigkeit, kein Umschalten zur Laufzeit.

Das Profil ist kein Währungs-Flag, sondern ein Austausch der gesamten Lot- und Klassifikationslogik:

Aspekt	US LLC (Hauptziel)	DE privat (Option)	DE GmbH (Option)
Berichtswährung	USD, keine Umrechnung	EUR, Umrechnung pro Vorgang	EUR, Umrechnung pro Vorgang
Lot-Matching	FIFO Standard, Specific ID wählbar	FIFO zwingend	Bilanzierung
Wash Sale (30 Tage)	ja, Basis-Anpassung	kein Äquivalent	kein Äquivalent
Haltefrist	short/long term ab 1 Jahr	irrelevant	irrelevant
Verlustverrechnung	Carryforward mit Deckel	getrennte Töpfe	wieder anders
Quellensteuer	–	Anrechnung nach DBA	Anrechnung
Ausgabe	1099-B-Abgleich / K-1	Anlage KAP	Bilanz/GuV

Die Wash-Sale-Regel ist die einschneidendste: sie verändert Anschaffungskosten rückwirkend. Eine Engine, die nur FIFO kann, lässt sich dafür nicht nachrüsten. Deshalb muss die Lot-Verwaltung von Anfang an lot-basiert sein und Basis-Anpassungen als eigene Buchungsart kennen – auch wenn das erste Profil sie noch nicht nutzt.

Die konkreten steuerlichen Ausprägungen (u. a. ob die LLC als Disregarded Entity oder Partnership behandelt wird, was das Reporting ändert) sind mit dem Steuerberater abzustimmen. Hier steht nur, was die Software mechanisch abbilden können muss.

Profile und Umgebungen

Test/Paper (EU)    BaseCurrency EUR   TaxProfile None
Produktion (US)    BaseCurrency USD   TaxProfile UsLlc
Option DE          BaseCurrency EUR   TaxProfile DePrivat | DeGmbh

Das Profil None/Paper führt vollständig Buch, rechnet aber keine Steuer und ist in UI und allen Exporten sichtbar als solches markiert. Deutsche Steuerregeln auf Paper-Trades zu rechnen wäre sinnlos und produziert Zahlen, die jemand später für echt halten könnte.

Wo der Lock hingehört

Nicht in appsettings.json. Eine Datei lässt sich editieren, und dann rechnet die Engine ab morgen nach anderen Regeln über denselben Bestand – der schlimmstmögliche Fehler, weil er sich still auswirkt.

Der Lock gehört in die Datenbank, neben die Daten, die er regiert: eine Stempelzeile im Accounting-Schema mit Jurisdiktion, Berichtswährung, Kontobasiswährung und Einrichtungszeitpunkt. Beim Start wird die Konfiguration dagegen geprüft; bei Abweichung startet das Accounting-Modul nicht, sondern meldet einen Konflikt. Gesetzt wird der Stempel bei der Ersteinrichtung, geändert nur durch eine leere Datenbank.

Was deshalb nicht gebaut wird

Die EZB-Kursanbindung (Kursquelle, Stichtagsregeln, Kursarchivierung) ist für das Hauptziel nicht nötig: USD-Konto, USD-Reporting, keine Umrechnung. Also nur die Naht bauen (IFxRateSource, im US-Profil eine No-Op), nicht die Implementierung. Wird die DE-Option je gezogen, geschieht das ohnehin auf einem anderen Server – dann wird sie dort ergänzt.

Falls doch: EZB-Referenzkurse autoritativ, IBKR-Bewertungskurse nur als Kontrollgröße; verwendeter Kurs, Quelle, Stichtag und Abrufzeitpunkt werden mitgespeichert, nicht nur der umgerechnete Betrag.

---

12. Datenmodell-Deltas

Heute	Delta
core_position (PK Module+Symbol)	Module → BookId; ConId, Currency, Exchange ergänzen
core_budget (Total/Used/MaxPerTrade)	ersetzen durch core_book: Cap-Regel, Flags (ReadOnly, Active), Mindestordergröße
–	core_reservation (Zustandsmaschine, TTL, Währung)
–	core_broker_snapshot + core_reconciliation_break
–	core_notification (Outbox)
–	core_instrument (aufgelöste Contracts, conId-Cache, Whitelist-Status)
–	acc_jurisdiction (Stempel, Abschnitt 11)
Buch-Cash, Transfers, Rebalance-Lauf	entfällt – ein Pool plus Caps (Abschnitt 3)
RiskContext.NetLiquidation	→ Verteilbar und Headroom(b), nicht NAV
IbkrConnection: NetLiquidation,AvailableFunds	+ TotalCashValue, SettledCash, Margin-Kennzahlen, pro Währung
IBrokerClient	+ GetPositionsAsync, + ResolveContractAsync
ExecutionService (Check-then-Act ohne Lock)	Order-Gateway davor: Serialisierung + Reservierung
ExecutionResult.Reason (string)	+ strukturiertes LimitBreach (Abschnitt 6)

---

13. Invarianten und Testkatalog

Die No-Margin-Bedingung wird als eine ausführbare Invariante formuliert, die an drei Stellen dieselbe Codebahn nimmt:

∀ Währung c:  FreiesCash(c) ≥ 0
            ∧ Σ offene Reservierungen(c) ≤ FreiesCash(c)
∀ Buch b, Symbol s:  Menge(b, s) ≥ 0
∀ Symbol s:  Σ_b Menge(b, s) = BrokerMenge(s)

1. als Assert am Ende jedes Trading-Tests (gemeinsamer Testhelfer, nicht pro Test neu geschrieben)
2. als Property-Test über zufällige Sequenzen aus Reservierung / Fill / Teilfill / Cancel / Slippage / manuellem Eingriff
3. als Laufzeitprüfung im Watchdog – identische Implementierung, damit Test und Produktion nicht auseinanderlaufen

Pflichtfälle

Fall	Erwartung
Zwei parallele Reservierungen, zusammen > freies Cash	zweite abgelehnt
N nebenläufige Tasks (Stresstest)	Σ Reservierungen nie > freies Cash
Fill teurer als reserviert, innerhalb Puffer	ok, Restfreigabe korrekt
Fill jenseits des Puffers	Alarm, Cash bleibt ≥ 0
Manuelle Margin-Position taucht auf, Cash < Reserve	alle Modul-Käufe gesperrt
Cash in Zielwährung = 0, andere Währung vorhanden	abgelehnt – kein stiller Fremdwährungskredit
Verkaufssignal über Buchmenge hinaus	gekappt, kein Short
Reservierung erreicht TTL	Alarm, keine stille Freigabe
Neustart mit offenen Reservierungen	aus DB rekonstruiert, keine Doppelausgabe
Modul setzt fremde BookId im Signal	serverseitig überschrieben
Verkaufssignal gegen MANUAL	abgelehnt
Contract löst auf fremde Währung/Börse auf	abgelehnt vor Ordersendung

---

14. Bewusst verschoben

• Self-Cross-Netting (Modul A kauft, Modul B verkauft dasselbe Symbol gleichzeitig). Bei der erwarteten Handelsfrequenz unrealistisch und allenfalls eine Ausnahmeerscheinung. Billige Vorstufe jetzt: Ist im Order-Gateway eine gegenläufige Order für dasselbe Symbol pending, wird das protokolliert und gewarnt. Der Lock ist ohnehin da – das kostet fast nichts und liefert Daten darüber, ob das Problem je real wird.
• Corporate Actions (Splits, Spin-offs) in der Buchzuordnung – vorerst über den Flex-Abgleich als Break sichtbar, manuelle Zuordnung.
• Echte Sub-Accounts bei IBKR (Advisor/Family-Struktur) als brokerseitige Trennung. Erwogen und verworfen: erfordert Kontotypwechsel und feste Vorabaufteilung des Kapitals, deutlich unflexibler als virtuelle Bücher.

---

15. Offene Punkte

• Mindestordergröße pro Buch: ein Wert in Kontobasiswährung, Fremdwährungsorders per Tageskurs dagegen geprüft. Konkreter Wert beim Bauen festzulegen.
• Konkrete Limitwerte (MaxSymbolPercent, HouseReserve, FX-Haircut, Slippage-Puffer, TTL) – Startwerte beim Bauen festzulegen und in settings.example.json dokumentieren.
• Handelsplatz-Whitelist: konkrete Börsenliste je Währung.
• Umsetzungsreihenfolge – noch nicht besprochen.

---

Zusammenfassung der getroffenen Entscheidungen

#	Entscheidung
1	Cash-Konto; Modul-Handel strikt cash-only, manueller Handel darf Margin nutzen
2	Kein Kapitaltransfer zwischen Büchern – ein Pool plus Obergrenzen; niemals aktives Schließen zum Balancieren
3	Limit-Verletzung: hartes Gate, strukturiertes Feedback; die Reaktion entscheidet die Strategie
4	Kontobasiswährung USD (Produktion) / EUR (Test), bei Ersteinrichtung gesetzt und danach gesperrt
5	Nur USD und EUR handelbar; Contract-Auflösung mit Währungs- und Handelsplatz-Whitelist ist Pflicht
6	Steuerbuch strikt getrennt, Flex Query als einzige Quelle, Jurisdiktionsprofil einmalig und in der DB verankert
7	Unzugeordnete Positionen: Quarantäne + Eskalation nach 30 Minuten mit Backoff
8	Benachrichtigungen über Outbox + Sink-Abstraktion; Matrix als Zielkanal, Telegram optional