risk profile series

A look at one way to store risk profile descriptions in the system

In a recent article we discussed risk profiles and said we would use that as a basis for how storing data in the system can lead to better template construction and better outcomes for system support and maintenance.

Where to store the data

Now there are a couple of ways we could go about storing the data in the system rather than the coded template but the most obvious one which probably comes to mind is storing them in the same spot as you actually setup, configure and manage the risk profiles

The code to pull them

Below are examples for the risk profile name for client partner joint and their respective descriptions

Client

<:=$client.risk_profile:>
<:=$client.risk_profile.attitude_to_risk().risk_profile_desc:>

Partner

<:=$partner.risk_profile:>
<:=$partner.risk_profile.attitude_to_risk().risk_profile_desc:>

Joint

<:=$client.risk_profile_j:>
<:=$client.risk_profile.attitude_to_risk(True).risk_profile_desc:>

We call the joint description from the client entity again just adding a ‘True’ argument within the brackets.

Advantages

• A place to store these descriptions in the system and remove the repetition from the template
• This data can be pulled and used for ANY template that needs this information (soa, risk profile questionnaire, wealth review, fact find etc).
• The data is logically stored in the same location as risk profiles themselves are configured.
• This method scales to accommodate multiple assumption sets which can be useful if you are on a site with multiple licensees or businesses.
• It’s clearly quick and easy for any admin person (with permissions to access this section) to update and edited when the time is needed.

Disadvantages

• Only a standard text element (non rich text) so the ability to format or stylise the text is limited – although you might surprised how with a bit of creative thinking you can work around that (see below).

Example:  My kingdom for a rich text element

Storing the data here (or in the system through other methods) will provide a long term value and benefit to most businesses (depending size etc) occasionally though that won’t matter and the preferred format of the client must be achieved.

As a small example I needed to achieve the following output for a particular template:

“You are a balanced investor who wants a mixed portfolio to work towards medium to long term financial goals…”

So the stopping point was this bold text. How to achieve that with this distinctly poor text element?

Potentially a quick fix would have been to just statically add in “You are a” and code the bold risk profile, this way the description text could start at the equivalent of ‘who wants…’. But not all risk profiles started with “You are a…” plus their risk profile questionnaire wasn’t going to have that bold but we wanted to draw from the one source still to reap those advantages.

The solution used in the end was similar to the below.

<:let riskprofile=$client.risk_profile.attitude_to_risk().risk_profile_desc.split($client.risk_profile.lower(),1):>
<:=riskprofile[0]:> <:=$client.risk_profile:> <:=’ ‘.join(riskprofile[1:]):>

# You are a Balanced investor who wants a mixed portfolio to work towards medium to long term financial goals. You require an investment strategy that will manage the effects of taxation and inflation. The risk tolerance of a balanced investor is suitable to strategic, calculated risks designed to achieve good returns.

You can even code in the client/partner/joint/entity names quite easily if it is required that they are within the description, for a personalised effect. The point of this example was to show that with a bit of thought and problem solving you can still use this area if the client has stylistic requirements like the above.

Wait a minute…

You might have noticed that the above example corrodes one of the benefits I mentioned. Namely, if they completely re-write the risk profile descriptions and style of the section in the future, the document wouldn’t merge as they might expect. This is true, although I did build in a mechanism to allow it to revert back to the standard desc call without needing to edit the coded doc.

Ultimately if things change entirely, you often can’t avoid messing with the coded document but in the interim to them doing major changes they will be able to manage, add to and edit those risk profile descriptions with a lot more ease than the traditional alternative (statically coded and repeated in the template and across multiple templates).

Again for sites with multiple licensee or risk profile sets the advantages are just further magnified.

Concluding thoughts

This is just one possibility and maybe it works for some of your clients or maybe it gets you thinking of other ways you could achieve the same benefits. Just one of many tools and approaches to be aware of in developing solutions and making informed decisions on the best approach to meet your client’s objectives.

Ideally also keeping in mind how to reduce issues of support and updating that will (and do) arise in the future.