Leitstück 03 · MCP · FinCrime-Architektur 2026

MCP ist nicht Observability

Tool Discovery ersetzt keine Traceability. Wenn Agenten in der Geldwäschebekämpfung mitarbeiten, brauchen sie Query-Policies, ein Event Ledger und auditierbare Decision Records — nicht nur einen Stecker, der sie an Werkzeuge anschließt.

Das Model Context Protocol hat in kurzer Zeit gelöst, was lange mühsam war: Ein Agent kann Werkzeuge und Datenquellen entdecken und aufrufen, ohne dass jemand für jede Quelle einen Spezialconnector schreibt. Ein MCP-Server kündigt seine Tools, Resources und Prompts an, der Agent findet sie und nutzt sie. Das ist ein echter Fortschritt — und genau deshalb gefährlich, wenn man ihn mit etwas verwechselt, das er nicht ist. MCP regelt den Zugang. Es regelt nicht die Rechenschaft — jedenfalls nicht allein und nicht im Sinne einer prüfungsfesten Spur.

In einem Marketing-Backend ist dieser Unterschied bequem zu ignorieren. In der Geldwäschebekämpfung ist er der Unterschied zwischen einem System, das einer Prüfung standhält, und einem, das im Ernstfall nicht erklären kann, warum ein Konto gesperrt oder ein Verdacht verworfen wurde. Die Aufsicht fragt nicht, ob der Agent Zugriff hatte. Sie fragt, was er getan hat, auf welcher Grundlage, mit welchen Daten, in welcher Reihenfolge — und wer es verantwortet.

Zwei Begriffe, die ständig verwechselt werden

Die Verwechslung beginnt bei der Sprache (siehe Leitstück 01). „MCP gibt uns Observability“ ist ein Satz, der zwei verschiedene Schichten zusammenwirft. Es lohnt, sie sauber zu trennen.

Tool Discovery ist die Fähigkeit eines Agenten, zur Laufzeit herauszufinden, welche Werkzeuge existieren und wie er sie aufruft. Das ist die Domäne von MCP: standardisierte Beschreibung von Tools, dynamisches Auffinden, einheitlicher Aufruf. Die Frage, die Tool Discovery beantwortet, lautet: Was kann ich tun?

Traceability ist die Fähigkeit eines Systems, im Nachhinein lückenlos zu rekonstruieren, was geschehen ist — welche Entscheidung auf welcher Grundlage fiel, in welcher Reihenfolge, mit welchen Daten, durch wen oder was. Das ist die Domäne von Observability und Auditierbarkeit. Die Frage, die Traceability beantwortet, lautet: Was ist geschehen, und warum?

Tool Discovery beantwortet „Was kann ich tun?“. Traceability beantwortet „Was ist geschehen, und warum?“. MCP ist exzellent in der ersten Frage und konstruktionsbedingt stumm in der zweiten.

MCP liefert nützliche Bausteine an der Grenze: Resources tragen oft Provenienz-Metadaten wie Quell-IDs und Zeitstempel, und auf den öffentlich kommunizierten Protokoll-Roadmaps für 2026 stehen Governance-Reife und Enterprise-Themen wie Audit-Trails und Zugriffskontrolle weit oben. Aber das sind Zutaten, keine fertige Audit-Architektur. Wer sie nicht aktiv zu einer Spur zusammensetzt, hat einen Agenten, der überall hinkommt und nirgends Spuren hinterlässt, die im Sinne der Beweisführung taugen.

Was fehlt, wenn nur MCP da ist

Stellen wir uns einen Agenten vor, der einen Alert vorqualifiziert. Über MCP greift er auf den Transaktionsspeicher, den Sanktions-Screening-Dienst, einen Graph (Neo4j) und einen Vektorindex für Adverse Media zu. Er ruft sie auf, zieht sich Daten, formt eine Einschätzung. Mit reinem MCP bleibt am Ende: ein Ergebnis. Was fehlt, ist alles, was dieses Ergebnis prüfbar macht.

Erstens fehlt die Query-Policy. Durfte der Agent diese Abfrage überhaupt stellen? Hat er auf personenbezogene Daten zugegriffen, die für diese Hypothese nicht erforderlich waren? In der EU ist Datenminimierung kein Stilfrage, sondern Pflicht. MCP fragt nicht, ob eine Abfrage erlaubt ist — es führt sie aus, wenn das Tool erreichbar ist. Die Erlaubnis muss eine eigene Schicht davor entscheiden.

