Sujit Unni

Hi, everyone. Thank you for checking out the video. My name is Sujit Unni. I am the Chief Technology Officer here at Paysafe, and over the next 30 minutes, I'd like to talk you through Paysafe as an organization, how we are pivoting our business, the critical role DevOps and tooling plays in our transformation, and our choice of GitLab as a partner in our tooling journey.

I'll start with an overview of Paysafe. Paysafe is a payments platform. We, in a sense, provide both payment services and payment acceptance services to both the B2B and the B2C side of the segment. Our B2B ecosystem has close to 400,000 merchants, largely in the US, Europe, and Canada. And we process a little over $100 billion in transactions annually within the B2B part of our ecosystem.

On the B2C side of our ecosystem, we've got a digital wallets offering under the brands of Skrill and Neteller, and we've got a cash digital ecosystem, which we run under the brand of Paysafe Cash. Between the wallets and the Paysafe Cash ecosystem, we've got close to about 15 million active customers.

In terms of our geographical footprint, like I said, our B2B side of it is largely in the US, Europe, and Canada. But our B2C ecosystem actually supports close to over 120 countries all over the world, which is where these 15 million odd customers come from.

So all in all, totally global business, wide geographical spread. And as the saying goes, it's 5:00 somewhere for Paysafe at any given point. So we are, by definition, required to be a very highly available ecosystem and, just given the nature of our business, are a very data-intensive ecosystem.

As we start to look at the business going forward, what I'd like to do is give you a view of what powers our business today, just so that we ground this conversation in some kind of a baseline.

So A, at the core of our business is our dev community. We are a team of close to 1,200 developers, globally spread, very large hubs in North America, Sofia, Bulgaria, India, and Vienna, Austria. And it's these 1,200 developers that largely provide most of the functional features that we roll out across our ecosystem.

In terms of maturity, we as an organization are relatively mature to the extent that we are an agile organization, have been so for several years. Very heavily focused towards a metrics-driven measurement ecosystem so that we are constantly improving. Like I said, our agile capabilities have been fairly mature for a while. There are parts of our ecosystem where we do close to about 80-odd new feature releases every month. And we did a lot of the early growing in terms of moving our testing left and stuff like that a couple of years ago.

Now, this team of 1,200 developers largely works on a set of core platforms, about five of them, which we largely leverage to provide cross-business capabilities for the three businesses that we work in. Very much a product mindset, so we are building out product features in the construct of the three business units that I talked about: wallet features, eCash features, or payment acceptance features, which we then roll out.

And security, of course, is at the core of our business. We are, at the end of the day, a payments platform, and we're only as good as our security is. So we've had a fairly mature ecosystem around managing SAST, DAST, SCA kind of scenarios for our business.

As we start to look at the next few years, our desire is largely to continue to mature this platform primarily around two business aspects. The first is, increasingly, we want to move the organization from a product mindset to a platform mindset, largely with the intent of focusing on customer outcomes and not specific products.

So a classic example here being if I was a customer, and I want to pay a merchant, rather than give them an offering that says, "Hey, pay through your wallet," or say, "Use the eCash product to pay for it, or use your credit card," what we want to be able to do is give the customer the optionality where he can choose whatever he wants based on the channel that he's in, the moment that he's in. So if he's in the store, he can choose to use a card or he could choose to use his wallet. But our intent is very much to provide that omnichannel experience over the next several years.

The other big opportunity that we see within our business is that as we start to build this integrated platform out, we think that bringing the data and the risk aspects of our business together actually allow us to start to recognize alternate revenue streams outside of the more traditional revenue streams that we have within our businesses today.

And then, of course, underpinning this business outcome very much is our technology. And we've looked at our technology organization and said for us to be successful, there are three pillars. The first pillar, of course, is making sure that we have the right architecture, which is pretty much the classic story that most organizations are going through, where we are taking heavily siloed, monolithic technology assets and then starting to decompose them into microservices that are more modular and can be offered out independently.

The second aspect of our transformation journey is very much the automation and the tooling. To the extent that we can actually build out the right pipelines and the right degree of automation, we definitely are more agile in the market.

