# Ausfüllbare Broker-Checkliste

Diese Vorlage kann direkt als Markdown kopiert und intern ausgefüllt werden.

> Tipp: Hinter jede Checkbox kann bei Bedarf ein kurzer Status ergänzt werden, z. B. `([Owner], [Datum], [Kommentar])`.

## Basisinformationen

- [ ] Brokername:
- [ ] Technischer Ansprechpartner (Name, E-Mail, Teams/Slack):
- [ ] Integrationsszenario festgelegt (`A = bestehende API`, `B = neue API`):

## Branding & Assets

- [ ] Logo als SVG (oder alternatives Format) bereitgestellt
- [ ] Logo-Variante für helle Hintergründe vorhanden
- [ ] Logo-Variante für dunkle Hintergründe vorhanden (falls verfügbar)
- [ ] Lange Logo-Version (Wortmarke + Icon) vorhanden
- [ ] Quadratische Version/Icon vorhanden

## Technische Ressourcen

### Szenario A (bestehende API)

- [ ] OpenAPI/Swagger-Datei geteilt
- [ ] Postman-Collection oder äquivalente API-Dokumentation geteilt
- [ ] Auth-Details dokumentiert (Auth-URL, Token-Endpunkt, Client-Setup)

### Szenario B (neue API)

- [ ] Umsetzungsumfang gegen [API Referenz](/guides/broker-integration/api/login) festgelegt
- [ ] Geplante Abweichungen dokumentiert

## Konfigurationsdaten

- [ ] Unterstützte Order-Modelle dokumentiert (z. B. Limit, Stop, Trailing Stop)
- [ ] Unterstützte Gültigkeitstypen dokumentiert (z. B. GFD, GTC)
- [ ] Exchange-Map bereitgestellt (IDs, Codes, Anzeigenamen)
- [ ] Compliance-/Risikohinweise bereitgestellt
- [ ] Lagerstellen-Logik dokumentiert (IDs/Kürzel inkl. lesbarer Labels)

## API-Mapping & Feature-Support

### Authentifizierung & Freigaben

- [ ] Session-TAN-Verhalten beschrieben
- [ ] Alternative Freigabeverfahren dokumentiert

### Datenabfrage & Performance

- [ ] Paginierung für große Listen geklärt
- [ ] Datumsfilter verfügbar und dokumentiert
- [ ] Historische Tiefe der Order-Historie geklärt
- [ ] API-Besonderheiten/Einschränkungen dokumentiert (z. B. keine parallelen Requests möglich, strikte Rate-Limits, sequentielle Verarbeitung)

### Order-Funktionalitäten

- [ ] Unterstützte Order-Typen aufgelistet
- [ ] Verhalten für `ChangeOrder` / Storno+Neuanlage geklärt
- [ ] Unterstützte `validityTypes` dokumentiert
- [ ] Teilausführungen inkl. Datenquelle/Endpunkt dokumentiert
- [ ] Bruchstückhandel inkl. Einschränkungen dokumentiert

### Datenformate & Standards

- [ ] Zeitstempel-Format dokumentiert (bevorzugt ISO 8601 in UTC)
- [ ] Währungen gemäß ISO 4217 geklärt
- [ ] Zahlenformate ohne Float-Rundungsprobleme geklärt

### Fehlerbehandlung

- [ ] Nutzung von HTTP-Statuscodes abgestimmt (`400`/`401`/`422` etc.)
- [ ] Error-Response-Struktur dokumentiert
- [ ] Verfügbarkeit übersetzter Fehlermeldungen geklärt
- [ ] Fehlercode-Liste mit Textvorschlägen bereitgestellt (falls nötig)

### Erweiterte Features

- [ ] Unterstützung für Spezial-Assets (z. B. Crypto) geklärt
- [ ] Gebühren-/Steuerinformationen in Orderdaten geklärt

## Testzugang

- [ ] Sandbox-Zugang bereitgestellt
- [ ] Mindestens ein Testaccount bereitgestellt
- [ ] Testaccount: Standardszenario mit Beständen/Cash vorhanden
- [ ] Testaccount: Fremdwährungsszenario vorhanden
- [ ] Testaccount: Spezial-/Compliance-Szenario vorhanden

## Abschluss

- [ ] Offene Punkte markiert und priorisiert
- [ ] Nächster Abstimmungstermin vereinbart
- [ ] Abgleich mit [technischen Mindestanforderungen](/broker-integration/requirements) abgeschlossen