The Present & Future of FinTech Compliance with Adi Goel

Adi Goel: To be able to enable digital banking, you have to reduce the friction, and while you reduce that friction, you also then create attack vectors, and the first attack vector comes with really understanding the user. Is this a real user? That's first.

Tarun Gupta: Welcome to The Jump Off Point. An original podcast by Jump Capital. Digital fraud has increased 53% since 2020 and shows no signs of letting up. In this episode, we get heavy into FinTech compliance, specifically the product side with our guest Adi Goel, co- founder of Sardine. No stranger in navigating the FinTech compliance terrain, Adi shed's light on his thought process behind building effective compliance products.

Jason Felger: I think always a great place to start Adi is like give us just this journey that you've been on through product leadership roles, co- founding a couple of companies, always within FinTech and closer and closer to banking and payments, but just that contextualization of that journey and kind of what's been motivating you and exciting you through that journey is a great background to start.

Adi Goel: Yeah, I started my life or let's say education as an engineer. My family's been full of engineers, so always wanting to build things from scratch. My brother started in trading during the great financial crisis, so during 2008, that's what really got me excited about just markets and finance in general. I started my career as a con trader with Penco. Those two years were really exciting, just the market's perspective, especially understanding risk, how the world works. This was the European crisis when there was a whole conversation of Portugal, Italy, Spain, will they go bankrupt? What would happen. During Penco is when I really realized a lot of the great institutions that have built defining institutions in the space of finance or financial technology, they have built a lot of great infrastructure, learned a lot about the need for what you need to do from a regulatory standpoint, how much it takes to think through okay, this business is require the right amount of capital. You need to understand each and every piece because you're dealing with people's money. And that led me to the journey of just enjoying building companies. So cut it short. A few years later came back to the US for business school and then joined Revolut. There I really, I would say got a lot of firsthand training, how to really think about building a bank from scratch. So the opportunity was really exciting. Revolut was already growing and they had no presence in the US and I was stabbed on to start their US business, US product from scratch. When you're a FinTech, you are building out the whole stack from payments, from regulatory and compliance side. The way to build new products is how do you interpret the regulation and what needs to be done versus what is just a process that was handed down by let's say generations because it was followed in a bank. The key thing about say the Revolut experience was just how do you think about building a platform, right? Where you start with one product and then you can add another product. I think a phenomenal journey that actually led to the founding of Sardine. So both my co- founders who were at Revolut with me. Soups was my co- founder and CEO, he was heading Fin Crime and Fraud at Revolut and then after that Crypto at Revolut, his prior background before Revolut was fighting fraud at Coinbase, so he was one of the OGs there. This was really interesting journey for us at Revolut, which resonated with a lot of our friends and other FinTechs. What we would see is we would build all of this amazing tech and then when we would launch the product, we would get hit with shred in sometimes or many cases. At Revolut there was a lot of things that we had to build in- house, but the key insight that we had was a user. It's not just an endpoint user, it's not its identity, it's not its transaction, it's not like a point in time action. A user is all of those things and based on that you've figured out, " Okay, is this a user that I want to let on my platform?" You want to focus on your use case. You want to focus on what you want to build your USB as a new FinTech versus having to build all this infrastructure in- house, which takes two plus years in sub dollars. And that was our key insight in launching Sardine to really enable money movement faster. Where we can understand and help our clients understand is Jason, Jason or is Jason pretending to be Tyrone, or if just Jason steal Tyrone's payment methods to actually transactions on a platform.

Jason Felger: The use cases you're describing are kind of modern pains. I mean banking and banking products have obviously existed for a hell of a lot longer than the stretching of the compliance needs for things like instant payments for a totally digital first bank. You've been in the industry long enough. How has the compliance tooling, how has the regulatory environment been pushed over the last call it 10- ish years as neobanks and payments have just become more and more readily accessible for most consumers?

