guide

Last updated June 25, 2026

CSSF MiCA Knowledge and Competence Rules for CASPs: 2026 Practical Guide to Circular CSSF 26/909

Direct answer

CSSF MiCA Knowledge and Competence Rules for CASPs: 2026 Practical Guide to Circular CSSF 26/909 helps compliance teams understand what changed, what reference was removed, and which evidence file must be updated. It explains understanding what a CSSF circular change or repeal does to references, affected UCI or fund actors, dates, controls, and evidence files, then shows how to identify the repealed or amended reference, affected actors, effective date, policy updates, and evidence needed for governance records. The later sections connect official sources used, why knowledge and competence matter under mica, and start with role mapping so the next step is easier to judge. Read it before updating policies or controls so the repealed reference, affected scope, and evidence trail are clear.

The immediate task for a CASP is to translate the circular into a role-based competence inventory. Which employees, tied agents, outsourced teams, support desks, onboarding staff, sales teams, client-service staff, marketing reviewers, product specialists, portfolio or execution staff, and complaints handlers interact with clients or influence client communications? Which of them provide information, which provide advice, which approve content, which handle complaints, and which explain risks? For each role, the CASP should define required knowledge, required competence, assessment method, training path, supervision model, approval status, evidence record, and remediation process.

This guide is for CASP boards, authorised managers, compliance officers, HR and training teams, client-service leaders, product teams, legal counsel, internal audit, and founders preparing Luxembourg MiCA operations. It is not legal advice. It is a practical control map for using CSSF Circular 26/909 and related MiCA sources to build a defensible competence framework.

Official sources used

• CSSF: Circular CSSF 26/909
• CSSF: Markets in Crypto-Assets (MiCA/MiCAR)
• CSSF: Crypto-Assets Service Providers (CASPs)
• CSSF: Crypto-assets
• CSSF: Crypto-assets explained
• ESMA: Guidelines for the criteria on the assessment of knowledge and competence under MiCA

Official CSSF, ESMA, and EU materials can change. Verify the current circular, MiCA page, CASP page, authorisation forms, ESMA publications, Luxembourg implementing law, and CSSF instructions before relying on any operational checklist.

Why knowledge and competence matter under MiCA

Crypto-asset markets create information asymmetry. Clients may not understand the difference between custody, exchange, execution, placing, transfer, advice, portfolio management, staking-related arrangements, stablecoin categories, white papers, operational risks, technology risk, market volatility, conflicts of interest, and the difference between a registered transitional VASP and an authorised CASP. A staff member who gives confident but incomplete explanations can cause client harm, complaints, misleading expectations, and regulatory exposure.

MiCA aims to create a regulated framework for crypto-assets in the European Union. But rules on capital, governance, authorisation, safeguarding, and conduct only work if the people operating the business understand what they are doing. Knowledge and competence requirements are therefore not a decorative training module. They are part of investor and consumer protection, market integrity, and operational resilience.

The CSSF's publication of Circular 26/909 should prompt CASPs to ask a direct question: can we prove that client-facing and advice-related staff are competent for the specific services, assets, risks, and client interactions they handle? If the answer depends on general crypto enthusiasm, previous start-up experience, or informal product familiarity, the framework is too weak.

Start with role mapping

The first control is role mapping. A CASP should list roles that provide information or advice about crypto-assets or crypto-asset services. This list may be wider than the sales team. It can include onboarding specialists who explain product access, support staff who answer client questions, account managers who discuss service features, complaints handlers who explain what happened, marketing reviewers who approve risk statements, product specialists who join client calls, treasury or execution staff who explain order handling, and senior managers who speak at client events.

The map should distinguish between information and advice. Information may include factual explanations about services, fees, risks, custody arrangements, order execution, conflicts, complaints, or product features. Advice may involve personal recommendations or suitability-oriented interactions, depending on the service model and applicable MiCA perimeter. The distinction affects competence expectations, supervision, scripts, and escalation.

