Dyrektywa DAC8 – nowy etap automatycznej wymiany  informacji o kryptoaktywach (case study)

Case study 1: Wymiana 2 BTC na 30 ETH (crypto-to-crypto)

Sytuacja: Użytkownik dokonuje na giełdzie krypto (CASP) transakcji wymiany – sprzedaje 2 BTC i za uzyskane środki kupuje 30 ETH. Jest to klasyczna wymiana jednej kryptowaluty na inną, przeprowadzona w ramach platformy.

Raportowanie DAC8

W związku z tym, że mamy do czynienia z transakcją wymiany krypto-krypto (Bitcoin na Ether), CASP musi ująć ją w raporcie jako transakcję typu “CryptoToCrypto”. W praktyce raport DAC8 przedstawi tę operację jako zbycie określonej ilości BTC oraz nabycie określonej ilości ETH przez danego użytkownika.

W schemie CARF transakcje tego typu są raportowane agregatywnie za cały okres – platforma sumuje wszystkie wymiany crypto-to-crypto użytkownika w danym roku i podaje łączną liczbę takich transakcji oraz łączną wartość (najczęściej w USD lub EUR) zbytych i nabytych aktywów. W raporcie pojawią się osobne wpisy dla każdego rodzaju kryptoaktywa: jeden dla BTC (z informacją ile BTC użytkownik łącznie sprzedał i za jaką wartość) oraz drugi dla ETH (ile łącznie kupił).

Każdy rekord zostanie oznaczony jako nowy wpis za dany rok (w ramach DocSpec z kodem OECD1, oznaczającym nowe dane). W przypadku późniejszej korekty, odpowiednio użyte byłyby kody OECD2 (korekta) lub OECD3 (usunięcie) – o czym mówi standard CARF.

Kluczowe pola CARF XML

• <CryptoToCryptoOut> = wartość oraz liczba jednostek kryptoaktywów zbytych przez użytkownika w transakcjach wymiany (tu: 2 BTC sprzedane). CASP raportuje w tym polu łączną kwotę uzyskaną ze sprzedaży BTC oraz liczbę sprzedanych BTC.
• <CryptoToCryptoIn> = wartość oraz liczba jednostek kryptoaktywów nabytych przez użytkownika w wyniku wymiany (tu: 30 ETH kupione). Pole wskazuje na łączną kwotę wydaną na zakup ETH oraz liczbę nabytych ETH.
• DocSpec/DocTypeIndic = znacznik rodzaju zgłaszanej transakcji. W przypadku nowej transakcji będzie to OECD1 (nowe dane), w przypadku korekty OECD2, a przy usunięciu wpisu OECD3. Pozwala to organom odróżnić dane pierwotne od późniejszych zmian w kolejnych raportach.

Case study 2: Płatność 60 000 USD w stablecoinie (RRPT)

Sytuacja: Przedsiębiorca dokonał zapłaty za usługę w kryptowalucie typu stablecoin. Kwota transakcji wyniosła równowartość 60 000 USD – np. użytkownik przesłał kontrahentowi 60 tys. USDC (stablecoin powiązany z dolarem) tytułem płatności za fakturę.

Raportowanie DAC8

Taka operacja to przykład wykorzystania kryptoaktywów jako środka płatniczego. DAC8 kwalifikuje ją jako płatność detaliczną (retail) podlegającą raportowaniu, ponieważ przekracza ona ustalony próg wartości.

W standardzie CARF figuruje ona jako Reportable Retail Payment Transaction (RRPT), czyli raportowana transakcja płatności za towary/usługi o wartości przekraczającej 50 000 (USD/EUR). CASP, za pośrednictwem którego doszło do tej płatności, musi uwzględnić ją w swoim raporcie.

W praktyce odnotuje on, że użytkownik wysłał określoną kwotę stablecoina w charakterze zapłaty – wskaże rodzaj aktywa (np. USDC), wartość transakcji w walucie fiat (60 000 USD) oraz oznaczy, że była to płatność za dobro/usługę.

