Wilson D’Souza Would Accelerate API Adoption

Announcer: If I Ran The Bank is a podcast hosted by Clayton Weir, co- founder and head of product and strategy at FISPAN, a Fintech that is enabling banks to provide contextualized consumer life experiences to their business clients. Clayton is a thought leader in financial innovation and hits on the hottest topics in banking, finance, and the future of payments. And he wants to know, if you ran the bank, what's the one thing you'd go all in on. Please tune into Spotify, Apple Podcasts, Google Play, or wherever you get your podcasts. And now here's your host Clayton Weir.

Clayton Weir: Welcome to another episode of If I Ran The Bank. Super excited for this week's guest, Wilson D' Souza. Wilson is the CTO of a really interesting group called Akoya and I'm super excited to have him on the show today. Very rare that we've had actually the voice of technologists and the literal architects of the future of financial services on this show. So we're going to take a slightly different tack. This conversation, I think is going to end up being a really interesting expansion on the one we had with Ben Isaacson recently around some of what's underway with the transition to market- based open banking and getting beyond the proto- open banking in North America, that was enabled by screen- scraping some of those things. I think this is going to be an interesting expansion on that with a man who has built this with his own bare hands. Thanks for coming on the show, Wilson. Really, really excited to have you.

Wilson D'Souza: Thank you, Clayton. Thank you for having me. Great to be having this conversation with you.

Clayton Weir: And so you were, pre- acquire obviously, you came along with the furniture on the spin- out from Fidelity, I think, right? Do you want to just walk us through some of what you've done in your career and the kinds of problems you've been solving?

Wilson D'Souza: Yep. So a little bit of background. Right. So first of all I've been with Akoya since the beginning as a CTO and really encompassing, I call it from a whiteboard to a PowerPoint deck to code. When I started off, we were a few folks just brainstorming around how we would solve this for Fidelity. And, as we started spending some time, discovered that we could make this a little bit broader than just Fidelity. And I'll walk into that, but a little bit about me, Clayton. Essentially I've been with Fidelity, before we got spun out, roughly around 11 years in different roles. I was in infrastructure focusing on employees on their work space. And then I transitioned internally, building some of our next generation investor centers, as well as running all the retail technology across multiple business functions that face off with our consumer, in the broker side, as well as on the 401k side and on the institutional side from a contact center, CRM, Advisor Desktop, and stuff like that. And prior to my time at Fidelity, I spent a few years in MIT really doing different roles, or as roles that kind of evolved there. Odd research, Bot services, building some new API capabilities mostly in the security and authorization and collaboration spaces, really supporting the faculty and the research community there. And then I spent a bunch of years at Merrill Lynch, in various roles, doing different kinds of things from launching, or helping launch or at least direct way back then in'99, which seems ages ago. And I've spent some time in the FMCG business. So more details can be found at LinkedIn. But yeah, I've done different kinds of roles and zigzagged across multiple industries and looked at problem sets in the technology sphere. And really, the general thread has been extremely customer- focused in all of these journeys for me. That has always attracted me to solve real customer problems. And Akoya was a unique opportunity, which was complex, boring, but a problem that was big with risk, but with very little awareness of the cyber issues and the financial risk that consumers are exposed to in the world of data sharing.

Clayton Weir: Totally makes sense. And so, so take us back there. I love your whiteboard, to PowerPoint, to code analogy. So I'm guessing as an outsider, I'd love to hear a little bit of behind the scenes of what led you to Akoya, really the problem statement. But I assume you guys had an interesting insight on this, because I'm guessing you both were a customer... You were the scraper and the scrapee, so to speak. I imagine you had certain account opening flows where you were trying to rely on this to bring in client data, to create some experience. And then, on the other side of it, you guys probably were the data store that was being scraped and there were some other criteria. So you're probably seeing both sides of what worked and didn't work on this, but I'm putting words in your mouth. I'd love to just go back to day one. What was the problem statement?

