Episode 4: How Rapido Balances Driver Supply with Fighting Fraud

This episode features a candid conversation between André Ferraz, Incognia’s CEO, and Rizwan Shaikh, VP of Customer Service Delivery at Rapido — one the biggest mobility platforms in India.

They unpack one of the big challenges of the gig economy: maintaining a healthy driver supply while also keeping risky drivers off the platform.

Discussion topics include:

• Rapido’s innovative SaaS-style model for drivers (no per-ride fees)
• When to warn a driver vs. when to ban — and giving banned drivers a chance to reactivate themselves
• The importance of VOC — from both riders and drivers
• Scaling to 40%+ automated onboarding with zero human touch

Show notes:

• Connect with Rizwan: https://www.linkedin.com/in/rizshaikh01/  
• Connect with André: https://www.linkedin.com/in/andreferraz/  

About Fraud On The Go Podcast

Fraud On The Go is the podcast for fraud fighters on the frontlines of the gig economy. Through candid conversations with experts, we explore how delivery, ride sharing, and marketplace platforms are fighting fraud and risk at scale, and what it takes to stay ahead.

Episode Transcript

André: I'm André Ferraz. This is Fraud On The Go. And today we're going to interview Rizwan from Rapido, a ride-sharing gig economy platform. We're going to talk about the challenges around balancing supply and also the integrity of the platform. Rizwan, thanks for joining us. It's a pleasure to have you here.

And I'd like to start by asking you a very broad question, which is: how do you balance the supply constraints and the integrity of your platform? Banning users, defining what good or bad is in terms of people abusing your policies.

Rizwan: Once the identification has been done—you know that this captain has been involved in activities of defrauding the system, getting onto my platform, or defrauding customers—then it’s an easy decision to make when it involves customers or integrity where the customer is at threat.

For example, a jockey captain—if we identify that the person on the ride is not the person that we had onboarded as a captain—these instances are non-negotiable because they cause a threat to customer security. So what we do in that case is we definitely ban the captains.

We ban the captains. However, at the same time, because there is technology involved, the accuracy of the technology might not necessarily be 95% or 100%. So what we do is give them an opportunity to come to our city offices, validate themselves there, and then reactivate on the platform.

However, in cases of asking for extra money or collusion with the customer—wherein we identify that this captain might have been the customer himself in this particular ride, which we identify through our rule-based checks. And we take a softer view in these cases. We let the captain know that, “we think this ride has been initiated by you, and we are not going to pay you for it. You’re not supposed to do that on the platform.”

Now, at scale, this becomes a huge problem. On an average day, we have about seven to eight lakh captains, which is 0.7 to 0.8 million captains on the platform every day.

Now, if your OCR or verification returns tell me that you have 2%, 3%, 5%, or 10% of those seven to eight lakh people are not who they're supposed to be, it becomes a very challenging decision for the marketplace teams to take. And over there, the decider is very simple: is it a threat to the customer? Would it compromise the security of the customer? If that is the case, we ban him from the platform, allowing him a chance to dispute my decision. But if it is collusion or asking for extra money, we try to give that money back to the customer and warn the captain for it, without entirely banning him.

André: Let me pause you for a second here because I wanted to expand a little bit more on the first part, which is: how do you define, and what signals and data do you use to define, that this person is not really who they claim to be? What exactly do you look into?

Rizwan: See, our onboarding processes are pretty robust. The verification of the documents is done through government portals where we verify the Aadhaar card, the driving license, and the RC registration copy of the vehicle. After this is validated, we additionally take personal identification details, and for taxation purposes, we collect their PAN card.

Now, even after this, what happens is that you have mule accounts in the market. India has a fairly big gig economy, and captains are used to multi-apping—wherein people have access to different platforms. What happens is that if somebody gets banned on one platform, we have a fairly large migrant population which forms part of our supply funnel.

Now, people in the migrant funnel tend to leave during various festival seasons or different weather conditions, going back to their hometowns. When they do this, they leave the devices and their identities on the platform behind, which other people might use.

