When we started R2, the question we couldn't answer was deceptively simple: if you look at a small business's transaction history from their digital sales, what does it actually signal about their credit risk and willingness to pay back a loan?
We had a hypothesis that there were indeed useful credit signals in this data. Most of what we've built since then is the work of proving that hypothesis, and then building systems - the credit infrastructure - that could act on these signals at the scale Latin America actually requires.
The Two Sources That Were Never Going to Work
Every lender in this region - traditional financial institution or fintech - was relying on the same 2 sources of data for underwriting: financial statements and/or credit bureau history. They're the inputs the industry is predicated on. But they have a structural problem.
Financial statements are produced annually, aggregated, and backward-looking. For a small business navigating new challenges, managing cash week to week, surviving a slow month, restocking before a high season, a document prepared by an accountant with a single number about the last 12 months tells you very little about where that business is today.
Credit bureau history is just as unhelpful - but in a different way. A huge share of small businesses in Latin America have never had a formal loan. So there’s no repayment history - their credit file is thin at best, or nonexistent. Any score is therefore unreliable. It becomes a vicious cycle that precisely excludes the businesses that most need access to capital, and it does so without anyone ever asking a meaningful question about the day-to-day operations and cash flow generation of the business itself.
My co-founder Roger Larach and I kept coming back to the same question: what if the real signal wasn't in a financial statement at all? What if they operational activity was already being recorded, every single day, in the transactions captured by payment systems?
The First Credit Decision We Ever Made
We tested our hypothesis for the first time without a credit model, without an API-based integration, and without hard data.
The business was a small business selling health supplements through a payment processor in Mexico. We weren't yet connected to the platform to pull data automatically. So we picked up the phone, called the owner on WhatsApp, and asked her a couple of basic questions while she was driving to work:
- How much, on average, do you sell each week?
- How many sales do you process each day with this payment provider?
- Have you been using the processor more or less in the last few months?
- How long have you been using this platform to receive card payments?
- What do you need the capital for?
We knew we'd be able to check every answer against the platform's records once we had access. That verifyability changed how we weighed the conversation. That's also why we've never offered credit based on self-reported numbers or sent directly by the merchant. Anyone can ultimately edit a spreadsheet or financial report. The platform's transaction records - received directly via API - can't be edited by the interested party.
That first loan was successfully repaid. It worked because the logic was sound: someone with a consistent, verifiable transaction history was a good bet riskwise, and this data provided a more realistic view than any static document would suggest. With a bit of technology and AI, we’ve managed to scale this logic to confidently underwrite millions of small businesses each month.
The Signal That Changed How We Think About Risk
Once we were ingesting real-time transaction data at scale, some patterns emerged that didn't match what classical credit training would predict.
Take two merchants with the same monthly revenue, and therefore the same capacity to pay back R2. One gets there through 150 transactions spread fairly evenly across the month, five to six sales a day, most days of the week. The other hits the same number with two or three large tickets. A traditional credit analysis may treat them as equivalent. Our models don't, and our performance data over the last 4 years backs this up.
The merchant with 150 transactions is behaviorally tied to this platform. Their relationship with the platform is operationally sticky. Their on-platform cash flow is predictable. When I look at their recent history, I can therefore make a fairly confident forecast about where their sales will be in 30, 60, 90 and 120 days. The merchant with 3 transactions has real revenue, but it's sporadic. Predicting their next quarter is statistically harder.
The broader pattern held up across our portfolio: a small, often informal, business with modest but consistent sales is counterintuitively a better credit risk than a larger, more formal one with erratic sales. Size doesn't protect you. Consistency does. That wasn't an assumption we had upfront. But it was an important paradigm shift we found naturally through data data, and it completely reshaped how we build credit offers today.
What You Miss When You Only Look Once
Observing a business's transactions at the moment they apply for credit is definitely better than reading a stale financial statement. But it's still a snapshot. You're seeing what the business looks like up to a point in time.
Continuous observation is different. When you're watching transaction flows over time, you start to see the shape of a business, its seasonality, whether it's growing or contracting, how it responded to an external shock three months ago. That information changes not just whether to approve, but how much to offer and when.
Getting the size of an offer right matters as much as the approval itself. A merchant who receives more capital than their on-platform cash flow can support isn't better off – they're unwittingly locked into a repayment cycle that burdens them operationally. The same logic applies, even more noticeably, when you move from merchants to independent workers. A driver or delivery courier has a ceiling that a small business merchant doesn't in terms of the hours in a day they can work. A business can reinvest working capital to grow and their transaction volume expands. A worker who receives a cash advance doesn't have that ability. If the advance is significantly bigger than their short-term need, the risk is that they treat it as some temporary income bridge, and pull back their activity on platform activity. Given our significant experience across all types of platforms in 5 markets, it’s precisely the type of unintended behavior we know how to minimize.
We also kept watching after the capital was disbursed. What happens to a business's sales after they receive working capital is one of the most critical real-time signals we track. In a lot of cases, you see a measurable jump – they bought more inventory, opened a second location, launched a marketing campaign, hired somebody. That post-credit behavior goes directly into how we design the next credit offer. The model learns from what the business owner did with the capital, and how fast, not just from whether it came back, allowing us to proactively retarget them right when they need it again.
What a Competitor With the Same Data Would Still Be Missing
People sometimes assume that if someone else had access to the same transaction data we do, they'd be able to replicate the results. I've heard this from some of the investors we’ve had, from potential partners, occasionally from people who want to believe the gap is smaller than it is.
The assumption misses something important. The models that predict credit behavior are trained on repayment data. You only get repayment data by extending credit. And early on, extending credit means you will lend to businesses that don’t pay you back, because you don't know enough yet to avoid them. This is the price of building a useful model in a risky segment where no prior data existed. We paid it early on, across various markets and in every vertical or new platform type we worked with.
Beyond the models themselves, you have to be able to process billions of transactions from some of the largest platforms. We process more than 10 billion transactions each month across five markets, each with different data structure, different definitions of what a transaction even is, and different distributions in the data. Making that data clean enough and consistent enough to learn from is a data engineering challenge that takes years of sustained investment to get right. It's not glamorous. It's also not something you inherit by getting access to a data set.
Then there's fraud. Latin America has fraud rates 2x-3x higher than the US. The fraud patterns evolve. Building underwriting that's accurate on legitimate merchants while staying resistant to fraudsters that change over time is a specialized capability. A new entrant with good data still has to develop that capability from scratch. And be able to capture unusual behavior split seconds before money is disbursed.
These are hard earned capabilities that compound over time.
Before the Models
The hardest version of the problem I just described is the cold start: a new market, a new vertical, a new partner type, with no local repayment history to train on.
When we first started, we solved it the hard way. I sat alongside Julián Miranda, our first data science hire and now Director of Data Science & Machine Learning, and Miki Inoue, who led credit analytics from the early days, now VP of Credit, and we manually reviewed 6,000 merchants’ activity. It took a few weeks to go through it. Each of us scored each merchant independently: would we lend to this business based on the transactional patterns displayed on the screen, “yes” or “no”? We combined our votes and used those results as target variables to train the first machine learning model. We essentially codified our expert judgement and let statistical learning approaches tell us what features in the data actually mattered before we had any scaled understanding of actual loan repayment.
That model had obvious limitations. But it gave us a starting point to work with, and as repayment data accumulated over the following months, we iterated. Today we have base predictive models trained across five countries and all kinds of platform types, making it much easier to fine-tune models given new contexts rather than rebuild each time from scratch.
What a Partner's Data Actually Tells You
When we evaluate a potential partnership, the first thing we ask for is a representative sample of transaction data. What's in that sample provides substantial context that we can then complement in a conversation with prospective partners to understand the texture of their ecosystem and the size of the opportunity.
What we like to see: a relevant number of active merchants transacting consistently throughout the month, behavioral variety across different types of businesses, and dollar volume distributed across many participants rather than concentrated in a few, massive accounts.
The yellow flag that's come up at this stage is platforms with impressive headline numbers that, on closer inspection, are driven almost entirely by five or ten large corporate merchants, which are not a good fit for us. Those large companies already have access to commercial credit through traditional channels.
Providing credit through R2 is designed to be fast - that's an important point of embedded lending. The outcome of any capital program, though, depends on one thing we can't substitute: the quality of the data the platform already has. Robust, transaction-level data from an active and varied merchant base is what enables the model to discriminate between good potential borrowers vs bad ones. When that data and technological foundation is there, the integration with a partner works well from the start. We can scale lending to its potential. When it isn't, no amount of model sophistication fixes it.
That's why our evaluation of a new partner isn't only commercial or technical. It’s also analytical. We're asking who their merchants are, what their behavior looks like, and how the platform thinks about the relationship with its user base.
What Generative AI Actually Changed for Us
Our core underwriting models haven't changed substantially because of generative AI. Our models work with structured transactional data, and focus on a discriminative task, which is a different problem from what generative foundation models were designed for.
Where the change has been more useful is for internal productivity, such as adapting and generalizing data pipelines from one market to another, which now takes a fraction of the time it used to. Technical documentation, which was always the first thing to get deprioritized in a startup when the team was heads-down, now gets done by default. And data engineers and data scientists on the team can build internal tools and UI interfaces without depending on software engineers for it. As such, the team's output definitely accelerated in the last year without the team getting substantially bigger.
What won't automate, I think, is the judgment that context about a small business requires. When a merchant's sales drop in October, the model picks it up. But the question of why seasonal, local economic events, product problems, platform issues, sometimes has a data answer and sometimes requires a quick conversation with the partner. Knowing which is which, and what to do once you know, is still human driven.