Leitstück 02 · Kernstück · FinCrime-Architektur 2026

Das EvidencePackage-Aggregate

Ein Alert ist kein Beweis. Das Aggregate hält Signal, Beziehung, Hypothese, Quelle und menschliche Entscheidung als einen konsistenten Gegenstand zusammen — und schützt die Regeln, ohne die aus einem Verdacht keine Evidenz wird.

Die meisten AML-Systeme speichern Alerts in der einen Tabelle, Fälle in der zweiten, Kundendaten in der dritten und die Begründung der Verdachtsmeldung in einem Freitextfeld der vierten. Technisch ist das normalisiert. Fachlich ist es zerlegt: Niemand hält den Beweisgegenstand als Ganzes zusammen. Wenn die Aufsicht fragt „Auf welcher Grundlage haben Sie hier entschieden?“, muss ein Mensch die Antwort aus vier Systemen rekonstruieren — und genau in dieser Rekonstruktion gehen Provenienz, Reihenfolge und Verantwortung verloren.

Das EvidencePackage ist die Antwort auf diese Zerlegung. Es ist kein weiteres Datenobjekt, sondern ein Aggregate im Sinne des Domain-Driven Design: eine Konsistenzgrenze um genau die Dinge, die nur gemeinsam gültig sind. Ein Signal ohne seine Herkunft ist wertlos. Eine Hypothese ohne stützende Beobachtung ist Spekulation. Eine Entscheidung ohne benannten Verantwortlichen ist im Audit nicht existent. Das Aggregate macht aus diesen Teilen einen Gegenstand, der seine eigenen Regeln durchsetzt.

Warum ein Aggregate, nicht eine Tabelle

Ein Aggregate ist im DDD eine Gruppe von Objekten, die als Einheit behandelt wird. Es hat eine Wurzel (Aggregate Root), über die jeder Zugriff läuft, und eine Konsistenzgrenze: Innerhalb dieser Grenze müssen die Regeln — die Invarianten — zu jedem Zeitpunkt erfüllt sein. Man kann ein Aggregate nicht in einem halb gültigen Zustand speichern. Genau das ist der Unterschied zur Tabelle: Eine Tabelle akzeptiert jede Zeile, die den Spaltentypen genügt. Ein Aggregate akzeptiert nur Zustände, die fachlich Sinn ergeben.

Für Evidenz ist das die zentrale Eigenschaft. Die Regel „eine meldepflichtige Verdachtsmeldung braucht mindestens eine Hypothese, die durch mindestens eine Beobachtung mit dokumentierter Quelle gestützt ist, und eine namentlich verantwortete menschliche Entscheidung“ ist keine Empfehlung — sie ist eine Invariante. Im Aggregate kann sie technisch erzwungen werden. In einem Tabellenmodell bleibt sie eine Hoffnung, die in der Anwendungslogik verteilt herumliegt und an irgendeiner Stelle vergessen wird.

Eine Tabelle fragt: Passen die Typen? Ein Aggregate fragt: Ergibt dieser Zustand fachlich Sinn — und darf ich ihn überhaupt speichern?

Die Anatomie des EvidencePackage

Das Aggregate besteht aus einer Wurzel und mehreren Bausteinen, die der Sprache aus Leitstück 01 folgen. Es lebt dabei in einem eigenen Bounded Context — dem Investigation-Kontext aus Leitstück 01 —, getrennt von Screening, Monitoring und Reporting. Drei Begriffe trennen sauber: Entity (etwas mit Identität und Lebenslauf — z. B. das Package selbst), Value Object (unveränderlich, durch seinen Wert definiert — z. B. eine Quelle, ein Beweiswert) und Domain Event (etwas, das passiert ist und nicht zurückgenommen werden kann).

Die Invarianten — die eigentliche Substanz

Der Wert des Aggregate steckt nicht in seinen Feldern, sondern in den Regeln, die es schützt. Drei davon sind nicht verhandelbar.

