Applicants, Checks, and Alerts

Applicant

An Applicant is the tenant-owned customer record. It provides continuity across onboarding, transactions, periodic screening, and later rechecks.

Use external_id for your stable customer identifier. Fidera returns its own immutable applicant_id; retain both.

Every Check is owned by an Applicant, including transaction and trade Checks. Other parties belong in the Check's subjects array rather than as temporary Applicants.

Check

A Check is an immutable evaluation and evidence record. Its submission, normalized query, active policy, data-source versions, timing evidence, provider result, derived decision, and match explanations describe what Fidera knew and how it evaluated the request at that point in time.

Use use_case to carry execution context:

• onboarding
• ongoing
• transaction
• lookback
• trade
• ad_hoc

That context can select policy thresholds and changes operational decisions. For example, an actionable transaction hit can produce hold.

Alert

An Alert is an actionable match from a Check. It adds mutable operational state around immutable evidence:

• assignment and unassignment;
• state transitions;
• SLA and escalation timestamps;
• false-positive or confirmed-match disposition;
• required reason and structured evidence;
• four-eyes proposal and approval;
• append-only event history.

An Alert is not a case. Fidera deliberately leaves investigation grouping and narrative ownership to your system.

Reconciliation model

Store Fidera identifiers with your own operational records:

Your record	Fidera values to retain
Customer	applicant_id, your external_id
Payment or trade	check_id, input_ref, your transaction reference
Investigation or case	One or more alert_id and check_id values
Webhook receipt	Fidera event ID and related resource IDs

Do not create a second source of truth for the Check evidence. Store the IDs, decision needed by your product, and an export if your retention policy requires it.