Welche Karten getestet wurden — bevor sie im Abzug verwendet werden.
Pattern Sieve™ erkennt Kartentest und Karten-Enumeration am Acquirer-Knoten, händlerübergreifend und vor der Autorisierung — und führt die Erkenntnis dem Aussteller zu. Kein Screening: Screening fragt „ist diese Partei sanktioniert?", zustandslos gegen eine Liste. Pattern Sieve fragt „ist dieses Muster auffällig?" — und ein Muster ist in einer einzelnen Transaktion grundsätzlich nicht sichtbar.
Was Pattern Sieve™ ist — und was nicht
- Mustererkennung über Zeit und über Entitäten — Fenster, Identitätsgraph, Rückkopplung
- Acquirer-seitig, vor der Weitergabe an das Kartennetz
- Cross-Merchant: eine Karte über viele Händler desselben Acquirers
- Händlerübergreifende Karten-Attribution ohne Klartext-PAN
- Ein Dienst, der empfiehlt — im Schattenbetrieb ohne Wirkung
- Kein Sanktionsscreening. Das ist Sanction Sieve™ — es prüft Namen, Firmen und IBANs gegen Listen
- Keine Betrugsentscheidung. Der Dienst empfiehlt, ein Mensch oder das Regelwerk des Kunden entscheidet
- Keine AML-Pflicht. Der AML-Kunde des Acquirers ist der Händler — Kartentest läuft zwischen Angreifer und vielen Händlern
- Keine Cloud. Der Dienst läuft beim Acquirer, unter dessen Kontrolle
- Keine Behauptung ohne Messung. Siehe den Kasten oben
Der Aussteller sieht den Test nicht. Der Acquirer sieht ihn.
Mastercard beschreibt die Rollentrennung in seinen Security Rules & Program Standards selbst — und liefert damit die präziseste Formulierung des Produktraums: „Issuers find compromised cards. Acquirers find affected merchants."
Wer nur gebuchte Umsätze überwacht, sieht den Test nicht: die Autorisierung ist der interessante Moment, und die Ablehnung ist kein Betrugslabel — meistens heisst sie „keine Deckung" und beschreibt einen ehrlichen Kunden. Erst die Verbindung aus vielen Ablehnungen mit jeweils anderer Karte trennt beides.
Und die regulatorische Lage ist eindeutig: für Autorisierungen gibt es keine Meldepflicht. Deshalb ist der Aussteller blind, obwohl die Information bei ihm ankommt.
Elf Regeln — jede mit ihrer Quelle
Jede Regel trägt im Code ihre Herkunft: BELEGT heisst, eine Netzwerkregel, ein Patent oder eine Aufsichtsquelle beschreibt den Mechanismus. ANNAHME heisst, die Kennzahl oder die Schwelle ist unsere eigene Setzung. Diese Trennung steht nicht im Kleingedruckten, sondern an der Regel selbst — und sie ist der Grund, warum hier keine Trefferquote steht.
| Regel | Erkennt | Quelle |
|---|---|---|
| C1 Integrität | Widerspruch zwischen Behauptung des Clients und Beobachtung | Architektur — unsere Schicht |
| C2 Netzherkunft | Hosting-Netz bei behauptetem Privatgerät | RFC 6269 / Mastercard CGNAT-Auflage |
| C3 Klon-Vielfalt | Eine Karte, viele Geräte (Klon-Fächer) | Visa US8473415B2 — Umfang |
| C4 Händlerübergreifend | Ein Gerät über viele Händler — nur mit Zweitsignal | CGNAT-Auflage (gemessen, W2-A3) |
| C5 BIN-Fächerung | Ein Gerät, viele Ausgabestellen in einer Stunde | CGNAT-Auflage |
| C6 Kartenvalidierung | Kleinstbetrag-Pre-Auth ohne Buchung | Visa §7.3.10.1/7.3.10.2 (AV-Kanal, 0,00/1,00 EUR) |
| C7 Kartenzahl je Eingang | Kartenfächerung — peer-relativ, nicht absolut | gemessen (W2-A7): absolut flaggt 15/15 Händler |
| C8 Ablehnungsfolge | Serie von Ablehnungen bei EINEM Händler, jede mit anderer Karte | Incode-Defaults (Analogie); Verbindung beider Zähler: ANNAHME |
| C9 Wiederkehr | Dieselbe Kennung kehrt öfter wieder, als der Reset-Vorteil erklärt | Arkose Labs US 11,539,697 B1, Claim 5 |
| C10 Detector Probing | Wiederholte, gleichförmige Versuche zur Sondierung der Abwehr | Visa US8473415B2 — „evaluating the fraud detection mechanisms" |
| C11 Händler-Zusammensetzung | Hosting-Anteil über dem der Peers | gemessen (W2-A7): 1 Alarm, 0 Fehlalarme |
⚠️ Die Schwellen sind ANNAHMEN. Alle vier Entscheidungsstufen (Review 3, Step-up 4, Hold 5, Block 6) sind gesetzt, nicht hergeleitet — ihre Herleitung aus Daten ist ein offener Arbeitspunkt. Eine Regel, die auf generierten Daten anschlägt, beweist, dass unser Code korrekt ist; sie beweist nicht, dass sie Betrug findet.
Sieben Schichten, ein Durchlauf
Acquirer-Format → kanonisches Schema. Fehlt ein Pflichtfeld, wird der Satz abgelehnt — nicht vervollständigt.
Karte, Gerät, Händler, Netz als Knoten — die Verknüpfung über Vorgänge und Zeit.
Fenster von einer Minute bis 60 Tage, je Vorgang und je Entität — nicht als Portfolio-Kennzahl.
Jede Regel liest ausschliesslich Felder dieses Vorgangs oder dieser Entität.
Vier Stufen, deterministischer Hash, Fail-open-Wächter mit Latenzbudget und Alarmierung.
Fälle, Dispositionen mit Akteur und Begründung, unveränderliches Audit-Log auf Datenbankebene.
Aussteller-Ergebnisse und Analysten-Labels getrennt geführt — die Trennung ist der Grund, warum später eine Rate messbar wird.
Was der Dienst strukturell nicht kann
Diese Zusagen sind keine Absichtserklärungen, sondern Eigenschaften des Codes — jede mit einer Probe, die nachweisen kann, dass sie fällt.
Der Dienst empfiehlt und wirkt nicht. Der scharfe Betrieb ist gesperrt und verlangt eine dokumentierte, schriftliche Entsperrung — ein blosses „true" genügt nicht.
Kein Standardwert, keine Hintertür. Der Prozess endet mit Exit 2 und nennt den Grund. Die Prüfung ist eine Erlaubnisliste: ein Tippfehler in der Umgebungsvariablen öffnet nichts.
Herkünfte stehen auf einer Liste. Der Mandant kommt aus dem Kopf, nie aus dem Rumpf — sonst könnte ein Aufrufer einen fremden Mandanten adressieren.
Eine PAN wird entfernt, bevor ein Vorgang gespeichert wird — auch auf dem angenommenen Pfad. Eine Nachprüfung bricht den Lauf ab, wenn doch eine hineinkommt.
Ändern und Löschen werden von der Datenbank selbst verweigert. Jede Disposition und jeder Notaus verlangen Akteur und Begründung.
Fehlt ein Feld, entsteht eine Lücke — keine Null. Eine Null wäre eine Behauptung („kostenloser Vorgang") und ist zusätzlich ein Kartentest-Muster. Eine Wächterregel verbietet Ersatzwerte im Produktionspfad.
Der Acquirer-Datenvertrag
Damit Pattern Sieve nicht blind ist, braucht es genau sechs Pflichtfelder — und fünf, die eine Regel erst messbar machen. Fehlt ein Pflichtfeld, wird die Nachricht abgelehnt und der Acquirer erfährt, welches. Vervollständigt wird nichts.
transaction_id— Kennung beim Acquirer. Auf ihr steht die Idempotenz: ein Retry darf keinen zweiten Fall erzeugentype—pre_auth/auth/capture/reversal… C6 hängt an Pre-Auth gegen Buchungtimestamp— die Transaktionszeit, nicht die Zustellzeit. Alle Fenster rechnen daraufamount— Minor Units. Kleinstbeträge sind das Kartentest-Muster Nr. 1currency— ISO-4217channel—ecom/pos/moto/atm/recurring. Ist der Kanal eine Eigenschaft des Feeds, wird er als erklärte Annahme gesetzt — nachweisbar angewandt, nicht als Code-Standardwert
device_fingerprint— eine stabile Kennung, nicht „Windows". Drei von elf Regeln sind ausschliesslich geräteabhängigpayment_token— ein irreversibler Token des Acquirers. Das Kernversprechen hängt daranmid— Händlerkennung. Ohne sie verschmelzen alle Händler zu einemissuer_response— die Rohantwort. Kein Betrugslabel: meistens heisst sie „keine Deckung"mccundbin— Kategorie und Ausgabestelle
Keine PAN im Klartext — und ausdrücklich auch kein selbstgebauter Hash darüber. SHA-256 ohne Salt ist bei der geringen Entropie einer Kartennummer brute-force-bar; das als Anonymisierung zu bezeichnen wäre eine Falschaussage. Der Weg ist ein irreversibler Token des Acquirers. Der Dienst arbeitet mit pseudonymen Kennungen: was nicht ankommt, muss nicht geschützt werden.
Ein Emulator, der den Acquirer spielt
Bevor es einen Design-Partner gibt, wird der Datenzugang simuliert — und zwar ausschliesslich der Zugang, nicht die Entscheidung. Der Emulator erzeugt Acquirer-Nachrichten im dokumentierten Wire-Format; er urteilt nicht, vergibt keine Labels und kennt keine Regeln.
Sein eigentlicher Wert ist ein Rundlauf: der Emulator bricht kanonische Ereignisse herunter, der Adapter baut sie auf. Beides muss Feld für Feld zusammenpassen. Damit wird jede erfundene Zahl im Übersetzungspfad zu einem Testfehler — statt zu einer Beobachtung, die irgendwann jemand macht.
Dreifach gesperrt: er liegt ausserhalb des Produktionspfads, startet nur über eine ausdrückliche Erlaubnisliste, und jede Nachricht trägt eine Herkunftskennzeichnung, die die Aufnahme in einer Produktionsumgebung zurückweist. Eine Wächterregel verbietet, dass ihn jemand in den Produktionspfad importiert.
Was noch nicht gemessen ist
- Keine Erkennungsrate. Es gibt keine einzige Zahl, die sagt, wie viele echte Kartentests Pattern Sieve findet. Ein solcher Wert braucht Aussteller-Ergebnisse als Labels — die liegen nicht vor.
- Keine Fehlalarmquote im Feld. Gemessen ist nur, dass ein sauberes Portfolio auf der kalibrierten Verkehrsschicht keine Alarme erzeugt. Das ist eine Aussage über unsere Bezugsgrössen, nicht über den Feldverkehr.
- Keine Feldlatenz. Die gemessene Dauer stammt aus einem Prozess auf einem Rechner. Das Latenzbudget im Autorisierungspfad ist ohne Acquirer-Daten nicht messbar.
- Die Schwellen sind gesetzt, nicht hergeleitet. Ihre Kalibrierung aus echten Daten steht aus.
- Der Dienst ist nicht lastfähig. Die Merkmalsberechnung wächst mit dem Verlauf; für Dauerbetrieb mit hohem Volumen ist ein inkrementeller Pfad nötig, der bitgleich zum heutigen rechnen muss. Freigegeben ist ein Schatten-Pilot mit kleinem Volumen.
- Kein Produktivbetrieb, kein Download. Pattern Sieve ist ein Dienst beim Acquirer, kein herunterladbares Produkt. Es läuft heute im Schattenbetrieb.
Diese Liste steht hier, weil eine Produktseite ohne sie unvollständig wäre. Ein Muster ist in einer einzelnen Transaktion nicht sichtbar, und eine Erkennungsrate, die niemand gemessen hat, ist keine.
Design-Partner-Acquirer gesucht
Der eine Schritt, der alles andere freischaltet, ist der Datenzugang: Autorisierungen inklusive Pre-Autorisierungen und ein irreversibler Kartentoken. Damit wird aus einer Architektur eine gemessene Erkennungsrate — und aus dieser Seite eine mit einer Zahl darauf.