The map should also cover language and jurisdiction. If clients receive explanations in English, French, German, Portuguese, Spanish, or another language, competence includes the ability to communicate risk accurately in that language. A technically knowledgeable person who cannot explain risk clearly to the client population may still be a conduct risk.

Build a competence standard by role

After mapping roles, define the competence standard. A generic statement that staff must understand crypto-assets is not enough. A client-support role may need knowledge of fees, account access, safeguarding basics, complaints process, fraud warnings, transaction finality, volatility, scams, and escalation boundaries. A person giving advice may need deeper knowledge of client objectives, risk tolerance, conflicts, suitability or appropriateness concepts where relevant, portfolio concentration, liquidity, product governance, and documentation.

The standard should include regulatory knowledge, product knowledge, risk knowledge, operational knowledge, and communication skill. Regulatory knowledge means understanding MiCA perimeter, CASP status, VASP transition context where relevant, white-paper concepts, client rights, complaints, conflicts, market abuse considerations, safeguarding, and required disclosures. Product knowledge means understanding the specific services offered. Risk knowledge means explaining volatility, liquidity, technology, custody, cyber, fraud, stablecoin, smart contract, settlement, and operational risks without exaggeration or minimisation.

Operational knowledge matters because many client harms arise from process misunderstandings. Staff should know what happens when a transfer is delayed, when an address is wrong, when a network is congested, when a token is delisted, when a client disputes a transaction, when custody access is suspended, when a complaint is filed, or when a service is unavailable. They should also know what they are not allowed to say.

Assessment should be evidenced

Training attendance is not the same as competence. A CASP should assess whether staff can apply knowledge. Assessment can include exams, scenario questions, observed calls, case studies, supervised client interactions, file reviews, script testing, complaints analysis, product-change quizzes, and manager sign-off. The assessment method should match the role. A senior adviser should face more complex scenarios than a first-line support agent.

Evidence should be retained by person, role, date, module, result, assessor, remediation, approval status, and next review date. If a person moves role, their competence status should be reassessed. If a product or service changes, affected staff should receive targeted update training. If a staff member fails an assessment, the record should show what limitations apply until remediation is complete.

This evidence should be easy to retrieve. During a supervisory review, a CASP may need to show who was competent on a given date, who handled a client interaction, what training they had, what assessment they passed, and what supervision applied. A spreadsheet that is updated informally after the fact is weaker than a controlled learning and competence register.

Training content should be practical

A good MiCA competence programme does not read like a law summary. It should connect rules to daily client interactions. Staff should practise explaining that crypto-assets can be volatile, that some protections differ from traditional banking or securities products, that custody arrangements and private-key controls matter, that fees and spreads can affect outcomes, that execution may involve delays or slippage, that scams and impersonation risk are common, and that clients should verify official registers and warnings.

Training should include examples of poor communication. For example, "this token is safe" may be misleading if safety is not defined and risks remain. "You can Usually sell" may be misleading if liquidity can evaporate. "We are regulated, so your investment is protected" may be misleading if it implies deposit-guarantee protection that does not exist. "This is not advice" may not cure a conversation that was in substance a recommendation.

Training should also include escalation rules. Staff need to know when to transfer a question to compliance, legal, complaints, fraud, cybersecurity, senior support, or an authorised adviser. A competence framework is stronger when it teaches staff to recognise their own boundary.

Governance and board oversight

The board or authorised management should receive periodic reporting on competence. Useful metrics include mapped roles, staff in scope, staff fully approved, staff under supervision, overdue training, failed assessments, remediation cases, product-change training completion, complaint themes linked to staff explanations, monitoring results, and high-risk roles without backup coverage. The report should not be limited to training completion percentages.

Governance should also approve the competence policy. The policy should define scope, role categories, standards, training, assessment, supervision, record keeping, remediation, outsourcing coverage, product-change updates, periodic review, and reporting. It should identify the owner and second-line review process.

Senior management should challenge whether competence expectations match the CASP's business model. A CASP offering simple transfer services has different needs from a CASP giving advice, operating a trading platform, providing custody, offering exchange services, or serving professional and retail client segments across multiple languages. The framework should be proportionate but not superficial.

