As an engineering problem, it’s deceptively simple to explain how Wealth Wizards gives financial advice: we take data from an applicant, process it, and then generate some artefacts that explain what we’ve recommended. Sounds easy enough, eh? Not quite…
First off, it’s worth noting that financial advice is hard! Giving out the wrong financial advice can bring people to financial ruin and no-one wants to be responsible for that. So producing advice that’s suitable to an applicant’s circumstances (and fully-regulated by the FCA) is essential.
So in engineering our advice we first need to find all the relevant facts about an applicant’s circumstances so we’re not making a decision based on incomplete or inaccurate information. Once we’ve done that, we analyse whether any of those facts might make automated advice unsuitable for our applicant – although we aim to provide instant advice to all of our end-users, there are always going to be individuals with special circumstances which are more suited to a human adviser who can craft a suitable outcome. If the facts strongly support providing automated advice then we look at current market conditions and the range of options we can take, and map the best set of outcomes to the applicant’s personal and financial circumstances.
And in cases where we can’t provide automated advice, we need to be able to pass what we’ve learned on to qualified advisers so they can take the case forward without starting from scratch.
The advice process needs to suit today’s financial realities, but also be suitable and reusable for tomorrow across a range of activities.
One thing we always need is engagement from our applicant throughout the process. Putting your personal preferences and financial history into a computer can be a long and drawn out process and it’s very easy to lose a user as they move through it, so we adhere to UX practices that allow it to be done in small, two-way interactive chunks that engage the user with graphical feedback to show how we’ve interpreted their situation.
We also need everything to be performant, because there’s nothing worse than typing loads of information into a system and then having to wait while a spinner rolls on and on. We aim to make our units of functionality small so they can be fast and unconstrained by other components of our system. This also helps us to release things to production much more quickly when we need to change part of the advice process, and having an efficient Devops culture enables us to deliver that change.
We ensure the information we’re dealing with is stored, processed and delivered with measures that wouldn’t be out of place in a high street bank. Aside from the standard practices of encryption at rest, strong access control for our staff and a strict separation of concerns between developers and operations for applicant data, we also run internal security testing to ensure our authentication and security model is as tight as possible.
Everything we open to our applicants is tested and approved by the best software engineers and financial advisers in the UK.
We develop our products in agile teams. Agility is important as when government regulations change we need to be able to respond to them appropriately and quickly and deploy this as quickly as possible to ensure advice is suitable. On top of that, we ensure every advice outcome is carefully audited. In case we need to trace the decision-making process in formulating a piece of advice, we need a high degree of understandable documentation to outline the rationale for giving it. This is especially useful as we often need to release several iterations of our advice model in a short amount of time, so understanding which versions of our systems provided a piece of advice is critical for compliance activities.
So all in all there’s a lot that goes into providing advice that requires top-notch engineering practices. As a technology firm we’re always evolving our practices as well as our products, and we love anything that makes giving our end-users the best outcomes we possibly can.