How should financial firms implement product governance under MiFID II?

How MiFID II product governance works in practice

mifid ii product governance is designed to stop firms from treating distribution as an afterthought. The governance obligation starts before launch: firms must define who the product is for, who it is not for, and what client objectives, knowledge, experience, risk tolerance, and loss-bearing capacity the product can reasonably fit. That creates the baseline for all later decisions, including approval, distribution, review, and remediation.

The practical value is that product governance turns product design into a controlled decision process rather than a sales-led judgement. For financial firms, the question is not only whether a product is lawful, but whether the intended market, distribution channel, and risk profile are coherent enough to support responsible sale and ongoing oversight.

That is why target-market definition and suitability analysis need to be connected. A product can be technically well structured and still fail governance if it is sent to the wrong client segment, distributed through an unsuitable channel, or described in a way that obscures downside risk. The governance standard therefore depends on good product data, clear documentation, and consistent accountability between the manufacturer and distributor.

Controls that make product governance auditable

A robust program usually has four control layers. First, firms define the positive target market and the negative target market in writing, with enough specificity to make distribution decisions repeatable. Second, they require documented product risk analysis before approval, including whether the product can be understood by the intended market and whether foreseeable harms are acceptable relative to client objectives.

Third, they maintain distribution controls that prevent drift. That includes checking whether distributors are selling into channels, jurisdictions, or client profiles that were not part of the approved market. Fourth, they keep an ongoing review cycle so that changes in product structure, market conditions, complaints, or sales patterns trigger a reassessment rather than waiting for a formal renewal date.

Written reporting matters because MiFID II governance is not just about initial design, it is about being able to explain why the firm believed the product was suitable at each stage. A well-run process leaves an audit trail from design decision to client outcome, which is what supervisors usually care about when they ask whether a firm truly understood its own product.

For broader control design, firms can align their internal governance model with the NIST Cybersecurity Framework 2.0 as a general governance discipline, and use ISO/IEC 27002:2022 Information Security Controls as a reference point for formal control selection and evidence retention in documented processes.

Why firms get MiFID II governance wrong

The most common failure is treating the target market as a marketing label instead of a control boundary. When that happens, firms describe the product in broad terms, but do not operationalise what excluded clients, unsuitable channels, or mismatched risk appetites look like in practice. Another common failure is assuming the distributor will “handle suitability” and therefore underinvesting in upstream product design documentation.

Firms also struggle when the approval file and the actual sales process drift apart. If the documented rationale says one thing but the sales playbook, remuneration structure, or customer journey pushes advisers toward a different segment, governance becomes weak even if the paperwork still looks complete. That is where mis-selling risk usually emerges, because the formal framework no longer matches the way products are actually placed.

For firms with complex product lines, the harder problem is monitoring change. A product can move from acceptable to inappropriate if charges change, risk features evolve, client communications are simplified, or the market environment changes materially. MiFID II product governance therefore has to behave like a living control, not a one-time launch gate.

Risk and Threat Considerations

Weak product governance creates a direct mis-selling exposure, but it also creates a control failure problem: once a product is pushed into the wrong market, remediation becomes slower, more expensive, and harder to evidence. The risk is highest where product complexity, opaque disclosures, or sales incentives narrow the gap between “can be sold” and “should be sold.”

Failure mechanism: The firm’s intended market definition, distribution controls, and post-sale review fall out of sync, so unsuitable products are approved, marketed, or retained without a defensible client-fit rationale.

Impact: Clients can be exposed to inappropriate risk, complaints and redress costs can rise, and the firm may be unable to show a clear supervisory record of why a product was considered suitable at launch and over time.

Practitioner Guidance

What to verify: Confirm that the target market document, the distribution strategy, and the suitability logic all describe the same client population in the same terms. If those three artefacts disagree, the control is already weak even if each document looks polished on its own.

Decision rule: If a product’s downside, complexity, or fee structure cannot be explained clearly to the intended market, treat that as a governance problem, not just a disclosure problem. The right response is usually to narrow the market or tighten distribution, not to add more marketing language.

Practitioner takeaway: Product governance works when firms can prove that launch decisions, sales behaviour, and ongoing monitoring all point to the same client fit. If the evidence trail does not support that alignment, the framework is decorative rather than protective.

Related resources from NHI Mgmt Group

• How should financial firms implement incident response for customer data under Reg S-P in cloud and SaaS environments?
• How should financial firms implement runtime authorization for AI agents under DORA?
• How should financial institutions implement AI governance for model risk management under OSFI E-23?
• How should financial firms implement automated blocking of commonly used passwords across employee and customer systems under NYDFS requirements?