Welcome to Pingwire — a risk and compliance platform designed to help financial institutions and regulated businesses manage onboarding, monitoring, fraud prevention, and compliance workflows.

This guide provides a quick overview of the platform’s core concepts and practical steps to get started. Whether you’re a developer integrating Pingwire into your systems or a user configuring rules and workflows, this guide will help you get familiar with the essentials.

1. Understanding the Pingwire Platform

Pingwire is built around five core principles:

• Entities: They are the foundation of the system as they are the subject of investigation or monitoring. An entity represents an individual, business, account, or product (asset) that your rules and workflows are applied to. Every request, rule, ping (alert), or case is ultimately tied to one or more entities.
• Requests: A request is submitted to Pingwire by the client (via API or manually in the interface), containing data about involved entities and the inquiry that the rule engine are to evaluate against. A request can be of type 'Transaction', 'Individual KYC' or 'Business KYC'.
• Flexible rule engine: Define rules and workflows that trigger actions, checks, or alerts based on data.
• Pings: A Ping is a system-generated alert that is created when the conditions of a configured rule are met. It aims to indicate suspicious activity detected by Pingwire’s rule engine.
• Cases: A Case is the central hub for managing investigations. It allows users to efficiently investigate, document, and report suspicious activities by consolidating related requests, pings, and entities into a single, organized interface.

2. Key Concepts

Rules
Rules are automated checks in Pingwire that help manage compliance, risk, and fraud detection. They let you define conditions that trigger actions, such as reviewing a case, blocking a transaction, or creating a ping for suspicious activity. Rules can be either request-based (triggered by KYC submissions, transactions, etc.) or ongoing (continuous monitoring of entities). 

Multiple rules can be combined to form scenarios, allowing you to detect and respond to more complex or evolving patterns of suspicious behavior. This scenario-based approach makes it possible to mirror how compliance and AML teams think about real-world risks, by connecting related events into a broader detection logic.

This flexible setup allows users to tailor actions, scoring, and monitoring to meet regulatory requirements and operational needs.

Example: "Flag transactions above €10,000", "Flag transactions above €15,000 if individual is under 20 year old" or "Trigger enhanced due diligence when transaction to/from high-risk countries".

Processes
A process defines which rules should be applied to an incoming request and how it should be handled. It acts as a logic container and routes the request through the appropriate decision flow. A process is set up to handle one type of request, which will then be allowed within the process.

Example: Name: "Transaction Monitoring", Request Type: "Transaction", or
Name: "Individual KYC", Request Type: "Individual KYC"

Transaction type
Transaction Type is a category used to classify different types of financial activity, such as regions, payment methods, or verticals. It helps you segment transactions and apply different rules based on context.

Example: "Card Payment", "Bank-Giro Transfer" and "Swish Payment", or 
"Platform X", "Platform Y" and "Platform Z", or
"Region 1", "Region 2" and "Region 3"

Groups
Groups are a way to categorize entities based on predefined criteria. This facilitates risk management as well as rule application. They help segment entities and ensure that compliance rules are applied efficiently.

Example: Group Name: "High-Risk Jurisdictions", Baseline Score: "80"

Tags
Tags are simple labels that help the user structure and organize in the interface, and it can be applied to both pings (alerts) and cases. They can be assigned automatically to a ping when a rule is triggered, or manually by the user. If a ping receives a tag, the case it belongs to will also inherit the same tag, ensuring consistent labeling. By configuring tag colors, users can instantly recognize what a ping or case relates to and maintain clearer organization.

Example: Name: "Individual on sanction list", Tag:  

Risk Class
Risk classes are partitions of the full probability range (0–100) into self-defined intervals. Each interval represents the likelihood of an entity committing a financial crime. The intervals must be contiguous and cover the entire range without gaps or overlaps. 

Note that intervals must be defined so that every possible probability (including decimals) is assigned to a risk class, and when a value falls on a boundary (e.g., 25 in the ranges 0–25 and 25–50), it is assigned to the higher class.

Example: Risk class name: "Low", Interval score: min=0, max=20, 
Risk class name: "Medium", Interval score: min=20, max=60
Risk class name: "High", Interval score: min=60, max=90
Risk class name: "Unacceptable", Interval score: min=90, max=100

Signals
A Signal is a client defined identifier that can be returned as part of a request response when a specific rule is triggered. Unlike standard recommendations such as Block, Review, or Proceed, signals can provide additional context about detected conditions, or trigger follow-up actions in Pingwire or the clients own system.

Example: A request may receive recommendation "Review" along with a signal to
 "Trigger_Enhanced_Due_Diligence"

