Product risk assessment has a lifecycle problem

Key takeaways

• Pre-launch product assessment is mandatory across UK and EU financial services, but regulators continue to find that the existence of a process does not necessarily mean the underlying analysis is strong.
• The process fails in three places. Every assessment starts from a blank page, the reasoning lives in a few senior heads, and the risks fall away the day the launch is approved.
• Language models can genuinely read a product proposal now. Assessing one is a different job, and it takes a governed framework: a register of product features, human decision points, and evidence a reviewer can actually check.
• Zango turns the underlying product proposal into a scored and evidenced draft assessment and committee pack, while leaving material judgements with the relevant people and, crucially, recording how those judgements were reached.

The reality of product risk assessment today

Before a regulated firm launches a product, or changes one in any way that matters, someone has to work out what could go wrong. Who’s this for, and who is it explicitly not for? Is the pricing fair, and would it still look fair in a thematic review two years from now? Which obligations does it trigger? What happens when the third party holding a critical function has a bad week?

None of this is optional. The FCA’s product governance sourcebook requires manufacturers in its scope to run a product approval process before anything reaches a customer, and the Consumer Duty stacked a target market assessment and a fair value assessment on top. The EBA’s product oversight and governance guidelines have demanded the same discipline for retail banking products since 2017. And judging by the FCA’s 2024 thematic review of insurance product governance, plenty of firms still get it wrong. In fact, that review reads like a regulator running out of patience.

Here’s what the work actually looks like. A proposal arrives from the first line, 15 to 30 pages, written to win an approval rather than to surface risk. A senior reviewer reads it twice. They pull out the features that matter, fill in the firm’s template (version six of it, usually), email Legal about the perimeter question and Financial Crime about the merchant exclusions, and wait. Eventually they draft the committee pack, reconcile figures that never quite reconcile, and present. Approval arrives with conditions attached.

Then everyone moves on to the next launch.

And count what actually flows through this process in a year. Every new launch, yes, but also every repricing, every vendor swap, every material change to a journey, and the annual review of everything already on the shelf. At most firms that is a steady queue, and nearly all of it crosses the same two or three desks.

I’ve sat in enough product committees to respect how much genuine judgement goes into a good assessment. I’ve also watched a lot of that judgement get spent on transcription. Reading, extracting, reformatting, chasing people for answers. Days of a senior specialist’s time per product, on a queue that sits directly in front of revenue.

The real problem: the assessment does not survive the product

The most obvious complaints about product assessment are usually about capacity: too many assessments, too few reviewers and committee dates slipping because the analysis has not been completed. But those problems sit on top of a more structural weakness in the process.

The first problem is that assessments often begin from scratch. A reviewer who worked out last year how an instalment feature interacts with credit regulation may end up doing much of that thinking again when another team proposes split payments. Two assessments of essentially the same feature can then reach different conclusions without anyone noticing.

The second problem is that the chain of reasoning often lives in people’s heads. Experienced reviewers know which features trigger which obligations, what risks follow and which controls should mitigate them. In many firms, that logic is not captured systematically, so assessments slow down when key people are unavailable and knowledge walks out of the door when they leave.

The third problem is that the assessment often stops at approval, even though the risks do not. Delivery risks may genuinely close out at launch, but many others remain. Fair value can drift, customer behaviour can differ from what was expected, a decisioning model can perform differently at scale, or a third-party dependency can become more significant over time. Yet the original assessment is often treated as an approval record rather than something used to manage those risks over time. A later pricing change, for example, may never trigger a review of the assessment that approved the original design.

An assessment that can’t outlive its approval meeting is a record of a decision, not a control.

One-off documents vs a connected assessment

What AI has made possible (and what it has not)

Large language models can now genuinely read a product proposal, and the reading is good. Given a detailed document for an instalment lending product, a model can identify that the structure creates a regulated credit agreement even where the proposal itself does not use the word “loan”. It can compare an executive summary describing a product as free with a fee table later in the document, or identify that a decisioning model relies on a proxy which the proposal itself says has not yet been adequately tested.

So why not paste the proposal into a chat window and ask for a risk assessment?

Because you’ll get one, and it will look plausible. But run it again tomorrow and you’ll get a different one, also plausible. No framework underneath, so nothing forces consistency between products or between runs. No citations back to the document, so checking its reasoning means redoing the work. No sense of which of its own calls were shaky, so everything arrives wearing the same confidence. And when the session ends, it remembers nothing.