Outsourcing and group teams

Many crypto businesses use group support, shared technology teams, outsourced customer service, external compliance consultants, marketing agencies, or third-party call centres. If those people provide information or influence client-facing content, they may fall within the practical competence perimeter. The CASP cannot assume that a group training deck is enough.

Outsourcing contracts should require role-based training, assessment, evidence sharing, monitoring rights, incident reporting, confidentiality, and change notification. The CASP should know which outsourced individuals or teams interact with clients, what scripts they use, what training they completed, how questions are escalated, and how quality is tested. If the provider refuses to supply adequate evidence, the CASP has an oversight problem.

Group teams create a related issue. A product specialist in another country may join Luxembourg client calls. A marketing team may write risk language. A central onboarding team may explain MiCA status. The Luxembourg CASP should ensure the competence framework covers these interactions and does not stop at local payroll.

Client communications and marketing review

Knowledge and competence rules should connect to marketing governance. A beautifully trained support team cannot fix misleading website language, token descriptions, app prompts, influencer scripts, newsletters, or onboarding messages. The staff who approve or produce client communications should understand MiCA boundaries, risk disclosures, prohibited exaggeration, register references, complaints rights, and conflict disclosures.

A marketing review checklist should ask whether the material clearly identifies the service, avoids assured-return language, avoids downplaying volatility, explains material risks, distinguishes information from advice, aligns with the authorised service perimeter, uses current fees, avoids unauthorised comparisons, and directs clients to official registers or warnings where relevant. Review evidence should be retained.

The same applies to FAQ pages and chatbot scripts. A chatbot that gives crypto explanations may become a client-information channel. The CASP should know what the tool can say, how it is tested, what escalation path exists, how updates are approved, and how inaccurate responses are corrected.

Complaints as competence feedback

Complaints can reveal competence gaps. If clients repeatedly say they were not told about fees, execution risk, custody limitations, transfer irreversibility, volatility, delisting, or account restrictions, the issue may not be only documentation. It may be staff explanation, script design, or training weakness. Complaints should therefore feed the competence programme.

A good complaints review asks whether the staff member involved was trained, whether the client communication was accurate, whether scripts were followed, whether the client was given advice when only information was allowed, whether escalation should have happened earlier, and whether training should be updated. This turns complaints into a control-improvement loop.

Complaint data should be reported to management alongside competence metrics. A low training-failure rate means little if complaints show recurring misunderstanding. The strongest evidence is consistency between training, client communications, monitoring, and complaint outcomes.

Monitoring and quality assurance

Competence should be monitored after initial approval. Monitoring can include call reviews, chat transcript reviews, email sampling, client-file checks, advice-file reviews where relevant, mystery shopping, complaint root-cause analysis, marketing sample checks, and manager observations. The sample should be risk-based. New staff, high-volume staff, advice roles, complex product roles, and staff with previous errors deserve more monitoring.

Monitoring criteria should be specific. Did the staff member explain the service accurately? Did they avoid promises? Did they state risks clearly? Did they stay within their role boundary? Did they escalate uncertainty? Did they use approved wording where required? Did they document the interaction? Did they correct client misunderstanding?

Monitoring findings should lead to action. Possible actions include coaching, retraining, revised scripts, temporary restriction from certain interactions, policy update, product disclosure revision, disciplinary action, or system change. A monitoring programme that records errors but never changes behaviour is not effective.

Product change and regulatory change

Crypto services change quickly. New tokens, new custody features, staking-like services, stablecoin arrangements, order types, fee models, geographic restrictions, wallet features, and settlement processes can alter client explanations. The competence framework should include product-change training. Staff should not answer questions about a new service before they have been trained and approved.

Regulatory change also matters. CSSF pages, ESMA guidance, EU-level Q&A, Luxembourg law, and internal authorisation conditions may evolve. Compliance should translate regulatory changes into training impacts. If a CSSF update changes how the CASP describes VASP transition, CASP authorisation, crypto-asset qualification, or consumer warnings, staff should receive an update.

