MiCA dla firm: software house, fintech i e-commerce – co musisz ogarnąć, żeby nie wpaść pod regulacje „przypadkiem”

MiCA obowiązuje od 30.12.2024 (stablecoiny od 30.06.2024). Jeśli tworzysz lub integrujesz usługi krypto, ustal rolę (CASP, emitent, integrator) i przygotuj dowody: bezpieczeństwo, logi, procedury incydentów oraz umowy.

Czym jest MiCA i dlaczego firmy technologiczne dostają nim „po backlogu”?

MiCA (Markets in Crypto-Assets) to unijne rozporządzenie, które porządkuje rynek krypto w UE: określa zasady dla emitentów części kryptoaktywów i dla dostawców usług krypto (CASP). Kluczowy twist dla branży IT jest prosty: nawet jeśli nie jesteś „firmą krypto”, możesz świadczyć usługę krypto poprzez produkt, integrację albo model biznesowy.

W praktyce MiCA najczęściej zahacza o trzy typy firm:

• Software house: budujesz giełdę, portfel, custody, moduł wymiany, aplikację do transferów, platformę tradingową, integracje do on ramp/off ramp.
• Fintech: oferujesz użytkownikom obrót, przechowywanie, zlecenia, transfery, albo „krypto jako funkcję” w aplikacji.
• E-commerce: przyjmujesz płatności w stablecoinach, robisz checkout z krypto, lojalność opartą o tokeny, czasem własny token.

Jeżeli Twój produkt robi choć jedną z typowych czynności typu custody, exchange, trading platform, execution, reception/transmission, advice, portfolio, transfer, to jesteś bardzo blisko definicji „crypto-asset service”.

Od kiedy MiCA obowiązuje i jakie daty musisz znać, zanim zaczniesz planować wdrożenie?

Tu nie ma miejsca na „wydaje mi się”.

• MiCA stosuje się od 30 grudnia 2024.
• Tytuły III i IV (stablecoiny: ART i EMT) stosuje się od 30 czerwca 2024.
• Dla części firm działa okres przejściowy: CASP działający legalnie przed 30.12.2024 może kontynuować do 1 lipca 2026 lub do decyzji o zezwoleniu, zależnie co nastąpi szybciej.
• Państwa członkowskie mogły skrócić ten okres. W zestawieniu ESMA dla Polski widnieje 6 miesięcy (warto to traktować jako sygnał „nie zwlekaj”, a nie poduszkę bezpieczeństwa).

Czy Twoja firma jest CASP, emitentem, czy „tylko” integratorem?

To jest najważniejsze pytanie w całym artykule, bo od niego zależy reszta.

Szybki test zakresu (praktyczny, nie akademicki)

Jeśli Twoja firma robi przynajmniej jedno z poniższych „w sposób zawodowy” dla klientów, to pachnie CASP:

• przechowujesz krypto lub klucze prywatne klienta (custody),
• prowadzisz platformę obrotu,
• wymieniasz krypto na pieniądz lub inne krypto,
• realizujesz zlecenia, przekazujesz zlecenia, robisz transfery,
• doradzasz inwestycyjnie w krypto lub zarządzasz portfelem.

Jeśli natomiast emitujesz token (szczególnie stablecoin), wchodzisz w ścieżkę emitenta i temat robi się cięższy operacyjnie i prawnie. Dla stablecoinów kluczowa jest zgodność z tytułami III i IV, obowiązująca od 30.06.2024.

Integrator (np. e-commerce), który „tylko” podpina bramkę płatniczą, zwykle nie chce zostać CASP „przez przypadek”. Tu celem jest architektura i umowy tak ustawione, żeby ryzyko regulacyjne było po stronie licencjonowanego dostawcy.

Co zmienia się dla stablecoinów i dlaczego to temat, który może wysadzić płatności w e-commerce?

Od 30.06.2024 działalność dotycząca ART i EMT (stablecoinów) jest regulowana. W praktyce regulatorzy przypomnieli rynkowi, że świadczenie usług dotyczących stablecoinów niezgodnych z MiCA może być zakazane, jeśli wchodzi w „oferowanie publiczne” lub „dopuszczenie do obrotu” w rozumieniu MiCA.

I tu pojawia się scena z życia.

Wyobraź sobie e-commerce z elektroniką. Chcesz „włączyć stablecoiny”, bo klienci z zagranicy, bo niższe fee, bo brzmi nowocześnie. Podpinasz integrację, odpalasz marketing i nagle dostajesz pytanie od compliance partnera: „Czy te tokeny są MiCA-compliant i czy nasza usługa nie jest w praktyce ‘oferowaniem do publicznej wiadomości’?”

To nie jest czepialstwo. Komisja i ESMA zwracały uwagę, że nawet niektóre usługi typu exchange, reception/transmission czy execution mogą w pewnych okolicznościach być traktowane jako „public offering”, jeśli w ramach usługi tokeny są promowane.

