FCA Compliance Software Development for UK Financial Services

What does FCA compliance software need to get right?

A financial-promotion pre-check is only useful if a compliance officer can trust it: it has to cite the rules that actually govern the product, catch what is missing as well as what is wrong, and never show a pass it has not earned.

Sector comes first. COBS governs designated investment business, so a regulated mortgage advert is judged under MCOB, insurance under ICOBS and consumer credit under CONC. In the FCA pre-checker we rescued, every scan is routed to the sourcebooks for its sector, with PRIN (the Consumer Duty) and PERG (the financial-promotion perimeter) applied to all of them, and citations to rulebooks that don't govern the product are stripped out.

Most real breaches are omissions, so plain code checks for the warnings a promotion has to carry: capital at risk, past performance, the effect of charges on a quoted figure, and the COBS 4.12A prescribed risk warning, word for word. A flag fires only when a warning is required and missing, so the FCA's own prescribed wording is never flagged.

• Financial-promotion pre-checks for adverts, emails, social posts, web pages, brochures and documents
• FCA Handbook ingestion from the JSON the Handbook's own web app loads, one chunk per provision
• Sector routing across COBS, MCOB, ICOBS, CONC, ESG, SUP, PRIN and PERG
• Deterministic checks for required warnings and prescribed wording
• Change detection when the FCA amends a section your rules rely on
• Audit trails that record the rule-pack version, Handbook snapshot and prompt hash

Why not let an LLM decide what's compliant?

Because a compliance tool that grades the same text two ways can't be trusted, and a model's own severity call can change from one run to the next. In the pre-checker, Claude decides only what is wrong and which rule it breaches, which are genuine language judgments. Code decides how serious it is, from a versioned rule pack: the most serious rule cited sets the severity, and a breach of prescribed wording is always high.

The model is also kept away from questions code can answer exactly. Asking the model about exact details such as a firm's FRN flagged them as missing on essentially every scan, so required wording is checked by deterministic code. Claude's output is constrained to a schema and validated, and every rule ID it cites must be in the rule registry or among the provisions retrieved for that scan, so an invented ID is dropped rather than shown as a real provision.

How do you make every result explainable?

Every scan records the rule-pack version, the date of the Handbook snapshot its rules were verified against, a SHA-256 hash of the system prompt, and the Handbook provisions retrieved to ground it. Any past result can be explained months later, and compared fairly with a scan made after a rule change.

When part of a scan fails, the result says so. If retrieval fails, the scan still runs and is labeled as ungrounded; if the model fails, the deterministic findings are still returned, no risk score is invented, and the user's quota is refunded. A result can show a clean verdict only when both the deterministic checks and the model's review ran.

Rules change, so the corpus is checked against its source. Each Handbook section's last-modified date in the FCA's API is stored with the provisions we ingested, and a change checker lists exactly which sections have moved, so only the affected sourcebook is re-ingested.

Accuracy is measured, not asserted. A 34-case labeled eval corpus covers breaches across sectors, genuinely compliant copy, adversarial inputs including prompt injection, and out-of-scope documents, alongside 250+ automated tests. We won't quote an accuracy figure from it until a qualified UK compliance professional has reviewed the cases.