‘We are the railway network that moves data from one site to the next’: Argyle’s Audrius Zujus
- Building secure fintech solutions is no easy feat -- you can't afford to move fast and break things.
- Argyle's founder and CTO explores the challenges and opportunities in scaling a firm focused on financial data from employers.

The following was produced by Tearsheet Studios. We worked with employment data platform Argyle to create a podcast series about the rising importance of employment data and how lenders, banks and fintechs are using this data to make financial products available to more people, solving some of the challenges with today’s financial services. You can access the first interview with Argyle CEO Shmulik Fishman here.
A fintech CTO’s job is wide and varied. Building a secure fintech solution that handles sensitive financial and employment data requires you to tread carefully. You can’t really move fast and break things. It gets really interesting when you imagine the challenge of getting at employment data, for example, requires building new tools on top of legacy tech stacks that weren’t built with modern fintech requirements in mind.
Audrius Zujus: My name is Audrius, and I'm a CTO at Argyle. I pretty much write Slack messages and emails all day long. And when it comes to the other side of my job, I guide and help my great team to guide the platform we’re building, and try to grow the team as best as I can.
Subscribe: Apple Podcasts I SoundCloud I Spotify I Google Podcasts
The following excerpts were edited for clarity.
From building scalable databases to yes -- writing emails and Slack messages -- fintech CTOs are tasked with big responsibilities. It can help when they have diverse backgrounds, building tech solutions in various industries. It even helps hone their communication skills.
Audrius Zujus: I started in consulting, so I guess I did start writing emails and Slack messages, way before Slack actually. I worked at Deloitte Digital, and I was a developer there. I worked on a lot of open banking projects, which is a similar feel to what we do, just in another industry. I had a very interesting long, winding road before ending up working on employment data. I essentially went through leaving Deloitte, starting my own VR startup that ended up not going anywhere, but I ended up selling the technology I had for one of the largest defense contractors in Europe. Then I worked in the field of defense for almost five years, primarily with simulation technologies. After a while I was ready to get back into fintech, and started contracting as a technology vp for hire. That's how I met Shmulik. We met while working online, and he had some interesting, crazy ideas that sounded way too simple at the beginning. We started building and here we are, three years later.
It’s not uncommon for tech professionals to move back and forth between various industries. That’s Audrius’ story with defense contracting. It makes sense. Some of the same skill sets and technologies -- like big data and aggregating data across various sources -- are employed in both industries. Some of the same challenges exist, too.
Audrius Zujus: There's actually a surprising number of people that went back and forth between defense and fintech. If you look at the history of those two fields, they're somewhat intertwined. For myself, in my experience in Deloitte with open banking and all the other digital banking sectors, it was actually something I enjoyed. And one of the things I missed in the defense sector was the speed at which things are going. It's a very interesting area of work, however it is at times pretty slow and outdated -- product life cycles are counted in decades or more. I really missed that fast-moving environment, and here I got what I wanted -- we ended up needing to build something that's really fast-moving.
Fintech frequently means building modern apps on top of aged, legacy technology. This approach may be easier than ripping out decades-old tech stacks, but it limits some of the things you can do. You have to write so much code just to manage someone else’s tech.
Audrius Zujus: In this type of fintech, especially at Argyle, the analogy I use is this: we are building a castle, on top of stilts that are leaning against boats in the sea. We're building our platform and infrastructure on some other people's infrastructure, which we don't control. And we integrate with them and have to do our best to make sure those stilts, those connectors, are as stable as can be to make sure the castle floats on top. It’s a really interesting technical challenge, because you end up having to write a lot of proprietary IP that helps you manage those under liabilities that are inherently there, because it's other people's code. People who work in banking and open banking definitely know the feels for this.
Building the castle that Audrius describes is just the beginning. Argyle’s building an employment data platform and that means integrating with a lot of businesses and payroll processors. A lot of them.
SPONSORED
Audrius Zujus: The scope is definitely the bit of the iceberg that’s under the water. When you look at this industry from the top view you won’t see why it's hard, until you get down into the details. Every business in the United States files taxes and has employment data, and they probably use one of the many thousands of providers that allow them to do that. The large portion of those use large platforms, but there's a really long tail of these small businesses that have their own SaaS solutions to let people hire people. When we integrate with these platforms, we have to cover pretty much everything -- we're talking about tens of thousands of potential integrations to get to 90 percent coverage of the market. And some of those have APIs, and some of those actually have websites that say ‘Copyright 2007’. So there's really a varying degree of technical prowess in those systems.
It’s not just the sheer number of nodes that makes building an employment data platform a massive undertaking -- it’s also the data. Employment data is messier than bank data, which has had years of efforts to standardize it.
Audrius Zujus: When it comes to the data itself, if you look at the bank statement data, it's actually easy to work with. I'm jealous of companies that integrate financial institutions, because they only have bank statements and investment products, where we're actually dealing with multi-year work histories. Because we don't only look at payments, but also at potential information such as shifts, gig work, trips -- so on average, we can sometimes have up to 300 megabytes worth of text data alone, per user. This really ups the game when it comes to building scalable infrastructure. We can't play with the same types of databases most people play with. It’s big data in the true sense of the word.
Financial data aggregation is about building the rails that data moves back and forth. Opening up employment data, like the moves afoot with banking data, is intended to empower the user. It’s about giving people the control over their information.
Audrius Zujus: This is something that people often get wrong -- we are not like some of the big, Equifax-like providers that just buy up and have all the data. We are the railway network that moves data from one site to another. From a technical perspective, our clients are companies who ask their clients -- people -- to share their financial data; we move that data, take it out, package it up nicely in little boxes that the company can retrieve through our API, and we move across the railway to give it to the company. If the user decides they no longer want to share that, they can just remove the connection, and we remove all the data at that same second. Every bit of data we move is user-controlled. The person who decided to give their permission for the company to see their data is always in control. I think this is not only a good thing to do, this is just the way the world works now. You look at the GDPR and CCPA against what’s right at the moment and right for the industry, and this is the logical conclusion -- people own their own data, they need to be able to utilize it, and we're just the means for doing that.
Open banking, or open finance if you want to include employment data in the mix, is still in its early innings. Europe and the U.S. have diverged in their approaches to creating ecosystems, but one thing is common to both markets: we’re still early in the number of open APIs and the quality of them.
Audrius Zujus: That’s a really interesting angle, because in some sense the open banking sector mimicked this problem. If you look at what happened in Europe -- government-mandated open APIs for all banks -- this is the direction in which the wind is blowing. When governments and people recognize that the data they own is locked up somewhere, they go and ask for a key, or a door they can put the key in. So I think we will see more and more of these companies getting APIs out and allowing people to move their histories fluently and easily. But another angle of that same analogy is that even though open banking provides you the APIs, they're usually not that good, so you end up still having to make integrations. Even though the companies who work in that space use those APIs, they still need to do custom integrations themselves. Also, I feel like in the future we're going to be in this mix where we can use some of the APIs these platforms have, but we also need to do other custom stuff because there just isn't enough incentive for them to be as fast and build great APIs as it is for somebody that makes integrations.
There’s an adage in entrepreneurship that in the early days, you should do things that don’t scale. To find the problem and get your first few customers. At some point, though, you’ve got to introduce automation to build a scalable fintech solution.
Audrius Zujus: I think automating is the only way to do it. I know there are some people out there trying to do it manually, and it sort of works, until you have five clients. If you want to do anything at scale, you need to fully automate the process. We have this few-step process, where we write custom automation integrations, but we're also developing a generalized ML/AI solution that can integrate tens of thousands of similar platforms. Automating horizontally as much as vertically is key in order to make this scalable. Automation is the only way to go.
Automation is especially important when you’re building on top of other firms’ infrastructure. That’s because there are more touch points to cover. Audrius describes this as surface area and it needs automation to build out.
Audrius Zujus: Currently, you just have a lot of people and other boats going around and fixing the stilts. But what you want to have is drones flying around and fixing the stilts. To continue in the same analogy, that's the automation you want to have -- automated robotic deployment of the stilts, to be able to provide more surface for the castle you're building. When it comes to the work we do, there's a large chunk of work as you integrate a new platform, but there’s also a substantial amount of work that continues throughout the time as that platform gets updated, because we have to keep on top of all the changes. It's as much automating the building of new integrations as it is automating the repairing and monitoring of the changes in the current ones.
For fintechs moving into financial data, they are sometimes surprised by the number of certifications they need. But it’s necessary to move into a space where large institutions share and consume data with you.
Audrius Zujus: We have SOC 2 Type II certification that we got recently. To use the current analogy, it’s like a COVID passport that lets you travel free without the checks. It’s something that essentially checks that you are compliant with certain rules and regulations. And even if you are, but don't have that sticker, that makes it harder to talk to people. So we're definitely on the road to get all the possible stickers that actually show that our processes and the way we do things are compatible with the best and even more than the best of industry standards. I think certifications are good in reflecting best practices, but for us internally it's also really important to do better than what is required. We don't want to just do everything that's in the checklist for integration, we actually want to do better, and then make sure that we're one step ahead of where that board of regulations is going. We're building the data business -- the two big pillars of which are uptime and security. These are the things we think about every day. Those are the things that we all want to work on and make better.
Audrius believes that new technology can give the historical credit score a run for its money. To make that happen, though, employment data will play a major role.
Audrius Zujus: A credit score is an output of a very primitive algorithm somebody came up with trying to essentially reduce the risk for the lender. If you have systems that use other ways to reduce the risk for the lender, what you end up having is a more efficient system for everyone. As a lender, if I don't have a risk to lend somebody money, or if I know it's a pretty low risk, I can actually work on tighter margins. What that means is that end users can get a cheaper loan. By improving the efficiency here, we’re actually helping both parties -- lenders to make money safely, and borrowers to borrow more cheaply. A good example is to imagine you want to lend somebody money before they get paid; you know that they make X, but you don't really know how much work they have done this week. If you use Argyle, and somebody works at, say, Walmart, and decides to share that information with you, you can see their shifts. And you can use that as evidence to lend them the money earlier or pay them daily, based on what they actually make and do, with as accurate of a forecast as possible. The fact that they already carried out the work and the fact that they work at a reputable place makes every lending decision way less risky. And so I think this area is going to see a lot of interesting innovations.