The change log should show what changed, who was affected, what training was delivered, what assessment was required, and when staff were approved to discuss the topic. This is especially important for fast-moving businesses where product launches can outrun governance.

Practical implementation roadmap

Start with a MiCA service inventory. List each crypto-asset service, client segment, country/language footprint, client channel, staff role, outsourced team, and communication type. Then define which roles provide information or advice. Build competence standards for each role. Create training modules that combine regulation, product, risk, operations, communication boundaries, complaints, scams, and escalation. Assess staff with scenario-based tests. Approve staff by role. Restrict staff who have not passed. Monitor live interactions. Report results to management. Update the framework after product, staff, provider, or regulatory changes.

Do not wait for a perfect learning platform. A CASP can start with a controlled register, approved materials, assessments, and management sign-off. But the framework should mature quickly. As the business scales, manual tracking becomes fragile. A regulated crypto business needs competence evidence that can survive staff turnover, product launches, supervisory questions, and complaint investigations.

Common failure patterns

The first failure pattern is treating competence as generic annual compliance training. MiCA competence is role-based and service-specific. The second is confusing industry experience with regulatory competence. A staff member may understand blockchain technology but not client disclosure, complaints, conflicts, or advice boundaries. The third is ignoring outsourced support. Clients do not care whether a misleading explanation came from an employee or a vendor.

The fourth failure pattern is weak evidence. Training slides exist, but nobody can prove who passed what assessment before handling clients. The fifth is stale training. Staff were trained before a product launch, fee change, new token category, new jurisdiction, or CSSF update. The sixth is marketing disconnect. Staff are trained carefully, but website claims create expectations staff cannot defend.

The seventh failure pattern is no remediation. Staff who fail assessments continue with unrestricted client contact. Monitoring findings do not lead to coaching. Complaint themes are not fed back into training. The framework looks good on paper but does not control behaviour.

Evidence file for supervisory readiness

A strong evidence file includes the CSSF circular, ESMA guideline reference, MiCA service inventory, role map, competence policy, role standards, training curriculum, assessment records, staff approval register, outsourced-provider evidence, monitoring plan, monitoring results, complaint feedback, management reports, product-change training records, regulatory-change log, and internal audit or second-line review results. It should also include examples of scripts, approved FAQs, marketing review checklists, escalation procedures, and remediation records.

The file should answer three questions quickly. Who is allowed to say what to which clients? How do we know they are competent? What happens when they are not? If those questions cannot be answered with current records, the CASP should treat the gap as a governance issue.

A role-based checklist

1. Identify all client-facing and client-influencing roles.
2. Separate information roles, advice roles, complaints roles, marketing approval roles, and escalation roles.
3. Define required knowledge for each role.
4. Define required practical competence for each role.
5. Build training around actual services and client scenarios.
6. Assess staff before approval.
7. Record approval status and restrictions.
8. Monitor live interactions.
9. Connect complaint themes to retraining.
10. Cover outsourced and group teams.
11. Update training after product or regulatory changes.
12. Report competence metrics to management.
13. Retain evidence in a retrievable register.

Final operating view

Circular CSSF 26/909 should be read as a governance trigger. A CASP that wants to be credible in Luxembourg should not rely on informal crypto knowledge or founder-led explanations. It needs a documented competence system that connects people, products, risks, services, client communications, and evidence.

For clients, the benefit is clearer and more reliable explanations. For CASPs, the benefit is lower conduct risk and stronger supervisory readiness. For management, the benefit is visibility into whether the business has enough qualified people to operate the services it sells. For the Luxembourg market, the benefit is a crypto-asset sector that competes on trust and discipline, not only on technology and speed.

Role inventory

The role inventory should be maintained as a live document. It should include employees, contractors, group teams, outsourced providers, and senior specialists who join client conversations. Each entry should show whether the person gives information, advice, operational explanations, complaints responses, marketing approvals, or product support. The register should also show language coverage and client segment exposure.