Wniosek dla e-commerce: stablecoin w checkout to nie tylko „metoda płatności”, ale też potencjalnie temat zgodności tokena i sposobu oferowania.

Jakie „dowody” musi dowieźć software house lub fintech, żeby przejść due diligence MiCA?

MiCA to nie jest wyłącznie papierologia. Dla firm technologicznych to w dużej mierze dowody kontroli operacyjnej.

Poniżej minimalny zestaw, który realnie jest pytany w ankietach i przeglądach:

1) Kontrola dostępu i kluczy

• separacja ról i uprawnień (zwłaszcza kont uprzywilejowanych),
• MFA i twarde zasady dla operacji na kluczach,
• polityka rotacji, odzyskiwania, procedury awaryjne,
• zasady hot wallet vs cold wallet, limity, wieloosobowa autoryzacja.

2) Logi i rozliczalność

• co logujesz (operacje na kontach, zleceniach, kluczach, wypłatach),
• retencja i niezmienność logów,
• korelacja zdarzeń i audyt trail „end to end”.

3) Incydenty i komunikacja

• klasyfikacja incydentów, czasy reakcji, runbooki,
• proces analizy przyczyn (RCA) i działania naprawcze,
• kanał kontaktu 24/7, jeśli operujesz krytyczną usługę.

4) Subcontracting i łańcuch dostaw

• lista podwykonawców (chmura, KYC provider, monitoring, custody tech),
• zasady zmian i informowania klientów,
• testy ciągłości działania na zależnościach.

5) AML jako element „bramki” w autoryzacji

MiCA jest obok, ale organ nadzoru patrzy też na ryzyka AML/CFT. Wprost w przepisach o autoryzacji pojawia się oczekiwanie „odpowiednich procedur” pod wymagania AML (w oparciu o prawo wdrażające dyrektywę AML).

Jak przygotować produkt pod MiCA, żeby nie przebudowywać go w panice po audycie?

Tu działa podejście „compliance by design”, ale bez religii. Chodzi o to, żeby od razu budować elementy, które potem są dowodem.

Krok 1: Zrób mapę funkcji na definicje usług

Weź backlog i odpowiedz: które funkcje to custody, exchange, trading platform, execution, transfer itd.

Jeżeli mapa pokazuje CASP, przygotuj plan licencyjny lub partnerstwo z licencjonowanym podmiotem.

Krok 2: Zbuduj „MiCA Control Pack” (wersjonowany)

To działa jak paczka dowodów dla klienta, audytora i nadzoru:

• opis architektury,
• polityki bezpieczeństwa (klucze, dostęp, backup, monitoring),
• procedury incydentowe,
• opis dostawców i subcontractingu,
• zasady komunikacji z klientem.

Krok 3: Uporządkuj marketing i opisy produktu

ESMA ostrzegała przed „halo effect”, czyli sytuacją, gdy firma będąca CASP miesza w jednej aplikacji produkty regulowane i nieregulowane, a klient nie rozumie różnicy. Wymóg jest prosty: komunikacja ma być fair, clear i not misleading.

To przekłada się na UX: etykiety, disclaimery, wyraźne rozróżnienia, brak „sugerowania nadzoru” tam, gdzie go nie ma.

Co z okresem przejściowym i dlaczego w Polsce lepiej go nie traktować jak wymówki?

MiCA daje mechanizm przejściowy, ale:

• nie każdy kraj daje maksimum,
• warunki bywają ostre,
• i finalnie i tak musisz dojść do zgodności.

Dla Polski w zestawieniu ESMA wskazano 6 miesięcy okresu grandfathering. To oznacza, że firmy działające przed 30.12.2024 powinny mieć plan licencyjny i wdrożeniowy naprawdę szybko.

Jakie błędy widzę najczęściej u firm IT wchodzących w MiCA?

1. „My tylko dostarczamy technologię”, a w umowie i operacjach wychodzi, że jednak świadczą usługę.
2. Brak dowodów: jest bezpieczeństwo „w głowie admina”, ale nie ma logów, procedur, testów.
3. Stablecoiny bez weryfikacji zgodności i kampania marketingowa, która wygląda jak oferowanie.
4. Mieszanie produktów w jednej aplikacji bez jasnego rozróżnienia regulacyjne vs nieregulacyjne.

Podsumowanie

MiCA działa od 30.12.2024, a dla stablecoinów od 30.06.2024. Najważniejszy ruch po stronie software house, fintech i e-commerce to szybkie ustalenie roli (CASP, emitent, integrator) oraz zbudowanie paczki dowodów: bezpieczeństwo kluczy, logi, incydenty, subcontracting i komunikacja, plus porządek w marketingu i opisach produktu.