Trisha Kothari, co-founder and CEO of Unit21, was recently invited to join the 31st episode of Fintech Cafe, hosted by Monisha Chakrapani and Ambika Sharma.
In this 54-minute interview, Trisha, Monisha, and Ambika covered several areas of interest, including how Trisha met her co-founder, Unti21’s CTO Clarence Chio, how Unit21 was formed, and what challenges the Unit21 software aims to solve for risk and compliance operations teams.
Here are a few highlights:
- Low-code / no-code is really a product philosophy that addresses how to enable somebody who does not have an engineering background, but is a strong business user, to do things that have been historically handled by engineering.
- The founder-market fit is simply finding the market that is right for the founder, which includes the background of the founder and the disposition of the founder, as well as everybody that enables a founder to be able to carry out the objectives associated with an evolving product-market fit.
- Trisha and Clarence met at this place called South Park Commons, and both had good intuition of the general fraud / anti-money laundering space given prior work experience.
- Trisha and Clarence built out a prototype of Unit21 in 3 weeks to participate in an RFP they were invited to present by the Head of Anti-Money Laundering at eBay.
- They were quickly a front-runner for the RFP because, unlike the other prominent vendors, for Unit21, monitoring could involve any data.
- The gap they found in the market was at the intersection of a complete off-the-shelf solution that was otherwise too limiting and a fully customizable solution that would otherwise involve expensive engineering resources.
Want to take a deeper dive? Read the transcript from the full interview below, or take a listen to the episode here.
Enjoy!
Unit21’s Trisha Kothari on Fintech Cafe: Full Interview
[Monisha] Trisha, let’s start with you for introductions.
[Trisha] Of course. Thank you, Monisha, for having me on the show. I’m very excited to be sharing more about Unit21 and for the discussion that will follow. I'm Trisha. I'm one of the founders as well as the CEO of Unit21. Unit21 provides a set of no-code tools for risk and compliance operations teams within financial entities. We have a set of tools for fraud, anti-money laundering, and identity operations and work with companies in the Fintech ecosystem such as Chime, Intuit, and Coinbase, as well as non-Fintech companies like Twitter.
[Monisha] Lovely. And so Trisha, Unit21, as I understand, offers a low-code / no-code solution. Can you tell us what low-code / no-code is?
[Trisha] Low-code / no-code is really a product philosophy that took shape 20 years ago with the original build-your-own-website product offering and has especially taken off in the last few years. The philosophy is, how do you enable somebody who does not have an engineering background, but is a strong business user, to do things that have been historically handled by engineering. That is a core value proposition of the no-code product philosophy – to enable people to do more than what they would be able to do historically. And the major benefit that we see in this ecosystem is that, by enabling the domain expert to own more of the no-code paradigm and, therefore, their operations, they're able to get more work done and have a greater positive impact on their companies.
[Monisha] So you started the company in 2018, just a couple of years ago. Let's go back to your early days. For this show, I was doing some research, and I found something that was very interesting that you and your co-founder Clarence dubbed as “founder-market fit.” We generally talk about “product-market fit.” So what is “founder market fit?”
[Trisha] The founder-market fit is simply finding the market that is right for the founder, which includes the background of the founder and the disposition of the founder, as well as everybody that enables a founder to be able to carry out the objectives associated with an evolving product-market fit. The first product may not always be the scope of all the products that will be offered by your company. By really focusing on founder-market fit and making sure that it is in place enables the company to support the evolution of products over the lifetime of your company, which will certainly be more than just a singular product if you're successful.
[Monisha] So, how did you and Clarence, your co-founder, meet?
[Trisha] So I worked at an online payments company called Affirm, and I was brought in fairly early on. There were only about ten engineers when I joined, and through that, I got to build a lot of the original systems. So I built the original ledger and a bunch of the original risk-related systems. And that gave me a good sense of what needed to be built. Clarence's background is in machine learning and security. He wrote the O’Reilly book on machine learning and security and is also a lecturer at U.C. Berkeley on machine learning.
We met at this place called South Park Commons after we had left both of our companies. And we both had some intuition of the general fraud / anti-money laundering space given prior work experience. But we weren't sure whether our intuition was correct and that this would necessarily be a space that would be worthwhile building the company in. And that's where South Park Commons was really helpful with providing us that space to do a lot of exploration. There were some really crazy stories that came out of that, that gave us a conviction to start a company.
[Monisha] Nice. So what were some of these stories? How did you validate your gut instincts – that this is the problem statement you both wanted to chase together?
[Trisha] Yeah, so we said, okay, we think there’s something in this fraud / anti-money laundering space. There’s a ton of competition and a lot of different companies, but the problems are still not solved. And through our previous experiences, the fraud operations or the anti-money laundering operations teams were always frustrated. So we said, okay, let's do some research and validate that this actually is the case. So we reached out to about 300 people who were experts in fraud and anti-money laundering. Through that effort, we met the Head of Anti-Money Laundering at eBay. At the time, we had no product, no company. We were just really brainstorming ideas, and this Head of AML at eBay was very interested in us. He met with us, we told him what we were thinking about building in the space, and he got really excited.
So he said, listen, I'm doing an RFP in three weeks. I’ll bump you up to the final demo if you're ready to present something by then. So we said, great! We went back to South Park Commons and Googled, “What is an RFP?” We both were technical founders who had never, ever engaged in any kind of sales process in the past.
So we basically did not sleep for three weeks. We just built out the first prototype of the product. We then went down to eBay. I got one of my friends from Affirm to come with us so that it seemed like a three-person company instead of a two-person company. And we demoed at eBay. It was a really interesting experience when we were demoing the product to them, which again was really just a prototype. Those we presented to were really, really interested and they told us that we were the front-runners.
So we asked them… Okay, we basically have no company. We have no funding. We’re a two-person team. We have no product. No customers. Why are you interested in us? They said that they were looking at a lot of different companies, scores of which were multibillion-dollar companies. All of the other vendors came to them and said, you want a transaction monitoring system? I'll give you a transaction monitoring system. A transaction has six fields: an ID, an amount, a date, etc. However, we came in and said a “transaction” can be anything. We only call it “transaction monitoring” because that’s the nomenclature, but really it's data monitoring.
So, for example, you can have a data variable like auction type. And if the auction item is, let's say, a couch and the starting bid is $800, then if the couch sells for $1,000, then that's completely in-line. But if the auction item type is, say, a Pokemon card and the starting bid for a Pokemon card goes for five bucks, then a one thousand dollar sale would be anomalous.
What was most striking was that their operations teams – their risk and compliance operations people – were really interested in pressing for something like this in their organization because ultimately, they're the ones who were going to get fired or promoted based on how well their monitoring worked. But today, for them to be able to leverage all of their data and write statistical models, they have to be reliant upon their engineering counterparts. So enabling these operations teams to own their work meant truly democratizing these capabilities, which was something that they really valued.
So after we heard that same pain point many times, we decided, okay, there must be something there. This random company that built out a hackathon project over three weeks was able to somehow go head-to-head with multi billion-dollar companies. So we decided to fundraise. We got our first round of funding in December 2018, and we launched Unit21 in July 2019. It’s been really wonderful. I'm very grateful to have seen the rapid growth of the company, largely due to the growth of the Fintech space and the resonance of our value proposition for companies like Chime, Intuit, and many others who found our core proposition truly valuable.
[Monisha] That’s amazing, Trisha. We have a different founder from a different Fintech company every week. And I must tell you. I think this was the best founder story we've heard in the last 31 weeks here. You practically had a three-week-long hackathon in which not only did you find your problem statement, you created a prototype, you registered a company, and you found yourself a business lead. That's fantastic.
All right. Well, so I know you operate in the AML / fraud space. Typically we hear about low-code, no-code in the development space – web or otherwise. So just curious about understanding the landscape. What are you thinking about when it comes to AML or fraud?
[Trisha] As I mentioned, this is a really competitive space. We're not the first company that woke up one day and said, “Oh, fraud is a problem. Let's try to solve it.” This is a problem that has existed since humans have existed. And, in the digital world, it's only accelerated. So while it’s a very competitive space, what we saw was that there are a lot of different solutions out there and a lot of legacy solutions, which ultimately traditional banks would purchase. But then they would want to tweak them and customize them based on their specific needs – their specific customer types, their specific use cases, their different products. In order to do that, they would have to go back to the vendor and say, okay, I'll pay you a hundred thousand dollars. Can you tweak this?
Then they would get an Accenture or another really large consulting firm just to be able to own their operations. That was their paradigm – I'm going to buy an off-the-shelf vendor product, and then I am going to pay hundreds of thousands of dollars in professional services so that I can get it installed. I can get it up and running. I’ll have a developer that's just focused on maintaining that product. And, and that's how I'm going to run risk and compliance operations.
So when the Fintech ecosystem really started around 2010, the idea of tweaking all of these traditional vendor solutions did not make sense because Fintechs were just so different. It’s not a brick-and-mortar bank where the product suite is fairly standardized, and the types of customers you're selling to are mostly the same.
Every Fintech, even if you're a payments company, is going to be slightly different based on who your customer is and what types of data you’re collecting. What Fintech companies started saying is, all of these off-the-shelf vendor solutions don’t really work for us, so we are going to hire an in-house engineering team. This really started that whole risk and identity engineering team revolution where some of the biggest Fintech companies have teams of 40, 50, 60 risk and compliance engineers. And they would just be focused on building engineering tools for their counterpart, the operations teams. And ultimately, the operations team would still be reliant on the internal engineering team, maybe not on a professional services team, but on the internal engineering team to do whatever they wanted to do.
What we found was that this was the gap in the market. There is a compliance operations or a fraud operations team. In either case, you have two options. You can purchase an off-the-shelf vendor product, which means you don't need to spin up a huge engineering team. And of course, engineers are very expensive, very difficult to hire. And also, there's a lot of opportunity cost because that engineer is working on an internal tool instead of the core product. And so, instead of an ops person, they have two options. You either purchase a vendor and then pour hundreds of thousands of dollars on professional services hours, or you try to convince your business to build out in-house engineering teams.
And this was really where we found the gap in the market. Is that what, if you can combine the benefits of being off-the-shelf – fewer resources to maintain, more agility, more control – with the benefits that come from being built in-house, which is completely customizing to exactly what you want. That's really why we decided to play in this space and to have an opinionated offering about how customers should think about and own their operations.
[Monisha] Trisha, along those lines, how do you think about use cases? I mean, fraud and AML, every time I speak to someone in this area, there's always an interesting use case. What are some of the use cases that you've seen your customers tackle and that Unit21 has enabled?
[Trisha] One really important component of monitoring is identity. If you can block criminals from your platform, then you potentially will have lower fraud. And there’s certainly truth to that. But the problem is it's not all-encompassing because ultimately, you only get limited data through the onboarding flow. Almost all the Know Your Customer (KYC) data is basically the same. So your ability to onboard 100% non-fraudulent customers is very limited. Fraud actually happens when money is transacted, after onboarding, not during the onboarding process. So it’s difficult to tell who might commit fraud until they start performing transactions after the onboarding process.
The operations teams we work with are able to easily create, test, and deploy logic to flag any kind of suspicious activity in their ongoing monitoring. So they can define parameters to flag suspicious activity and then decide whether to investigate further or simply block that customer or type of transaction. This is where we have found the value is that typically, for the operations team to be able to do this, they may not have the necessary technical skills to write SQL queries or complex scripts, but they are strong business users. So a lot of this would be done by intuition rather than by actually leveraging analytics in the data decisions.
What we've enabled is that the operator can now easily create, test, and deploy these statistical models without having to know how to write code and without having to involve an engineer to say, “Hey, can you deploy this model?” They can completely own their process. And so through that, our customers have seen up to a 50% reduction in fraud loss and up to an 80% reduction in false positives.
Unlike other providers in this space, we're not saying, “Hey, we have this machine learning score, which is a magic wand. You wave the wand, and all of your problems go away.” What we're saying is, you are already hiring your magic: your operations team that is really strong. And they're strong business users. We will enable them to be significantly more effective so that your company can achieve its business outcomes without putting a burden on your engineering teams, and by enabling your operations team to up-skill themselves from pushing paper to performing true analytics and investigations.
[Monisha] So your customers are primarily in fraud and compliance operations?
[Trisha] Exactly. So our customers are primarily in fraud ops and compliance ops. They can easily create a task and deploy the physical models and workflows. They can take automated actions on it, or they can have an alert generated, which they can then report to regulatory agencies as needed.
[Monisha] One more question before I transition to Ambika. I know there are a lot of industry coalitions around fraud data and identity. Do you also enable other data sources, or is it primarily leveraging the institutions’ data sources?
[Trisha] That’s a great question. We have integrations and partnerships with the leading providers of data companies like Socure from an identity verification perspective, Middesk for KYB / business verification perspective, and Chainanalysis from a blockchain analytics perspective.
[Ambika] Could you talk to us about one of your machine learning models and some of the metrics that are driving impact? I'm just trying to gauge more of a day-to-day practical application of your platform.
[Trisha] Sure. One of the main differentiators with Unit21 is that you can leverage all of your data, so you don't need to be restricted by what the concept of a transaction is, for example, an ACH transaction or a wire transaction. You can put in whatever data you're collecting, login information, any kind of data that you're collecting, even if we have no standardized way of consuming it. We can consume any kind of data via JSON. That’s really the core – it's a data monitoring platform. So the customer is able to leverage all of their data.
For example, let's say we’re working with a restaurant payment platform. With most other platforms, they would be able to create something like, flag if a restaurant has more outflows than inflows. Or a flag if a restaurant has had a spike in transactions in the last year. However, this is limited to financial transaction data.
With Unit21, we can consume any type of data. The operations teams can write models, which look at very specific data derived from their business model. So they might write something like, flag if the tip is more than 80% of the amount of the bill. And if this happens more than five times in a month, then that is potentially anomalous. The major benefit of Unit21 is that you can leverage all of your data, which means you can be very, very fine-tuned as to what you consider suspicious.
Another key component of the platform is data labeling. You can label the businesses or the individuals that might actually be fraudulent, and then you can consume those labels back. You may have different thresholds or different parameters that you want to monitor for those people who have been marked as potentially fraudulent.
With this level of granularity, you can really lower your fraud loss rates significantly, as well as reduce false positive rates, because the platform is not just a static rules engine. It's constantly consuming the data labels that your agents are producing.
Through this, we’ve seen a lot of operational benefits. We have one customer, Envel. They were able to reduce the time to deploy a model from days to an hour. But the major benefit has been that another customer, Lilli, was able to reduce fraud loss by 50%. They were able to reduce $400,000 of fraud loss in the first quarter of using Unit21 because they could leverage all of the data and were not restricted to the standard data schema most vendors allowed them to consume.
[Ambika] So would it be correct to say that it's an analytical platform? For example, let's say I'm a Fintech company and I collaborate with Unit21. Your product would be an analytical platform that I would plug into. The data would be mine, but your platform would actually provide metrics analysis for me. And it would also enable me as a Fintech company or a fraud strategy specialist to control for the rules I want to control for, but faster because I don’t need to go through engineering. Is that the right kind of example here?
[Trisha] Exactly. It's a no-code customizable platform. You can own the statistical modeling. You can own the workflows. You can own the data orchestration on the onboarding and define what makes sense for your company.
[Ambika] Okay. So then a follow-up question: How does your solution fit in with big banks, which, you know, there's a lot of legacy data, data is in different formats that don’t necessarily speak to each other. How does integration work for big banks with Unit21?
[Trisha] That's a really good question. And a major benefit is that we don't have a very confined data schema, and we can consume data from whatever you are interested in sending. It’s much easier to be able to consume and integrate different types of data. You would typically not see this with most standard vendors where it would involve a huge, super long implementation process that could take years. What we see with smaller Fintechs is that they may have nothing in place, so we may be the first tool that they're using. But a larger financial institution, or larger Fintech, already have a bunch of systems. What we are providing is the ability to see what part of the overall solution can we enable the operations team to control where they do not have currently the capabilities to do certain things? How can we provide more value with the platform model?
You can choose whatever components of our platform you're interested in. We don't push and force people to use all of the software. It's really up to people to leverage Unit21 for wherever the ops team finds themselves very reliant upon their data scientists or their engineering counterparts to be able to turn themselves into mini data scientists with core business expertise.
[Ambika] So we're coming to the end of our moderated session. The last question from me to you, Trisha, is around data security. Do you deal with PII – personally identifiable information –such as social security numbers, and if so, could you talk about how secure are your data marts?
[Trisha] Yes, we do. This is a really interesting question. We deal with very sensitive data about individuals and businesses. We have two modes of deployment. We have a SaaS model, as well as the ability to host a managed deployment through which we can deploy on the host instance of the company. But data security has been integral to the company from day zero. Before we had any customers, we had to do software compliance. We had to make sure that we were going through penetration tests. We were three employees, but everyone needed to go through background checks. And so there are a lot of different policies in place, not only from a technology perspective but also from a personnel perspective – things like making sure that everyone goes through security training and there are reference checks on every single employee hired.
And we are always looking for multiple people for a single position so that we can ensure that there is no way that there can be a rogue actor at all in our personnel or on the technology side of things. We've been very fortunate. Clarence wrote the O’Reilly book on machine learning and security, and we take security very seriously. When the company started, and before we had any customers, we got SOC 2 attestation. And today, privacy and confidentiality are very important for us as well. We are compliant with GDPR and NCA regulations too.
[Ambika] Awesome. Thank you, Trisha, for joining!
[Trisha] Thank you so much for having me and, and thank you too for your really interesting questions. We’re really excited to be building something in this space with all of this amazing energy, and we’re looking forward to seeing where this all goes.
Subscribe to our Blog!
Please fill out the form below:
