Leitstück 01 · Sprache · FinCrime-Architektur 2026

Die Ubiquitous Language des Verdachts

Warum FinCrime-Analysten und Engineers eine gemeinsame Ontologie brauchen, bevor sie gemeinsame Systeme bauen — und warum jeder ungeklärte Begriff später als fehlerhafte Evidenz wieder auftaucht.

Zwei Teams sehen auf denselben Bildschirm und meinen nicht dasselbe. Der Analyst liest „Alert“ als Anfang einer Untersuchung — als Frage, die er beantworten muss. Der Engineer liest „Alert“ als Datensatz mit Status, Zeitstempel und Fremdschlüssel. Beide haben recht, und genau das ist das Problem. Solange „Alert“, „Treffer“, „Kunde“, „Risiko“ und „Verdacht“ in Code und Gespräch unterschiedliche Dinge bedeuten, baut ein Institut keine gemeinsame Plattform, sondern zwei Systeme, die zufällig dieselbe Datenbank teilen.

Die teuersten Fehler in Compliance-Systemen sind selten Programmierfehler. Es sind Übersetzungsfehler. Eine Regel feuert auf einen „Treffer“, aber der Treffer war ein Namensabgleich gegen eine Sanktionsliste, kein Transaktionsmuster — und die nachgelagerte Logik behandelt beide gleich. Ein Modell bewertet „Risiko“, aber niemand kann im Audit erklären, ob das inhärentes Risiko, Restrisiko nach Kontrollen oder schlicht der Score eines Klassifikators war. Ein Fall wird „geschlossen“, aber die Aufsicht fragt, ob „geschlossen“ heißt: ohne Verdacht, mit gemeldetem Verdacht, oder mangels Kapazität liegengelassen. Jede dieser Lücken ist eine Stelle, an der aus einem Signal kein belastbarer Befund werden kann.

Was Ubiquitous Language wirklich heißt

Der Begriff stammt aus dem Domain-Driven Design von Eric Evans. Er wird oft missverstanden als „wir schreiben ein Glossar“. Ein Glossar als PDF im Confluence-Wiki ist das Gegenteil dessen, was gemeint ist. Ubiquitous Language ist eine Sprache, die überall dieselbe ist: im Gespräch zwischen Analyst und Entwickler, im Klassennamen, im Datenbankfeld, im Test, im Logeintrag — und am Ende in der Begründung einer Verdachtsmeldung. Wenn die Analystin von einer „Geschäftsbeziehung“ spricht und im Code eine Klasse BusinessRelationship existiert, deren Lebenszyklus genau das abbildet, was die Analystin meint, dann lebt die Sprache. Wenn der Code stattdessen eine Tabelle customer_accounts hat und „Geschäftsbeziehung“ nur in der Präsentation der Compliance-Abteilung vorkommt, ist die Sprache tot, bevor das System gebaut ist.

Der entscheidende Punkt: Die Sprache ist kein Beiwerk zum Modell, sie ist das Modell. Wer die Begriffe klärt, klärt die Domäne. Wer die Begriffe vage lässt, verschiebt die Klärung auf den Zeitpunkt, an dem es teuer wird — in die Fallbearbeitung, in den Prüfungsbericht, in das gerichtsfeste Dokument.

Eine gemeinsame Datenbank ist keine gemeinsame Sprache. Sie ist nur ein gemeinsamer Ort, an dem zwei Missverständnisse nebeneinander gespeichert werden.

Die Sprache des Verdachts ist systematisch mehrdeutig

Anders als in vielen Domänen ist die Mehrdeutigkeit hier kein Zufall, sondern strukturell. Vier Beispiele, an denen sich täglich Geld und Haftung entscheiden.

„Treffer“ ist nicht gleich „Treffer“

Ein Sanktionslisten-Treffer ist eine Aussage über Identität: Diese Person könnte die gelistete Person sein. Ein Transaktionsmonitoring-Alert ist eine Aussage über Verhalten: Dieses Muster weicht von der Erwartung ab. Ein Adverse-Media-Treffer ist eine Aussage über Reputation. Diese drei haben völlig verschiedene Falsch-Positiv-Profile, verschiedene Beweiswerte und verschiedene Eskalationspfade. Werden sie unter einem einzigen Feld match zusammengefasst, entsteht ein System, das nicht mehr weiß, was es eigentlich gefunden hat.

„Kunde“ ist eine Rolle, kein Objekt

Ist der „Kunde“ die natürliche Person, die juristische Person, der Kontoinhaber, der wirtschaftlich Berechtigte (UBO), der Bevollmächtigte oder die Geschäftsbeziehung als Ganzes? In KYC-Systemen kollabieren diese Rollen regelmäßig zu einer einzigen customer_id — und genau dort verschwindet die Information, die für Beneficial-Ownership-Analysen und UBO-Verifikation gebraucht wird. „Kunde“ ist keine Entität, sondern eine Rolle, die eine Partei in einem bestimmten Kontext einnimmt.

