Lenders and lessors have moved quickly from asking what AI can do to deciding how to deploy it. Once they decide to use AI agents with their core systems, they face three choices: use an agent from a system of record vendor, bring in a third-party specialist or build their own in house.
Kristian Dolan, CEO of Northteq, says the best answer is often a mix of all three. In this Q&A from the Monitor Podcast, Dolan talks with Monitor Editor in Chief Rita Garwood about who should be involved in the decision, why an AI tool that takes a weekend to build can take far longer to own, how to apply access controls to agents and what lenders should be asking their software vendors right now.
Watch the full podcast below or listen on Spotify.
This conversation has been edited for length and clarity.
Rita Garwood: Today we’re going to talk about AI, which I feel like everybody’s talking about all the time. Lenders and lessors are all eager to get into AI. Where do you see the industry headed right now in terms of adoption?
Kristian Dolan: Great question. For a long time, we were talking about what’s possible at a lot of ELFA and NEFA events. That was a big part of the discussions. But I think we’ve really turned a corner in the last six months to a year. We’re starting to see some big impacts from some of the solutions. There are big gains on the document processing side, and some people are able to remove humans from the loop as far as getting applications in and processing invoices. When you talk to credit folks and asset management folks, they’re all using LLMs to help with credit and with valuations, residual values, things like that. So there’s been a lot of progress. There’s still a lot of fragmentation, but I think people are really starting to see some gains.
Garwood: That’s awesome. I feel like the conversation went from theoretical just a year or two ago to actually implementing all of this, which is so exciting to see. When we were planning this, we talked about three choices that lenders or lessors have when they’re using AI agents with core systems. The first is using an agent from a system of record vendor. The second is using a third-party agent, and the final one is having the lender build its own agent in house. Can you walk us through each of those and how they work?
Dolan: When we talk to our clients and the industry in general, the build-versus-buy discussion comes up, and I really don’t think it needs to be mutually exclusive. There’s a time and place for everything. The way we look at it, there are the system of record providers. That’s the loan origination software, like us at Northteq and our product Aurora, among others. Then there are portfolio servicing companies that are doing the lease accounting, cash receipts, invoicing and things like that. We’re evolving as an industry. We’re building agents, and we’re building capabilities. So that’s one camp of providers.
The next camp is general-purpose AI providers. For example, there are companies like Middesk that are offering KYB agents to do things like check whether a company is really still active based on Secretary of State data, or, if the name is a little different on the application than on the Secretary of State registration, resolve that and decide which one to use. Those are very point solutions that aren’t equipment finance-specific, and there are a lot of third parties offering agents to do that. On the fraud side, there’s also a ton of tools out there to help reduce fraud. They look at documents, look at borrowers, look at personal guarantors and look for fraudulent activity.
And then, like you mentioned, the third is rolling your own. A lot of IT groups are really excited to be able to build out their own solutions, and I think they can. There are so many use cases for artificial intelligence right now that you don’t need to say, “We’re going to build everything ourselves.” You can really use a combination of the different options.
Garwood: That’s awesome. When making the decision about which way to go, who should be involved in that process? Should it be entirely up to the technology team, or should leadership be involved in the discussions?
Dolan: I’m a software engineer by trade. That’s how I started my career, so I’ll tell you firsthand that for a software engineer, everything’s a nail. I want to build my own agents. If you make it a pure IT task, you’re most likely going to end up down that route. Kidding aside, there are a lot of professionals who will steer you the other direction, too. But I think you really need to take a step back and look at what problems you’re trying to solve and what your strategy is.
If this is an equipment finance-specific task, I think the first place to look is your system of record provider, whether that be your loan origination software provider or your lease accounting provider, because they’re going to be focusing on equipment finance-specific solutions. Second, as I mentioned, if you’re dealing with more general-purpose things like fraud or KYB that go across multiple verticals, then looking for a third party is the way to go.
You’ll want to involve your credit team and your leadership in identifying what problems you want to solve and which route you want to go. And then, of course, if it’s really proprietary to you and your business and it’s a differentiator, that’s a great reason to build your own. In other words, the leadership of the company says, “One thing we do really well that differentiates us is how we come up with our fair market value leases, the residual values, or how we underwrite this deal that doesn’t follow conventional underwriting and relies deeply on our own proprietary data and knowledge set.” You’re just not going to find that at the general equipment finance software providers, and definitely not out in the broader market.
So it’s looking at the problem, working with your leadership, understanding your strategy and then choosing the solution accordingly.
Garwood: That makes sense. You mentioned third-party agents like Middesk, or the ones that verify business identities, that plug into your system. What are the advantages of tapping into specialists like that versus trying to build something like that on your own?
Dolan: There are a couple. On the fraud provider side, we integrate with Mastercard Identity, which is a great example of a company that has a broad reach and a network effect with fraud. When these companies can tap into a data set that a local equipment finance software provider won’t be able to, nor will the lender, it’s a great reason to do it. We’re just not going to have the volume and the network effect that some of these larger third-party providers will.
The second is that fraud is such a cat-and-mouse game. You plug one hole and another one pops open, and you’ve got to plug that. It’s constantly evolving. The fraudsters are getting more sophisticated, and they’ll try different ways to do things, so you constantly need to evolve with that. In that hyper-specialty market, it’s ideal to go with a third-party provider, because as a lender your business is not purely fighting fraud. For some of these third parties, that’s all they do. That’s what they focus on.
Garwood: That makes sense. With tools like Claude Code, it’s a lot easier for internal IT teams to spin up their own agents. Why is there so much energy and buzz around building them? And what kinds of situations would it make sense to use them in?
Dolan: Well, let me ask you a question back. Have you tried it yet? Have you gotten on Claude Code and built anything?
Garwood: I did make a web page with it, but I’m a writer, I’m not a coder.
Dolan: It’s cool, right? I think a lot of people are doing that. It’s not unusual to show up on Monday morning after spending the whole weekend vibe coding and say to your boss, “Check it out.” People are using Claude Code, Codex, Copilot or something similar to build out these tools. There’s not a big barrier to entry. The key thing here is two points. One is that it’s fairly easy to build, but that does not mean it’s cheap to own.
In other words, you can get something up and running, but to continually maintain it, keeping track of the cost, the tokens, what model to use, the security, there are just so many aspects. You can spin it up quickly, but maintaining it is a whole different story, and it can be costly.
Now that I think about it, there’s one more thing. This is a small analogy, but rewind the clock about eight years, when Salesforce came on the scene. It was a small blip compared with the AI revolution we’re seeing. But with Salesforce, you saw a lot of lenders say, “We’re going to build out our own systems on Salesforce.” A lot of people did. They invested money, built this stuff and got things spun up really quickly, only to find out that maintaining it, and getting to the end result they wanted, was much more complex in the long term than going to a provider who specializes in this. And there are economies of scale. So it’s a small analogy going back in time, but I think there are some lessons to be learned from that transformation.
Garwood: Definitely. When we met to plan this podcast, you were talking about the 80/20 trap. As you mentioned, if someone spent a whole weekend with Claude and then came back to the CEO on Monday saying, “Look what I built,” what could potentially go wrong in that situation?
Dolan: I’ll use a personal example here at Northteq. About a year ago, we built our first intelligent document processing, or IDP, functionality. Basically, Rita, you throw applications at it, or you throw invoices at it, and it parses out the contents and writes them to the database. We put that in front of clients, and they said, “Well, this is great, but this is not useful.” And you ask, “Why not?” Then you start to peel back the onion. Sometimes the application is wrong, or there’s missing data, and what’s the confidence level? You start asking what sort of user experience you need.
What they really wanted was the invoice on one side of the screen and the parsed-out data on the other. So we built that, and they said, “Okay, this is great, but how do we know the level of confidence for each of these? If the AI transcribes the name wrong, we’re not feeling good.” So we started adding confidence scores. Then it was, “At the end of the day, we’re doing this so we can score deals faster, right?” These are app-only deals, and we want to get them in and scored. What if there’s missing data? I guess we need to go back to the vendor or borrower and say, “We really need your tax ID in order to process this.” So we added sending out communications automatically to get that.
That first release got out quickly. We got to 80% really fast, and it was cool, and we thought we were ready to go. But once you get it in the hands of your users, it took another nine months, honestly, to iterate and make the experience good for them.
Garwood: That makes a lot of sense. That tends to be the case for most things with AI. It looks amazing and fully formed, but when you start getting into it, you find these little holes or things that you missed when you were putting it together.
Dolan: 100%.
Garwood: Beyond that last 20%, what does the ongoing maintenance burden look like for things that you create in house? You gave an example there, but let’s say a lender were trying to do something in house, creating its own agent. What would that maintenance burden look like?
Dolan: There are a lot of considerations. Probably the biggest, most obvious one is token usage, and there are so many choices around that. If you’ve played around with Fable versus some of the earlier models, you notice that they chew up a lot, and you start running out of your tokens. There are also open-source models that you can use for much cheaper. So there are a lot of costs that people don’t think about. If you’re going to use the frontier models for everything you do, it’s going to be very expensive.
There’s also the constant upgrading of the models. New models come out, and they need to be tested and vetted. And there’s the ongoing learning. Some of the skill files and prompts need to evolve as you learn, which goes back to what we were talking about earlier with the 80/20 trap. It’s not once and done. It’s constantly evolving. So the resources and cost are real, both direct, in the sense of tokens, and indirect, in the sense of ongoing maintenance.
Garwood: When you let agents into your system of record, whether you build them in house or through a third party, how should companies think about access controls?
Dolan: Oh boy. Really, you need to treat them like employees, and you might even want to treat them like employees you neglected to do a background check on. When somebody has access to your data via an MCP server or direct API, they can approve deals. Do they have the credit authority? They can change the phone number of a customer. Things like that really need to be guarded. So one thing to think about is access down to the row and field level. What sort of access do you want to give these agents to get at your data? And does your IT infrastructure allow it? That’s super important.
Another is having humans in the loop, at least initially, making sure that things are reviewed. For example, if you’re using an agent to determine residual values, I think we’ve all experienced with LLMs that you do 20 things and it’s awesome, and then you get one random response and you’re like, “Where did that come from?” Having that human in the loop is critical. So are some of the audit capabilities, especially with credit decisions: auditing what’s happening and why decisions are being made. So it’s super important. You need to basically tighten down access as if they’re an employee.
Garwood: We talked a lot about how lenders want to build their own agents. If they’re planning to do that someday and they’re not at that stage yet, what should they be asking their software vendors today about opening up access to their data, such as through MCP or APIs?
Dolan: Great question. There’s been such a big push in the last 10 years to move everybody to the cloud, and there have been some real advantages to doing so. We’re not maintaining hardware in our basements, and we’re not dealing with a lot of the performance and scaling issues we had 10 years ago. The interesting part now, with AI, is: Now that the data is in the cloud, how accessible is it?
The reality is that if you can’t access your data in real time, and I mean the credit scores, the fair market values, the deal status, the missed payments, the phone calls that are made and the checks that are bounced, you’re really limited in what you can do. You’re also limited if it’s read-only. It’s not uncommon for a lot of vendors to provide read-only access to the data, but they’re not going to allow you to write, and long term that’s going to really prevent you from maximizing your ability to build your own agents. And it’s understandable. You definitely don’t want to open up your lease accounting system or your loan origination system to full write access. But there needs to be a path to get there.
We talked about access controls. So I think it’s about working with your vendors. If they don’t have MCP access now, understand what they do have. If they do have MCP servers and APIs available now, understand what those are. Is it read-only? Is it read-write? If it’s read-write, what access are they limiting? What does their roadmap look like? There’s a lot to unpack there.
We’re built on Salesforce, and I think it was probably six to nine months ago that Salesforce announced it was going headless. They talked about Headless 360. It was a pretty big announcement, and basically what that meant was that they were saying, “We are the system of record. We have all this access control. We’ve got the workflows, we’ve got the data, but we’re not going to prevent you, Rita, from building your own agent and accessing your data. We’re going to take the opposite approach. We’re going to embrace it. We’re going to offer these MCP servers, and we’re going to allow you to build your own against your own system of record.” So they embraced it. I think they were pretty early to that strategy, and quite frankly, I think they had no choice. If they hadn’t done that, people would start moving off Salesforce to find solutions they could build their agents against.
Garwood: If your vendor doesn’t offer that kind of access, and they don’t have a roadmap to at some point, what should you do?
Dolan: If they don’t offer it, switching out your portfolio management system or loan origination system can be a big effort and a big cost. Building your own could be an option, but there are still a lot of hurdles, and it’s not very pragmatic right now. So I’d say work with them. First, understand where they’re at. What they’ve built to date is probably a reflection of what they’re going to build in the future. I would lean toward understanding their strategy and what their cost model will be when they roll this functionality out.
Maybe there are options, like getting a replicated database for read access. There might be some interim solutions you can have in place. But ultimately, if you’re going down that path, you’ll probably want read-write access, and you’ll want to work with a vendor that’s leaning into enabling you to do that.
Garwood: That makes sense. The last question I have for you: If the people listening to this conversation today take one thing away about AI strategy, what should it be?
Dolan: I would say choose an architecture, not a tool, right now. Things are evolving so quickly that probably the most important thing is to be in an open architecture, where you can build these agents and have access to your data. You don’t want to put yourself in a corner where the rest of the world has taken advantage of all these AI capabilities, but you can’t, because you made some fundamental architecture decisions early on.
The two big things there are data access and open architecture. Make sure you have access to your data, both read and write. And make sure you have an open architecture where you can add components and come up with your own way of figuring out how a residual value is calculated. Both are critical.
Garwood: Excellent advice. Well, Kristian, thank you so much for joining me today and talking through this topic. I really appreciate it.
Dolan: Thank you, Rita. It was a lot of fun.