Wilson D'Souza: Yeah, I think the problem statement was a few years ago when we were at Fidelity, I think the company realized we started seeing a significant increase in web traffic. And we realized, as we started doing some analysis, a huge amount of that traffic was completely robo- traffic driven by scraping. As you are familiar with screen scraping, and screen scraping doesn't generally care whether you use a third party app or not, it happens every day or every periodic cycle. So we started looking at what are the different kinds of risks that that creates for the company. And we realized that there is a degree of credential sharing that is happening that really exposes consumers to various kinds of risk, whether it's set in the cyberspace, around their privacy and just generally financial risk. We looked at and as I'm sure you've read, there were people trying to use accounts that they've got through some external breach at some other site and generally do the math and say Clayton and Wilson probably use the same user ID and password at a few other places, and then try their luck logging in with those credentials in us, sitting behind some third party. And they may not use that to go and perform fraud, but then they'll take the data from that and have the ability to go and do some social engineering and do other activities with it. So we started, we got along, I think Stuart Rubinstein, who is CEO of Akoya, he and Anil Mahalaha was one of the founding members of FDX. They basically got together with other members of the community, in the financial services industry, and started pushing this mantra of putting APIs and putting everything behind APIs, standardizing the API, and really addressing the gap that's been in the industry. If there were data APIs 20 years ago, there would be no screen scraping, right? You know, skin scraping was a solution to a gap that was in the industry. Clients wanted to use third party apps. So I think that led us to start building our... I'm saying our, I'm no longer at Fidelity. But when I was at Fidelity, the team basically was put together to go and build an API. And I joined sometime just after the API was announced, with I think Stuart and others. And we all got together and realized that, if everyone's building APIs, we all have to do the onboarding. And if you take the simple equation of, if a thousand financial institutions all build their APIs, and then they have to onboard a thousand data recipients, aggregators, Fintechs, and other banks. That's a million conversations and a million legal contracts and a million assessments. That's unsustainable. So that's when we pivoted and created this concept of Akoya and built this two- sided marketplace data network that will connect basically suppliers of data on one side and that's a much more tenable approach for the industry. Right? So we would have a thousand connections on one side on the supply and a thousand connections on the recipient side. So we just took those million conversations and turned them into 2000 conversations. Right?

Clayton Weir: What you're describing makes sense. And I would almost characterize it as, there's obviously a need for an aggregator in this world and historically the screen scrapers had acted as that. But the insight was that you were almost a... became or have become, a captive aggregator. Right? To the captive, to the supply side. Whereas everybody was then bought in on it, had a little bit deeper emotional investment, because it was completely under their control or that the data publishing side felt a stronger voice of how it was being built and that their concerns were addressed, which would increase the supply side.

Wilson D'Souza: Yeah. I think there's a need, like we don't think Akoya... So just to give you some kind of idea about what Akoya is. So we essentially built a platform to eliminate use of credentials at a bank or financial service credentials in a third party. The relationship of a consumer is with the third-party app, right? Our service, whether it's for lending, whether it's for budgeting, whether it's for payments end with the financial institutions. And we wanted to remove the use of credential sharing in that flow. The other piece is if a consumer wants to give access to their data and financial institutions to a third party, they should be able to give explicit enough consent and instructions and also specify what data. It's not unfettered access to all data. And then they should be able to monitor and review and revoke, if the need is no longer there. And so that's the business of Akoya. What we've built is a pass through network, where we manage the onboarding on both sides, and we manage all the assessments and everything else. And then we built the business rules that really allow this data to flow. We don't get in the middle of the consumer authentication, that's done where they should be doing their authentication, but we do manage the operations and we use that to kind of ensure that things consented and instructed by the consumer is what Akoya enables, on both the financial distribution as well as the data recipient on the other side. And to your point, we don't do the stuff that some aggregators do. They qualify data, they add value to that data, they create that data, they do categorization, they may provide more insights. That's not the business variant.

Clayton Weir: It strikes me as maybe a good way to shine more light on this, is let's think of the full stack of activities that have to happen here. So in the Akoya model, there's obviously the publishing side, so that the bank, or I'm assuming it's a bank, but the financial institution in this case, obviously has some account data about Wilson, right? And that's the desirable data in this scenario. So they're going to have to build an API, ultimately, to be able to... They're going to need the mechanism to publish that. So you guys don't play in that layer. They're still on their hook to build that service, right? That raw publishing. And so, where somebody like FDX, who you referenced, comes in, is their job in this stack is to say, well, let's get everybody to build that with roughly the same... Use the same dictionary and let's have sorta the same entities. Let's have that be as mutually intelligible as possible. So that's their role. And also on the publishing side, it's ultimately the banks or the publisher, but in this case the banks, they need to have the ability to present a log to you and present an OAuth token to somebody that says, yeah, that's Wilson, that's his account, you can ping this API. What you guys really do is, before... So do you aggregate that publishing capability, tactically? So do you take those 10 APIs and make it one API for the financial application developer? Or do you just orchestrate the access?