Adi Goel: It's really interesting, right? Pandemic kind of showed us the power of digital banking. A lot of new users who had never used digital banking or digital movement of money had to experience it up until early last decade. A lot of the banking activity was performed by walking into a branch. So when you're walking into a branch, you're checking the identity of the person. Most of the times you still have a relationship with that teller or banker. So things such as know your customer, things such as anything around anti- money laundering, what is the use case? What is a source of funds? These are very clear, but in the age we live in where you want to be able to do all of these things, you want to buy a stock, you want to buy crypto, you want to send funds to your friend or your parents outside of the country, you don't need to walk into a branch. And to be able to do that, the first thing is onboarding, digital onboarding. And as part of that process, different countries have different kind of regulatory requirements, but it's generally you need the name, address, state of birth of a person and you need to verify some kind of identity that this person says who they are. In US most of the times we use the social security number. All you need to know is first name, last name, address, date of birth, SSN. In some cases a little more information, but it's generally that, and it's so easy to find this set of information. SSNs get hacked. There's a lot of black market data around it where you can purchase it. And fraudsters can do this easily, even in terms of where they need to upload an identity, they could upload a forge identity. That is where the vector of fraud starts essentially. And to your point, to be able to enable digital banking, you have to reduce the friction. And while you reduce that friction, you also then create attack vectors. And the first attack vector comes with really understanding the user. Is this a real user? That's first.

Jason Felger: From a product standpoint, how do you think about the winners and losers of the modern technology companies that are actually building to solve these problems? And so as you say, there's just the digitization of banking, whether it's legacy who's coming into digital or from scratch, neos, and there's all these different attack vectors from onboarding through ongoing fraud prevention. Curious how you think about it almost from like a product roadmap standpoint. Where have been the boundaries of those that have succeeded in those that have maybe not?

Adi Goel: It's such a really interesting question and maybe it's interesting to note, what is the journey of a user, right? When they go through onboarding or in general is I want to do a use case. So let's take the use case of someone wanting to buy crypto today and they want to use that crypto to buy NFTs. How do they do that? And they want that crypto immediately because otherwise the NFT drop is done. They'll probably have a wallet somewhere on a centralized exchange or they'll go and open up a wallet. Now for them there are multiple processes. One is just onboarding. So I need to know that this is a good user, this is a verified user. You provide the details. Again, first name, last name, date of birth, address, maybe a form of identity. And that's where the first attack vector starts. Now the second attack vector is to be able to buy crypto, I need to actually have funds available. So I need to pay for those funds. I can pay via Wire, I can pay via Zelle, which is a push payment method in the US. I could pay via debit card or credit card or I could link my bank account via a Plaid or MX and verify that I own that account because I know the login and password, and the exchange that is going to provide you crypto will know your bank account number routing number and they can then debit that account, and then they will give you crypto. Now you could take that crypto out of the ecosystem, out of the wallet, and if you do that, there is no way for the exchange to get that money back, because again, crypto is irreversible. They could keep that once, they could keep the crypto and allow you to only withdraw after a few number of dates. And then of course you can keep doing these activities and number of times. And then finally, when we think about just the product roadmap here, right? As someone building this product facing the end user at every point I want to reduce friction. I want to increase my conversion. I want to make sure that if it's a good user, if Jason is Jason, and Jason has money, and Jason will not commit fraud on my platform and he's a compliant user, I want Jason to do every transaction that he wants on our platform because that's how I make money at the end of the day. But now it's very easy from an attack vector where one, Jason can pretend to be someone else through stolen data. And that's where we've seen a lot of companies actually create good tools. There are KYC platforms that exist, which take a selfie, which take a picture of your self and your ID, are able to detect that first ID. That said, let's say you passed through KYC. It's very easy to now use a stolen bank account or a stolen card to load funds in and then get crypto and then take that crypto out. There's a regulation in the US called Reg E, which allows a consumer to be able to call up their bank or card company to say that they did not authorize this transaction for up to 60 days, and they'll pretty much get their money back because it's more focused on protecting the consumers. It's a very easy fraud vector, fraud tag that can be done. And this is where we've seen a lot of companies, especially FinTechs, have had to build this in- house because existing platforms or vendors have been very point solutions where they take care of KYC fraud, where they might have something around, okay, is this wallet address that the money is being sent to, that the crypto is being sent to is a sanction address or not? But that's pretty much it. That covers your baseline regulatory compliance. But that leaves a lot to be desired in between because we could see cases where you guys might have seen this off late if there was an article in Forbes around a scam called Pig Butchering Scam, where you get these messages from people asking you to be friends. And over time after persistence, they'll ask you to invest in a scheme where they'll show you that they have hand returns in the past, it could be through a crypto company or it could be a simulated return. And you'll see that, " Okay, you know what? This guy has been really good. I've been talking to them." Because they actually talked to you on the phone, and after a point you will start to invest money. Once you've done that after a couple of times and you've seen simulated returns on the app that they direct you to, after that, when you load funds, real funds, big time, the third time they will run away with those and you don't have any funds anymore. Now it's very easy to detect these kind of things because when you're actually interacting with the investment app, you can see that hey, this person is probably being controlled by a third party because they're probably taking screenshots when they're doing that investment. And we see a lot of these cases where scams such as these could be prevented if you know what is the intent of the user. Again, like a simple thing would be if you're a person that has been able to steal an identity, how you type in that identity information. Am I copy pasting an SSN? Like when have you seen a legitimate person copy paste his SSN? This goes back to the true compliance and fraud understanding of a user license, not an end point solution, but everything that we do throughout the life cycle of the journey, right from login, because they might have created an account, your account username, password might be stolen. We've seen, and this is something we do at Sardine, but in general, if you're able to detect, " Okay, this is not how Tyrone types his username, password." Even if it says username, password. Then you can say that, "Okay, this might not be Tyrone, this might be someone else." Then you can send a multifactor authentication or some kind of step up that makes sure and verifies Tyrone. You don't want to do that every time they log in because then it's a lot of friction for the user. So it's really about how do you create the right kind of checks and balances at every step the user goes through and only ask them the right kind of step- ups if there is a suspected activity, you have to look at what payment methods are they using, how frequently are they coming in, what are they doing with those funds? And once you start to understand that activity, you can create a dynamic, literally a risk score for each user. And generally 70% of your population that's coming in would be good users, so you want to roll out the red carpet for them. Whereas for the rest, instead of rejecting them, you could have a tiered functionality, where, " Okay, this seems to be high risk. Maybe let's allow them a small amount of transaction limits."

