Portfolio Management purple - icon

View Our Brand Assets

Access a suite of logos, fonts and media resources for the AdvisorEngine Brand. If you can’t find what you need, please contact us.

View Assets

Joseph Larizza: Implementing a single repository for data in wealth management

As a financial advisor, precision and timeliness are paramount and effective data management can make a difference.

The financial industry thrives on the accuracy of information, and having data scattered across various systems and platforms can be a significant obstacle to success.

That's where the concept of implementing a single repository for data, or a 'data lake,' in wealth management comes into play.

Joseph Larizza, CEO and president of Mirador has some compelling reasons why consolidating data into a centralized repository is necessary for financial professionals. Here's what he had to say. Click the video below to watch the full interview. 

Transcript:

One of the biggest challenges I see advisors have been asking me is whether they need a data lake – and what they're going to use it for and what value they're going to be able to get out of it. A data lake is essentially taking all the data in your firm and putting it into a single repository so that you can consolidate all of that for reporting. Advisors believe they need to put this data together for either good practice management, good client management or to enhance the client experience. 

Frankly, you don't need a data lake. If you have a performance reporting tool or something that aggregates all of your accounts, and you have a really good CRM, you can use those two data sources as a pseudo data lake without having to build all that technology and take on all that expense. 

The key to implementing a really good data lake without having to build it yourself is to understand what we call the golden source of data. Where is the one place where you can go and you make sure the data is all completely correct? So if your CRM is that, that's great; if your custodial system works for that, that's fine, too. And on the account side, again, your account aggregation systems are a great place to do that. Then, you can marry those two pieces of data together and have the same effect without the cost of that data lake technology. 

If you're going to take this approach, there are two things you should think about. One is what is my golden source of data and enforce that across the entire firm, with no exception. And second, think of the concept of one touch with the data, meaning all the data comes from this particular source and feeds everything else. For instance, if you're answering your phone number in your CRM, your CRM should feed your custodial system. It should feed your client portal; it shouldn't feed your security system. You shouldn't have to enter that data in multiple places.

 


This blog is sponsored by AdvisorEngine Inc. The information, data and opinions in this commentary are as of the publication date, unless otherwise noted, and subject to change. This material is provided for informational purposes only and should not be considered a recommendation to use AdvisorEngine or deemed to be a specific offer to sell or provide, or a specific invitation to apply for, any financial product, instrument or service that may be mentioned. Information does not constitute a recommendation of any investment strategy, is not intended as investment advice and does not take into account all the circumstances of each investor. Opinions and forecasts discussed are those of the author, do not necessarily reflect the views of AdvisorEngine and are subject to change without notice. AdvisorEngine makes no representations as to the accuracy, completeness and validity of any statements made and will not be liable for any errors, omissions or representations. As a technology company, AdvisorEngine provides access to award-winning tools and will be compensated for providing such access. AdvisorEngine does not provide broker-dealer, custodian, investment advice or related investment services.