All articlesFR

AI in Financial Planning: Capability Was Never the Hard Part

Every planning platform now has an AI story. The pitches have converged remarkably fast: the software reads the client's situation, produces the analysis, and hands you something close to a finished plan.

The demos are impressive. They are also answering a question advisors were not really asking.

Capability is not the constraint. Language models have been able to produce fluent, plausible financial commentary for several years, and they can now read a stack of statements faster than any person. The constraint is accountability. You sign the plan. You sit across from the client. If a regulator asks why you recommended a particular drawdown sequence, "the model suggested it" is not an answer.

That asymmetry should drive how advisors evaluate AI in planning software, and it mostly does not.

The Accountability Gap

When a plan goes wrong, the consequences do not distribute evenly between you and your software vendor.

The client's outcome is worse. Your relationship absorbs it. Depending on severity, your regulator and your errors and omissions carrier become involved. The vendor, in almost every case, has a limitation of liability clause and continues its quarter unaffected.

This is not a criticism of vendors. It is simply the structure of the arrangement, and it means the question "can the AI do this?" is less important than "can I defend what it produced?"

Those are different questions, and only one of them shows up in a demo.

Autonomy Is the Wrong Axis

Most AI marketing in this category sits on a single scale: how much of the work the software does on its own. The further along that scale, the better the demo.

A more useful way to think about it is the way you already think about people. A good associate in your practice does a great deal of work. They read the statements, enter the figures, draft the scenarios, prepare the report, and flag what looks off. Nobody worries that the associate does too much. What makes the arrangement safe is not how little they do. It is that their work comes to you for review before it reaches the client, that the numbers come from the planning software rather than their head, and that the file shows who did what.

Apply the same test to AI and the question changes. Not "how autonomous is it?" but "who approves its work, where do its numbers come from, and what record does it leave?" An AI that does a lot under those conditions is more useful than one that does a little without them.

Where AI Genuinely Helps

Used in the right place, AI does real work that nothing else does as well.

Gathering. Reading a T4, a CPP Statement of Contributions or QPP Statement of Participation, an insurance policy or a T2 return and mapping the figures to the right fields is slow, error-prone work for a person. It is well suited to a model, provided the advisor confirms what was mapped before it becomes part of the plan.

Catching what is missing. Omissions are harder to spot than errors, because nothing on the screen looks wrong. A client with a spouse and no beneficiary designation on a RRIF. A business owner with a holding company whose succession has never been modelled. A plan that never tested an early death scenario. Systematic checking for absence is genuinely hard for humans and well suited to software.

Answering in the moment. A client asks what happens if they take QPP at 72 instead of 65, or retire two years earlier. An AI that answers from the plan's own figures, and drafts the question as a scenario you can review afterwards, keeps the meeting moving without inventing anything.

Explaining in the client's language. Turning a projection into prose a client understands, in English or French, is a legitimate strength. The numbers are already fixed; the model is helping you communicate them.

Notice what these have in common. In each case, the AI either prepares material a human confirms, or operates on numbers produced by something else. A person decides what reaches the plan and the client.

Where It Should Not Be Trusted

The numbers themselves.

Language models are probabilistic. Run the same prompt twice and you can get different output. That property is a feature in writing and a serious defect in a projection engine, because financial planning requires the opposite guarantee: the same client data must produce the same figures every time, in the projection, in the on-screen chart, and in the printed report, this month and next year.

You cannot audit something that will not reproduce. If a client asks why last quarter's plan showed a different number than today's, "the model computed it differently" ends the conversation badly. And a compliance review is precisely an exercise in reproduction.

This is why the architecture matters more than the feature list. A deterministic engine computing the numbers, with AI reading, checking and explaining that engine's output, gives you both things: analysis you can defend and assistance that is genuinely useful. A model generating the figures directly gives you fluency without traceability, which is the worst combination available, because it looks the most convincing.

Four Guardrails That Make AI Defensible

If accountability is the constraint, the guardrails are what turn an impressive tool into one you can use with clients. Four matter most.

The advisor approves every change. The AI can propose, draft and prepare. Nothing it does should reach the plan until you accept it. A tool that writes silently into a client file fails in the worst possible way: you find out later, and usually from the client.

Every number comes from the engine. The model should cite figures the deterministic engine produced and never generate one of its own. When it explains why the OAS recovery tax bites in a given year, the income figure it quotes should be the one in the projection.

There is a record. One reviewable thread per client, showing what was asked, what the AI proposed and what you approved, gives your team continuity and gives compliance something to read. Without it, AI assistance leaves no trace in the file, which is a problem the first time anyone asks how a recommendation was reached.

Client data stays where it should. For Canadian advisors this is a privacy question before it is an AI question. Where is the data stored? Is it used to train models? The answer belongs in writing rather than in a demo.

The Regulatory Direction

Canadian regulators have not issued planning-specific AI rules, and advisors should watch that space rather than assume it stays quiet. But the existing obligations already point clearly.

You are required to know your client, to have a reasonable basis for a recommendation, and to be able to explain it. None of those obligations transfer to a vendor because a model was involved. If anything, using a tool you cannot explain makes them harder to meet. This is a general observation rather than legal advice; your compliance team and your regulator's guidance are the place to confirm what applies to your registration.

The practical standard to hold software to is simple: can it show its work? Not "does it have AI," but "when I ask why this number is what it is, does the tool answer, and is the answer the same every time?"

Questions Worth Asking a Vendor

Six that cut through most AI demos.

Does the AI produce the numbers, or read them? This is the single most clarifying question, and vendors answer it very differently.

If I run the same client twice, do I get the same result? Ask them to demonstrate it rather than confirm it.

Can I trace any figure back to its assumptions? Pick something deep in the projection and follow it.

What happens when the AI is wrong? A tool that puts suggestions in front of you for approval fails safely. A tool that changes the plan on its own does not.

What record does it leave? Ask to see the history for one client: what was asked, what changed, and who approved it.

Where does my client data go, and is it used for training? Get the answer in the contract or the privacy policy, not just the sales call.

The Position Worth Holding

AI belongs in planning software. Advisors who refuse it will spend time on work that could be delegated, and they will communicate less clearly than colleagues who use it well.

But the value is in supervised assistance, not autonomy. The category markets autonomy because it demonstrates better. The more useful model is the one your practice already runs on: capable people doing real work, reviewed by the person who signs.

That is the model we built Finn, PlanBase's financial planning associate, around. It gathers, builds, checks and drafts; every figure comes from the deterministic engine; you approve every change; and each client has one thread your team and compliance can read. The advisor is accountable for the recommendation, so the advisor has to remain its author. Software that respects that constraint is more useful than software that pretends it away, and considerably easier to defend when someone asks you to explain your work.


Finn works for the advisor, never directly for the client. Every figure it discusses comes from PlanBase's deterministic engine, nothing reaches the plan without your approval, and client data is stored in Canada and never used to train AI models.

All articles