Wilson D'Souza: Right. So we do a few things. So first of all, we manage the initial, what we call, the consent signup, right? So the time a consumer says... Assume they go to an app called Paprika and Paprika is a nice budget app, so they go, I want to add my account at a bank called McComo, and I'm creating fictitious a bank's name and a fictitious app. So in this case, because they are both connected to Akoya and the value of Akoya here is, Paprika needs to connect once and get integrated. They do a single assessment, they do a single contract and the same thing for McComo. So the next time another provider comes in, Paprika doesn't have to do anything extra, other than make sure that they can subscribe to that. So what we do is, at the initial sign- up, we manage that flow more from a routing perspective. So the first time the sign- up comes in, we just route it straight to McComo, who does all the authentication and verification guest the consent. And then it shows us kind of an authorization. This is a very classic flow. And then we use that authorization to fetch the data for the accounts that the customer has selected. And then we issue a percent of tokens, Akoya tokens to Paprika to then use that to basically send the data that was requested. So Paprika cannot take these Akoya tokens and go straight to the source, because they mean nothing to the source. And so we manage all those entitlements in the middle, on behalf of both sides. And with respect to your standards, we do align ourselves very well with FDX and what FDX is doing. But the reality of the matter is, there are some APIs that are better for their roles than FDX, right? So we want to make sure we support those, but we map it out in a variety of gates and compatible access APIs for the applications. And that's one of the biggest values, because then they don't have to worry about 15 different indications, and they don't have to worry about competition or anything else, because we don't compete with them on any front.

Clayton Weir: Totally. So the Paprika sounds legitimately like a real FinTech.

Wilson D'Souza: It just happens to be my favorite spice.

Clayton Weir: It is a top- notch spice. That makes sense. Right? So you're coordinating, you're converting whatever these banks are publishing at, into one API that kind of looks roughly like the screen Bot standard and you're doing all of this very safe token redirect thing and you're getting rid of that. I mean, ultimately one of the core problems of the old model is somebody is storing your bank username and password in plain text somewhere, so the robot can use it. And so that's gone. But what I think is really interesting about what you're doing, from what I hear is ultimately as the consumer, in every other dimension of technology, other than this, right? Other than this proto- open banking and screen- scraping world. Whenever I do these kinds of three- legged token exchanges. So I use Gmail or I use Facebook to sign up for this and that app, I can always log into Facebook and see, oh yeah, I didn't even remember I signed up for that app. Right? But you authenticated this two years ago, these are all the data you're sharing to those guys. You authenticated this five years ago, this is all the data you're sharing with those folks. And I can delete that at any time. And it sounds like for the consumer, ultimately, they're going to have an employee log-in, if they do or don't today, and they're going to see, hey, these are all of these multi- part type relationships you've authorized, in case you forgot, and if you don't like it anymore, you can kill it. Right?

Wilson D'Souza: No. So we actually don't do that. We don't have anything for consumers directly with Akoya. And we made that decision, not lightly, but decisively. We think the relationship of the consumer is with the app that they're using and with the financial institution. And we have no business being in the middle of that. So we don't build an aggregated view of where they are. You know, where they have all their authorizations. They can go to their financial institution. You know, like in the case of... I can use some examples, whether it's Account Save or Control Tower, used by different banks and Security Dashboard for some other financial institution. That's why they go and see who they've granted access to, when they granted access to, and then they can walk and monitor, or continue with it. The same thing when they go to an app, they can see all the accounts that they're connected into and they'll stop using something and it'll say that you can't get any more data, and then they can go and do the necessary. We made this decision because we don't store any data at all with respect to the consumer. Right? So, we don't know who the consumer is. We use an analogy. We're like the US Post Office. They pick up mail from one place and deliver it to the other side, with one extra step. We don't even know who we're delivering it to at that remote destination and we don't know the individual at that destination. We make this because, I think too many folks are playing in the middle with these credentials, and I just don't think a consumer gave Akoya the permission to go and store this stuff. Right? I don't think our clients want us to store that stuff. I believe our value is in building this really open finance network that really enables innovation on both sides, because we think people that are supplying data will also come and receive data from other institutions. Today, they use third parties for that.