3. Getting Started as a User

In your development account:

1. Log in to the Pingwire platform.
2. Set up a Process:
   1. Create a new Process and name it accordingly, and select the request type ("Transaction", "Individual KYC", or "Business KYC").
   2. Once created, the ProcessID is available in interface. This is needed for the developers to be able to send in requests.
3. Create rules:
   1. Set up one or a few test rules, such as the rule "Amount threshold" and name it something like "Test rule ...".
   2. Configure it to run on the process you just created.
   3. Ensure you set Initiator or Recipient as "Entities to check". Don't worry about Group filtering or Group assignment for now.
   4. Select the rules recommendation as either "Proceed", "Review" or "Block". This is the recommendation the system will give on a request when triggered.
   5. Select "Rule Score" and "Rule decreasing timeline", these can be set to "0" and "1 year" to start with
   6. Save rule
   7. Important - Once saved the rule will show in the rule tree, however, you also have to publish the rule for it to be live. Once you do, you can decide if the rule tree are to be published as a test version or not. Select "no" since we are in the development environment. 
4. Explore and Create Entities, Groups and Tags – Create individuals, businesses, or accounts. Assign groups and create tags - Just click around to familiarize yourself with the interface.
5. Explore the Case view (Once developers have sent in requests that triggers pings and cases)

• Optional - You can also create request manually in the interface to test rules and explore pings and cases. Here's how you manually create a transaction request in the interface:
  • Press 'Create' in the top right corner of the Request list 
  • Select a Request type 'Transaction'  
  • Fill in at least 'Amount', 'Date' and 'Currency'
  • Add a 'Initiator' and/or a 'Recipient' 
  • Select the Process you created above
  • Press 'Send'
  • The request is now sent and can be seen in the request list, and a ping and case is created which can be found the respective list (ping list and case list)

4. Getting Started as a Developer

Do the following steps for your development environment

1. Access the API – Pingwire provides a REST API for integration. Authentication is via API keys that can be fetched from the interface. All requests and responses use JSON.
   • API keys are generated under 'API Keys' in left hand menu. Press 'Create' -> Select one or several 'Permission Roles' ('ReadWrite', 'ReadOnly' or 'Manager') -> Press 'Save' -> 'Client ID' and 'Client Secret' is now shown in the interface.
   • The login endpoint returns both an authentication token and a refresh token. The authentication token is valid for 15 minutes and can be refreshed for 10 hours using the refresh token. Once both the refresh token and the authentication tokens have expired, the login endpoint should be used to retrieve new tokens.
2. Set up a Process (if not already done by a user):
   1. Create a new Process (either via API or in manually the interface) name it accordingly, and select the request type ("Transaction", "Individual KYC", or "Business KYC").
   2. Once created, you will receive a ProcessID (or manually fetch in interface if created manually)
   3. When submitting requests to Pingwire, include this ProcessID. That tells the system which rules to run on the request.
3. Set up rules in the interface (if not already done by a user):
   1. Set up one or a few test rules, such as the rule "Always trigger" or "Amount threshold" and name it something like "Test rule ...".
   2. Configure it to run on the process you just created.
   3. Ensure you set Initiator and Recipient as "Entities to check". Don't worry about Group filtering or Group assignment for now.
   4. Select the rules recommendation as either "Proceed", "Review" or "Block". This is the recommendation the system will give on a request when triggered.
   5. Select "Rule Score" and "Rule decreasing timeline", these can be set to "0" and "1 year" to start with
   6. Save rule

   7. Important - Once saved the rule will show in the rule tree, however, you also have to publish the rule for it to be live. Once you do you can decide if the rule tree are to be published as a test version or not. Select "no" since we are in the development environment. 

      *Rules can can also setup through api, although it is a little more intuitive to do through interface. See API documentation for more information - https://docs.pingwire.io/#tag/Rules

4. Send in your first request(s) according to 'Create Request' in the API documentation
5. Handle response 
    

5. Best Practices for a Smooth Start

• Environments: Start testing in your Development environment, before moving to Sandbox and Production
• Start small: Begin with a limited set of rules and expand gradually.
• Leverage tags: Organize rules and entities with consistent tagging.
• Collaborate: Developers integrate the data flow, while compliance teams refine the rules.
• Monitor and adjust: Review pings and cases regularly and fine-tune rules based on outcomes.
   

6. Additional Resources

• Help Center: Explore the categories 'Help Guide' and 'FAQs' for further in-depth guidens
• API Documentation - Full reference for developers - 'API Docs'
• Support: Contact Pingwire’s support team for implementation assistance.