Provenienz ist Pflicht. Ein Claim — eine Behauptung über die Welt, etwa „dieses Konto erhielt am 3. März eine Zahlung von 48.000 € aus Jurisdiktion X“ — existiert nur mit angehängter Provenance: Quelle, Abrufzeitpunkt, Verfahren. Eine Behauptung ohne Herkunft kann das Aggregate gar nicht aufnehmen. Das ist die technische Form des Satzes aus dem Dossier: Der Graph beweist nichts (Leitstück 06) — erst Quellenbindung macht aus einer Kante einen Beleg.

Eskalation braucht Substanz. Das Package darf nicht in den Zustand REPORTABLE übergehen, solange nicht mindestens eine Hypothese durch mindestens einen quellengebundenen Claim gestützt ist. Ein Verdacht „weil das Modell 0,9 sagt“ ist keine meldefähige Evidenz. Diese Invariante übersetzt die rechtliche Schwelle aus Leitstück 01 in eine Bedingung, die der Code durchsetzt. Sie ist dabei eine bewusste Modellierungsentscheidung dieses Dossiers — sie kann strenger ausfallen als das gesetzliche Minimum und gibt keinen konkreten Normtext wieder.

Jede Entscheidung hat ein Gesicht. Der Übergang in einen abschließenden Zustand verlangt eine HumanDecision mit benanntem Verantwortlichen, Begründung und Zeitpunkt. Eine Maschine darf vorbereiten, sortieren, vorschlagen — aber der abschließende Schritt trägt einen Namen. Das ist nicht Nostalgie, sondern Voraussetzung der aufsichtlichen Erklärbarkeit und der späteren Agentic-Audit-Pipeline (Leitstück 09).

Python · EvidencePackage als Aggregate Root mit erzwungenen Invariantenfrom dataclasses import dataclass
from datetime import datetime, timezone
from enum import Enum
import uuid

class DomainError(Exception):
    """Verletzte Invariante — dieser Zustand darf nicht entstehen."""

class PackageStatus(Enum):
    OPEN        = "open"
    UNDER_REVIEW= "under_review"
    REPORTABLE  = "reportable"     # §43-GwG-Schwelle erreicht
    CLOSED_NO_SUSPICION = "closed_no_suspicion"
    REPORTED    = "reported"

@dataclass(frozen=True)
class Provenance:          # Value Object — durch seinen Wert definiert
    source_id: str
    retrieved_at: datetime
    method_ref: str        # dokumentiertes Abruf-/Bewertungsverfahren

@dataclass(frozen=True)
class Claim:               # eine Behauptung — nie ohne Herkunft
    statement: str
    provenance: Provenance # Pflichtfeld: kein Claim ohne Provenienz
    confidence: float

@dataclass(frozen=True)
class Hypothesis:
    typology: str          # z.B. "structuring", "trade-based ML"
    supported_by: tuple[Claim, ...] = ()

@dataclass(frozen=True)
class HumanDecision:
    analyst_id: str        # jede Entscheidung hat ein Gesicht
    rationale: str
    decided_at: datetime
    outcome: PackageStatus

class EvidencePackage:    # Aggregate Root
    def __init__(self, subject_ref: str):
        self.id = str(uuid.uuid4())
        self.subject_ref = subject_ref
        self.status = PackageStatus.OPEN
        self._hypotheses: list[Hypothesis] = []
        self._events: list[dict] = []      # Domain Events

    def add_hypothesis(self, h: Hypothesis) -> None:
        # Invariante 1: Hypothese braucht quellengebundene Claims
        if not h.supported_by:
            raise DomainError("Hypothese ohne Claim ist Spekulation")
        self._hypotheses.append(h)
        self._emit("HypothesisFormed", typology=h.typology)

    def begin_review(self) -> None:
        # erlaubter Übergang: OPEN -> UNDER_REVIEW (keine Sprünge)
        if self.status is not PackageStatus.OPEN:
            raise DomainError("Review startet nur aus OPEN")
        self.status = PackageStatus.UNDER_REVIEW
        self._emit("ReviewStarted")

    def escalate_to_reportable(self) -> None:
        # Invariante 2a: nur aus UNDER_REVIEW — die State Machine erlaubt keine Sprünge
        if self.status is not PackageStatus.UNDER_REVIEW:
            raise DomainError("Eskalation nur aus UNDER_REVIEW")
        # Invariante 2b: Eskalation braucht Substanz
        supported = [h for h in self._hypotheses if h.supported_by]
        if not supported:
            raise DomainError("Kein gestützter Verdacht — nicht meldefähig")
        self.status = PackageStatus.REPORTABLE
        self._emit("EscalatedToReportable")

    def record_decision(self, d: HumanDecision) -> None:
        # Invariante 3: jede abschließende Entscheidung hat ein Gesicht
        if not d.analyst_id or not d.rationale:
            raise DomainError("Entscheidung braucht Verantwortlichen + Begründung")
        self.status = d.outcome
        self._emit("DecisionRecorded", by=d.analyst_id, outcome=d.outcome.value)

    def _emit(self, name: str, **data) -> None:
        self._events.append({"event": name, "at": datetime.now(timezone.utc), **data})