Zweitens fehlt das Event Ledger. Welche Tools hat er in welcher Reihenfolge mit welchen Parametern aufgerufen, und was kam zurück? Ohne ein append-only-Protokoll dieser Aufrufe lässt sich der Weg nicht rekonstruieren. Ein nachträglicher Log, der erst beim Speichern entsteht, verliert Reihenfolge und Lücken, sofern er nicht selbst explizit append-only und transaktionsnah geführt wird — derselbe Fehler wie beim nachträglichen Audit-Logging am Aggregate (Leitstück 02).

Drittens fehlt der Decision Record. Aus welchen Belegen folgte welche Schlussfolgerung, mit welcher Konfidenz, und wer hat sie verantwortet? Genau hier schließt sich der Kreis zum EvidencePackage: Die Aktionen des Agenten müssen in dieselben Claims, Hypothesen und Decisions münden, die das Aggregate verlangt — sonst produziert der Agent Aktivität, aber keine Evidenz.

Die drei Schichten im Detail

1 — Query-Policy: die Erlaubnis vor dem Aufruf

Bevor ein Tool-Call den MCP-Layer erreicht, entscheidet eine Policy, ob er stattfinden darf. Sie prüft Zweckbindung (gehört diese Abfrage zur aktiven Hypothese?), Datenminimierung (sind alle angeforderten Felder erforderlich?) und Rolle (darf dieser Agent in diesem Kontext überhaupt diese Quelle berühren?). Wichtig ist, dass die Policy-Entscheidung selbst protokolliert wird — auch eine Ablehnung ist ein Audit-relevantes Ereignis.

2 — Event Ledger: die lückenlose Spur

Jeder zugelassene Aufruf und seine Antwort werden in ein append-only-Ledger geschrieben, bevor das Ergebnis weiterverarbeitet wird. Append-only heißt: kein Update, kein Delete. Die Spur ist damit nicht nur vollständig, sondern auch unveränderlich — eine Voraussetzung, die später die Privacy-Enhancing-Architektur (Leitstück 07) und die Echtzeit-Governance (Leitstück 08) brauchen.

3 — Decision Record: der Übergang zur Evidenz

Aus dem Ledger und den gewonnenen Daten formt der Workflow Decision Records, die sich nahtlos in das EvidencePackage einfügen: ein Claim mit Provenance, eine Hypothese mit Konfidenz, am Ende eine menschlich verantwortete Entscheidung. Der Agent darf den Record vorbereiten — verantworten muss ihn ein Mensch (Invariante aus Leitstück 02).

Python · Auditierender Wrapper um jeden MCP-Tool-Callfrom dataclasses import dataclass
from datetime import datetime, timezone
import json, hashlib

@dataclass(frozen=True)
class PolicyDecision:
    allowed: bool
    reason: str
    purpose: str          # aktive Hypothese / Zweckbindung

class AuditedMcpClient:
    """Legt VOR Discovery die fehlenden Schichten um MCP."""
    def __init__(self, mcp, policy, ledger):
        self._mcp = mcp          # roher MCP-Client (Tool Discovery)
        self._policy = policy     # Query-Policy-Engine
        self._ledger = ledger     # append-only Event Ledger

    def call(self, tool: str, args: dict, *, purpose: str, agent_id: str):
        # 1) Policy: darf der Aufruf stattfinden?
        decision = self._policy.evaluate(tool, args, purpose, agent_id)
        self._ledger.append({
            "type": "PolicyEvaluated", "tool": tool,
            "allowed": decision.allowed, "reason": decision.reason,
            "purpose": purpose, "agent": agent_id, "at": datetime.now(timezone.utc),
        })
        if not decision.allowed:
            raise PolicyError(decision.reason)   # Ablehnung ist protokolliert

        # 2) Aufruf via MCP — erst jetzt
        result = self._mcp.call_tool(tool, args)

        # 3) Ledger: Aufruf + Antwort-Hash + Provenienz, append-only
        self._ledger.append({
            "type": "ToolInvoked", "tool": tool,
            "args_hash": _hash(args),
            "result_hash": _hash(result),
            "source_id": result.get("_provenance", {}).get("source_id"),
            "purpose": purpose, "agent": agent_id, "at": datetime.now(timezone.utc),
        })
        return result

def _hash(obj) -> str:
    return hashlib.sha256(json.dumps(obj, sort_keys=True, default=str).encode()).hexdigest()

Der Wrapper ist absichtlich dünn. Er erfindet kein neues Protokoll — er legt nur das herum, was MCP nicht abdeckt: eine Erlaubnis davor, eine Spur daneben, einen Übergang zur Evidenz dahinter. Genau dieser Aufbau macht aus „der Agent hatte Zugriff“ ein „der Agent tat X, weil Y, gestützt auf Quelle Z, freigegeben von Person P“.

Ein durchgespielter Agentenlauf