Jason Felger: One of the really interesting things that you mentioned there is throughout the customer life cycle, these FinTechs need to leverage multiple vendors to actually manage compliance and fraud. And so I'm interested in how you think about one, if FinTech managing that, it's a lot of different vendors to utilize. To two, how the partner banks and vast providers they work with actually look into the compliance of those specific institutions. Because in a lot of these cases, they don't have the full level of visibility that they really would like. I mean that we think has presented a lot of issues that have come up recently.

Adi Goel: Yeah, I can start with the second question first, which is really interesting. To Jason's earlier point that we've seen a huge growth of FinTechs in the US especially, it's because of the ecosystem that Parker Banks have been able to create clear, especially the sponsor bank is the one that has actually had the license. They're the ones that are interfacing with the regulators and at the end of the day they are passing on their regulatory requirements onto the FinTech company or the crypto company to be able to fulfill. And for that it's truly important that they have that level of visibility, which we have seen over the ecosystem is generally the way it works is the sponsor bank would do a review of your policies and procedures and we'll have a quarterly audit or annual audit. It's almost impossible for anyone to be able to sift through those millions of users, millions of transactions, to be able to say that, " Okay, was there a gap somewhere?" And I think that's where we are seeing actually a lot of interesting pieces come along. There's a massive need of more trust and shared data around the ecosystem in the FinTech space, we are seeing a lot of sponsor banks that we are looking to work with or working with now, where we do this thing called portfolio level monitoring, where essentially a sponsor bank has stand or 20 or more FinTechs and is each of their FinTech is implementing at Sardine or something similar where you have an understanding of each user right from onboarding to each transaction to a rule engine that allows specific rules to be sent based on the use case that that FinTech is doing. For example, if you could be a sponsored neobank or sponsor bank that does not allow let's say withdrawals to a certain set of use cases, and you can actually track that, " Okay, these withdrawals are going to these addresses." That level of granular data is available, but then you also have insights into each of the portfolio. Well, the key things is you can actually see some similarities like, okay, maybe we are seeing an increased level of fraud with specific use cases or within a specific maybe geography or for a specific subset of industries. So that level of portfolio level granularity right now is probably not there yet. And that is what we are seeing the big need for a lot of the sponsor banks. It's a pretty common fact that with a lot of the neobanks and in general with more digital onboarding, there's more fraud. And with that fraud comes the issue of, " Okay, if we've seen this fraudulent user across one of our neobanks, should we allow this fraudulent user across our 10 other neobanks?" And that level of data sharing just within your own portfolio of neobanks allows for first detection of a fraudulent or suspicious activity. And that level of data sharing back to your neobanks can further help in just making a safe, trusted ecosystem.