W strukturze logicznej XSD znajduje się odpowiedni znacznik RRPT, informujący, że dana transferowana kwota stanowi transakcję płatniczą podlegającą raportowaniu. Należy zaznaczyć, że małe płatności poniżej ok. 1000 EUR mogą być zwolnione z raportowania w DAC8, jednak kwota 60 tys. USD zdecydowanie przekracza ten próg – transakcja jest więc w pełni raportowana.

Kluczowe pola CARF XML

<RRPT> = znacznik transakcji Reportable Retail Payment Transaction, informujący o wykorzystaniu kryptoaktywa jako środka płatniczego powyżej progu wartości. W schemacie struktury logicznej przy tym polu znajdzie się informacja, że użytkownik zrealizował płatność w kryptowalucie za towar/usługę o wartości 60 000 USD (przekraczającej 50 tys.).

W takim case study CASP wskaże także szczegóły transakcji, m.in. typ użytego stablecoina oraz dokładną kwotę. (Wartość ta zostanie zapewne podana w dolarach lub innej walucie referencyjnej zgodnie z wymogami struktury logicznej).

Case study 3: Transfer na unhosted wallet (prywatny portfel)

Sytuacja: Klient zleca wypłatę kryptowaluty z giełdy (np. 1,5 BTC) na swój prywatny portfel. Adres docelowy nie jest powiązany z żadną inną platformą czy instytucją finansową – to tzw. unhosted wallet, należący wyłącznie do użytkownika.

Raportowanie DAC8

Transfer kryptoaktywów na zewnętrzny, nieregulowany portfel podlega szczególnemu oznaczeniu w schemacie struktury logicznej. Z perspektywy CASP jest to wyjście środków poza ekosystem regulowany, co jest istotną informacją dla organów (wiąże się np. z ryzykiem ukrycia aktywów poza zasięgiem łatwego monitoringu).

W schemacie CARF przewidziano dedykowany element TransferWallet – służy on do raportowania transferów na adresy nieznane jako powiązane z VASP lub instytucją finansową. Giełda raportująca wskaże więc, że dana wypłata trafiła na taki unhosted wallet.

W polu tym podaje się adres blockchain docelowego portfela (o ile jest dostępny) oraz powiązane szczegóły transakcji – rodzaj i ilość wypłaconej kryptowaluty, czas transferu itp. Dzięki temu w przekazywanym raporcie jasno widać, że środki opuściły platformę do prywatnego portfela użytkownika, a nie zostały przeniesione np. na inną giełdę czy konto custodialne. Dla organów podatkowych to sygnał, że dalsze śledzenie tych aktywów może wymagać dodatkowych narzędzi (np. analiz blockchain).

Kluczowe pola CARF XML

<TransferWallet> = informacja o transferze na portfel zewnętrzny (poza nadzorowanym podmiotem). Pole to zawiera m.in. adres docelowego portfela unhosted (ciąg znaków identyfikujący wallet, na jaki dokonano wypłaty) oraz może zawierać dodatkowe atrybuty identyfikujące okoliczności transferu. Użycie tego elementu oznacza dla organu podatkowego, że raportowana transakcja to wypływ kryptowaluty na nieznany adres, co zostało odnotowane zgodnie z wymogami DAC8. 

Case study 4: Klient zagraniczny z polską rezydencją podatkową

Sytuacja: Użytkownik będący obywatelem innego kraju (np. Francuz) mieszka i pracuje w Polsce, przez co posiada rezydencję podatkową w Polsce. Korzysta on z zagranicznej giełdy kryptowalut (np. platformy zarejestrowanej w innym kraju UE) do obrotu kryptoaktywami.

Raportowanie DAC8

Z perspektywy DAC8 kluczowa jest rezydencja podatkowa klienta, niezależnie od obywatelstwa czy siedziby giełdy. W powyższym scenariuszu użytkownik jest polskim rezydentem, korzystającym z usług zagranicznego CASP. Taki CASP ma obowiązek uwzględnić tego klienta w swoim pliku DAC8, ponieważ klient posiada Nexus podatkowy z Polską (tj. podlega opodatkowaniu w PL jako rezydent).

