At Uber, we put safety first in order to minimize risks for users on the Uber platform. Uber Insurance Tech focuses on three pillars; claims, compliance, and affinity programs.

In case of a crash or incident we provide the required support and efficient claims handling processes to get drivers back to their everyday lives as quickly as possible through partnering with insurance carriers.  

Uber continuously makes sure that drivers are compliant with local regulatory requirements working with partner insurance carriers.

Uber offers various affinity programs such as Optional Injury Protection, Vehicle Interruption Coverage, in major markets to drivers; this way drivers are provided flexibility and further coverage through such programs. We do all these by working closely with insurance carrier partners worldwide. 

To operate in a safe and compliant way, it’s crucial for Uber to adhere to the guidance of various local regulatory requirements held by regional regulatory bodies. As part of these regulatory checks, Uber checks to ensure the validity of a driver’s insurance documents. 

Across the markets Uber operates in there are significant varying requirements. For example in London, when an insurance document is uploaded by a driver, a document operations agent is assigned to review the document and ensure that it meets the local requirements. However, at any point after policy issuance, the policy holder could make mid-term adjustments (MTAs) through the insurance carrier. There are two major MTA changes we consider:

Whenever a driver’s policy is modified or canceled in the insurance carrier’s system, we need to update the insurance document for agent review at Uber to ensure there is no gap in insurance coverage and prevent a potential compliance breach. To prevent such issues, we designed the insurance verification service to continuously track the validity of insurance coverage for drivers at Uber.

Tracking the validity of insurance documents can be challenging due to the following special characteristics of insurance documents:

In this blog post, we will share Uber’s insurance verification service process, as well as our learnings from the process of its development and implementation. 

The Uber insurance verification service is a microservice that abstracts the underlying complexities of insurance policy renewals/adjustments and tracks vehicle insurance validity continuously for drivers at Uber.  

In a vehicle insurance policy, multiple drivers and/or vehicles can be insured under the same policy. Meanwhile, in the Uber system, a dedicated driver account is created when a driver is onboarded to Uber. We work with panel insurance carriers to convert the insurance coverages from policy level to (driver, vehicle) pairs in our system, as noted in Figure 3.

Identifying and verifying the same driver and vehicle pairs from the insurance carrier system to the Uber system is nontrivial. Driver and vehicle information could be represented differently across multiple insurance carriers. Additionally, each carrier may have their own set of APIs to access their data. In an effort to standardize the insurance verification APIs across multiple carriers, we define the standard fields to identify and match driver and vehicle entities across insurance carriers and Uber. Additionally, the verification APIs define a standard strategy and lifecycle to digitally verify insurance coverage. Our Insurance Verification APIs are composed of the two communication models:

At a high level we deal with two types of insurance policy ownership schemes in the insurance marketplace:

The vehicle insurance verification service started with handling individual vehicle insurance policies. We extended the verification service to cover fleet insurance in the same framework.

The insurance verification process is composed of 4 major components: driver insurance updates, verification with panel insurance vendors, verification at Uber, and the insurance document review process. The interactions and data flow are illustrated in Figure 5.

When onboarding or nearing insurance policy expiration, a driver manually uploads an insurance document through the Uber app to show the vehicle insurance coverage. The insurance document uploaded by a driver is stored in a manual insurance document database in the Uber Document service. After the document is reviewed, a document status change event is produced.

The insurance verification service listens to the document status change events. When a manual insurance document approval event from the panel insurance vendors is received, the service verifies the insurance coverage of the (driver, vehicle) pair with the associated insurance carrier by making API calls to the insurance carrier endpoints. 

When an upsert/cancel request is received from the carrier, the insurance verification service finds the matching driver and vehicle accounts and updates the corresponding digital insurance document in our database.

When a carrier receives an insurance verification request, they look up the insurance coverage for the given driver, vehicle pair. If a valid insurance coverage is found, the carrier follows up by upserting a digital insurance document to Uber. 

Once the (driver, vehicle) pair is onboarded for digital verification, the carrier collects the follow-up policy renewals and changes related to the drivers and vehicles. Such changes are populated to Uber through the verification upsert/cancel APIs.

