When customers book an Uber ride, payment collection primarily happens through the rider's preffered payment method associated with their Uber account, with fares collected at trip completion. Some markets also offer cash payment options, allowing riders to pay drivers directly at the conclusion of their journey.
A chargeback occurs when a rider files a dispute through their financial institution, such as their bank or credit card issuer. These disputes typically stem from potential fraud concerns or service-related issues. The latter often falls into categories like unsatisfactory service or unrecognized transactions. During the chargeback process, the financial institution reimburses the customer by withdrawing the disputed amount from the merchant's account. For businesses like Uber, managing chargebacks requires significant time and operational resources to properly investigate, respond to, and resolve these disputes. Effective chargeback management plays a crucial role in preserving customer trust and reducing financial impact.
This article explores how early chargebacks signals differ from actual chargebacks, and examines Uber's approach to leveraging these signals for payment fraud prevention.
Types of Chargeback signals
Fraud notifications represent one category of chargeback signals. Payment service providers may include fraud notifications or inquiries within dispute files sent to merchants.
TC40 and SAFE reports contain both chargeback information and additional signals. These reports include fraud alerts for transactions that aren't necessarily forwarded to the merchant, such as transactions where 3D secure (3DS) or other liability shifts occurred. 3DS functions as an authentication protocol designed to enhance security for online card transactions while recucing fraud. Merchants typically receive TC40 and SAFE reports earlier than actual chargebacks.
When customers submit fraud claims, their card-issuing bank generates a TC40 data claim. This TC40 file acts as a fraud notification and contains transaction details pertinent to the claim. Once created, the TC40 claim is distributed to various parties involved in the transaction process, including
- The acquirer: The financial institution processing the merchant's card payment, responsible for managing the merchant's account and handling fund transfers.
- Other issuing bank: TC40 data claims are shared with other financial institutions that might face similar risks, enabling them to monitor for comparable fraud patterns.
- Credit card networks: Major credit card providers receive these claims and distribute TC40 data across their ecosystem to assist with fraud risk identification and mitigation.
This distribution system allows each participant to monitor potential fraudulent activity throughout their networks, strengthening protection against recurring incidents. TC40 claims form an essential component in the payments industry's fraud detection and prevention framework.
How Uber Utilizes Early Chargeback Signals
These alerts essentially function as early fraud notifications transmitted by card networks. While these signals alone cannot prevent chargebacks, they significantly enhance fraud prevention strategies.
TC40 signals serve as valuable indicators of fraudulent patterns and can identify fraud earlier than systems relying solely on chargeback data. For Uber, TC40 signals assist in recognizing potential fraud patterns before chargebacks materialize, creating diverse fraud-related signals, and training fraud detection models.
To reinforce their fraud prevention approach, Uber incorporates TC40 signals from multiple sources and, when appropriate, prompts riders to complete neccessary actions like penny drop verification challenges.
Engineering Architecture
The diagram below illustrates how Uber ingests, processes, stores, and utilizes TC40 data to evaluate risk and initiate appropriate rider actions.
Uber receives early chargeback signals from external vendors through various channels including SFTP, third-party APIs, and webhooks, which their external integration system handles. Following validation and conversion to a standardized format, these signals are publishes to an Apache Kafka topic while simultaneously stored in an Apache Hive table for offline storage. The streaming pipeline service monitors the Kafka topic, communicates with the settlement system to connect external signals with internal transactions, and identifies the associated users.
using sophisticated decision report system, these signals transform into meaningful real-time features. The system then engages the risk evaluation and decisioning system to execute machine learning models and determine appropriate responses.
Concurrently, signals flow into Kafka topics for consumption by other systems and are archived in Hive tables for batch processing. The risk evaluation system gathers both real-time and offline features, passing them to the rule engine where final actions are determined. If signal quantity and associated transactions amounts exceed predetermined threshold, the system may initiate penny authorization challenge, with the decision forwarded to the actioning system. Finally, the risk actioning system collaborates with the user actioning system to implement necessary measures on the user's profile.
Duplicate Handling Methodology
Uber frequently receives duplicate signals from payment service providers within short timeframes,as these providers also receive signals fro upstream sources. Preventing processing of these duplicates is essential, as doing otherwise could result in incorrect signal calculations and negative customer experiences. The objective involves consuming these signals and mapping them to internal users, verifying associated amounts for each signal across timeframes ranging from 24 hours to 180 days. This mapping helps identify crucial patterns and anomalies.
For efficient management, Uber employs Redis Cache to store previously computed external references. Redus enables caching records with Time-To-Live (TTL) parameter, ensuring each entry expires after a specified duration. When processing new signals, the system checks the Redis cache for existing records. If a record already exists in the cache, the system ignores it to prevent duplication and unnecessary processing.
This record management approach optimizes performance, reduces redundant proessing, and creates a smoother experience by effectively filtering duplicates before they impact the system.
Actioning Process
Uber implements various risk challenges, including penny drop verification, to prevent fraudulent payment activities. Penny drop verification within the Uber app helps establish ownership of the payment method being used. During this verification, riders must confirm two small, randomly generated authorization hold amounts before they expire within a specified timeframe. Successful completion suggests that the rider is likely the legitimate cardholder rather than someone attempting fraud. For additional information about risk challenges, readers can Uber's engineering blog posts.
Conclusion
TC40 signals play a vital role in Uber's strategy to mitigate fraud and reduce chargeback risks. Since implementing this system, Uber has processed over 2 million additional signals, enhancing both fraud actioning capabilities and model performance. On averafe, Uber receives TC40 signals 4-5 days earlier compared to chargeback notifications. By receiving advance alerts about fraudulent transactions and disputed charges, Uber can identify fraud patterns, implement proactive measures, and strengthen their fraud prevention framework earlier than would be possible with chargeback signals alone.
Generally, by leveraging TC40 reports, merchants can:
- Detect and block suspicious transactions earlier in the process
- Enhance fraud prevention measures through data-drive insights
- Decrease chargeback losses and associated processing fees
- Strenghten customer trust and payment security
While TC40 data alone cannot prevent all chargebacks, it serves as an invaluable resource for Uber's risk management strategies and enables appropriate actions to minimize fraudulent activities across their platform.
