Fintech Goes Global: The Playbook on Rapid International Expansion With Dan Westgarth, COO at Deel

Launching products across borders—especially when you manage payroll of a globally distributed employee base — requires obsessive attention to detail, deep local domain expertise, and a flexible product that can adapt to rapidly changing regulatory landscapes.

It’s no small feat, but Dan Westgarth's time helping Revolut expand to the U.S. brought a necessary skill set to Deel, where he’s led the charge to scale the product from Deel from a contractor invoicing solution to a full-fledged HR platform that seamlessly handles offsite payroll to more than 150 countries.

Below, we discuss Deel’s framework of splitting the org into “change-the-business” teams and “run-the-business” teams, why configurability is a core competency, and how a fintech-first DNA enabled .

You joined Revolut straight out of school before you ended up at Deel and the U.S. What drew your ambitions to the international stage?

As a boy from rural England, I wanted to find a venture backed business that I thought was cool. I found Revolut, which was a closed, private beta on a blog. I used the platform, loved it, and decided to reach out and ask for a job. Of course, they said no. I had to be extremely persistent with them. Eventually, they said, "You know what? Sure, come work for us. You can be a customer support agent." I packed my bags and moved to London with some friends.

My last role at Revolut was the GM of North America when we launched Revolut into the U.S. market. I had the opportunity of going to another country in another region, doing it all again for Revolut. I was introduced to Alex and Shuo, who were just starting up Deel and going through the YC process, and I thought their work was interesting. I don't know much about HR, so I thought it would be nice to combine my fintech and international experience with HR.

Let's rewind to 2018, before Deel was founded. If I was an HR manager here in the U.S., and my CTO said, "Hey, I want to build my engineering team out in Uruguay or name your country," what were my options?

Many companies hired people as contractors, both domestically and internationally. The experience was broken and disjointed, and most importantly, the contractor felt like a second-class citizen compared to full-time employees.

Deel's v1.0 one was to close that gap and give contractors tools to make the regulatory part of their role easier. That meant issuing invoices, generating tax forms, and getting paid. At that time, no one had brought in an HR element, which is what Deel did.

With Deel 2.0, we established the Employer of Record model, where we set up entities in all of these countries. We’d offer the talent a full-time employment agreement with Deel, even though they would be working for our customers. Technically, that model’s been around for decades, but it was very fragmented. They're mostly small cash flow businesses with a few big players, which have consolidated over regions and countries, but there wasn't an internet-first or a tech-first player like Deel.

Deel 3.0 was about running payroll. Our clients might set up their entity in Argentina, file with the Secretary of State, and incorporate an entity. They’d be on the hook for taxes, social security, and everything else. We’d say, "Well, we can install your entity on our payroll software, and run payroll for you."

Now, it's not a clean stop at 3.0, because after that, we added on so many different adjacent services. We're probably at 20.0 now.

What's Deel 100.0?

Payroll is at the core. From there comes onboarding, management, learning management, engagement, visas, and mobility. There are so many different services that surround HR, and if you start to plot them out on a whiteboard, it becomes complicated.

What's important is consolidating all of those things into one place, and then putting a data layer and business intelligence on top of it. That way you can see exactly where your employees are, what they're doing, how they're getting paid, and all of the adjacent HR things that are going on. Historically, HR couldn't do that, because payroll, benefits, and equipment provisioning were all fragmented systems.

Was there an early “Why now?” for a software-first product to take on this category?

Scalability. A lot of those incumbent businesses are built with a service mindset. So much of HR is manual with a human behind everything, which sets a hard ceiling for growth in these companies. Yet they’re cash flow businesses, and nobody had taken a scalable lens to this. I wouldn't say we did it by accident, but starting with the contractor payments and contractor invoicing, then progressing to EOR and payroll was quite natural.

All of the processes we've built have scalability in mind. We'll use software and AI, and some have human elements. We have a global service center of agents doing manual, repetitive tasks like data entry and data validation, which is highly scalable.

So you centralized the components these services businesses would have otherwise been doing one-offs for every client?

Yes. It’s highly repetitive work. Take healthcare enrollment data. First that data needs to be validated and then taken and entered into another system. If you have a team of people doing that 24/7, 365, you can zoom in on that process, automate it, and make it more efficient. One process, for example, was originally 100% manual. It all went through the service center. But now, we're up to 99% automation. That's the type of approach we take on all of these manual processes.

How have you productized that approach to launching a new country or region?

We have our "country configurator," which is a giant map of the world. Every country where Deel is enabled is marked in blue and over time the map has become more and more blue.

Setting up a country is highly complicated, but it's not equal. China, for example, is incredibly difficult. We had to go province-by-province in China.

In the early days of scaling internationally, there’s this trade-off between market coverage and depth of coverage. How did you decide where and when to deploy resources?

It was always driven by client demand. From there we’d look at impact vs. effort. In every country that we operate, we have common stakeholders, such as an HR person, a finance person, a payroll person, and a legal person. Sometimes they’ll split over a region, like the Balkans, where several countries have similar processes.

Is the Uber model of sending a GM to blitz a market the same one you guys take?

We delineate between the front office and the back office pretty aggressively. Anything that is done in terms of sales or marketing is run by a completely separate, centralized organization.