Now, this becomes extremely risky because we have verified a person with his documents. If somebody else is using that account, the only way to verify it is that during the ride, we ask him to click a photograph of himself. We also ask customers for indicators. We provide the customer micro-feedback chips, asking if the rider is the same person they see on the app, and whether the vehicle number matches or not.

When the customer gives this feedback—say, if they indicate a vehicle mismatch or a driver mismatch—we immediately trigger a verification process. An online verification process requires the captain to click a photo of himself while being on the ride and online, to prove he’s the same person. If that fails, we immediately ban the captain from the platform.

André: And one follow-up question to that: when you see this kind of behavior—an existing account that was already validated, and then someone else is using it—what is the typical behavior? Are these accounts being rented? Is the original owner of that account renting it and making money by having other people use it? Are they just giving it away? Are these accounts being shared with friends and family, for example? What is the typical situation there?

Rizwan: What happens with the migrant population is that these people have certain places where they stay, usually within a particular neighborhood. They come from a particular part of the country to Tier 1 and Tier 2 cities to earn their livelihood. So most likely, when they go back, they leave their accounts with known people in the neighborhood.

It’s generally friends and family who would be using the account. There is a big problem with this, though—it can result in the account ending up with people that we’ve already banned from the platform. So, for example, you have found a captain who was involved in collusion, and you banned them. Now, this account—which is still valid with my platform, with all documents and verification in place—goes to somebody who has been removed from the platform, compromising the integrity of the platform.

André: Got it. And one more question related to this, which is—we saw across other gig economy platforms that there are usually some implications when it comes to insurance.

When an unverified driver or captain, for example, gets involved in a traffic accident, from an insurance standpoint, the premiums might be much higher, right? And the platforms may end up having to pay a lot more for that kind of situation. Is this something that you see on your side as well? Does it have an impact on insurance?

Rizwan: Absolutely. What happens is that every single ride, from the moment the ride starts on my platform until the time the ride ends, is insured on the platform. These are through large insurance providers in the country.

But, God forbid, if a customer is involved in a road accident—for them to be eligible to get all the claims, for Rapido to be processing those claims—we need to have the right person, the person who was supposed to be on the ride, taking that ride. Because that is the person who was verified on the platform.

If it is somebody else, we would not shy away from our responsibility toward the customer. So we would still end up spending whatever is needed for the customer involved in the accident. But that comes out of our pocket because the insurance company would not go ahead and honor that.

André: Exactly. Got it. All right. And then in terms of the ongoing verification—you’ve mentioned that you have a very robust onboarding process, and then if you believe that someone else might be using that account, you ask that captain to go and take a selfie, for example.

Which signals do you use to decide which people you want to re-verify during their journey on the platform? Because you also don’t want to create a lot of friction, right? You don’t want to be re-verifying everybody all the time.

Rizwan: Yeah. So we are very careful, and we take cognizance of what the customer says. At different parts in the journey of a ride, our customer is asked different questions.

For example, before the ride begins, just as the ride starts, we ask whether they got a helmet or not. In the case of a cab, we ask the customer whether the AC is turned on or not. Then we ask the customer if the vehicle details match, or if the captain details match. We also ask the customer whether they were asked for extra cash.

All these indicators are part of the quality metrics I have for user experience. These are then put into a grid based on the severity of the issue. For example, if somebody says a different captain has turned up—that’s severity zero—versus somebody saying, “I was asked for extra cash.”

So when it’s a severity zero, that captain is suspended or removed. When it’s a severity one, two, or three, as the severity decreases—for example, asking for extra cash—I’ll still be more tolerant. Because if the customer has ended up paying extra cash, I will definitely refund the customer, and then I will speak to the captain to decide what happened.

It could be that the customer asked the captain to go an extra mile, and that’s why the guy asked for extra money. In an ideal scenario in Rapido, that gets auto-calculated in the fare. But if, because of any technical issue, that hasn’t happened and the captain has asked for extra cash, we let the captain go with a warning, saying that next time you have such an issue, Rapido is where you have to get in touch—you should not be indulging directly with the customer on these issues.