„Risiko“ trägt drei Bedeutungen

Inhärentes Risiko, Restrisiko nach Kontrollen und der numerische Score eines Modells sind drei verschiedene Größen. Die Aufsicht — und unter dem EU-Single-Rulebook zunehmend explizit — verlangt, dass ein Institut sein Risikoprofil erklären kann. Ein System, das nur eine Zahl risk = 0.83 speichert, kann diese Frage nicht beantworten. Es weiß nicht, ob 0,83 vor oder nach Kontrollen gilt, woraus es sich zusammensetzt und wer es verantwortet.

„Verdacht“ hat eine operative und eine rechtliche Schwelle

Operativer Verdacht entsteht, wenn ein Analyst stutzt. Der meldepflichtige Verdacht im Sinne des Geldwäschegesetzes (in Deutschland § 43 GwG) ist eine rechtliche Schwelle mit eigenem Tatbestand. Zwischen beiden liegt die gesamte Ermittlungsarbeit. Ein System, das „suspicious: true/false“ speichert, hat diese Schwelle wegabstrahiert — und damit genau die Stelle gelöscht, an der eine menschliche, begründete Entscheidung dokumentiert werden müsste.

Ontologie vor System

Die naheliegende Reaktion lautet: „Das klären wir, wenn wir das Datenmodell bauen.“ Das ist der teure Weg. Eine gemeinsame Sprache lässt sich nicht nachträglich verschrauben, weil bis dahin jede Tabelle, jede API und jedes Dashboard die alten Mehrdeutigkeiten bereits einzementiert hat. Die Klärung muss vor dem System stattfinden — und sie ist selbst Modellierungsarbeit.

Das wirksamste Format dafür ist eine Sitzung, in der Analysten und Engineers gemeinsam die Domäne durchspielen — was in der DDD-Praxis als Event Storming firmiert, eine von Alberto Brandolini (2013) geprägte Workshop-Methode. Man legt nicht fest, welche Tabellen es gibt, sondern welche Ereignisse in der Wirklichkeit passieren: „Eine Geschäftsbeziehung wurde begründet.“ „Ein Schwellenwert wurde überschritten.“ „Ein Verdacht wurde gemeldet.“ Jedes Ereignis zwingt das Team, die Substantive zu benennen, die darin vorkommen — und die Verben, die sie verändern. Die Begriffe, die dabei überleben, sind die Kandidaten für die Ubiquitous Language.

Der härteste Akzeptanztest für diese Sprache ist die Verdachtsmeldung selbst. Wenn die Begründung einer SAR/Verdachtsmeldung sich nicht aus den Begriffen des Systems formulieren lässt, ohne dass ein Mensch sie nachträglich „übersetzt“, dann ist die Sprache des Systems nicht die Sprache des Verdachts. Dann produziert das System Arbeit, aber keine Evidenz — exakt der Bruch, den dieses Dossier schließen will.

Glossar-as-Code: die Sprache erzwingen

Eine lebende Sprache lässt sich im Typsystem verankern. Statt freitextlicher Felder und magischer Strings werden die zentralen Begriffe zu Typen, die illegale Zustände unmöglich machen. Das ist kein Selbstzweck: Jeder Wert, der nur als Typ existieren kann, ist ein Wert, über dessen Bedeutung sich Analyst und Engineer einig sein mussten.

Python · Sprache als Typsystem statt magischer Stringsfrom dataclasses import dataclass
from enum import Enum

class SignalKind(Enum):
    # Ein "Treffer" ist nicht ein Ding — er hat eine Herkunft
    SANCTIONS_NAME_MATCH = "sanctions_name_match"   # Identitätsaussage
    TM_BEHAVIOUR_ALERT   = "tm_behaviour_alert"     # Verhaltensaussage
    ADVERSE_MEDIA_HIT    = "adverse_media_hit"      # Reputationsaussage

class PartyRole(Enum):
    # "Kunde" ist eine Rolle in einem Kontext, kein Objekt
    ACCOUNT_HOLDER     = "account_holder"
    BENEFICIAL_OWNER   = "beneficial_owner"
    AUTHORISED_SIGNER  = "authorised_signer"
    LEGAL_ENTITY       = "legal_entity"

class SuspicionLevel(Enum):
    # Operative Stufen UND die rechtliche Schwelle — getrennt
    NONE        = "none"
    OPERATIONAL = "operational"        # Analyst stutzt
    REPORTABLE  = "reportable_§43_gwg"  # meldepflichtige Schwelle