The digital insurance documents uploaded by the panel vendors go through a similar document review process to ensure they are insurance compliant. If the driver fails the digital insurance document check, the driver can be blocked from going online. 

In the insurance verification process, we came across a few technical challenges. Below we discuss some key challenges and our solutions to overcome them. 

For each driver account, we can receive insurance document updates from both the driver and panel vendors at the same time. This can cause document update collisions. Also, we don’t want to lose the insurance updates from the panel vendors due to insurance compliance risk.

To address these issues, we store insurance documents uploaded from drivers and insurance panel vendors in separate databases. This gives us a couple of benefits:

Given the scale and diversity of insurance carriers, carriers may obtain insurance data from different data sources (e.g., distributed broker networks, online and offline systems, etc.). The varying veracity and velocity of the carrier’s application data creates many technical challenges for their timely response to insurance verification calls, which can add turnaround time spanning from minutes to hours. These issues can impact the data availability at the insurance carriers and the success rate of insurance verification calls.

To adapt to the varying data availability across different carriers, the pull model of the insurance verification process does not ask for the insurance document synchronously. Instead, the verification call is a simple process that only verifies the existence of insurance coverage for a given driver and vehicle. When the data is ready, the carrier follows up with a digital document upsert to Uber. For failed verification calls, we put the corresponding request into a Kafka dead letter queue (DLQ) and retry the request later.

Eventually, we need to show the associated insurance coverage for each driver account at Uber. With the standard verification APIs, identifiers for the (driver, vehicle) pair are used as primary keys to match the driver and the vehicle across Uber and the insurance carrier systems. In the process, we will convert the insurance changes of the (driver, vehicle) pair to insurance coverage adjustments of the associated driver accounts.

A fleet policy is often owned by a third party (e.g., a rental company or multi-vehicle owner). Fleet policies generally provide the flexibility to cover any driver under a given policy. Hence, ensuring the insurance coverage of a fixed (driver, vehicle) pair is not required in the fleet vehicle insurance verification. Instead, we want to verify that the fleet vehicle used by a driver is properly covered. In order to track the insurance coverage at the driver account level, we build a mapping between vehicles and the associated driver’s accounts. Whenever we receive the upsert/cancellation events from the carriers, we convert them from the vehicle to the associated driver accounts.

For some fleet policy changes, e.g policy cancellation, the request can affect all related vehicles in a fleet policy. In some cases, one fleet policy change can map to thousands of actions on the underlying individual vehicle entities in the Uber system. To scale up to such large burst requests, we opt to distribute the vehicle entity level requests through Kafka and handle the requests asynchronously. We utilize Kafka’s robustness guarantees to ensure each action is processed in a timely manner. 

Due to the nature of data issues, occasionally there are policies that do not successfully pass through the API in a timely manner. To unblock such cases we offer operational support to manually verify the policies. 

Currently we have launched this verification process in London. In the future we will look to expand in the United Kingdom and beyond. As we continue to improve our compliance systems we hope to improve the onboarding process for all parties involved. 

We discussed the design and implementation of Uber’s vehicle insurance verification solution to improve the insurance compliance at Uber. Also, we shared the challenges and our solutions in the verification process. Since 2016, the service has evolved to an end-to-end insurance compliance guard for many insurance types at Uber. We will continue working with the panel vendors to improve the verification latency and accuracy as well as streamline the driver experience regarding insurance document updates. 

The Vehicle Insurance Verification project could not have been built without the cross-functional efforts of many Uber internal teams and our panel insurance carriers. Thank you to Victoria D’Amelio, Ike Yararbas, Ronak Modi, Keiko Ikenami, Umamaheshwara Sunkesula, Rafael Nascimento, Nadia Moosvi, Eoghan Costelloe, Karl Gray, Marwan Hatem, James Jeffery, Kosuke Takano, Mike Akamine, Melodie Videau, Bex Xiao, Louise Kinane, Pritesh Gokani, Neil McGonigle for your support and contributions toward building this product.