FCA Targeted Support Decision Model: Solution Documentation

A full-density Rainbird knowledge graph for the FCA's targeted support regime (PS25/22, COBS 9B, RAO article 55A), live since 6 April 2026. It decides, for one firm and consumer interaction (a Support Case), whether a ready-made suggestion may be delivered, which suggestion, on what consumer-segment basis, whether the segment-level suitability and better-position tests are met, what must be disclosed and charged, and — where targeted support cannot help — what the consumer must be signposted to. Every outcome carries the rationale a firm would file for FCA supervision. All firms, consumers, products and figures are fictional; every numeric threshold is firm policy data, because the FCA publishes no thresholds for these situations.

This accelerator is released as an open Accelerator under the MIT licence for demonstration and evaluation. It is a complete, generic reference implementation of the regime, not a product configured for any firm: calibrate the policy surface to your own risk appetite and validate the model against your own cases before any production use. The pack contains the knowledge graph (graph.xml), the Studio test suite, this document, the regulatory cross-reference (which carries the full requirements register and the rule-to-source mapping in both directions), and the MIT licence.

Regulatory verification date: 30 August 2026 (see Regulatory Cross Reference Documentation.md for the bidirectional source mapping).

The graph at a glance

71 concepts, 270 relationships, 341 instances and 286 rules (280 requirement-traced rules plus 6 evidence rules). The graph never consults the wall clock: today() appears nowhere, every date comparison is anchored to the case assessment date, and a filed decision therefore replays identically whenever it is re-run.

The decision chain (16 layers)

1. Perimeter, permission, client status — Part 4A permission for the article 55A activity (an advising permission does not authorise it); no appointed representatives (COBS 9B.2.4G); natural person; UK; trust-based occupational scheme rights outside the perimeter; regime commencement 6 April 2026 (inclusive, probe-verified). All positive determinations — unknown data never places a case inside the perimeter.
2. Initiation, consent, marketing — express request / reasonable grounds (COBS 9B.5.3R); service opt-out (9B.5.14R); PECR reg 22 for electronic mail (consent or the standard reg 22(3) soft opt-in; broadcast and neutral messages outside the marketing rules; objection absolute). The workplace-pension soft opt-in is encoded as PENDING LEGISLATION — it never grants permission and is recorded in the supervisory file instead.
3. Consumer data sufficiency — per-item staleness windows measured against the case assessment date (COBS 9B.5.7R currency is assessed as at the date the firm gives the suggestion, so a filed decision replays identically whenever it is re-run); client verification of possibly-out-of-date information restores reliance on it (9B.5.7R second limb); provenance strength (weak provenance may support an excluding characteristic but never establish an including one); ordinal-keyed contradiction detection regardless of record currency; record-integrity checks (duplicate or missing ordinals block the case).
4. Characteristics — three-valued (has / lacks / unresolved). An unresolved excluding characteristic blocks qualification, so unknown never reads as clear.
5. Segment design validation — the COBS 9B.4 registry defects: no excluding characteristics, granularity floor/ceiling (9B.4.9R), poor-practice characteristics, material or unevidenced assumptions (9B.4.11R), missing better-position definition, the 9B.4.16R(2) two-limb relevance test, missing prevalence rationale, and protected characteristics without an Equality Act justification. A defective segment can never deliver; the defect is routed to governance, not blamed on the consumer.
6. Situation tally — within one situation only one segment may align (9B.4.7R), enforced arithmetically over composed case-and-situation keys.
7. Qualification and alignment — every including characteristic positively confirmed, every excluding characteristic positively resolved, all required data present and current at the assessment date; firm-defined situation priority selects one suggestion per case and records deferrals.
8. Contra-indication and vulnerability — COBS 9B.5.11R information the firm is or ought reasonably to be aware of (including volunteered information with firm routing); FG21/1 four drivers with categorical severity; third-party representation routes to specialist support.
9. Suggestion selection and product scope — prohibited categories (9B.4.42R), complex/illiquid/volatile products (9B.4.43G), express AND implied consolidation (9B.4.38R–4.41G), the annuity limits (9B.4.28R/4.32R/4.33R), cost/target-market/ provider evidencing (9B.4.24G) including the registry-level target-market consistency check, and product-adaptation review (9B.10.6R).
10. Segment suitability and better position — 9B.4.20R suitability is the binding RULE; the better-position test (9B.1.1G/1.2G) is evidenced by the firm's quantified projection method, ex ante, against a no-support counterfactual.
11. Charging and disclosure — third-party benefit prohibition with the 9B.8.3R/8.4R exceptions, fair value (PRIN 2A.4.2R via 9B.4.2R(2); 9B.8.7R), cash-terms charge disclosure (9B.8.9R), differential cost disclosure (9B.8.8R), the full COBS 9B.6 disclosure set, understanding testing (9B.6.9R), durable medium (9B.6.17R), and the article 55A(4)/(5) statement delivered contemporaneously.
12. Signposting — debt advice, regulated advice, Pension Wise (COBS 19.7), MoneyHelper, annuity comparison and brokerage, vulnerability specialist support (plural payload).
13. Automated decision-making — UK GDPR Articles 22A–22D (DUAA 2025); solely-automated cases route to human review as firm policy while ICO guidance is in draft.
14. Candidate outcomes — every stop and withhold state has its own named outcome.
15. Precedence ladder — precedence lives in facts, lowest number wins; consumer- protective and recoverable stops outrank firm-side governance defects; the ladder is total (terminal default: Request Further Data at cf 60).
16. Supervisory file, MI, evidence — delimited positional records (CODE;provision;narrative;status) covering the full audit surface, plus MI fields matching the FCA's announced first-year data collection.

