Entity Resolution Prompt for Identity Matching

This prompt is designed for fraud, security, and identity resolution teams who need to compare two identity records and determine whether they refer to the same individual. It handles real-world messiness: transliterated names, data entry errors, address changes, and deliberate obfuscation. Use it when you need a structured match decision with rationale, not just a binary yes/no. This prompt belongs in onboarding verification, watchlist screening, duplicate account detection, and KYC remediation workflows. It is not a replacement for deterministic matching on exact government ID numbers; it is the reasoning layer that handles the cases where exact matching fails.

The ideal user is an engineering lead or product manager building an automated identity verification pipeline. The required context includes two identity records—each containing fields like name, date of birth, address, and document numbers—along with a defined risk tolerance. The prompt expects you to specify the match confidence threshold that triggers automatic approval versus human review. You must also define the output schema, typically a JSON object containing a match decision, confidence score, and a rationale field that explains which attributes matched, which conflicted, and why. Without this structured output contract, the model's reasoning is not auditable, and the decision cannot be reliably integrated into downstream systems.

Do not use this prompt for high-volume, real-time matching where latency is critical and deterministic rules suffice. If you have exact matches on government-issued ID numbers, use a database lookup. Do not use this prompt as the sole decision-maker for high-stakes actions like account creation or transaction approval without a human review step for low-confidence matches. The prompt is a reasoning layer, not a source of truth. Always log the full prompt, response, and model version for audit trails. Before deploying, test the prompt against a golden dataset of known matches and non-matches, including edge cases with transliterated names, swapped name components, and address variations, to calibrate your confidence thresholds.

This prompt template is designed to be pasted directly into your system instructions for an identity resolution task. It instructs the model to act as an identity resolution analyst, comparing two identity records and determining the likelihood that they refer to the same individual. The template is built for high-stakes fraud and security workflows, so it requires the model to reason about deliberate obfuscation, data entry errors, and transliteration differences rather than just performing a simple string match. Before using this prompt, ensure you have a clear policy on how the output will be used—automated blocking, manual review queue, or audit trail—because a false match in this domain can have severe consequences.

textCopy
You are an identity resolution analyst. Your task is to compare two identity records and determine the likelihood that they refer to the same individual. You must reason carefully about name variations, data entry errors, transliteration differences, and potential deliberate obfuscation.

## INPUT
Record A: [RECORD_A]
Record B: [RECORD_B]

## MATCHING RULES
1. **Exact Match**: All normalized fields match exactly.
2. **High Confidence Match**: Minor variations exist that are explainable by common data entry errors (typos, transpositions), known nickname patterns, or standard transliteration differences. No conflicting fields.
3. **Possible Match**: Some fields match but others are missing, partially match, or have conflicts that could be explained by data aging (e.g., address change) or clerical error. Requires human review.
4. **Low Confidence Match**: Only weak identifiers match (e.g., common name and city only) or there are significant unexplained conflicts.
5. **No Match**: Critical identifiers conflict and cannot be reconciled.

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "match_decision": "EXACT_MATCH" | "HIGH_CONFIDENCE" | "POSSIBLE_MATCH" | "LOW_CONFIDENCE" | "NO_MATCH",
  "confidence_score": 0.0 to 1.0,
  "rationale": "A concise explanation of the key factors that led to this decision.",
  "matched_fields": ["list of fields that matched"],
  "conflicting_fields": ["list of fields with conflicts and a brief description of the conflict"],
  "missing_fields": ["list of fields missing from one or both records"],
  "obfuscation_indicators": ["list of any indicators suggesting deliberate identity manipulation, or an empty list if none"]
}

## CONSTRAINTS
- Do not assume a match based on a single identifier like name or date of birth alone.
- Treat missing data as neutral, not as evidence for or against a match.
- Flag any indicators of deliberate obfuscation, such as: swapped name components, slightly altered document numbers, inconsistent formatting designed to evade exact-match systems, or use of multiple aliases.
- If you cannot make a determination, set the decision to POSSIBLE_MATCH with a low confidence score and explain what information is needed to resolve the ambiguity.

