MiCAR STOR Reporting: How CASPs File Suspicious Transaction and Order Reports Under Article 92

ByOfficer

Last updated: June 2026

A trader on your platform splits a large sell into a string of small orders, cancels most of them within seconds, and walks the visible price down before lifting it again. Your surveillance dashboard flags it. Now the clock is running, because MiCAR STOR reporting is not a back-office nicety. Under Article 92 of the Markets in Crypto-Assets Regulation, a crypto-asset service provider that reasonably suspects an order or transaction could amount to market abuse has to notify the competent authority without delay. Miss it, and the gap is not a late filing. It is a surveillance failure that a supervisor can see in your records long after the trade settled.

This is the part of MiCAR that feels familiar to anyone who has worked under market abuse rules for shares or derivatives, and that familiarity is exactly where firms trip. The suspicious transaction and order report regime for crypto-assets borrows the structure of the equities world but sits under a different EU regime, points at a different authority, and reaches a different population of firms. For a Luxembourg CASP, the report goes to the CSSF on a specific form, through a specific secure channel, and the obligation reaches well beyond the trading platform operator.

This guide walks through who has to monitor for market abuse, what a MiCAR STOR contains, how a Luxembourg CASP files it with the CSSF, and the records you need to keep even when you decide not to file. It is written for the reporting and surveillance teams who have to build the workflow, not for the marketing deck.

Related reading: our MiCAR reporting obligations overview.

What MiCAR STOR reporting actually is

STOR stands for suspicious transaction and order report. It is the notification a firm sends to a supervisor when it has a reasonable suspicion that an order or a transaction in a crypto-asset could be insider dealing, unlawful disclosure of inside information, or market manipulation. MiCAR places the market abuse rules in Title VI, running from Article 86 through Article 92. The first articles set out the scope and the prohibitions. Article 92 is the one that turns those prohibitions into a reporting duty.

The market abuse provisions do not cover every token in existence. Title VI applies to acts concerning crypto-assets that are admitted to trading on a trading platform, or for which a request for admission to trading has been made (Article 86). A token sitting in a private wallet that has never been listed is outside the surveillance perimeter for these purposes. The moment a crypto-asset is listed, or an admission request is filed, the orders and transactions around it fall inside the Article 92 net.

One distinction sets the boundary of the whole regime. MiCAR market abuse rules apply to crypto-assets that are not financial instruments. If a token qualifies as a financial instrument, it is the Market Abuse Regulation, Regulation (EU) No 596/2014, that governs it, and the report is a MAR STOR through the established channel for financial instruments. The two regimes are deliberately close in design, which is why a surveillance analyst can read across from one to the other. They are not interchangeable in filing. Sending a MiCAR suspicion through your MAR pipeline, or the reverse, puts the report in front of the wrong supervisory process.

Who has to file: persons professionally arranging or executing transactions

The common assumption is that market abuse surveillance is the trading platform’s job. It is broader than that. Article 92(1) places the obligation on any person professionally arranging or executing transactions in crypto-assets. The drafting language for that population, carried through the technical standards, is persons professionally arranging or executing transactions, sometimes shortened to PPAETs.

That phrasing pulls in more than the venue. A CASP executing client orders, a firm receiving and transmitting orders, a platform matching trades, and an intermediary arranging transactions can each fall within scope depending on what they actually do in the order flow. The test is functional. If your firm is professionally arranging or executing transactions in in-scope crypto-assets, you need arrangements to prevent and detect market abuse and a route to report what you find. Outsourcing the matching engine does not outsource the obligation.

This matters for Luxembourg firms that hold an authorisation covering several crypto-asset services. A single CASP licence can bundle execution of orders, reception and transmission, and the operation of a trading platform. Each of those activities can engage Article 92, so the surveillance build has to cover the whole authorised footprint, not just the service line that looks most like an exchange. Where firms get this wrong is by scoping surveillance to the venue and leaving the order-handling desks outside the monitoring perimeter.

The legal stack: Article 92, the RTS, and the ESMA guidelines

Three layers sit on top of each other here, and keeping them straight saves a lot of confusion about what is binding.

The first layer is Article 92 of MiCAR itself. It sets the obligation to have arrangements, systems and procedures, the duty to report a reasonable suspicion without delay, and the rule that the competent authority receiving a report transmits it immediately to the competent authorities of the trading platforms concerned. Article 92(2) handed ESMA the mandate to write regulatory technical standards specifying the arrangements, systems and procedures, the template to be used, and the cross-border coordination procedures between national authorities. ESMA had to submit those draft standards to the Commission by 30 December 2024.