The practical test is whether the CASP can retrieve evidence for a named person, role, service, client channel, and date. If the evidence is fragmented across emails, learning tools, vendor files, and manager memory, the framework is vulnerable. A regulated business should make competence visible, current, and auditable.

Competence standard

A competence standard should be granular enough to test. It should identify required knowledge of MiCA, CSSF pages, CASP services, risk warnings, safeguarding, fees, conflicts, complaints, fraud, market abuse boundaries, and operational procedures. It should state the evidence required before a person can handle the role without close supervision.

The practical test is whether the CASP can retrieve evidence for a named person, role, service, client channel, and date. If the evidence is fragmented across emails, learning tools, vendor files, and manager memory, the framework is vulnerable. A regulated business should make competence visible, current, and auditable.

Assessment design

Assessments should use scenarios because client interactions are scenarios. Ask staff how they would respond to a client who asks whether a token is safe, whether losses are protected, whether a transfer can be reversed, whether the firm recommends buying, or whether authorisation means a guarantee. The answers reveal whether staff can apply rules rather than repeat training slides.

The practical test is whether the CASP can retrieve evidence for a named person, role, service, client channel, and date. If the evidence is fragmented across emails, learning tools, vendor files, and manager memory, the framework is vulnerable. A regulated business should make competence visible, current, and auditable.

Supervision model

New or remediating staff may need enhanced supervision. That can include call approval, chat review, restricted scripts, mandatory escalation, or limited product coverage. The supervision model should be documented and removed only after evidence supports normal approval.

The practical test is whether the CASP can retrieve evidence for a named person, role, service, client channel, and date. If the evidence is fragmented across emails, learning tools, vendor files, and manager memory, the framework is vulnerable. A regulated business should make competence visible, current, and auditable.

Outsourced support

Outsourced support should be included in onboarding, training, assessment, quality assurance, and incident escalation. The CASP should retain evidence that the provider's staff understand the approved scripts, service boundaries, risk warnings, and escalation triggers. Provider dashboards should be reviewed by the CASP, not simply received.

The practical test is whether the CASP can retrieve evidence for a named person, role, service, client channel, and date. If the evidence is fragmented across emails, learning tools, vendor files, and manager memory, the framework is vulnerable. A regulated business should make competence visible, current, and auditable.

Marketing and content

Client-facing content should be reviewed by competent people. The review should catch exaggerated safety claims, implied guarantees, less visible fees, missing volatility warnings, unclear custody wording, advice-like language, and stale regulatory references. Content approvals should be retained with version control.

The practical test is whether the CASP can retrieve evidence for a named person, role, service, client channel, and date. If the evidence is fragmented across emails, learning tools, vendor files, and manager memory, the framework is vulnerable. A regulated business should make competence visible, current, and auditable.

Incident learning

Operational incidents should feed competence updates. If a wallet outage, delayed transfer, token suspension, fraud wave, or complaint cluster occurs, staff need updated explanations. Training should follow the incident quickly so clients receive accurate information.

The practical test is whether the CASP can retrieve evidence for a named person, role, service, client channel, and date. If the evidence is fragmented across emails, learning tools, vendor files, and manager memory, the framework is vulnerable. A regulated business should make competence visible, current, and auditable.

Internal audit

Internal audit can test whether the competence framework works. It can sample staff records, compare approval status with client interactions, review outsourced evidence, inspect scripts, test complaint feedback, and verify that management reports are accurate. Findings should be tracked to closure.

The practical test is whether the CASP can retrieve evidence for a named person, role, service, client channel, and date. If the evidence is fragmented across emails, learning tools, vendor files, and manager memory, the framework is vulnerable. A regulated business should make competence visible, current, and auditable.

Management information

Management information should show more than completion rates. It should show high-risk roles, overdue assessments, failed assessments, monitoring findings, complaint themes, product-change training gaps, outsourced-provider issues, and remediation status. This helps management decide whether growth is outrunning control capacity.

