AI assists with prose; software calculates financial tables. Check the full draft and its source data before approving it.
1.Financial tables are calculated from recorded inputs
Language models are good at prose and unreliable at arithmetic. Bloom instructs the AI to use placeholders for regulated financial tables. Where a charges comparison, projection table, or income schedule belongs, the AI may only leave a placeholder token — and Bloom's calculation engine replaces that token with tables computed directly from your stored client data.
Pension-switch charge comparisons are software-calculated because COBS 9A.2.18R requires the firm to demonstrate that the benefits of switching exceed the costs. That demonstration should never rest on a language model's arithmetic — in Bloom, it doesn't. Projections run through one deterministic engine, the same one behind Bloom's cashflow modelling.
Recognised unresolved placeholders block issuance. Automated checks cannot detect every error: the adviser must review the full draft, including prose, figures and source data.
2.Checks support the adviser’s review
Every drafting request runs under strict anti-fabrication rules: the AI may not invent figures, dates, FCA references, fund identifiers, or provider names, and may not assert suitability the underlying data doesn't support. Where something is genuinely unknown, it must write a highlighted [CONFIRM: …] marker instead of guessing — and those markers glow red in the editor until you resolve them.
After drafting, a separate grounding check re-reads the letter against the client's fact record and flags detected contradictions where comparable source facts are available. The result is stored against a cryptographic hash of the exact letter text — so if the letter is edited afterwards, the stored check no longer matches and must be re-run.
And the client sees the process too: issued letters carry a disclosure in the document itself — “prepared with AI-assisted drafting, reviewed and approved before issue by [your adviser] on [date]” — written by Bloom (never the AI) and filled from the recorded sign-off, so the disclosure is literally backed by the audit record. Your firm controls the wording, or can switch it off.
3.A real approval gate, not a download button
Drafts move through a controlled lifecycle — draft, review, approved, sent — and the transition to “sent” runs through an issuance gate. An automated pre-check against a 24-item FCA-derived rubric must exist for the exact letter text, and a “concern” or “fail” can only be overridden with a recorded reason. The letter's required structure — risk warnings, charges disclosure — must be present and in order, or issuance is blocked outright.
Cases involving defined-benefit or safeguarded pension movement are hard-blocked. No override exists. Every required item on your firm's compliance checklist must be ticked, guarantee findings (GARs, protected tax-free cash) acknowledged, and out-of-date charge data forces a recorded justification. The adviser's sign-off is recorded by identity — who approved it, and when.
4.An audit trail built for file reviews
When a letter is issued, Bloom writes an immutable record: a hash of the letter content, a hash of the client data it was drafted from, the linked pre-check and grounding results, the recorded sign-off, any override reasons, and a hash of the final PDF. Issued letters are locked — revision means duplicating into a new draft with its own version history, never silently editing the record of what was sent.
Every draft version is kept. When a compliance officer or the FCA asks “what did the client receive, what was it based on, who approved it, and what did the checks say at the time?” — the answer is one query, not an archaeology project.
Cashflow reports get the same treatment: every generated forecast — PDF or Word — is snapshotted with the full inputs, the modelling conventions in force, the run-out figures, and a hash of the rendered file. When a client asks about a plan from three months ago, Bloom can show exactly what they were shown, even if assumptions have changed since.
5.UK data residency, and what we scrub before any AI sees it
Bloom's primary data stores run in London (AWS eu-west-2), and hosting is London too. Before text is sent to our AI provider (Anthropic), Bloom replaces direct identifiers with tokens — National Insurance numbers, dates of birth, postcodes, phone numbers, email addresses, sort codes and account numbers — and restores the real values only in the response you see. This is enforced in code, not just promised in a policy. To be straight with you about the limit: client names are not tokenised on the drafting path, because a suitability letter has to be written about a named person and reliable name detection needs a model we do not want in that loop. Names therefore do reach Anthropic, under the contractual protections below.
Client data sent for drafting is not used to train AI models, and transfers are safeguarded by Standard Contractual Clauses with the UK Addendum. If you don't use an AI feature, no data is sent to the AI provider for it. Ever.
6.Meeting notes and soft facts: the AI suggests, you approve, the record remembers
Bloom can turn a recorded client meeting into a file note, a summary, and a set of proposed fact-find updates — incomes, pensions, goals, and the soft facts that explain what the money is for. Every proposal arrives un-ticked. Nothing touches the client record until you tick it, and each proposal carries the literal transcript quote that triggered it, so you approve against what the client actually said, not the AI's paraphrase.
Approved soft facts keep that quote permanently, with the source meeting and its date — and when one is quoted in a suitability report, it's the client's own words that appear, attributed and dated. A fact you promote into the plan as a goal or expense keeps a link back to why it exists. You supply the numbers; the AI never quantifies a client's life for them.
Mentions of possible vulnerability are handled differently on purpose: the AI is forbidden from proposing them as routine updates. They surface as review flags for a human to assess, and reach the vulnerability register only through a deliberate, separate action.
7.What we deliberately don't do
No one-click send: Bloom will not let speed remove the adviser from the loop — the gate is the product. No AI-computed charges or projections: if a number matters to the recommendation, software calculated it. No overclaimed risk profiling: Bloom's built-in questionnaire is labelled exactly what it is — indicative, not psychometrically validated — and Bloom records externally assessed risk profiles alongside it.
And no pretending AI is magic. It drafts. You advise.
Where Bloom uses AI
The complete list. Every row sends data to our AI provider (Anthropic) only when you use that feature, with identifiers token-swapped as described above — and none of it is used to train AI models.
| Feature | What the AI does | The human gate |
|---|---|---|
| Suitability letter drafting | Drafts the prose; leaves tokens where calculated tables belong | Issuance gate: pre-check rubric, grounding check, recorded sign-off |
| Meeting summaries & file notes | Summarises a transcript into a structured file note | Adviser reviews and edits before the note is relied on |
| Fact-find & soft-fact extraction | Proposes updates from a transcript, each with its transcript quote | Every proposal arrives un-ticked; nothing applies without a tick |
| Vulnerability signals | Flags possible indicators from a conversation for review | Never auto-recorded — a human assesses and adds via a separate action |
| Risk questionnaire | The built-in ATRQ's question set was AI-authored, and is labelled indicative | Static content — no client data is sent; external assessments recorded alongside |
See the gate for yourself
We'll walk you and your compliance team through a letter from first draft to issued record — checks, hashes, and all.