The second layer is the regulatory technical standards themselves. The Commission adopted the delegated regulation on 29 April 2025, and Commission Delegated Regulation (EU) 2025/885 was published in the Official Journal on 20 August 2025, entering into force on 9 September 2025. These standards are where the detail lives: what your monitoring has to do, how the report is structured, and how long you keep the supporting analysis. Because they take the form of a delegated regulation, they apply directly. There is no national transposition step to wait for.

The third layer is the ESMA guidelines on supervisory practices to prevent and detect market abuse under MiCA. Article 92(3) required ESMA to issue these by 30 June 2025 to keep supervisory practice consistent across national authorities. The point worth holding onto is that these guidelines are addressed to the competent authorities, not directly to CASPs. They shape how the CSSF and its peers supervise, rather than adding a separate reporting template for firms. Reading them as a firm-level rulebook is a common misread. The firm-facing detail is in the regulatory technical standards.

For the wider reporting picture beyond market abuse, our guide to MiCAR token classification and reporting obligations covers how the type of token drives which obligations attach.

Arrangements, systems and procedures: what the rules require

Article 92(1) does not just ask for a report after the fact. It asks for effective arrangements, systems and procedures to prevent and detect market abuse in the first place. The regulatory technical standards turn that into operational expectations.

Monitoring has to cover orders and transactions, and it has to cover aspects of the distributed ledger technology that are specific to crypto. Article 92(1) names the functioning of the distributed ledger technology, such as the consensus mechanism, as something the surveillance has to be able to consider. That is a genuine departure from equities surveillance. A manipulation pattern in crypto can live in protocol behaviour, not only in the order book, and the rules expect your systems to be able to look there.

The standards expect technology and people together. Firms are expected to run software capable of deferred reading, replaying and analysing of order book data, so that a flagged sequence can be reconstructed and examined rather than judged in the moment. Alongside that automated layer, the firm needs human analysis capacity to assess alerts, decide whether a suspicion is reasonable, and write up the reasoning. Treating an automated alerting tool as the entire compliance answer is the error here. The system raises candidates. A person still has to reach the judgment that an order or transaction is reportable.

The arrangements also have to be proportionate to the nature and scale of the business. A small order-routing firm is not expected to run the same surveillance estate as a large multi-service venue. Proportionate does not mean optional. It means the design has to match the activity, and a firm that arranges transactions still needs a documented way to spot and escalate a suspicious pattern.

The STOR itself: template, content, and how Luxembourg CASPs file with the CSSF

When a suspicion crystallises, the report goes through the CSSF MiCAR STOR process. The CSSF page published on 10 June 2026 directs Luxembourg firms to complete the Suspicious Transaction and Order Report form available in its Documentation section. Before filing, teams should verify the live CSSF form and instructions, because the submission process is MiCAR-specific and must follow the current CSSF route for Article 92 MiCAR suspicions.

The CSSF form is built in sections, and the instruction on the form is blunt about completeness. The CSSF instruction is broader: no fields in the form should be left blank. If a specific item is not relevant or not applicable, the relevant field should say N/A, with the form instructions taken into account before submission. That last instruction is easy to skim past and important to honour. A blank field reads as an incomplete report. An N/A with a short reason reads as a considered one. In practice, the report should follow the CSSF form and the MiCAR STOR instructions current at the time of filing. The control point is not only completing the sections, but checking that the template used is the latest CSSF route for Article 92 MiCAR suspicions.

The first practical thing I check on a MiCAR STOR is the transmission route, because it is where good content goes to the wrong place. The CSSF submission route must be built into the procedure. The CSSF says MiCAR STORs and their annexes shall be submitted by email to market.abuse@cssf.lu, with the STOR and annexes password-protected and the password provided through a separate channel. Secure transmission through the CSSF MFT service is also possible, and interested persons can obtain an MFT link by contacting the same CSSF mailbox.

On timing, Article 92(1) sets the standard as without delay. There is no comfortable fixed window to plan around, and no number of days to treat as a deadline. Once a suspicion is reasonable, the report goes. The practical control is the internal escalation path: how an alert moves from the surveillance analyst to the person who signs off the report, and how quickly that can happen on the day it matters. After the CSSF receives a report, Article 92 requires it to transmit the information immediately to the competent authorities of the trading platforms concerned, which is how a cross-venue pattern reaches the other supervisors involved.

Record-keeping: why a decision not to file still has to be documented

The field that teams forget is the one that is not on the form at all. It is the internal record of the orders and transactions you looked at and decided not to report.

