MiCA has been in force since 30 December 2024 (stablecoin provisions since 30 June 2024). If you build or integrate crypto services, determine your role (CASP, issuer, integrator) and prepare evidence: security, logs, incident procedures, and contracts.
What is MiCA, and why does it hit tech companies “through the backlog”?
MiCA (Markets in Crypto-Assets) is an EU regulation that organizes the crypto market across the EU: it sets rules for issuers of certain crypto-assets and for crypto-asset service providers (CASPs). The key twist for the IT industry is simple: even if you’re not a “crypto company,” you can still provide a crypto-asset service through a product, an integration, or a business model.
In practice, MiCA most often catches three types of companies:
- Software houses: building an exchange, a wallet, custody, a swap module, a transfer app, a trading platform, or on-ramp/off-ramp integrations.
- Fintechs: offering users trading, storage, order execution, transfers, or “crypto as a feature” inside an app.
- E-commerce: accepting stablecoin payments, building a crypto checkout, token-based loyalty programs, sometimes a proprietary token.
If your product performs even one of the typical activities — custody, exchange, trading platform, execution, reception/transmission, advice, portfolio management, transfer — you’re very close to the definition of a “crypto-asset service.”
When does MiCA apply, and which dates do you need to know before you start planning your rollout?
There’s no room for “I think so” here.
- MiCA has applied since 30 December 2024.
- Titles III and IV (stablecoins: ARTs and EMTs) have applied since 30 June 2024.
- Some companies get a transitional period: a CASP legally operating before 30 December 2024 may continue until 1 July 2026 or until an authorization decision is reached, whichever comes first.
- Member states could shorten this period. ESMA’s overview lists 6 months for Poland (treat that as a signal to move fast, not as a safety cushion).
Is your company a CASP, an issuer, or “just” an integrator?
This is the most important question in the whole article, because everything else depends on it.
A quick scope test (practical, not academic)
If your company does at least one of the following “on a professional basis” for clients, it smells like a CASP:
- you hold crypto or a client’s private keys (custody),
- you run a trading platform,
- you exchange crypto for money or for other crypto,
- you execute orders, transmit orders, or process transfers,
- you provide investment advice on crypto or manage a portfolio.
If instead you issue a token (especially a stablecoin), you’re on the issuer path, and the topic gets operationally and legally heavier. For stablecoins, compliance with Titles III and IV, in force since 30 June 2024, is key.
An integrator (e.g., e-commerce) that “just” plugs in a payment gateway usually doesn’t want to become a CASP “by accident.” Here the goal is to structure the architecture and contracts so the regulatory risk sits with the licensed provider.
What’s changing for stablecoins, and why could this topic blow up e-commerce payments?
Since 30 June 2024, activity involving ARTs and EMTs (stablecoins) has been regulated. In practice, regulators have reminded the market that providing services related to stablecoins that aren’t MiCA-compliant may be prohibited if it amounts to a “public offer” or “admission to trading” under MiCA.
And here’s a scene straight out of real life.
Imagine an e-commerce store selling electronics. You want to “turn on stablecoins” because you have customers abroad, lower fees, and it sounds modern. You wire up the integration, launch the marketing, and suddenly compliance asks: “Are these tokens MiCA-compliant, and is our service effectively a ‘public offer’?”
This isn’t nitpicking. The Commission and ESMA have pointed out that even certain services such as exchange, reception/transmission, or execution can in some circumstances be treated as a “public offering” if the tokens are being promoted as part of the service.
The takeaway for e-commerce: a stablecoin at checkout isn’t just a “payment method” — it can also raise questions about the token’s compliance status and how it’s being offered.
What “evidence” does a software house or fintech need to pass MiCA due diligence?
MiCA isn’t purely paperwork. For tech companies, it’s largely about evidence of operational control.
Below is the minimum set that actually comes up in questionnaires and reviews:
1) Access and key control
- separation of roles and permissions (especially privileged accounts),
- MFA and strict rules for key operations,
- rotation and recovery policy, emergency procedures,
- hot wallet vs. cold wallet rules, limits, multi-person authorization.
2) Logs and accountability
- what you log (account operations, orders, keys, withdrawals),
- log retention and immutability,
- end-to-end event correlation and audit trail.
3) Incidents and communication
- incident classification, response times, runbooks,
- root cause analysis (RCA) process and corrective actions,
- a 24/7 contact channel if you operate a critical service.
4) Subcontracting and the supply chain
- a list of subcontractors (cloud, KYC provider, monitoring, custody tech),
- change and client-notification rules,
- continuity testing across dependencies.
5) AML as a “gate” in authorization
MiCA sits alongside AML/CFT risks, but supervisors look at those too. The authorization provisions explicitly expect “appropriate procedures” for AML requirements (based on the law implementing the AML directive).
How do you prepare your product for MiCA so you’re not rebuilding it in a panic after an audit?
This calls for a “compliance by design” approach — without turning it into dogma. The point is to build components from the start that later serve as evidence.
Step 1: Map your features to service definitions
Take your backlog and answer: which features are custody, exchange, trading platform, execution, transfer, etc.
If the map points to CASP, prepare a licensing plan or a partnership with a licensed entity.
Step 2: Build a “MiCA Control Pack” (versioned)
This works like an evidence pack for the client, the auditor, and the supervisor:
- architecture description,
- security policies (keys, access, backup, monitoring),
- incident procedures,
- a description of vendors and subcontracting,
- client communication rules.
Step 3: Clean up your marketing and product descriptions
ESMA has warned about the “halo effect” — when a CASP mixes regulated and unregulated products in a single app and the client doesn’t understand the difference. The requirement is simple: communication must be fair, clear, and not misleading.
That translates into UX: labels, disclaimers, clear distinctions, and no “implying oversight” where none exists.
What about the transitional period, and why shouldn’t companies in Poland treat it as an excuse?
MiCA provides a transitional mechanism, but:
- not every country grants the maximum,
- the conditions can be strict,
- and in the end you still have to reach full compliance.
For Poland, ESMA’s overview lists a 6-month grandfathering period. That means companies operating before 30 December 2024 need a licensing and rollout plan in place very quickly.
What mistakes do I see most often among IT companies entering the MiCA space?
- “We just supply the technology” — yet the contracts and actual operations show they’re providing a service after all.
- No evidence: security exists “in the admin’s head,” but there are no logs, procedures, or tests.
- Stablecoins with no compliance verification, paired with a marketing campaign that looks like an offering.
- Mixing products in a single app with no clear distinction between regulated and unregulated.
Summary
MiCA has applied since 30 December 2024, and stablecoin rules since 30 June 2024. The most important move for software houses, fintechs, and e-commerce is to quickly determine your role (CASP, issuer, integrator) and build an evidence pack: key security, logs, incidents, subcontracting, and communication — plus clean, compliant marketing and product descriptions.