Kyle Van Pelt on the Advisor Tech Stack Problem

Transcript:

Brad Johnson: One of the biggest frustrations I see with let’s just say here’s an advisor.

They’ve been doing this 10, 20 years. Maybe they’re gathering 100 million of assets annually and they’ve got a few advisers on the team, 10, 12 team members. That sounds like a pretty good cross-section of maybe a standard firm that would work a Triad. And they’re like, “Wait, I’ve got to be a technology expert, too? It’s hard enough being a financial planner,” and they’re trying to get all of these disjointed technologies to talk to each other, to transfer data so their team doesn’t have to do data entry five different times and five different softwares.

Let’s just talk because you’ve grown up in this, you know, APIs. Maybe you define what an API is for the novice out there, but I feel like it’s a kitchen juncture of technologies in a lot of financial services firms, and like how do you start to see that? I know Milemarker is on a really cool mission. That’s kind of where that all comes together. So, just riff on that a little bit, if you don’t mind.

Kyle Van Pelt: Yeah. Well, there’s a couple of things at play here. So, the first and foremost is the reason why integrations work really well outside of our space is because there’s always a well-defined hub for all of the spokes to plug into. And most of the time that is the CRM because a business like Milemarker, for example, we run everything off of our CRM. And so, we’re trying to get things to plug into that CRM. And so, in the financial advisor space, there’s always for the past ten-plus years, probably even longer than a debate about what the hub for a financial advisor’s office is.

Is it the CRM? Is it the portfolio management system? Is it the financial planning application or is it the custodian? So, not only do you not have a hub, you have four potential hubs. So, if you back up into the shoes of somebody who’s trying to build technology and build integrations, you have to understand that this isn’t as flexible and malleable as some people might want to think.

When you’re going to build an integration, you’ve got to think about what is the most common use case or way somebody would want to do this. So, that’s why integrations and other spaces work really well is because people go, they’re going to be using their CRM in this way, we’re going to build our integration to the CRM so that it creates this great efficiency because we know this is going to be the workflow. Well, when I was at Riskalyze (now Nitrogen) and we built over 30 tools, you try to guess what the most commonly used way is going to be this but most of the frustration you hear from people out there are probably because they’re not using their tools in the way that is the most common use case.

So, you’ve seen this a lot with Michael Kitces, who I know is was just most recently on the show. He’s been advocating for the CRM is kind of the new operating system and saying, “Hey, industry, let’s get behind the CRM being the place that people build to and from.” But there’s still just a ton of firms who believe that their asset management and portfolio management is the value so they live out of Orion or they live out of something like that, or there’s people who are so planning heavy or even risk heavy. There’s a lot of people who run their business with Riskalyze being the hub, and they want that to be the hub. So, that’s why so many people listening to this have probably experienced frustration with integrations, is because you can’t just say, “I want Orion and Riskalyze to talk to each other. Okay, great.” And then the advisor would hope that they can go, “Here’s how I want it to talk to each other.”

You talked about APIs. So, for people who don’t know what that’s like, that’s like Lego blocks, right? So, it stands for an application programming interface. And what that means is here are the six ways that other pieces of software can talk to Riskalyze. And other pieces have the same thing, and you’re trying to stack those together to create a flow but it’s point in time. It’s the same as coming and asking you a question in your office, you giving me an answer, and then I take that answer back and I deploy it. What people want is flexibility and APIs just don’t provide enough flexibility. So I’ll kind of pause there and say that’s really one of the challenges I think that advisors are experiencing when it comes to integrations with their software. And I think everybody’s trying to figure out what’s a better way to do this and how do we think about approaching this in a more meaningful way.