Man beachte, was hier nicht möglich ist: Es gibt keinen Weg, ein Package nach REPORTABLE zu bringen, ohne gestützte Hypothese. Es gibt keinen Setter für status. Der Zustand ändert sich nur über Methoden, die ihre Bedingungen prüfen und ein Event hinterlassen. Das ist der Punkt: Die Geschäftsregeln sind nicht dokumentiert, sie sind durchgesetzt.

Der Lebenszyklus als State Machine

Das Package bewegt sich nicht beliebig durch seine Zustände, sondern entlang erlaubter Übergänge. Diese Zustandsmaschine ist zugleich die Stelle, an der die spätere AMLA-RTS-Logik (Leitstück 05) andockt — denn Schwellen und Übergänge sind genau das, was die Aufsicht modelliert.

Domain Events: Wie das Aggregate mit der Welt spricht

Das Aggregate hält seine Konsistenzgrenze klein und dicht — aber es lebt nicht allein. Es kommuniziert nach außen über Domain Events: HypothesisFormed, EscalatedToReportable, DecisionRecorded, CaseReported. Diese Events sind die Schnittstelle zum Rest des Operating Models. Der FRAML-Kontext (Leitstück 04) hört auf dieselben Events, ohne in das Aggregate hineinzugreifen. Die Audit-Spur (Leitstück 03) entsteht aus dem Event-Strom, nicht aus nachträglichem Logging. Und das aufsichtliche Reporting liest die Events, statt die Datenbank zu durchforsten.

Der architektonische Gewinn ist Entkopplung mit Nachvollziehbarkeit. Statt dass fünf Systeme dieselbe Tabelle pollen und jeweils ihre eigene Interpretation bauen, gibt das Aggregate eine einzige, geordnete Wahrheit über das aus, was passiert ist. Wer das Event-Log liest, kann den gesamten Weg von „Signal eingegangen“ bis „Verdacht gemeldet“ rekonstruieren — in der richtigen Reihenfolge, mit Provenienz und mit Namen.

Ein gutes Aggregate ist geizig nach innen und großzügig nach außen: Es lässt fast nichts an seine Invarianten heran und teilt fast alles über seine Events mit.

Persistenz: Der Event-Strom als Quelle der Wahrheit

Wenn jede Zustandsänderung ohnehin ein Domain Event erzeugt, drängt sich eine Frage auf: Warum den aktuellen Zustand speichern und die Events nebenbei — und nicht die Events selbst als die eigentliche Wahrheit behandeln? Genau das ist die Idee des Event Sourcing. Statt eine Zeile zu überschreiben, hängt man jede Veränderung als unveränderliches Ereignis an einen Strom an; der aktuelle Zustand des Package ergibt sich aus dem Abspielen dieser Ereignisse von Beginn an.

Für die meisten Domänen ist das eine Geschmacksfrage. Für die Beweisführung ist es fast eine natürliche Konsequenz. Ein überschreibender Speicher kennt nur das Jetzt: Er weiß, dass ein Package REPORTED ist, aber nicht zwingend, wie und wann es dorthin kam. Ein Event-Strom kennt die ganze Geschichte — und zwar in der Reihenfolge, in der sie geschah, ohne dass jemand sie nachträglich rekonstruieren muss. Die Frage der Aufsicht „Was wussten Sie zu welchem Zeitpunkt?“ lässt sich dann nicht nur beantworten, sondern belegen: indem man den Strom bis zum fraglichen Zeitpunkt abspielt und den damaligen Zustand exakt wiederherstellt.