@dataclass(frozen=True)
class RiskRating:
    # Risiko trägt drei Bedeutungen — also drei Felder, nicht eine Zahl
    inherent: float
    residual: float
    model_score: float
    method_ref: str  # Verweis auf das dokumentierte Bewertungsverfahren

    def __post_init__(self):
        if not (0 <= self.inherent <= 1 and 0 <= self.residual <= 1):
            raise ValueError("Risiko ist normiert auf [0,1] und stets erklärbar")

Der Gewinn ist nicht die Eleganz des Codes. Der Gewinn ist, dass kein Entwickler mehr stillschweigend „Risiko = 0,83“ speichern kann, ohne sich zu entscheiden, welches Risiko gemeint ist und auf welches Verfahren es sich beruft. Die Sprache ist im Compiler verankert, nicht im Wiki.

Bounded Contexts: Wo die Sprache absichtlich auseinanderfällt

„Eine Sprache für alles“ ist eine Illusion — und im DDD ausdrücklich nicht das Ziel. Derselbe Begriff darf in verschiedenen Teilen des Systems Verschiedenes bedeuten, solange die Grenze, an der die Bedeutung wechselt, explizit ist. Diese Teile heißen Bounded Contexts. Im FinCrime-Operating-Model sind mindestens vier davon natürlich:

Der Screening-Kontext kennt „Treffer“ als Identitäts- und Listenabgleich. Der Monitoring-Kontext kennt „Alert“ als Verhaltensabweichung. Der Investigation-/Case-Kontext kennt „Verdacht“, „Hypothese“ und „Evidenz“. Der Reporting-Kontext kennt die rechtliche Schwelle, die Verdachtsmeldung und die aufsichtliche Definition. In jedem Kontext ist „Kunde“, „Risiko“ und „Verdacht“ anders gefärbt — und das ist richtig so. Falsch wird es erst, wenn die Begriffe ungeprüft über die Grenze wandern.

Der Anti-Corruption Layer (ACL) ist der praktische Hebel: An jeder Kontextgrenze sitzt eine Übersetzungsschicht, die das fremde Vokabular in die eigene Sprache überführt. Ein Monitoring-Alert wird beim Eintritt in den Investigation-Kontext nicht einfach als „Alert“ weitergereicht, sondern als Signal mit deklarierter Herkunft und deklariertem Beweiswert aufgenommen. So bleibt die Sprache jedes Kontexts rein — und die Herkunft jeder Aussage nachvollziehbar. Genau diese saubere Trennung ist die Voraussetzung dafür, dass FRAML (Leitstück 04) durch geteilte Events statt durch ein verschmolzenes Datenmodell funktioniert.

Der Anschluss an die Aufsicht

Es gibt einen externen Mitautor dieser Sprache, den viele Architekturen übersehen: die Aufsicht. Mit dem EU-Single-Rulebook werden zentrale Begriffe nicht mehr hausintern definiert, sondern europaweit harmonisiert. Die AMLA arbeitet an dreizehn Regulatory Technical Standards und sechs Implementing Technical Standards; die AML-Verordnung (AMLR) und die sechste Geldwäscherichtlinie (AMLD6) gelten ab dem 10. Juli 2027. Darunter ist ausdrücklich ein RTS zu den Kriterien, anhand derer eine „Geschäftsbeziehung“ von einer „gelegentlichen Transaktion“ abgegrenzt wird (Art. 19(9) AMLR) — also genau jene Begriffe, über deren Bedeutung Analyst und Engineer sich ohnehin einigen müssen.

Das verändert die Aufgabe. Die Ubiquitous Language eines Instituts muss anschlussfähig an die regulatorische Sprache sein, sonst lässt sich Wirksamkeit nicht nachweisen. Wenn die Aufsicht „Geschäftsbeziehung“ als Zustand mit definierten Schwellen versteht (das Thema von Leitstück 05) und das interne System „Geschäftsbeziehung“ nur als Datumsfeld kennt, dann scheitert nicht die Technik, sondern die Beweisführung. Die Sprache des Verdachts wird so von einer internen Konvention zu einer Schnittstelle gegenüber dem Regulator.

Die Aufsicht prüft längst nicht mehr nur Prozesse. Sie prüft, ob ein Institut erklären kann, was seine eigenen Begriffe bedeuten — und ob das System dieselbe Sprache spricht wie der Bericht.

So findet man die Sprache: ein durchgespieltes Event Storming

