Matcha links messy, misspelled, half-typed addresses to the records they really refer to, on your own machine, with a calibrated probability and a reason for every decision. Person names, business names, email, IP location and identifiers run on the same engine. For the hard cases, add Jev (typesafe.ai) or a local Ollama model.
Included in Jenner. No external service, no API key, no data leaving your network unless you choose to add a model: Jev (typesafe.ai) or a local Ollama model.
Who it is for
Six jobs where the address is the key, and the key is never typed the same way twice.
KYC and customer onboarding
An applicant types their address once, on a phone, in a hurry. Matcha resolves it against your reference table while they are still on the page, and when two records are equally plausible it names the one field that would settle it, so the form can ask "Milton or Morton?" instead of failing the check or waving it through.
AML and sanctions screening
Screening is matching with the costs turned around: a missed hit is expensive and a false alarm is cheap. Matcha takes those costs as inputs and moves its thresholds to suit, so the same engine that onboards a customer can screen one. Addresses ship today; person and business name screening against sanctions and PEP lists runs on the same engine, with the same decisions.
Fraud detection
Matcha reports every candidate it considered, with the per-field evidence and the probability that the truth is not in the table at all. A fraud rule can work within what the matcher actually looked at rather than a single score, and the IP-location entity checks a session's location against the address the customer claims.
Marketing and CRM deduplication
The same household appears ten ways across sign-ups, orders and imports. Matcha matches a table against itself, writes the clusters, and keeps a calibrated probability on every link, so a deduplication can be as strict or as forgiving as the mailing it feeds. Householding by address and surname is a composed entity on the same engine.
Delivery and logistics
A wrong delivery costs a return trip; a rejected order costs the sale. Matcha standardizes each address to the postal rules of its locale, matches it to your serviceable-address table, and tells you when an address is real but outside your area, or real but missing from your table, so the fix goes to the right place.
Public sector and civic tech
A city parcel lookup service let residents text an address and get their parcel back. On the hardest cases, the misspellings and dictation slips its previous matcher got wrong every time, the Matcha engine alone answered 81% correctly on the first try, and a model on the residual took that to 91%.
How it works
Native Rust inside the Jenner binary. One step, one table of decisions, and a reason for each.
1
Parse and standardize
Each address is split into house number, direction, street, suffix, unit, city and postcode, and normalized to the postal rules of its locale (USPS Publication 28 for the US, Canada Post for Canada). Where the text is ambiguous the parser keeps every reading and lets the reference decide.
2
Find candidates in your table
The engine builds a street vocabulary from your own reference table and snaps the typed street to it by spelling, sound and official aliases. Candidates are found by house number, postcode and street, so a wrong ZIP is not fatal.
3
Score every field, calibrate the result
House number, street, suffix, direction, unit and postcode are compared separately, and the evidence combines into a calibrated probability. A missing suffix costs nothing when the reference has one street of that name, and raises a question when it has two.
4
Decide by cost
You say what a wrong match, a missed match and a follow-up question cost in your process. The engine picks the decision with the lowest expected cost, so it matches only when it is sure enough for your numbers and when it is not, it returns no match rather than a wrong match.
5
Report everything it looked at
One row per input with the decision, probability and reason; one row per candidate with the per-field evidence; a metrics table that says why inputs did not match. Nothing is silently dropped.
6
Send only the residual to a model
Optionally, the cases the engine cannot settle go to a language model with their candidates, inside the same step. The model picks one candidate or says none of them fits; it never rewrites the address.
Six decisions, each with a probability attached
match
One candidate is the right record with high probability. Use it.
likely
The most probable candidate, reported with its real probability when that is below the match threshold. Never a random pick.
nonmatch
No plausible candidate. Treat as not found; the candidates considered are still reported.
review
The engine could not decide and your process can ask. Emitted only when you price a follow-up channel.
not_in_table
A real address your reference does not hold. Fix the reference, not the input.
out_of_area
The postcode or place lies outside the reference's area. Route it elsewhere.
The follow-up list: ask exactly the right question
Most matchers hand their hard cases to a manual review queue that nobody staffs. When Matcha cannot decide between candidates it knows why: the input said 1200 Milton Street and the reference has a 1200 Milton St and a 1200 Morton St, two street names that look alike and sound alike. That is a question with a one-word answer.
So when you price a follow-up channel, the undecided rows come out as review with the ranked candidates, the exact field that would settle it (ask about street, ask about unit), and the probabilities your process needs to decide whether the question is worth asking. An SMS service replies "Milton or Morton?". An onboarding form shows the two addresses. A call-center screen shows the agent the candidates instead of a blank. Without a priced channel there is no review decision: those rows are nonmatch, with the same candidates and reason attached.
Start with an evaluation run
Give Matcha a truth file, a few hundred inputs whose correct record you can vouch for, and one run scores every decision against it: correct on the first try, precision of the matches made, wrong answers, recall among the top five candidates, a calibration curve, and the expected cost of each error weight so you can choose yours from the curve rather than guess.
Measured results
Two tests, one on the public's typing and one on deliberately corrupted addresses across six US areas. Numbers as published in the documentation.
Real lookups typed by the public
About 2,400 addresses that residents typed into a city parcel lookup service, against a register of about 378,000 parcels, with the correct parcel known from what happened next. On the 223 hardest cases, real misspellings, dictation artefacts and missing suffixes, the city's previous matcher was wrong on the first try every time.
0% to 81%
hard cases matched correctly on the first try, engine alone
91%
with a local model or Jev on the residual
89% to 97%
agreement with the easy cases, engine alone to engine plus model
Deliberately corrupted addresses, nationwide
3,000 real addresses from six randomly chosen ZIP areas, drawn from the National Address Database and corrupted with the error mix measured from real data: misspellings, dropped directions and suffixes, abbreviations, glued tokens and digit slips. The truth is known exactly, and every input ends as a match or a non-match with nothing set aside for a person.
83.3%
correct match on the first try, engine alone
98.1%
precision of the matches made
1.6%
wrong answers, about one in sixty
87.8% to 89.3%
correct on the first try with Jev or a local model on the residual
A similarity score on its own is dangerous: with fuzzy street matching switched on and nothing above it, one address in four came back wrong. The alternates, aliases and building resolution do most of the work, and the decision layer then cuts wrong answers from 3.6% to 0.7% by returning no match instead of a wrong one when it is not sure enough. The cost weights let you move that trade either way.
Lift by stage: what each layer adds
The same 3,000 corrupted addresses, matched with one layer switched on at a time. Stages 1 to 5 are cumulative; the last two are alternatives on the full engine's residual.
Exact string match gets 34.6% right and none wrong. Parsing and standardizing raises correct matches to 48.8% but wrong ones to 20.8%. Fuzzy street matching raises correct to 64.5% and wrong to 25.0%. Alternates, aliases and units take correct to 89.3% and wrong down to 3.6%. Cost-aware decisions, the full engine, give 84.1% correct and 0.7% wrong. On that engine's residual, a local Ollama model reaches 90.0% correct with 2.1% wrong, and Jev reaches 88.5% correct with 0.8% wrong.
Share of 3,000 corrupted addresses matched correctly, matched wrongly or missed, by stage. The last two rows are alternatives forked from stage 5, not a sequence.
Stage
Correct match
Wrong match
Missed
stage 1: Exact match
34.6%
0.0%
65.4%
stage 2: Parse and standardize
48.8%
20.8%
30.4%
stage 3: Fuzzy street
64.5%
25.0%
10.5%
stage 4: Alternates and units
89.3%
3.6%
7.1%
stage 5: Cost-aware decisions
84.1%
0.7%
15.2%
+ AI on the residual: Local AI (Ollama)
90.0%
2.1%
7.8%
+ AI on the residual: Jev (TypeSafe)
88.5%
0.8%
10.7%
Source: 3,000 real US addresses from six randomly chosen ZIP areas, drawn from the National Address Database and corrupted with the error mix measured from real data, so the truth is known exactly. Numbers as published in the PROC MATCHA documentation.
Fuzzy matching alone is dangerous. With fuzzy street matching switched on and nothing above it, one address in four comes back wrong, and nothing in a similarity score tells you which.
The alternates layer does the heavy lifting. Official street aliases, alternate spellings, unit and building resolution take correct matches from 64.5% to 89.3% and cut wrong ones from 25.0% to 3.6%.
The decision layer cuts wrong answers to under 1%. Pricing a wrong match against a missed one, the engine returns no match instead of a wrong match when it is not sure enough: 0.7% wrong, with the undecided cases reported, not dropped.
AI on the residual lifts correct matches to about 90%. A local model finds the most matches and roughly triples the wrong answers; Jev adds matches at the engine's own precision, 0.8% wrong.
Run it on your own addresses
Matcha is included in every Jenner license. Buy Jenner, read the PROC MATCHA documentation, or tell us about your matching problem and we will help you set up an evaluation run.
Language models are expensive per row and slow per row. Matcha uses them the way a good analyst would: only on the cases that need judgement.
Ollama with qwen2.5:7b-instruct, fully offline
Run a local model through Ollama on your own hardware, fully offline, so nothing leaves the machine. We benchmark with qwen2.5:7b-instruct. Local models are free per row and answer almost every question they are shown, which finds the most matches and roughly doubles the wrong answers.
Jev, a System One model from TypeSafe (typesafe.ai)
Instead of generating text, Jev answers a typed question, which candidate, if any, is the same place as this address, and returns a choice with a calibrated probability. When it says 0.9 it is right about 90% of the time, and when it is unsure it says none of the candidates fits, rather than guessing. That is exactly the shape a cost-aware matcher needs, and it is why Jev adds matches at the engine's own precision.
In measured runs the undecided band is 2% to 8% of inputs, so a job of 100,000 addresses makes a few thousand model calls, not a hundred thousand.
Both are optional and both are off by default. The engine needs neither, and a remote model can only be used once you set allow_remote in the configuration.
Jev from typesafe.ai: System One models for the hard cases
Jev is made by TypeSafe (typesafe.ai). Matcha calls it only on the residual the engine cannot settle.
Jev is TypeSafe's System One model. Instead of generating text, it answers a typed question, which candidate, if any, is the same place as this address, and returns a choice, a calibrated probability and a confidence. System One models are built for decisions of that shape, not for conversation.
That shape is what a cost-aware matcher needs. Calibration means that when Jev says 0.9 it is right about 90% of the time, so the engine can weigh its answer against the price of a wrong match, and when Jev is unsure it says none of the candidates fits instead of guessing.
Matcha uses Jev only on the residual, the cases the engine cannot settle on its own, so a job of 100,000 addresses makes a few thousand Jev calls, not a hundred thousand. Put your TypeSafe API key in the environment, add adjudicate provider=jev; to the PROC MATCHA step, and leave allow_remote off until you have decided that those cases may leave your machine.
Turning Jev on
export TYPESAFE_API_KEY=... # never in a file
adjudicate provider=jev; # inside the PROC MATCHA step
Measured on the corrupted-address benchmark, Jev lifts correct matches from 83.3% to 87.8% at the engine's own 98.1% precision, with 0.8% wrong answers on the stage-by-stage ablation. On the real lookups typed by the public it matched the hard cases as often as the local model, and when no candidate was right it said so instead of picking one.
The engine matches against the table you give it, helped by open knowledge packs: US address points from the National Address Database, street aliases from Census TIGER, and Canadian addresses from Statistics Canada, all public domain or openly licensed. Jenner Analytics rebuilds the packs when their sources publish, validates them against the previous release, signs them and publishes them to a data channel.
Nothing on your machine changes until you run the update yourself. Every pack is verified against a signed manifest before a byte is extracted and swapped in atomically, so a running job sees the old pack or the new one and never a partial one. PROC MATCHA never downloads anything, and the report records which data release a run used.
Check, then update, on your schedule
jenner data update --check # what would change; writes nothing
jenner data update # install or refresh every pack
jenner data update --pin 2026.9.28
Locales
US is the default and Canada is supported, including bilingual forms. Locale packs for the UK, France, Japan, Korea and Australia are in progress. Each is data, not code, so adding a country adds a pack.
One matching engine for KYC, AML, fraud, credit risk, delivery and compliance
Addresses ship today. Every other match in the KYC family runs on the same engine: the same calibrated probabilities, the same cost-weighted decisions, the same outputs and the same evaluation run.
A new kind of match is an entity definition, not a new product: the roles a record has, the comparator for each role, the blocking strategy and the knowledge packs it may consult. The scoring, the decisions, the follow-up list and the evaluation are shared code, so a person-name match is evaluated and priced exactly like an address match.
Capabilities on the same engine
IP address to postal address: geolocation distance and VPN signals
Matcha compares where a session's IP address geolocates with the address the customer claims, using geodesic distance with the geolocation radius as the uncertainty. ASN, proxy and VPN flags count as evidence against, never as a verdict on their own. The result is the same calibrated probability and cost-weighted decision as an address match, so a fraud rule can act on it or route it to review.
Example: A card applicant gives a Denver address from an IP that geolocates 40 km away with no VPN flag: agree within the radius. The same address from a data-center IP in another country: conflict, and the row is priced for review.
Email to person and business: local part, domain and disposable signals
The email-identity entity tests whether an address belongs to the person and the organization claimed at onboarding. The local part is compared with the name tokens, first.last, initials and nicknames included; the domain is compared with the organization's registered domains; free-mail and disposable-domain lists and MX presence are evidence. Every signal is a comparator, and the engine says how strongly they agree.
Example:[email protected] against Jane Okafor at Northwind Actuarial: the local part agrees with the name and the domain agrees with the company. [email protected] against the same record: disposable domain, and the probability says so.
Business name matching: legal forms, acronyms and registry identifiers
The business entity strips legal forms by ISO 20275, weights rare words, expands acronyms and lets a registry identifier override the name: LEI, EIN, UEI and Companies House numbers. The GLEIF Level 1 data and EDGAR former names are knowledge packs, so a company that renamed itself still matches the counterparty on your books. Vendor validation, counterparty matching and KYB use the same run.
Example: "INTL BUSINESS MACHINES CORP" against "International Business Machines Corporation" with a matching LEI: match, registry-id override. "IBM Credit LLC" against the parent: nonmatch, with the legal form and rare-word evidence reported.
Person name matching: nicknames, transliteration, phonetics and date of birth
The person entity compares given, middle and family names with nickname packs, transliteration from Cyrillic, Arabic and CJK, phonetic comparison and name-order variants, and treats a transposed date of birth or a checksum-valid national ID as the evidence it is. A sanctions or PEP list is an ordinary reference table with the cost of a missed match set high, so screening and customer deduplication are the same engine with different prices.
Example: "Mohammed Al-Rashid, 03/07/1981" against "Muhammad Alrashid, 07/03/1981": transliteration agrees, the date is a day-month transposition, and the row comes back as a screening hit with its probability rather than a missed one.
Phone numbers and identifiers: IBAN, VIN, NPI and national IDs
Phone numbers are normalized to E.164 and checked for country and area consistency and carrier type. Identifiers are validated before they are matched: IBAN, VIN and NPI checksums, format and issuer consistency, national ID shapes. A valid identifier is strong evidence; an invalid one is a finding in its own right, reported before a single candidate is scored.
Example: An applicant's IBAN fails its mod-97 check: the row is flagged before matching, with the reason, instead of being scored against every account in the reference table.
Coordinates, households, transaction counterparties and product names
Entities compose. A device coordinate reverse-geocodes to the nearest address point; a household is an address match plus surname agreement; a transaction counterparty is a business or person plus an account and a country; a product or drug name matches by token containment with a code override. The scoring code does not know the difference, which is why each arrives on the same engine with the same evaluation run.
Example: A delivery app's GPS fix lands 30 m from the address on the order: agree, with the distance reported. Two customer records at one address with the surname in agreement: one household, with a calibrated probability on the link.
Verify the address, the email, the phone and the identifiers an applicant gives you in one step, with one probability per check and one follow-up question when something is ambiguous. Matcha resolves the address while the applicant is still on the page and asks "Milton or Morton?" instead of failing the check or waving it through.
Compare the session's IP location with the claimed address, the device coordinate with the delivery address, and the email with the person, and get evidence a rule can act on rather than a black-box score. Every candidate the matcher considered is reported, with the probability that the truth is not in your table at all.
Screen person and business names against sanctions and PEP lists with transliteration, nicknames, phonetics and date-of-birth transpositions, priced for screening: a missed hit expensive, a false alarm cheap. The list is a reference table, the evaluation run scores your hit rate against known cases, and the calibration curve tells you what a 0.9 means on your data.
Resolve the businesses on an application, a trade or a ledger to one legal entity across legal forms, former names and registry identifiers, so exposure is counted once. LEI, EIN, UEI and Companies House numbers override names when they are present and corroborate them when they are not.
Standardize every address to the postal rules of its locale, match it to your serviceable-address table, and learn when an address is real but outside your area or real but missing from your table. A device coordinate at the door confirms the delivery point, and the cost weights decide when a wrong address is worse than a rejected order.
Every decision carries a probability, a reason and the candidates considered, in tables you keep. Nothing leaves your machine unless you choose to add a model, the report records which data release a run used, and the same evaluation run reproduces a result for an auditor months later.
PROC MATCHA is part of Jenner, not a separate product and not a per-row fee. On Windows and Linux a Jenner license is bought once per machine and is perpetual: the version you buy keeps running for as long as you want to use it, with new releases and support included for a year. Jenner for macOS is on the Mac App Store, and the Workspace is billed by the hour.
There is no charge from Jenner Analytics for a row matched, a candidate considered or a question asked. If you choose Jev, TypeSafe prices it per input token, and it sees only the residual.
Jenner runs existing PROC DQMATCH and PROC DQSCHEME code for compatibility, so a SAS data quality program keeps working. Matcha is the recommended matcher for new work: it uses the same SAS-style statement syntax, but it returns a calibrated probability and a reason for every decision, can ask a follow-up question, and reads and writes CSV, Parquet, Avro and most databases through the same data= syntax, so you are not locked in to either tool.
No. The engine is native Rust inside the Jenner binary and makes no network calls; the reference data is the table you give it plus knowledge packs installed on your machine. Language models are off by default. A local model through Ollama keeps everything on your hardware. A remote model such as Jev is used only if you enable it in the configuration, and then it sees only the undecided cases with their candidates, never the whole file.
The United States is the default locale, with standardization to USPS Publication 28 and open address data from the National Address Database and Census TIGER. Canada is supported, including bilingual French forms and Canadian postcodes, with data from Statistics Canada. Locale packs for the UK, France, Japan, Korea and Australia are in progress. You can match against your own reference table in any country today; the packs add standardization rules and open address points.
Yes. The engine needs no service, no key and no network. Reference packs are installed once with jenner data update and refreshed only when you run that command again. With a local Ollama model the optional adjudication step is offline too; only Jev is a remote call, and only if you turn it on.
When the engine cannot decide between candidates and you have priced a follow-up channel, those rows come out as review with the ranked candidates, the exact field that would settle the question (suffix, direction, unit) and the probabilities. Your process turns that into a question to whoever can answer it: an SMS reply, a prompt on an onboarding form, a call-center screen. Nobody on the matching side reads those rows, and without a priced channel they are reported as nonmatch with the same candidates attached.
Give a run a truth file of inputs whose correct record you know and Matcha scores every decision against it: correct on the first try, precision, wrong answers, recall among the top five candidates, correct abstentions on out-of-area inputs, a calibration curve, and the expected cost at a range of error weights. The published results on this page come from the same run mode, on public lookups with known outcomes and on corrupted addresses with exact truth.
Yes, on the same engine. Addresses ship today. Person names, business names, email identity, IP location, phone numbers, checksummed identifiers and sanctions or PEP lists are entities the same engine matches, with the same calibrated probabilities, cost-weighted decisions, outputs and evaluation run. A screening list is an ordinary reference table with the cost of a missed match set high. Use the form on this page to request availability for the entity you need.
Matcha is included in Jenner, so you buy Jenner: a perpetual per-machine license for Windows and Linux, Jenner for macOS on the Mac App Store, or hourly Workspace credits. There is no per-row or per-match charge. The pricing page has the current plans and the free trial.
Yes. A sanctions or PEP list is a person or business reference table, and screening is matching with the costs turned around: a missed hit priced high, a false alarm priced low. The person entity handles nicknames, transliteration from Cyrillic, Arabic and CJK, phonetic comparison, name-order variants and date-of-birth transpositions, and the evaluation run scores your hit rate against known cases. Request availability from the form on this page.
Yes. The IP-location entity geolocates the session's IP address and compares it with the coordinates of the claimed address by geodesic distance, using the geolocation radius as the uncertainty, and treats ASN, proxy and VPN flags as evidence against. The result is the same calibrated probability and decision as an address match, so a fraud rule or a review queue can use it directly.
Yes. The business entity strips legal forms by ISO 20275, weights rare words, expands acronyms and lets a registry identifier override the name: LEI, EIN, UEI and Companies House numbers. GLEIF data and EDGAR former names are knowledge packs, so a renamed company still resolves to the counterparty on your books. That is vendor validation, counterparty matching and KYB in one run.
Jev is a System One model made by TypeSafe (typesafe.ai). Rather than generating text, it answers a typed question, which candidate, if any, is the same place as this address, with a choice, a calibrated probability and a confidence. Matcha uses it because that is the shape of a matching decision: when Jev says 0.9 it is right about 90% of the time, and when it is unsure it says none of the candidates fits. It is called only on the residual the engine cannot settle, a few thousand calls per 100,000 rows, and on the corrupted-address benchmark it lifts correct matches from 83.3% to 87.8% at the engine's own 98.1% precision. It is off by default and needs a TypeSafe API key in the environment and adjudicate provider=jev; in the step.
Yes. Point Matcha at a local model served by Ollama on your own hardware, fully offline, and the same adjudication step runs with nothing leaving the machine. We benchmark with qwen2.5:7b-instruct. A local model answers almost every case it is shown, which finds the most matches, 89.3% correct on the corrupted-address benchmark, and roughly doubles the wrong answers compared with Jev. You can also run both side by side and get an agree flag per row. Neither is required: the engine alone needs no model, no key and no network.
Try it on your own addresses
Run an evaluation against a few hundred records you can vouch for, and get one honest number for how good it is on your data.
Addresses ship today. Ask for an evaluation run on your own data, or request availability of a capability on the same engine, and we will reply with dates and what it takes to set up.
See Matcha for yourself
Buy Jenner and run PROC MATCHA on your own addresses, read the documentation, or watch the three-minute introduction to Jenner.
