Skip to content
The Algorithm
InsightsCompliance Engineering
Compliance Engineeringfinancial-services12 min read · 2025-12-31

MiFID II Suitability Compliance for Wealth Management Platforms

MiFID II suitability obligations require investment firms to assess client knowledge, experience, financial situation, and investment objectives before making investment recommendations — and to maintain auditable records demonstrating that every recommendation was suitable. For wealth management platforms operating at scale, this is fundamentally a data architecture challenge: client profiles must be current, recommendations must be traceable to the suitability assessment that justified them, and the entire chain must be producible for regulatory review on demand. This article examines the platform architecture patterns that make MiFID II suitability compliance operationally sustainable.

MiFID II Articles 25 and 54 of the Delegated Regulation require investment firms providing investment advice or portfolio management to obtain from clients the information necessary to assess the suitability of investment recommendations or decisions for that client. The suitability assessment must cover the client's knowledge and experience, financial situation including ability to bear losses, and investment objectives including risk tolerance. For wealth management platforms operating at scale — thousands or tens of thousands of clients receiving personalised recommendations — maintaining current, accurate suitability data and demonstrating that every recommendation was based on a current assessment is a data infrastructure challenge that the front office alone cannot solve.

The Data Currency Problem

MiFID II requires that investment firms have in place appropriate arrangements to ensure they can demonstrate suitability on an ongoing basis. ESMA's guidelines on suitability, updated in 2018, make clear that firms should have processes to identify when client information has become outdated and to update it before making further recommendations. For a wealth management platform with a large client base, this creates a systematic requirement: each client's suitability profile must have a defined currency period, and recommendations must not be made based on profiles that have expired.

The engineering implementation requires that the suitability profile for each client be time-stamped and version-controlled, with an expiry date calculated from the last review date and the client's profile type. The recommendation engine must check profile currency before generating a recommendation and either block the recommendation, notify the adviser, or trigger a client re-engagement workflow when the profile has expired. Platforms that do not implement this check are making recommendations based on stale data, which constitutes a suitability failure regardless of whether the underlying information has actually changed.

The Engineering Reality

ESMA's 2022 supervisory work on MiFID II suitability found that the most common deficiency across surveyed firms was insufficient processes for updating client information. The finding was not that firms had incomplete data at onboarding — it was that they had no systematic mechanism for identifying when data had become stale and refreshing it. This is a workflow and data architecture failure, not a policy failure.

Recommendation Traceability Architecture

Demonstrating suitability requires that every investment recommendation be traceable to the suitability assessment that justified it. This means storing, at the moment of recommendation, a snapshot of the client's suitability profile as it existed at the time — not a reference to a current profile that may subsequently change. If a regulator asks three years after the fact why a particular recommendation was made, the firm must be able to produce the suitability profile that was used, show that it was current at the time, and demonstrate that the recommended product was appropriate for a client with that profile.

This traceability requirement has implications for data architecture that many platforms have not addressed. If the recommendation system reads the client suitability profile from a current-state table that is updated as clients' circumstances change, the historical suitability basis for past recommendations is overwritten and cannot be retrieved. The correct architecture stores the suitability profile snapshot alongside the recommendation record, creating an immutable audit trail. This is a design decision that must be made before the system is built; retrofitting audit trail storage into a platform that was designed around current-state data is expensive and disruptive.

Product Governance and Suitability Integration

MiFID II product governance requirements, under Articles 9 and 10 of the Delegated Directive, require manufacturers and distributors of financial instruments to define and implement target market criteria for each product. Distributors — wealth management firms providing advice — must ensure that products are only recommended to clients within the identified target market. The integration of product target market criteria with client suitability assessments is a matching problem: the firm must be able to demonstrate that the client's profile falls within the target market for any product recommended to them.

Building this matching logic requires that product target market data — typically maintained in a product catalogue or instrument reference database — is structured in a way that can be compared directly with client suitability profile data. When the two data models were designed independently (product catalogue by the investment team, suitability data by compliance), they frequently use different taxonomies for risk tolerance, investment horizon, and knowledge and experience categories. Harmonising these taxonomies is a data governance task that must precede the technical integration.

Regulatory Reporting and Examination Readiness

National competent authorities have the right to request suitability documentation for any client relationship at any time during a MiFID II examination. The FCA, AFM, BaFin, and other NCAs have all included suitability as a thematic examination area in recent years. Examination readiness requires that the platform can produce, within a reasonable timeframe, a complete suitability file for any client: the initial suitability assessment, all subsequent updates, the recommendation history with the suitability basis for each recommendation, and evidence that the client received required suitability reports. This is not an export function that can be built after an examination notice is received; it requires an ongoing data architecture designed for auditability from the start.

Related Articles
Compliance Engineering

EU AI Act: What CTOs Actually Need to Do Before August 2026

Read →
Compliance Engineering

DORA Is Live. Here's What 'Operational Resilience' Means for Your Codebase

Read →
Compliance Engineering

FedRAMP Rev 5: What Changed and Why Most Current ATO Holders Are Already Non-Compliant

Read →
Facing This?

The engineering behind this article is available as a service.

We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.

Talk to an EngineerSee Case Studies →
Engage Us