Features

Impact assessments

Pre-deployment Consumer Duty evidence for every AI use case, signed off by a named senior and anchored to the immutable ledger.

Before a new AI use case starts producing customer-facing advice, the firm files an impact assessment against the platform's Consumer Duty template. The assessment walks each of the four PRIN 2A outcomes (products and services, price and value, consumer understanding, and consumer support) and records a risk rating and a narrative per outcome. A named senior (lead reviewer or firm admin) then approves or rejects the draft. The approval snapshot is hashed and anchored to the immutable ledger as the IMPACT_ASSESSMENT_APPROVED event, so the firm can evidence to the FCA that the use case was scrutinised before it went live.

What an impact assessment contains

Use case, a short title (e.g. "GPT-4 fact-find summariser").
Description, where in the workflow the AI runs and what it does.
Model provider & version, optional, but required if you want the firm's enforcement gate (see below) to tie jobs back to this assessment.
Four outcome responses, one per PRIN 2A outcome:
- products_services, target market fit, product governance alignment, guardrails against mis-alignment.
- price_value, whether the AI element changes cost structure or fair-value assessment.
- consumer_understanding, whether clients are told about the AI, and how its role is explained.
- consumer_support, escalation paths, additional support for vulnerable customers, post-deployment monitoring.
Each outcome captures structured responses to template questions plus a free-form narrative and a LOW / MEDIUM / HIGH risk rating.
Sign-off, named approver (must be LEAD_REVIEWER or FIRM_ADMIN), role, and timestamp. The approval event is signed with the firm's ECDSA P-256 ledger key.

Lifecycle

Assessments move through an explicit status graph:

DRAFT, author drafts the content, can edit freely.
PENDING_SIGNOFF, submitted for senior review. Still editable.
APPROVED, senior has signed off. Anchored to the ledger. Immutable from this point, further edits require a new draft.
REJECTED, sent back to draft.
SUPERSEDED, explicitly retired by a newer assessment covering the same use case.

Invalid transitions (e.g. APPROVED → DRAFT) return 409 CONFLICT. Senior sign-off is always performed by an authenticated user; API keys cannot approve assessments.

Enforcement on job submission

Firms have a boolean setting enforceImpactAssessments (defaults to true). When it is on, any job submitted to POST /v1/review/jobs that includes an aiContext with a model must have at least one APPROVED impact assessment matching aiContext.model.provider and aiContext.model.version on file. If there is not one, the submission returns:

curl

409 Conflict
{
  "error": "IMPACT_ASSESSMENT_REQUIRED",
  "message": "No approved impact assessment for openai gpt-4o-2024-08-06. …",
  "details": {
    "provider": "openai",
    "version": "gpt-4o-2024-08-06"
  }
}

Jobs that do not include aiContext are allowed through regardless; there is nothing to match against. Firms that want to disable the gate (e.g. during an initial backfill window) can:

curl

PATCH /v1/firm/me/settings
{ "enforceImpactAssessments": false }

Toggling the gate is itself a compliance-relevant change, so the PATCH emits a FIRM_SETTINGS_UPDATED ledger event carrying the field-level diff and the authenticated actor (user or API key). An auditor reviewing jobs submitted during a gate-off window can follow this trail to see exactly when the enforcement was disabled, by whom, and when it came back on.

Evidence produced

IMPACT_ASSESSMENT_APPROVED ledger event on senior sign-off, containing a hashed snapshot of the approved outcomes, template version, model provider/version, and signer identity.
FIRM_SETTINGS_UPDATED ledger event whenever enforceImpactAssessments is toggled, carrying the field-level diff and the actor.
Both events are signed with the firm's ECDSA P-256 ledger key over the canonical JSON of the snapshot, verifiable via POST /v1/internal/verify-signature.

FCA mapping