The six DROP hash lists, explained
DROP matches against six published lists, each keyed to a different identifier. There’s no street-address list. Matching runs on these six only:
| List | What it’s built from |
|---|---|
| NDZ | name (first + last) + date of birth + ZIP, combined into one composite |
| a single standardized email address | |
| Phone | a phone number |
| MAID | a mobile ad ID |
| NameVIN | name + vehicle identification number |
| CTVID | a connected-TV ID |
Standardizing before hashing
Every identifier gets normalized to the state’s rules before it’s hashed. Get the formatting wrong and a real match reports as a miss. By type:
- Names: lowercase, accents folded off, Greek and Cyrillic characters transliterated per the platform’s published tables, ligatures normalized (ß becomes ss, for instance), and compound names collapsed.
- Date of birth: reformatted to YYYYMMDD.
- ZIP code: ZIP-5 only. The +4 extension is dropped and leading zeros are stripped.
- Email: trimmed and lowercased, keeping dots and plus-addressing intact rather than stripping them.
- Phone: reduced to the last 10 digits.
- VIN: alphanumeric, lowercased, 17 characters. MAID: hex characters only, lowercased, 32 characters. CTVID: alphanumeric, lowercased, 8-32 characters.
That per-type list isn’t a closed set of rules, either. 11 CCR §7613(a)(1)(A)(vi) requires a broker to implement any other standardization it knows will increase the likelihood of a match. The published formats are a floor, not the whole obligation.
A composite like NDZ is built by hashing each underlying field on its own, concatenating those Base64-encoded digests in order, and hashing the concatenation again. The single-field lists (email, phone, MAID, CTVID) skip the concatenation step and just hash the one standardized value.
Exact match, not close enough
Matching runs on exact equality only (11 CCR §7613). There’s no fuzzy or partial matching anywhere in the process. That cuts both ways. It means a broker doesn’t have to worry about a near-miss on a name spelling incorrectly flagging a match. It also means a genuinely matching record will report as “not found” (status 5) if the standardization was off by even a formatting detail: a ZIP with the +4 still attached, a phone number with a country code left on, an email that wasn’t lowercased. An honest “not found” is a compliant outcome when the hashes really don’t line up; the risk sits in standardization errors that make them not line up when they should have.
To catch exactly that kind of error, the state publishes worked examples with their expected hashes, and the DROP Sandbox (live since April 2026) includes a free standardization-and-hashing verification tool for checking an implementation’s output against them before it’s used for real matching. Book a 20-minute call to have that check run against an actual system rather than a sample record.
The trap: partial coverage
The costliest mistake isn’t a standardization bug. It’s an incomplete inventory. A broker holding customer emails in six different systems but only hashing the field in one of them will report clean matches on the table it checked and silent misses on the five it didn’t. The six lists describe what the state matches against; they say nothing about how many places inside a broker’s own systems each identifier type actually lives. Building the variant inventory (every table, every field, every system holding a name, an email, a phone number) is the part that takes longer than the hashing itself.
A worked example, in shape
Take an email entered as Jane.Doe+list@Example.COM , stray spaces and all. Standardization trims the whitespace and lowercases it (jane.doe+list@example.com) while leaving the dot and the plus-addressing alone, since those are meaningful to email standardization here, not noise to strip. That standardized string gets run through SHA-256 and the digest is Base64-encoded. The result isn’t reproduced here: a real hash value has no business appearing in a guide, and typing one in from a webpage isn’t how anyone should validate a pipeline. But the shape is predictable: a Base64-encoded SHA-256 digest comes out to somewhere around 44 characters, ending in a padding ”=”. Checking an implementation’s actual output against the state’s own published test vectors and sandbox tool is the way to confirm it’s right, not eyeballing the shape.
Related: For how these six lists fit into the recurring cycle, see The 45-day DROP cycle, operationally.
Common questions
Does any of this send raw consumer data to the state?
No. The DROP protocol itself exchanges only hashes. Records are standardized and hashed on the broker's side, and only those hashes are ever sent. Brokers never send raw consumer data through DROP. The exchange is hashes in both directions.
Which of the six lists does a broker need to select?
Every list that matches data the broker actually holds. 11 CCR §7610(a)(3) requires subscribing to every list that matches a held data type. A broker that holds none of the six data types still has to select at least one list and report. It can't opt out of reporting by opting out of every list.