Sehen wir den Unterschied an einem konkreten Schritt. Ein Agent soll einen Sanktions-Screening-Treffer vorqualifizieren: Ist „J. Petrov“ auf dem Konto plausibel dieselbe Person wie der gelistete „Jurij Petrov“? Mit reinem MCP ist der Ablauf kurz: Der Agent entdeckt das Screening-Tool, ruft es auf, holt Geburtsdatum und Adresse aus dem Kundenstamm dazu, vergleicht, meldet „kein Match“. Sauber, schnell — und im Audit wertlos, weil niemand mehr nachvollziehen kann, welche Daten er sah und ob er sie sehen durfte.

Mit der vollständigen Schicht sieht derselbe Schritt anders aus. Bevor der Agent den Kundenstamm berührt, fragt die Query-Policy: Gehört „Geburtsdatum abrufen“ zur aktiven Hypothese „Identitätsabgleich Sanktionstreffer“? Ja — Zweckbindung erfüllt. Braucht er auch die Kontoumsätze? Nein — die Anfrage würde abgelehnt und die Ablehnung protokolliert. Jeder zugelassene Aufruf landet mit Zeitstempel, Parameter-Hash, Antwort-Hash und Quell-ID im Event Ledger, bevor das Ergebnis weiterläuft. Am Ende formt der Agent keinen blanken Befund, sondern einen Decision Record: Claim („Geburtsdaten weichen um 14 Jahre ab“), Provenance (Kundenstamm, Abrufzeitpunkt), Confidence, Vorschlag „kein Match“ — zur Bestätigung durch einen Menschen.

Beide Läufe kommen zum selben Ergebnis. Nur der zweite kann es verteidigen. Der Mehraufwand ist gering — ein dünner Wrapper und eine Policy-Engine — aber er verwandelt eine Maschinenaktivität in eine zurechenbare, prüfbare Entscheidung. Das ist der ganze Punkt dieses Leitstücks in einem einzigen Schritt.

Was ins Ledger gehört — und was nicht

Ein Event Ledger, das alles roh mitschreibt, wird selbst zum Risiko: Es häuft personenbezogene Daten an, die niemand für die Spur braucht, und kollidiert mit Datenminimierung und Löschpflichten. Die Kunst liegt darin, genug zu protokollieren, um den Vorgang zu rekonstruieren — aber nicht mehr.

Praktisch heißt das: Ins Ledger gehören die Tatsache des Aufrufs, der Zeitpunkt, das aufgerufene Tool, der Zweck, der handelnde Agent, die Policy-Entscheidung sowie kryptografische Hashes von Parametern und Antwort. Die Hashes belegen, dass eine bestimmte Anfrage eine bestimmte Antwort erhielt, ohne die Inhalte selbst im Klartext zu speichern. Die eigentlichen Rohdaten bleiben in ihren Quellsystemen mit deren eigenen Aufbewahrungs- und Löschregeln; das Ledger verweist auf sie über die Quell-ID. So bleibt die Spur lückenlos und unveränderlich, ohne zu einer zweiten, schlecht geschützten Kopie sensibler Daten zu werden.

Die Unveränderlichkeit ist dabei kein Detail. Ein append-only-Ledger, dessen Einträge sich verketten lassen — jeder Eintrag trägt den Hash seines Vorgängers —, macht nachträgliche Manipulation sichtbar. Genau diese Eigenschaft brauchen die föderierte Erkennung (Leitstück 07) und die Echtzeit-Governance (Leitstück 08): Wenn mehrere Parteien oder Millisekunden-Entscheidungen im Spiel sind, muss die Spur beweisen können, dass sie nicht nachträglich zurechtgelegt wurde.

In der Praxis wird diese Spur selten als simple Liste geführt. Bewährt haben sich dedizierte, append-only Event Stores — etwa ein unveränderliches Kafka-Topic oder eine Ledger-Datenbank — und die Spiegelung der Ereignisse in bestehende SIEM- und APM-Systeme, damit Sicherheits- und Betriebsüberwachung dieselbe Wahrheit sehen. Das Schreiben ins Ledger sollte transaktional an die eigentliche Aktion gekoppelt sein — etwa über ein Transactional-Outbox-Muster —, damit kein Aufruf stattfinden kann, der nicht auch protokolliert wurde. Erst diese Kopplung macht aus „wir loggen das schon“ eine belastbare Garantie.

Observability ist mehr als Logs

