Essay  ·  May 2026

How I Accidentally Became a Fraud Expert

A story involving pandas, hangovers, and Indonesia

By Vivek Ahuja

Let me be clear upfront: I had absolutely no business working in fraud.

In the summer of 2015, I was a 29-year-old ex-nuclear submarine officer with an MBA, a brief internship at The North Face, and approximately zero meaningful experience in technology, startups, or financial crime. What I did have was a co-founding role at a tiny payments startup called Xendit, some funding from Y Combinator and a free desk at UC-Berkeley Skydeck, and (as it would turn out) a fraud problem that was completely out of control.

I also had about $50,000 to my name and $100,000 in MBA student debt.

I want to be specific about that last part, because it matters for understanding everything that follows. I had gone to the Naval Academy and then to Haas. On paper, those are impressive credentials. In practice, neither comes with a financial cushion. While my MBA classmates were accepting offers from McKinsey, BCG, Bain, Facebook, and Goldman Sachs (and I'll be honest, I wasn't exactly being chased by those firms either; my interview skills and resume were not my strongest assets coming out of business school), I had chosen to co-found a startup instead.

There was no lifeboat. If Xendit didn't work, I had a modest net worth, six figures of debt, and a resume that didn't scream "hire me immediately."

My entrepreneurship professors at Haas, Toby Stuart and the late Rob Chandra, had done their best to prepare me for what building a company actually feels like: the uncertainty, the loneliness, the gap between the founder narrative you tell in public and the reality you experience in private. They were right about most of it. None of their frameworks, however, covered the specific scenario of "your fraud rate is 30% and you have no idea what to do about it."

This is the story of how that summer accidentally set the course for the next decade of my career. I'm telling it now because it only makes sense in hindsight, and because I think it might be useful for other people who find themselves staring at an ambiguous problem with no roadmap, no network, no domain expertise, and no safety net.

Which, if you're early in your career or transitioning from the military into tech, might sound familiar.

The Setup: Bitcoin, Indonesia, and 30% Fraud

