How Much of Your SOA Is Boilerplate? The FMA Is Asking

The Test Every SOA Should Pass

Here's a simple exercise. Take the recommendation rationale from your most recent Statement of Advice. Cover the client's name. Now ask yourself: could this paragraph be dropped into a different client's SOA without anyone noticing?

If the answer is yes, that paragraph isn't advice documentation. It's product description wearing advice documentation's clothes.

This matters because the rationale section is the part of the SOA that carries the compliance weight. The disclosure sections, the scope, the fee explanation, all of those can and should be consistent across clients. But the section explaining why this recommendation suits this client is the evidence that the advice was suitable. When it reads generically, the file doesn't demonstrate personalised advice, no matter how thorough the rest of the document is.

What the Regulator Has Signalled

The Code of Professional Conduct for Financial Advice Services deliberately avoids prescribing an SOA format. But the FMA's monitoring work has repeatedly emphasised the substance behind the format: advice must be suitable for the individual client, and the documentation must demonstrate it.

Template-heavy advice documents are a known concern. A document where 90 percent of the text is identical across every client in the book, and the remaining 10 percent is names and dollar amounts, invites an obvious question from a reviewer. Where, exactly, is the evidence that this client's circumstances shaped this advice?

Why Good Advisers Produce Boilerplate SOAs

The uncomfortable truth is that boilerplate SOAs are usually not a sign of boilerplate advice. Most advisers know their clients deeply and reason carefully about their recommendations. The generic document is a symptom of the drafting burden, not the advice quality.

SOA preparation is routinely the largest single time cost in the advice process. Faced with hours of drafting per client, advisers do the rational thing: build a template, and reuse as much of it as possible. The structural sections deserve that treatment. The trouble is that the rationale sections, the hard part, the part that requires the client's specifics to be woven into prose, get swept into the same time-saving approach.

The result is a perverse outcome. The advice was personalised, but the document that exists to prove it says otherwise.

What Personalised Rationale Looks Like

Compare two versions of a life cover rationale.

Boilerplate: "Life cover provides a lump sum payment in the event of death, which can be used to repay debt and provide for your family. Based on our analysis, we recommend cover of $850,000."

Personalised: "With your mortgage at $520,000 and Sarah planning to stay home until Tom starts school in 2028, your income is the household's only income for at least the next two years. The recommended $850,000 clears the mortgage and provides approximately three years of replacement income, which you told us was your priority. You were clear that you didn't want Sarah forced back into work while grieving. We considered a lower sum insured to reduce premiums, but that would cover the mortgage only."

The second version does three things the first cannot. It ties the number to the client's actual situation. It echoes the client's own stated priorities. And it records an alternative that was considered and why it was rejected. That is what a suitability record looks like.

Closing the Gap Without Doubling the Work

The fix isn't "write more from scratch." That just recreates the time problem that caused the boilerplate in the first place. The fix is recognising that personalised rationale is a data problem before it's a writing problem.

Everything in the personalised example above came from somewhere. The mortgage balance and family situation came from the fact-find. Sarah's plans and the client's stated priority came from the meeting notes. The alternative that was considered came from the needs analysis. If that information exists as structured, current data against the client record, drafting rationale from it is fast, whether the adviser writes it themselves or reviews a draft generated from that data.

This is also the honest answer to the question of AI in SOA drafting. AI given thin inputs produces fluent boilerplate at scale, which is arguably worse than the template because it sounds personalised. AI grounded in the client's real fact-find, file notes, and analysis can produce genuinely client-specific first drafts for the adviser to review, correct, and own. The differentiator isn't the AI. It's whether your practice captures client data well enough to feed it.

The Standard Worth Aiming For

Every SOA that leaves your practice should pass the covered-name test: the rationale should only make sense for the client it was written for. That isn't a regulatory nicety. It's the difference between a document that protects you in a review and one that quietly undermines you.

And if meeting that standard currently costs you hours per client, that's not a reason to lower the standard. It's a signal that the process feeding your SOAs, the fact-find, the file notes, the needs analysis, is where the investment belongs.