So, based on the severity grid of customer feedback, we issue the next line of action. Now, if somebody says that this is a different captain, we immediately send the selfie verification—the OCR check—to the captain as a follow-up, saying it has been reported that you are not the one driving the bike. Please take a photograph.

André: Okay, so let me play this back to you and see if I got it right. There’s a reliance on the end user—the customer side—for their input regarding what’s going on with that ride, right? So if there’s any kind of policy violation, like asking for extra cash, the vehicle not being the same, not having the AC turned on, or being a different captain than expected, you have this rank of severity. Depending on that, you have a different policy on how to react.

One follow-up question to that is—obviously, by relying on the end user, how do you incentivize users to provide this kind of input to you? Because, for example, as an end user, usually when I get into one of these rides, I just stare at my phone and do something else. Maybe I don’t even look into the app anymore. So is there any incentive for the end user? Is there any program to help them share more information with the platform?

Rizwan: We pick up these signals from what the customers report when they connect to our contact centers. And India being a huge country, you would not face, for example, an “asked for extra cash” problem in a city like Delhi, but you would face the same problem in a city like Kolkata or Guwahati, which is in the eastern part of the country.

So, customer signals form the basis of asking these questions—the micro-feedback that we collect. We take customer VOC very seriously. That’s what molds the questions we ask during different parts of the journey.

And there are a lot of proactive solutions we’ve implemented because of this. For example, we got a few cases where riders or drivers were rude, or to extract extra money from the customer, they would stop mid-ride and say, “I can’t go any further; I want to end the ride here.”

Now it’s a double whammy, because the customer either has to book another bike cab—wasting time—or wait. It’s time lost for him, and when he’s choosing a bike taxi, he’s looking for the fastest transportation solution available in busy traffic to take him from point A to point B.

Now, in that scenario, because the captain also understands the dependency the customer has on him, some of them—rogue ones—end the ride midway. We picked up this signal from customers. In our journey now, we have a process where if the captain or driver tries to end the ride before the destination, there’s a pop-up that goes to the customer:

“Did you want the ride to end here?”

If he or she says no, immediately the captain is contacted and told that the customer has not requested to be dropped here—please go ahead and complete the ride.

We actually take these feedbacks very seriously, and we make use of these VOCs to create predictive flows in our processes.

One very common thing that you would find, especially in a cab, is that people tend to get very relaxed once they sit down. What happens is, you keep your phone somewhere, you keep your bag somewhere—and we received a lot of VOCs from customers contacting us saying they had left their items behind.

Our contact center teams proactively reached out, saying they were getting a lot of these cases. We listened and made a small change in the process. Now, before you exit a ride, we ensure that we ask or remind you to collect your belongings. This very small correction, based on VOC, ensured that 90% of these feedback cases were reduced.

Before the ride ends, we now send a buzz saying, “Please ensure that you have collected all your belongings before you exit the cab or auto.” So, we take these feedback and VOCs very seriously—we make sure to hear them and make process corrections.

The incentive for the customer here is that it saves them time. It saves the time it would take to contact us and resolve the issue if we proactively solve it in advance.

André: I wanted to ask you a bit about automation and how that process runs internally. You mentioned the contact center, and there’s a lot of input coming from your customers—lots of customers, right? The numbers are quite big. So how large is the contact center operation, how much automation goes into it, and how does that work internally? Which tools are you also implementing to make that process more efficient?

Rizwan: Our contact centers—or our support centers—have undergone a transformation from being reactive to being predictive today.

What used to happen in the early days is that we would react only when the customer reached out to us. Then we started studying journeys—where in the flow is the friction happening? Where is the customer’s expectation failing?—and we started resolving those issues within the app itself.

I’m very proud to say that we have a very lean customer service team. We have industry benchmark numbers in terms of contact ratios. Our customer contact ratio is less than 1% of the overall audits that we do, and our captain contact ratio is about 1.5% of our captain base.

Our product teams have been very proactive in understanding these journeys, taking feedback from the contact centers, and then working on automating them. There are a lot of examples of this—and it’s not just on the customer side; we treat the captain or rider equally.

One of the most common queries we get from captains on the ground is, “I’m not getting an order,” or “I haven’t received an order,” or “Where is my order?”

