Skip to content

Technical Integration Guide for Riskwolf APIs

Introduction

Welcome to the Riskwolf Technical Integration Guide, designed to assist businesses in seamlessly integrating with our APIs for a streamlined insurance process. Riskwolf offers a range of parametric coverages to safeguard against unforeseen risks such as weather-related incidents. This guide will walk you through the high-level business integration points and the technical details to successfully leverage our APIs.

High-Level Data Exchange

The integration with Riskwolf APIs involves a seamless, four-step process for businesses to efficiently manage parametric insurance. First, businesses can validate allowed coverages by providing location and time parameters, receiving a list of available coverages. Next, a technical quote request requires the submission of coverage details, leading to the generation of a quote ID with associated rates and prices. Businesses can then accept or reject the quote, initiating policy monitoring if accepted.

The monitoring process automatically starts at the inception date of the policy. Claim data can be pulled daily claim data to identify policies that have ended and their claim status. If the policy ended and there are no claims this state will also be reported along with the tracked index.

Riskwolf's APIs provide a robust and straightforward solution for businesses to navigate insurance processes, ensuring effective risk mitigation and swift decision-making.

Example scenario:

In the scenario, a company seeks to insure against potential weather-related risks. To assess available insurance coverages, the client utilizes Riskwolf's API, providing the event's location coordinates and the specified time frame. Upon receiving a list of parametric coverages, the client decides to protect against excess daily rainfall and requests a quote, ultimately accepting the policy to initiate monitoring during the event. As the event concludes, the client uses Riskwolf's API to evaluate claims, gaining insights into the effectiveness of the coverage and informing future risk management strategies.

Step 1. Coverage Assessment and Validation

The first ensures that businesses can assess and understand the available parametric coverages based on the specific criteria, e.g. location, time, risk type etc. It allows them to make informed decisions about the types of coverage that are applicable to the given scenario, providing a foundation for the subsequent steps. For single coverages only one element is returned and can be proposed to the client.

Interaction:

  • Request: Send a given criteria.
  • Response: Receive a list of available coverages with unique IDs and parametric definitions. Show the available options to the client.
  • Default: At least one coverage. No coverage returned indicates it's not allowed to quote for the given parameters.

Example:

  • Scenario: A client wants to ensure excess rainfall in a specific location during a particular time frame.
  • Action: The client sends a request to Riskwolf providing the latitude, longitude, and time range for the event.
  • Outcome: Riskwolf responds with a list of available coverages, such as "Excess of Daily Rainfall," with unique IDs and parametric definitions.

Step 2. Quote Generation

Businesses need to generate a quote to understand the financial implications and rates associated with the selected coverage. This step allows them to quantify the potential risk and cost, aiding in decision-making processes. The unique quote ID serves as a reference for tracking and managing the quote throughout its lifecycle.

Interaction:

  • Request: Submit relevant coverage ID, Max. Payout/Sum Insured, quantity (number of days), and a technical client reference to get a quote.
  • Response: Obtain a quote ID with the technical rate in percentage and the risk price in the local currency.

Example:

  • Scenario: The client decides to cover the exposure against excess daily rainfall and requests a quote.
  • Action: The client submits a request to Riskwolf, specifying the coverage ID, max payout, quantity (number of days), and a technical client reference.
  • Outcome: Riskwolf generates a quote ID (e.g., "456") and provides the technical rate (2.5%) and risk price (2500$) in the local currency.

Step 3. Policy Confirmation

Once a quote has been generated, businesses must confirm or reject it to proceed with or cancel the policy. Accepting the quote initiates the policy monitoring process, enabling Riskwolf to actively track and manage the specified coverage. This step is crucial for transitioning from a quote to an active policy.

Accept Quote

  • Request: Accept a quote by sending the quote ID to initiate monitoring.
  • Response: Receive an acknowledgment along with the technical policy monitoring ID. Note: Policy ID is different to Quote ID.

Reject Quote

  • Request: Reject a quote by sending the quote ID.
  • Response: Receive an acknowledgment and quote is removed.

Example:

  • Scenario: The client decides to proceed and accept the quote and start monitoring the policy.
  • Action: The client sends an acceptance request to Riskwolf, including the quote ID and external policy ID.
  • Outcome: Riskwolf acknowledges the acceptance and provides the technical policy ID reference (e.g., "789") for monitoring.

Step 4. Claim Evaluation

To check on the claims, either the Riskwolf platform can send notifications on policy level or a regular data pull can query the claim status.

If daily payments are sufficient, please use the PULL option as it decreased the implementation complexity:

Pulling daily claim data helps businesses identify policies that have expired, allowing them to determine whether a claim was made and, if so, the associated claim amount. This step provides valuable insights into the real-world performance of the coverage and informs future risk management strategies.

Option 1: Daily PULL for Claims Data

Workflow:

  1. Scheduling: The client system periodically sends a scheduled request on a daily basis, typically during non-peak hours (e.g., 8 pm), to pull the latest claims data.
  2. Data Retrieval: The request includes a parameter specifying the date or time range for which claim data is needed. Riskwolf responds with information about policies that have ended during the specified period, indicating whether a claim was made and the associated claim amount.
  3. Processing: The client System processes the retrieved data, updating its records, and takes necessary actions based on the claim information.

Pros:

  • Control: The client System has control over when to retrieve claim data.
  • Predictability: The system can plan and schedule the data retrieval process.

Cons:

  • Latency: Claims data is not immediately available, and there may be a delay based on the chosen retrieval frequency.

Option 2: Real-time Notification for Policy ID

Workflow:

  1. Event-Based Notification: Riskwolf's system sends real-time notifications to The client System whenever a policy monitored by a specific Policy ID ends, indicating whether a claim was made and the associated claim amount.
  2. Subscriber Mechanism: The client System subscribes to Riskwolf's notification service, providing callback endpoints to receive real-time updates.
  3. Immediate Processing: Upon receiving a notification, The client System processes the information promptly, updating its records, and takes necessary actions based on the claim details.

Pros:

  • Real-time Updates: The client System receives immediate notifications, enabling quick response to claim events.
  • Reduced Latency: Claims data is available as soon as the policy ends.

Cons:

  • Implementation Complexity: Setting up and maintaining a real-time notification mechanism can be more complex than scheduling daily pulls.
  • Potential Overhead: Continuous real-time updates may lead to higher resource usage.

The choice between these options depends on the specific requirements, system architecture, and preferences of The client System. The daily PULL option provides control and predictability, while the real-time notification option offers immediacy and responsiveness.

Example:

  • Scenario: The event concludes, and the exposed client wants to assess if any claims need to be processed.
  • Action: The client queries Riskwolf, specifying the time (e.g., 8 pm).
  • Outcome: Riskwolf returns information on policies that have ended, indicating whether a claim was made and the associated claim amount.

Technical API Specifications

Authentication

All API requests must include proper authentication credentials. Please refer to our authentication documentation for details on obtaining and using API keys.

Error Handling

Our APIs follow RESTful principles for error handling. Detailed error messages will be provided in case of any issues.

LINK TO API SWAGGER SPECS

Conclusion

This Integration Guide provides a comprehensive understanding of the business and technical aspects of integrating with Riskwolf APIs. For any further assistance, please refer to our API documentation or contact our support team. We look forward to a successful collaboration in securing your business against unforeseen risks.

For further help please contact the Riskwolf support - support@riskwolf.com