koreainvestment/open-trading-api: KIS Open API als Beispielsammlung mit Backtester und MCP-Anbindung

Was das Repository liefert und was es ausdrücklich nicht ist

Die README beginnt mit einer Haftungsabgrenzung, die man ernst nehmen sollte: Die Beispiele dienen der Veranschaulichung, können ohne Ankündigung aktualisiert werden, und für Schäden aus Programmen, die auf ihrer Grundlage entstehen, übernimmt das Unternehmen keine Verantwortung. Das ist keine Formalie, sondern beschreibt den Charakter des Ganzen. Wer hier nach einer gepflegten Bibliothek mit versionierten Releases sucht, sucht am falschen Ort. Es handelt sich um Referenzcode für die Schnittstelle von Korea Investment & Securities, gegliedert nach zwei Zielgruppen: examples_llm für Agenten, die eine einzelne Funktion nachschlagen und aufrufen, und examples_user für Menschen, die produktnah arbeiten. Dazu kommen strategy_builder, backtester und ein MCP-Verzeichnis. Die Zielgruppe ist damit enger, als die Themenliste vermuten lässt: Entwickler mit Konto bei diesem Broker, die Python schreiben und entweder die API erlernen oder eine vorhandene Integration strukturell verbessern wollen.

Zwei Beispielbäume mit unterschiedlicher Granularität

Der interessanteste Entwurf liegt in der Aufteilung. In examples_llm bekommt jede einzelne API-Funktion einen eigenen Ordner, etwa domestic_bond/inquire_price, und darin liegen zwei Dateien: inquire_price.py als minimale Aufrufdatei und chk_inquire_price.py zur Prüfung des Ergebnisses. Diese Zwei-Datei-Konvention ist auf Kontextfenster zugeschnitten. Ein Agent muss nicht eine Datei mit hunderten Funktionen durchsuchen, sondern liest eine kurze Datei mit genau dem Aufruf, der gebraucht wird. In examples_user liegt derselbe Funktionsumfang anders sortiert: pro Produktkategorie eine Datei domestic_bond_functions.py mit allen REST-Funktionen, dazu domestic_bond_examples.py als Ausführungsbeispiel sowie die WebSocket-Pendants mit dem Suffix _ws. Beide Bäume decken dieselben acht Kategorien ab: auth, domestic_stock, domestic_bond, domestic_futureoption, overseas_stock, overseas_futureoption, elw und etfetn. Wer den Code liest, um eine eigene Anwendung zu bauen, wird in examples_user schneller fündig; wer eine einzelne Funktion verstehen will, in examples_llm. Diese Trennung ist der eigentliche Beitrag des Repositories zur Frage, wie man API-Beispiele für maschinelle und menschliche Leser gleichzeitig bereitstellt.

Authentifizierung, Konfigurationspfad und der Umweg über ~/KIS/config

Die gemeinsame Authentifizierung liegt in kis_auth.py, das in beiden Beispielbäumen vorhanden ist. Laut README übernimmt es die Ausgabe und Verwaltung des Zugriffstokens, gemeinsame Aufruffunktionen, die Umschaltung zwischen Simulations- und Echtgeldumgebung sowie die WebSocket-Konfiguration. Für die WebSocket-Seite existiert zusätzlich auth_ws_token, das einen separaten Verbindungsschlüssel ausgibt, getrennt vom REST-Token in auth_token. Die Zugangsdaten liegen nicht im Repository, sondern in kis_devlp.yaml. Der dokumentierte Standardpfad ist ~/KIS/config/kis_devlp.yaml, und die README empfiehlt ausdrücklich, die Datei aus dem Projektwurzelverzeichnis dorthin zu kopieren und erst dann zu bearbeiten. Wer den Pfad ändern will, passt den Wert config_root in kis_auth.py an. Das ist ein Detail mit Folgen: Die Konfiguration liegt außerhalb des geklonten Verzeichnisses, damit App-Key und App-Secret nicht versehentlich in einem Commit landen. Für den Einstieg werden getrennte Schlüssel für Simulations- und Echtgeldbetrieb verlangt, die über das Portal beantragt werden müssen. Ohne diese Freischaltung läuft keines der Beispiele.

