Skip to main content
Corsa can’t read HYOK-encrypted values, so any feature that needs the plaintext doesn’t work on those fields. Features on fields you don’t encrypt are unaffected. This page lists every difference so you can choose your fields with full information.

​
Feature comparison

​
Screening on encrypted names

When name fields are HYOK-encrypted, Corsa screens them with exact-hash matching:
  1. For your workspace, Corsa normalizes every primary name and alias on the screening list and computes its keyed index with your workspace’s salt. It recomputes these indexes whenever the list is updated.
  2. Corsa compares them with the stored keyed index of the client’s name.
  3. A client matches when their complete normalized name equals a list name or alias:
    • full name (for example a company’s legal name);
    • first, middle, and last name together, in given-name-first or family-name-first order;
    • first and last name, when the list entry has no middle name.
Normalization ignores case, accents, punctuation, and extra spaces. José María García-López and JOSE MARIA GARCIA LOPEZ match. Exact-hash matching doesn’t find:
  • transliteration variants (Mohammed vs Muhammad);
  • typos and spelling variants;
  • partial names, initials, or a first or last name on its own;
  • nicknames that aren’t listed aliases.
Matches have a confidence score of 1 and are labeled exact-hash match in the alert. Date of birth, nationality, and other attributes don’t affect exact-hash matches. Fuzzy screening is shown as unavailable for the encrypted name fields.
Exact-match screening has a higher false-negative rate than fuzzy screening. Discuss compensating controls with your compliance team. For example, keep names unencrypted and encrypt only identifiers and contact details, choose BYOK instead, or screen names in your own systems before ingest.

​
Eligible fields

You can encrypt these fields with HYOK: Corsa rejects any other field for HYOK with HTTP 400. It also rejects an eligible field when a rule or workflow trigger uses it in a non-equality condition. Change the rule first, or keep the field unencrypted. Exact search and screening compare normalized values, so formatting differences don’t matter: