Abstract
1. Core Concepts (in alphabetical order)
| Term | Definition |
|---|---|
| API Endpoint | A specific URL in the API that allows access to a certain function or dataset, e.g., `/transactions` to submit transaction data. |
| Accounts | A type of entity representing financial or user accounts associated with individuals or businesses. Typically used in monitoring activity or linking transactions. |
| Audit Tracks | Logs or records of user and system actions for traceability and compliance auditing. Tracks changes, access, and rule executions. |
| Businesses | A type of entity representing organizations or companies under AML monitoring. May include registration data, risk profile, and associated transactions. |
| Case | A workspace that groups related entities, requests, and pings to facilitate investigation and reporting of suspicious activity. |
| Case Deadline | The time limit assigned to an investigation case. The case deadline is inherit from included pings, and always inherit the earliest (shortest) deadline if several pings are included in a case. |
| Case Status | Shows the progress of a Case, with statuses "pending", "open", "in progress" or "closed", used for managing case investigations. |
| CDD (Customer Due Diligence) | The process of collecting and verifying customer information to assess their risk profile, including identity verification and continuous monitoring. |
| EDD (Enhanced Due Diligence) | A more in-depth version of CDD applied to high-risk customers, involving more extensive data collection and analysis. |
| Entity | A subject under investigation. Can be an individual, business, car, account, or product. Entities are central to AML evaluations. |
| Groups | Custom-defined categories used to group entities based on business logic, usage type, or inherent risk levels. Also used in rule targeting. |
| Individuals | A type of entity representing natural persons under investigation or risk monitoring. May be linked to KYC, CDD, Request, Cases or Pings. |
| KYC (Know Your Customer) | A subset of CDD focused on verifying the customer's identity and understanding their financial behavior, essential in preventing financial crimes. |
| Members | Users with access to the Pingwire platform, typically part of the compliance, risk, or engineering team. Member roles define permission levels. |
| Ping | An alert generated when a rule or scenario is triggered in the system, containing details about the suspicious activity and used as a basis for further investigation. For example specific transaction patterns or threshold breaches. |
| Ping Deadline | A time limit assigned to a ping for review or handling. A ping deadline is automatically calculated based on a configured deadline offset in the rule that triggered the ping. The deadline is derived from the ping’s creation date and time and reflects the intended timeframe for investigating or resolving the identified risk indicator. |
| Ping Status | Indicates the current state of an Ping, either "pending", "confirmed", "resolved" or "ignored", aiding in tracking and workflow. |
| Population Register | A data source that allows population-level registry data to be imported or queried for individuals. |
| Process | Defines which set of rules should be applied to an incoming request and how the request should be handled. It acts as a container for logic that determines what actions to take based on the data received. |
| Products | Items or services offered or involved in a transaction. Products can be associated with higher or lower risk and may be monitored individually. |
| Reports | Lists that can be pulled directly from the interface, providing an overview of data such as Pings, Requests, Cases, or Entities. Useful for reviewing activity, investigating cases, or exporting data for further analysis |
| Request | Data input or event that enters the system for evaluation. Each request is routed through a defined Process, where it is checked against defined rules to determine whether it should trigger actions such as generating a Ping or updating a Case |
| Risk Class | A classification system (e.g., Low, Medium, High) based on risk score ranges. Used to apply different decision logic to entities. |
| Risk Score | A dynamic metric (0–100%) representing the estimated likelihood of an entity being involved in financial crime. |
| Rule | Logic conditions (defined by you or system defaults) that are executed against a request. If conditions are met, a Ping can be generated (optional). |
| Rule Engine | System component that allows users to define and manage rules for detecting suspicious behavior, as well as configure CDD processes. The engine is fully customizable to fit different business needs, enabling tailored risk assessments and automation of compliance workflows |
| Scenario | A predefined set of rules and conditions used to detect specific types of suspicious activity, helping structure and streamline monitoring. |
| Signal | Custom identifiers that can be returned as part of a response when specific rules are triggered. Unlike standard recommendations such as "Block" or "Review," signals provide additional context or actions for the user. They act as flags for specific detected conditions and can trigger follow-up actions within the client's own system. |
| Tags | Labels that can be applied to Pings or Cases to support categorization, filtering, and reporting |
| Transaction Monitoring | The real-time process of reviewing financial transactions to identify and flag unusual or suspicious activity. |
| Transaction Types | Categories used to classify different types of financial activity, such as regional transactions, payment methods, or verticals. Useful for rule-building and segmentation of transactions. |
| Webhook | A method for receiving real-time notifications from the system when specific events occur, such as ping generation, enabling automated responses. |
2. Operational Flow Concepts
Term | Definition |
| Override Recommendation | Temporarily replaces the default recommendation logic for future matching pings (e.g. during investigation). |
| Recommendation | The outcome of a request evaluation, based on rules: proceed, review, or block. |
| Risk Timeline | Defines how a ping’s score contribution fades over time. Modeled with period (e.g., days, months) and amount. |
| Score Contribution | Each ping may contribute a numeric value to an entity’s overall risk score, which decays over time unless confirmed. |
3. Data & Manual Input
| Term | Definition |
| Connected Entities | Entities (e.g., owners or controllers) linked to an account or transaction, often used to map real-world relationships. |
| Connections | Explicit relationships between two entities. These can be financial, familial, organizational, or transactional in nature. |
| Manual Insert | APIs that allow manual population of data such as board members, beneficial owners, or population registers if automatic sources aren’t available. |
4. Forms & End User Interaction
| Term | Definition |
| Form | A configurable interface used to collect additional information from end users. |
| Form Answer | The submitted payload from a completed form, retrievable via the API for further review or rule evaluation. |
| Form Link | A unique URL generated per formId + entityId combo. Shared with users for submission. |
| Redirect Flow | A form usage mode that returns the user to your app with a formAnswerId and status (SUCCESS, CANCELLED, ERROR). Useful for integrated user journeys. |
| Standalone Mode | A form usage mode where the user is redirected to a generic "Thank You" page upon submission, with no backend redirect. |
5. Technical Features
| Term | Definition |
| API Request Types | Categories of requests you can send to Pingwire: transaction, individualKyc, businessKyc, carKyc, carPurchase. |
| Bearer Token | Authentication credential retrieved via clientId and clientSecret from /auth/login. Required for most API calls. |
| CustomId | A user-defined external identifier. Useful for synchronizing Pingwire entities with your own systems. |
6. Testing & Validation
| Term | Definition |
| Test Entities | Hardcoded individuals, businesses, or cars in the staging environment (e.g., SSN 201912072392) that always trigger pings for testing purposes. |
| Test Rules | Predefined rules like Test Block or Test Review that always trigger for certain test entities. |