Jason Felger: You had mentioned that there are a lot of components of the lifecycle that a FinTech has to manage fraud across. Onboarding is one, but then as continuous transactions happen, you have to monitor that piece of it too. And there's no one size fits all vendor that works across every component of that. And so a lot of different vendors end up getting used. How do you think about a FinTech managing, stitching together a compliance program through a ton of different providers?

Adi Goel: So it's always a challenge and I think it goes back to what is the USP of the FinTech? What is their real value, right? Let's say you are a company that wants to do cross- border payments or you want to do specifically to crypto. I have a biased opinion here. The two key things to evaluate would be one, whichever vendor you're going with, does that have that level of modularity so that if you do want to use a specific vendor for one use case, you can still shed that vendor into the second vendor or the third vendor. So in a way, if let's say you use KYC vendor for something and then you have a transaction monitoring aspect with the second vendors, you are actually able to share the data between the two vendors and build that platform yourself, or you use something where you're able to pass on that data and then the platform does the intelligence part of it. So to kind of break it down into components, trying to pick the best in class endpoint solution for everything that you do. Second, how does that data flow together and what are you doing with that data? Are you managing that data or you're sharing it with the vendor or third party? And then who has that intelligence level and what needs to be done with those insights that are happening together? So an example would be, let's say a user comes in, they've used a email or a phone number that potentially is medium risk and then they load funds via a card or a bank account where their name does not match. Now if you use an endpoint solution just for KYC and then you use an endpoint solution just for bank verification, you got to build that logic yourself, and then you will have to have tooling that will allow you to change this logic. And then what do you do with these results sets, right? Let's say this user comes back as a good user, there is no fraud that happens, or if this user comes back as actually fraudulent because you let them transact on your platform. Now what do you do that with that feedback? So I think these are the questions when should first ask, how are they thinking about all of this and then based on the USP that they have, do they want to build this in- house? What part of that stack do they want to build in- house? And then I think the final part is if you're building all of this in- house versus using let's say a platform that actually does all of these pieces as an intelligence layer, are you getting the benefit of a consortium of the network? At Sardine, we believe strongly that a lot of the decision making again, is very much a life cycle journey, and it's also equally important to be transparent to the clients and give them back all the signals. So that's why we actually don't do a black box model. We look at explainability of the models and the risk scores that we give back, and then you've seen companies that have created data science teams leverage those models and signals to build on top of it. And we've seen another piece that really helps on is let's say if you've seen a fraud pattern, a fraud attack vector, again, you can never solve any fraud, but purely machine learning, you have to have that human intelligence layer. So on a constant basis, we are fine- tuning the risk rules.

Jason Felger: 10 years from now, where will we be from a product standpoint? Are the merging of the data sets and merging of infrastructures going to unlock new products for consumers that maybe aren't even feasible today? And then also, how much more complex is the compliance and regulatory environment or technology needs going to be over the next five to 10 years?

Adi Goel: I mean, you hit the nail on the head, because I think this is where FinTechs have a true advantage because they can be nimble, they can move fast. It's just really exciting to see what kind of use cases would emerge. I can only think about a few. I'm sure amazing folks are building out really great use cases, but we've seen NFT marketplaces come out, not very dissimilar from an eBay of 20, 25 years ago or an Amazon of 20 years ago, we are seeing NFT marketplaces come off where there are sellers, creators, brands that are literally minting NFTs and on the other side are their users loyal buyers that want to then exchange it for a certain experience. But then you can create a marketplace where if you are a buyer and then you want to back shell it to another user on the platform, you're able to do that. Now with NFTs involved, that adds unique challenge because one, these are more easily tradable digital goods compared to a more traditional book or something else that you might buy on the internet, because it's on chain. There's a whole aspect of on chain transaction monitoring and crypto related both regulatory and compliance needs that come in. So that's something we are starting to see emerge. We've only seen the surface of it. Another thing that has been really exciting to see is people wanting to get paid in crypto globally and that too in dollars, people wanting to get paid in USDC, how do you even enable those use cases? There is a lot of pieces of, "Okay, is this user being onboarded into a US bank who's not a US user or a US resident?" Do they have the right checks? Do they have the right identity? What kind of other information do you need? How can you make sure that whatever they're spending those funds are, the source of funds and the use of funds is in compliance? I mean, these are a few use cases, but I think that's the most exciting part. Going back to what I think 10, 12 years ago, companies like Stripe enabled where people have built lots of different platforms that you could not even think of. I mean today, tomorrow, if Twitter decides to add a digital wallet where people can get paid directly on Twitter, that opens the whole aspect of what kind of infrastructure with Twitter require for that. And this is exactly the kind of things that we are building at Sardine, we are seeing a lot of strokes and doubt in the industry.