And the last pillar, and probably the most critical pillar, is our culture. At the end of the day, culture makes or breaks an organization, and we actually see the technology and the tooling, the tooling more so, to be very critical to defining that culture of the organization.

So the most classic example that I can give you is that the risk appetite of an organization that has the right kind of tooling, where when a change is made and put into production, should something go wrong, correcting it takes a little under two minutes to do, is very different from the risk appetite of an organization where the technology as well as the tooling is at a point where should a change be made and rolled out and should it go wrong, you could potentially put the business out for several hours or even worse, till several days. Very obviously, the risk tends to be very different in these two kind of organizations, and we believe that getting the right tooling will very much enable our culture to have the right degree of appetite for both taking risks as well as dealing with change.

And then, of course, security is never too far behind in any of these conversations. Our approach to making our business resilient as well as secure has largely been built around two pillars. The first element of it is that we very much want to get to a place where we have a multi-cloud strategy. So today, as much as we've got parts of our businesses within two public cloud providers, the long-term intent is to very much have a multi-cloud strategy just to make sure that we are also protecting ourselves against the exposure with a particular provider.

And the second element of it is very much to graduate our security offerings. Today, our security offering is still very much end of the cycle, so to say. But the desire very much is that we would like to get to a place where we think of security more from a preventative measure, i.e., identify and protect early in the cycle, as opposed to detecting and resolving later in the cycle, which makes you more reactionary. So the thought process very much, as with our testing, is that over time, we want to take all the security aspects of our business and continue to shift left and move them as close to the design and build aspects as possible.

And the hunt very much was for such a tool. So as we started to look at our tooling, we looked at it largely across a couple of areas. One, like I said, is that we wanted to make sure that we got a tool that supports our multi-cloud strategy. We wanted a toolset that we knew could support our long-term aspirations in terms of where we want to take our security capabilities. And then, of course, to my point earlier, very heavy focus on making sure that we choose a tool that drives the right kind of automation that enables a culture that we aspire for.

Now, given that long list of items and the tall order, we started our journey largely from a position where, okay, what is it that we are struggling with today? And again, I think this will resonate with pretty much all of you. I think most organizations have seen some of these limitations or opportunities no different than we have.

So as with most organizations, I think the lack of standardization within our very complex landscape was a cause of concern. I mean, our tooling wasn't ineffective. I just think it wasn't as effective as it could be. So we do have tooling, and we do have the kind of automation that allows us to be reasonably agile. But for us to really break ground and hit that J curve, we think it required a fair degree of uplift.

So I think standardization was one area where when we did our inventory, we had close to almost 2,000 pipelines with varying flavors of maturity. So there was very much a need to say, look, if you want to run an integrated platform, we've got to standardize the tooling, which means that we've got to take these 2,000-odd flavors of pipelines that we have and whittle them down to a core set that would actually allow us to scale, improve the fungibility, and the cross-functional assignment of our resources. And to that extent, that became a pretty critical ask in terms of any tool that we went with.

The second element of it that was very key to us, just given the fact that we are a very metrics-driven organization: we're pretty ruthless. We measure, and we constantly improve. We wanted a toolset that would actually give us the kind of insights that would allow us to measure our productivity or effectiveness, and then, of course, allow us to mature over time.

Again, we had some of that, but a lot of it was massively manual. There's a lot of work going around. There is a little cottage industry that we've got in place that largely takes all these metrics from these various tool sets that we have, puts it together, and then starts to draw out insight. Our intent was to actually, again, make that as intuitive on the platform to the extent as possible that teams can start to consume it on their own, and then start to improve or almost create that self-generated desire to improve. So that was another key pillar.

The third pillar, which again was pretty critical to us, was just the ability to be able to automate our auditing and our compliance asks. As with most organizations, we've got software development policies, we've got compliance asks that we need to adhere to. And for most parts, a lot of that control and check ecosystem is either manual or happens through after-the-fact sweep or audits and stuff like that.

The intent, again, was to almost embed a lot of these policy adherence and compliance asks into our tooling to the extent that if teams find out early, they're using it, and they're almost running the entire ecosystem more through a lens of preventing variances, more so than the current culture of having to go and do an audit, find the outliers, do the findings, come back, and do remediation work. So that was a pretty key element of our desire to find the right tool set.