Clayton Weir: No, it totally makes sense. That's a very valid point. I mean, if you were to sum it up it's, for you as Akoya, as the middle people, to add any of that kind of marginal value, you have to, by taking on any marginal data into the middle or anytime you guys index data, you create friction in the whole system. Right? You create additional dimensions of friction and risk. No, that totally makes sense. And so the more transparent you are, the more friction reduction there is for all the clients. That totally makes sense. But what I want to challenge you on, was your assertation that the banks somehow do that today. I, and I mean, my retail banking accounts are in Canada, not the U.S. I find that impossible to believe that the banks somehow do that and present that in a useful or visible way to users, right? Where you have made these third- party app connections.

Wilson D'Souza: Yeah. So that's one of the values actually Akoya is bringing. We are building that capability that a bank or a financial institution can call an API or user white label page to actually display that capability into their digital properties. That's exactly why Akoya exists. So this way we can help them with this stuff. Most of the banks, at least in the U.S., a lot of them are ruling on this inaudible, as well as some financial institutions and not just banks. Right? So a lot of them are providing this capability where their customers can actually come and review who they give access to. I'm not a hundred percent familiar with the Canadian banking system. But I think that's going to change there, as well. And I think part of our, part of Akoya is what we're bringing as value to our clients on both sides, is we can help augment some of their, if they need this capability, we can help bring it to market very fast for them. So we have a permission API and they can leverage that and build that digital dashboard of like the Control Tower that Wells Fargo has, or Account Save that Chase has, and build that capability right into their digital properties.

Clayton Weir: I mean, and I don't want to put words in your mouth, but like my opinion is I think, that for some banks, especially for the trillion dollar banks with the scope of their user install base, they probably have a material opportunity to be your real trusted OAuth login for a whole wide range of high- trust tasks on the internet. The way that Facebook or Gmail would be for low- trust tasks. I don't know if you have any thoughts on that, but I think if you start to play that out into the future, the potential is endless. Like these are the trusted, secure brands with deep core informational object about that user. For high contact situations.

Wilson D'Souza: Yeah. I absolutely think the way we manage our platform and the architecture supports significant amounts of different kinds of use cases. We wanted to first focus on the financial data access piece, but the points you just made are absolutely relevant. I think it's a natural evolution that as more parties come on both sides of the network, for different purposes, they can leverage each other's rich capabilities that they already have in the network and make that available to others. And we think we are going to drive more and more use cases, whether it's in the pure financial data perspective, but also in other kinds of financial data, that's not necessarily in a banking or trading or brokerage. We also see this in the lending world, right? You can see that play out, as well. I mean, ultimately yes, we have to understand the data. And I'm saying this with a great degree of humility, having learned very hard lessons about not underestimating the complexity that goes into products. And we think this architecture can scale up for other kinds of use cases like the ones you mentioned. But I do feel like we need to stay focused initially to get all the data on the network, but then I think we can leverage that availability into other kinds of problems that we can solve, that are causing friction in the marketplace.

Clayton Weir: Totally. I mean, the other thing I want to put on there, and I think what's important to say around, where I was postulating is, and it's ultimately at the end of the day, too, that this data does belong to consumers and not banks. And so what's fundamentally different about this, than the Facebook and the Google examples of them being kind of the OAuth hub, or the identity of that for people, is they didn't treat that data with a ton of respect. Whereas I think in the banking world, it is fundamentally different. Where they're recognizing that somebody else's data and the business model is moving it safely, where you want it as the user, under your permission, and making money doing that, as opposed to making money using your data. Right? And I think that's a fundamental and important distinction, as well.

Wilson D'Souza: I do agree. I think, it's easy for anyone to build an app without any level of control or without any controls, or risk management, or having a regulatory body overseeing. I think a lot of the financial institutions have a significant oversight role around how they look at customer data, how they treat customer data, how to get customer consent. I know, in the past there were situations where it wasn't clear whose data it was. I don't think that's the case anymore. I think everyone recognizes this is the customer's data. But I think that is a responsibility that I think all parties are also need to take in terms of what they do with the data. Right? And I think that's the real missing piece. I do think the financial distribution and I'm not saying this because we have investors that represent a lot of the banking world, as well as our old parent company, but I just know from my experience, treating this is in a careful, methodical way has been always the... And I think there's a recognition that this belongs to the consumer and if the consumer wants to use it for you share that data for a particular use case... I mean, I'll use the examples of lending decisions, credit decisions, even simple budgeting, these things should be made available. And I think you're beginning to see some new opportunities come out as more and more APIs come into the marketplace. People are beginning to realize, you know, I can partner with an app to provide a level of capability to my customers, that it'll take me four years to do, or I can partner with someone to do that faster. So I think that's what we're hoping to accelerate in some sense.

