Leitstück 06 · Graph · FinCrime-Architektur 2026
Der Graph beweist nichts
Kanten zeigen Beziehungen. Beweiskraft entsteht erst durch Claims, Provenienz, Review-Status, Confidence und Quellenbindung — sonst produziert der Graph überzeugende Bilder und schwache Evidenz.
Ein Graph ist verführerisch. Man legt die Knoten aus, zieht die Linien, und plötzlich „zeigt“ das Netzwerk den Geldwäscher: hier das Zentrum, dort die Mule-Konten, da die verdeckte Kontrolle. Das Bild ist mächtig — und genau deshalb gefährlich. Eine Linie zwischen zwei Knoten ist keine Tatsache. Sie ist eine Behauptung, die jemand oder etwas aufgestellt hat, aus einer Quelle, mit einer Sicherheit. Wer Kanten wie Wahrheiten behandelt, baut ein System, das eindrucksvolle Diagramme erzeugt und vor der Aufsicht zusammenbricht.
Die Frage „Wer kontrolliert dieses Unternehmen?“ lässt sich als Graph elegant beantworten — solange niemand nachfragt, woher jede einzelne Kante stammt. Eine Beteiligung aus dem Transparenzregister ist etwas anderes als eine aus einer Selbstauskunft, und beide sind etwas anderes als eine algorithmisch abgeleitete Kante. Verschmilzt man sie zu einer einheitlichen Linie, geht genau die Information verloren, die einen Befund belastbar macht. Der Graph ist ein hervorragendes Werkzeug, um Beziehungen zu finden — und ein wertloses, um sie zu beweisen, wenn seine Kanten keine Herkunft tragen.
Warum Graphen verlocken — und wo sie kippen
Geldwäsche ist ein Beziehungsproblem, kein Transaktionsproblem (so die Architekturthese des gesamten Dossiers). Netzwerke aus Konten, Gegenstellen, Unternehmen und wirtschaftlich Berechtigten lassen sich als Graph natürlich abbilden, und Graph-Algorithmen — Zentralität, Community-Erkennung, kürzeste Pfade — finden Strukturen, die in tabellarischen Daten unsichtbar bleiben. Das ist der berechtigte Grund, warum Neo4j und Co. im FinCrime-Stack stehen.
Der Bruch kommt, wenn aus dem Such- ein Beweiswerkzeug werden soll. Eine Kante (A)-[:BESITZT {anteil:30}]->(B) sieht aus wie ein Faktum, ist aber eine Aussage mit Vorgeschichte: Stammt sie aus einem amtlichen Register, einer Kundenangabe, einem geleakten Dokument, einer KI-Inferenz? Hat sie ein Mensch geprüft? Gilt sie noch, oder ist sie zwei Jahre alt? Eine nackte Kante beantwortet nichts davon. Sie behauptet nur.
Ein Graph aus ungeprüften Kanten ist eine Meinung mit guter Grafik. Erst Herkunft, Sicherheit und Prüfung machen aus der Linie einen Beleg.
Der Reframe: die Kante als Claim
Die Lösung ist, die Kante zu reifizieren — sie nicht als simple Linie, sondern als eigenständigen Beweisgegenstand zu modellieren, der dieselben Eigenschaften trägt wie der Claim aus Leitstück 02. Eine Beziehung im Graphen besteht dann nicht aus „A besitzt B“, sondern aus: einer Aussage, einer Provenienz (Quelle, Abrufzeitpunkt, Verfahren), einer Confidence, einem Review-Status und einer zeitlichen Gültigkeit. Die Kante ist damit kein Faktum mehr, sondern ein datierter, geprüfter, quellengebundener Anspruch — derselbe Claim, nur als Beziehung.
Python · Die Kante als reifizierter Claim, nicht als nackte Liniefrom dataclasses import dataclass from datetime import date, datetime, timezone from enum import Enum class ReviewStatus(Enum): UNREVIEWED = "unreviewed" # maschinell, ungeprüft CONFIRMED = "confirmed" # menschlich bestätigt REFUTED = "refuted" # widerlegt — bleibt erhalten! class SourceKind(Enum): REGISTER = "official_register" # hohe Beweiskraft SELF_DECLARED = "self_declared" LEAK = "leaked_document" INFERRED = "model_inferred" # niedrige Beweiskraft @dataclass(frozen=True) class Provenance: source_kind: SourceKind source_id: str retrieved_at: datetime method_ref: str @dataclass(frozen=True) class EdgeClaim: # die Kante IST ein Claim (vgl. Leitstück 02) subject: str # A predicate: str # "owns_percent" object: str # B value: float # 30.0 provenance: Provenance # Pflicht — keine Kante ohne Herkunft confidence: float # 0..1 review: ReviewStatus = ReviewStatus.UNREVIEWED valid_from: date | None = None # zeitliche Gültigkeit valid_to: date | None = None def is_admissible(self, min_conf: float = 0.8) -> bool: # für Beweisführung: geprüft ODER hohe Confidence aus harter Quelle if self.review is ReviewStatus.REFUTED: return False if self.review is ReviewStatus.CONFIRMED: return True return (self.provenance.source_kind is SourceKind.REGISTER and self.confidence >= min_conf)
Widerspruch, nicht Überschreiben
Sobald Kanten Herkunft tragen, tritt ein Phänomen zutage, das die naive Grafik versteckt: Quellen widersprechen sich. Das Register sagt 30 %, ein geleaktes Dokument sagt 60 %, eine Selbstauskunft nennt 24,9 % — auffällig knapp unter der meldepflichtigen Schwelle. Ein System, das die Kante „aktualisiert“, löscht damit Beweismaterial. Richtig ist das Gegenteil: Beide Claims bleiben als parallele Kanten erhalten, jeder mit seiner Provenienz und seinem Review-Status. Der Widerspruch ist der Befund — nicht ein Datenfehler, den man wegbügelt.
Damit wird auch der Review-Status zur tragenden Eigenschaft. Eine widerlegte Kante wird nicht gelöscht, sondern als REFUTED markiert und behalten — denn die Tatsache, dass jemand etwas behauptet hat, das sich als falsch erwies, ist selbst Evidenz. Geldwäschestrukturen leben von genau solchen Diskrepanzen zwischen Erklärtem und Tatsächlichem (Leitstück 04). Ein Graph, der nur den jeweils „aktuellen Wahrheitsstand“ speichert, kann diese Diskrepanz gar nicht mehr zeigen.
Temporale Gültigkeit: Beteiligung ist ein Datum
Eine Beteiligung ist kein Zustand, sondern ein Zeitabschnitt. „A besitzt 30 % von B“ ist ohne Datum eine halbe Aussage: seit wann, bis wann? Wer im Januar 2024 wirtschaftlich Berechtigter war, muss es heute nicht mehr sein — und für eine Verdachtsmeldung, die einen Vorgang aus dem Vorjahr betrifft, zählt der damalige Stand, nicht der heutige. Ein Graph, der nur den jeweils neuesten Wert hält, kann die zentrale forensische Frage nicht beantworten: Wer kontrollierte dieses Unternehmen zum Zeitpunkt der Transaktion?
Deshalb tragen reifizierte Kanten ein valid_from und valid_to. Eine geänderte Beteiligung erzeugt keine Überschreibung, sondern eine neue Kante mit neuem Gültigkeitsbeginn; die alte bekommt ein Enddatum und bleibt erhalten. Eine Abfrage „Stand zum Datum T“ rekonstruiert dann den Graphen, wie er damals galt — dieselbe Logik des zeitlich rekonstruierbaren Zustands, die schon das EvidencePackage (Leitstück 02) und die Zustandsmaschine (Leitstück 05) tragen. Ohne diese Zeitachse ist jeder UBO-Befund nur eine Momentaufnahme, die rückwirkend nichts beweist.
Der Algorithmus-Trugschluss
Die zweite Falle ist subtiler und teurer. Graph-Algorithmen — Betweenness-Zentralität, Community-Detection, PageRank-Varianten — rechnen über Kanten, als wären sie gleichwertig. Lässt man sie über einen Graphen mit gemischter Provenienz laufen, entsteht eine Zahl mit drei Nachkommastellen, die auf Sand gebaut ist: Eine abgeleitete, ungeprüfte Kante zählt genauso viel wie eine bestätigte Registerbeteiligung. Das Ergebnis ist nicht falsch im Sinne der Mathematik, aber wertlos im Sinne der Beweisführung — und gefährlich, weil es so präzise aussieht.
Die Konsequenz für die Architektur: Algorithmen laufen nicht über den Rohgraphen, sondern über eine nach Beweiswert gefilterte oder gewichtete Projektion. Zentralität wird über bestätigte und hochkonfidente Kanten gerechnet; abgeleitete Kanten gehen, wenn überhaupt, mit reduziertem Gewicht ein und werden im Ergebnis als solche ausgewiesen. So bleibt nachvollziehbar, worauf eine „zentrale Rolle im Netzwerk“ tatsächlich beruht.
| Quelle einer Kante | Beweiswert |
|---|---|
| Amtliches Register, menschlich bestätigt | hoch — meldefähig |
| Amtliches Register, ungeprüft | mittel-hoch |
| Selbstauskunft des Kunden | mittel — gegenzuprüfen |
| Geleaktes Dokument | variabel — Quellenkritik nötig |
| Modell-Inferenz (KI), ungeprüft | niedrig — nur als Hinweis |
Die KI-Kante ist die gefährlichste
Unter allen Kantenarten verdient eine besondere Vorsicht: die maschinell abgeleitete. Entity Resolution verschmilzt „J. Petrov“ und „Jurij Petrov“ zu einer Identität; ein Sprachmodell liest aus einem Geschäftsbericht eine Kontrollbeziehung heraus; ein Embedding-Vergleich legt zwei Konten als „wahrscheinlich dieselbe Person“ zusammen. Diese Inferenzen sind nützlich — und sie sehen im Graphen exakt aus wie eine Registerbeteiligung. Genau das macht sie gefährlich: Sie tragen die Autorität einer harten Linie, ohne ihre Beweiskraft zu haben.
Die Architektur muss die KI-Kante deshalb sichtbar als das kennzeichnen, was sie ist: SourceKind.INFERRED, Review-Status UNREVIEWED, niedrige Confidence, im Zweifel nur als Hinweis und nicht als Beleg zugelassen. Sie ist ein hervorragender Ausgangspunkt für eine Ermittlung und ein miserabler Endpunkt für eine Meldung. Wer abgeleitete und bestätigte Kanten optisch wie rechnerisch gleichbehandelt, importiert die Halluzinationsneigung der Modelle direkt in die Beweisführung — der Bruch, vor dem schon Leitstück 03 bei agentischen Workflows gewarnt hat.
Provenienz entsteht an der Grenze — oder nie
Der häufigste Einwand lautet: „Wir haben schon einen Graphen mit Millionen Kanten — Herkunft nachträglich anzuhängen ist unmöglich.“ Das stimmt, und genau das ist der Punkt. Provenienz lässt sich nicht rekonstruieren; sie muss im Moment der Aufnahme entstehen. Jede Quelle, die in den Graphen schreibt — der Registerimport, das KYC-Formular, der Screening-Dienst, das Inferenzmodell —, stempelt ihre Kanten beim Eintritt mit SourceKind, Abrufzeitpunkt, Verfahren und Confidence. Wer das versäumt, kann es später nicht heilen.
Architektonisch ist das genau der Anti-Corruption Layer aus Leitstück 01: An jeder Grenze, an der fremde Daten in den Graphen übersetzt werden, sitzt die Stelle, die aus einer rohen Beziehung einen Claim mit Herkunft macht. Eine Kante ohne Provenienz darf gar nicht erst in den Graphen gelangen — so wie das EvidencePackage (Leitstück 02) keinen Claim ohne Quelle aufnimmt. Der Graph erbt seine Beweisfähigkeit nicht von seiner Struktur, sondern von der Disziplin an seinen Eingängen. Wird dort sauber gestempelt, trägt jede spätere Abfrage ihre Begründung mit; wird dort geschludert, hilft auch der schönste Algorithmus nicht mehr.
Wann ein Pfad zur Evidenz wird
Die eigentliche Stärke des Graphen liegt im Pfad: „A kontrolliert über C und D letztlich B.“ Doch ein Pfad ist nur so stark wie seine schwächste Kante. Hängt an einer Stelle eine ungeprüfte Inferenz, ist die ganze Kette nur ein Hinweis, kein Beweis — egal wie überzeugend das Gesamtbild wirkt. Ein beweisfähiger Pfad verlangt deshalb, dass jede Kante auf ihm Provenienz trägt und die schwächste ausdrücklich benannt wird. Erst dann lässt sich der Pfad als Claim-Kette in ein EvidencePackage (Leitstück 02) übernehmen — mit der ehrlichen Aussage über seine Belastbarkeit.
Damit schließt sich der Kreis zum Dossier-Titel. Der Graph liefert die Beziehung — die Stufe nach dem Signal im Bogen von Alerts zur Evidenz. Aber er liefert sie als Hypothese, nicht als Beweis. Beweiskraft entsteht erst durch das, was die naive Grafik weglässt: Quelle, Sicherheit, Prüfung, Gültigkeit. Das ist keine Verzierung des Graphen, sondern seine Voraussetzung als Beweismittel.
Ein durchgespielter Fall
Eine Analystin findet im Graphen einen schönen Pfad: Person A kontrolliert über die Holding C die Firma D, und D zahlt an das verdächtige Konto B. Vier Kanten, ein überzeugendes Bild. Erst die Provenienz entzaubert es. Die Kante A→C stammt aus dem Transparenzregister, bestätigt, hohe Confidence — admissibel. Die Kante C→D ist eine Selbstauskunft, ungeprüft. Die Kante „A kontrolliert C“ hat zusätzlich eine zweite, widersprechende Version aus einem Leak (60 % statt der gemeldeten 24,9 %) — als REFUTED markiert war sie nie, sie steht als konkurrierender Claim daneben. Und die letzte Verbindung D→B ist eine KI-Inferenz aus Namensähnlichkeit, INFERRED, Confidence 0,4.
Der is_admissible-Filter macht aus dem überzeugenden Bild eine ehrliche Lage: Eine harte Kante, eine prüfbedürftige, ein dokumentierter Widerspruch, ein bloßer Hinweis. Der Pfad ist damit kein Beweis, sondern eine gut begründete Hypothese mit einer klar benannten schwächsten Stelle — der KI-Kante D→B. Genau das gehört so ins EvidencePackage: nicht „A wäscht über D Geld“, sondern „Pfad mit drei belegten und einer abgeleiteten Kante; der Widerspruch bei der Beteiligungshöhe ist selbst auffällig“. Aus dem Fund wird eine Ermittlungsrichtung, kein vorschneller Befund.
Anti-Muster
- Die nackte Kante. Eine Beziehung ohne Provenienz, Confidence und Review ist eine Behauptung mit guter Grafik.
- Update statt Versionierung. Wer widersprüchliche Kanten überschreibt, löscht Beweismaterial. Claims bleiben parallel erhalten.
- Algorithmen über Rohgraphen. Zentralität über gemischte Provenienz erzeugt präzise wirkende, wertlose Zahlen. Erst filtern/gewichten, dann rechnen.
- Der schwächste-Kante-blinde Pfad. Ein Pfad ist nur so beweisfähig wie sein schwächstes Glied — das gehört ausgewiesen, nicht versteckt.
Kernsätze
Was bleibt
- Eine Kante ist ein Claim. Aussage plus Provenienz, Confidence, Review-Status und Gültigkeit — nicht eine Tatsache.
- Widerspruch ist Befund. Konkurrierende Claims bleiben parallel erhalten; auch Widerlegtes wird behalten.
- Rechne nicht über den Rohgraphen. Graph-Algorithmen brauchen eine nach Beweiswert gewichtete Projektion.
- Ein Pfad ist so stark wie seine schwächste Kante. Beweisfähig nur, wenn jede Kante Herkunft trägt.
- Finden ≠ beweisen. Der Graph liefert Beziehungen als Hypothese; Evidenz entsteht erst durch Quellenbindung.
Der reifizierte Graph hält Beziehungen, Quellen und Widersprüche zusammen — aber er setzt voraus, dass die Daten überhaupt zusammenfließen dürfen. Was aber, wenn die entscheidenden Kanten über Institute und Jurisdiktionen verstreut sind und niemand sie zentral sammeln darf? Dann braucht es föderierte Erkennung ohne Rohdatenhalde — das Thema von Leitstück 07: Project Aurora und Privacy-Enhancing Technologies.
Quellen & Bezug
- Property-Graph-Modellierung und Reification von Beziehungen (z. B. Neo4j): Kanten mit Eigenschaften, intermediäre Knoten für komplexe, belegte Beziehungen.
- Graph-Algorithmen (Zentralität, Community-Detection) und ihre Abhängigkeit von Kantenqualität/-gewichtung.
- Eric Evans / Vaughn Vernon, Domain-Driven Design — Claim, Value Object, Provenienz; Anschluss an Leitstück 02 (EvidencePackage), 04 (deklariert vs. tatsächlich), 05 (Zustände), 10 (UBO-Traversierung).
- EU-AML-Rahmen: Beneficial-Ownership-Transparenz und die Bedeutung quellengebundener Beteiligungsdaten (Vertiefung in Leitstück 10).