Query surfaces and the voice run-book

Relationship (subject: the case)	Purpose
case has final outcome	THE decision — query this first
case has selected suggestion / case has selected segment	what is delivered and on what basis
case requires signpost / case requires next step	mandatory signposting and actions
case has supervisory file entry	the FCA-supervision rationale records
case has contributing evidence	figures behind each material finding
case has mi field	aggregable MI
segment has design defect (subject: a segment)	registry governance view

Voice latency run-book:

1. Use ONE fresh session per case: co-resident session facts add latency at cohort scale and carry cross-case leakage risk.
2. Inject the COMPLETE payload in one call, including explicit values for all 13 client-stated relationships (all carry allowUnknown — inject or answer "unknown" rather than leaving them to be asked; every question avoided saves a round-trip plus a voice turn).
3. Query case has final outcome FIRST, cold; do not pre-warm with staged sub-queries. Staged warm-up reaches the decision more slowly than a single cold outcome query on the same payload.
4. Fetch narrative surfaces (suggestion, signposts, next steps, supervisory file) AFTER speaking the outcome; they return warm and can stream while the user listens.
5. Clean deliveries are structurally the SLOW class: the graph must prove the absence of every stop condition (the COBS 9B compliance semantics). Early stops short-circuit.

Outcome vocabulary (precedence order, lowest wins)

Out Of Perimeter (1); Out Of COBS 9B Scope Apply Advising Rules (2); Stop Client Declined Service (3); Stop Safeguarded Benefits Refer To Advice (4 — includes the unknown-status fail-safe at cf 85 on pension cases, surfacing as final cf 95); Stop Article 53 Breach Risk Statement Not Delivered (5); Stop Unlawful Initiation (6); Stop Marketing Permission Absent (7); Stop Signpost Debt Advice (8); Stop Vulnerability Referral (9); Stop Contra Indication Signpost Alternative Support (10); Stop Data Insufficient Data Request Issued (11); Stop Service Not Deliverable Design Defect (12); Stop Charging Non Compliant (13); Stop Product Scope Breach (14); Stop No Segment Alignment Signpost (15); Stop Disclosure Set Incomplete (16); Withhold Suggestion Segment Suitability Not Established (17); Withhold Suggestion Better Position Not Established (18); Deliver Targeted Support Suggestion With Adjusted Delivery (19); Deliver Targeted Support Suggestion (20); Request Further Data (21, terminal default).

The registry (all data, no rules)

Eight firm-defined situations across both domains — pensions (increasing contributions / under-saving; choosing how to access a pension; sustainable withdrawal; multiple small pots) and retail investments (excess cash; concentration; tax wrapper; costs). Fourteen segments: S1–S11 compliant, S12/S13 deliberately defective, S14 design-compliant but carrying a prohibited consolidation suggestion. Three firms: Kesterly Wealth (authorised), Brindle Financial (advising permission only — perimeter fail), Oakhurst Appointed (appointed representative — barred). A new segment, suggestion, product, threshold, vulnerability indicator or data item is a data edit; no rule changes.

