> ## Documentation Index > Fetch the complete documentation index at: https://docs.frankieone.com/llms.txt > Use this file to discover all available pages before exploring further. # Key Terms and Definitions > This page defines the key terms used across FrankieOne Fraud and Transaction Monitoring (v2). Use it as a reference when reading the Implementation Guide, Features Guide, or API documentation. ## Common terms | Term | Definition | Notes / Relationships | | :----------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------- | | **Entity** | A customer represented in FrankieOne. Can be an Individual or Organization. Identified by a unique **Entity ID**. | Anchor for risk, activities, accounts, and alerts. | | **Individual (entity)** | A person represented in FrankieOne, usually created via onboarding or import. | Most current flows focus on Individuals. | | **Entity ID** | Unique FrankieOne identifier for an entity (Individual or Organization). | Used to join activities, accounts, alerts and workflows. | | **Workflow (general)** | Configured sequence of steps FrankieOne runs for an entity (onboarding or monitoring). | Workflows drive when and how risk checks run. | | **Onboarding workflow** | Workflow type used for KYC/KYB and onboarding fraud checks. | Shares core concepts (steps, PROs, feedback) with monitoring workflows. | | **TM** | TM refers to the Transaction and Activity Monitoring product, also referred to as Transaction Monitoring in navigation and headings. The full name — Transaction and Activity Monitoring — is used in API and technical contexts. | TM is the standard abbreviation for the product. TxAM appears only in the technical bundle identifier Basic-Monitoring-TxAM. | | **Monitoring workflow** | Workflow type used for ongoing transaction and activity monitoring (AML, Fraud, Events). | Reuses same workflow engine as onboarding with monitoring-specific steps. | | **Workflow step** | Single executable unit inside a workflow (e.g. device check, fraud TM step, AML TM step, event monitoring). | Each step can produce one or more PROs and activity results. | | **workflowExecutionId** | Unique identifier for a single run of a workflow for an entity. | Used to trace the full run, including all steps and PROs. | | **workflowName** | Logical name for a workflow (e.g. “Onboarding – Retail”, “TM – AML-Fraud”). | Used in config, analytics, and reporting. | | **Process Result (PRO) / Alert** | Core result object from running a workflow step. PRO stands for Process Result and represents an alert in FrankieOne. | PRO ID = alert ID; holds risk details, status, related activities. | | **Transaction ID / transactionIdentifier** | External or provider transaction identifier | Used for debugging, grouping, and feedback. | | **Session key (sessionKey)** | Identifier for a device / session context for an activity. | Critical for device and behavioral risk signals and linking related events. | | **Account** | Logical representation of a customer account (e.g. bank account, card, wallet) associated with an entity. | Account properties can be used as risk factors. | | **Account external reference** | Client’s identifier for an account in their own system. | Used for reconciliation and mapping to FrankieOne accounts. | | **Account metadata** | Additional attributes on the account (e.g. account type, VIP flag, product tier). | Treated as risk factors and can influence monitoring decisions. | | **Custom attributes (general)** | Client-defined key–value pairs added to entities, activities, accounts or alerts. | Used to enrich data and as optional risk factors. | | **Entity custom attributes** | Custom attributes attached to an entity (e.g. risk segment, customer tier, KYC channel, referral source). | Can affect risk assessments and segmentation. | | **Activity custom attributes** | Custom attributes attached to an activity (e.g. merchant category, campaign ID, promo code, channel). | Used heavily in TM to contextualise transactions and events. | | **Risk assessment** | The process where FrankieOne evaluates the risk of an entity, activity, or account using provider signals and risk handlers. | Outputs a normalized FrankieOne risk level used by both products. | | **Risk handler** | Backend logic that ingests provider signals and maps them into FrankieOne risk factors and outcomes. | Same framework used; triggered at different stages (onboarding vs monitoring). | | **Risk factor** | Input used during risk assessment, such as device signals, rule hits, behavior patterns, custom attributes, or account metadata. | Shared conceptual list, different subsets may be relevant per product. | | **Risk level / risk outcome** | Normalized risk evaluation (e.g. LOW, MEDIUM, HIGH, VERY\_HIGH or internal mappings like UNACCEPTABLE). | Derived from provider scores. | | **Alert** | A Process Result (PRO) that has met the risk threshold to require attention. It is generated from an activity evaluation or workflow step. It is distinct from an Issue. An alert is an evaluation output; an issue is a workflow problem requiring intervention. | Central unit of work for analysts/ops teams. | | **Alert ID** | Identifier for an alert in FrankieOne, typically the **Process Result (PRO) ID**. | Used in UI and APIs for alert management. | | **Alert class / subclass** | Type of alert, such as `ACTIVITY_AML`, `ACTIVITY_FRAUD`, `ACTIVITY_EVENT`. | Enables filtering, routing, and reporting. | | **Alert status / manualStatus** | Operational status of an alert, e.g. Needs attention, In review, True positive, False positive. | Drives analyst workflows and SLAs. | | **Issue** | A problem raised during a workflow that requires manual review or intervention (for example, an AML alert generates an AML issue). It is distinct from an alert. Issues are workflow-level flags; alerts are risk evaluation outputs. | | ## Transaction and Activity Monitoring Terms | Term | Definition | Notes / Relationships | | :----------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------- | | **Activity** | An event or operation associated with an entity (transactional or non-transactional) that FrankieOne and your provider evaluates. | Core object monitored for risk; can generate alerts (PROs). | | **Transaction activity** | Activities representing financial movements (for example, fiat transfer, fiat deposit, fiat withdrawal, card payment, crypto transfer). | Primary focus for Transaction and Activity Monitoring v2 workflows. | | **Event-based activity** | Non-financial events (for example, account create, login fail, insufficient funds, KYC fail or pass, challenge fail or pass). | Important for device/behavior signals and non-transactional fraud. | | **Activity ID** | Unique identifier for an activity in FrankieOne | Used to link activities to PROs (alerts), feedback, and workflows. | | **Activity request ID** | Client-supplied identifier for an activity request, used for idempotency and tracking. | Helps reconcile client systems with FrankieOne activities. | | **Activity custom attributes** | See also: Activity custom attributes in Common terms above. | Used heavily in TM to contextualise transactions and events. | | **Alert origination webhook** | Webhook notifying clients when a new alert is created. | Includes entity, activity/activities, alert metadata, custom attributes. | | **Alert resolution webhook** | Webhook notifying clients when an alert is resolved. | Includes final status, decision, classifications/reasons when present. | ## How key objects relate When FrankieOne evaluates an activity, it produces one or more **Process Results (PROs)** — each representing the outcome of a single check (for example, an AML check or a fraud check). PROs that meet the risk threshold to require attention are surfaced as **alerts** in the FrankieOne Portal. An **issue** is a separate, distinct object — a problem raised during a workflow that requires manual review or intervention. Issues are created for significant events, such as a high-risk AML transaction alert or a fraudulent activity, and provide clear guidance on the next steps. In summary: | Object | What it is | | ---------------------------- | ---------------------------------------------------------------------------- | | Activity | An event or transaction submitted for evaluation | | Process Result (PRO) = Alert | The outcome of evaluating an activity; surfaced when risk thresholds are met | | Issue | A workflow-level problem requiring manual review or intervention |