> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Regel-API und MCP - Programmatische KYT-Regelverwaltung > Mit Didit KYT-Regeln per API und MCP erstellen, anpassen, backtesten, migrieren und aktivieren: Endpoints, MCP-Tools, Workflow. Wann welche Oberfläche Jede Regelfunktion der Business-Konsole ist auch programmatisch verfügbar: über die **Management API** mit dem API-Schlüssel Ihrer Anwendung und über die **Didit MCP** für KI-Agenten, die als angemeldeter Konsolenbenutzer handeln. Nutzen Sie sie, um Regeln aus dem Code zu verwalten, Regelsätze in der Versionsverwaltung zu halten oder einen KI-Assistenten Regeln für Sie erstellen und migrieren zu lassen. ## Wann welche Oberfläche | Oberfläche | Authentifizierung | Am besten geeignet für | | - | - | - | | **Business-Konsole** | Anmeldung an der Konsole | Manuelle Prüfung jeder Änderung; visuelles Erstellen von Regeln und Backtesting | | **Management API** | `x-api-key` | Automatisierung aus Ihrem Backend, Regelsätze im Code, über CI verwaltete Regel-Deployments | | **Didit MCP** | Anmeldung mit Didit (OAuth) | KI-Assistenten und Agenten: der Copilot der Didit-Konsole, Claude, Cursor oder jeder MCP-Client | ## Die Endpoints | Endpoint | Zweck | | - | - | | [`GET /v3/transactions/rules/`](https://docs.didit.me/de/management-api/transactions/rules-list) | Regeln mit Filtern und nach Performance sortiert auflisten | | [`POST /v3/transactions/rules/`](https://docs.didit.me/de/management-api/transactions/rules-create) | Eine benutzerdefinierte Regel erstellen | | [`GET /v3/transactions/rules/{rule_uuid}/`](https://docs.didit.me/de/management-api/transactions/rules-get) | Eine Regel mit Ausführungszählern abrufen | | [`PATCH /v3/transactions/rules/{rule_uuid}/`](https://docs.didit.me/de/management-api/transactions/rules-update) | Eine benutzerdefinierte Regel aktualisieren; den Modus einer beliebigen Regel umschalten | | [`DELETE /v3/transactions/rules/{rule_uuid}/`](https://docs.didit.me/de/management-api/transactions/rules-delete) | Eine benutzerdefinierte Regel löschen (dauerhaft) | | [`POST /v3/transactions/rules/backtest/`](https://docs.didit.me/de/management-api/transactions/rules-backtest) | Eine hypothetische Regel gegen Ihren Verlauf auswerten | | [`GET /v3/transactions/rules/library/`](https://docs.didit.me/de/management-api/transactions/rules-library) | Die Bibliothek mit 150+ Presets einschließlich Installationsstatus durchsuchen | | [`POST /v3/transactions/rules/install/`](https://docs.didit.me/de/management-api/transactions/rules-install) | Presets nach Schlüssel, Bündel oder Schnittmenge aus beidem installieren | | [`DELETE /v3/transactions/rules/install/`](https://docs.didit.me/de/management-api/transactions/rules-uninstall) | Presets nach Schlüssel, Bündel oder Schnittmenge aus beidem deinstallieren | Die entsprechenden MCP-Tools sind `didit_transaction_rule_list`, `didit_transaction_rule_get`, `didit_transaction_rule_create`, `didit_transaction_rule_update`, `didit_transaction_rule_delete`, `didit_transaction_rule_backtest`, `didit_transaction_rule_library_list`, `didit_transaction_rule_install` und `didit_transaction_rule_uninstall` – siehe die [MCP-Tool-Referenz](https://docs.didit.me/de/integration/mcp/tools.md). Das vollständige Schema – der Feldkatalog, alle 19 Bedingungsoperatoren, Geschwindigkeitsfenster, gruppierte Bedingungen und die sechs Aktionstypen – ist auf der Seite [Regeln & Scoring](https://docs.didit.me/de/transaction-monitoring/rules.md) dokumentiert und in der API-Referenz eingebettet. ## Erstellen, Backtest durchführen, Aktivieren Das sichere Rollout-Muster für jede neue Regel: **1. Die Regel im TEST-Modus erstellen** ```bash theme={null} curl -X POST 'https://verification.didit.me/v3/transactions/rules/' \ -H 'x-api-key: YOUR_API_KEY' \ -H 'Content-Type: application/json' \ -d '{ "title": "Structuring - inbound (custom)", "description": "20+ inbound EUR transfers, all under 10,000 EUR, 30 days", "category": "finance", "mode": "TEST", "evaluation_mode": "ALL", "scope": { "transaction_types": ["finance"], "directions": ["INBOUND"] }, "conditions": [ {"field": "currency", "operator": "eq", "value": "EUR"}, {"field": "amount", "operator": "lt", "value": 10000} ], "aggregation": [ { "metric": "count", "operator": "gte", "value": 20, "window": "30d", "filters": {"direction": "INBOUND", "transaction_type": "finance", "currency": "EUR", "subject_vendor_data": "__current__"} }, { "metric": "max", "field": "amount", "operator": "lt", "value": 10000, "window": "30d", "filters": {"direction": "INBOUND", "transaction_type": "finance", "currency": "EUR", "subject_vendor_data": "__current__"} } ], "actions": [{"type": "add_score", "value": 35}] }' ``` Lesen Sie den Payload in zwei Hälften. `scope` und `conditions` beschreiben **die bewertete Transaktion**: eine eingehende Finanztransaktion in EUR mit einem Rohbetrag `amount` unter 10.000. Die Einträge in `aggregation` beschreiben **das 30-Tage-Fenster für dieselbe Entität**: mindestens 20 eingehende Finanztransaktionen in EUR, und keine davon 10.000 EUR oder mehr. Beide Aggregationseinträge müssen zutreffen, unabhängig davon, was `evaluation_mode` vorgibt – diese Einstellung steuert nur die Bedingungen. Dieses Beispiel verwendet den Rohbetrag `amount` und legt `currency` in beiden Hälften auf EUR fest, sodass es nicht von der FX-Normalisierung abhängt. Um einen Backtest mit Sandbox-Fixtures durchzuführen, reichen Sie mindestens 20 eingehende Finanztransaktionen in EUR für dieselbe Entität innerhalb von 30 Tagen ein, jeweils mit `amount` unter 10.000. Weder `preferred_currency_amount` noch `amount_in_default_currency` sind erforderlich. Die Sandbox-Verarbeitung speichert diese Transaktionen; führen Sie den Backtest explizit aus. Eine `TEST`-Regel bewertet jede neue Transaktion und protokolliert, welche Transaktionen sie erfasst hätte, verändert aber niemals den Score oder den Status der Transaktion. > [!NOTE] > > **Ein Aggregationsfilter ist keine Bedingung.** Eine Bedingung liest immer nur die bewertete Transaktion; ein Aggregationsfilter grenzt immer nur das historische Fenster ein und vergleicht per Gleichheit oder Listenzugehörigkeit – es gibt keinen `lt`-Filter, daher können Sie nicht *nur die Überweisungen unter 10.000 zählen*. > > Der Eintrag `max ... lt 10000` ist die unterstützte Möglichkeit, dem Fenster eine Obergrenze zu setzen: Er verlangt, dass **jede** Transaktion im Fenster unter 10.000 liegt. Das ist strenger, als nur die kleinen zu zählen – eine einzige Überweisung von 12.000 unter den zwanzig verhindert, dass die Regel auslöst. Entfernen Sie diesen Eintrag, wenn die Zählung für sich allein stehen soll, und benennen Sie das dann im Titel: Ohne ihn zählt die Regel eingehende Überweisungen jeder Größe, und neunzehn Überweisungen zu je 50.000 gefolgt von einer kleinen erfüllen diese Regel. **2. Backtest gegen Ihren Verlauf** ```bash theme={null} curl -X POST 'https://verification.didit.me/v3/transactions/rules/backtest/' \ -H 'x-api-key: YOUR_API_KEY' \ -H 'Content-Type: application/json' \ -d '{ "conditions": [ {"field": "currency", "operator": "eq", "value": "EUR"}, {"field": "amount", "operator": "lt", "value": 10000} ], "aggregation": [ { "metric": "count", "operator": "gte", "value": 20, "window": "30d", "filters": {"direction": "INBOUND", "transaction_type": "finance", "currency": "EUR", "subject_vendor_data": "__current__"} }, { "metric": "max", "field": "amount", "operator": "lt", "value": 10000, "window": "30d", "filters": {"direction": "INBOUND", "transaction_type": "finance", "currency": "EUR", "subject_vendor_data": "__current__"} } ], "evaluation_mode": "ALL", "scope": { "transaction_types": ["finance"], "directions": ["INBOUND"] }, "period_days": 90 }' ``` ```json theme={null} { "evaluated": 4820, "matched": 12, "affected_entities": 4, "period_days": 90 } ``` Ein auffälliger `matched`-Wert bedeutet, dass die Schwellenwerte angepasst werden müssen, bevor die Regel überhaupt wirksam werden kann. > [!WARNING] > > Führen Sie einen Backtest für die **exakte** Konfiguration durch, die Sie aktivieren möchten: dieselben `conditions`, `aggregation`, `evaluation_mode` und `scope`. Weggelassene `conditions`, `aggregation` und `scope` fügen keine eigenen Einschränkungen hinzu; wenn Sie den Scope weglassen, können Richtungen oder Transaktionstypen einbezogen werden, die die gespeicherte Regel überspringt. Ein weggelassenes `evaluation_mode` ist standardmäßig `ALL`; wenn Sie es bei einer `ANY`-Regel weglassen, können sich die Treffer verringern. Ein weggelassenes `period_days` ist standardmäßig 90 Tage; es wählt keinen unbegrenzten Verlauf aus. **3. Aktivieren** ```bash theme={null} curl -X PATCH 'https://verification.didit.me/v3/transactions/rules/RULE_UUID/' \ -H 'x-api-key: YOUR_API_KEY' \ -H 'Content-Type: application/json' \ -d '{"mode": "ACTIVE"}' ``` Die Regel gilt sofort für alle neuen Transaktionen einer **Live**-Anwendung. > [!WARNING] > > Sandbox-Anwendungen werten Regeln niemals aus. Eine Sandbox-Transaktion wird nur gespeichert und nichts weiter, daher ändert das Aktivieren einer Regel in einer Sandbox-Anwendung nichts, was Sie beobachten können. Der Backtest ist der unterstützte Weg, eine Regel vor dem Livebetrieb zu prüfen – siehe [Transaktionsüberwachung in der Sandbox](https://docs.didit.me/de/integration/sandbox-testing.md#transaktionsüberwachung-in-der-sandbox). ## Regeln von einem anderen Anbieter migrieren Da die Regelerstellung ein einfacher API-Aufruf mit vollständig dokumentiertem Schema ist, kann ein KI-Assistent den Regelexport eines anderen Anbieters für Sie in Didit-Regeln übersetzen. 1. **Exportieren** Sie Ihre Regeln beim bisherigen Anbieter. Die meisten Tools exportieren nach CSV oder Excel. 2. **Legen Sie die Datei** im Assistenten der Didit-Konsole ab (oder in einem beliebigen über MCP verbundenen Agenten wie Claude, an den das [Didit MCP](https://docs.didit.me/de/integration/mcp/overview.md) angebunden ist). Tabellenkalkulationen werden automatisch in Text umgewandelt. 3. Der Assistent **ordnet jede Zeile** dem Didit-Schema zu, also Bedingungen, Velocity-Fenstern und Aktionen, und zeigt Ihnen die Zuordnung. Dabei weist er auf alles hin, das kein Didit-Pendant hat, und erstellt erst danach etwas. 4. Nach Ihrer Freigabe **erstellt er die Regeln im TEST-Modus**, führt mit Ihrer eigenen Transaktionshistorie einen Backtest durch und meldet erstellte, fehlgeschlagene und nicht zuordenbare Zeilen. 5. **Prüfen Sie die Zahlen und aktivieren Sie** die Regeln, die passend aussehen, entweder in der Konsole oder mit `PATCH {"mode": "ACTIVE"}`. Ein Anbieter-Export dieser Art: ```csv theme={null} Rule Name,Condition,Threshold,Window (days),Action Structuring - Small Transfers,count of outbound transfers under amount,20 transfers under 10000 EUR,30,Flag for review High Value Wire,single transaction amount,> 50000 USD,,Decline ``` wird zu Regeln wie diesen: ```json theme={null} { "title": "Structuring - Small Transfers", "description": "20+ outbound EUR transfers, all under 10,000 EUR, 30 days", "category": "finance", "mode": "TEST", "evaluation_mode": "ALL", "scope": { "transaction_types": ["finance"], "directions": ["OUTBOUND"] }, "conditions": [ {"field": "currency", "operator": "eq", "value": "EUR"}, {"field": "amount", "operator": "lt", "value": 10000} ], "aggregation": [ { "metric": "count", "operator": "gte", "value": 20, "window": "30d", "filters": {"direction": "OUTBOUND", "transaction_type": "finance", "currency": "EUR", "subject_vendor_data": "__current__"} }, { "metric": "max", "field": "amount", "operator": "lt", "value": 10000, "window": "30d", "filters": {"direction": "OUTBOUND", "transaction_type": "finance", "currency": "EUR", "subject_vendor_data": "__current__"} } ], "actions": [ {"type": "add_score", "value": 35}, {"type": "change_status", "value": "IN_REVIEW"} ] } ``` Die CSV-Zeile gibt eine Richtung und eine Währung an, daher übernehmen beide Teile der Regel diese Angaben: `scope` und `conditions` beschränken die bewertete Transaktion auf eine ausgehende EUR-Überweisung unter 10.000, und die Aggregationsfilter beschränken das 30-Tage-Fenster auf die ausgehenden EUR-Überweisungen desselben Subjekts. Der Rohwert `amount` ist nur innerhalb einer Währung vergleichbar. Halten Sie die Währung daher wie oben fest. Eine währungsübergreifende Obergrenze setzt voraus, dass für jede Transaktion im Fenster ein normalisierter Betrag vorliegt. Wenn Sie nur auf `preferred_currency_amount` umstellen, wird die Verfügbarkeit nicht erzwungen: Fehlende historische normalisierte Beträge können bei numerischen Aggregationen als 0 behandelt werden. Der Eintrag `max` sorgt dafür, dass das Fenster unter 10.000 EUR bleibt, weil ein Aggregationsfilter *unter 10.000* nicht ausdrücken kann. Die Abwägung, die dabei entsteht, finden Sie im Hinweis zum [Schritt Erstellen](#erstellen-backtest-durchführen-aktivieren) weiter oben. Alles, was das Schema nicht exakt abbilden kann, sollten Sie in der `description` der Regel ausdrücklich benennen, statt es stillschweigend anzunähern. > [!TIP] > > Bevor Sie die Regel eines Anbieters als benutzerdefinierte Regel neu anlegen, prüfen Sie die [Regelbibliothek](https://docs.didit.me/de/management-api/transactions/rules-library.md). Didit stellt 150+ Presets für die gängigen Typologien bereit, etwa Structuring, Velocity, Sanktionsbezug, Geräte-Wiederverwendung und Krypto-Risiko. Ein Preset lässt sich mit einem einzigen Aufruf installieren. ## Validierungsfehler sind bewusst präzise Die Endpoints zum Erstellen und Aktualisieren prüfen Bedingungen, Aggregation und Scope-Werte genau gegen das, was die Regel-Engine akzeptiert. Unbekannte Operatoren oder Metriken, fehlerhafte Fenster (etwa `"30days"` statt `"30d"`), ungültige Scope-Richtungen, `contains_any` ohne Liste, `fuzzy_match` ohne `score` und `change_status` auf `AWAITING_USER` ohne `workflow_id` führen zu einer `400`-Antwort. Diese nennt den Index und das Problem. So wird verhindert, dass eine Regel gespeichert wird, die nie greift, ohne dass es auffällt. Agenten und Skripte sollten den Fehlerkörper der Antwort lesen und die Anfrage entsprechend korrigieren. Zusätzliche Scope-Schlüssel neben `transaction_types`, `directions` und `action_types` werden gespeichert, aber von der Engine ignoriert. Die Business Console speichert sie seit jeher genauso. ## Nächste Schritte > [card] [Regeln und Scoring](https://docs.didit.me/de/transaction-monitoring/rules.md) > > Das vollständige Regelschema: Felder, Operatoren, Velocity-Fenster und Aktionen. > [card] [API zum Erstellen von Regeln](https://docs.didit.me/de/management-api/transactions/rules-create.md) > > Endpoint-Referenz mit den Schemas für Anfrage und Antwort. > [card] [Regelbibliothek](https://docs.didit.me/de/transaction-monitoring/rules-library.md) > > Der Katalog mit 150+ Presets und seinen Bündeln. > [card] [MCP-Übersicht](https://docs.didit.me/de/integration/mcp/overview.md) > > Verbinden Sie einen KI-Agenten mit Ihrem Didit-Workspace. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.