Einrichten mit uv und der erste Aufruf

Die Installation ist knapp gehalten. Vorausgesetzt wird Python 3.11 oder neuer, als Paketmanager empfiehlt die README uv. Dessen Installation erfolgt unter Windows über powershell -c "irm https://astral.sh/uv/install.ps1 | iex", unter macOS und Linux über curl -LsSf https://astral.sh/uv/install.sh | sh, die Prüfung über uv --version. Danach folgen git clone https://github.com/koreainvestment/open-trading-api, cd open-trading-api und uv sync, das die Abhängigkeiten aus pyproject.toml und uv.lock auflöst. Anschließend wird die Konfiguration mit mkdir -p ~/KIS/config und cp kis_devlp.yaml ~/KIS/config/ an den erwarteten Ort gebracht und um die eigenen Schlüssel ergänzt. Auffällig ist, was hier fehlt: Es gibt keinen dokumentierten Einzelbefehl zum Start eines Beispiels, etwa in der Form python examples_user/domestic_stock/domestic_stock_examples.py. Die README beschreibt die Dateikonventionen, nennt aber kein konkretes Ausführungskommando für die Beispiele. Wer das Repository einsetzt, muss diesen Schritt aus der Struktur selbst ableiten. Auch eine Liste der Abhängigkeiten aus pyproject.toml wird im Material nicht wiedergegeben.

Strategie-Builder, .kis.yaml und der Backtester im Container

Neben den Beispielen beschreibt die README eine Kette aus Strategieentwurf, historischer Prüfung und Orderausführung. Der strategy_builder dient dem Entwurf über eine grafische Oberfläche und erzeugt Signale in den drei Zuständen BUY, SELL und HOLD; genannt werden 80 technische Indikatoren und zehn vordefinierte Strategien, von Golden Cross über 52-Wochen-Hoch und Mean Reversion bis zu einem Trendfilter. Der backtester nutzt QuantConnect Lean und läuft laut README Docker-basiert, mit HTML-Berichten als Ergebnis. Das Bindeglied ist das Format .kis.yaml: Ein im Builder entworfene Strategie wird in dieser Datei exportiert und im Backtester wieder importiert, sodass beide Seiten dieselbe Strategiedefinition lesen. Die zehn Presets sind in beiden Verzeichnissen identisch hinterlegt. Der Ablauf ist damit nicht nur dokumentiert, sondern über ein gemeinsames Dateiformat technisch verkoppelt. Für einen Bewertungstext ist das der belastbarste Teil des Repositories, weil er eine überprüfbare Schnittstelle zwischen zwei Werkzeugen definiert. Ob die Backtest-Ergebnisse belastbar sind, hängt allerdings an den historischen Daten, die das Material nicht benennt.

MCP, llms.txt und die Frage, was ein Agent hier wirklich kann

Das Repository adressiert Sprachmodelle auf drei Ebenen. Erstens über llms.txt im Wurzelverzeichnis, das als Wegweiser für Assistenten gedacht ist. Zweitens über die Ordnerstruktur in examples_llm. Drittens über das Verzeichnis MCP, das laut README einen KIS Code Assistant und ein Trading MCP enthält. Die Trennung ist sinnvoll, weil sie unterschiedliche Aufgaben abdeckt: llms.txt hilft bei der Orientierung, examples_llm beim Nachschlagen eines Aufrufs, MCP bei der Anbindung als Werkzeug. Unklar bleibt, was das Trading MCP im Einzelnen freigibt und wie die Authentifizierung dort geführt wird. Die README verweist für Details auf MCP/README.MD, ohne den Inhalt wiederzugeben. Wer eine automatisierte Orderausführung über einen Agenten plant, sollte diesen Punkt zuerst prüfen, denn die Verantwortungsabgrenzung der README deckt Schäden aus dem eigenen Programm ausdrücklich nicht ab. Die Themenliste des Repositories nennt ai-trading und autotrade, die dokumentierte Grundlage bleibt aber bei Beispielcode und Werkzeuganbindung.