The practical test is whether the CASP can retrieve evidence for a named person, role, service, client channel, and date. If the evidence is fragmented across emails, learning tools, vendor files, and manager memory, the framework is vulnerable. A regulated business should make competence visible, current, and auditable.

Client trust

Competent explanations build trust because clients receive fewer surprises. In crypto markets, trust is operational. A CASP that explains risks clearly may lose some speculative clients, but it reduces the risk of complaints, regulatory attention, and reputational damage from misunderstood products.

The practical test is whether the CASP can retrieve evidence for a named person, role, service, client channel, and date. If the evidence is fragmented across emails, learning tools, vendor files, and manager memory, the framework is vulnerable. A regulated business should make competence visible, current, and auditable.

Deep implementation playbook for CASP competence

The first implementation step is to build a service-to-role matrix. List each MiCA service the business provides or intends to provide. Then list each client channel: website, app, onboarding flow, email, chat, telephone, relationship manager, institutional desk, complaint channel, marketing material, webinar, social media, and help centre. For each channel, identify who can give information or advice and what topics they can discuss. This matrix prevents the common mistake of training only the obvious sales team while ignoring the people who actually answer client questions.

The second step is to classify interaction risk. A low-risk factual response, such as where to find a fee schedule, does not require the same competence depth as a conversation about whether a client should use a specific service. But even simple information can be harmful if it is wrong. The classification should consider product complexity, client type, language, volatility, operational risk, safeguarding implications, fees, transfer finality, and whether the staff member might influence a client decision.

The third step is to create a minimum knowledge baseline for all in-scope staff. Every person who interacts with clients should understand the CASP's regulatory status, the services actually authorised or notified, the difference between official information and personal recommendation, the key risk warnings, the complaints process, the escalation path, and the limits of their own role. This baseline should be tested, not merely delivered.

The fourth step is to build specialist modules. Advice roles need deeper training on client objectives, risk profile, conflicts, unsuitable recommendations, documentation, and monitoring. Custody-support roles need deeper training on safeguarding, access, operational incidents, private-key concepts where relevant, transfer instructions, fraud prevention, and irreversible transactions. Trading-support roles need deeper training on order handling, liquidity, spreads, slippage, execution venues, outages, and market abuse boundaries. Marketing roles need deeper training on fair, clear, and not misleading communication.

The fifth step is to approve staff for specific interaction types. Approval should not be binary. A person may be approved for general information but not advice. Another may be approved for custody support but not trading explanations. Another may be approved in English but not in a language where they cannot explain risk precisely. Role-specific approval prevents overreach.

The sixth step is to connect competence to systems. If the help desk tool, CRM, or call-routing platform can identify role permissions, use it. If a staff member is not approved for advice, the system should make escalation easy. If a client asks a high-risk question, staff should have approved response templates and escalation buttons. Competence is stronger when workflow supports it.

How to design scenario assessments

Scenario assessments should mirror real client pressure. Ask what the staff member says when a client asks, "Is this crypto safe because you are regulated?" A competent answer should avoid implying a guarantee and should explain the limits of regulation and the continuing risks. Ask what they say when a client asks whether a transfer can be reversed. A competent answer should explain operational finality and escalation without creating false certainty. Ask what they say when a client asks which token to buy. A competent answer should follow the firm's advice boundary and escalation policy.

Other scenarios should cover fees, volatility, custody access, fraud warnings, phishing, stablecoins, delisting, service outages, complaints, conflicts, marketing claims, and client misunderstanding. The assessment should reward clarity and boundary discipline. It should not reward confident improvisation. In regulated client communications, saying "I need to escalate that" is often the competent answer.

Scenario results should be analysed by theme. If many staff misunderstand the same topic, the training is weak. If staff understand the rule but fail to communicate it simply, the communication module is weak. If staff cannot identify advice boundaries, the business model may be unclear. Assessment data is a management signal, not just an HR record.

How to supervise advice risk

Advice risk deserves special attention because clients may interpret personalised comments as recommendations. A CASP should define what constitutes advice in its operating model, who is allowed to provide it, what documentation is required, and what controls apply. Staff who are not authorised for advice should receive clear scripts for declining or escalating personalised questions.

