States and identifiers

Identifier rules

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

• applicant_id identifies the durable customer record.
• check_id identifies one immutable evaluation.
• match_key identifies the same Applicant, subject reference, and source entity across Monitor Checks. It is scoped to nested Check evidence, not a resource ID.
• monitor_id, batch_id, and flow_id identify the Check's execution parent where applicable.
• previous_check_id links a Monitor Check to the prior successful Check.
• input_ref records your Check reconciliation reference.
• external_id records your Applicant, Batch, or Monitor reference where supported.

Treat Fidera IDs and cursors as opaque.

Check outcomes

Decision	Meaning
clear	Configured policy found no reportable Match
review	A non-transaction Check produced a Match
hold	A transaction Check matched or required screening failed
error	Required evaluation did not complete

The decision is screening policy output, not a disposition or legal conclusion. Your compliance program owns the action.

Match evidence change types

• observed: evidence recorded by a direct, Flow, or Batch Check;
• new: first appearance relative to a Monitor's previous successful Check;
• changed: stable key, different query or source material;
• unchanged: stable key and material;
• removed: previously present but absent now, with present=false.

Customer-owned workflow

Fidera has no Alert or Case resource. Your case can group any number of Applicants, Checks, Monitors, and customer references. Keep assignee, SLA, disposition, approvals, and narrative in your system.