Design notes: record currency, verification and latency

Record currency is anchored to the assessment date, not the wall clock (TSM-302/TSM-303, COBS 9B.5.7R). Every data record carries an as-at date and a per-item staleness window, and currency is measured with daysBetween(record as-at, case assessment date): COBS 9B.5.7R assesses currency as at the point the firm gives the suggestion, so a filed decision replays identically whenever it is re-run. case has current data item and case has stale data item bind case has assessment date, and today() appears nowhere in the graph. Edge semantics, each pinned by a shipped test: windows are inclusive at exactly the window age; a case with no assessment date can never deliver (the perimeter requires it positively); and daysBetween is sign-absolute, so a record dated after the assessment date is treated by its absolute distance (the data contract expects record as-at dates on or before the assessment date).

Client verification restores reliance on stale data (TSM-303, COBS 9B.5.7R second limb). A record beyond its staleness window that the client confirms counts as current, so verification restores segment alignment as the rule intends. The confirmation flag is deliberately case-global (one confirmation covers all stale items on the case, matching the stale-block design), and the suite pins both directions: verification restores alignment and a surviving contra-indication still stops the case (never a bare delivery), while absent verification leaves the data-insufficiency stop in place.

Clean deliveries are the structurally slow class. A delivery must prove the absence of every stop condition in the COBS 9B chain, while stops short-circuit as soon as one gate fires, so stop outcomes (the majority of real traffic) resolve faster than clean deliveries. This is the compliance semantics of the regime, not an implementation accident; the voice run-book above is the practical consequence.

The Studio test suite

The suite ships 23 tests, every one generated from a live run and shaped Inject → Query → Expect Result with no question steps: zero questions on full injection, engine-exact expected objects and certainties.

• Scenario and policy-boundary tests (11): straight-through delivery (Amara, cf 100), problem-debt signposting and its signpost payload surface, the contra-indication stop (Verity, cf 100), perimeter and appointed-representative breaches, contradictory alignment data, a precedence collision (declined service outranks problem debt), the safeguarded-benefits unknown fail-safe (final cf 95), and a two-sided fringe pair 100 pounds above and below the excess-cash policy floor (the model delivers on one side and stops on the other, so the policy fact is live, not decorative).
• Adversarial and boundary tests (12): currency-window boundaries (record age exactly at the window delivers; one day past stops), future-dated and far-future records, a missing assessment date (never delivers, with no wall-clock fallback), assessment on the regime commencement day (delivers), zero-age records, current-versus-stale contradiction with verification set (still stops), a contra indicator over unverified stale data (the data stop, because the contra gate cannot bypass currency), duplicate record ordinals on a contra case (a designed precedence collision: the contra stop at precedence 10 outranks the integrity stop at 11, and delivery remains impossible either way), and client-verification rescue on one and on two simultaneously stale items.

Two behaviours worth knowing when you extend the suite: unknown never delivers (every delivery is a conjunction of positive determinations, so unknown-heavy runs end in a stop or a data request, never a suggestion), and every numeric threshold the fringe pair exercises is a policy fact on the firm policy instance, so recalibration is a data edit followed by a re-run of the suite.

Datasource patterns (platform and open finance)

Every consumer fact is askable="none" and injected. Feeds: platform system of record (case links, demographics, holdings, pots, CRM flags, contra records, marketing consent), open finance (cash balance, expenditure, debt indicators), client-stated in the interaction (the 13 askables). Each feed lands as a Data Record carrying provenance, an as-at date (per-item staleness windows against the case assessment date) and a unique ordinal (contradiction detection). Data contract cautions: one value per singular relationship per session (first-write-wins, refusals only in the inject warningLog); inject the complete payload before the first query; record as-at dates must not post-date the assessment date; injected conclusions carry a WA:IF: factID and are distinguishable from derived WA:RF: facts — whitelist the relationships your integration may inject.

Persona bank

The Studio suite carries the complete injection payload for every persona it uses. The named scenario personas are Amara Devlin (straight-through excess-cash delivery), Callum Rees (problem debt), Verity Oyelaran (contra-indication, and the verification-rescue cases), Gethin Prosser (contradictory data), Morwenna Vaile (the safeguarded-unknown fail-safe) and Tobias Wrenn (out of perimeter); the adversarial tests add boundary personas for the currency-window, record-integrity and precedence cases. Each test's Inject step is a worked example of the full data contract for its scenario.