Supervision can include pre-approval of advice templates, sample review of advice interactions, mandatory file notes, suitability or appropriateness controls where applicable, conflict checks, and complaint monitoring. If the business chooses not to provide advice, monitoring should test whether staff are nevertheless drifting into recommendation language. A prohibition is only credible if the firm tests it.

Marketing can also create advice risk. Personalised campaigns, influencer content, app prompts, push notifications, or segmented product messages may influence client decisions. The competence framework should therefore include people who design, approve, and monitor these materials. A compliance review that ignores behavioural marketing is incomplete.

Consumer protection and plain language

Competence is not only knowing the regulation. It is the ability to explain important facts in language clients understand. Crypto clients may include sophisticated traders, retail beginners, expatriates, multilingual users, institutional clients, and small businesses. The same risk disclosure may need different delivery formats. Plain language is a control because misunderstanding is a conduct risk.

Plain language does not mean oversimplification. It means explaining volatility, liquidity, fees, custody, technology, fraud, transfer finality, conflicts, and complaint rights without hiding nuance. Staff should avoid jargon when it obscures meaning. If technical terms are necessary, they should be defined.

The CASP should test whether clients understand key warnings. This can be done through onboarding comprehension checks, complaint analysis, support-ticket themes, user testing, and monitoring. If clients repeatedly misunderstand a concept, the firm should improve communication rather than blaming clients.

Linking competence to authorisation readiness

For a new applicant or a VASP transitioning toward CASP authorisation, the competence framework can support the broader authorisation story. It shows that the business has considered conduct risk, client protection, governance, staffing, outsourcing, and operational control. A regulator reviewing the business wants to know not only that policies exist, but that people can execute them.

The competence framework should therefore connect to the organisational chart, three-lines model, outsourcing register, complaints policy, conflicts policy, product governance, marketing policy, incident management, and internal control plan. If these documents contradict each other, the competence evidence becomes weaker. For example, a policy may say compliance approves risk language, while the marketing workflow shows product managers publishing without review. The framework should expose and fix those contradictions.

Metrics that actually help

Completion rates are necessary but insufficient. Management should also see how many staff are approved by role, how many are restricted, how many failed first assessment, how long remediation takes, which topics generate the most wrong answers, which channels produce the most monitoring findings, which outsourced teams have evidence gaps, which product changes are awaiting training, and which complaints indicate misunderstanding. These metrics help leaders see whether the business is scaling safely.

Metrics should be interpreted with judgment. A sudden drop in findings may mean quality improved, or it may mean monitoring stopped sampling the right interactions. A high pass rate may mean staff are strong, or it may mean tests are too easy. A low complaint rate may mean clients are satisfied, or it may mean complaints are not being captured. The second line should challenge the meaning of the numbers.

Correcting competence failures

When a staff member fails an assessment or monitoring review, the response should depend on severity. Minor errors may need coaching. Repeated errors may need retraining and enhanced supervision. Serious misstatements to clients may require client remediation, compliance escalation, complaint review, or temporary removal from client contact. The action should be recorded and followed to closure.

The firm should also ask whether the failure is individual or systemic. If one person misunderstands a fee, individual coaching may work. If many people misunderstand the same fee, the disclosure, training, or product design may be unclear. Competence failures are often early warnings of broader control problems.

A final caution on crypto expertise

Crypto-native expertise is valuable, but it can create blind spots. People who understand protocols, wallets, liquidity pools, exchanges, and token economics may assume clients understand them too. They may also use market language that is normal in crypto communities but risky in regulated client communications. A CASP should respect technical expertise while adding regulatory discipline.

The strongest staff combine technical understanding, regulatory awareness, plain-language communication, and humility about uncertainty. They can explain what the firm knows, what it does not know, what the client should verify, and when the issue must be escalated. That is the competence profile Circular CSSF 26/909 should push firms to build.

Final supervisory readiness test