And then, of course, like I said earlier, over time, the intent very much was to start to shift left a lot of our security asks. So those are the broad asks. Again, I think a lot of these are very common in a lot of organizations, so I don't think we were unique to that extent.

Given that ask, how did we go about it? We actually started at the top of the house where we were very clear in terms of what is the outcomes that we wanted our target tool set to drive. Kind of a combination of both the development team insights and asks, as well as bringing in some industry views from known repositories like Gartner and Forrester to actually put together a scoring template. We identified five potential choices in the market, and then, of course, ran a pretty extensive proof of value across these five tool sets before we decided to take our pick.

We eventually went with GitLab, largely owing to the fact that it had the most functionally enabled value set that we wanted. But more importantly, at least to me, a large part of our decision with GitLab also was the strong sense of partnership that the team brought.

Because as you can imagine, migrating from one tool set to another tool set takes anywhere between six months and a year. And as you start to do this, as much as the teams are putting in the effort to migrate away from a particular tool set, there's an element of a bubble cost that a lot of organizations need to deal with.

In our case, GitLab actually came to the table, understood our current ecosystem, the kind of contracts and commitments that we had with the incumbents, and then actually worked with us in a very collaborative manner to make sure that we had a commercial value proposition that worked for both sides. To the extent that it didn't overly penalize my budget, but at the same time, also gave GitLab enough value in the deal to the point where they engaged with us and we made sure that we had a very pragmatic implementation plan as we started this journey.

So I think the partnership element probably stands out more to me than anything else. Like I said, the tool is definitely well-positioned functionally and in terms of its roadmap also is, I would say, fairly future-proof. But what tipped the scale in GitLab's favor for us was also the sense of partnership. So I just want to make sure that we don't dilute that element or the relevance of that element in our decision-making process.

So as we started this journey, what does the first phase look like? First phase, of course, is very much what we think is the low-hanging fruit, the benefits view that largely underpinned our business case. And I've talked of some of these things earlier.

At the very left end of the spectrum, we are looking to standardize our CI/CD pipelines. Today, we've got close to about 2,000 varying flavors of our pipelines. We are looking to actually consolidate that onto a core set. We expect anywhere between an 8 and a 13% improvement in productivity from existing teams just through that standardization.

Part of this is very much, as we are starting to do this, we are also templatizing our CI/CD pipeline. So when you go back and look at an organization like ours that's in a hypergrowth mode, we are constantly bringing on and growing the team. And one critical element: growing a team is easy, in the sense that it's not so much about getting people in, but it's the element of the new people that you bring in, how many of them are truly productive, and how soon can they get productive?

And one of the things that we found out is that our ability to make a team productive is more enhanced when we start to templatize a lot of the tooling. And to that extent, I think that's the second value proposition that we are hoping GitLab will put in place for us. Like I said, the reuse of the pipelines out of the box, combination of the tool set, and our approach itself, we think that the core set of templates that we're going to land at will largely future-proof us for the next several years in terms of how we continue to roll our platform out.

We spoke about the automation. Again, we are in the midst of our move to the cloud. We've got a very large part of our business in the cloud. We've got smaller legacy pieces that are still sitting on-prem that we are looking to move within the cloud construct. We've got two public cloud providers that we partner with for our business services. Again, the hunt was very much for a tool set that could actually span this scenario: support us in our diminishing on-prem footprint, but also then continue to effectively support us across our two cloud providers, very much with the intent of saying that at some point we would be multi-cloud. So we weren't looking to put the organizations through the transformation of having to move across their tooling at the same time. So I think GitLab insulated us from that exposure.

And then, of course, I've spoken about the other two, which is that as we start to do this, very heavy focus on ensuring that we've got the right controls within the tool set that make sure that teams are adhering to our broader software development policies and procedures. So I think getting those five items sorted out over the next two months or three months gives us that base camp in terms of the core benefits that underpin our business case.

