When a rider takes a trip, Uber collects money primarily through the rider’s preferred payment method linked to their Uber account, with the fare collected upon trip completion. In some markets, cash payments are also an option, with riders paying the driver in cash at the end of the trip. 

A chargeback is a dispute filed by a rider through their bank or credit card issuer. Chargebacks typically arise due to suspected fraud or service-related issues. Most service-related disputes are further categorized as poor service or unrecognized charges. In the chargeback process, the bank refunds the customer by deducting the disputed amount from the merchant. For companies like Uber, handling chargebacks is time-consuming and also involves a high level of operational resources to investigate, respond, and resolve disputes. Managing chargebacks effectively is essential for maintaining customer trust and minimizing financial losses. This blog describes how early chargeback signals are different compared to chargebacks, and how Uber leverages them to mitigate payment fraud. 

One type of chargeback signal is a fraud notification. Payment service providers can send a notification of fraud or inquiry to the merchant in the dispute files. 

TC40 and SAFE are reports that contain chargeback and additional signals. These reports include fraud alerts for chargebacks that aren’t passed on to the merchant. For example, they contain transactions where 3D Secure (3DS) or other liability shifts happened. 3DS is an authentication protocol designed to reduce fraud and add an extra layer of security for online card transactions. Typically merchants receive TC40 and SAFE reports earlier than chargebacks. 

When a customer makes a fraud claim, their card-issuing bank generates a TC40 data claim. This TC40 file serves as a fraud notification and includes transaction details related to the claim. Once generated, the TC40 claim is sent to multiple parties involved in the transaction process, including:

This process allows each party to monitor for potential fraud activity across their networks, helping to protect against repeated incidents. The TC40 claim serves as a critical part of the fraud detection and prevention process within the payments industry.

These  alerts are basically early fraud notifications sent by card networks. These signals alone can’t be used to prevent chargebacks but can be used to improve ‌fraud prevention strategies. 

TC40 signals are a helpful indicator of fraudulent patterns and can identify fraud earlier than systems that receive chargebacks. For Uber, TC40 signals help in identifying potential fraud patterns before chargebacks occur, creating different fraud-related signals, and training our fraud detection models.

To strengthen our fraud prevention strategy, we leverage TC40 signals from multiple sources and when appropriate, prompt riders to take required actions like throwing a penny drop verification challenge.

Figure 2 shows how we ingest, process, store, and use TC40 data to evaluate risk and initiate rider actions.

We receive early chargeback signals from external vendors via SFTP, third-party APIs, or webhooks, which our external integration system processes. After validation and conversion into a common format, the signals are published to an Apache Kafka^® topic and simultaneously stored in an Apache Hive^™ table (2.1) for offline storage. Our streaming pipeline service listens to the Kafka topic, calls the settlement system to map external signals to internal transactions, and identifies the associated user. Using our decision support system, these signals are transformed into meaningful near real-time features. We then invoke our risk evaluation and decisioning system to run machine learning models and determine appropriate actions. 

In parallel, signals are stored into Kafka topics for consumption by other systems and archived in Hive tables for batch processing (4.1). The risk evaluation system retrieves both near-real-time and offline features and passes them to the rule engine, where a final action is decided. If the number of signals and the associated transaction amount exceed a set threshold, the system may trigger a penny authorization challenge, with the decision forwarded to the actioning system. Finally, the risk actioning system collaborates with the user actioning system to take the necessary action on the user’s profile.

Many times we receive duplicate signals from the payment service provider end within a short period of time, as they also receive these signals from upstreams. It’s crucial to avoid processing these duplicates, as doing so can lead to false signal calculations and negative user experiences. Our objective is to consume these signals and then map it to internal users, verifying the associated amounts for each signal over a time frame from 24 hours to 180 days. This mapping helps identify patterns and anomalies that could be critical to our operations.

To efficiently manage this, we use Redis Cache^™, to store previously computed external references. Redis allows us to cache records with a Time-to-Live (TTL), ensuring that each entry expires after a specified duration. When processing new signals, we check the Redis cache to see if the record already exists. If a record is found in the cache, it’s ignored to prevent duplication and redundant processing.

By managing records this way, we optimize performance, reduce unnecessary processing, and provide a smoother experience for riders, as duplicates are effectively filtered out before impacting the system.

By throwing in various risk challenges like penny drop verification, we help prevent bad actors from conducting payment fraud. Penny drop verification was introduced in the Uber app to identify the ownership of the payment profile used. In this challenge, a rider is asked to confirm to Uber two small, random authorization hold amounts before they expire within a given timeframe. Successful completion indicates that a rider is likely the legit cardholder and not a fraudster. To learn more about risk challenges, refer to this blog.

TC40 signals play a crucial role in helping Uber mitigate fraud and reduce chargeback risks. Since the launch of this project, we’ve processed more than 2 million additional signals, improving our fraud actioning and model performance. On average we receive TC40 signals 4-5 days earlier compared to chargeback signals. By receiving early alerts about fraudulent transactions and disputed charges, Uber can identify patterns of fraud, take proactive measures, and strengthen their fraud prevention strategies earlier compared to chargeback signals.

In general, by leveraging TC40 reports, merchants can:

While TC40 data alone doesn’t prevent chargebacks, it serves as a valuable tool for Uber to manage risk management strategies and take appropriate action to minimize fraudulent activities.

Stay up to date with the latest from Uber Engineering—follow us on LinkedIn for our newest blog posts and insights.