To adapt this template, replace the [RECORD_A] and [RECORD_B] placeholders with your serialized identity records. The records should be provided as structured text, ideally with consistent field labels like Name, DOB, Address, Document_Number, and Phone. If your records contain nested objects or arrays, flatten them into a readable text block before insertion. For production use, you should also add a [RISK_THRESHOLD] parameter if your downstream system needs to automatically escalate matches above a certain confidence level to a human review queue. The output schema is designed to be parsed by an application, so validate the JSON structure before acting on the match_decision field. In high-risk deployments, log the full prompt and response for audit purposes and never automate actions on POSSIBLE_MATCH or LOW_CONFIDENCE decisions without human approval.

This prompt is not a standalone tool; it is a decision component inside a larger identity resolution pipeline. The application layer is responsible for assembling the input records, enforcing schema contracts, managing model calls, validating the output, and deciding whether to accept, retry, or escalate the match result. Treat the prompt as a function with a strict input signature and a structured output that must pass validation before any downstream system acts on it.

Input assembly starts with two identity records, each containing the fields specified in the prompt template: name, date of birth, address, and document numbers. The application must normalize these fields before they reach the prompt. Convert dates to a consistent format (ISO 8601), trim whitespace, and handle null fields explicitly by passing the string "null" rather than omitting the field. For address fields, run a lightweight normalization step first—expand common abbreviations and standardize casing—so the model spends its reasoning budget on resolution logic rather than surface formatting. If the input records come from different source systems, attach a [SOURCE] label to each record so the model can weigh source reliability when explaining its match decision.

Model selection matters for this task. Use a model with strong reasoning capabilities and a large context window if you are passing full address histories or multiple document numbers. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro are appropriate starting points. Avoid smaller or older models that may struggle with transliterated name comparison or deliberate obfuscation detection. Set the temperature to 0 or a very low value (0.1 maximum) to reduce variance in match likelihood scores. If your throughput demands are high, consider batching multiple record pairs into a single request with a clear delimiter, but keep each pair's analysis independent to avoid cross-contamination of reasoning.

Output validation is the critical gate before any automated action. Parse the model's JSON response and validate it against a strict schema: match_likelihood must be one of the defined enum values, confidence_score must be a float between 0.0 and 1.0, rationale must be a non-empty string, and flags must be an array of strings from the allowed flag set. If the output fails schema validation, do not silently accept it. Log the failure, capture the raw response, and retry with the same input plus a repair instruction that includes the specific validation error. After two failed retries, escalate to a human review queue with the original records and all model responses attached.

Human review integration is mandatory for high-risk decisions. Any match with a confidence score below your organization's threshold (start with 0.85 and adjust based on observed performance) should route to a review queue, not an automated system. The same applies to matches where the flags array contains "potential_obfuscation", "synthetic_identity_risk", or "conflicting_evidence". Build the review interface to display both input records side by side, the model's match likelihood and rationale, and a simple accept/reject/override control. Log every human decision to build a feedback dataset for future prompt improvements and potential fine-tuning.

Logging and observability are essential for this workflow. Log every request with a unique correlation ID, both input records, the raw model response, the validated output, the final decision (auto-accepted, auto-rejected, or escalated), and any human override. This audit trail is non-negotiable for fraud and security use cases. Monitor the distribution of confidence scores over time—a sudden shift toward higher or lower scores may indicate prompt drift, model behavior changes, or a change in the input data distribution. Set up alerts for spikes in schema validation failures or escalation rates, as these often signal upstream data quality problems or model degradation that require prompt revision.

What to avoid: Do not use this prompt to make fully automated decisions on high-stakes identity matches without human review. Do not pass raw, unnormalized data and expect the model to handle formatting inconsistencies reliably. Do not skip output validation—malformed JSON or missing fields will break downstream systems silently. Do not ignore the flags field; it exists specifically to surface risks that the confidence score alone may not capture. Finally, do not treat this prompt as static. Plan to review and update it quarterly based on production logs, human reviewer feedback, and new obfuscation patterns observed in your domain.