This question has an underlying sentiment. The VOC is: “I’m not getting an order, I’m waiting for an order.” But in reality, he’s anxious that he’s not going to make the money he expected to earn on the platform by doing a certain number of rides. In any ride-hailing business, this becomes a major query if you do not pay fixed payouts to last-mile drivers.

So, if they’re paid based on the number of orders they complete and the kilometers they travel, this becomes a big concern.

We solved it. On the captain’s app, we started showing real-time data—indicating which areas the orders were coming from in the last 15 minutes. We nudged captains not to stay in a cold zone but to move to a zone where orders were being generated at that moment.

This helped improve customer experience, increased riders’ earnings, and also helped us save the contact—since my agent no longer had to reactively tell him, “Sir, go to this zone, you’ll get orders.”

That’s one example of how we predict problems and solve them beforehand—for both our captains and our customers.

André: Great. One thing I wanted you to share a bit about is that Rapido has quite a unique business model compared to other ride-sharing platforms. It would be great if you could share more about that, and what you think the impact is in terms of fraud and abuse because of that business model.

Rizwan: A lot of ride-hailing players—or most of them—operate on a commission basis for most of their business. On our platform, at least for our two major services and the third one that’s growing, our main bike taxi business, we let the captains be their own boss.

They have the option to apply on my platform on a subscription basis, to apply on a zero-commission basis, or to apply where they get surge pricing and we charge commissions from them. So, the captain selects what he wants to do.

Our cab business, our auto business, and our courier business—all three of them—are on SaaS. We do not charge any commissions from the captains, nor are we the custodian of the money being exchanged. Our job is just to bring the captain and the customer together, let them handshake on the platform, and take it forward from there.

Now, this presents unique cases of being defrauded, because Rapido as a platform is not taking charge of the money being exchanged—it’s a direct cash transaction happening between the customer and the captain. That opens up a lot of scope for collusion happening on the platform.

For example, since we do not control the money, if a captain is being incentivized—which we generally do not do—but if he gets a higher payout, say on a long ride, he can use the same device, and both the customer and the captain could be in the same place. The more rides he completes, the more he earns.

Or, for instance, if a captain is running a referral program and is using a fake GPS device on his phone, he could refer fake people, ensuring that those referrals again go on short or no rides, because it’s all happening at the same place. On the surface, it looks like the device has done rides, but in reality, no rides have taken place—and based on cancellations, payouts still go out.

So, in a cash-first market, or with the business model shift that we’ve made, predictive identification—being able to tell in advance that this customer or captain is a threat—becomes very important, rather than being reactive. Because in this setup, we don’t control a lot of things—it’s a direct cash exchange between the captain and the customer.

André: Got it. And when it comes to the future—in terms of fraud prevention and identifying abuse—what would you say are important priorities for you going forward?

Rizwan: India is a country of multi-apping and about 1.4 billion people. The more predictive you become, and the more you share the benefits of the network, the safer the supply becomes.

The captains that I want to acquire are the same captains that an e-commerce company wants to acquire. That’s the same captain that a food delivery company wants to acquire. So, we all want to acquire the same captain.

Now, in this race to onboard him first, a lot of times what happens in India is that his behavioral issues—or whether he’s the right candidate to onboard—we come to know later. Because the actions he might have displayed on Rapido aren’t captured on other platforms, and vice versa.

That’s where a shared network would greatly help. For example, if while onboarding I can detect that this guy has apps on his phone that shouldn’t be there—like an auto-clicker or a cloning app—that’s a red flag. Unless he’s a developer or working in tech, which some of our part-time captains do, there’s no reason for those apps to exist.

So, if I can identify that the device is risky, that’s one method. But if network sharing becomes stronger—if people who have been red-flagged for fraud on another platform can be identified—then I can take a proactive stance.

He might be a reformed man today, but at some point in his journey, he might try to take advantage of the system again. It would then be up to me either to place him on a watchlist—knowing that this guy has certain apps on his phone that might lead to possible fraud—or to flag that he has committed fraud on another platform.

If we can get all this information in one place, it makes decision-making about what to do with a captain a lot better.

