Identity data comparison (v1)

Stable / GA

This is the current stable version of this step type.

Compares identity details from two sources using step IDs configured in options

Ensures the identity information collected from different steps or documents refers to the same person, improving decision accuracy. Both source steps are declared by their IDs in the options object. Use Identity data comparison (v2) for new flows — v2 wires operands via inputMapping and validates the data flow at publish time.

---

Key features

• Dual source comparison: Compares identity data from two distinct BasicIdentity data blocks produced by earlier steps.
• Configurable attributes: Select which fields to compare — givenName, familyName, name, or birthDate. At least one attribute is required.
• Dual comparison modes: strict requires exact matches; tolerant accepts minor name variations and ignores the day component of dates.
• Detailed ComparisonResults output: Produces a ComparisonResults data block on both routes, including a per-attribute breakdown of compared, mismatched, and missing fields.

---

Configuration

Option	Type	Required	Description
leftOperand	string	Yes	The id of the step that produced the first BasicIdentity data block. Must differ from rightOperand.
rightOperand	string	Yes	The id of the step that produced the second BasicIdentity data block. Must differ from leftOperand.
attributes	string[]	Yes	BasicIdentity field names to compare. At least one required. Accepted values: givenName, familyName, name, birthDate.
mode	string	Yes	Comparison mode: "strict" (exact match) or "tolerant" (minor variations accepted). See Comparison mode details. Accepted values: strict, tolerant.

Comparison mode details

Mode	Name comparison	Date comparison
strict	All words from both names must have a "close enough" match.	Dates must be exactly equal.
tolerant	At least one word from the first name must have a "close enough" match in the second name.	Year and month must match; day is ignored.

---

Input data blocks

The flow validation system ensures the steps referenced by leftOperand and rightOperand are reachable and each produces a BasicIdentity data block.

Input slot	Data block	Required	Description
basicIdentity1	BasicIdentity	Yes	First identity source — wired via inputMapping.
basicIdentity2	BasicIdentity	Yes	Second identity source — wired via inputMapping.

---

Comparison logic

The step derives an internal verdict and maps it to one of two routes. Both noMatch and inconclusive route to failure.

Internal verdict	Route	Description
match	match	All specified attributes were compared and all values matched.
noMatch	failure	At least one compared attribute did not match. Takes priority over inconclusive when both mismatches and missing values are present.
inconclusive	failure	One or more required attribute values were missing, making comparison impossible. No mismatches were detected among the available attributes.

---

Routes

Route	Description
match	All specified attributes were compared and all values matched.
failure	At least one attribute did not match, or one or more required attribute values were missing.

---

Output data blocks

Route	Data blocks produced
match	ComparisonResults
failure	ComparisonResults

---

Example payloads

ComparisonResults — match

{
  "verdict": "match",
  "leftOperand": "doc-id-step",
  "rightOperand": "eid-step",
  "attributesCompared": [
    "givenName",
    "familyName",
    "birthDate"
  ],
  "mismatchedAttributes": [],
  "missingAttributes": []
}

ComparisonResults — noMatch

{
  "verdict": "noMatch",
  "leftOperand": "doc-id-step",
  "rightOperand": "eid-step",
  "attributesCompared": [
    "givenName",
    "familyName",
    "birthDate"
  ],
  "mismatchedAttributes": [
    "familyName"
  ],
  "missingAttributes": []
}

ComparisonResults — inconclusive

{
  "verdict": "inconclusive",
  "leftOperand": "doc-id-step",
  "rightOperand": "eid-step",
  "attributesCompared": [
    "givenName",
    "familyName"
  ],
  "mismatchedAttributes": [],
  "missingAttributes": [
    "birthDate"
  ]
}