Suitability software and evidence software are two different products. MiFID II asks for the second one.
Most tools sold as "MiFID II suitability software" calculate whether a recommendation fits a client profile: questionnaire in, risk score out, product eligibility checked. That is suitability assessment, and every serious advisory platform does it. What firms fail inspections on is different: proving, months or years later, what was actually known about the client at the moment of advice, where that knowledge came from, and that the recommendation followed from it. That is suitability evidence, and it is the part almost no system produces while the work happens.
What does MiFID II actually require a firm to keep?
The obligation is a chain, not a document. Under Article 25 of MiFID II, an investment firm providing advice must obtain the necessary information on the client's knowledge and experience, financial situation including the ability to bear losses, and investment objectives including risk tolerance, and must give the retail client a suitability statement specifying how the advice meets their characteristics. The delegated rules (Articles 54 and 55 of Delegated Regulation (EU) 2017/565) spell out what "necessary information" means, and the record-keeping obligations require the firm to retain records sufficient to demonstrate the whole process, not only its output.
Two documents make the standard concrete for supervision. The ESMA Guidelines on certain aspects of the MiFID II suitability requirements set out how firms are expected to collect, maintain and update client information and to ensure the suitability assessment is demonstrable. In Luxembourg, Circular CSSF 23/835 applies those guidelines, making them the baseline the CSSF supervises against. A firm evaluating software should read its requirements off those two texts, not off a vendor's feature list.
Why do firms with suitability software still fail on evidence?
Because the assessment and the proof live in different places. The suitability engine holds the questionnaire result. The reasons behind the recommendation, the client's actual circumstances as they evolved, the conversations where objectives changed, all of that sits in mailboxes, call notes and meeting summaries that no compliance system reads. When an inspection or a complaint arrives, the file gets reconstructed afterwards, from memory, unevenly across relationship managers. Reconstruction is the risk: it is slow, it is incomplete, and it is the hardest thing to defend precisely because it was written after the fact.
The gap has a shape. Roughly 80% of what a firm knows about its clients lives in unstructured communications rather than structured systems, and by Luscent's analysis 40 to 50% of the compliance task load per relationship manager is automatable documentation work. The information that would satisfy the evidence standard already exists inside the firm. What is missing is a system that reads it and writes the record at the moment the work happens.
Suitability engines vs evidence software: what each one produces
Suitability engine | Evidence software | |
|---|---|---|
Core question | "Does this product fit this profile?" | "Can we prove what we knew, when, and why we advised this?" |
Input | Questionnaire, risk profile, product data | The firm's actual communications: mail, meetings, calls, notes |
Output | Suitability result, product eligibility | Audit-ready record: source, rule applied, decision, decision-maker, timestamp |
When the record is written | At assessment, then frozen | Continuously, as the relationship evolves |
Failure mode at inspection | Profile stale, circumstances changed unrecorded | Largely eliminates reconstruction |
Typical vendors | Advisory platforms, portfolio systems | Relationship intelligence platforms |
The two are complementary. A firm needs the engine to assess and the evidence layer to demonstrate. What it should not do is assume that buying the first delivers the second.
How evidence generation works when it is done properly
A credible evidence system has properties a compliance officer can test in a demo:
It reads what already exists. Communications the firm already produces, connected read-only, with nothing written back into the systems of record.
Consent and lawful basis are recorded before anything is read, and identifiers are removed before any model sees content.
Compliance outcomes come from deterministic rules, never from a model. A rule produces the same result on the same input every time, which is the property an auditor needs and a probabilistic model does not have.
Every output carries its working: the source messages, the rule that fired, the model and version that read them, and the person who decided.
The record is immutable and retained for the supervisory horizon (Luscent retains the audit trail for seven years; MiFID II sets five years as the minimum).
A person stays in the loop. The system recommends and records; the relationship manager decides. Software that claims to decide suitability for the firm is mis-sold: under MiFID II the firm remains responsible for the assessment regardless of the technology used.
How Luscent fits this picture
Luscent is the system of intelligence for wealth management: an EU-native AI platform for private banks, family offices, external asset managers, and independent advisors. It reads client communications (emails, call notes, meeting summaries) to surface relationship insights and generate compliance evidence automatically. Client data is processed and stored in the EU, on EU infrastructure.
For suitability specifically, Luscent generates the evidence as the work happens: each Signal carries its source messages, the deterministic rule that gated it, and the decision the relationship manager took, written to an immutable audit trail. It sits beside an existing CRM and advisory stack rather than replacing them, connecting read-only to Microsoft 365 and Salesforce. The compliance engine covers MiFID II (Article 25), GDPR, the EU AI Act (Article 50), Swiss FinSA/FinIA, and Brazilian CVM/ANBIMA resolutions in the same deterministic rules core.
This page describes what the software produces, not what your firm is obliged to do; it is not legal advice, and the suitability assessment remains the firm's responsibility at all times.
Frequently asked questions
What is suitability evidence under MiFID II? The demonstrable record of the whole advisory process: what the firm knew about the client, where that information came from, how the recommendation followed from it, and the suitability statement given to the client. Under MiFID II record-keeping obligations the firm must be able to demonstrate the process, not merely store its result.
Is a completed suitability questionnaire enough evidence? No. The ESMA guidelines expect client information to be collected, maintained and kept up to date, and the record to demonstrate the assessment. A questionnaire frozen at onboarding does not show that changed circumstances were noticed or acted on.
What is CSSF Circular 23/835? The circular by which the Luxembourg regulator applies the ESMA Guidelines on certain aspects of the MiFID II suitability requirements. For firms supervised by the CSSF it makes the ESMA guidelines the operative supervisory baseline for suitability.
Can AI decide whether advice is suitable? It should not, and under MiFID II the responsibility cannot move to the software: the firm remains responsible for the suitability assessment. The defensible use of AI is reading and organising the underlying communications; the compliance outcome should come from deterministic rules, and the decision from a person.
Does Luscent replace our advisory platform or CRM? No. Luscent is an intelligence and evidence layer over the systems a firm already runs. It reads from Microsoft 365 and Salesforce and writes nothing back into them.
Sources: MiFID II (Directive 2014/65/EU), Article 25; Commission Delegated Regulation (EU) 2017/565, Articles 54-55; ESMA Guidelines on certain aspects of the MiFID II suitability requirements; Circular CSSF 23/835. Statistics from Luscent's published research pages. Last updated: 24 August 2026.
