Journal of Financial Planning: August 2014
Rick Adkins, CFP®, ChFC®, CLU®, is president/CEO of The Arkansas Financial Group Inc. in Little Rock, Arkansas. He served as the 2003 Chair of the Board of Governors of the Certified Financial Planner Board of Standards. Email author HERE.
Over the past six years, I’ve spent a great deal of time working to get our systems truly integrated so that we no longer have to update client data in nine different places. While I have seen great progress in this area, it seems that we’ve simply moved from “no integration” to “pseudo-integration.” We haven’t yet progressed to “real integration” where one software package and one custodian can easily and readily connect data by household. The reason for this lack of meaningful progress is pretty simple—the financial planning profession is a household-based profession trapped in an account-based world.
For virtually every vendor—and regulator—with whom we interact, accounts are the currency of activity, structure, and relationship. From their perspective, everything begins and ends (from a suitability standpoint) with that individual account. There is almost a subtle ambivalence when you move the conversation and focus from accounts to households.
Accounts can be easily tracked and identified because they possess an account number, a tax ID number, and a legal registration. They can be easily and specifically identified. For most people in “financial services,” that is sufficient. For some of these firms, each client relationship involves one or two accounts. As a result, accounts define the relationship pretty well.
Yet, for many of us, accounts are simply the necessary fragments in a much larger picture. Our relationship with our clients involves their overall holdings and the ability of those holdings to help them achieve their goals. Within our world, accounts are simply the fractals possessing tax, ownership, cash flow, and distributory characteristics that we must navigate to avoid unintended outcomes on the path to a client’s goal-based success. They are merely the means to an end.
The Problem
Here are a few problems created by the lack of a household variable:
- Where there are “internal” transfers between accounts in one household, most systems see the money going out of any one account as a withdrawal and the money coming in as a deposit. Thus, both deposits and withdrawals are overstated on the summary page if they aren’t grouped by household and corrected to show their true internal status. (This assumes that your software even separates deposits from withdrawals).
- When handling data with firms other than custodians, if the various records don’t contain a distinct variable connecting it with a household, the effort to make it do so can be immense or impossible. That’s why for years we’ve had to maintain multiple databases.
- When databases are built from account data, one person can end up with multiple records. For example, the first time we imported data from our custodian to our CRM, I was in there nine times because of my various inclusions on personal accounts, corporate accounts, qualified plans, and trusts.
To date, the best we seem to have been able to do is either to use metadata or to “tag” accounts within a specific environment so that within that environment, accounts are grouped together with a tag much like Tweets can be lumped together by hashtags. The most popular tagging method has been to identify one account as “primary” and then connect all of the other accounts (at that vendor) to that primary account. Unfortunately, most tagging methods are only “good” at that one vendor; they don’t translate well universally. A will or trust instrument saved in a document management system has its own set of tagging, distinct from any tagging your custodian may use, and lots of luck if you work with multiple custodians.
My experience over the past few years has led me to one conclusion: For financial planning to continue to progress as a profession and not get totally bogged down in an increasingly technological world, we need to develop a standard for a household variable.
That variable must be developed so that it’s unique to that household across all systems and can be incorporated into the various pieces of software and all of your technological relationships. Let’s face it, how many Bob Smiths do you suspect hold accounts at all of your custodians and vendors?
Possible Solutions
My experience has also led me one other conclusion: I don’t have the answer. As a result, I raise the issue in the hope that enough of you who see the same problem can start offering your possible solutions. Here is what we’ve attempted to employ and what limitations these attempts have posed:
First, we looked at existing variables that might be used as a “grouper.” Tax ID won’t work because any one household of four people might have anywhere from four to 10 tax IDs if you have qualified plans, irrevocable trusts, or charitable trusts. Last name, email, and address wouldn’t work for the same reason. We gave up on this approach.
One of our vendors wanted us to create a variable that they could use to sort our accounts into households. There was a size limitation on the field. As a result, we started using a nine-character “household variable” at that vendor that was composed of (1) the first four characters of the clients’ last names, (2) the first three characters of the primary client’s first name, and (3) a two-digit number beginning with 01. That gave our firm the ability to have up to 99 distinct households with a primary name of Bob Smith, Bob Smithson, Bob Smithers, etc. Unfortunately, that did nothing for our custodians because it would not serve as a unique variable across their systems.
I suspect that the one possible solution will be to create a blended variable. Here’s an actual example that seems to work for one custodian in another situation: they create a unique variable for their retirement accounts by blending the client’s Social Security number with a plan ID number. The end result was a unique variable across the custodian.
The same approach could be taken by custodians and vendors if they blended each planning firm’s household variable with the custodian’s or vendor’s master account identifier for the firms that use their services. The blended variable at one custodian or vendor might be SMITBOB04-08009992. For another custodian or vendor that last group of numbers would be different. Yet, a unique identifier would exist for each household at each custodian or vendor.
Creative Thinking
My hope is that this idea will trigger your creative thinking about ways to solve this problem. If you have any thoughts, please post them in the discussion about this in the All Member Forum on FPA’s social media platform, FPA Connect (Connect.OneFPA.org). The payoff for all of us could be huge in terms of being able to properly connect accounts, emails, documents, and reports to one household, and do so in a way that if you changed any one of the vendors or custodians, the same system structure would continue to work without you having to totally rebuild that piece of the system.
The hard part is that this issue requires homogenous, not diverse examination. Our profession has been built on differentiation, not conformity. We each want to do things in our own way. A variable such as this will require some sort of standard that practitioners, custodians, and other technology vendors could agree upon. I fear that there aren’t enough of us who even care about this to make it worth everyone’s time to develop a solution. I hope that this idea isn’t a pipe dream. What do you think?