André: Yeah, and on the network side, this is interesting because, on one hand, you have many apps competing for the same supply of captains. On the other hand, everybody wants to know who the bad actors are—the ones nobody wants to work with because they’ve been committing fraud or abuse.

How does that relationship work with other players in the market—leveraging network effects that combine data from different sources? How do you see that, and how do you think other players look at that as well?

Rizwan: If you talk about the industry as a whole, I think sharing data and signals would move the entire industry forward. It would be very shortsighted of me to say, “This is a bad apple on my platform, but I’ll keep it hidden from everyone else.” That’s not the right approach.

Currently, people are very skeptical about sharing data—whether it’s my competitors in the market or even me, when it comes to sharing that kind of information. But I think there’s some work happening on this front. People are starting to look at the larger market as a whole, realizing that if there’s someone who’s doing multi-apping, they’re more likely to do a ride on your platform tomorrow if they’re not doing it today.

As long as the market dynamics are right—if you meet the captain’s expectations of earnings per hour and the amount he makes per kilometer—if he’s not on your platform today, he’s likely to be there tomorrow to try it out.

That’s why I said it’s a shortsighted view not to let this information flow across the market. I would definitely want Rapido to take the lead on this and create a list of bad apples—something that anyone could verify if they wanted to.

André: Fantastic. And we’re observing this trend too—more players being open to sharing these kinds of signals across the ecosystem. This is very important because, at the end of the day, if a customer has a bad experience with one player, they’ll be more hesitant to use any other solution in the market.

Especially when it’s safety-related—it’s important for the whole ecosystem to present itself as safe and secure for all users.

Rizwan: There’s something interesting that we do at Rapido. If we get a whiff of a safety threat on social media—because on social media you can actually do listening—if my competitor is tagged by a customer saying, “This captain is a red flag,” we proactively take that into account.

But having said that, if we had a proper structure around this, where people were more forthcoming in sharing such information, it would benefit everyone. It would make all platforms safer and more secure overall for customers.

André: Going a bit deeper now on the technology side—in terms of your future roadmap and new things you want to implement—are there any particular signals or data points you want to go deeper on in your operations?

Rizwan: Yes. Our customer support contact ratios have reduced from 20% to under 1.5% today. We’re also working on automating our supply onboarding journeys. Earlier, only about 10–12% of captains were able to get onboarded without human intervention. Today, that number has gone up to 40%.

In a fully mature state, we want 80% of people to be able to get onboarded and start earning from the platform when they need it most. When someone downloads the app and wants to become a captain, that’s when their intent is highest. Today, because of our processes—and because many of us don’t use technology to its fullest extent, especially in non-business hours—this becomes a problem.

Let’s say someone wants to earn ₹100 at 9 o’clock at night—they have a bike, fuel in the tank, and they know they can take a few rides to earn that money. But because it’s outside business hours and our verification processes aren’t fully automated, they have to wait until the next morning for someone to connect with them and activate their account if something goes wrong during onboarding.

We definitely want technology to solve this problem—so that even during non-business hours, automated nudges, pushes, or calls go out to ensure that when intent is highest, we can convert that person right away.

We’re at about 40% auto-activations today, and we want to get that to 80% or more. The real problem isn’t the onboarding journey itself—it’s where you’re getting your leads and registrations from.

When you get your leads and registrations through non-human-intervention processes, the conversion ratios and the sanctity of the platform remain more intact than when you have human interventions in your onboarding journeys.

For example, when you work with references or with vendors on the ground—since India is a country where multi-apping is very common—people would have access to data, and those who onboarded people for other platforms would most likely have access to that data. That is where the chances of not getting the right kind of leads onto your platform increase.

That’s why being proactive about it—doing your sanctity checks, or having your sanctity checks during the onboarding journey, whether it is for a customer or a captain—is the right way to go about it. Which, I think, is a problem that Incognia solves for a lot of people in the market.

André: Excellent. You spoke a little about referrals, and that’s one area where there could be a lot of abuse. The other part I wanted to ask about is loyalty. If you have incentives for captains who are very active on your platform or get good ratings—how do you see referral and loyalty programs being potentially abused by captains?

