States and identifiers

Identifier rules

Fidera UUIDs identify resources globally, but every read and mutation is tenant-scoped. A resource outside the caller's tenant is not discoverable.

• applicant_id identifies the customer record in Fidera.
• check_id identifies one immutable evaluation.
• alert_id identifies one actionable match workflow.
• input_ref records the customer-supplied Check reconciliation reference.
• external_id records a customer-supplied Applicant, Batch, or Monitor reference where supported.

Treat every Fidera ID as opaque. Do not infer timestamps, tenancy, ordering, or resource type from its representation.

Check decisions

Decision	Meaning
clear	Configured policy found no condition requiring intervention
review	An operator or customer decision is required
hold	Do not release the associated transaction or action
error	Required evaluation did not complete

A decision is policy output, not a legal conclusion. Your compliance program owns the customer action.

Alert states

new → investigating → escalated
  └───────────────→ cleared_false_positive
  └───────────────→ confirmed_match
cleared_false_positive | confirmed_match → closed

Allowed transitions are enforced by the API. A false-positive or confirmed-match disposition requires both disposition_reason and disposition_evidence.

When four_eyes_required is true on the Alert, one operator proposes the disposition and a different supervisor or admin approves it. The proposer cannot approve their own action.

Customer-owned cases

Fidera has no Case resource and no /v1/cases endpoint. A customer case can group any number of Applicants, Checks, and Alerts. Keep that grouping in your system and pass only the relevant Fidera IDs when retrieving evidence or performing Alert actions.