The regulatory technical standards require firms to keep records of the analysis carried out on orders, transactions and aspects of the functioning of the distributed ledger technology that could constitute market abuse, for a period of five years. That record has to include the analysis made and the reasons for submitting or not submitting a STOR. In other words, a decision that an alert was a false positive is itself a reportable event to your own file. The supervisor can later ask why a pattern that looks suspicious in hindsight did not generate a report, and your answer needs to be a contemporaneous record, not a reconstruction.

This reframes what surveillance produces. The output of the process is not only the reports you send. It is a five-year trail of judgments, each with a reason attached. Firms that log only the STORs they filed leave the larger half of the evidence base empty. A clean not-filed record, written at the time, is what turns a defensible judgment into a demonstrable one.

STOR is not STR: keeping market abuse and AML reporting apart

The single most common confusion I see around this obligation is between two reports that share an acronym shape and almost nothing else. A MiCAR STOR is a market abuse report. A suspicious transaction report, or STR, in the anti-money-laundering sense is a different report, under a different legal basis, going to a different authority.

A MiCAR STOR concerns insider dealing and market manipulation in crypto-assets, sits under Article 92 of MiCAR, and in Luxembourg goes to the CSSF. An AML suspicious activity report concerns money laundering and terrorist financing, sits under the anti-money-laundering framework, and in Luxembourg goes to the financial intelligence unit, the Cellule de Renseignement Financier. The same trade can, in theory, trigger both: a wash-trading scheme designed to manipulate a token price might also be laundering proceeds. When that happens, both reports are due, to both recipients, on their own legal bases. One does not discharge the other.

The practical failure is a single escalation queue that routes every alert to one team and one destination. Market abuse surveillance and AML monitoring are different disciplines with different triggers, and collapsing them means one of the two reports gets missed. Keep the workflows distinct, and make sure the analysts know which authority a given suspicion is bound for. Our overview of AML reporting in Luxembourg sets out the financial intelligence unit channel that sits parallel to the market abuse route described here.

When the obligation bites: timeline and the Luxembourg transitional regime

The market abuse and CASP provisions of MiCAR became applicable on 30 December 2024. That is the date the Article 92 duty switched on across the European Union, independent of any national implementing law.

Luxembourg then put the supervisory architecture in place. A Luxembourg law of 6 February 2025 designated the CSSF as the competent authority for MiCAR, published in the Official Journal on 10 February 2025 and applicable from that date. The same framework carries a transitional regime for existing virtual asset service providers. A VASP registered with the CSSF before 30 December 2024 may continue to provide the services it was registered for during an 18-month window running from 30 December 2024 to 1 July 2026, or until its authorisation under Article 63 of MiCAR is granted or refused, whichever comes first.

The trap inside that transitional comfort is to read it as a holiday from market abuse surveillance. The transition concerns authorisation status, not the Article 92 obligation. A firm operating under the transitional regime and arranging or executing transactions in in-scope crypto-assets is still expected to detect and report suspected market abuse. The surveillance build cannot wait for the full CASP licence to land. For the policy direction of travel, our summary of the European Commission MiCAR review consultation for CASPs tracks where the framework may move next.

Frequently Asked Questions

What is a MiCAR STOR?

A MiCAR STOR is a suspicious transaction and order report filed under Article 92 of the Markets in Crypto-Assets Regulation. It is the notification a firm sends to its competent authority when it reasonably suspects that an order or transaction in an in-scope crypto-asset could constitute insider dealing, unlawful disclosure of inside information, or market manipulation. In Luxembourg the report goes to the CSSF.

Who has to monitor for market abuse and file MiCAR STORs?

Article 92(1) applies to any person professionally arranging or executing transactions in crypto-assets. That reaches beyond trading platform operators to firms executing client orders, receiving and transmitting orders, and arranging transactions. The test is functional, so a CASP whose authorisation bundles several services has to cover each in-scope activity, not only the venue.

How quickly does a MiCAR STOR have to be filed?

Article 92(1) requires the report to be made without delay once a suspicion is reasonable. The regulation does not set a fixed number of days. The practical control is the internal escalation path that moves an alert from the surveillance analyst to the person who files the report.

How does a Luxembourg CASP submit a STOR to the CSSF?

The CSSF has published a dedicated STOR form for MiCAR. No fields in the form should be left blank, and where an item is not relevant or not applicable the field should say N/A. The CSSF states that MiCAR STORs and their annexes are submitted by email to market.abuse@cssf.lu, password-protected with the password sent through a separate channel, and that secure transmission through the CSSF MFT service is also possible.

Is a MiCAR STOR the same as an AML suspicious transaction report?