A CASP can test readiness with one exercise. Pick five client interactions from the last month, five staff members, two outsourced agents, one marketing campaign, one complaint, and one product change. For each, retrieve the relevant competence record, training evidence, assessment, approval status, script or content approval, monitoring result, and escalation record. If the firm can do this quickly and the evidence is coherent, the framework is usable. If the exercise requires manual reconstruction, the framework needs work.

This exercise should be repeated periodically. It is a practical way to keep the competence programme alive after the initial implementation project. It also reinforces the core point: knowledge and competence are not abstract values. They are daily controls that shape what clients hear, what staff say, and how a regulated crypto business earns trust.

What to document after the first competence cycle

After the first full competence cycle, the CASP should hold a formal review. The review should ask whether the role map was complete, whether any client-facing teams were discovered late, whether outsourced providers delivered evidence on time, whether assessment questions were too easy or too theoretical, whether monitoring found behaviour that training missed, and whether client complaints revealed misunderstanding. The review should be chaired by someone with enough authority to change training, staffing, scripts, or workflow.

The review should also test whether competence evidence is retrievable. Pick a date, a client channel, and a staff member. The firm should be able to show whether that person was approved for that channel on that date, what training and assessment supported the approval, whether any restrictions applied, and whether later monitoring found issues. If the answer cannot be produced without manual reconstruction, evidence governance needs improvement.

The final output should be a revised competence plan for the next cycle. That plan should include new modules, better scenarios, role-map corrections, outsourced-provider remediation, content updates, monitoring priorities, and management reporting improvements. Competence under MiCA is not a certificate to be obtained once. It is an operating discipline that must keep pace with clients, products, rules, and market events.

A practical example of a competence file

A practical competence file for one support role might contain the role description, client channels, permitted topics, prohibited topics, escalation rules, language permissions, training modules, assessment results, supervisor approval, monitoring samples, complaint links, remediation notes, and next review date. It should show that the person can explain account opening, fees, custody basics, transfer risk, fraud warnings, complaints, and service limitations without drifting into advice. If the person later moves to a product specialist role, the file should not simply travel unchanged. The new role needs its own standard and assessment.

A practical competence file for an advice role should be deeper. It should include evidence that the person understands client objectives, concentration risk, suitability boundaries where relevant, conflicts, documentation, vulnerable-client indicators, escalation, and the firm's exact service perimeter. It should include reviewed examples of client interactions, not only test scores. Advice creates higher conduct risk because clients can act directly on what they hear.

A practical file for marketing approval should include training on fair communication, risk warnings, prohibited claims, product perimeter, register references, performance language, fee presentation, conflicts, and content versioning. A marketing reviewer who does not understand crypto risk can approve language that creates expectations the support team cannot safely explain. Marketing competence is therefore part of the client-protection framework, not a separate brand function.

These examples show why the CASP should avoid one-size-fits-all evidence. The same staff member may need different permissions for different channels. A person may be competent to answer factual questions by email but not to join a live advisory call. Another may be technically strong but not approved for retail communications. The framework should capture those distinctions clearly.

The same distinction should apply to temporary cover. If a trained employee is absent, the backup should already have the right approval. Emergency substitution is not a competence framework. It is a weakness that becomes visible during complaints, outages, market stress, and supervisory review. The file should name the backup and the limits of that backup role.

Why the framework should be tested before growth

Competence controls become harder to repair after rapid growth. A small CASP can still identify every client-facing role by name, review conversations manually, and correct training gaps quickly. A larger CASP with multiple products, jurisdictions, languages, vendors, and distribution channels can accumulate inconsistent explanations before management sees the pattern. That is why the competence framework should be tested before headcount expansion, product launch, language expansion, or outsourced support migration.

The practical growth test is simple. Before adding a new service or channel, ask whether the firm has approved training material, scenario assessments, scripts, escalation rules, monitoring criteria, complaint feedback loops, and named accountable managers. If any of those pieces are missing, the launch creates conduct risk. Growth should not outrun the ability of staff to explain the service accurately.