Podcast: Play in new window | Download | Embed
Subscribe: RSS
“I think back to when I entered this industry, myself, back in the late 90s, at Merrill Lynch, where we did build everything. And the reason we built everything is because there wasn’t large commercial vendors in this space. There wasn’t a lot of startups there wasn’t fintechs per se. So we had to build everything.”
— Kevin P. Adams, Principal, Technology, Edward Jones
The WealthTech Today podcast features interviews, news, and analysis on the trends and best practices in wealth and technology for wealth management, asset management, and related areas. This episode is part of our January focus on platform consolidation. We’re talking to influential industry leaders who can provide technology solutions that help advisors build stronger relationships, improve outcomes, and enrich their clients’ lives. A quick shoutout to our sponsor, the Invest in Others Foundation, please go to InvestInOthers.org, and be sure to subscribe to our show wherever you listen to podcasts so you don’t miss future episodes.
Topics Mentioned
- Lessons Learned in Platform Consolidation
- Avoiding the “Old School” Mindset
- Preparing for Future Consolidations
- 3 Tips for Platform Vendors
- Interoperability and APIs
- Advice for Choosing a New Platform
Episode Transcript
Craig: I’m excited to introduce our next guest on the podcast. It is Kevin Adams, General Partner in the technology division at Edward Jones. Kevin, welcome to the program.
Kevin: Good to see you Craig, thank you for having me.
Craig: I’m glad you can make it. I’m glad we worked all this out, you’re busy guy. Where are you calling in from now?
Kevin: I am in Carmel, Indiana where my wife Maggie and I moved almost a year and a half, two years ago now.
Craig: It’s a big change from where you were.
Kevin: It certainly is but we’re really happy to it’s been great.
Craig: The weather is not bothering you.
Kevin: It was a little bit of an adjustment but we have a lot of family here and culturally the Midwest is just more and more akin to the two of us.
Craig: Well, I was always jealous when you were down in Tampa, because I’m stuck here in New Jersey. Now we’re kind of the same, we have similar weather.
Kevin: I think if you lived there year round, you wouldn’t be jealous after a couple of years. When you wake up at 5am and try to go for a run it’s already 100 degrees out.
Craig: Yeah, we all got those problems. Alright, let’s jump into what we’re talking about. So this is part of our January topic on platform consolidation. And again, thanks for being here and sharing some of your experiences and some of your strategies. So let’s talk about large scale platform consolidation projects you’ve been a part of, which ones can you share with us?
Kevin: I can think of several off the top of my head just in the advisory and managed account arena. Having been responsible for wealth management technology, and specifically advisory platforms, now for large wealth managers, I’ve seen a lot of evolution over the past 15 years both in internally developed and also well known, commercial managed account platforms.
Lessons Learned in Platform Consolidation
Craig: When you’ve been around as long as you and I have, you’ve seen a lot of stuff and you start to get the battle scars and see what works and what doesn’t work. So you’ve been involved with more than one consolidation project. I imagine it’s a mix of successes and failures and lessons you’ve learned?
Kevin: Yeah, for sure. I’ll talk about the significant challenges or failures first. One was with a well known commercial managed account platform that was purchased to be leveraged by a global wealth manager replace a legacy end to end advisory platform that was portfolio management, rebalancing and accounting. It was being brought in to replace a mainframe based system with a really old user interface, rather than just use the commercial platform out of the box. The wealth manager had decided to make so much customization to the vendor’s platform, it became a huge burden for the vendor to make and maintain all of those changes. The project was significantly challenged due to that approach, delay of over budget.
Kevin: So lesson number one, don’t try to over customize vendor based managed account platforms, try to use what the vendors built. I’ll often refer to it as the 80/20 rule, don’t let any customization you make exceed 20% of the functionality of the platform itself, and keep 80% with what the vendor or commercial provider has provided. In another example, a large wealth manager who was trying to build everything front to back in the advisory technology space from scratch, the time, the effort, the skill, the resources to build a modern robust managed account platform is something you can’t pull off in two, three or four years without an army of experienced people and a huge budget. Even then trying to get on par or even eclipse today’s commercial managed account platforms is a Herculean effort. Lesson number two, today, a build everything approach is complex. It takes significant resources and that’s people and money, leverage a buy and integrate strategy, even if it’s a hybrid, or a mix of commercial and internally custom technology.
Craig: These are excellent lessons, these can save companies millions of dollars, if only they would listen. One of the jokes I use a lot with consulting as clients pay me for my advice, but I can’t force them to take, it’s unbelievable.
Kevin: Well said.
Craig: Alright, so you’re talking about the 80/20 rule. So what is it about enterprise wealth management firms that push them to overcomplicate things and over customize?
Kevin: Over customization, or over complication sometimes comes from also trying to meet every single need of every single advisor or every single option that’s out there on the market. You have to stay focused on what you’re really trying to accomplish from a business perspective, that’s going to be the most meaningful, again, to the advisors and their clients.
Craig: That’s great advice. It’s really focusing on the areas that your firm can differentiate themselves. No one cares if your rebalancer does X, Y, and Z, it’s not going to change the business you get or whether a client works with you or not, or trusts you or not. But we find that focusing more on front end changes or interface changes rather than back end changes usually is more bang for your buck. Would you agree with that?
Kevin: I would agree with that. Definitely.
Avoiding the “Old School” Mindset
Craig: And in your second example, which we’ve also seen, where firms fall under the spell of the CTO/CIO, who says I can build it, no problem, give me an empire so I can build this. Is that oftentimes what you’re seeing, someone over promising or is it another reason why they’re doing that?
Kevin: Yeah, I think it’s I think it’s an old school mindset. I think back to when I entered this industry, myself, back in the late 90s, at Merrill Lynch, where we did build everything. And the reason we built everything is because there wasn’t large commercial vendors in this space. There wasn’t a lot of startups there wasn’t fintechs per se. So we had to build everything. Fast forward now 20 to 25 years later, there’s a lot of well established commercial providers doing this at scale, and then there’s also been an emergence of a lot of startups in the fintech space, specifically in portfolio management, rebalancing, risk management, tax optimization, model management. So using commercial off the shelf tools is just a quicker time to market. Also, I believe that you gain a lot of intellectual capital from those years of experience of what that product is now being deployed at other wealth managers, that functionality that’s been put into it, others glean as they utilize it, and then they put their own functionality or intellectual property in the platform where others can take advantage of it too.
Craig: All good points. Another thing we see is they don’t firms don’t realize when they want to build themselves that having the vendor do that for you is a huge advantage because they can bring in these features from every other firm that they work with. So you’re getting that benefit of this group, this crowd sourced system that many other firms are adding to and building it yourself, you lose that while of course, you get exactly what you want. You don’t get the benefit of the rest of the industry, feeding in features and functionality to this platform.
Craig: And also you mentioned Merrill Lynch, I think we just missed each other because I worked at ADP, a brokerage services group and they had that division in the early 90s. I think I left there in 98, and Merrill was our first client. So I helped with that. I did that rollout, and that was stock market data back when you could charge for that sort of thing. All good stuff way back in the past.
Preparing for Future Consolidations
Craig: So now we’ve talked about lessons learned post project when you’ve made the mistakes, what about preemptively? What about before a wealth management firm goes into a platform consolidation, even if they’re not even thinking of it, what can they do prepare themselves now, for that possible future?
Kevin: I think all wealth managers, both large and small, should have their finger on the pulse of what other firms are doing from a competitive perspective. And then have depth of understanding how their commercial managed account platforms stack up against their own platform. Then they need to overlay that with their own roadmap and functional needs as a business to see where they’re on par or where the gaps are.
Craig: We’re always looking for ways to think about the future and firms oftentimes wait until the last minute or wait until it’s right upon them to start thinking, and that’s really too late. So when you’re talking about understanding your platform and looking at how it stacks up, would you recommend is that as an annual process or semi annual? How often would you say they should be looking at that and looking at the gaps?
Kevin: The way I’ve seen it done and I think this works well is most firms go through an annual process for prioritization of initiatives, projects, where money is going to be spent, where that money being spent matches the business objectives or the business needs. So I do think annually or in the sense of if you follow a product model and you had a product manager or a product owner, they’re probably spending a lot of time doing that over the course of the year, but certainly at least once a year, that needs to happen only because the advances in the industry, not only their competitors, but also the commercial providers, it’s moving so quickly. Minimum you need to do it yearly.
3 Tips for Platform Vendors
Craig: Excellent advice. So speaking of advice, if you had to pick just three pieces of advice for the platform vendors, the companies that are selling the software to the wealth management firms that will reduce complexity, increase consistency and lower costs, what would those three pieces of advice be?
Kevin: I think first it all starts with data. They need flexible data models, integration layers that make the integration and the flow of data between the back, middle, and front office systems easier. Second, make sure the user experience or the interface of the application is modern, stays modern. No financial advisor or investment professional wants to use a system that looks like it was developed 10 years ago. I think that goes to the point you made earlier around the interface itself that the advisors are going to use. And then third, good interoperability and well defined APIs, application programming interfaces with other commercial platforms so you can build an ecosphere of managed account functionality within the overall wealth management lifecycle.
Craig: That’s a million dollars worth of advice right there I have to say. So when you’re talking about data, and data models, a lot of companies don’t see that as important, they sort of overlooked that. And they just see well, it’s data, we’ll get to it when we need it. But why is it important when you’re talking about the flow of data? Can you talk a little bit about understanding the flow between your different systems and some advice around understanding that and how to make that better?
Kevin: I’m glad you pulled the thread on that one a bit more, because I did start with data. I think focusing on the data ihelps to reduce multiple copies of both operational and transactional data platforms that get replicated throughout a firm, so much to the extent you don’t know where the authoritative source is anymore. It enables that efficient movement and transformation of data across platforms. So modern ETL tools are there continue to grow, continue to be needed to stitch all of these systems together. And so although that’s important, you want to be able to minimize the use of ETL so much to move and transform data. It really provides the right interface for the users and other systems to read and write. And then lastly, it’s around establishing that common vocabulary and helps with data cleanliness, so you know, what data you’re dealing with in a system and really where it came from, why it’s being used, and how it’s being used.
Craig: Cleanliness of data is next to godliness of data. A couple things you mentioned thereall right on the mark. We built a data assessment product that we sell as a consulting product because we’re seeing exactly what you mentioned. They lose the understanding of where their good data is. They no longer have a golden source, because they brought in so many different tools and platforms over the years and no one has gone back and re evaluated, as you mentioned, the operational and the transactional data platforms and how they’re interacting. So that’s spot on, and your common vocabulary also, that a lot of firms as they grow, and as you’ve seen, you’ve been at some of the biggest companies at UBS and Merrill Lynch, Edward Jones, that you’re seeing that firms grow over time, they lose that vocabulary and different teams start speaking different languages about the exact same data and it starts to make it much more difficult to build systems and much more difficult to manage your existing system. So that’s why I pulled that because we’re doing a lot of work on data and it’s it’s a hot button topic for us.
Kevin: You’re very spot on.
Interoperability and APIs
Craig: Your second point, and your third point, so interoperability and API’s, what are you seeing along those lines in terms of the trend? I mean, obviously, it’s easy to say, well, they’re building more API’s, but what is it about the interoperability and the definition of API’s that can make it easier for a consolidation project to succeed?
Kevin: So if I look at the established advisory managed account vendors in this space, and the interoperability sometimes within multiple solutions are products that they sell and generally it’s through acquisition of, you know, competing products that came together under one umbrella over time. I think many of the large commercial vendors out there still struggle with well defined API’s or being able to create that interoperability for those dissimilar or similar systems to communicate with each other. And then if I look at it going outward from there, there’s there’s a reason many of the other vendors that are out there, and I’m not promoting them per se. But those API platforms that exist, they exist because you have to be able to get that data in a common format between internally developed commercial systems and commercial systems. I just have not seen yet any commercial vendor do a really good job at publishing a clean, well defined API spec and then being able to partner with other firms to make their maybe similar but yet competing products be able to work with each other.
Craig: You brought up a good point that a lot of our clients don’t realize is that not only are they merging and growing through acquisition and causing problems and issues in their back office and front office, but the vendors are as well because vendors are snapping up other companies to try to grow. Either they’re PE backed and they need to grab more revenue, or they just see opportunities in the market to build out their platform, they want to have an end to end delivery to their buying up all these companies. And then they’re suffering from the integration problems and the over promises and under delivery and the turnover. And that’s a non functional requirement that we often have clients review is how well is the vendor dealing with their own growth and it’s often opaque, because they don’t know no vendor wants to admit when they’re having these kind of problems. But it’s something you need to realize because basically it’s a marriage for 7-10 years, usually is how long these platforms last because it’s hard to get rid of them. As you you were talking about that none of these vendors have really built out a well defined API that’s easy to use, that’s well documented that has sample source code that has enough staff to support them. So a lot of firms are on their own and they’ve got to work their way through the wilderness through the darkness and build this stuff. Would you agree?
Kevin: I think I do agree. There’s also, going back to the point you you started with earlier around the user interface itself, lot of these large commercial vendors as they’re acquiring firms, yes, the interoperability or the API’s between the the systems are a challenge. But even the user interfaces or the experience for the advisor or client that’s touching the systems and in most cases, it’s the advisor. It could be the same umbrella or the same vendor name, but yet it looks like, it could be six distinct products, but it looks like you’re using six distinct products from six different companies. So also, I think the user experience or the interface of the applications needs to evolve and needs to look common if it’s coming from one provider or one vendor.
Advice for Choosing a New Platform
Craig: Now, one thing I know you’re good at, and I’ve seen you do this, when you when you’re judging at conferences, judging demos, you’re very good at seeing behind the curtain or at least kind of peeking behind the curtain if you can, because the demos always look good, right? They’re only showing the best of the best and the only shown the stuff that works. So what advice can you give to other firms that are getting demos, how can they kind of peel the onion a bit and see is it really working the way they’re telling me it’s working or is there something behind the scenes that’s, that’s not working right?
Kevin: Once you get past the demos, you have to go through, take some real use cases, take some test data, take some dummy data from your firm, and you actually have to run it through their system and run it through the process. It may not be the identical real world use case that you’d have your advisors using, but it needs to be close to it. So that’s one, actually testing the system out.
Kevin: Two, talk to other clients have have a deep discussion with clients that have been on the system, been using it for a while listen to you know the successes, listen to the opportunities, listen to the the challenges they’ve dealt with in the platform. I think those two I’ve seen skipped by firms time and time again, but they just pay off in in the longer term before decision of purchasing something without really trying to put it through some semblance of paces or learning around how it’s performed or how it’s worked with a competitor.
Craig: So true. We often refer to that as user acceptance testing, that you need to build out that test plan. And even when the vendor tells you it’s going to work, you can’t trust them because this is your business and you need to, as you said, run the data through even it’s just a sample to make sure that it works the way they say and also define what it means to accept that. What’s your exit criteria? It’s got to do this, this and this, and here are the things we expect. Have you seen any issues around that where you’re doing your UAT and it’s not working well and how do you work with the vendor to get that resolved?
Kevin: Of course, I’ve seen that.
Craig: I know you’ve seen it!
Kevin: I think I’m going to go away from the functional side for a minute, and an area that a lot of people don’t always talk about or maybe think about in advance coming too close into UAT is really the non functional side, performance calculations, performance of the system, time responsiveness. So when going through that final stage you talk about of UAT that’s really around the functionality of the system, but the non functional side is often either forgotten or not paid as much attention to and in this day and age when you need quadruple nine uptime for these systems because, you know, millions, billions of dollars are flowing through them, that scalability, reliability, robustness of these vendor commercial most of the time, SaaS, cloud based hosted solutions really needs to be tested thoroughly.
Craig: Yes, the non functional requirements are often overlooked to the expense of the functional requirements because the functionals are in front of your face. It’s easier to see those than the non functional. When we’re talking about interoperability, back to integration, when you’re doing platform consolidation, you often have a choice. Sometimes it is a choice of a vendor, which one you’re picking, sometimes it isn’t if you’re acquiring another firm, oftentimes the acquired firm’s software gets nixed. But if you have a choice and you’re picking and choosing, how do you define which applications get integrated, which applications get replaced?
Kevin: That varies so much depending on the business itself. I think and I’ll take the last piece which applications get replaced, some of that starts with the overall architecture of the application. Is it legacy, does it run on a modern stack? Is it something that maybe not as cloud based today? Is it going to be easy to move it into the cloud? Is it secure? Is it performant? Those will help you make that decision. If you’re talking about you know, acquiring another firm where you’re inheriting a technology stack you could spend a lot of time trying to modernize a platform, and you have to balance that versus saying, we’re going to replicate this functionality into something new. That something new could be an internal custom build. That’s something new could be another vendor solution. So I think that’s a really important piece of it, and I wouldn’t call that functional or non functional, but really just the underlying architecture stack, how modern is the platform itself from a technology perspective?
Craig: So when we’re talking about the platform consolidation projects, and how to support them, and give yourself a higher probability of success, one thing you mentioned is the data data models and the data architecture. So can you go a little bit more detail? On how a well designed data architecture supports platform consolidation projects?
Kevin: I believe it starts with understanding and I touched on this earlier, what is the data? Where did it come from? How is it being used? The authoritative source of it, making sure that it’s curated well, it’s managed well, you’re not making multiple copies of it. Other systems are now using it right into it, we’re not really sure where the authoritative source came from, was it derived data? So hence, understanding the depth of the calculation and why that calculation was used and the output. It’s not just about the data in the systems or how they’re being used, but the audit mechanism of understanding if something went wrong, or there was a question about a calculation or trade within the system, being able to understand that whole lineage of the data to be able to recreate that scenario to either validate what happened was actually right, or try to understand what went wrong.
Craig: It goes back to your earlier comment about a common vocabulary which is also I think, can be described as a data dictionary, and be able to build that data dictionary so you know which which data is coming from the source, which data is derived, which data is calculated. And that changes over time you have these slowly changing dimensions over years or more, where the data slowly morphs, nothing big, nothing major, where it’s enough to to get people concerned, but slowly morphing over time. And you wind up with a completely different data set than you had when you started out 7-10 years ago. The common vocabulary also helps with data cleanliness, can you talk a little about specifically when you’re when you’re consolidating multiple platforms, that why is data cleanliness important?
Kevin: I think I touched on it in the last answer, but that cleanliness is important. You’re managing money, you’re rebalancing a portfolio, you’re placing a trade, you’re understanding performance of an account or a portfolio or specific security, that data is everything that’s going to define why you’re doing something or how you’re doing something and making sure you’re doing it right. So hence why all large enterprises in the last 5-10 years have taken data so seriously with data strategies, data architects beefing up their data engineering, data stewards. It’s become such an important factor in financial services and albeit investment banking, capital markets, the sell side, buy side, asset management, wealth management. Data and understanding the cleanliness is one of the most important things that we have to focus on as a firm or in my role as a technologist.
Craig: So we’re running out of time. I want to squeeze in one more question. When you’re consolidating platforms, and we mentioned earlier about replacing platforms or integrating platforms and sometimes you don’t have a choice and sometimes you do, if you’re integrating multiple vendors, what’s some advice you can give firms about that process and how to make it a smooth offering so that in the end you’re getting a best of breed, but you’re not suffering from the the consequences of having different vendors all fighting to get things done?
Kevin: I’ll start with the large commercial managed account or advisory vendors, they need to partner with other firms that may be competitors, so some coopetition to provide a more robust offering end to end for wealth managers, and we talked about this via those well defined interfaces for best of breed components. And the example I would use is you can have Vendor ABC, which may have a robust tax optimization and their engine, Vendor EFG might be best in class from portfolio construction capabilities. They need to work together on their API’s, on the data integration of the product.
Kevin: So think about wealth managers could go out there and pick and choose from the imaginary managed account App Store, so to speak, to implement the best platform that meets their advisors and clients needs. And that’s really talking about that hybrid based solution where it might not be build it all yourself. It might not be just buy one solution and try to force it into your needs, doing a lot of customization. It’s really picking and choosing the best solution and being able to work together. And then from an experience perspective, not just the systems communicating or the underlying data, but that the experience is fairly cohesive for the advisor that’s using a system.
Craig: And with that, I’m going to have to wrap up this interview. Kevin, you said it all you brought everything we wanted to talk about, you covered it in record time.
Kevin: Thank you, Craig.
Craig: You killed it man. So thanks so much for for sharing. Can you tell people listening where they can find out more information about Edward Jones?
Kevin: EdwardJones.com
Craig: Easy. Go to EdwardJones.com. Kevin, thanks so much for being a program. I really appreciate it man.
Kevin: Thank you so much, Craig. It’s a pleasure to see you.
Craig: Talk to you soon.