Das hat einen Preis. Event Sourcing ist anspruchsvoller in Abfrage und Migration, und man braucht zusätzlich aufbereitete Lesemodelle (Read Models / Projektionen) für die täglichen Sichten der Analysten. Es ist deshalb kein Pflichtmuster für jedes Aggregate. Aber für das EvidencePackage, dessen einziger Zweck die belastbare, zeitlich geordnete Begründung einer Entscheidung ist, fällt die Abwägung leicht: Hier ist die lückenlose Historie kein Nebenprodukt, sondern das Produkt. Derselbe Strom speist später unmittelbar das Event Ledger der agentischen Workflows (Leitstück 03) — Aggregate und Audit-Spur sprechen dann buchstäblich dieselbe Ereignissprache.

Wie groß darf ein Aggregate sein?

Die häufigste Fehlentscheidung beim Aggregate-Design ist die Größe. Die Versuchung ist, alles Verwandte hineinzuziehen: den Kunden, alle seine Konten, jede Transaktion, den vollständigen Beziehungsgraph. Das Ergebnis ist ein Gott-Aggregate, das bei jeder kleinen Änderung gesperrt werden muss, ständig in Konflikte läuft und am Ende nicht mehr ladbar ist, weil es halbe Datenbanken in den Speicher zieht. Die Designregel aus dem reiferen DDD lautet deshalb: Aggregate klein halten und über Identität referenzieren, statt zu enthalten.

Konkret besitzt das EvidencePackage seine Claims, Hypothesen und Decisions — sie sind nur in seinem Kontext sinnvoll und ändern sich gemeinsam. Es besitzt aber nicht den Kunden, das Konto oder den Graph. Diese referenziert es nur über stabile Verweise (subject_ref, Entitäts-IDs). Der Graph ist ein eigenes Gebilde mit eigenem Lebenszyklus (Leitstück 06); das Package zieht daraus nur die Kanten heran, die es als Claim mit Provenienz festhält. Die Faustregel: In eine Konsistenzgrenze gehört, was zusammen wahr sein muss — nicht, was zufällig zusammengehört.

Diese Disziplin hat einen unmittelbaren Nutzen für die Beweisführung. Weil das Package klein ist, ist es vollständig ladbar, vollständig prüfbar und vollständig als ein Gegenstand auditierbar. Ein Prüfer muss nicht fünf Tabellen joinen, um den Vorgang zu verstehen — er liest ein Aggregate und dessen Event-Strom.

Konsistenz über Aggregate-Grenzen hinweg

Wenn Aggregate klein sind, stellt sich sofort die nächste Frage: Wie hängen sie zusammen, ohne dass man sie wieder zu einem Klumpen verschmilzt? Die Antwort des DDD ist nüchtern: Innerhalb eines Aggregate herrscht starke Konsistenz — die Invarianten gelten sofort und immer. Zwischen Aggregaten herrscht eventual consistency — sie gleichen sich über Domain Events ab. Entscheidend ist dabei nicht eine bestimmte Verzögerung (die kann durchaus im Millisekundenbereich liegen), sondern der bewusste Verzicht auf transaktionale Atomarität über Aggregate-Grenzen hinweg. Innerhalb der Grenze schützt umgekehrt ein Versionszähler im Aggregate Root vor konkurrierenden Schreibzugriffen (optimistisches Sperren): Zwei gleichzeitige Änderungen am selben Package werden erkannt und die zweite zurückgewiesen, statt die erste stillschweigend zu überschreiben.

Das ist kein Kompromiss aus Bequemlichkeit, sondern fachlich richtig. Wenn ein EvidencePackage in den Zustand REPORTED übergeht, muss der Kundenstammsatz nicht in derselben Datenbanktransaktion sein Risikoprofil ändern. Er erfährt vom Ereignis CaseReported und reagiert, wenn es passt. Würde man beides in eine Transaktion zwingen, koppelte man zwei unabhängige Lebenszyklen aneinander und erzeugte genau die Sperren und Ausfälle, die agentische Echtzeitsysteme (Leitstück 08) nicht verkraften. Die Trennung ist die Voraussetzung für Skalierung — und für die FRAML-Architektur, in der Fraud- und AML-Kontext über geteilte Events kommunizieren, ohne ein gemeinsames Datenmodell zu teilen (Leitstück 04).