Rizwan: Fortunately for us, our cab services and auto services operate on a SaaS model. So we don’t incentivize or offer discounts.

Now, you might ask—if there’s no incentive, why would I care about wrong acquisitions? Two reasons. First, I’d still be paying for the acquisition, so someone could defraud me there. Second, if it’s not the right kind of acquisition, user experience suffers.

The person might be a dummy player, not a real captain, yet still get assigned rides, which they decline—hurting customer experience. So, the fraud wouldn’t happen during or after the ride; it would happen before, during acquisition.

If I have device IDs that flag red devices, I can avoid onboarding those captains, saving both customer experience and money.

André: And another topic I wanted to cover with you is around GPS spoofing. GPS spoofing is very common in the ride-hailing industry, and we’ve seen this across many platforms. Behaviors like, for example, when there is a lot of demand from places like airports, the captains or the drivers would spoof their location to make it look like they’re closer to the airports so that they get those rides prioritized.

Then the customer requests a ride, but they’re not really there at the airport, so it takes much longer for them to get there. And then the customer experience could be very bad. Is this a concern for you at Rapido, and how have you handled this so far?

Rizwan: Absolutely. Great that you asked this, you brought this up. So, one of our major cities where we run our operations is called Kota, and there we faced this problem at a syndicate level where about 20% of my captains—as I told you that we are a platform where we do not incentivize, where we do not give discounts—but because you have displayed certain good behavior on the platform and because of the kind of vehicle that you have, we would try to prioritize airport rides to you.

Now, captains were aware of this, and what they started doing is that they started GPS spoofing by showing that they were closer to the airport in order to get these rides. And it started leading to a bad experience because the ETA of the rides were supposed to be two minutes, three minutes, but these captains were actually far away. Then, getting into the airport to pick these rides was delaying the time that the customer was being picked up and spoiling the customer experience.

André: Got it. And this is very dynamic. What we see on our side at Incognia is that typically when you start identifying this kind of behavior and you start blocking it, then the bad actors adapt very quickly and start using other techniques to spoof GPS, right?

You can use GPS spoofing apps, you can use app cloners, clickers, and sometimes they’re even hardware-based attacks—like people who have devices that allow them to spoof GPS. So this is a very dynamic space, but I’m glad that you’re monitoring this kind of behavior.

Rizwan: What becomes even more challenging for a platform like us is that we have three, four, five different services, and each comes with their own personnel. For example, my bike taxi business would have a lot of part-timers coming onto my platform to earn a part-time income or supplementary income over and above their main jobs.

Now, these people could be developers, product guys, tech guys—for them, to test apps they would probably, in a certain environment, have GPS spoofing apps on their phones, but not necessarily with the intention to defraud. However, for a cab guy or an auto guy and the genre of people there, it is something very surprising for them to have GPS spoofing apps.

Now, you cannot take a blanket decision—you know, that anybody who has a GPS spoofing app, remove him from the platform. But what you could definitely do is watch. Once you are aware that he has a GPS spoofing app on his phone, then watch. Watch such that you could limit the damage, such that you can prevent the damage.

That’s just one example of why you would not go ahead and blindly remove anybody who has a GPS spoofing app on their phone.

André: Yeah, totally. And on another technical topic—app cloners. We’ve seen in many ride-hailing businesses people using app cloners so that they can manage multiple accounts at the same time. They can accept rides faster. And many times, if one account is being prioritized, they would use that one, and if another gets prioritized later, they would switch. Is that kind of behavior something that you see as well?

Rizwan: We encounter these problems, and it is not just to get access to prioritized accounts that they use cloners for or to have multiple accounts. They also use it to defraud customers.

For example, you take a ride, and you are in a hurry to get off the ride and rush to the airport or the railway station or your office. At the end of the ride, you ask the captain what is the amount that you pay, and he shows you the app—it shows ₹600, while when you booked the ride you would have seen ₹400.

And by the time you reach the office, that is when the “cash collected” message would come to you, and it would say ₹400 or ₹450 is what you paid. So they would match the last two digits—for example, if it is ₹497, they would ask you for ₹697. Now, you see that message, but you’ve already gone into your morning meetings. Only later do you realize, “Oh, I ended up paying ₹200 more,” but you saw that on the app.