Jason Felger: As these use cases become unlocked, which of course who knows what all of those use cases are, but as these new use cases become unlocked, how much further will that stretch the compliance needs for FinTechs? I'm just curious how you think about what that world might look like in the near future.

Adi Goel: With every use case, I guess let's think about this here, going back to the growth of digital form of money, of digital onboarding, folks who have never interacted with that medium are also coming on board. So there are lots of web two users that have never interacted with crypto and they probably are not aware of there are benefits to crypto, but then also crypto is irreversible. So if you have sent crypto accidentally to an address or you got scammed, there's no way for you to get that back yet. There is no regulation around it, and that is by nature, by design from a technology standpoint, we see Zelle scams, like Zelle at the end of the day where people are just pushing funds to a certain user. We've seen where you get an ad on Craigslist and they ask you to then send money to this Zelle user and then they will send you the money, right? They'll send you the good afterwards. Now, if you paid via card or an ACH debit, you could call up pure bank, whereas on Zelle right now, at least as of now it stands, it's the user who's responsible for the fraud. You've lost the money. And the short answer is the more use cases you have, the more people that get onboarded and the level of education that those users have, depending on the use case that they're doing, it only actually gets more complex both from a fraud standpoint but also from a compliance and regulatory standpoint. Because at that point, okay, does the government come in and make a new regulation? For example, I'm sure all of you guys have seen there are talks around making either buy or other folks responsible rather than just the customers for Zelle scams, right? Now, if you're able to prevent the Zelle scam upfront by being able to tell the application that, " Hey, you know what?" Let's say this user who's trying to buy on your website, he's accessing it. There's also growth in terms of the lack of visibility and protection for the end users, which might result in a regulation that then protects the consumers, but also prohibits these use cases. So I think just for the innovation of the industry, it's really important to keep pushing the barrier. I think we're done 1% in the innovation this side.

Jason Felger: On the Zelle side, I'm more curious just about the consumer propensity and the movement we are seeing to real- time payment and the host of issues that creates, and I know you and Sardine are helping solve some of that, right? On sort of the instant ACH side of things. So I'd love to understand just the money movement side and how that translates into newer solutions being built and a new host of problems that come up, and then on totally separate side, away from money movement, but still on the regulator side of things, we're seeing neobanks coming under a little bit of fire right now from the OCC, and I'm curious just to get your perspective.

Adi Goel: Any kind of money movement is at the end of the day, or let's say the velocity of money movement is totally dependent on trust in the ecosystem. Let's say between the four of us, we trust each other. We can literally maintain a ledger between the four of us and move money on that ledger and say that you have$ 100 from my side and all four of us could have access to that account, but we know that there is trust in that ecosystem. To extrapolate that example, if you take things such as Zelle or in general, any kind of real- time money movement platform, what it does is it's great for the end users and of course that's where we are all moving towards, but it also reduces or takes away the ability for institutions to do post checks. So today, when you see with ACH as well, we have same day ACH available. We have next day ACH available, but a lot of institutions still hold your funds for five days. And the reason for that is generally the return codes on ACH that you receive pretty much 80% of the returns you would receive within the three to four business days. There's of course that 20% unauthorized returns that you could still get in the next 53, 54 days, but most of the returns you capture within that timeframe. Now with instant money movement, whether now that's why Zelle, whether that's why ACH or any other rail, you take away that ability to do a post check on that transaction. So the owners actually then falls on being able to do that check in real- time or three, the transaction is authorized. So in case of Zelle scams, let's say the user does this and then their code does not ship within the two days, they still have an ability, let's say there was a whole period, they could go to their bank and place a hold. Of course, that's where we were in the past, and we don't want to be towards old and slower payment methods, but where I'm coming from is that's why the check on fraud and compliance becomes even more important because at the end of the day, someone is burying this loss, right? Whether it's being passed around from the consumer to the bank or to the merchant between the three parties, someone has to, and there is a cost to it. There's a reason. Cards are generally more expensive. Now, cards have a dispute mechanism that is, it's actually pretty good dispute mechanism because you have a represented between the merchant and the consumer. You can actually dispute that represent then again. And what that does is it creates friction, but it also creates checks and balances, but that adds cost to the ecosystem. So if you can actually solve for these problems upfront in real- time money movement, and again, right in US as Zelle, we are going to get Fed now. But again, a lot of the countries outside of US already have real- time money movement, and there again, a few push funds to a user, and then you have to take the loss as a consumer. That's where designing, again, not just from a regulatory aspect, but also from a UX standpoint, how can you verify? How can you inform the user? How can you create that trust, whether it's through things such as any kind of past balances, past checks around the merchant, around the consumer, you need to create that. And sharing of that data across the ecosystem becomes even more important because again, a certain fraudster had a bank account that be used for Zelle scams. If that account is shared across all the banks, then that can be prevented. If that can be shared across merchants, that can be prevented from onboarding that user. Or when you're actually about to go to your bank app and then say that, " Okay, I want to send money to this user." Your bank can then tell you, " Hey, this is a suspected account, please do not send money." So going back, what we are seeing, whether from a Sardine perspective and more so pushing the envelope on checks and balances and regulatory and compliance and fraud checks upfront for real- time payments becomes even much more important compared to money movement methods which have a lot built-in.