Ein durchgespielter Vorgang

Wie das im Zusammenspiel aussieht, zeigt ein knapper Durchlauf. Ein Transaktionsmonitoring-Alert geht ein: mehrere Bareinzahlungen knapp unter der Meldeschwelle, verteilt über drei Tage. Der Anti-Corruption Layer (Leitstück 01) übersetzt diesen Alert in ein Signal mit deklarierter Herkunft und legt ein neues EvidencePackage im Zustand OPEN an. Das ist noch kein Verdacht — nur ein Anfang mit einem Namen.

Eine Analystin — oder ein Agent unter ihrer Aufsicht (Leitstück 03) — zieht Beziehungen heran: dieselbe Einzahlerin taucht bei zwei weiteren Konten auf. Jede dieser Beobachtungen wird zu einem Claim mit Provenance — Quelle, Abrufzeitpunkt, Verfahren. Aus den Claims formt sich eine Hypothesis mit der Typologie „Structuring“. Erst jetzt, weil die Hypothese durch quellengebundene Claims gestützt ist, lässt das Aggregate den Übergang nach UNDER_REVIEW und schließlich die escalate_to_reportable()-Operation zu. Hätte die Analystin nur den Modell-Score gehabt, wäre die Eskalation an der Invariante gescheitert — kein gestützter Verdacht, nicht meldefähig.

Den Abschluss bildet eine HumanDecision: Name, Begründung, Zeitpunkt, Ergebnis REPORTED. Das Aggregate hat über den ganzen Weg eine geordnete Spur von Domain Events erzeugt — EvidenceCollected, HypothesisFormed, EscalatedToReportable, DecisionRecorded, CaseReported. Fragt die Aufsicht ein Jahr später nach der Grundlage dieser Meldung, lautet die Antwort nicht „das stand in vier Systemen verstreut“, sondern: hier ist der Vorgang, in Reihenfolge, mit Provenienz, mit Namen. Genau das ist der Übergang von Alerts zu Evidenz.

Der Unterschied zeigt sich erst im Audit: Ein zerlegtes System muss seine Geschichte rekonstruieren. Ein Aggregate hat sie nie verloren.

Was das Aggregate für die Aufsicht leistet

Die regulatorische Bewegung — AMLA, FATF, das Single Rulebook — verschiebt die Prüfung von der Prozessdokumentation hin zur Wirksamkeit. Geprüft wird nicht mehr nur, ob ein Institut ein Verfahren hat, sondern ob es im Einzelfall nachvollziehbar entschieden hat. Genau diese Frage beantwortet das EvidencePackage strukturell: Es hält pro Vorgang fest, welche Signale eingingen, welche Hypothesen daraus wurden, worauf sie sich stützen, wer wann auf welcher Grundlage entschied — und kann diese Kette als geordneten Event-Strom ausgeben.

Das ist der Übergang, den der Dossier-Titel benennt: von Alerts zur Evidenz. Der Alert bleibt, was er ist — ein maschinelles Signal mit niedrigem Beweiswert. Erst das Aggregate, das ihn mit Beziehung, Hypothese, Quelle und menschlicher Verantwortung zusammenbindet, macht aus ihm einen belastbaren Befund.

Kernsätze

Das Aggregate erzeugt also einen geordneten Strom von Entscheidungen und ihren Gründen. Doch sobald Maschinen — Agenten — an diesem Strom mitarbeiten, stellt sich die nächste Frage: Reicht es, einem Agenten über ein Protokoll Werkzeuge zugänglich zu machen, oder braucht es eine eigene Spur, die festhält, warum er was getan hat? Das ist Leitstück 03: MCP ist nicht Observability.

Markiert: RegTech · RegTech Architecture · Domain-Driven Design · AML · Evidence · Architektur