Using risk profiles as examples of some broader development topics
Risk profiles or some form of risk aversion metrics, generally form a part of most planners “getting to know your client” process. They are often a compliance requirement for any investment, margin lending, superannuation and pension advice; serving as a guide or basis for the adviser in their strategic and tactical recommendations as well as any portfolio modelling.
Given this, it’s not surprising that they come up a lot in coding and development. Typical documents you might see them in include: fact finds, risk profile questionnaires, advice documents and wealth review reports – to name a few.
Context, configuration and frequency
In terms of the styles and configuration, a broad array of them exist in the industry between licensees, research houses and even from one adviser to the next – in short, risk profile sections come in all shapes and sizes. Usually depending on the business, the importance ascribed to them and the perceived value to the client you may find some risk profiles are brief and concise. Others are comprehensive, spanning a full page or multiple pages and incorporating a host of charts, tables, historical statistics, visuals, growth rates etc.
Risk profiles and the assumptions or statistics for them can often be reviewed or updated on an annual basis. Depending on the type of xplan site and licensee(s), sometimes more frequently. So this data will change and we should build systems that allow for it to easily be updated.
The problem
Both historically and in the present day, we typically find a pretty consistent theme; that these sections are repetitively, tediously lengthy sometimes spanning anywhere for 10-40 pages in the coded template.
This occurs for 2 reasons
- Storing the data in the template rather than the system and;
- Using basic iteration techniques
They also often include static risk profile names, so if the risk profile name changes (as does occur on occasion) even changing the risk profile name from balanced to Balanced, can break templates.
Storing data in the template
Statically coding in data (risk profile names, descriptions, min/max/target tables, images etc) should be avoided as much as possible. Storing data dynamically gives the following benefits:
- Dynamic templates are shorter, often easier to read, less error prone and generally superior to static building models;
- Data stored in the system can be used in any number of documents
- Data stored in the system needs to only be written and updated once, the change then flows down to ALL your documents that draw on this.
- Editing a risk profile description and changing some numbers or a diagram is easy. Doing so within a coded template for clients, regular xplan users or administrators is not as easy and in the worst cases can break documents and cause all sorts of issues. In essence dealing with coded templates is a riskier proposition that can be avoided by storing information with the system.
That’s a lot of powerful benefits for our templates and for our clients or admin users who support and update these things in the future.
So what are we going to do?
With this all in mind we are going to use risk profiles as a basis for some future articles over the coming weeks that will link back to this.
The end result of these successive articles will be you can migrate to models of storing the data in the system allowing for better more efficient support and maintenance. Combined with utilising better coding techniques we are going to get your risk profiles down to a handful of coded lines on a single page.
The risk profiles will serve part of the basis for practical examples for these new methodologies.
