Matcha verknüpft unsaubere, falsch geschriebene, halb eingetippte Adressen mit den Datensätzen, die tatsächlich gemeint sind – auf Ihrem eigenen Rechner, mit einer kalibrierten Wahrscheinlichkeit und einer Begründung für jede Entscheidung. Personennamen, Firmennamen, E-Mail, IP-Standort und Kennungen laufen auf derselben Engine. Für die schweren Fälle ergänzen Sie Jev (typesafe.ai) oder ein lokales Ollama-Modell.
In Jenner enthalten. Kein externer Dienst, kein API-Schlüssel, keine Daten verlassen Ihr Netzwerk, es sei denn, Sie fügen ein Modell hinzu: Jev (typesafe.ai) oder ein lokales Ollama-Modell.
Für wen es gedacht ist
Sechs Aufgaben, bei denen die Adresse der Schlüssel ist – und der Schlüssel nie zweimal gleich eingetippt wird.
KYC und Kunden-Onboarding
Ein Antragsteller tippt seine Adresse einmal ein, am Telefon, in Eile. Matcha löst sie gegen Ihre Referenztabelle auf, während er noch auf der Seite ist, und wenn zwei Datensätze gleich plausibel sind, benennt es das eine Feld, das die Frage entscheiden würde – sodass das Formular „Milton or Morton?“ fragen kann, statt die Prüfung scheitern zu lassen oder sie durchzuwinken.
AML und Sanktionsprüfung
Screening ist Abgleich mit umgekehrten Kosten: Ein verpasster Treffer ist teuer, ein Fehlalarm ist billig. Matcha nimmt diese Kosten als Eingaben und verschiebt seine Schwellenwerte entsprechend, sodass dieselbe Engine, die einen Kunden onboardet, ihn auch screenen kann. Adressen sind heute verfügbar; das Screening von Personen- und Firmennamen gegen Sanktions- und PEP-Listen läuft auf derselben Engine, mit denselben Entscheidungen.
Betrugserkennung
Matcha meldet jeden Kandidaten, den es in Betracht gezogen hat, mit der Evidenz pro Feld und der Wahrscheinlichkeit, dass die Wahrheit gar nicht in der Tabelle steht. Eine Betrugsregel kann mit dem arbeiten, was der Matcher tatsächlich geprüft hat, statt mit einem einzelnen Score, und die IP-Standort-Entität prüft den Standort einer Sitzung gegen die Adresse, die der Kunde angibt.
Marketing- und CRM-Deduplizierung
Derselbe Haushalt taucht auf zehn Arten auf – über Registrierungen, Bestellungen und Importe hinweg. Matcha gleicht eine Tabelle mit sich selbst ab, schreibt die Cluster und behält für jede Verknüpfung eine kalibrierte Wahrscheinlichkeit, sodass eine Deduplizierung so streng oder so nachsichtig sein kann wie das Mailing, das sie speist. Householding nach Adresse und Nachname ist eine zusammengesetzte Entität auf derselben Engine.
Zustellung und Logistik
Eine falsche Zustellung kostet eine zweite Fahrt; eine abgelehnte Bestellung kostet den Verkauf. Matcha standardisiert jede Adresse nach den Postregeln ihres Gebiets, gleicht sie mit Ihrer Tabelle der belieferbaren Adressen ab und sagt Ihnen, wenn eine Adresse echt ist, aber außerhalb Ihres Gebiets liegt, oder echt ist, aber in Ihrer Tabelle fehlt – damit die Korrektur an der richtigen Stelle ansetzt.
Öffentlicher Sektor und Civic Tech
Ein städtischer Flurstück-Suchdienst ließ Einwohner eine Adresse per SMS senden und erhielt ihr Flurstück zurück. Bei den schwierigsten Fällen, den Tippfehlern und Diktierfehlern, die sein bisheriger Matcher jedes Mal falsch beantwortete, beantwortete die Matcha-Engine allein 81 % beim ersten Versuch richtig, und ein Modell für den Rest brachte das auf 91 %.
So funktioniert es
Natives Rust in der Jenner-Binärdatei. Ein Schritt, eine Tabelle mit Entscheidungen und eine Begründung für jede.
1
Parsen und standardisieren
Jede Adresse wird in Hausnummer, Richtung, Straße, Suffix, Wohnungseinheit, Ort und Postleitzahl zerlegt und nach den Postregeln ihres Gebiets normalisiert (USPS Publication 28 für die USA, Canada Post für Kanada). Wo der Text mehrdeutig ist, behält der Parser jede Lesart und lässt die Referenz entscheiden.
2
Kandidaten in Ihrer Tabelle finden
Die Engine baut aus Ihrer eigenen Referenztabelle ein Straßenvokabular auf und ordnet die eingetippte Straße nach Schreibweise, Klang und offiziellen Aliasen darauf ab. Kandidaten werden über Hausnummer, Postleitzahl und Straße gefunden, sodass eine falsche ZIP nicht fatal ist.
3
Jedes Feld bewerten, das Ergebnis kalibrieren
Hausnummer, Straße, Suffix, Richtung, Wohnungseinheit und Postleitzahl werden getrennt verglichen, und die Evidenz verbindet sich zu einer kalibrierten Wahrscheinlichkeit. Ein fehlendes Suffix kostet nichts, wenn die Referenz eine Straße dieses Namens hat, und wirft eine Frage auf, wenn sie zwei hat.
4
Nach Kosten entscheiden
Sie geben an, was ein falscher Treffer, ein verpasster Treffer und eine Rückfrage in Ihrem Prozess kosten. Die Engine wählt die Entscheidung mit den geringsten erwarteten Kosten, sodass sie nur dann einen Treffer meldet, wenn sie sich für Ihre Zahlen sicher genug ist, und andernfalls keinen Treffer statt eines falschen zurückgibt.
5
Alles berichten, was betrachtet wurde
Eine Zeile pro Eingabe mit Entscheidung, Wahrscheinlichkeit und Begründung; eine Zeile pro Kandidat mit der Evidenz pro Feld; eine Metriktabelle, die sagt, warum Eingaben nicht zugeordnet wurden. Nichts wird stillschweigend verworfen.
6
Nur den Rest an ein Modell senden
Optional gehen die Fälle, die die Engine nicht entscheiden kann, mit ihren Kandidaten an ein Sprachmodell – im selben Schritt. Das Modell wählt einen Kandidaten aus oder sagt, dass keiner passt; es schreibt die Adresse nie um.
Sechs Entscheidungen, jede mit einer Wahrscheinlichkeit versehen
match
Ein Kandidat ist mit hoher Wahrscheinlichkeit der richtige Datensatz. Verwenden Sie ihn.
likely
Der wahrscheinlichste Kandidat, gemeldet mit seiner tatsächlichen Wahrscheinlichkeit, wenn diese unter dem Schwellenwert für match liegt. Nie eine zufällige Wahl.
nonmatch
Kein plausibler Kandidat. Als nicht gefunden behandeln; die betrachteten Kandidaten werden trotzdem gemeldet.
review
Die Engine konnte nicht entscheiden, und Ihr Prozess kann nachfragen. Wird nur ausgegeben, wenn Sie einen Rückfragekanal mit Kosten belegen.
not_in_table
Eine echte Adresse, die Ihre Referenz nicht enthält. Korrigieren Sie die Referenz, nicht die Eingabe.
out_of_area
Postleitzahl oder Ort liegen außerhalb des Gebiets der Referenz. Leiten Sie sie anderswohin weiter.
Die Rückfrageliste: genau die richtige Frage stellen
Die meisten Matcher reichen ihre schwierigen Fälle an eine manuelle Prüfwarteschlange weiter, die niemand besetzt. Wenn Matcha sich nicht zwischen Kandidaten entscheiden kann, weiß es, warum: Die Eingabe lautete 1200 Milton Street, und die Referenz hat 1200 Milton St und 1200 Morton St – zwei Straßennamen, die ähnlich aussehen und ähnlich klingen. Das ist eine Frage mit einer Antwort aus einem Wort.
Wenn Sie also einen Rückfragekanal mit Kosten belegen, kommen die unentschiedenen Zeilen als review heraus – mit den gereihten Kandidaten, dem genauen Feld, das die Frage klären würde (ask about street, ask about unit), und den Wahrscheinlichkeiten, die Ihr Prozess braucht, um zu entscheiden, ob sich die Frage lohnt. Ein SMS-Dienst antwortet „Milton or Morton?“. Ein Onboarding-Formular zeigt die beiden Adressen. Ein Callcenter-Bildschirm zeigt dem Agenten die Kandidaten statt einer leeren Fläche. Ohne einen mit Kosten belegten Kanal gibt es keine Entscheidung review: Diese Zeilen sind nonmatch, mit denselben Kandidaten und derselben Begründung.
Beginnen Sie mit einem Evaluierungslauf
Geben Sie Matcha eine Wahrheitsdatei – einige hundert Eingaben, für deren korrekten Datensatz Sie bürgen können – und ein einziger Lauf bewertet jede Entscheidung dagegen: richtig beim ersten Versuch, Präzision der gemeldeten Treffer, falsche Antworten, Trefferquote unter den fünf besten Kandidaten, eine Kalibrierungskurve und die erwarteten Kosten für jede Fehlergewichtung, sodass Sie Ihre aus der Kurve wählen können, statt zu raten.
Gemessene Ergebnisse
Zwei Tests, einer mit Eingaben aus der Öffentlichkeit und einer mit absichtlich verfälschten Adressen aus sechs US-Gebieten. Zahlen wie in der Dokumentation veröffentlicht.
Echte Suchanfragen, von der Öffentlichkeit eingetippt
Etwa 2.400 Adressen, die Einwohner in einen städtischen Flurstück-Suchdienst eingetippt haben, gegen ein Register von etwa 378.000 Flurstücken, wobei das korrekte Flurstück aus dem weiteren Verlauf bekannt war. Bei den 223 schwierigsten Fällen – echte Tippfehler, Diktierartefakte und fehlende Suffixe – lag der bisherige Matcher der Stadt beim ersten Versuch jedes Mal falsch.
0 % bis 81 %
schwierige Fälle beim ersten Versuch richtig zugeordnet, Engine allein
91 %
mit einem lokalen Modell oder Jev für den Rest
89 % bis 97 %
Übereinstimmung bei den einfachen Fällen, Engine allein bis Engine plus Modell
Absichtlich verfälschte Adressen, landesweit
3.000 echte Adressen aus sechs zufällig gewählten ZIP-Gebieten, entnommen aus der National Address Database und verfälscht mit der aus echten Daten gemessenen Fehlermischung: Tippfehler, weggelassene Richtungen und Suffixe, Abkürzungen, zusammengeklebte Token und Zahlendreher. Die Wahrheit ist exakt bekannt, und jede Eingabe endet als Treffer oder Nichttreffer, ohne dass etwas für einen Menschen zurückgestellt wird.
83,3 %
richtiger Treffer beim ersten Versuch, Engine allein
98,1 %
Präzision der gemeldeten Treffer
1,6 %
falsche Antworten, etwa eine von sechzig
87,8 % bis 89,3 %
richtig beim ersten Versuch mit Jev oder einem lokalen Modell für den Rest
Ein Ähnlichkeitsscore allein ist gefährlich: Mit eingeschaltetem unscharfem Straßenabgleich und nichts darüber kam jede vierte Adresse falsch zurück. Die Alternativen, Aliase und die Gebäudeauflösung leisten den Großteil der Arbeit, und die Entscheidungsschicht senkt die falschen Antworten dann von 3,6 % auf 0,7 %, indem sie keinen Treffer statt eines falschen zurückgibt, wenn sie sich nicht sicher genug ist. Mit den Kostengewichten können Sie diesen Kompromiss in beide Richtungen verschieben.
Zugewinn pro Stufe: was jede Schicht beiträgt
Dieselben 3.000 verfälschten Adressen, abgeglichen mit jeweils einer weiteren eingeschalteten Schicht. Die Stufen 1 bis 5 sind kumulativ; die letzten beiden sind Alternativen auf dem Rest der vollständigen Engine.
Der exakte Zeichenkettenabgleich trifft 34,6 % richtig und keine falsch. Parsen und Standardisieren hebt die richtigen Treffer auf 48,8 %, die falschen aber auf 20,8 %. Der unscharfe Straßenabgleich hebt richtig auf 64,5 % und falsch auf 25,0 %. Alternativen, Aliase und Einheiten bringen richtig auf 89,3 % und senken falsch auf 3,6 %. Kostenbewusste Entscheidungen, die vollständige Engine, liefern 84,1 % richtig und 0,7 % falsch. Auf dem Rest dieser Engine erreicht ein lokales Ollama-Modell 90,0 % richtig bei 2,1 % falsch, und Jev erreicht 88,5 % richtig bei 0,8 % falsch.
Anteil von 3.000 verfälschten Adressen, die nach Stufe richtig, falsch oder gar nicht abgeglichen wurden. Die letzten beiden Zeilen sind Alternativen, die von Stufe 5 abzweigen, keine Abfolge.
Stufe
Richtiger Treffer
Falscher Treffer
Verpasst
Stufe 1: Exakter Abgleich
34.6%
0.0%
65.4%
Stufe 2: Parsen und Standardisieren
48.8%
20.8%
30.4%
Stufe 3: Unscharfe Straße
64.5%
25.0%
10.5%
Stufe 4: Alternativen und Einheiten
89.3%
3.6%
7.1%
Stufe 5: Kostenbewusste Entscheidungen
84.1%
0.7%
15.2%
+ KI auf dem Rest: Lokale KI (Ollama)
90.0%
2.1%
7.8%
+ KI auf dem Rest: Jev (TypeSafe)
88.5%
0.8%
10.7%
Quelle: 3.000 echte US-Adressen aus sechs zufällig gewählten ZIP-Gebieten, aus der National Address Database gezogen und mit dem an echten Daten gemessenen Fehlermix verfälscht, sodass die Wahrheit exakt bekannt ist. Zahlen wie in der PROC MATCHA-Dokumentation veröffentlicht.
Unscharfer Abgleich allein ist gefährlich. Mit eingeschaltetem unscharfem Straßenabgleich und nichts darüber kommt jede vierte Adresse falsch zurück, und nichts in einem Ähnlichkeitsscore verrät Ihnen, welche.
Die Alternativen-Schicht leistet die Hauptarbeit. Offizielle Straßenaliase, alternative Schreibweisen sowie Einheiten- und Gebäudeauflösung heben die richtigen Treffer von 64,5 % auf 89,3 % und senken die falschen von 25,0 % auf 3,6 %.
Die Entscheidungsschicht drückt die falschen Antworten unter 1 %. Wird ein falscher Treffer gegen einen verpassten bepreist, gibt die Engine keinen Treffer statt eines falschen zurück, wenn sie sich nicht sicher genug ist: 0,7 % falsch, wobei die unentschiedenen Fälle gemeldet und nicht verworfen werden.
KI auf dem Rest hebt die richtigen Treffer auf etwa 90 %. Ein lokales Modell findet die meisten Treffer und verdreifacht die falschen Antworten in etwa; Jev fügt Treffer mit der Präzision der Engine selbst hinzu, 0,8 % falsch.
Führen Sie es auf Ihren eigenen Adressen aus
Matcha ist in jeder Jenner-Lizenz enthalten. Kaufen Sie Jenner, lesen Sie die PROC MATCHA-Dokumentation oder erzählen Sie uns von Ihrem Abgleichproblem, und wir helfen Ihnen, einen Evaluierungslauf aufzusetzen.
Sprachmodelle sind teuer pro Zeile und langsam pro Zeile. Matcha setzt sie so ein, wie es ein guter Analyst täte: nur bei den Fällen, die Urteilsvermögen brauchen.
Ollama mit qwen2.5:7b-instruct, vollständig offline
Betreiben Sie ein lokales Modell über Ollama auf Ihrer eigenen Hardware, vollständig offline, sodass nichts den Rechner verlässt. Wir benchmarken mit qwen2.5:7b-instruct. Lokale Modelle kosten pro Zeile nichts und beantworten fast jede Frage, die man ihnen stellt; das findet die meisten Treffer und verdoppelt ungefähr die falschen Antworten.
Jev, ein System One-Modell von TypeSafe (typesafe.ai)
Statt Text zu erzeugen, beantwortet Jev eine typisierte Frage – welcher Kandidat, wenn überhaupt einer, derselbe Ort ist wie diese Adresse – und liefert eine Wahl mit einer kalibrierten Wahrscheinlichkeit. Wenn es 0,9 sagt, liegt es in etwa 90 % der Fälle richtig, und wenn es unsicher ist, sagt es, dass keiner der Kandidaten passt, statt zu raten. Das ist genau die Form, die ein kostenbewusster Matcher braucht, und deshalb fügt Jev Treffer mit der Präzision der Engine selbst hinzu.
In gemessenen Läufen liegt der unentschiedene Anteil bei 2 % bis 8 % der Eingaben, sodass ein Auftrag mit 100.000 Adressen einige tausend Modellaufrufe verursacht, nicht hunderttausend.
Beide sind optional und beide sind standardmäßig ausgeschaltet. Die Engine braucht keines von beiden, und ein entferntes Modell kann erst verwendet werden, wenn Sie allow_remote in der Konfiguration setzen.
Jev von typesafe.ai: System One-Modelle für die schweren Fälle
Jev wird von TypeSafe (typesafe.ai) entwickelt. Matcha ruft es nur für den Rest auf, den die Engine nicht selbst entscheiden kann.
Jev ist das System One-Modell von TypeSafe. Statt Text zu erzeugen, beantwortet es eine typisierte Frage, welcher Kandidat, wenn überhaupt einer, derselbe Ort wie diese Adresse ist, und liefert eine Wahl, eine kalibrierte Wahrscheinlichkeit und eine Konfidenz. System One-Modelle sind für Entscheidungen dieser Form gebaut, nicht für Konversation.
Genau diese Form braucht ein kostenbewusster Matcher. Kalibrierung heißt: Wenn Jev 0.9 sagt, liegt es in etwa 90% der Fälle richtig, sodass die Engine seine Antwort gegen den Preis eines falschen Treffers abwägen kann, und wenn Jev unsicher ist, sagt es, dass keiner der Kandidaten passt, statt zu raten.
Matcha setzt Jev nur auf den Rest an, die Fälle, die die Engine allein nicht entscheiden kann, sodass ein Lauf mit 100,000 Adressen einige tausend Jev-Aufrufe macht, nicht hunderttausend. Legen Sie Ihren TypeSafe-API-Schlüssel in die Umgebung, fügen Sie adjudicate provider=jev; in den PROC MATCHA-Schritt ein und lassen Sie allow_remote aus, bis Sie entschieden haben, dass diese Fälle Ihren Rechner verlassen dürfen.
Jev einschalten
export TYPESAFE_API_KEY=... # never in a file
adjudicate provider=jev; # inside the PROC MATCHA step
Gemessen am Benchmark mit verfälschten Adressen hebt Jev die korrekten Treffer von 83.3% auf 87.8% bei der engine-eigenen Präzision von 98.1%, mit 0.8% falschen Antworten in der stufenweisen Ablation. Bei den echten, von der Öffentlichkeit eingetippten Anfragen traf es die schweren Fälle so oft wie das lokale Modell, und wenn kein Kandidat der richtige war, sagte es das, statt einen auszuwählen.
Offene Referenzdaten, aktualisiert nur auf Ihr Kommando
Die Engine gleicht mit der Tabelle ab, die Sie ihr geben, unterstützt von offenen Wissenspaketen: US-Adresspunkte aus der National Address Database, Straßenaliase aus Census TIGER und kanadische Adressen von Statistics Canada, alle gemeinfrei oder offen lizenziert. Jenner Analytics baut die Pakete neu, wenn ihre Quellen veröffentlichen, validiert sie gegen die vorherige Version, signiert sie und veröffentlicht sie in einem Datenkanal.
Auf Ihrem Rechner ändert sich nichts, bis Sie das Update selbst ausführen. Jedes Paket wird gegen ein signiertes Manifest geprüft, bevor ein Byte entpackt wird, und atomar eingewechselt, sodass ein laufender Auftrag das alte Paket oder das neue sieht und nie ein unvollständiges. PROC MATCHA lädt nie etwas herunter, und der Bericht hält fest, welche Datenversion ein Lauf verwendet hat.
Prüfen, dann aktualisieren – nach Ihrem Zeitplan
jenner data update --check # what would change; writes nothing
jenner data update # install or refresh every pack
jenner data update --pin 2026.9.28
Gebiete
Die USA sind der Standard, und Kanada wird unterstützt, einschließlich zweisprachiger Formen. Gebietspakete für Großbritannien, Frankreich, Japan, Korea und Australien sind in Arbeit. Jedes ist Daten, nicht Code, sodass ein neues Land nur ein neues Paket bedeutet.
Eine Matching-Engine für KYC, AML, Betrug, Kreditrisiko, Zustellung und Compliance
Adressen sind heute verfügbar. Jeder weitere Abgleich der KYC-Familie läuft auf derselben Engine: dieselben kalibrierten Wahrscheinlichkeiten, dieselben kostengewichteten Entscheidungen, dieselben Ausgaben und derselbe Evaluierungslauf.
Eine neue Art von Abgleich ist eine Entitätsdefinition, kein neues Produkt: die Rollen eines Datensatzes, der Komparator für jede Rolle, die Blocking-Strategie und die Wissenspakete, die sie heranziehen darf. Scoring, Entscheidungen, Rückfrageliste und Evaluierung sind gemeinsamer Code, sodass ein Personennamen-Abgleich genau wie ein Adressabgleich evaluiert und bepreist wird.
Fähigkeiten auf derselben Engine
IP-Adresse zu Postadresse: Geolokalisierungsdistanz und VPN-Signale
Matcha vergleicht, wohin die IP-Adresse einer Sitzung geolokalisiert wird, mit der Adresse, die der Kunde angibt – über die geodätische Distanz, mit dem Geolokalisierungsradius als Unsicherheit. ASN-, Proxy- und VPN-Flags zählen als Gegenbeweis, nie als Urteil für sich allein. Das Ergebnis ist dieselbe kalibrierte Wahrscheinlichkeit und kostengewichtete Entscheidung wie bei einem Adressabgleich, sodass eine Betrugsregel darauf reagieren oder den Fall zur Prüfung weiterleiten kann.
Beispiel: Ein Kartenantragsteller gibt eine Adresse in Denver an, von einer IP, die 40 km entfernt geolokalisiert wird, ohne VPN-Flag: Übereinstimmung innerhalb des Radius. Dieselbe Adresse von einer Rechenzentrums-IP in einem anderen Land: Konflikt, und die Zeile wird für die Prüfung bepreist.
E-Mail zu Person und Unternehmen: lokaler Teil, Domain und Wegwerf-Signale
Die E-Mail-Identitäts-Entität prüft, ob eine Adresse zu der Person und der Organisation gehört, die beim Onboarding angegeben wurden. Der lokale Teil wird mit den Namensbestandteilen verglichen – first.last, Initialen und Spitznamen eingeschlossen; die Domain wird mit den registrierten Domains der Organisation verglichen; Freemail- und Wegwerf-Domain-Listen sowie das Vorhandensein von MX-Einträgen sind Evidenz. Jedes Signal ist ein Komparator, und die Engine sagt, wie stark sie übereinstimmen.
Beispiel:[email protected] gegen Jane Okafor bei Northwind Actuarial: Der lokale Teil stimmt mit dem Namen überein und die Domain mit dem Unternehmen. [email protected] gegen denselben Datensatz: Wegwerf-Domain, und die Wahrscheinlichkeit sagt es.
Firmennamen-Abgleich: Rechtsformen, Akronyme und Registerkennungen
Die Unternehmens-Entität entfernt Rechtsformen nach ISO 20275, gewichtet seltene Wörter, expandiert Akronyme und lässt eine Registerkennung den Namen überstimmen: LEI, EIN, UEI und Companies-House-Nummern. Die GLEIF-Level-1-Daten und die früheren Namen aus EDGAR sind Wissenspakete, sodass ein umbenanntes Unternehmen weiterhin die Gegenpartei in Ihren Büchern trifft. Lieferantenvalidierung, Gegenpartei-Abgleich und KYB nutzen denselben Lauf.
Beispiel: "INTL BUSINESS MACHINES CORP" gegen "International Business Machines Corporation" mit übereinstimmender LEI: match, Registerkennung überstimmt. "IBM Credit LLC" gegen die Muttergesellschaft: nonmatch, mit gemeldeter Evidenz aus Rechtsform und seltenen Wörtern.
Personennamen-Abgleich: Spitznamen, Transliteration, Phonetik und Geburtsdatum
Die Personen-Entität vergleicht Vor-, Zweit- und Nachnamen mit Spitznamen-Paketen, Transliteration aus dem Kyrillischen, Arabischen und CJK, phonetischem Vergleich und Varianten der Namensreihenfolge und behandelt ein vertauschtes Geburtsdatum oder eine prüfsummenkonforme nationale ID als die Evidenz, die sie ist. Eine Sanktions- oder PEP-Liste ist eine gewöhnliche Referenztabelle, bei der die Kosten eines verpassten Treffers hoch angesetzt sind, sodass Screening und Kunden-Deduplizierung dieselbe Engine mit unterschiedlichen Preisen sind.
Beispiel: "Mohammed Al-Rashid, 03/07/1981" gegen "Muhammad Alrashid, 07/03/1981": Die Transliteration stimmt überein, das Datum ist eine Tag-Monat-Vertauschung, und die Zeile kommt als Screening-Treffer mit ihrer Wahrscheinlichkeit zurück statt als verpasster.
Telefonnummern und Kennungen: IBAN, VIN, NPI und nationale IDs
Telefonnummern werden auf E.164 normalisiert und auf Länder- und Vorwahlkonsistenz sowie Anschlusstyp geprüft. Kennungen werden validiert, bevor sie abgeglichen werden: IBAN-, VIN- und NPI-Prüfsummen, Format- und Ausstellerkonsistenz, Formate nationaler IDs. Eine gültige Kennung ist starke Evidenz; eine ungültige ist ein eigenständiger Befund, der gemeldet wird, bevor ein einziger Kandidat bewertet wird.
Beispiel: Die IBAN eines Antragstellers besteht die mod-97-Prüfung nicht: Die Zeile wird vor dem Abgleich markiert, mit Begründung, statt gegen jedes Konto in der Referenztabelle bewertet zu werden.
Koordinaten, Haushalte, Transaktionsgegenparteien und Produktnamen
Entitäten lassen sich zusammensetzen. Eine Gerätekoordinate wird auf den nächstgelegenen Adresspunkt rückgeocodiert; ein Haushalt ist ein Adressabgleich plus Nachnamensübereinstimmung; eine Transaktionsgegenpartei ist ein Unternehmen oder eine Person plus Konto und Land; ein Produkt- oder Arzneimittelname wird über Token-Enthaltensein mit Code-Überstimmung abgeglichen. Der Scoring-Code kennt den Unterschied nicht, und genau deshalb kommt jede davon auf derselben Engine mit demselben Evaluierungslauf an.
Beispiel: Der GPS-Fix einer Liefer-App landet 30 m von der Adresse auf der Bestellung entfernt: Übereinstimmung, mit gemeldeter Distanz. Zwei Kundendatensätze an einer Adresse mit übereinstimmendem Nachnamen: ein Haushalt, mit einer kalibrierten Wahrscheinlichkeit für die Verknüpfung.
Prüfen Sie Adresse, E-Mail, Telefonnummer und Kennungen eines Antragstellers in einem Schritt, mit einer Wahrscheinlichkeit pro Prüfung und einer Rückfrage, wenn etwas mehrdeutig ist. Matcha löst die Adresse auf, während der Antragsteller noch auf der Seite ist, und fragt „Milton or Morton?“, statt die Prüfung scheitern zu lassen oder sie durchzuwinken.
Vergleichen Sie den IP-Standort der Sitzung mit der angegebenen Adresse, die Gerätekoordinate mit der Lieferadresse und die E-Mail mit der Person, und erhalten Sie Evidenz, auf die eine Regel reagieren kann, statt eines Blackbox-Scores. Jeder Kandidat, den der Matcher in Betracht gezogen hat, wird gemeldet, mit der Wahrscheinlichkeit, dass die Wahrheit gar nicht in Ihrer Tabelle steht.
Screenen Sie Personen- und Firmennamen gegen Sanktions- und PEP-Listen mit Transliteration, Spitznamen, Phonetik und Geburtsdatums-Vertauschungen, bepreist fürs Screening: verpasster Treffer teuer, Fehlalarm billig. Die Liste ist eine Referenztabelle, der Evaluierungslauf bewertet Ihre Trefferquote gegen bekannte Fälle, und die Kalibrierungskurve sagt Ihnen, was eine 0,9 auf Ihren Daten bedeutet.
Lösen Sie die Unternehmen auf einem Antrag, einem Handelsgeschäft oder einem Hauptbuch über Rechtsformen, frühere Namen und Registerkennungen hinweg zu einer juristischen Person auf, damit das Exposure nur einmal gezählt wird. LEI, EIN, UEI und Companies-House-Nummern überstimmen Namen, wenn sie vorhanden sind, und bestätigen sie, wenn nicht.
Standardisieren Sie jede Adresse nach den Postregeln ihrer Region, gleichen Sie sie mit Ihrer Tabelle belieferbarer Adressen ab und erfahren Sie, wann eine Adresse echt, aber außerhalb Ihres Gebiets ist oder echt, aber in Ihrer Tabelle fehlt. Eine Gerätekoordinate an der Tür bestätigt den Zustellpunkt, und die Kostengewichte entscheiden, wann eine falsche Adresse schlimmer ist als eine abgelehnte Bestellung.
Jede Entscheidung trägt eine Wahrscheinlichkeit, eine Begründung und die betrachteten Kandidaten – in Tabellen, die Sie behalten. Nichts verlässt Ihren Rechner, es sei denn, Sie fügen ein Modell hinzu; der Bericht hält fest, welches Datenrelease ein Lauf verwendet hat, und derselbe Evaluierungslauf reproduziert ein Ergebnis Monate später für einen Prüfer.
PROC MATCHA ist Teil von Jenner, kein separates Produkt und keine Gebühr pro Zeile. Unter Windows und Linux wird eine Jenner-Lizenz einmal pro Rechner gekauft und ist unbefristet: Die gekaufte Version läuft so lange, wie Sie sie nutzen möchten, mit neuen Releases und Support für ein Jahr inklusive. Jenner für macOS gibt es im Mac App Store, und der Workspace wird stundenweise abgerechnet.
Jenner Analytics berechnet nichts für eine abgeglichene Zeile, einen betrachteten Kandidaten oder eine gestellte Frage. Wenn Sie sich für Jev entscheiden, rechnet TypeSafe es pro Eingabe-Token ab, und es sieht nur den Rest.
Jenner führt bestehenden PROC DQMATCH- und PROC DQSCHEME-Code aus Kompatibilitätsgründen aus, sodass ein SAS-Datenqualitätsprogramm weiterhin funktioniert. Matcha ist der empfohlene Matcher für neue Arbeit: Es verwendet dieselbe Anweisungssyntax im SAS-Stil, liefert aber eine kalibrierte Wahrscheinlichkeit und eine Begründung für jede Entscheidung, kann eine Rückfrage stellen und liest und schreibt CSV, Parquet, Avro und die meisten Datenbanken über dieselbe data=-Syntax, sodass Sie an keines der beiden Werkzeuge gebunden sind.
Nein. Die Engine ist natives Rust in der Jenner-Binärdatei und macht keine Netzwerkaufrufe; die Referenzdaten sind die Tabelle, die Sie ihr geben, plus auf Ihrem Rechner installierte Wissenspakete. Sprachmodelle sind standardmäßig ausgeschaltet. Ein lokales Modell über Ollama behält alles auf Ihrer Hardware. Ein entferntes Modell wie Jev wird nur verwendet, wenn Sie es in der Konfiguration aktivieren, und dann sieht es nur die unentschiedenen Fälle mit ihren Kandidaten, nie die ganze Datei.
Die USA sind das Standardgebiet, mit Standardisierung nach USPS Publication 28 und offenen Adressdaten aus der National Address Database und Census TIGER. Kanada wird unterstützt, einschließlich zweisprachiger französischer Formen und kanadischer Postleitzahlen, mit Daten von Statistics Canada. Gebietspakete für Großbritannien, Frankreich, Japan, Korea und Australien sind in Arbeit. Gegen Ihre eigene Referenztabelle können Sie heute in jedem Land abgleichen; die Pakete fügen Standardisierungsregeln und offene Adresspunkte hinzu.
Ja. Die Engine braucht keinen Dienst, keinen Schlüssel und kein Netzwerk. Referenzpakete werden einmal mit jenner data update installiert und nur aktualisiert, wenn Sie diesen Befehl erneut ausführen. Mit einem lokalen Ollama-Modell ist auch der optionale Entscheidungsschritt offline; nur Jev ist ein entfernter Aufruf, und nur, wenn Sie es einschalten.
Wenn die Engine sich nicht zwischen Kandidaten entscheiden kann und Sie einen Rückfragekanal mit Kosten belegt haben, kommen diese Zeilen als review heraus – mit den gereihten Kandidaten, dem genauen Feld, das die Frage klären würde (Suffix, Richtung, Wohnungseinheit), und den Wahrscheinlichkeiten. Ihr Prozess macht daraus eine Frage an denjenigen, der sie beantworten kann: eine SMS-Antwort, eine Abfrage in einem Onboarding-Formular, einen Callcenter-Bildschirm. Auf der Abgleichseite liest niemand diese Zeilen, und ohne einen mit Kosten belegten Kanal werden sie als nonmatch gemeldet, mit denselben Kandidaten.
Geben Sie einem Lauf eine Wahrheitsdatei mit Eingaben, deren korrekten Datensatz Sie kennen, und Matcha bewertet jede Entscheidung dagegen: richtig beim ersten Versuch, Präzision, falsche Antworten, Trefferquote unter den fünf besten Kandidaten, korrekte Enthaltungen bei Eingaben außerhalb des Gebiets, eine Kalibrierungskurve und die erwarteten Kosten über eine Spanne von Fehlergewichtungen. Die auf dieser Seite veröffentlichten Ergebnisse stammen aus demselben Laufmodus, mit öffentlichen Suchanfragen mit bekanntem Ausgang und mit verfälschten Adressen mit exakter Wahrheit.
Ja, auf derselben Engine. Adressen sind heute verfügbar. Personennamen, Firmennamen, E-Mail-Identität, IP-Standort, Telefonnummern, Kennungen mit Prüfsummen sowie Sanktions- oder PEP-Listen sind Entitäten, die dieselbe Engine abgleicht – mit denselben kalibrierten Wahrscheinlichkeiten, kostengewichteten Entscheidungen, Ausgaben und demselben Evaluierungslauf. Eine Prüfliste ist eine gewöhnliche Referenztabelle, bei der die Kosten eines verpassten Treffers hoch angesetzt sind. Nutzen Sie das Formular auf dieser Seite, um die Verfügbarkeit für die Entität anzufragen, die Sie brauchen.
Matcha ist in Jenner enthalten, Sie kaufen also Jenner: eine unbefristete Lizenz pro Rechner für Windows und Linux, Jenner für macOS im Mac App Store oder stundenweise Workspace-Guthaben. Es gibt keine Gebühr pro Zeile oder pro Treffer. Die Preisseite zeigt die aktuellen Pläne und die kostenlose Testversion.
Ja. Eine Sanktions- oder PEP-Liste ist eine Personen- oder Unternehmens-Referenztabelle, und Screening ist Abgleich mit umgekehrten Kosten: verpasster Treffer hoch bepreist, Fehlalarm niedrig. Die Personen-Entität beherrscht Spitznamen, Transliteration aus dem Kyrillischen, Arabischen und CJK, phonetischen Vergleich, Varianten der Namensreihenfolge und Geburtsdatums-Vertauschungen, und der Evaluierungslauf bewertet Ihre Trefferquote gegen bekannte Fälle. Fragen Sie die Verfügbarkeit über das Formular auf dieser Seite an.
Ja. Die IP-Standort-Entität geolokalisiert die IP-Adresse der Sitzung und vergleicht sie über die geodätische Distanz mit den Koordinaten der angegebenen Adresse, mit dem Geolokalisierungsradius als Unsicherheit, und wertet ASN-, Proxy- und VPN-Flags als Gegenbeweis. Das Ergebnis ist dieselbe kalibrierte Wahrscheinlichkeit und Entscheidung wie bei einem Adressabgleich, sodass eine Betrugsregel oder eine Prüf-Warteschlange es direkt verwenden kann.
Ja. Die Unternehmens-Entität entfernt Rechtsformen nach ISO 20275, gewichtet seltene Wörter, expandiert Akronyme und lässt eine Registerkennung den Namen überstimmen: LEI, EIN, UEI und Companies-House-Nummern. GLEIF-Daten und frühere Namen aus EDGAR sind Wissenspakete, sodass ein umbenanntes Unternehmen weiterhin zur Gegenpartei in Ihren Büchern aufgelöst wird. Das ist Lieferantenvalidierung, Gegenpartei-Abgleich und KYB in einem Lauf.
Jev ist ein System One-Modell von TypeSafe (typesafe.ai). Statt Text zu erzeugen, beantwortet es eine typisierte Frage, welcher Kandidat, wenn überhaupt einer, derselbe Ort wie diese Adresse ist, mit einer Wahl, einer kalibrierten Wahrscheinlichkeit und einer Konfidenz. Matcha nutzt es, weil das die Form einer Matching-Entscheidung ist: Wenn Jev 0.9 sagt, liegt es in etwa 90% der Fälle richtig, und wenn es unsicher ist, sagt es, dass keiner der Kandidaten passt. Es wird nur für den Rest aufgerufen, den die Engine nicht entscheiden kann, einige tausend Aufrufe pro 100,000 Zeilen, und im Benchmark mit verfälschten Adressen hebt es die korrekten Treffer von 83.3% auf 87.8% bei der engine-eigenen Präzision von 98.1%. Es ist standardmäßig aus und braucht einen TypeSafe-API-Schlüssel in der Umgebung sowie adjudicate provider=jev; im Schritt.
Ja. Richten Sie Matcha auf ein lokales Modell, das Ollama auf Ihrer eigenen Hardware bereitstellt, vollständig offline, und derselbe Adjudikationsschritt läuft, ohne dass etwas den Rechner verlässt. Wir benchmarken mit qwen2.5:7b-instruct. Ein lokales Modell beantwortet fast jeden Fall, den es sieht; das findet die meisten Treffer, 89.3% korrekt im Benchmark mit verfälschten Adressen, und verdoppelt ungefähr die falschen Antworten gegenüber Jev. Sie können auch beide nebeneinander laufen lassen und erhalten pro Zeile ein agree-Flag. Keines von beiden ist Pflicht: Die Engine allein braucht kein Modell, keinen Schlüssel und kein Netzwerk.
Probieren Sie es mit Ihren eigenen Adressen
Führen Sie eine Evaluierung gegen einige hundert Datensätze durch, für die Sie bürgen können, und erhalten Sie eine ehrliche Zahl dafür, wie gut es auf Ihren Daten ist.
Adressen sind heute verfügbar. Bitten Sie um einen Evaluierungslauf auf Ihren eigenen Daten oder fragen Sie die Verfügbarkeit einer Fähigkeit auf derselben Engine an – wir antworten mit Terminen und dem, was für die Einrichtung nötig ist.
Sehen Sie sich Matcha selbst an
Kaufen Sie Jenner und führen Sie PROC MATCHA auf Ihren eigenen Adressen aus, lesen Sie die Dokumentation oder sehen Sie sich die dreiminütige Einführung in Jenner an.