Models also get things wrong, confidently. That has to be treated as a design constraint. Material decisions in a product approval process ultimately need to sit with identifiable people who can examine the evidence, challenge the reasoning and take responsibility for the outcome. Human review therefore needs to be embedded in the operating model rather than added at the end as a nominal sign-off step.

The interesting question is what the model has to be connected to, and where the humans stand, before that draft deserves a second line’s signature.

The spine of it: a register of product features

Our answer starts with a register of product features. This gives each assessment the same underlying structure rather than asking every reviewer to start from scratch.

Any financial product breaks down into features that carry regulatory significance. Tiered pricing is one such feature, as is automated creditworthiness decisioning, cross-selling to an existing base, reliance on a single critical supplier, an introductory fee waiver. A current account with split-payment functionality may have twenty relevant features, while a money market fund will have a very different set. The product is new; the features almost never are.

Each feature in the register is linked to the regulatory and risk implications that normally accompany it: the obligations it may engage, the harms it can create and the controls ordinarily used to mitigate those harms. Automated affordability decisioning, for example, may engage creditworthiness requirements and rights associated with automated decision-making. Potential harms include unaffordable lending or biased outcomes for groups on which the model has not been adequately tested. Relevant controls might include model validation, a route for human review of declined applications and appropriate fairness testing.

Experienced second-line teams already understand most of these relationships. The purpose of the register is not to replace that expertise, but to turn it into something that can be applied consistently. The analysis is written down once, reviewed and versioned, and can then provide the starting point whenever the same feature appears in another product.

One feature, unpacked

This is what makes assessments more consistent. Where two products contain the same feature, the assessment begins from the same underlying interpretation regardless of who wrote the product proposal or which reviewer happens to pick up the work. Rather than treating each assessment as an essay written from a blank page, the reviewer is decomposing the product against a framework that the firm itself governs.

Two characteristics of that framework are particularly important. First, it is versioned and immutable, so changes are subject to recorded review, published versions carry a changelog and each assessment is pinned to the version of the framework used at the time. That means it remains possible to establish what the relevant framework said when a historic approval was made. Second, the register is able to expand under governance as new product features appear.

There is also a legitimate question about who determines the content of the register. Our baseline was developed from relevant rulebooks and refined against real assessments, but it is itself subject to review rather than treated as authoritative by default. Firms can also apply their own risk taxonomies and impact matrices, so the assessment can be scored using the framework they already govern. Where scoring depends on defined bands or arithmetic, those calculations are performed deterministically rather than generated by the language model.

How a run works, and where the humans stand

A run moves through a series of stages, with three clear review gates where material decisions are routed to a person.

From product document to committee pack

The process begins with the materials the product team has already produced. These can include PDF, Word and Markdown documents, attachments and journey screenshots, so information contained only in a screen mock or journey diagram is still available to the assessment.

The first output presented to the reviewer is effectively a structured interpretation of the product: journeys, money movement, fees, third parties, data flows, target market and other relevant characteristics, together with information the source material does not contain. Missing information must either be provided or consciously skipped, with a reason. That reason is retained and carried into the final committee pack rather than disappearing during the process. Gate one.

The product is then decomposed against the feature register. Each detected feature is presented with supporting evidence from the source material, allowing the reviewer to confirm the interpretation against the text rather than simply accept a model output. Where the evidence does not support a confident conclusion, the feature is routed separately and the reviewer decides whether it belongs. Gate two.

The feature gate: confirmed, routed, and discovered

The same gate is where the register grows. If the product contains a feature the framework has not seen before, it is surfaced as a candidate rather than quietly forced into an existing category. If accepted for the assessment, it is clearly identified as new and is separately queued for consideration as a permanent addition to the standing register. The immediate assessment can therefore take account of a novel issue without allowing the model itself to alter the governed framework.

The next stage is the risk analysis. Risks are drafted and scored with their underlying causes, inherent score, relevant controls and residual score. Where the residual score is reduced, that reduction is tied to named controls. Some risks should reduce significantly because the design contains effective mitigations; others should remain largely unchanged where the underlying exposure cannot realistically be removed through product controls.

The reviewer can inspect and flag any of these risks before the pack is assembled. A flag does not simply disappear or prevent completion of the run; it remains attached to the relevant risk so that the governance body can see that the issue was raised. This forms the third review point.

Transparency here isn’t a dashboard we bolted on. It is the evidence trail itself: the source text supporting each feature, the decisions routed to a reviewer, the reasons recorded for missing information and the exact register version used.

The second line opinion stays a blank, human-owned section. The machine drafts everything around it, but it doesn’t get to hold the pen on the judgement.

