WEBVTT
1
00:00:10.120 --> 00:00:10.953
Last year,
2
00:00:11.380 --> 00:00:16.040
a high-growth AI company discovered that a single user had created
3
00:00:16.320 --> 00:00:21.060
more than 86,000 accounts and never made any
4
00:00:21.280 --> 00:00:23.980
legitimate payments, not a single one.
5
00:00:25.100 --> 00:00:26.860
That wasn't a bug in their system.
6
00:00:27.440 --> 00:00:32.000
It was in fact a coordinated multi-account attack that allowed
7
00:00:32.300 --> 00:00:36.980
bad actors to systematically take advantage of free token usage.
8
00:00:38.680 --> 00:00:43.320
So multi-account attacks are just one of many abuse patterns
9
00:00:43.600 --> 00:00:48.580
hitting high-growth companies. It's happening across industries-from SaaS,
10
00:00:49.020 --> 00:00:51.880
retail, travel, AI, and more.
11
00:00:52.480 --> 00:00:56.880
There's been a rise in first-party fraud. So, what is first-party fraud?
12
00:00:57.660 --> 00:01:02.520
It's when a customer abuses businesses' policies for their own gain.
13
00:01:04.480 --> 00:01:07.780
The exact shape of customer abuse varies by industry,
14
00:01:08.680 --> 00:01:13.500
but we saw that over 60% of businesses experienced an increase in first-party
15
00:01:13.580 --> 00:01:18.440
fraud in 2025-especially free trial, policy,
16
00:01:18.920 --> 00:01:23.480
and refund abuse. And AI has accelerated all of this,
17
00:01:24.020 --> 00:01:28.520
making these attacks much easier to orchestrate and more rewarding for bad
18
00:01:28.580 --> 00:01:31.400
actors. I'm Samuel,
19
00:01:32.020 --> 00:01:35.680
a lead product for payments intelligence here at Stripe. And today,
20
00:01:36.380 --> 00:01:40.180
we'll walk through how first-party abuse can impact your business.
21
00:01:41.000 --> 00:01:42.740
We'll also talk about how Radar,
22
00:01:43.220 --> 00:01:46.700
Stripe's fraud and abuse prevention solution,
23
00:01:47.140 --> 00:01:50.280
can help you at every stage of the customer lifecycle.
24
00:01:51.000 --> 00:01:55.260
We'll also hear directly from Cursor about how they've responded to these new
25
00:01:55.440 --> 00:01:56.540
abuse vectors.
26
00:01:58.080 --> 00:02:02.660
So let's get started and let's start by walking through the customer lifecycle
27
00:02:03.240 --> 00:02:07.100
to see exactly where these attacks hit and what we built to address it.
28
00:02:08.640 --> 00:02:13.260
So first, at accounts sign-up, bad actors commit multi-account abuse.
29
00:02:14.120 --> 00:02:17.820
What they do here is that they just cycle through multiple accounts using new
30
00:02:17.920 --> 00:02:20.320
email addresses. In fact,
31
00:02:20.780 --> 00:02:25.100
we found that 14% of new accounts at AI companies are
32
00:02:25.260 --> 00:02:29.420
suspected of committing multi-account abuse. It's a big number.
33
00:02:30.180 --> 00:02:34.660
So the user I mentioned with 86,000 accounts-that's an extreme,
34
00:02:34.820 --> 00:02:36.740
but it's definitely not an anomaly.
35
00:02:38.420 --> 00:02:41.900
So let's spend a bit more time to understand what makes this hard to catch
36
00:02:41.980 --> 00:02:46.780
today. Generative AI has made all signals obsolete.
37
00:02:47.460 --> 00:02:51.740
We used to rely on things like gibberish email addresses, inconsistent names,
38
00:02:52.060 --> 00:02:55.500
suspicious sign-up patterns. Those are all gone.
39
00:02:56.520 --> 00:03:00.980
Bad actors are also using AI themselves, but this time to generate clean,
40
00:03:01.260 --> 00:03:05.260
convincing, onboarding data. So the accounts, they look pretty real.
41
00:03:05.920 --> 00:03:09.520
We did what we usually do best at Stripe, which is we built a new API.
42
00:03:10.740 --> 00:03:15.540
That API takes in sign-up events and returns a multi-account abuse
43
00:03:15.760 --> 00:03:18.640
risk score before the payment even occurs.
44
00:03:19.160 --> 00:03:23.980
So what you're seeing here is you can think of Radar working upstream at sign-up
45
00:03:24.020 --> 00:03:27.360
time, decoupled entirely from the transaction itself.
46
00:03:28.640 --> 00:03:32.000
And because we're looking across millions of businesses under Stripe network,
47
00:03:32.520 --> 00:03:36.520
you can now catch bad actors at sign-up using device, email,
48
00:03:36.760 --> 00:03:41.740
and identity signals from across millions of businesses, not just your own.
49
00:03:44.140 --> 00:03:46.260
So now that we've talked about multi-account abuse,
50
00:03:47.340 --> 00:03:49.720
the next thing that happens is after sign-up,
51
00:03:49.880 --> 00:03:54.020
you may want to offer free trials to drive business growth.
52
00:03:54.120 --> 00:03:56.900
But this is also where trial abuse happens.
53
00:03:57.600 --> 00:04:02.600
This is when a user signs up and exploits the trial period by driving high
54
00:04:02.680 --> 00:04:05.620
usage without ever intending to pay.
55
00:04:06.800 --> 00:04:10.680
This actually can be quite challenging to catch because you have to tell the
56
00:04:10.720 --> 00:04:15.640
difference between a legitimate user interested in trialing your product and
57
00:04:15.660 --> 00:04:18.860
the bad actors looking to exploit free access.
58
00:04:21.520 --> 00:04:23.320
To make this even more challenging,
59
00:04:23.660 --> 00:04:28.660
traditional fraud prevention wisdom actually says to automatically block
60
00:04:28.880 --> 00:04:32.620
high-risk payment methods like virtual cards at trial.
61
00:04:33.740 --> 00:04:34.573
But today,
62
00:04:34.580 --> 00:04:39.200
virtual cards are legitimately used by customers for privacy and
63
00:04:39.240 --> 00:04:40.073
security reasons.
64
00:04:40.820 --> 00:04:45.680
So what that means is blanket blocking virtual cards as a payment method leads
65
00:04:45.740 --> 00:04:49.320
to rejecting legitimate trials, and in result,
66
00:04:49.640 --> 00:04:54.220
taking a hit to your revenue.
So now to put all of this in
67
00:04:54.260 --> 00:04:58.700
perspective by the numbers: every day, on average,
68
00:04:59.100 --> 00:05:03.940
our models detect 155,000 fraudulent free trial
69
00:05:04.680 --> 00:05:05.580
with more than 100,000
70
00:05:07.400 --> 00:05:10.160
high-risk cards added to trial accounts daily.
71
00:05:12.540 --> 00:05:16.720
So the recommendation is just don't stop offering free trials.
72
00:05:16.780 --> 00:05:19.980
You can't just stop offering them. It's a key way of driving growth.
73
00:05:20.500 --> 00:05:25.420
So we built a one-click control that lives within Radar that predicts the
74
00:05:25.520 --> 00:05:29.760
likelihood of an abusive free trial at the moment a payment
75
00:05:30.600 --> 00:05:35.280
method is added, not at the end of the trial when it's already too late.
76
00:05:36.180 --> 00:05:41.160
So you can now block high-risk trials automatically before you've incurred the
77
00:05:41.220 --> 00:05:42.260
cost of serving them.
78
00:05:44.200 --> 00:05:49.160
And our models have a 95% precision at detecting fraudulent free trials
79
00:05:49.560 --> 00:05:51.740
and are getting better every day.
80
00:05:54.300 --> 00:05:58.920
Next, when it comes to payment, preventing transaction fraud is critical.
81
00:05:59.720 --> 00:06:01.220
When customers use stolen cards,
82
00:06:02.100 --> 00:06:05.600
it results in disputes driving up cost and reducing your revenue.
83
00:06:06.440 --> 00:06:10.600
This actually has been Radar's bread and butter for a long time. And today,
84
00:06:11.060 --> 00:06:15.120
we're excited to share that Radar now blocks high-risk
85
00:06:15.580 --> 00:06:20.260
transaction across all payment methods.
That's right. All of them,
86
00:06:21.200 --> 00:06:25.480
including bank debits, BNPLs, wallet, stablecoins, and more.
87
00:06:26.320 --> 00:06:30.020
Sophisticated fraudsters don't just stop at one payment method,
88
00:06:30.460 --> 00:06:32.120
and now Radar doesn't either.
89
00:06:33.600 --> 00:06:38.000
We're also excited to share that Radar now covers payments processed
90
00:06:38.300 --> 00:06:39.133
off-Stripe.
91
00:06:39.400 --> 00:06:43.760
What this means is you can think of Radar as your holistic fraud provider,
92
00:06:44.280 --> 00:06:46.960
even when payments run through other processors,
93
00:06:47.460 --> 00:06:52.080
with the same intelligence built in with fraud likelihood scores on every
94
00:06:52.500 --> 00:06:53.333
transaction.
95
00:06:55.440 --> 00:06:59.800
But transaction fraud is no longer the only threat at checkout.
96
00:07:00.460 --> 00:07:03.980
We're seeing a rise in automated bot-driven
97
00:07:04.260 --> 00:07:08.700
purchases-high volume of transactions made programmatically.
98
00:07:09.700 --> 00:07:14.400
The key here is distinguishing between legitimate agentic transactions
99
00:07:14.780 --> 00:07:19.640
and abusive ones like bulk buying subscriptions to resell or draining
100
00:07:19.740 --> 00:07:24.400
limited inventory. That's why we're introducing a bot score:
101
00:07:24.980 --> 00:07:29.760
a new signal at payment time to help you catch fraudulent automated
102
00:07:30.040 --> 00:07:34.940
transactions. To be clear, not all bots are bad. We actually love good bots.
103
00:07:35.080 --> 00:07:37.140
We welcome them. As we've shared yesterday,
104
00:07:38.020 --> 00:07:40.200
agentic commerce represents a huge opportunity.
105
00:07:41.080 --> 00:07:43.220
The goal isn't to block automation:
106
00:07:43.720 --> 00:07:48.460
it's to tell the difference between a legitimate agent acting on a user's behalf
107
00:07:49.120 --> 00:07:52.040
and an automated scheme with the goal of committing fraud.
108
00:07:54.380 --> 00:07:59.040
Now, at the end of the cycle, after your customer uses your product,
109
00:07:59.480 --> 00:08:02.120
you experience pay-as-you-go abuse.
110
00:08:02.680 --> 00:08:04.880
So if you have a usage-based business model,
111
00:08:05.360 --> 00:08:09.120
or you may just invoice your customers at the end of the month, let's say,
112
00:08:09.320 --> 00:08:10.720
for services already rendered,
113
00:08:11.360 --> 00:08:15.800
you face the risk that a user racks up a bunch of usage only for the payment to
114
00:08:15.920 --> 00:08:18.600
fail. So to bring this to life,
115
00:08:19.600 --> 00:08:24.200
let's say a SaaS business attempts to charge their user for their monthly usage
116
00:08:24.320 --> 00:08:27.240
bill, but they can't successfully complete the transaction.
117
00:08:28.000 --> 00:08:32.600
So the SaaS business is stuck with the bill for a service they already
118
00:08:32.800 --> 00:08:37.000
provided. So what makes this kind of abuse hard to detect?
119
00:08:37.760 --> 00:08:42.560
The challenge here is that the initial transaction often looks clean and went
120
00:08:42.600 --> 00:08:43.433
through.
121
00:08:43.600 --> 00:08:47.840
The problem doesn't surface until later in the billing failure.
122
00:08:49.600 --> 00:08:52.320
That's why to minimize pay-as-you-go abuse,
123
00:08:52.770 --> 00:08:57.120
Radar now helps you spot users who complete initial transactions,
124
00:08:57.560 --> 00:09:00.160
but have no intent to pay for future usage.
125
00:09:03.360 --> 00:09:04.193
So to recap,
126
00:09:04.800 --> 00:09:08.680
you can now protect your business from fraud and abuse across the entire
127
00:09:09.000 --> 00:09:13.560
customer lifecycle with Radar-not just at transaction time.
128
00:09:14.480 --> 00:09:19.280
And Radar is now able to do that because it analyzes data from millions of
129
00:09:19.400 --> 00:09:22.120
businesses across the full customer lifecycle.
130
00:09:22.800 --> 00:09:27.720
This allows it to detect front-end abuse patterns that might not normally
131
00:09:27.880 --> 00:09:31.760
stand out when looking at individual interactions.
132
00:09:34.240 --> 00:09:38.800
Now, customer abuse affects every industry as we've shared earlier,
133
00:09:39.440 --> 00:09:44.440
but AI companies are feeling this even more acutely because of the high compute
134
00:09:44.680 --> 00:09:45.513
cost.
135
00:09:46.120 --> 00:09:50.040
So to learn how a leading AI company is navigating these threats,
136
00:09:50.520 --> 00:09:54.520
please join me in welcoming Jacob Meltzer, engineering lead for Radar,
137
00:09:54.840 --> 00:09:57.560
and Jacob Witt, product manager at Cursor.
138
00:09:58.040 --> 00:10:00.840
Hi. Thanks, Samuel, and thanks, Jacob, for joining us.
139
00:10:00.920 --> 00:10:01.753
Of course.
140
00:10:02.200 --> 00:10:05.560
I think most people in the audience have probably heard of Cursor,
141
00:10:05.780 --> 00:10:08.080
but for those who haven't, can you give us the 10-second pitch?
142
00:10:08.520 --> 00:10:11.300
Yeah. Cursor is a developer tool.
143
00:10:11.500 --> 00:10:14.220
We make it easy to build and build with agents.
144
00:10:14.300 --> 00:10:18.840
We're used by millions of people across a lot of society-from Fortune 500,
145
00:10:19.500 --> 00:10:21.280
high school teachers, and even Stripe.
146
00:10:22.300 --> 00:10:24.600
That's awesome. So you lead growth at Cursor.
147
00:10:24.920 --> 00:10:27.520
Can you share how you think about growth? And specifically,
148
00:10:27.600 --> 00:10:31.660
we know that growth often comes with an increased opportunity for fraud.
149
00:10:32.100 --> 00:10:33.660
How do you think about balancing that trade-off?
150
00:10:35.080 --> 00:10:37.900
Yeah. So high level for growth is,
151
00:10:38.360 --> 00:10:41.060
you want to acquire customers that are happy on your platform,
152
00:10:41.700 --> 00:10:45.680
and you want to make sure the customers you have are getting the most out of the
153
00:10:45.720 --> 00:10:47.660
tool. Now, the challenge is,
154
00:10:47.880 --> 00:10:51.420
and I think a lot of people are not selling an AI product,
155
00:10:51.500 --> 00:10:55.340
this is not intuitive, but inference is very similar to interchange.
156
00:10:55.740 --> 00:10:59.580
You've got this very valuable thing that has a high marginal cost,
157
00:11:00.220 --> 00:11:02.940
and it incentivizes actors to come and take it.
158
00:11:03.400 --> 00:11:05.340
So what we get is a lot of people who,
159
00:11:05.720 --> 00:11:08.340
any offer we give or promo or referral bonus,
160
00:11:09.260 --> 00:11:12.840
you get inference and you can take it, resell it, package it, take the SDK,
161
00:11:13.060 --> 00:11:14.040
the API, whatever.
162
00:11:14.940 --> 00:11:19.480
If you scroll down to like 20 through 30 on the app store ranks for
163
00:11:19.640 --> 00:11:20.473
productivity apps,
164
00:11:20.580 --> 00:11:24.900
a lot of those apps are probably reselling inference from some other tool.
165
00:11:24.900 --> 00:11:28.200
So what that means for us is everything we're balancing between-sure,
166
00:11:28.260 --> 00:11:30.820
there's a growth opportunity-but we have a real fraud cost.
167
00:11:31.340 --> 00:11:35.200
Yeah, that makes sense. I feel like even just like a year or two ago,
168
00:11:35.340 --> 00:11:39.620
we would see cards get used and you would see stealing shoes and things like
169
00:11:39.660 --> 00:11:39.960
that.
170
00:11:39.960 --> 00:11:44.440
And it's like token theft is like the new shoe stealing and stuff like that,
171
00:11:44.520 --> 00:11:45.440
which is kind of interesting.
172
00:11:45.780 --> 00:11:47.840
You can steal a lot more tokens than shoes for sure.
173
00:11:48.820 --> 00:11:53.360
A little easier to store, I guess. Cool. So walk us through,
174
00:11:53.570 --> 00:11:54.420
how long have you been at Cursor?
175
00:11:54.850 --> 00:11:55.683
Eight months.
176
00:11:55.870 --> 00:11:58.110
Okay. I think it's probably been an exciting eight months.
177
00:11:58.490 --> 00:12:02.180
Walk us through fraud when you first joined. What did it look like?
178
00:12:02.250 --> 00:12:03.930
What did you do about it? Stuff like that.
179
00:12:04.630 --> 00:12:09.070
One of the things we're known for, at least in SF is when you're interviewing,
180
00:12:09.470 --> 00:12:12.490
you come on-site and you're in the office for two days.
181
00:12:13.110 --> 00:12:17.750
So I was expecting to have a project, go and put together some slides,
182
00:12:17.800 --> 00:12:18.633
maybe a prototype.
183
00:12:19.750 --> 00:12:24.410
And I come in Monday morning and there's a literal war room going on. Our COO,
184
00:12:24.650 --> 00:12:29.110
some engineers, the finance team, and it's like, we have to fix the trials.
185
00:12:30.030 --> 00:12:33.750
At the time, we did not require a credit card to start a trial.
186
00:12:34.450 --> 00:12:39.450
And inference cost on free trials was approaching or even greater
187
00:12:39.510 --> 00:12:41.610
than some of our inference costs for paid segments.
188
00:12:42.170 --> 00:12:47.030
We were just getting completely lit up. So after this huge period of growth,
189
00:12:47.150 --> 00:12:50.350
it was like, we have to put our feet down. We have to fix it.
190
00:12:50.790 --> 00:12:54.530
So my two-day onboarding interview project was
191
00:12:56.130 --> 00:12:59.030
how are we going to actually require credit cards up front?
192
00:12:59.030 --> 00:13:01.170
How are we going to test it? How are we going to make sure that
193
00:13:02.770 --> 00:13:04.750
we're not hurting conversion, but bringing these costs down?
194
00:13:05.170 --> 00:13:08.230
How'd you go about making that trade-off? What was the thinking?
195
00:13:08.870 --> 00:13:13.290
When you see a chart that is going so up into the right that quickly, it was a,
196
00:13:13.770 --> 00:13:15.530
like, we have to pull a lever, we have to do something.
197
00:13:16.630 --> 00:13:21.280
I think for free trials generally-especially for Cursor starting in 2023,
198
00:13:21.590 --> 00:13:25.790
which seems really recent-but for a lot of customers at the time,
199
00:13:26.610 --> 00:13:27.680
you maybe don't believe in AI.
200
00:13:27.800 --> 00:13:31.530
So it was very important for us to have an extremely generous free trial to feel
201
00:13:31.570 --> 00:13:35.510
the magic, actually use it, believe that it's something that you can work with.
202
00:13:36.630 --> 00:13:37.650
By the time we were doing this,
203
00:13:37.730 --> 00:13:39.950
I think the name Cursor was a little more well known.
204
00:13:40.490 --> 00:13:43.910
I think a lot of people understood, yes, AI is valuable and it's more,
205
00:13:44.030 --> 00:13:48.930
what do I do with it? So we were really concerned about the trade-off,
206
00:13:49.070 --> 00:13:52.630
and we didn't end up actually seeing that much of a conversion hit.
207
00:13:52.680 --> 00:13:57.650
People understand now that tokens cost money and are a little more willing to
208
00:13:57.670 --> 00:13:59.850
pay up front before they even get into the app.
209
00:14:00.350 --> 00:14:03.350
Yeah. That makes sense. It's sort of like a unique challenge, I guess,
210
00:14:03.410 --> 00:14:06.910
in an industry that's sort of evolving and a lot of people are experiencing this
211
00:14:07.350 --> 00:14:10.680
for the first time. So you sort of mentioned something interesting.
212
00:14:11.550 --> 00:14:14.430
You said free trials and then I think you hinted at free accounts.
213
00:14:14.490 --> 00:14:18.710
So my understanding is Cursor at one point offered trials, now less trials,
214
00:14:18.810 --> 00:14:19.643
more free accounts.
215
00:14:20.270 --> 00:14:22.590
I know I've talked to a bunch of AI companies here today who are thinking about
216
00:14:22.710 --> 00:14:25.010
promos. Maybe I should actually do 50% off.
217
00:14:25.410 --> 00:14:28.930
How do you think about these trade-offs? And why offer free trials?
218
00:14:28.990 --> 00:14:31.270
Why offer free accounts? When to think about promos?
219
00:14:31.410 --> 00:14:35.590
We've evolved over time as malicious actors have kind of gotten smarter.
220
00:14:36.370 --> 00:14:40.350
I wish we could be more generous, but there's a cost to giving free things away.
221
00:14:41.210 --> 00:14:45.570
So we required a credit card to start a trial and eventually,
222
00:14:45.630 --> 00:14:47.870
we had to make the decision to remove trials entirely.
223
00:14:48.230 --> 00:14:49.230
We still offer a free plan,
224
00:14:49.530 --> 00:14:51.990
but I think the way we thought about the trial versus a free plan,
225
00:14:52.110 --> 00:14:56.070
was free plan you can really kick the tire a tiny bit,
226
00:14:56.790 --> 00:14:59.970
get started, see how it works. Versus the trial,
227
00:15:00.050 --> 00:15:03.410
we wanted to replicate what does the paid plan feel like?
228
00:15:03.470 --> 00:15:05.150
And it was much more generous in terms of usage.
229
00:15:05.970 --> 00:15:07.390
We just didn't find a way to make that work.
230
00:15:07.650 --> 00:15:11.410
And even in cases where we could identify who are the really good trusted
231
00:15:11.450 --> 00:15:14.350
customers, there wasn't that much of a conversion delta.
232
00:15:15.530 --> 00:15:17.290
So now it's just a, when you sign up,
233
00:15:17.370 --> 00:15:20.770
there's a paywall to start on our $20 entry plan,
234
00:15:21.330 --> 00:15:24.750
or you can start for free and that'll get you a couple minutes,
235
00:15:25.510 --> 00:15:27.210
maybe a couple of requests to play around.
236
00:15:27.770 --> 00:15:30.870
Yeah, that makes sense. I guess free is never fully free,
237
00:15:31.470 --> 00:15:32.570
but that's sort of interesting though.
238
00:15:33.030 --> 00:15:36.070
You don't want to degrade the trial experience if it's a trial,
239
00:15:36.130 --> 00:15:38.270
you want to give someone the experience of the full thing.
240
00:15:38.330 --> 00:15:42.250
Whereas free accounts are sort of an opportunity to have a more limited product
241
00:15:42.310 --> 00:15:46.070
experience. So what do you do today to mitigate the risk of the free accounts?
242
00:15:47.810 --> 00:15:48.850
We lean heavily on you guys.
243
00:15:49.890 --> 00:15:53.390
We have probably 200-plus Radar rules at this point.
244
00:15:53.490 --> 00:15:56.690
It's been a work in progress, but we need,
245
00:15:57.450 --> 00:16:02.250
we have tons and tons and tons of sign-ups every day and we need to measure
246
00:16:02.310 --> 00:16:05.610
like, do we think these actors are real? Are they actually going to pay us?
247
00:16:06.530 --> 00:16:08.190
And the math is basically,
248
00:16:08.730 --> 00:16:12.830
the more we're able to cut off and get signals on users before they sign up,
249
00:16:13.190 --> 00:16:16.650
the more generous we can be for valid users who we want to have a really good
250
00:16:16.670 --> 00:16:21.350
experience. But if we can't stop fraud, then your mix is much worse.
251
00:16:21.790 --> 00:16:25.250
Definitely. I think it's been really helpful. One of the... Previously,
252
00:16:25.330 --> 00:16:29.110
Radar usually only operated at payment time and we've sort of been going up the
253
00:16:29.150 --> 00:16:30.970
funnel and hopefully down the funnel too.
254
00:16:31.330 --> 00:16:35.090
And I think being able to screen the sign-ups has both made us better at helping
255
00:16:35.410 --> 00:16:38.370
stop abuse early, but also has made us better at payment time,
256
00:16:38.470 --> 00:16:39.303
which is kind of cool.
257
00:16:39.350 --> 00:16:43.170
Other than free accounts and obviously credit card fraud and traditional
258
00:16:43.210 --> 00:16:46.250
fraudulent disputes, what other risk vectors are you currently fighting?
259
00:16:47.110 --> 00:16:51.670
We see a lot of it. There's card testing. Local payment methods,
260
00:16:51.930 --> 00:16:56.330
I think was this beautiful idea of like people want to pay the way they want to
261
00:16:56.370 --> 00:16:58.110
pay. So why add friction?
262
00:16:59.270 --> 00:17:01.830
It was not as easy just flipping a switch.
263
00:17:02.990 --> 00:17:06.790
Local payment methods have local fraud varieties and different logic and dealing
264
00:17:06.830 --> 00:17:11.010
with either flow of funds or the timing between transactions can get kind of
265
00:17:11.030 --> 00:17:11.863
gnarly.
266
00:17:12.510 --> 00:17:17.410
So we flipped some switches and got blown up a little bit and then had to figure
267
00:17:17.450 --> 00:17:21.130
out on the Radar side. But working with you all has made that work well.
268
00:17:21.290 --> 00:17:24.890
What we're starting to see more is-and again,
269
00:17:24.950 --> 00:17:28.410
it feels very much like operating a fintech or a crypto company-of account
270
00:17:28.430 --> 00:17:31.790
takeovers, of more and more and more we're seeing people either
271
00:17:33.550 --> 00:17:37.510
managing to get an invite to customer, they're pretending to be a valid user.
272
00:17:37.510 --> 00:17:40.710
They get joined onto this team and then all of a sudden they're able to invite
273
00:17:41.150 --> 00:17:44.530
hoards of bots. You're draining inference. It's again,
274
00:17:44.590 --> 00:17:48.690
this variable product that you can resell extremely easily.
275
00:17:49.290 --> 00:17:52.590
So we've had to implement a ton of controls to protect against that.
276
00:17:53.010 --> 00:17:57.390
That makes sense. On the LPM side. I definitely wanted to get there,
277
00:17:57.490 --> 00:17:59.710
so it is as easy as a click of a button, but yeah-.
278
00:18:00.330 --> 00:18:00.710
Not yet.
279
00:18:00.710 --> 00:18:03.310
Not yet. I think like a lot of businesses,
280
00:18:03.370 --> 00:18:06.350
they're not used to the asynchronous nature of some of the payment methods.
281
00:18:06.410 --> 00:18:07.690
They get less information.
282
00:18:07.790 --> 00:18:11.350
And I think Radar sort of adapting is one way we want to close that gap.
283
00:18:13.190 --> 00:18:16.650
Can you share any other examples of customer-friendly features that you've
284
00:18:16.750 --> 00:18:20.330
introduced and have been exploited in ways that you didn't expect?
285
00:18:21.310 --> 00:18:23.010
We just want to be generous for customers,
286
00:18:23.070 --> 00:18:25.950
and I think most of the time we get hammered when we try to do so.
287
00:18:26.810 --> 00:18:27.890
What are some of those features?
288
00:18:28.670 --> 00:18:32.310
So the one that was like the most frustrating was,
289
00:18:33.490 --> 00:18:36.270
if you're using Cursor, you send a message in the chat,
290
00:18:36.350 --> 00:18:40.510
the agent works with you and you get code or whatever output you requested.
291
00:18:42.190 --> 00:18:45.210
We care a lot about the uptime on the agent, but there are errors.
292
00:18:45.730 --> 00:18:48.370
And we want to be super generous for customers when there are errors.
293
00:18:48.450 --> 00:18:50.470
We assume if it's an error, it's Cursor's fault,
294
00:18:50.550 --> 00:18:52.830
we need to figure out how to make that request go through.
295
00:18:53.790 --> 00:18:57.830
So for a very long time, any error, the entire request,
296
00:18:58.310 --> 00:18:59.330
we would not charge you for it.
297
00:19:00.590 --> 00:19:02.950
Something we've been dealing with over time in both the business model,
298
00:19:03.010 --> 00:19:07.440
but also specific instances like this is agent requests used to run for like 10
299
00:19:07.650 --> 00:19:08.930
seconds. It cost 2¢ or 3¢.
300
00:19:10.670 --> 00:19:14.610
And now these models are running for 20, 30 minutes at a time.
301
00:19:14.750 --> 00:19:18.790
You can have one request cost $100.
So what we ended up seeing was,
302
00:19:19.010 --> 00:19:22.810
users would cancel requests. That sends a error message.
303
00:19:22.930 --> 00:19:25.790
We would treat it as an error. We would not charge for the request.
304
00:19:25.930 --> 00:19:29.430
And we had a whole host of users. We were looking at like cancellation,
305
00:19:29.510 --> 00:19:32.130
and like everyone right at the very end,
306
00:19:32.710 --> 00:19:34.410
the agent would produce all of this code,
307
00:19:34.930 --> 00:19:37.910
and then the user would cancel the request. They don't pay for it,
308
00:19:38.470 --> 00:19:39.303
and they keep the code.
309
00:19:39.730 --> 00:19:43.610
And this became a GitHub repos started popping up of like,
310
00:19:43.610 --> 00:19:46.950
"Here's how to defraud Cursor." And everyone started realizing how to do this,
311
00:19:49.030 --> 00:19:51.330
and we had to kill it.
312
00:19:52.010 --> 00:19:56.810
And for two days there was like riots on our forum of people who were telling
313
00:19:57.690 --> 00:20:00.910
really convincing stories around like, "This is crazy.
314
00:20:01.430 --> 00:20:02.930
I only do this every once in a while.
315
00:20:03.030 --> 00:20:07.370
I can't believe Cursor blocked this." And we actually almost pulled it back.
We
316
00:20:07.390 --> 00:20:09.650
thought we had made a mistake. We thought these were valid users.
317
00:20:10.250 --> 00:20:11.930
And then we kind of stopped and realized of like,
318
00:20:12.090 --> 00:20:16.080
someone literally would have to be at 99.9%
319
00:20:16.650 --> 00:20:19.930
utilization, know that they're there, start the request,
320
00:20:20.010 --> 00:20:23.990
and stop it on time and do that repeatedly to even know that we didn't charge
321
00:20:24.050 --> 00:20:27.510
for that request. So we were basically just getting astroturfed by bots,
322
00:20:28.190 --> 00:20:32.050
which again, maybe soured me a little bit on some of the forum,
323
00:20:32.930 --> 00:20:33.870
but it's tricky.
324
00:20:34.970 --> 00:20:38.530
No, but I think the forum's a great example. It's so easy to just like say, "Oh,
325
00:20:38.670 --> 00:20:39.670
the customers are in pain.
326
00:20:39.730 --> 00:20:43.050
I want to go help." And then you take a step back and you look and it's like,
327
00:20:43.050 --> 00:20:43.203
"Oh,
328
00:20:43.490 --> 00:20:47.610
maybe this isn't exactly what it looks like." What surprised you the most about
329
00:20:47.630 --> 00:20:48.750
the growth in the fraud space?
330
00:20:51.310 --> 00:20:53.950
And maybe particularly working at an AI company.
331
00:20:55.170 --> 00:20:57.270
Yeah. We were talking about this.
332
00:20:57.330 --> 00:21:00.610
We have a colleague who worked at Stripe and now at Cursor and he helps on both
333
00:21:00.990 --> 00:21:02.910
growth and billing and fraud.
334
00:21:03.410 --> 00:21:06.970
And I think something that's been so surprising is that you really need those
335
00:21:06.990 --> 00:21:11.670
people either doing all of it or sitting next to each other because for every
336
00:21:11.730 --> 00:21:14.630
promo, for every referral program, these trials that we run,
337
00:21:15.090 --> 00:21:19.190
you have to size it for fraud. And it basically is just a drag on efficiency,
338
00:21:20.550 --> 00:21:25.030
which is not the worst thing of like you have these inorganic growth
339
00:21:25.650 --> 00:21:27.830
levers. They just become a little more inefficient,
340
00:21:28.130 --> 00:21:32.310
which pushes you more towards what are actually the organic good ways to get
341
00:21:32.350 --> 00:21:35.970
growth? So I can implement a referral program, I can pay people money,
342
00:21:36.070 --> 00:21:40.950
I can get lit up by bots-or I can find more organic ways to give
343
00:21:40.990 --> 00:21:42.070
people opportunities to share,
344
00:21:42.450 --> 00:21:46.630
either configs for automations or MCPs or skills or setups like that
345
00:21:47.630 --> 00:21:51.490
has pushed us to be a lot more creative of beyond just giving people inference
346
00:21:51.510 --> 00:21:54.770
for free-what are other ways to drive more adoption on the platform?
347
00:21:55.810 --> 00:21:58.470
No, that makes sense. I think one of the really interesting things,
348
00:21:58.530 --> 00:22:02.370
like we work with companies in all these different industries-like when we're
349
00:22:02.390 --> 00:22:05.410
working with SaaS companies, they really just want to grow top of funnel.
350
00:22:06.030 --> 00:22:09.250
The cost of offering the service is low.
351
00:22:09.570 --> 00:22:12.990
They should just have as many sign-ups as possible, see who converts.
352
00:22:13.370 --> 00:22:17.850
And it seems just like very different for AI companies where the cost of service
353
00:22:18.410 --> 00:22:19.290
is so much different.
354
00:22:20.130 --> 00:22:22.390
I'm curious how that sort of plays into your growth strategies.
355
00:22:22.690 --> 00:22:24.430
It's like payments. I don't think
356
00:22:26.410 --> 00:22:30.570
it is very hard to sell a variable service unless you're carrying the risk.
357
00:22:30.830 --> 00:22:32.090
So we just need to be smart about it.
358
00:22:32.470 --> 00:22:36.230
No, that makes sense. I really appreciate your time. Before we close out,
359
00:22:36.430 --> 00:22:39.870
I wanted to share three practical lessons that I've learned from working with
360
00:22:39.910 --> 00:22:44.390
businesses like Cursor and helping them keep growing while managing risk. First,
361
00:22:44.730 --> 00:22:47.230
your growth strategy depends on your cost structure.
362
00:22:47.950 --> 00:22:52.090
If your cost to serve a free user is low, offering free accounts is easy.
363
00:22:52.670 --> 00:22:55.430
No need to apply the friction of collecting a card.
364
00:22:56.390 --> 00:23:00.170
If your cost of product is high, cards up front really matter.
365
00:23:00.970 --> 00:23:05.830
The real question is if the extra protection is worth the friction of requiring
366
00:23:05.870 --> 00:23:08.350
a card. Second,
367
00:23:08.750 --> 00:23:13.250
you should consider how much you actually need to offer to convert a trial user
368
00:23:13.410 --> 00:23:16.610
into a paying user. For AI companies in particular,
369
00:23:17.330 --> 00:23:21.090
anything beyond that is additional compute or services that you're kind of
370
00:23:21.150 --> 00:23:25.910
giving away for free without too much of a reason. And third,
371
00:23:26.170 --> 00:23:28.310
you should plan for abuse before your launch.
372
00:23:28.630 --> 00:23:32.730
Whether it's rolling out a new growth strategy, launching in a new region,
373
00:23:33.050 --> 00:23:34.410
launching new promotion codes,
374
00:23:34.790 --> 00:23:37.810
you should think about how it's going to get abused ahead of time and if it
375
00:23:37.850 --> 00:23:39.410
does, how you would respond.
376
00:23:41.390 --> 00:23:44.150
If you want to get ahead of the next wave of customer abuse,
377
00:23:44.410 --> 00:23:48.890
scan the QR code to join our waitlist or stop by the fraud booth in the expo
378
00:23:48.970 --> 00:23:52.070
hall. Would love to chat with you all. Thank you so much for your time.