Xendit started as a remittances company using Bitcoin rails. Then we pivoted into something closer to "Venmo for Indonesia." (aside, now it's more like Stripe in Indo)

The pivot made intuitive sense. Indonesia is a massive, largely unbanked market with a real need for peer-to-peer payments infrastructure. What we hadn't fully accounted for was that when you build something people actually want to use, when your product starts going viral, you also attract people who want to exploit it.

We started seeing fraud almost immediately. And I mean a lot of fraud.

Here's how unsophisticated our fraud detection was at the time: we used Google Analytics data about unique devices versus account counts to estimate our fraud rate. Our back-of-the-envelope math suggested approximately 30% of our transactions were fraudulent.

Thirty percent.

For context, a fraud rate above 1-2% in payments is considered a serious problem. We were sitting at 30% with a methodology that involved Google Analytics and optimism.

The good news was 1. that the bar for improvement was extremely low, and 2. I was so naive that I had no idea how terrible this was.

What 30% Fraud Actually Feels Like in Your Body

Here is what the business school case studies don't tell you about being a first-time founder with no safety net facing an existential problem you have no training to solve:

Your body stops working properly.

By the time we were deep into YC that summer, I was operating in a more or less permanent state of fight-or-flight. I couldn't sleep well. I couldn't relax. I experienced sexual dysfunction. I had no ability to mentally leave the problem. It followed me into every waking moment and most sleeping ones.

A doctor, presented with that constellation of symptoms, would have recognized it immediately as chronic stress, the kind that comes from sustained cortisol overload, from a nervous system that has been running red for so long it forgets how to idle.

I didn't see a doctor. I just kept working.

Almost every founder I've spoken to has been there. Almost none of them talk about it.

I'm mentioning this not for sympathy, and definitely not for drama. I'm mentioning it because I have since spoken to enough founders, especially veterans who are culturally trained to project toughness and treat stress as weakness, to know that this experience is nearly universal and almost never discussed. If you are in the middle of something hard right now and your body is sending signals you don't have the vocabulary for: this is normal, it has a name, and you are not alone.

Okay. Back to the fraud.

First Principles From Someone With No Principles (Of Fraud Detection)

The problem was that I had no idea where to start.

It was 2015. The identity verification and fraud prevention infrastructure that exists today, the vendor ecosystem, the academic literature, the practitioner communities, was far less developed. And even if it had been, I didn't have the network to access it. I hadn't worked in tech before. I hadn't worked in fraud before. I hadn't really worked in startups before. My most relevant prior experience was operating a nuclear submarine, which, while genuinely useful for developing a tolerance for high-stakes ambiguity, doesn't come with a lot of transferable fraud detection frameworks.

I did what any reasonable person in my position would do: I started taking sales calls with vendors.

I remember getting on the phone with Jumio and LexisNexis that summer, trying to understand what identity verification technology even existed.

The irony of this is almost too good: Jumio, one of the pioneers of the IDV space, went bankrupt a few years later, having mistimed what should have been a generational opportunity (it's still around, btw). And LexisNexis was and is still today a multi-billion dollar data behemoth deeply embedded in the fraud and risk infrastructure of essentially every major financial institution in the country.

I took both calls. I implemented neither product. Mostly because I didn't really understand what they were selling, and I definitely didn't have any budget (I think "YC Discounts" only existed for AWS at the time).

So I went back to first principles. Which, when you don't have any domain knowledge, basically means: stare at the problem until something occurs to you.

The MBA Class That Accidentally Became My Fraud Framework

Something did occur to me.

I thought back to a class I had taken during my MBA at UC Berkeley called, of all things, Social Media Marketing, taught by Professor Zsolt Katona. In that class, I had learned about link analysis and graph databases: the idea that you could map relationships between entities to surface hidden patterns and connections.

It's a concept that powers everything from Facebook's friend recommendations to law enforcement's organized crime investigations. Professor Katona had taught it in the context of Instagram influencers. I was about to apply it to financial crime.

But staring at our fraudulent account data in Google Sheets, something clicked. Fraudsters, almost by definition, reuse things. They reuse phone numbers, email addresses, device IDs, IP addresses. A single fraudster operating at scale looks, in data, like a hub with many spokes: multiple fake accounts all connected by shared attributes.

I started manually building what was essentially a graph in Google Sheets. My working definition of risk became: "same common attribute across two or more unique profiles." If three accounts shared a phone number, that cluster was suspicious. If five accounts shared a device ID, that cluster was very suspicious.

It was not sophisticated. It was not automated. It was me, a laptop, and a spreadsheet, trying to reverse-engineer financial crime with tools designed for tracking household budgets.

But it worked. Well enough, anyway.

The Hungover Pandas Incident

Around this time I went to a wedding in Seattle for my friends Elizabeth and Kurt.

At the wedding was a friend named Otto Stegmaier, a fellow veteran and a genuinely kind and technically gifted person who listened to me ramble about my startup over what I'm sure were several drinks. Remember: I was running on chronic stress and cortisol at this point. I was probably not exactly a great wedding guest.

The morning after the wedding, both of us very hungover, Otto sat down with my laptop and spent a few hours setting me up with Anaconda, IPython notebooks, and a set of pandas cookbooks.

If you're not a data person: pandas is a Python library for data manipulation and analysis. It is extremely powerful. It is also, for a non-technical person encountering it for the first time while mildly hungover, extremely indtimidating.

Otto walked me through the basics with patience and the good humor of someone who understood that what I really needed was not a data science degree but just enough capability to stop drowning.

I cannot overstate how important that hungover Saturday morning was for my career.

The Transpacific Flight Where I Became (Barely) Technical

Shortly after the wedding, I had to fly to Indonesia for Xendit business.

It is a long flight. San Francisco to Jakarta with a connection is somewhere in the neighborhood of 20+ hours of total travel time.

I spent most of it completing seven or eight pandas cookbooks.

This is a funnier image if you picture the physical reality of it: a sleep-deprived, chronically stressed, financially precarious 29-year-old, wedged into an economy seat on Korean Airlines over the Pacific, desperately working through Python tutorials and cursing about basic syntax errors while the person next to him watched movies.

By the time I landed in Jakarta, I had a working, if rudimentary, understanding of how to manipulate large datasets in Python. I could filter. I could group. I could merge. I could not yet do anything that would impress an actual data scientist, but I could do enough to be dangerous in the specific context of our fraud problem.

In the midst of those same transpacific flights, I also leaned on Juan Gonzalez, one of Xendit's co-founders, to teach me the basics of MongoDB queries so I could pull my own data without having to beg an engineer every time I needed to look at something.

A few weeks later I had self-implemented two things that I didn't even have names for at the time:

First: A recurring process (not automated, because I didn't know how to write cron jobs, so I ran it manually every morning) that surfaced the riskiest clusters of accounts for review and shutdown based on my shared-attribute graph logic.

Second: A basic decision tree for identity verification requirements on high-risk accounts. If an account tripped certain signals, it got routed to a manual review queue with specific document requirements.

These were the bones of what the industry would later call application fraud detection and identity verification workflows.

I just called it "the thing I run manually every day so we don't get all the VC's money stolen by Indonesian criminals."

The Interview That Changed Everything

That fall, I parted ways with Xendit just before YC Demo Day. That's a story for another time, or possibly never, depending on how the statute of limitations on awkwardness between friends works.

But I had a story to tell. And surprisingly, it turned out to be a story people wanted to hear.

I got connected to Affirm through a Xendit advisor named Phil Inghelbrecht. Affirm at the time was a fast-growing buy-now-pay-later lender that cared deeply about fraud and credit risk, which made sense, because their business model depended on not getting destroyed by bad actors.

In my interview, I told the Xendit story. The 30% fraud rate. The Google Analytics methodology. The graph logic in Google Sheets. The pandas cookbooks on the transpacific flight. The manually-run Python scripts.

I'm sure I came across as a combination of naive, scrappy, and slightly unhinged.

The risk team, a small group of around four to six people, apparently found this combination either entertaining or compelling enough to prod one of Affirm's co-founders that they make me a job offer with the inventive and non-MBA-like title of "Lead Fraud Fighter."

I did not know, at the time, that two of the people who interviewed me, Naftali Harris and Max Blumenfeld, would go on to found SentiLink, which would become one of the most important companies in the synthetic identity fraud space. I also did not know that they would spend the next couple of years teaching me SQL, Unix shell scripting, and Python, and that I would eventually spend six years working with them at the company they built.

I also did not know, and this is perhaps my favorite piece of trivia from this entire story, that I had technically already encountered Max Levchin, Affirm's co-founder, years earlier. He had spoken at UC Berkeley's engineering school while I was in grad school there. My co-founders Bo and Juan had dragged me along to the talk. I vaguely remembered a smart person saying smart things and that he loved data analytics. I had not retained his name.

The man whose company I was now joining to fight fraud: someone I'd once watched speak without knowing who he was or that he started PayPal a decade or so prior.

The identity verification industry is, it turns out, a very small world.

What I Know Now That I Didn't Know Then