So this is one way that they use it to defraud customers, and it’s a problem that we face.

André: Yes, for sure. Now, moving to collusion—talk a bit more about that. How do you see that, and which kind of collusion do you typically see on the platform, and what’s the impact for the business?

Rizwan: See, there are a few common types of collusion that happen, and they happen across the internet company space—whether it is food delivery, whether it is quick commerce, or ride-hailing.

We initially, when we do acquisitions—especially customer acquisitions—for customers to use the platform or to experience the platform, there are certain discounts, or there would be seasonal offers for customers. When you want to grow, people take advantage, creating multiple accounts to take advantage of the first-time discounts or the user acquisition discounts. It’s very common.

Wherever you have incentives running—whether for captains or drivers, whether it is on time-based incentives, login-based incentives, or ride-based incentives—all of this, wherever you have incentives, wherever you have discounts, wherever you have referrals, wherever you have human beings intervening to allow you to acquire your end user—these four or five cases are common for everybody in this space.

The first-user discounts getting misused and your incentives getting misused is common for everybody.

André: Yeah, and cancellations, refunds, and all that. Cool. Excellent. I think we covered a lot of things, so I’ll try to summarize a few takeaways here, and I’d love to close with some of your recommendations for other players in the industry.

Let me see if I got things right or if I’m missing something. So the first one here is around balancing supply and protecting the ecosystem and the platform. You have to separate the different types of violations. In some cases, your policy would be to just block the account right away. In others, it would be more related to prioritization and things like that.

The second takeaway here is related to the business model and its impact on fraud and abuse, right? So depending on how you structure your business model, you’re going to incentivize or disincentivize certain fraudulent behaviors on both sides—the rider and the customer.

It’s also interesting that you have this approach that’s very customer-centric. The customers are providing a lot of input and signals to you, and this is informing your strategy on how you handle and correct these problems. And then your customer service team is able to act on that.

There’s an ongoing effort to go from a more reactive type of approach to a more proactive one, with more technology and more automation.

And finally, some specific technical things that you’ve been looking into, like device IDs, GPS spoofing detection, app cloning detection, and collusion detection being part of your strategy to address these things with more automation, more scale, and more productivity.

Did I miss anything?

Rizwan: Yeah, I think overall as an industry, based on summarizing how network effects would help make the place safer for customers—yeah, I think that summarizes all that we covered.

André: Fantastic. The network effect is a big component. So, Rizwan, any recommendations for your peers in the industry on how they should think about not only preventing fraud and abuse on the platform but also balancing that with supply constraints and keeping the business running?

Rizwan: One is that we should definitely be aware. While a lot of us—companies like us in the market—do a lot of reactive stuff in terms of curbing, controlling, and identifying fraud, we should try and at least be aware in the onboarding journeys what are the red flags you would want to act upon, based on severity grades that you have defined, which is completely all right.

But knowing that a red-flag device—or supposedly a red-flag device—is on my platform, and keeping it under watch, looking out for what’s happening on those accounts, I think only makes the platform safer and helps you stop yourself from being defrauded, while at the same time bettering your customer experience.

So, all of us, I think, should move towards less rule-based reactive stuff, and more towards—if customer safety, experience, and not being defrauded are on our priority list—we should definitely work towards getting proactive indicators on whether we are acquiring the right kind of people onto the platform.

André: Fantastic. Awesome. Really good. Rizwan, thanks for joining me on this session. I really appreciate your time. You shared very valuable insights with the audience here.

And one thing I wanted to tell the audience is, if you’re watching or listening to this and you are in a business that competes with Rapido, please know that Rizwan is willing to partner on sharing intelligence on a network to make the whole ecosystem better and safer. So this is very good and, I’d say, a very mature approach—to be willing to collaborate with other companies in the industry. Because again, this is going to make the entire sector better, and it’s going to grow the pie for everybody. This is a very good approach.

Rizwan: Thank you for having me here. It was my pleasure talking to you, André.