Grenzen: keine Release-Historie, keine Lizenzangabe, keine Bibliotheksgarantie

Drei Einschränkungen sind aus dem Material direkt ableitbar. Erstens existiert keine abrufbare Release-Historie. Es gibt keinen versionierten Stand, an dem man eine Integration festmachen könnte; die README sagt selbst, dass die Beispiele ohne Ankündigung aktualisiert werden können. Wer den Code als Grundlage einer Handelsanwendung nutzt, muss mit Änderungen rechnen, die er nicht kontrolliert. Zweitens fehlt eine Lizenzangabe. Ohne sie ist unklar, ob angepasste Dateien weitergegeben oder in ein eigenes Produkt übernommen werden dürfen. Das ist kein Nebenaspekt, sondern betrifft jede kommerzielle Nutzung, und die Klärung ersetzt keine Rechtsberatung. Drittens ist die Struktur selbst eine Fehlerquelle: Der Konfigurationspfad ~/KIS/config/kis_devlp.yaml liegt außerhalb des Repositories, und die Umschaltung zwischen Simulations- und Echtgeldbetrieb erfolgt über getrennte Schlüssel in dieser Datei. Ein falsch gesetzter Schlüssel führt nicht zu einem Syntaxfehler, sondern zu Orders in der falschen Umgebung. Ein weiterer Punkt: Der Backtester setzt Docker und QuantConnect Lean voraus, was den Einstieg deutlich schwerer macht als das reine Durchsehen eines REST-Beispiels.

Alternative: offizielle Client-Bibliotheken statt Referenzcode

Der naheliegende Vergleich sind eigenständige Python-Bibliotheken für Broker-Schnittstellen, wie sie für andere Handelsplätze existieren. Der Unterschied liegt nicht im Funktionsumfang, sondern im Vertragsverhältnis. Eine Client-Bibliothek kapselt Endpunkte, Fehlerbehandlung und Token-Erneuerung hinter stabilen Funktionssignaturen und wird üblicherweise versioniert, sodass ein Update eine bewusste Entscheidung ist. Dieses Repository geht den umgekehrten Weg: Es zeigt die Aufrufe offen, damit man sie liest und anpasst. Die Token-Verwaltung in kis_auth.py ist genau deshalb sichtbar, weil sie als Lehrmaterial gedacht ist. Für einen Prototyp oder zum Verstehen der KIS-Endpunkte ist das ein Vorteil. Für eine Anwendung, die über Monate läuft und bei einer Änderung der Schnittstelle nicht brechen soll, ist es ein Nachteil, weil die Anpassung bei jedem Nutzer liegt. Wer bereits eine eigene Anbindung pflegt, findet hier vor allem die Kategorienaufteilung und die Zwei-Datei-Konvention als Anregung, nicht eine Ablösung des eigenen Codes.

Redaktionelles Fazit

Sinnvoll ist das Repository für Python-Entwickler mit einem Korea-Investment-Konto, die REST- und WebSocket-Aufrufe der KIS-Schnittstelle kennenlernen wollen, und für Teams, die den .kis.yaml-Weg vom Strategie-Builder in den Docker-Backtester ausprobieren möchten. Wer eine versionierte Client-Bibliothek mit SemVer-Garantie braucht, sollte zuerst prüfen, ob die KIS-Portal-Dokumentation oder eine eigenständige Bibliothek diesen Bedarf deckt. Vor dem ersten Einsatz ist zu klären, ob die Lizenz des Repositories eine Weitergabe angepasster Dateien erlaubt; dazu enthält das Material keine Angabe.

Offizielle Quellen

1. Issues
2. koreainvestment/open-trading-api on GitHub
3. Project website
4. README