Platforma w swoim pliku XML wykaże dane identyfikacyjne użytkownika, w tym kraj rezydencji = PL oraz lokalny numer TIN (polski numer identyfikacji podatkowej, np. PESEL lub NIP). Transakcje tego użytkownika zostaną zsumowane i przekazane polskim organom za pośrednictwem mechanizmu automatycznej wymiany informacji – odbywa się to w ten sposób, że giełda raportuje dane do swojego rodzimego fiskusa, a ten przekazuje je dalej do Polski (zgodnie z procedurami DAC8).

W efekcie polskie organy skarbowe otrzymają informację o dochodach i obrotach kryptowalutowych polskiego rezydenta, mimo że korzystał on z zagranicznej platformy. Dla działów podatkowo-compliance ważne jest upewnienie się, że w procesie KYC klient poprawnie zadeklarował Polskę jako kraj rezydencji i podał prawidłowy TIN – te dane muszą trafić do zaraportowanego pliku XML.

Z perspektywy CASP ważny jest także własny nexus raportujący – np. fakt, że giełda jest zarejestrowana lub posiada siedzibę w konkretnym kraju UE – co wskazuje się w sekcji struktury logicznej dla CASP kodem CARF901–907. Jednak w tym scenariuszu najistotniejsze są pola dotyczące identyfikacji użytkownika.

Kluczowe pola CARF XML

<ResCountryCode> = kod kraju rezydencji podatkowej użytkownika. W tym przypadku CASP wskaże "PL" dla Polski, sygnalizując że klient jest polskim rezydentem podatkowym. (Jeśli użytkownik ma wielką liczbę rezydencji, struktura logiczna umożliwia zaraportownaie więcej niż jednego kod kraju).

<TIN> = Tax Identification Number użytkownika w zadeklarowanym kraju rezydencji. Dla polskiego rezydenta będzie to zazwyczaj PESEL (dla osób fizycznych) lub NIP (np. dla JDG), w zależności od statusu podatnika. CASP ma obowiązek zaraportować ten numer – a jeśli klient nie posiada polskiego TIN lub go nie podał, należy zaraportować wartość “NOTIN” z flagą unknown. Poprawne raportowanie TIN jest niezbędne, ponieważ umożliwia polskim organom jednoznaczną identyfikację podatnika.

<UserID> = unikalny identyfikator użytkownika w systemie CASP. Choć nie jest to pole wymagane przez OECD w każdej jurysdykcji, wiele platform przypisuje każdemu klientowi własny ID użytkownika lub numer konta. Ujęcie go w raporcie (jeśli jest przewidziane lokalnie) ułatwia późniejszą komunikację między organami, pozwalając powiązać raportowane transakcje z konkretnym klientem w systemie danej giełdy.

<Nexus> = pole używane w sekcji schematu struktury logicznej dotyczącej identyfikacji CASP (nie bezpośrednio użytkownika, ale warto je tutaj wspomnieć w kontekście pełnego obrazu struktury logicznej). Określa ono podstawę podlegania platformy pod daną jurysdykcję podatkową, za pomocą kodów CARF901–907. Przykładowo: CARF901 oznacza, że CASP jest inkorporowany (zarejestrowany) w danym kraju; CARF902 – że posiada tam miejsce zamieszkania lub zarządu; CARF904  – że ma oddział lub stałe miejsce prowadzenia działalności; aż po CARF907, który UE przewidziała dla zdalnego świadczenia usług na jej terytorium. Dzięki temu administracja podatkowa wie, dlaczego dany podmiot raportuje w określonym kraju (np. giełda X raportuje w Austrii, bo tam ma siedzibę – CARF901, albo giełda Y raportuje we Francji, bo choć formalnie nie jest regulowana przez MiCA, to świadczy usługi klientom z UE – CARF907).