Ein zweites Missverständnis lauert auf der Betriebsseite. „Observability“ wird gern auf Logs, Metriken und Traces reduziert — die drei klassischen Säulen. Für agentische FinCrime-Systeme reicht das nicht. Klassische Observability beantwortet, ob das System läuft: Latenz, Fehlerrate, Durchsatz. AML-Observability muss beantworten, ob das System wirkt: Wie viele Alerts wurden vom Agenten verworfen, und hielt diese Entscheidung der Stichprobe stand? Driftet die Falsch-Positiv-Rate? Greift der Agent systematisch auf bestimmte Quellen zu und ignoriert andere? Das sind fachliche, keine technischen Signale — und sie entstehen nur, wenn das Event Ledger fachlich reich genug protokolliert.

Klassische Observability fragt, ob das System läuft. AML-Observability fragt, ob es wirkt — und ob seine Entscheidungen einer Prüfung standhalten.

Aus dem fachlich reichen Ledger lassen sich Kennzahlen ableiten, die ein klassisches Monitoring nie zeigt. Drei davon — hier als Dossier-Vorschläge gedacht, nicht als etablierte Industriestandards — sind besonders aufschlussreich. Die Verwerfungs-Treffsicherheit misst, wie oft vom Agenten verworfene Alerts in einer Stichprobe doch hätten eskaliert werden müssen — der direkte Indikator dafür, ob die Maschine zu viel wegfiltert. Die Quellen-Abdeckung zeigt, ob der Agent systematisch bestimmte Datenquellen heranzieht und andere ignoriert; ein blinder Fleck im Zugriffsverhalten ist ein blinder Fleck in der Beweisführung. Und die Policy-Ablehnungsrate macht sichtbar, wie oft die Query-Policy greift — ein plötzlicher Anstieg verrät einen fehlgeleiteten Agenten, ein Wert nahe null verrät eine Policy, die in Wahrheit nichts prüft.

Keine dieser Kennzahlen entsteht aus Latenz oder Fehlerraten. Sie entstehen ausschließlich, weil die Spur fachlich protokolliert wurde — Zweck, Quelle, Policy-Entscheidung, Ergebnis. Wer nur technisch loggt, hat ein System, das zuverlässig läuft und über dessen Wirksamkeit niemand etwas sagen kann.

Wer baut diese Schicht — und wo sitzt sie?

Eine berechtigte Sorge lautet: Verlangt das nicht, dass jeder Agent diszipliniert protokolliert — und genügt damit nicht dem ersten unsauberen Prompt, um die ganze Spur zu unterlaufen? Die Antwort liegt im Architekturort. Die fehlende Schicht gehört nicht in die Verantwortung des Agenten und schon gar nicht in seinen Prompt. Sie gehört vor den Agenten — als Gateway, durch das jeder Tool-Zugriff zwingend hindurch muss. Der Agent kann gar nicht direkt mit dem MCP-Server sprechen; er spricht mit dem auditierenden Gateway, das Policy prüft, ins Ledger schreibt und erst dann weiterleitet. Was nicht durch das Gateway geht, findet nicht statt.

Dieser Unterschied ist entscheidend, weil er die Garantie von der Gutwilligkeit des Agenten entkoppelt. Ein Prompt kann einen Agenten überreden, Audit-Schritte zu „vergessen“ — eine erzwungene Durchleitung kann er nicht umgehen. Die Spur entsteht also unabhängig davon, wie das Modell gerade denkt. Genau diese Eigenschaft braucht die Agentic Audit Pipeline aus Leitstück 09: Retrieval-Quality-Gates, ein adversarialer Prüfschritt und eine Review Queue setzen voraus, dass jeder Zugriff zwangsläufig erfasst wurde — sonst prüfen sie Lücken.

Bleibt die Build-vs-Buy-Frage. MCP-Client und Server kauft oder nutzt man als Standard; das ist die Commodity. Die Query-Policy, das append-only-Ledger und die Anbindung an das EvidencePackage hingegen kodieren den Risikoappetit, die Rechtslage und die Ontologie des Instituts — sie sind dessen Eigentum und sollten es bleiben. Wer diese Schicht vollständig auslagert, lagert die Erklärbarkeit seiner eigenen Entscheidungen aus. Und genau die verlangt die Aufsicht nicht vom Anbieter, sondern vom Institut.

Kernsätze

Damit ist die agentische Grundausstattung umrissen: zugänglich durch MCP, rechenschaftspflichtig durch Policy, Ledger und Decision Record. Im weiteren Verlauf des Dossiers wird diese Spur tragend — für die saubere Trennung von Fraud und AML über geteilte Events (Leitstück 04), für die Echtzeit-Governance, wenn das Ermittlungsfenster auf Millisekunden schrumpft (Leitstück 08), und für die Agentic Audit Pipeline mit Quality-Gates und Review Queue (Leitstück 09).

Markiert: RegTech · RegTech Architecture · Agentic AI · AML Observability · MCP · Architektur