On the back office side, they're responsible for establishing and setting up operations, and then running them. In the back office, we delineate between the people who run-the-business and those who change-the-business.

When launching a new company. We first deploy the change-the-business folks. These are some of the smartest people I've ever worked with. They will set up the country's operations, do the initial recruitment, and then let the run-the-business folks take over. We’ll have a country leader who is looking after finance, payroll, and legal. Once that structure is set up, it runs pretty autonomously within the global guidelines the change-the-business folks have set up.

Why did you decide to set it up like this?

It keeps us focused. The lines become very blurred when you mix these two things. It's very hard to be critical about whether a process is good or not if you're actually in the weeds doing the process. Having a separate stakeholder look at the process, build the process, and optimize the process works well.

Does this draw from your prior experience of being sent from the UK to the US to scale an international company?

Yeah. I've seen many different models. When the front and back offices are connected, you need a GM in place. You might even want a local CEO, especially if the license required is a complicated one like financial services. You may need a CEO, a Chief Risk Officer, and a few others. I was never really a fan of this, because it takes much longer. I'm an advocate of splitting up the work. Get the infrastructure done and the infrastructure working, then hand it off to the run-the-business folks. Once all of that is done and working, we can start to think about how we sell, market, and capitalize on what we've built.

From a technology standpoint, is Deel the same platform that scales to every new country, just configured differently on the back end?

It is. Let's take a min and a max salary example. Some countries don’t have maximums. How it works in the new country has to be researched by the team, checked by the local council, and put into the platform. However, these parameters change over time as countries change their regulation. For example, during COVID’s high inflationary period, governments rapidly raised minimum wages. Some countries paid 13th and 14th month salaries. In Switzerland, you had two extra paychecks at the end of the year. We were able to record that over time, update our platform, and tell our clients about it, which delivered a lot of value to them.

That’s why we built Deel AI on the platform. It can be used to query regulatory changes over time by asking, "Hey, Deel, how has the minimum wage evolved in France over the last 10 years?" We have all of those data points, and we're able to give that data to our customers. We had this exclusive data set that could be accessed without AI with an old-school search function. But with AI, it can index it all and generate responses for us.

The coolest part is it combines with the client's data set. As a client, I could ask, "How many employees do I have in France?" AI would say, "You have 13." "Okay, cool. What's the most tenured employee?" "The most tenured employee is Emily." "Okay, what's her accrued vacation for this year and next year, and how is that going to evolve?" and go from there.

The next cool thing we’re building is what's called "payroll variance." It’s a horrible experience to try and figure out why one week’s paycheck is a little different than the last. We've taken every line of the payslip to see how the payslip is evolving. This is a huge, huge point of friction for most corporations around the world. Employees write into them, their tickets go onto a service desk, and when they have thousands of employees, they then need 10 people to manage that service desk, and employees get upset when they don’t get answers. So we've taken that same automation lens that we have in the back office and on the upside also in the product.

Let’s go back to your centralized customer support. How do you think about the system that supports them?

It’s a 24/7, 365 function. It doesn't stop. It works on a multilevel model, too. So first things first, we identify the type of query and send the query to the appropriate first-level group. For example, we might have a group for UK payroll, Irish HR, and so on. If the ticket is solved on the first touch, the customer is really happy. If it's not, they're generally less happy. If it goes to that second level, then it goes to the in-country team, and we’ll bring in payroll HR and finance legal experts, which takes a little bit longer. That’s why we want to have everything solved on the first level.

A lot of this comes from the fact that Deel started as a fintech-first company. We weren't HR-first. That’s why we built a really strong fintech core from the get-go, and that starts with ledgering, then compliance, transaction monitoring, KYC/AML, all of that stuff, which was there from the outset.

We’ve built some pretty cool internal services as well. My favorite is the treasury management service that pulls all of our bank accounts, transactions, and balances multiple times per day. We have over 800 bank accounts across 140 countries. We can use that to manage things like FX risk and even move liquidity around. We said to ourselves, “Why don't we just build the pipes ourselves, and then after building the pipes, we'll also build the adjacent services, which will allow us to do all the things that we need to do.”

Did you ever choose to use third-party partners? If so, where, and how did you find and evaluate them?

When we started, we built relationships with just about every major payment service provider out there, then cherry-picked the most efficient payment service provider who could get money into the countries we wanted. We were able to leverage each payment service provider for its local expertise, which meant we had a really good experience for the customer.

Say I'm a multinational company in the U.S. that has teams out in Ukraine and Brazil. I'm using you as our payroll system with entities in both of those regions. How does that work its way through your system?

The customer links their bank account using an ACH debit payment method. Then, with one click, they can fund every contract and employee on payroll. We'll pull that money in, we'll exchange it into various currencies, move it around the world, and then pay everyone on time.

What’s your approach to build versus buy?

We're big fans of build. We don't buy too much.

What pointed advice would you have for early-stage fintech companies looking to scale internationally?

Outsource as much as you can. For example, use Deel when it comes to handling HR. From there, think about effort versus impact, then the organizational design. Are you designing to solve problems, or are you just copying someone else's design? The GM model worked well for Uber, but I think it would have slowed Deel down. Your model needs to be solving the problems your business has.