Applicants and Checks

Applicant

An Applicant is the tenant-owned customer record and the owner of every Check. Use external_id for your stable customer identifier and retain the Fidera applicant_id.

Transaction and trade counterparties are typed, role-bearing Check subjects. They do not need temporary Applicant records.

Check

A Check is one immutable evaluation. It records:

• the normalized query and typed subjects;
• use case and synchronous or asynchronous mode;
• policy snapshot and content-addressed policy version;
• dataset and source versions;
• result, derived decision, timing, and provider evidence;
• nested matches evidence and summary counts;
• explicit flow_id, batch_id, monitor_id, and previous_check_id lineage where applicable.

origin is derived as direct, flow, batch, or monitor.

Nested match evidence

A matches entry records how one Check associated a subject reference with a source entity. It contains the score, categories, datasets, source evidence, stable key, and material_hash. It is part of the Check aggregate, not a top-level resource, table, or independently addressable API object.

Direct, Flow, and Batch Checks classify evidence as observed. Monitor Checks compare against the previous successful Check:

Change	Meaning
new	The stable key did not exist in the prior successful Check
changed	The key existed but query or source evidence changed
unchanged	Key and material evidence are identical
removed	The prior key is absent now; present is false

Nested evidence is not an assignment, disposition, or case. Fidera does not mutate or suppress screening evidence based on a customer investigation outcome.

Why evidence is nested

Match evidence only has meaning under the Check's query, policy, dataset versions, and timing. Nesting makes that context unavoidable and retrieves the complete immutable evaluation in one request. Compact match_count and match_change_counts fields keep Check lists filterable without creating a second resource.

The tradeoff is that individual match entries cannot be paginated or queried globally. Integrations first filter Checks, then read the selected Check's evidence.

Ownership boundary

Fidera owns screening execution, evidence, policy and data versions, recurring scheduling, change detection, delivery, and technical audit.

Your systems own assignment, investigation, SLA, escalation, disposition, four-eyes approval, narratives, and case grouping. A customer case can retain Fidera applicant_id, check_id, monitor_id, and input_ref values, plus nested evidence keys when useful.