Theorie hilft wenig, wenn unklar bleibt, wie die Begriffe konkret entstehen. Spielen wir eine kurze Sitzung durch — Analystin, Ermittler und zwei Engineers vor einer Wand. Niemand spricht über Tabellen. Die erste Frage lautet schlicht: Was passiert in der Wirklichkeit? Die Antworten kommen als Ereignisse, in der Vergangenheitsform, weil ein Ereignis etwas ist, das geschehen ist: „Eine Geschäftsbeziehung wurde begründet.“ „Eine Transaktion wurde ausgeführt.“ „Ein Schwellenwert wurde überschritten.“ „Ein Alert wurde erzeugt.“ „Eine Hypothese wurde gebildet.“ „Ein Verdacht wurde gemeldet.“

Jetzt beginnt die eigentliche Arbeit, und sie ist sprachlich. Beim Ereignis „Ein Alert wurde erzeugt“ hakt der Ermittler ein: Welcher Alert? Ein Listentreffer oder eine Verhaltensabweichung? Damit ist SignalKind geboren — nicht als Designentscheidung, sondern weil zwei Fachleute gemerkt haben, dass sie verschiedene Dinge meinten. Beim Ereignis „Eine Geschäftsbeziehung wurde begründet“ fragt ein Engineer: Ab wann gilt sie als begründet — ab Vertragsschluss, ab erster Transaktion, ab Überschreiten eines Betrags? Die Analystin zögert, und in diesem Zögern steckt die spätere AMLA-Schwellenlogik aus Leitstück 05. Der Begriff „Geschäftsbeziehung“ ist also kein Datumsfeld, sondern ein Zustand mit einem Eintrittskriterium, das die Aufsicht mitdefiniert.

Aus einer einzigen Stunde fallen so drei Arten von Artefakten: Ereignisse (was geschah), die zu Domain Events werden; Befehle (was jemand auslöste), die zu Methoden werden; und vor allem die Substantive, über deren Bedeutung gerungen wurde — die Kandidaten der Ubiquitous Language. Entscheidend ist, was man nicht tut: Man schreibt das Ergebnis nicht als hübsches Glossar weg, das niemand mehr liest. Man überführt es direkt in Typen, Tests und Methodennamen, solange die Diskussion noch frisch ist. Ein Begriff, der die Sitzung überlebt, aber nicht im Code landet, ist binnen Wochen wieder unscharf.

Der Lackmustest am Ende der Sitzung ist immer derselbe: Man nimmt einen realen, bereits gemeldeten Fall und versucht, seine Begründung ausschließlich mit den eben gefundenen Begriffen zu erzählen. Gelingt das ohne Übersetzung, trägt die Sprache. Stolpert man — „hier müsste ich eigentlich sagen…“ — fehlt ein Begriff, und man hat ihn gefunden, bevor er Geld gekostet hat.

Die Sprache lebt — also versioniert sie sich

Eine Ubiquitous Language ist kein einmaliges Projekt, sondern ein gepflegter Bestand. Geldwäschetypologien verändern sich, neue Zahlungswege entstehen, und die regulatorische Sprache wird mit jeder RTS-Konsultation präziser. Wenn die AMLA die Abgrenzung zwischen Geschäftsbeziehung und gelegentlicher Transaktion schärft, ist das eine Änderung an der Sprache des Instituts — und sie muss denselben Weg gehen wie eine Codeänderung: nachvollziehbar, versioniert, getestet.

Praktisch heißt das, die zentralen Begriffe an einem einzigen Ort zu definieren, von dem aus Code, Tests und Dokumentation generiert oder geprüft werden, statt sie in Wiki, Datenbank und Quelltext dreifach und widersprüchlich zu halten. Wer eine Bedeutung ändert, ändert sie an dieser einen Stelle, und die Pipeline zeigt, wo es bricht. Das klingt nach Mehraufwand, ist aber das Gegenteil: Es ist die einzige Form, in der eine Definition über Jahre konsistent bleibt — und genau Konsistenz über Zeit ist es, was die Aufsicht im Wirksamkeitstest sehen will. Ein Institut, das im Mai „Risiko“ anders verwendet als im November, kann seine eigenen Befunde nicht vergleichen, geschweige denn verteidigen.

Begriffe altern. Eine Sprache, die sich nicht versionieren lässt, zerfällt im Stillen — und der Zerfall fällt erst auf, wenn die Aufsicht zwei widersprüchliche Befunde nebeneinanderlegt.

Kernsätze

Damit ist die Grundlage gelegt. Steht die Sprache, lässt sich das erste echte Bauteil modellieren — das Aggregate, das aus Signal, Beziehung, Hypothese, Quelle und menschlicher Entscheidung einen zusammenhängenden Beweisgegenstand macht. Das ist Leitstück 02: Das EvidencePackage-Aggregate.

Markiert: RegTech · RegTech Architecture · Domain-Driven Design · AMLA · Compliance · Architektur