Annual review document generation

Annual review document generation is a drafting control, not an advice engine. The model reads structured balances, product inventory, and risk flags, then writes a narrative that points back to those fields. The relationship manager still decides what is true for the client, still completes any blank suitability assessment, and still signs before the pack can leave the bank.

That split is the design. The annual pack is a regulated artefact. Product suitability, client objectives, and "what we discussed" are judgments or records of meetings. An LLM that fills those gaps from tone of voice is not speeding the review. It is manufacturing evidence. Empty fields stay empty.

Relationship and wealth teams spend review season copying CRM screens into Word, then rewriting the same paragraphs for every household. Core and CRM already hold the numbers. The quality outcome is a draft that is faster to check than it was to type, with cites the RM can reconcile, not a letter that looks finished because the prose is fluent.

This work sits next to other review-stage controls. A perpetual KYC refresh can change what the pack may say about identity and screening status. Continuous credit risk reassessment can change flags that must appear in the annual narrative. Neither process replaces the RM's sign-off on the client-facing pack.

The extract comes first. Generation starts only after the pipeline has a frozen snapshot of the fields the narrative is allowed to mention.

Pull from the systems that already act as book of record. In many banks that is a CRM such as Salesforce for the household, contacts, and last recorded activity, plus a core or wealth platform such as Temenos for balances, product codes, and account status. Treat them as a class of sources. The model sees structured fields with names, as-of timestamps, and a null or populated state. It does not browse free-text meeting notes in search of a story.

Minimum extract for a usable draft:

• Account and household identifiers, review period, and the as-of date of every balance.
• Product inventory: code, name, open or closed status, open date, and current balance or valuation where the core stores one.
• Risk and review flags as stored: KYC status, credit or collections flags, open complaints, and any vulnerability marker your policy allows in this pack.
• Last documented contact: date and channel only, if those are structured. Do not pass the meeting-note body unless policy classified it as an approved source.
• Suitability or risk-appetite fields if they exist as structured values. If they are blank, pass blank. Do not infer from product mix.

Merchant spend labels can enrich transaction views elsewhere (merchant category enrichment), but they are not a substitute for an RM conversation. Do not let the annual narrative claim the bank "discussed lifestyle spending" with the client. Propensity scores from cross-sell propensity at account opening belong to origination. They are not an annual suitability finding. Do not import them into this pack as a recommendation.

Freeze the extract. If a balance moves after freeze, regenerate from a new freeze or let the RM edit by hand. Mixing live screens with a stale paragraph is how packs disagree with the statement the client already has.

The generator turns the extract into readable sections the RM can verify in minutes. Every factual clause should carry a cite to a field name and as-of date, in the citation convention operations agrees (inline tags, footnotes, or a sidebar). If a sentence cannot cite a field, it does not belong in the draft.

A workable section order:

1. Period and household covered, citing the review window and party IDs.
2. Balances and valuations, citing each figure.
3. Products in force and products closed in period, citing product codes and status.
4. Open risk and review flags, quoting the flag values, not interpreting them.
5. Recorded contact, date and channel only.
6. Suitability: emit the stored rating if present. If empty, write "Suitability assessment: not recorded" and leave the rest blank for the RM.

Stop after that. Do not add a closing paragraph that "confirms the current product set remains appropriate." That sentence is a suitability conclusion. The model is not allowed to write it.

Illustrative example, not a measured result: an RM covers a joint current account and a stocks and shares ISA. The extract shows current-account balance, ISA valuation, both product codes, a KYC-overdue flag, and a blank suitability field. The draft may say the current account remains open at the cited balance as of the freeze date, the ISA remains open at the cited valuation, and the KYC overdue flag is set. It may not say the RM "talked through retirement goals in the spring," because no structured contact of that kind exists. It may not say the ISA is suitable. The suitability line stays "not recorded" until the RM completes the assessment in the system of record.

The RM's edit pass is expected. They add the meeting that actually happened, complete or decline the suitability section under policy, and strike any sentence that does not match the extract. The draft works when that pass is short because the numbers and flags already match, not because the letter already sounds like advice.

Inventing a conversation the RM never had. Fluent models pad a thin extract with "we reviewed your goals" or "you confirmed you are comfortable with market risk." In a complaint or a suitability file review it becomes a statement the bank cannot evidence. Block meeting-summary language unless a structured contact type and date are in the extract. If last contact is empty, the draft says last contact is not recorded.

Stating a product is suitable when the field is blank. Product mix is not a suitability rating. Tenure is not a suitability rating. A blank field stays blank, including in headings and in any client-facing summary table. If policy requires a completed assessment before the pack can be signed, the workflow holds the item in draft and shows the missing field. It does not let the model guess "appropriate" to clear the hold.

Emailing the pack from the draft queue. A complete-looking PDF in a shared mailbox is not a signed pack. The send path (client portal, secure email, or print) must require an RM or dual-control signature on the frozen extract version. Drafts do not receive client addresses. Queue jobs named "send" that fire on "draft complete" are a control failure, not an automation win.

Watch the template as well: a balance without an as-of date, household figures mixed with personal figures, a closed product listed under current holdings, or an internal-only flag leaking into a client-facing paragraph. Fix the template. Do not ask the model to "be careful."

The operating path is extract, freeze, draft, RM review, sign, then send. Signing binds the client narrative, the extract version, and the RM identity and timestamp. If the RM changes a number, they regenerate from a corrected extract or they record a visible override. Silent edits that leave cites pointing at old fields recreate the copy-paste risk.

Empty fields stay empty through that path. The signature means the RM accepted the blanks as blanks, or filled them in the system of record first.

Annual document generation is not a KYC determination or a credit decision. Those processes may write structured flags into the extract when policy says the pack must mention them. The quality bar is a pack the RM can stand behind because every sentence still traces to a field they can see.