ITDRF ist als gemeinsame, regelbasierte Entscheidungs- und Ausführungsarchitektur für institutionelle Handelsforschung, Risikosteuerung und reproduzierbare Prüfungen angelegt. Im Mittelpunkt steht nicht eine einzelne Handelsidee, sondern ein konsistenter fachlicher Rechenweg, der Entscheidungen, Execution-Annahmen, Risiko und Nachweis voneinander unterscheidbar hält. Dadurch soll ein Prüfer erkennen können, wie eine Aussage zustande kommt und welche Voraussetzungen für ihre Gültigkeit gelten.
Plagge Consulting bereitet die vollständige Übertragung seines operativen Geschäftsbetriebs an einen strategischen Erwerber vor. Der technologische Schwerpunkt ist das eigenentwickelte Institutional Trading Decision & Risk Framework (ITDRF), ergänzt um dokumentierte Forschung, Entwicklungswissen und die dazugehörigen betrieblichen Zusammenhänge. Gegenstand der geplanten Transaktion ist damit nicht nur eine einzelne Softwarelizenz, sondern ein übertragbarer technischer und fachlicher Bestand, den ein Erwerber in die eigene institutionelle Umgebung übernehmen, vertieft prüfen und weiterentwickeln kann.
Forschung, Replay, Simulation und Risikobewertung orientieren sich an einer gemeinsamen Fachlogik, statt für jeden Arbeitsbereich eine eigene Version derselben Regel zu erzeugen. Der Gedanke dahinter ist einfach: Wenn eine fachliche Entscheidung unter identischen Voraussetzungen unterschiedlich ausfällt, nur weil sie in einer anderen Ansicht berechnet wurde, ist das Ergebnis nicht belastbar. Deshalb bleiben Handelsentscheidung, Ausführungsannahmen und Risikosteuerung zwar klar getrennte Verantwortungen, greifen aber auf denselben kanonischen Regelstand zurück.
Dieses Architekturprinzip beschreibt, wie ITDRF entwickelt und geprüft wird; es ist ausdrücklich kein Ersatz für noch ausstehende fachliche oder wirtschaftliche Validierung. Implementierte Software, bestandene technische Tests und ein sauberer Rechenweg beantworten andere Fragen als robuste Out-of-Sample-, Forward- oder Live-Prüfungen. Der öffentliche Auftritt trennt diese Ebenen deshalb bewusst voneinander, statt einen Entwicklungsstand als bereits vollständig abgenommene Handelslösung darzustellen.
Für die vorgesehenen Arbeitsabläufe soll dieselbe fachliche Regelbasis maßgeblich bleiben. Forschung, Replay, Simulation oder andere Ansichten dürfen deshalb nicht unbemerkt zu unterschiedlichen Antworten auf dieselbe fachliche Frage kommen. Wo Abweichungen notwendig oder noch nicht abschließend geklärt sind, werden sie als solche sichtbar gemacht, getestet und dokumentiert, statt sie durch Sonderlogik zu verdecken.
Eine fachlich richtige Handelsentscheidung ist noch kein belastbarer Ausführungsnachweis. Innerhalb eines Handelstags können die Reihenfolge von Kursereignissen, Ziel- und Stop-Berührungen, Break-even- oder Trailing-Anpassungen sowie Slippage und Kosten das Ergebnis wesentlich verändern. Diese Faktoren werden deshalb als eigenständiger Prüfgegenstand behandelt und nicht nachträglich aus einem Tagesergebnis hergeleitet.
Die Angriffsplanstrategie (APS) koordiniert für jedes Instrument einen operativen Hauptplan und ordnet darin Positionsstufen, Schutzmaßnahmen und Warnzustände. Sie soll damit eine vorhandene Handelsentscheidung in einen kontrollierten Handlungsrahmen übersetzen, ohne selbst zur zweiten Signalquelle zu werden. Übergeordnete Risikolimits und zentrale Schutzregeln bleiben davon unabhängig verbindlich und können den instrumentbezogenen Plan begrenzen oder übersteuern.
Ein Ergebnis wird nicht als losgelöste Zahl betrachtet, sondern zusammen mit seinem Entstehungskontext. Dazu gehören insbesondere der verwendete Datenstand, die maßgeblichen Regeln und Parameter, die Softwareversion, die Ausführungs- und Kostenannahmen sowie der konkrete Prüfumfang. Dadurch lässt sich später unterscheiden, ob zwei Ergebnisse tatsächlich vergleichbar sind oder lediglich ähnlich aussehen.
Die folgenden sechs Funktionsbereiche geben einem möglichen Erwerber eine verständliche Übersicht darüber, wie Daten, Forschung, Entscheidung, Ausführung, Risiko und Nachweis zusammenwirken. Sie beschreiben Verantwortungen und Übergaben auf fachlicher Ebene, ohne interne Modulgrenzen, konkrete Regelwerke oder geschützte Implementierungsdetails offenzulegen. Damit soll die Architektur verständlich werden, ohne die Kernmechanik der Software öffentlich reproduzierbar zu machen.
Marktinformationen werden nicht nur als Kurswerte übernommen, sondern mit ihrem zeitlichen Bezug, ihrer Herkunft und ihrem Qualitätsstatus betrachtet. Eingangskontrollen sollen erkennbare Datenfehler und widersprüchliche Zustände nicht stillschweigend in die Fachlogik weiterreichen. Zugleich bleibt die technische Verarbeitung klar von der rechtlichen Nutzbarkeit der jeweiligen Datenquelle getrennt: Eigene Software begründet keine zusätzlichen Rechte an fremden Marktdaten.
Analytische Methoden, Sequenzen und Marktstrukturen werden unter vorher festgelegten Regeln untersucht, damit ein beobachteter Effekt nicht erst im Nachhinein passend erklärt wird. Historische Befunde liefern dabei Kontext und Forschungswissen, sind aber nicht automatisch ein freigegebenes Handelssignal. Erst die Einordnung in den kanonischen Entscheidungsweg, die Kausalität des Informationsstands und die jeweils erforderliche Validierung bestimmen, welche Aussage tatsächlich zulässig ist.
Der gemeinsame Core bewertet Richtung, Voraussetzungen und Freigaben anhand der jeweils gültigen Regeln und ausschließlich mit dem Informationsstand, der zum Entscheidungszeitpunkt verfügbar war. Damit soll verhindert werden, dass spätere Kursinformationen oder nachträglich veränderte Parameter rückwirkend in frühere Entscheidungen einfließen. Für gleiche Eingaben und denselben Regelstand soll derselbe fachliche Rechenweg maßgeblich sein.
Einstieg, Ziel, Stop, Break-even und Trailing werden als eigenständige Handelsereignisse mit einer nachvollziehbaren zeitlichen Reihenfolge behandelt. Gerade auf Intraday-Ebene reicht es nicht aus, nur Tageshoch, Tagestief und Schlusskurs zu kennen, wenn mehrere relevante Marken im selben Zeitraum berührt wurden. Der Ausführungsnachweis muss deshalb klären, welches Ereignis unter den verfügbaren Daten tatsächlich zuerst eintreten konnte und welche Folgewirkung daraus entstand.
Kapital- und Positionssteuerung setzen auf einer bereits bestimmten fachlichen Entscheidung auf und ergänzen diese um einen kontrollierten Handlungsrahmen. Dazu gehören Begrenzungen, Freigaben, Warnzustände, Positionsstufen und dynamische Schutzmechanismen. Der Zweck besteht nicht darin, ein unpassendes Signal nachträglich wirtschaftlich attraktiv zu machen, sondern zulässiges Exposure und Schutzmaßnahmen nachvollziehbar zu steuern.
Regel- und Softwareversion, Datenstand, Kostenannahmen und Prüfbedingungen bleiben mit dem jeweiligen Ergebnis verbunden. Ebenso werden bekannte Grenzen und noch offene Validierungsschritte nicht vom Resultat getrennt. Für einen institutionellen Prüfer entsteht damit eine nachvollziehbare Kette vom verwendeten Input über die angewandte Logik bis zu der Aussage, die aus einem Lauf tatsächlich abgeleitet werden darf.
Gegenstand der geplanten Transaktion sind die eigenentwickelte Technologie, dokumentierte Forschung, betriebliches Know-how und diejenigen Bestandteile von Plagge Consulting, die tatsächlich übertragbar sind. Der strategische Wert liegt dabei nicht allein in Quellcode oder einzelnen Handelsregeln, sondern in der Verbindung aus Entscheidungslogik, Execution-Modellierung, Risikosteuerung, versionierten Nachweisen und dokumentiertem Entwicklungswissen. Genau diese Verbindung macht den Bestand für einen Erwerber als technische und fachliche Grundlage interessant, auf der eigene Daten, Research-Prozesse, Risikovorgaben und institutionelle Infrastruktur aufsetzen können. Der konkrete Erwerbsgegenstand wird in der vertraulichen Bestands-, Rechte- und Technologieprüfung eindeutig festgelegt und anschließend vertraglich beschrieben.
Die vollständige Übertragung wird vorbereitet, weil ein strategischer Erwerber ITDRF in einer größeren institutionellen Umgebung mit eigenen Datenbeständen, Governance, Validierungskapazitäten und operativer Infrastruktur weiter prüfen, integrieren und entwickeln kann. Welche Nutzung daraus sinnvoll entsteht, hängt vom Geschäftsmodell des Erwerbers ab: Ein Trading- oder Quant-Unternehmen stellt andere Anforderungen als ein Asset Manager, ein Marktinfrastrukturanbieter oder ein Finanzsoftwareunternehmen. Die Website verspricht deshalb keine pauschale Synergie, zeigt aber klar, an welchen Stellen ein Erwerber technologische Substanz, Integrationsfähigkeit und strategischen Nutzen prüfen kann.
Für Trading- und Investmentorganisationen steht die Frage im Vordergrund, ob regelbasierte Entscheidungen und Risikosteuerung in bestehende Research- und Handelsprozesse eingebettet werden können. Dabei lässt sich nicht nur ein Ergebnis betrachten, sondern auch der Weg dorthin: Datenstand, Entscheidung, Ausführung, Positionssteuerung und Nachweis bleiben unterscheidbar. Das erleichtert eine kritische fachliche Prüfung, bevor über eine operative Nutzung entschieden wird.
Für Technologie- und Softwareanbieter kann der reproduzierbare Core als mögliche Ergänzung vorhandener Anwendungen geprüft werden. Entscheidend ist dabei nicht die heutige Benutzeroberfläche, sondern die Frage, ob fachliche Logik, Datenübergaben und Nachweisführung sauber genug getrennt sind, um in eine andere technische Umgebung überführt zu werden. Eine solche Integration wäre Gegenstand einer konkreten technischen Due Diligence und nicht bereits durch die öffentliche Website zugesagt.
Für Börsen- und Marktinfrastruktur stehen vor allem Schnittstellen, Datenflüsse, Integrationsfähigkeit und unabhängige Verifikationsanforderungen im Mittelpunkt. Ein Erwerber kann prüfen, welche Bestandteile in vorhandene Systeme passen, welche Abhängigkeiten bestehen und welche Nachweise für den eigenen Betriebsrahmen zusätzlich erforderlich wären. Die Architektur soll diese Prüfung ermöglichen, ohne externe Infrastruktur als Bestandteil des eigenen Cores darzustellen.
Geschäftsführung, Strategie und M&A müssen neben der Technologie auch Rechte, Reifegrad, offene Verpflichtungen und den tatsächlichen Erwerbsgegenstand beurteilen. Dazu gehört insbesondere die Trennung zwischen eigenem geistigem Eigentum, extern lizenzierten Daten und nicht automatisch übertragbaren Drittanbieterpositionen. Eine belastbare Transaktionsentscheidung kann deshalb erst aus der gemeinsamen technischen, wirtschaftlichen und rechtlichen Prüfung entstehen.
Die öffentliche Darstellung erklärt Zweck, Architektur, Anwendungsfelder und Prüfgrenzen. Quellcode, Handelsregeln, Parameter und vertrauliche Forschungsdaten werden nur im Rahmen einer qualifizierten Prüfung offengelegt.
Historische Forschung ist kein Nachweis heutiger ausführbarer Handelsperformance; es werden weder ein Anlageprodukt noch Live-Erträge oder garantierte Renditen angeboten.
Extern lizenzierte Marktdaten und fremde Nutzungsrechte sind nicht automatisch Bestandteil der geplanten Übertragung. Verwendung und Rechteübertragung bedürfen einer gesonderten vertraglichen Prüfung.
ITDRF verbindet einen einheitlichen Entscheidungs- und Execution-Core mit fachlich getrennten Aufgabenbereichen. Sequenzregeln, adaptive Parameterraupe, Setups sowie Positions- und Risikosteuerung erfüllen unterschiedliche Funktionen und werden nicht deshalb zu einem einzigen Verfahren, weil sie innerhalb derselben Architektur zusammenarbeiten. Forschungs- und Vergleichslabore dienen dazu, Zustände, Varianten und Wechselwirkungen nachvollziehbar zu untersuchen; eine interessante Darstellung oder ein historischer Effekt ist damit noch keine automatische Freigabe für den Live-Handel.
Die öffentliche Darstellung soll ausreichend Substanz liefern, damit ein institutioneller Leser die Architektur, den Entwicklungsstand und die Grenzen der bisherigen Nachweise verstehen kann. Gleichzeitig werden konkrete Strategieregeln, Parameter, Quellcode und vertrauliche Forschungsbestände nicht so veröffentlicht, dass die Kernmechanik reproduziert werden könnte. Die vertiefte Prüfung gehört deshalb in einen qualifizierten, vertraulichen Prozess.
