> For the complete documentation index, see [llms.txt](https://detected.gitbook.io/detected-api-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://detected.gitbook.io/detected-api-docs/terminology.md). # Terminology Definitions of the key terms used across the Detected platform and API. ## Alert A notification that something about a profile has changed and may need a compliance review. Alerts are raised by [monitoring](#monitoring) in two situations: * a new screening hit is found on a profile, for example a new sanctions or PEP match * the company data on a profile changes, for example a change of director or registered address Each alert records what changed, with its previous and current value. Analysts review alerts in [case management](#case-management), and acknowledge or clear them with a comment. Alerts can be assigned to [teams](#team). **Related:** [Monitoring](#monitoring), [Profile](#profile), [Team](#team)\ **In the API:** the **Alerts** section. ## Audit Log The complete history of what has happened on a profile. Each entry records the action taken (for example a profile being updated), the resource it was taken on, who or what performed it (a user or the system), which application it came from, when it happened, and the reason where one was given. The audit log gives compliance teams and auditors a traceable record of every decision and change, across all profiles in an account. A profile has many audit log entries over its lifetime. **Related:** [Profile](#profile), [Case Management](#case-management)\ **In the API:** the **Audit Logs** section. ## Brand A distinct customer-facing identity within an account, with its own logos, fonts and styling for buttons and inputs. When the multi-brand module is enabled, an account can have multiple brands, so that customers go through onboarding under the brand they know, while every brand is managed from one central compliance environment. A profile can be assigned to a brand when it is created, or later by updating the profile. The brand decides how the [onboarding portal](#onboarding-portal) looks for that profile. **Related:** [Profile](#profile), [Onboarding Portal](#onboarding-portal)\ **In the API:** the **Brands** section, and the `brand_id` field when creating or updating a profile. ## Case Management The application analysts use to review and manage cases. It brings together everything held on a [profile](#profile) (company data, representatives, documents, screening results, risk analysis and decisions) in one workspace, so reviewers don't need to piece information together from separate tools. Case management also contains all of the administrative functionality, including managing users, [teams](#team) and API keys. **Related:** [Case Management User](#case-management-user), [Team](#team), [Profile](#profile) ## Case Management User A person who uses [case management](#case-management), typically a compliance analyst or administrator. Case management users review profiles, work through [checklists](#checklist), handle [alerts](#alert) and make decisions. A profile can be assigned to a single case management user, who is then responsible for it, and users can be grouped into [teams](#team). **Related:** [Case Management](#case-management), [Team](#team), [Profile](#profile)\ **In the API:** the **Case Management Users** section, and the `assignee_id` field when updating a profile. ## Checklist A structured list of the review tasks that need to be performed on a [profile](#profile). Case management users complete the tasks as part of their profile workflows, so every profile gets a consistent, auditable review. A checklist is made up of sections, and each section of tasks. Tasks can be assigned to [teams](#team). Each task has a status: * **Passed**: the task's checks were satisfied * **Failed**: the task's checks were not satisfied * **Needs review**: the task needs further review * **Exempt**: the task doesn't apply to this profile A profile can have multiple checklists assigned. **Related:** [Profile](#profile), [Case Management User](#case-management-user), [Team](#team)\ **In the API:** **Profiles › Checklists**. ## Custom Field A field an account defines to hold extra information on a profile that isn't part of the standard data, for example an internal account number or a product line. Each custom field has a label and a value. A custom field can be: * **text**: free text * **select**: one option from a list * **multi-select**: several options from a list * **date**: a date **Related:** [Profile](#profile)\ **In the API:** **Profiles › Custom Fields**. ## Document A file uploaded to a profile, such as a certificate of incorporation, a proof of address or a bank statement. Documents are usually collected during onboarding, through the [onboarding portal](#onboarding-portal) or by API. Each document belongs to a document type from the [document library](#document-library). The document type decides how the document is processed, for example whether it goes through fraud checks or translation. A profile can have multiple documents. **Related:** [Document Library](#document-library), [Profile](#profile)\ **In the API:** the **Documents** section for listing and retrieving documents, and **Profiles › Documents** for uploading them. ## Document Library The set of document types an account has configured, such as "Certificate of incorporation" or "Proof of address". Each document type has its own settings, including: * the file types accepted * size limits * workflow steps the document goes through once uploaded, for example fraud checks and translation Setting document types up once in the library means every document of that type is collected and processed consistently. When a document is uploaded, it's uploaded against a document type. **Related:** [Document](#document)\ **In the API:** the **Documents** section. ## Domain The website domain of the business a profile is for. A profile can have one domain. When a domain is added, it's analysed in the background, covering: * WHOIS records, such as when the domain was registered and by whom * social media presence * wider online presence * a scam advisor check Together these help assess whether a business's online footprint matches what it claims to be. The domain can be added when the profile is created, so the checks run as part of the initial workflow, or added later. **Related:** [Profile](#profile)\ **In the API:** **Profiles › Online Presence**, and the `domain` field when creating a profile. ## Entity The type of business or individual a profile is created for. The entity type decides which information is collected and which checks apply, for example which search fields and creation fields are needed. The entity types are: * company * sole trader * partnership * charity * government entity * incorporated syndicate * company syndicate * syndicate * association * trust * fund * club * individual * joint individual **Related:** [Profile](#profile)\ **In the API:** **Profiles › Profile Creation**, which lists the entity types and the fields each one needs. ## Form A set of questions used to collect information that isn't covered by the standard onboarding steps. Forms can contain a wide variety of inputs. A form can be: * **internal**: completed by the compliance team in [case management](#case-management) * **customer-facing**: completed by the customer in the [onboarding portal](#onboarding-portal) or the [verify portal](#verify-portal) Forms can be assigned to profiles and to representatives, and a profile can have multiple forms. Which forms appear in the onboarding portal is part of the profile's [onboarding portal configuration](#onboarding-portal-configuration). **Related:** [Onboarding Portal Configuration](#onboarding-portal-configuration), [Profile](#profile), [Representative](#representative)\ **In the API:** the **Forms** section for the forms in your account, and **Profiles › Forms** and **Representatives › Forms** for assigned forms and their answers. ## Monitoring The ongoing checks that continue after a profile has been onboarded, because trust doesn't stop at onboarding. Monitoring covers: * **business data changes**: changes to the company data held on the profile * **screenings**: ongoing screening of the entity and its [representatives](#representative), for example against sanctions and PEP lists When monitoring finds something, it raises an [alert](#alert). Monitoring can be stopped for a profile entirely, or for data changes or screenings only. Screening monitoring can also be stopped for a single representative. **Related:** [Alert](#alert), [Profile](#profile), [Representative](#representative)\ **In the API:** **Profiles › Monitoring** and **Representatives › Monitoring**. ## Onboarding Portal The hosted, branded portal where a business completes its onboarding. It's used for entities such as companies, trusts and funds, and is accessed by [onboarding portal users](#onboarding-portal-user). The portal is made up of modules, such as: * Declare representatives * Provide documents * Complete additional information * Trigger ID verifications for representatives Which steps a profile needs to complete is set by its [onboarding portal configuration](#onboarding-portal-configuration), and the portal takes on the look of the profile's [brand](#brand). Progress through each step is tracked as pending, in progress, incomplete or completed. When everything is complete, the profile is submitted for review and moves to **Needs Review**. The onboarding portal is for the business itself. Individuals verify their identity in the separate [verify portal](#verify-portal). **Related:** [Onboarding Portal User](#onboarding-portal-user), [Onboarding Portal Configuration](#onboarding-portal-configuration), [Verify Portal](#verify-portal)\ **In the API:** **Profiles › Onboarding**, which checks progress and submits a profile for review. ## Onboarding Portal Configuration The set of rules that define which onboarding steps a profile must complete in the [onboarding portal](#onboarding-portal), including which [forms](#form) are included. Configurations are created in the platform, so onboarding journeys can differ by location, business type and risk level without any code changes. A configuration is assigned to each profile automatically, and can also be changed for an individual profile by API. **Related:** [Onboarding Portal](#onboarding-portal), [Form](#form), [Profile](#profile)\ **In the API:** the **Onboarding Portal Configurations** section, **Profiles › Portal Configuration**, and the `configuration_id` field when updating a profile. ## Onboarding Portal User A person who signs in to the [onboarding portal](#onboarding-portal) to complete onboarding tasks for a business, such as a company, trust or charity. This is usually an employee or representative of the business being onboarded. Portal users are assigned to the profiles they work on, and can be sent an invitation email when they're assigned. They can sign in with a login link, or with a one-time passcode (OTP) if their link has expired. Their activity in the portal, such as sign-ins with IP address, browser and location, is recorded. Onboarding portal users are different from [representatives](#representative): portal users complete the business's onboarding, while representatives verify their own identity in the [verify portal](#verify-portal). **Related:** [Onboarding Portal](#onboarding-portal), [Representative](#representative), [Profile](#profile)\ **In the API:** the **Onboarding Portal Users** section, and **Profiles › Portal Users**. ## Profile The core "case" in Detected. A profile holds everything the platform knows about one [entity](#entity): its company data, [representatives](#representative), [documents](#document), [forms](#form), [risk analysis](#risk-analysis), screening results and the compliance decisions made about it. Think of a profile as a case to be processed, from onboarding through to ongoing [monitoring](#monitoring). Every profile has an entity type and a customer reference, and can be assigned a [brand](#brand), a [case management user](#case-management-user) and a [team](#team). Each profile has a review status: * **Processed** * **Needs Review** * **Additional Info Required** * **Approved** * **Declined** * **Archived** A profile can be created from a search of global data providers, or manually. **Related:** [Entity](#entity), [Representative](#representative), [Case Management](#case-management)\ **In the API:** the **Profiles** section and its sub-sections. ## Representative A person or entity associated with a [profile](#profile), such as a director, ultimate beneficial owner (UBO), partner, trustee, shareholder entity or director company. A representative can be a natural person or a legal entity, and a profile can have many representatives. Representatives have types that describe their role, for example director, ownership, trustee, authorised signatory or declaratory (the person who declares the information is correct when a profile is submitted). One representative can have several types. Individual representatives verify their identity in the [verify portal](#verify-portal), and are screened as part of [monitoring](#monitoring). Each representative has a review status: * **Pending** * **Needs review** * **Verified** * **Rejected** * **Fraud** * **Additional information** * **Previously verified** **Related:** [Profile](#profile), [Verification](#verification), [Verify Portal](#verify-portal)\ **In the API:** the **Representatives** section and its sub-sections. ## Risk Analysis The result of running a profile through the risk engine. The risk engine applies an account's risk rules, grouped into rule groups, and produces: * an overall **score** * a **risk level** for that score * a detailed report showing every rule, which rules triggered a score, and the related thresholds The analysis is produced by a configured workflow, and has a status of pending, completed, failed or missing data. The risk engine can run several times over the lifecycle of a profile, for example after new information arrives, so a profile can have multiple sets of analysis. **Related:** [Profile](#profile), [Monitoring](#monitoring)\ **In the API:** **Profiles › Risk Analysis**. ## Team A group of [case management users](#case-management-user). One user can belong to multiple teams. [Profiles](#profile), [alerts](#alert) and [checklist](#checklist) tasks can be assigned to a team, so work can be shared and routed, for example to a dedicated enhanced due diligence team. **Related:** [Case Management User](#case-management-user), [Profile](#profile), [Alert](#alert)\ **In the API:** the `team_id` field when updating or listing profiles. ## Verification A check carried out on a [representative](#representative) to confirm who they are. The verification types are: * **IDV (identity verification)**: the representative provides an ID document and completes biometric checks, usually in the [verify portal](#verify-portal) * **ID3**: an electronic identity (eKYC) check that looks up the representative's details against data sources * **Digital footprint**: a check of the representative's digital footprint Each verification records which provider carried it out and the provider's result. For IDV, a PDF report from the provider can be downloaded. **Related:** [Representative](#representative), [Verification Flow](#verification-flow), [Verify Portal](#verify-portal)\ **In the API:** **Representatives › Verifications**. ## Verification Flow The journey a [representative](#representative) completes in the [verify portal](#verify-portal). Which steps it includes is set by a verification configuration, which is resolved in order of precedence: 1. a configuration assigned to the representative 2. the configuration linked to their verification flow 3. global configurations matching the profile's country and the representative's types A representative starts their flow from a login link. If something needs to be redone, the flow can be reset, and the representative is emailed a fresh link. **Related:** [Verify Portal](#verify-portal), [Verification](#verification), [Representative](#representative)\ **In the API:** **Representatives › Verification Flow**. ## Verify Portal The hosted portal where an individual [representative](#representative) completes their identity verification, separately from the business's onboarding. It's made up of modules, such as: * Provide their details (address, country of birth and so on) * Provide ID documents and complete biometric checks (ID verification) * Trigger an eKYC check, a lookup of their details against sources such as credit agencies, government records and telco records * Provide information and documents, such as proof of address The steps each representative sees are set by their [verification flow](#verification-flow). **Related:** [Verification Flow](#verification-flow), [Verification](#verification), [Onboarding Portal](#onboarding-portal)\ **In the API:** **Representatives › Verification Flow**. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://detected.gitbook.io/detected-api-docs/terminology.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.