Jason Felger: This could be totally irrelevant, I'm just curious. So many of the solutions that we see, meaning new companies being formed up and down the compliance stack, they have the presumption that access to data both inside the FI and then clean data from third parties is easy and accessible. And I won't say that that's a complete fallacy, but in our conversations with folks in industries like that in many respects is some of the hardest things to solve for is I built a fraud module. But that's predicated off of getting a whole bunch of different disparate data sources cleanly into the system to then be able to derive that value. You've done this enough times for different constituencies and different types of products. I'm curious if that resonates, if you've seen that or if you've kind of hacked your way through it.

Adi Goel: This is a big issue, especially in more legacy institutions. There's something I've seen during my time at Penco and then working with other larger banks and institutions, and I mean, we call it the data lake issue, essentially, where there are all these data lakes where let's say the consumer information, the PII or just the KYC information is sitting, then you have a separate log somewhere in a separate database where the transaction information is sitting. Then you have a third data lake, data is traditionally being really hard, and that's where Tyrone and asked this question, when FinTechs are deciding how to do vendor management, how do they think about that? And I think this should be one of the biggest pieces in thinking about a vendor, because even for new companies, even though you're building on a new stack, you can have your initial database design where all of these pieces talk to each other. How do you ingest this data? How do you then actually build an intelligence layer and then be able to then act on that intelligence layer is extremely important. So one of the things that we've seen that is easy to do is one, have APIs for pretty much ingesting any kind of be, right? For example, at Sardine we build this custom value, key value pair. For example, when you're sending us PII in one of our API endpoints, if you don't have that data, you just send us that in a key value pair and we'll take that in, ingest it, create a database schema around it, and then you can actually use that data in your models and goes back to whether you build that pipeline in- house or you build that through a vendor. I think that's such a key piece to be able to then extract these insights. And at that point, for a lot of these companies, I mean these are sophisticated machine learning problems to solve. How are you making sure that you have the right data ingestion pipeline? Can you build a model very quickly on top of that? But specifically for, I would say whether it's new organizations or more traditional organizations like large banks, as long as you have access to that data and then you're able to send that back in any kind of format, whether API, Excel dumps, CSC dumps, we have at least sardine. That's how we think about that problem. The ability to do that is probably, I would say the most important architectural decision that you would make, whether you're building it in-house, whether you're using a third party like Sardine or even if you're stitching together multiple vendors.

Jason Felger: Good. We covered a lot. Yeah. Thanks for doing this exploration.

Adi Goel: Sorry for boring you guys.

Jason Felger: No, no It was a great exploration through like how you think about these products and the implications of these products from a compliance and regulatory environment, and that's something we're as odd as it is to say passionate about and spending a lot of time in. So thanks for sharing the experiences that you've had with doing it.

Tarun Gupta: You've reached the end of another episode of The Jump Off Point, like what you heard, head to wherever you heard this podcast, subscribe, rate, and leave us a review. We'd appreciate it. Today's show is produced by Jump Capital and mastered by Fabian Rodriguez. Until next time.