> ## Documentation Index
> Fetch the complete documentation index at: https://docs.profiledrisk.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Keywords & Definitions

> This section defines the core terms used across the ProfiledRisk APIs, dashboard, webhooks, and reports. These definitions are consistent across all use cases (Onboarding, Banking, Payments, Lending, and Reporting).

This section defines the core terms used across the ProfiledRisk APIs, dashboard, webhooks, and reports. These definitions are consistent across all use cases (Onboarding, Banking, Payments, Lending, and Reporting).

### Core Entities

**Profile**\
A unique entity being monitored by ProfiledRisk. This can represent a user, customer, merchant, device, agent, wallet, or any identifier you choose. All related events, scores, and cases are linked to a Profile.

**Profile ID**\
A unique identifier assigned by ProfiledRisk to a profile. It appears in API responses, dashboard views, and reports. It is different from your internal `user_id` or account identifier, but they are linked.

**Event**\
A single occurrence sent from your system to ProfiledRisk, such as a login, payment attempt, onboarding action, transfer, or loan request. Events are evaluated against rules and intelligence to produce a decision.

**Event ID**\
A unique identifier assigned by ProfiledRisk to each event. Used for traceability across API logs, cases, and reports.

**Case**\
An investigation object created when an event or profile requires manual review. Cases group related context (events, risk factors, device history) and record analyst decisions.

**Case ID**\
Unique identifier for a Case in ProfiledRisk. Used in dashboard, audit logs, and reports.

### Rules, Flows, and Logic

**Flow**\
A configuration of rules and checks that define how a specific event type is evaluated. Flows are managed in the dashboard and determine which conditions must be met for a status to be returned.

**Rule**\
A single conditional statement used within a Flow. For example:\
“If `amount` > 100000 AND `device` is new THEN set status to `pending`.”

**Risk Logic**\
The combined evaluation of flows, rules, and intelligence signals applied to each event. This logic produces the final `status`, `risk_score`, and `risk_level`.

### Event Classification Fields

**type**\
Top-level category for an event. Examples include:

* `onboarding`

* `banking`

* `payments`

* `lending`

The `type` value determines which flow(s) and rule sets will evaluate the event.

**channel**\
How the event was initiated in your system. Common examples:

* `mobile`

* `online`

* `pos`

* `atm`

* `branch`

Used for behavioral analysis and channel-specific rules.

**purpose**\
Business intent of the event or transaction (for example `salary payment`, `bill payment`, `airtime`, `transfer`). Used primarily for rule conditions and analytics.

**direction** (where applicable)\
Describes the movement of funds for a transaction. Common values:

* `inbound`

* `outbound`

Used in Banking/Payments contexts for exposure and laundering checks.

### Risk and Decision Fields

**status**\
The primary decision output returned by ProfiledRisk for an evaluated event. Possible values:

* `allowed` – event is considered safe to proceed

* `blocked` – event should not proceed

* `pending` – event requires manual review before proceeding

Your system is expected to enforce this status in your own workflow.

**risk\_score**\
A numeric value representing the assessed risk of the event or profile. Typically a range from 0 to 100, where higher values indicate higher risk.

**risk\_level**\
A categorical classification derived from the `risk_score`, such as:

* `low`

* `medium`

* `high`

* `very high`

Levels can be mapped to your internal policies for routing or escalation.

### User and Context Fields

These fields are not enforced globally but appear frequently across event payloads:

**user\_id**\
Your internal identifier for the user or account. Used to link your system to a Profile in ProfiledRisk.

**user\_type**\
Describes the category of the profile

**account\_type**\
Type of account serviced by your system.

**tier**\
Internal classification of the user or account, often linked to KYC or product access

**kyc\_information**\
Structured identity data (for example `id_number`, `id_type`, `country`) sent during onboarding or updates. Used for risk and compliance checks.

**device**\
Object describing device attributes such as `device_id`, `os`, `model`, `language`, `ip_address`. Used to detect account takeover, device sharing, and network anomalies.

**address**\
Structured postal or location information associated with the user or transaction. Often used for geolocation risk, jurisdiction checks, and AVS-related logic.

**meta**\
Flexible key-value structure for custom attributes that are specific to your product or risk model. Meta fields are not predefined by ProfiledRisk but can be used inside your rules.

### Reporting and Compliance

**STR (Suspicious Transaction Report)**\
Report generated when activity is confirmed as suspicious. Prepared by ProfiledRisk and downloaded by your compliance team for filing.

**CTR (Currency Transaction Report)**\
Report generated for cash or cash-equivalent transactions that meet defined threshold rules.

**FTR (Fraud Transaction Report)**\
Report generated when transactions are confirmed as fraud after investigation.

**Reporting Entity**\
The regulated institution or organization responsible for filing STR/CTR/FTR documents. Entity details are configured once in the dashboard and reused across all reports.

### Webhook and Integration Terms (High Level)

**Webhook**\
An HTTP callback configured by you to receive decisions and case-related notifications from ProfiledRisk in real time.

**Webhook endpoint**\
The URL in your system that ProfiledRisk sends event decisions and updates to.

### How to Use This Glossary

* Use these definitions as the baseline when reading API responses, event schemas, and dashboard labels.

* Any field that appears in multiple endpoints will use the meaning defined here.

* Schema-specific documentation will only detail field format and constraints, not re-define the concept.