And then I think comes the extra lift that we are hoping to bring in with GitLab. Again, in no particular order, but starting on the left, I think once we've got to base camp with our automation in terms of standardizing the tool sets, making sure that we've got the right automation around controls and adherence to policies, we intend to pick up the shift-left element of our security features. Which is, what we want to do is start to bring security increasingly closer to the design and build phase. That would be, I would say, phase two for us.

And then, of course, finally phase three, which is where we are hoping that the metrics gathering that we are hoping to do out of this tool set really powers our measure and improve ecosystem. We, as an organization, have traditionally been very focused around constantly measuring and improving. But the overhead in terms of getting that measure today is pretty high. What we are hoping is this becomes a lot more intuitive and centric to the tool set. So to that extent, there isn't this body sitting out there that's taking all this data, drawing the insight, giving it back to the teams for them to then start to put together their improvement measures. We want this to be served up to the teams directly through the tool set, and to that extent, every team owns its own destiny. It's constantly measuring itself and improving itself, both in construct of what they are doing as well as in comparison to their peer set. And that, in my mind, brings us to a place where we've got a tool that's humming.

I'll move on in terms of what the benefits are. Definitely short-term benefits. And I've touched on bits and pieces of this over the past several slides.

At the very left end of the spectrum, I think getting the right tool set put in place just increases a sense of ownership with the teams. Today, in our ecosystem, we've got a tool set that, while working, just doesn't give developers the kind of visibility that they would like within the build process, doesn't give them the kind of insight. They're waiting on somebody else to give them the insight. Here, I think since it's all being served up in the tool to the teams, it'll drive a much stronger sense of ownership as well as a stronger desire to continuously improve. So to that extent, I think it definitely builds to a more self-sufficient organization.

I would say it's a natural byproduct, but the better that our tooling and our automation gets, especially around the audit elements, the adherence to our SDLC, the quality of code obviously starts to improve. And to that extent, we start to see metrics like elements around rework and things like that start to substantially improve.

Increase in audit and compliance checks. Like I said, like most organizations, we've got a little ecosystem that actually almost supports our development ecosystem that's very focused around the right audits and the compliance checks. To the extent that we can start to bring this and make it more integral to the tool, that overhead goes away, improving both agility as well as there's an efficiency element for the organization in terms of not having to do that manually.

And then, of course, the last one is very much almost a byproduct of the other items, which is that to the extent that we get the first three items solved, we definitely become a more efficient ecosystem. And as part of our business case, we have underpinned our investment with a certain committed productivity improvement that we are hoping to deliver.

These, I think, are the more short-term elements. As with everything else, there is a long-term element, which is that this, in conjunction with our wider architectural transformation that's happening, in a sense, puts us in a better place.

A, I think a combination of our microservices architecture, the right tooling, we will be able to deliver stuff to our business faster, and we're already starting to see it. Over the last several weeks, we've seen multiple instances where we've taken the sheer breadth of our releases from 10 or 15 apps every release to about 30 apps every release. So we will launch products to market faster. We think the sheer number of releases that we are going to do will go up. We will see marked improvement in our mean time to recovery. So everything that suggests that an organization can move at pace.

Secondly, I think culturally, we get to be in a better place, too. At the end of the day, one of the biggest friction points in the organization today, particularly the dev teams, is the sheer overhead of having to manage this heavily fragmented ecosystem and all the inefficiencies that come with it. To the extent that we are able to streamline the tooling and automation, we definitely provide a better work environment for our teams to be more effective. And to that extent, it can only help the culture of the organization.

And the last element is better. Again, as security gets more and more threaded into our ecosystem, we are inherently building out a safer value offering for our customers as well as our employees. And more importantly, just given the fact that we are making the entire development process much, much more integrated around a single tool set, we are also hoping to be an efficient organization.

I'll stop briefly there. I don't think I had anything else. But hopefully, that gave you some kind of a view into just what we as an organization do, how critical getting the right tooling is to us, especially with regards to the right culture. And then, of course, a high-level view of what kind of benefits we are hoping to see. A lot more to cover, but feel free to reach out to me or anyone on my team. We're quite happy to answer questions. If nothing else, share war stories in terms of what's worked for us and what's not. Thanks for your time.