Clayton Weir: No, it totally makes sense. And the reason I think banks are going to excel in this world is, ultimately I think, open banking is maybe best described as everything a bank has ever done before, but with the acknowledgement that it's information stored in the vault and it's not dollar bills anymore. And it's the same jobs to be done, keep my data safe, move my data where I want it, when I ask, in a safe way, is no different than keep my deposit safe and move them where I ask, in a safe way. It's the exact same service a bank has provided for hundreds of years.

Wilson D'Souza: Yeah. I have a slight tweak on that, which is, I think part of our job, or if I was a bank, I think banks were, you said If I Ran A Bank was the name of your podcast. I would accelerate API option using open finance standards. And I'm using the word open finance because I think it's beyond banking. Right? There are various kinds of financial services and I really think the more API adoption is done, I think you get higher quality of service, you get higher quality of capabilities, your scale is faster, you can build faster. I think time to market to deliver new services becomes faster. And, as long as you remove the legacy capabilities that you had, which really inhibit your ability to execute on some new capabilities. And I truly, in talking to a lot of the financial institutions, as well as a lot of recipients and Fintechs, and as well as aggregators, I think there's a race on to really accelerate this API adoption across the U. S., but it has to be done in a responsible way. I think it has to be done with consent of consumers. I don't think a third party representing someone and saying, I'm here on behalf of the customer. We use this example, if you walk into a live bank and said Wilson's credentials. Can I do a data check? You know what will happen to you. Either they'll call the police on you or they'll throw you out right then and there. Yet that happens in the digital world today. And we think that's broken. We think the consumer should... So to me, get API adoption done, use open site finance standards and put the consumer in charge. That's what I would do, if I was running a bank.

Clayton Weir: No, totally makes sense. I couldn't agree more with that. And so, I think that this is kind of a logical transition then. So, you talked about, when I was trying to boil the ocean five minutes ago, staying focused, because you're trying to drive adoption on both sides of your business with the core offering. With your starting point and all this has happened. Can you walk us through that? I mean my intuition is, because your organization was very connected to the supply side of this, but what are the challenges on building audience and building activity on both the consumption side and the publishing side of your business, too?

Wilson D'Souza: What is that famous line? What doesn't kill you makes you stronger. And I can tell you the last 15 months have made us very, very strong. You know, we are subject to the same level of rigor and assessment that is done for any third party, right? While we may have investors invest with one lens, from an assessment perspective, we have to go through the same rigor. So the way we look at it is, while we had a better sense of what the supply side looked like, we also had a good sense of what the recipient side looks like. You know, our parent company continues to invest in new capabilities, Akoya as an example, there's many other mini- incubations that do different things, and the company is always looking to try new stuff. So, the things we've learned is that, if you get through the process and do it the right way... For example, most startups at the first year of their incubation, do not go after a SOC 2 type 1, and then a type 2 attestation. But we early on recognized that that was a really important thing for us to pursue because of the business we were going to be in. Of the service we wanted to build, of the network we want to build. So that's something that I think, I would say helped us. And that we learned from our parent company, knowing that how important having some of those controls has helped us fast track some of our integrations. So our focus this year is really getting the supply from the network and getting some data flowing through some early partners on the recipient side. Our expectation is we'll have about 60% of all deposit accounts on the network by the end of this year. Roughly a third of all retirement accounts. About 25% off all brokerage accounts on the network. And then we'll keep building on that. But I would claim and I also don't want to leave you with the impression that we're not looking at other areas. It's just that those are not big areas of focus for us. In parallel, we are incubating on other use cases like the ones you mentioned.

Clayton Weir: Oh yeah. No. I wasn't challenging you on that. No, it makes perfect sense. And so on that, as you're on your journey, tell me about the future? Do you fundamentally think that this, I guess in any dimension... But the specific question I'll ask is, from a regulatory perspective, do you think that there's that market driven approaches, Akoya being one of which, to enable a very uniquely American version of open banking? Is that enough? Or do you think there will ultimately be some kind of regulatory compulsion on this space? Like how do you see the future of that?

