What Is Exact Data Match (EDM)?

What problem does EDM solve?

Pattern detectors answer "does this look like an email?" They can't answer "is this one of our customers?" A prompt that says "summarise the complaint from maria.keller@example.com" contains an email either way. The question that matters to the business is whether that address is in your customer table.

Internal identifiers make this sharper. A customer number like KD-48213 has no public format, no checksum and no context word that a rule could rely on. Only the list of real customer numbers can tell it from an invoice reference. EDM is that list, turned into something a detector can use.

How does EDM work without sharing the data?

The usual objection to custom-data detection is obvious: to recognise your customers, a vendor would need your customer list, and uploading that creates the very exposure you want to prevent. EDM avoids it with keyed hashing. In Maskflare's design:

1. Normalise. The command-line tool reads your CSV locally and normalises each value: case, accents and Unicode look-alike characters, so María and MARIA become the same input.
2. Hash. Each value is hashed with a key issued for your organization (HMAC-SHA256, truncated). The same value hashes the same way every time, and nobody without the key can reproduce the hash.
3. Upload hashes only. The tool sends the hashes. It doesn't upload or print the values in your file.
4. Match at request time. Text in AI traffic is split, normalised and hashed the same way and looked up in the table. A hit is treated like any other detection: it is masked, redacted, alerted or blocked by the rule's action.

Because the hash is keyed per organization, a stolen table is useless outside your workspace. Setup steps and capacity are on the Exact Data Match module page.

A worked example

Your customer table has a row for Ada Lovelace with the account number KD-48213. An employee pastes a ticket into an AI assistant:

Employee sends:  Please reply to Ada Lovelace about account KD-48213.
Maskflare sees:  a name and an identifier whose keyed hashes are in the dataset
Provider gets:   Please reply to mf_mask_9c2e... about account mf_mask_41d7...

A different person named in the same ticket, who is not in the dataset, would be left to the name detector and the NER layer. EDM only adds certainty about the values you loaded. It never removes anything the other detectors find.

What are the limits of EDM?

• Exact means exact. After normalisation, the value must match. A misspelling (Lovelase), a nickname or a different account number format won't. Normalisation absorbs case, accents and look-alike characters, not typos.
• It only knows what you loaded. A new customer isn't detected until the next upload. Re-upload on a schedule that matches how fast your data changes.
• Short or common values are noisy. A first name alone, or a very short code, appears everywhere. Use multi-field values such as first and last name together, and test the rule in alert mode.
• A keyed hash is protection, not anonymity. A hash of a guessable value, such as a common name, can be confirmed by anyone who holds the key. Treat the key as a secret and delete a dataset (and its key) when you no longer need it.
• Capacity is bounded. There are limits on datasets, fields and total values per organization; the module page lists them.

How does EDM relate to DLP?

EDM is a long-standing feature of data loss prevention products, where it is also called structured data fingerprinting. The idea is the same across vendors: fingerprint the real records, then look for the fingerprints. What differs is where the hashing happens and who holds the key, so ask any vendor both questions.

In Maskflare, EDM rules run with the other detectors on every route, gateway, SDK or proxy, and take the action you set per rule. Start in alert mode to see how many of your own records leak into prompts, then move to mask or block. The detection engine page shows how the pieces fit.