No. A MiCAR STOR is a market abuse report under Article 92 and goes to the CSSF. An AML suspicious transaction report concerns money laundering and terrorist financing, sits under the anti-money-laundering framework, and in Luxembourg goes to the Cellule de Renseignement Financier. The same activity can require both reports on their separate legal bases.

Do we have to keep records when we decide not to file?

Yes. The regulatory technical standards require firms to keep records of the analysis of orders, transactions and relevant distributed ledger technology activity for five years, including the reasons for submitting or not submitting a STOR. A decision that an alert was not reportable has to be documented at the time.

Which rules govern crypto-assets that are financial instruments?

Crypto-assets that qualify as financial instruments fall under the Market Abuse Regulation, Regulation (EU) No 596/2014, not under MiCAR Title VI. The MiCAR market abuse regime applies to in-scope crypto-assets that are not financial instruments. Classifying the asset correctly decides which market abuse regime and which report apply.

Where do the detailed surveillance requirements come from?

The firm-facing detail is in Commission Delegated Regulation (EU) 2025/885, the regulatory technical standards on market abuse under MiCA, published in the Official Journal on 20 August 2025 and in force from 9 September 2025. The separate ESMA guidelines under Article 92(3) are addressed to competent authorities and shape supervisory practice rather than adding a firm-level template.

Related Articles

Key Takeaways

  • MiCAR STOR reporting sits in Article 92 of MiCAR. A firm that reasonably suspects market abuse in an in-scope crypto-asset has to notify the competent authority without delay.
  • The obligation reaches any person professionally arranging or executing transactions, not only trading platform operators. Scope the surveillance to the whole authorised activity.
  • The market abuse rules apply to crypto-assets admitted to trading or with a pending request for admission (Article 86). Crypto-assets that are financial instruments fall under the Market Abuse Regulation instead.
  • The firm-level detail is in Commission Delegated Regulation (EU) 2025/885, in force from 9 September 2025. The ESMA Article 92(3) guidelines are addressed to competent authorities.
  • Surveillance has to combine automated systems, including deferred replay of order book data and attention to distributed ledger technology behaviour, with human analysis.
  • In Luxembourg the report goes on the CSSF STOR form for MiCAR. No field should be left blank, a not-applicable item is marked N/A, and the report is submitted by email to market.abuse@cssf.lu (password-protected, with the password sent through a separate channel) or through the CSSF MFT service.
  • Records of the analysis, including the reasons for not filing, have to be kept for five years.
  • A MiCAR STOR is not an AML suspicious transaction report. Market abuse reports go to the CSSF, money-laundering reports go to the financial intelligence unit, and the same activity can require both.

Sources and References

  • Regulation (EU) 2023/1114 of 31 May 2023 on markets in crypto-assets (MiCAR), Title VI, Articles 86 to 92 – EUR-Lex
  • Commission Delegated Regulation (EU) 2025/885 supplementing MiCA with regulatory technical standards on market abuse (arrangements, systems and procedures, STOR template, cross-border coordination), OJ 20 August 2025, in force 9 September 2025 – EUR-Lex
  • ESMA Final Report on the draft technical standards under Article 92(2) of MiCA (STORs), ESMA75-453128700-1278, December 2024 – ESMA
  • ESMA Guidelines on supervisory practices to prevent and detect market abuse under MiCA, ESMA75-453128700-1039 – ESMA
  • ESMA press release, ESMA issues supervisory guidelines to prevent market abuse under MiCA – ESMA
  • CSSF, Suspicious transaction and order reports (MiCAR STORs), published 10 June 2026, including the STOR form for MiCAR in the Documentation section – CSSF
  • CSSF, Markets in Crypto-Assets (MiCA/MiCAR), including the MiCAR STOR submission instructions (email to market.abuse@cssf.lu, password protection, MFT option) – CSSF
  • CSSF, Publication in the Official Journal of the Luxembourg law designating the CSSF as the competent authority for MiCAR (Luxembourg law of 6 February 2025) – CSSF

Getting the MiCAR market abuse workflow right

MiCAR STOR reporting rewards firms that treat it as a process rather than a form. The form is the easy part. The hard part is the surveillance estate that feeds it: monitoring that covers every in-scope activity the firm is authorised for, technology that can replay an order book and look at protocol behaviour, analysts who can turn an alert into a reasoned judgment, and a five-year record that captures the calls you made in both directions. Build the not-filed record with the same care as the filed one, keep the market abuse route clearly separate from the AML route, and wire the CSSF submission channel into the procedure so the report leaves the building cleanly. Get those pieces in place and the without-delay standard stops being a source of anxiety and becomes something the firm can actually meet on the day it matters.

Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.

Similar Posts