Wilson D'Souza: Yeah. First of all, I'll put the caveat, I am no expert on what the government will do or any regulation. I can tell you our mission in life has been to build this utility- like network that should benefit all parties. And we call this three sets of parties, the consumers, obviously, the financial institutions, and we also think the Fintechs and data aggregators, all have to benefit from this network. It cannot be where one of those three parties are not benefiting. Only then I think this network becomes kind of a little bit of a utility. You know, someone recently told us that we could become, that this could be like a commodity. Well, great. That's awesome. Right? So, that's mission accomplished. That it becomes so ubiquitous that everyone's using it and so I think that for us is where we are striving to build towards. That we want to build, and because we don't hold data, we think we can make the argument that we're not going to compete with any of those bodies. That's a big, compelling argument we can make to any one of those bodies. We're not going to compete on getting consumers. We're not going to compete building our own apps to substitute our clients. We've got our capabilities, right? We want to be the engine that kind of removes friction around data, around access, and de- risk the entire... That's the primary motivation. De- risk the entire financial system, at least from a data and credentials perspective.

Clayton Weir: No, I think that makes perfect sense. I just thought, I should've thought of this earlier, but to my knowledge, your core design principle of not really storing data in the middle, certainly not storing anything important. I don't even know that that's practically true of the European open banking model. I imagine there is a design pattern where that does happen, but almost the vast majority of cases, I think there's a middle party managing credential exchange in a lot of those open banking. This is a somewhat of a novel design principle, I think.

Wilson D'Souza: We believe so. You know, we were built not to do data aggregation. So, right at the onset was to solve this. I got sold on the concept of, imagine trying to broker the thousand or two thousand million inaudible into this two- sided marketplace and that is a compelling network to build. And I do believe that that is a unique aspect of what Akoya brings to the table, given that we don't partake in the data sharing, in terms of storing the data itself. Yeah, even from what I've seen with open banking and read with open banking and experienced with open banking, which is largely a UK- based standard, right? That's why we try to use the word open finance. Because people get confused, like isn't the open banking style standard? And I'm like, yeah.

Clayton Weir: They use crosstalk

Wilson D'Souza: So for us, it's more like open finance and really like opening up through safe, secure, transparent. That's our motivation. We feel pretty good about the fact that we're building something that truly does something different than others. I'm not saying that we're the most unique in the world by no means, but it's a different pattern than others.

Clayton Weir: To steal the Silicon valley line, " Sincerely making the world a better place doing stuff."

Wilson D'Souza: Yeah. You know, a lot of us... It's rare where people come out of financial services and become a standalone startup FinTech of sorts. And for a lot of us, I hate to use the word, but it is true, because a lot of our folks truly believe in what we are building and kind of came over as a result of this. And there is a passion, when you build something with purpose and then make sure people are rewarded appropriately for it, there's a different kind of magic that gets created out of that. And for us, it is... I don't know if the world will become the best possible place as a result of Akoya, but I do think it will play a part in at least making it more secure, more safe, and actually allow more innovation in the marketplace. I use the analogy of there are some protocols that were invented 20, 25 years ago that people use today and no one knows who created them. Our hope is we build something that is similar to that. That we become an architecture and a utility that really does that to scale. And we benefit all parties. That's the other important thing. We don't want to put anyone out of business.

Clayton Weir: No, I think those are great sentiments to wrap up on, to rest your case, so to speak. So no, that I think that's wonderful and totally concur in it. I think it's interesting and these conversations around secure and permission and consumer- directed access of these things are so important. And we're just really in the early days of I think ultimately how these ecosystems are gonna look. So I appreciate you sharing your thoughts on this. This conversation has been awesome. I think the audience will really enjoy this. I think you did a really good job of laying out the problem set without getting too far in the weeds. So thanks for your time. I really appreciate it.

Wilson D'Souza: Thank you, Clayton. Thanks for having me and, you know, we'll stay connected, obviously.

Clayton Weir: Awesome. No, looking forward to it and thanks everyone for listening in and giving us your time, as always. Always appreciate you subscribing wherever you get your podcasts, and never hesitate to send us any questions at info @ fispan. com. We'll see you next week. Thanks.