The committee pack

Everything above exists to produce one artefact: the pack a committee actually reads, assembled rather than transcribed.

The pack begins with an executive summary and product profile, followed by the target market and fair value assessments. The risks are presented both in summary and in greater detail, including their causes, inherent and residual scores, credited controls and the reasoning supporting the assessment. The pack also includes the regulatory mapping, identified coverage gaps, control gaps and recommendations, together with any consultations required under the firm’s governance framework.

The approval path and governance tier are calculated from the same underlying assessment. Information that was missing during intake, including any reasons recorded for proceeding without it, is also carried through so that the committee can see the basis on which the analysis was completed.

Review triggers can then be defined at approval and linked to the metrics relevant to the product. The intention is that the circumstances in which the original assessment may cease to be reliable are documented at the same time as the approval itself, rather than being reconstructed later. Approvals remain associated with the same assessment, which can also be exported into a conventional document where required.

Because each section is generated from a common underlying assessment, figures and conclusions do not have to be copied manually between different documents or versions. For teams accustomed to reconciling committee packs immediately before a meeting, that is a fairly practical benefit.

Scored risks: inherent to residual, with the reduction attributed

What this looks like in practice

Consider a bank proposing to add split payments to its current account. The product proposal is twenty pages long and contains journey descriptions, a plan-mechanics table, vendor arrangements, rollout phases and a number of unresolved questions linked to separate memos.

In a conventional process, a capable reviewer may still produce a strong committee pack, but contradictions can survive because the relevant information is scattered across the proposal. The executive summary might describe the product as free to use while a table on page eight includes a £6 missed-payment fee. Both facts are present, but identifying the tension between them depends on the reviewer joining them together during a manual read.

In the assessment process described above, those statements are extracted into the product profile and can be presented together. The relevant credit features are identified with supporting quotes, an uncertain outsourcing issue can be routed to the reviewer, and a potential statutory liability issue contained in a memo reference can be surfaced for consideration as a new register feature.

The same information then flows into the risk analysis. The tension between “free” positioning and a missed-payment fee can become an explicit conduct risk, with its inherent score, relevant mitigations and residual score set out for review. If the proposal includes a grace period and appropriate disclosure journeys, those controls can be credited specifically. The fair value assessment can also identify material information that is absent from the proposal, such as the lack of benchmarking of the fee against comparable third-party providers or the underlying cost of collections.

The resulting pack can therefore be assembled without the reviewer manually recreating each stage of the analysis. The benefit is not just that the review takes less time, but that more of the reviewer’s time can be spent on the points that require judgement, such as resolving uncertain classifications, challenging the risk analysis and writing the second-line opinion.

For the product team, that can also reduce the amount of avoidable iteration before committee because missing information and inconsistencies are uncovered earlier in the process.

Three questions worth asking

There are three useful questions for testing whether a product approval process is fit for purpose.

The first is how long it takes, once a product document arrives, for the relevant team to identify the obligations engaged by the product and the material harms that could arise, with enough evidence and structure for those conclusions to be reviewed. If the answer is measured in weeks, the bottleneck isn’t your committee calendar.

The second is what happens to the risks identified in the last product approval once the product is live. If a fee changes, customer behaviour departs from expectations or a key performance indicator moves materially, there should be some way of determining whether the assumptions underpinning the original assessment remain valid.

And finally, the one that gets to the heart of it all: does your assessment process record what it was unsure about? Clean conclusions read well in a pack, but the uncertain calls are where the risk actually lives. A process that can’t surface them, route them to a person and record who resolved them is asking the regulator to take its confidence on trust. Any AI you put in front of that process should be held to the same standard.

‍

Zango is the AI compliance layer for financial institutions. Product risk assessment turns a product proposal into a scored, evidenced draft assessment on a governed feature register, with reviewers deciding every call that matters and a committee pack assembled from the result. To see it run on one of your own products, speak with our team.

‍

Sources & further reading

• PROD 3 Product governance (FCA Handbook)
• PRIN 2A.3 Consumer Duty: products and services outcome (FCA Handbook)
• Consumer Duty: findings from our review of fair value frameworks (FCA)
• Price and value outcome: good and poor practice update, September 2024 (FCA)
• TR24/2 General insurance and pure protection product governance thematic review (FCA)
• Guidelines on product oversight and governance arrangements for retail banking products, EBA/GL/2015/18 (EBA)

Note: this post is for information only and does not constitute legal advice. Always apply your firm’s policies and seek counsel where appropriate.

‍