InsureTech: Insurance Compliance

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.

Claims

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.

Compliance

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

Affinity Programs

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.

Figure 1: Pillars of InsureTech @ Uber

This blog post will be the first of a series of blogs regarding InsureTech at Uber covering the challenges and solutions to cover the compliance aspects.

Auto Insurance Compliance

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:

Update MTAs: changes made to update an existing policy (e.g., adding/removing a driver, adding/removing a vehicle, coverage date adjustment, etc.)
Cancellation MTA: a special change that terminates the policy

Figure 2: Insurance coverage tracking

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:

A variety of MTAs can be made prior to the policy end period
A driver covered under an insurance document might be named insured but not the policyholder; this increases the complexity to track the insurance coverage at the named insured driver level
Insurance documents expire on a regular basis and the term of the policy can range from weekly, monthly, to annually
Different types of insurance coverages and coverage limits can be specified in an insurance document

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.

Insurance Verification Service

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.

Bridging the Data Model Gap

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.

Figure 3: Insurance policy to vehicle insurance coverage

Standard Insurance Verification APIs

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:

Push model: The insurance carrier pushes digital insurance documents and follow-up MTA changes to Uber via upsert and cancellation requests
Pull model: Whenever a driver uploads their manual insurance document, to confirm the validity, Uber sends a policy verification request of the insurance coverage for a (driver, vehicle) pair to the associated insurance carrier. After a successful verification, the associated insurance carrier then provides a digital copy of the document to Uber asynchronously through the push model APIs.

Figure 4: Push and Pull Data Flows

Multiple Insurance Types

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

Individual: An insurance policy that specifies the coverage for a single vehicle and named drivers
Fleet: A fleet policy covers a number of vehicles which are often owned by a company and allow flexible combinations between qualified drivers and vehicles in the fleet

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.

Overall Verification Process

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.

Figure 5: Verification Service Architecture

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.

Verification Service (Steps 4-5)

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.

Verification with Panel Insurance Vendors (Steps 6-8)

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.

Digital Compliance and Go-Online Check (Steps 9-10)

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.

Technical Challenges and Solutions

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:

It separates the insurance document updates from different parties
It allows us to use digital insurance documents as a compliance signal for the driver go-online process

Data Availability Across Insurance Carriers

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.

Robust Insurance Coverage Matching

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.

Scale to Support Bulk Policy Cancellations

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.

Addressing Long Tails

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.

What’s Next?

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.

On the carrier side, we are continuing to build toward an environment where an insurance company can simply integrate themselves with our APIs and provide verification through our system.
On the driver side, we are striving to simplify the driver onboarding experience for insurance certification, such as enabling drivers to choose the insurance carrier that they use instead of manually uploading the insurance certificates.

Conclusion:

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.

Acknowledgements:

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.

Header Image Attribution: The “Auto insurance policy with small yellow car” image is licensed under CC BY-ND 2.0 and credited to QuoteInspector.com