DAC8 and CARF Crypto Reporting: What Cyprus Crypto-Asset Firms Must Do Before the 30 June 2027 First Report

The commercial reality most Cyprus crypto firms have not yet internalised is this: reporting is retroactive to 1 January 2026, so any provider whose onboarding and transaction-data capture is not already running has a data gap it cannot lawfully backfill before the deadline. This guide sets out who is caught, exactly what must be captured, and a concrete roadmap to the 30 June 2027 filing.

Last updated: August 2026

What are DAC8 and CARF, and why do they matter for Cyprus crypto firms?

DAC8 and CARF are the tax-transparency rules that force crypto-asset firms to report their users' identities and transaction values to tax authorities each year. For a Cyprus firm, DAC8 turns crypto reporting from a voluntary best practice into a mandatory annual obligation owed to the Cyprus Tax Department, backed by EU law and an international standard. If you exchange, custody, broker or process crypto-assets for clients with a Cyprus nexus, these rules almost certainly apply to you.

What is the Crypto-Asset Reporting Framework (CARF)?

The Crypto-Asset Reporting Framework (CARF) is the OECD's global standard for the automatic exchange of tax information on crypto-asset transactions, completed by the OECD together with the G20 in 2023. CARF requires crypto-asset service providers to identify their users, determine each user's jurisdiction of tax residence, and report annual transaction data to their home tax authority, which then exchanges it with partner jurisdictions. CARF does the same job for crypto that the Common Reporting Standard (CRS) has done for bank accounts since 2016.

CARF is deliberately broad. It imposes no minimum reporting threshold, so in principle every reportable transaction is captured regardless of size, and it reaches exchanges, brokers, custodians and certain wallet providers.

What is DAC8 and how does it bring CARF into EU law?

DAC8 is Council Directive (EU) 2023/2226 of 17 October 2023, which amends Directive 2011/16/EU on administrative cooperation in the field of taxation (the DAC) and imports CARF into binding EU law. DAC8 makes CARF-style crypto reporting mandatory across all EU Member States on a harmonised legal basis, rather than leaving each state to adopt the OECD standard voluntarily. The Directive was published in the Official Journal and its official text is available on EUR-Lex.

Because DAC8 is a Directive, each Member State had to transpose it into national law. The transposition deadline was 31 December 2025, and the rules apply from 1 January 2026, making 2026 the first reporting year across the Union.

How DAC8/CARF relate to CRS, MiCAR and the FATF Travel Rule

DAC8, CRS, MiCAR and the FATF Travel Rule are four overlapping but distinct regimes, and a Cyprus crypto firm typically sits inside all of them at once. Keeping them separate in your compliance design avoids duplicated work and dangerous gaps.

The practical link is that DAC8 reuses much of the customer data you already hold for MiCAR authorisation and anti-money-laundering (AML) purposes. If you are still at the licensing stage, our guide on registering a Crypto-Asset Service Provider in Cyprus explains the CySEC and MiCAR framework that sits alongside these reporting duties.

Has Cyprus actually implemented DAC8 yet?

Yes. Cyprus has transposed DAC8 into national law, and the obligation is live now rather than pending. The rules apply retroactively from 1 January 2026, which is why data capture cannot wait.

The Cyprus transposing law and its entry into force

Cyprus transposed DAC8 through the Administrative Cooperation in the Field of Taxation (Amending) Law of 2026, Law 38(I)/2026, published in the Official Gazette of the Republic of Cyprus on 27 March 2026 and entering into force on that date with retroactive application from 1 January 2026. The instrument amends the principal Law 205(I)/2012 and carries the reporting and due-diligence rules in its Article 7ΣΤ and Annex VI, and it fixes the 30 June 2027 first-reporting deadline for calendar-year 2026 data. The Cyprus Tax Department is designated as the competent authority for receiving reports and exchanging information with EU peers.

Why the retroactive 1 January 2026 start date matters

The retroactive start date matters because it means the first reporting period was already running before the Cyprus law was even gazetted. Reporting covers all of calendar year 2026, so transactions from 1 January 2026 onward are in scope even though Law 38(I)/2026 only entered into force on 27 March 2026. A firm that switched on compliant onboarding in, say, April 2026 is still expected to report the full year, including the first quarter it may not have properly captured.

This retroactivity is the single most important operational fact in this article, and it drives the data-gap problem addressed below.

The January 2026 European Commission infringement context

On 30 January 2026 the European Commission opened infringement procedures against 12 Member States, including Cyprus, for failing to implement DAC8 by the 31 December 2025 deadline. This context explains why the Cyprus law arrived only in March 2026 with retroactive effect: the state was closing a gap the Commission had formally flagged. The Commission sent letters of formal notice under Article 258 of the Treaty on the Functioning of the European Union, giving each state two months to respond, and because Cyprus completed transposition with Law 38(I)/2026 in March 2026 it has since remedied the deficiency the letter identified, with the Commission's practice being to discontinue such procedures once full transposition is notified. For firms, the takeaway is that neither late national legislation nor the infringement dispute delays your own reporting duty for 2026 data.

Who is a Reporting Crypto-Asset Service Provider (RCASP) in Cyprus?

A Reporting Crypto-Asset Service Provider (RCASP) in Cyprus is any crypto-asset service provider licensed in Cyprus under MiCAR, or any Crypto-Asset Operator with a Cyprus nexus, meaning Cyprus tax residence, incorporation, place of effective management, or usual place of business. If any one of these connecting factors applies, DAC8 reporting to the Cyprus Tax Department is mandatory. The definition is deliberately wide so that firms cannot escape reporting simply by holding their licence elsewhere while operating from Cyprus.

MiCAR-licensed CASPs based in Cyprus

Any entity holding a MiCAR authorisation from CySEC and based in Cyprus is an RCASP. This is the clearest category: exchanges, brokers, custodial wallet providers, portfolio managers and advisers licensed under the Markets in Crypto-Assets Regulation are directly captured. If your firm went through CySEC authorisation to provide crypto-asset services, you should assume RCASP status and build reporting accordingly.

Crypto-Asset Operators with a Cyprus nexus

A Crypto-Asset Operator that is not MiCAR-licensed can still be an RCASP if it has a Cyprus nexus. The connecting factors are Cyprus tax residency, incorporation in Cyprus, place of effective management in Cyprus, or usual place of business in Cyprus. This sweeps in operators that provide crypto-asset services without holding a MiCAR licence, including some firms that assumed they were outside the perimeter. A Cyprus-incorporated holding or operating company that facilitates crypto transactions should test itself against these factors carefully, because incorporation alone can trigger the obligation.

How to run a positive RCASP determination and document it

To determine RCASP status, test your entity against each connecting factor in turn and record the reasoning in a dated file. A defensible determination protects the board if the analysis is later questioned.

1. Confirm whether the entity holds, or should hold, a MiCAR authorisation in Cyprus.
2. Assess Cyprus tax residency and place of effective management, drawing on your analysis of Cyprus tax residency and non-domiciled status.
3. Check the place of incorporation and the usual place of business.
4. Record a written conclusion, the date, and the person responsible, and refresh it if the business changes.
5. Where the result is positive, register with the Cyprus Tax Department and begin reporting for 2026.

If you are still structuring the entity, how to open a company in Cyprus sets out the incorporation steps that themselves create a Cyprus nexus for these purposes.

What is the 30 June 2027 first-reporting deadline and what does it cover?

The 30 June 2027 first-reporting deadline is the date by which every Cyprus RCASP must file its first DAC8 report, covering all reportable crypto-asset activity for calendar year 2026, with the Cyprus Tax Department. Miss it and you are in breach of Law 38(I)/2026 for the entire first year of the regime. The deadline is fixed and applies uniformly regardless of when in 2026 your firm began operating.

The reporting period: calendar year 2026

The first reporting period is the full calendar year from 1 January 2026 to 31 December 2026. Every reportable exchange transaction, transfer and reportable retail-payment transaction executed for a reportable user during that year must be captured and aggregated. Because the year is already well advanced, the window to fix any capture failures is closing.

Filing to the Cyprus Tax Department by 30 June 2027

The report is filed to the Cyprus Tax Department (CTA), the designated competent authority, by 30 June 2027. The CTA is expected to publish a technical reporting schema specifying the file format and data fields, but the substantive catalogue of reportable items is already fixed by Annex VI of Law 38(I)/2026, which mirrors the CARF and DAC8 templates: for each reportable user and each reportable crypto-asset, the RCASP reports the gross amounts and number of units for acquisitions, disposals, transfers in, transfers out and reportable retail-payment transactions. Firms should not wait for the schema before capturing data, because the underlying fields are already defined by CARF and DAC8.

EU-level exchange of information by 30 September 2027

After receiving reports, the Cyprus Tax Department exchanges the information with other EU tax authorities by 30 September 2027. At EU level, the first DAC8 exchanges for the 2026 reporting year take place within nine months of year-end, that is between 1 January and 30 September 2027. This means data you file in Cyprus about a German or French resident user is routed to that user's home tax authority within months, so accuracy has cross-border consequences.

Why must your data capture already be live now?

Your data capture must already be live because DAC8 reporting is retroactive to 1 January 2026 and the required transaction and self-certification data generally cannot be reconstructed after the fact. Every day of trading without compliant capture creates a permanent hole in your 2026 report. This is the operational heart of the whole regime for Cyprus firms.

The retroactive data-gap problem you cannot backfill

The data-gap problem is that transaction-level details and validly collected self-certifications lose integrity once the moment has passed. You cannot credibly recreate a January 2026 self-certification of tax residence in mid-2027, and you cannot reconstruct exchange values and counterparties that were never recorded to the CARF standard. An RCASP that started capturing DAC8 data late therefore faces a gap that is not a mere formatting fix but a substantive evidentiary shortfall.

What a compliant onboarding flow should already collect

A compliant onboarding flow should already collect, at account opening, a valid self-certification of tax residence plus the full identity dataset, and should be validating that data against your AML and know-your-customer (KYC) records. If any of the following are missing from your current flow, you have work to do immediately:

• A structured self-certification capturing every jurisdiction of tax residence and the Tax Identification Number (TIN) for each.
• Full legal name, residence address, date of birth and, for individuals, place of birth.
• Controlling-person data for entity users.
• A reasonableness check that reconciles the self-certification against existing AML/KYC data.
• Transaction logging that records the data points needed for annual aggregation.

Remediating a 2026 data gap before the filing

If you already have a 2026 gap, remediation means moving fast to collect fresh self-certifications, reconstruct what can be evidenced, and document the limits of what cannot. Early legal advice is essential, because the way you characterise and disclose a gap to the Cyprus Tax Department affects your exposure. Do not wait until 2027 to discover the hole, when the remediation window has effectively closed.

What crypto-assets and transactions are reportable?

Reportable crypto-assets are, broadly, assets that can be held and transferred in a decentralised manner using distributed-ledger technology, and reportable transactions are exchanges between crypto and fiat, exchanges between different crypto-assets, and certain transfers including reportable retail payments. The scope is wide by design, though specific carve-outs exist for assets that cannot be used for payment or investment and for central bank digital currencies.

Crypto-assets in and out of scope (stablecoins, NFTs, CBDCs, e-money)

Most tradeable crypto-assets are in scope, while central bank digital currencies (CBDCs) and certain e-money products are treated separately and may fall outside the crypto rules. Stablecoins are generally in scope as crypto-assets, and non-fungible tokens (NFTs) are in scope where they are used for payment or investment rather than being genuinely unique collectibles. Cyprus follows the DAC8 definitions in Annex VI of Law 38(I)/2026 directly: central bank digital currencies and specified electronic-money products are carved out of the crypto-asset reporting stream and instead captured under the amended Common Reporting Standard financial-account rules, while stablecoins that are not e-money products remain in scope as crypto-assets. Because the classification of a specific token can be finely balanced, borderline assets should be assessed case by case.

Exchange transactions: crypto-to-fiat and crypto-to-crypto

Exchange transactions are reportable in both directions: crypto-to-fiat and crypto-to-crypto. This means a user swapping Bitcoin for euro and a user swapping Bitcoin for Ether both generate reportable events. For each, the RCASP reports the aggregate annual number of transactions and gross values, distinguishing acquisitions from disposals, so your transaction log must record enough detail to build those aggregates per user per asset type.

Transfers and reportable retail payment transactions

Transfers of crypto-assets to and from a user, and reportable retail payment transactions processed on behalf of a merchant, are also within scope. Retail-payment transactions become reportable when they cross the EUR 50,000 threshold, discussed below. Where a user withdraws crypto to an external wallet, the RCASP reports the transfer, and where the destination is not another RCASP, additional detail may be required.

What due diligence and self-certification must RCASPs perform?

RCASPs must perform CARF-style due diligence: obtain a valid self-certification of tax residence from every user, test it for reasonableness against existing AML/KYC information, and enforce consequences when a user fails to provide one. This due diligence is not optional paperwork; it is the mechanism that makes the annual report accurate and legally defensible.

Collecting valid self-certifications of tax residence

A valid individual self-certification must include the user's full name, residence address, every jurisdiction of tax residence, the TIN for each reportable jurisdiction, and date of birth. A self-certification missing any required field is not valid and does not discharge your obligation. Collect it at onboarding for new users and retrospectively for pre-existing users within the timelines set by the framework.

The reasonableness test against existing AML/KYC data

The reasonableness test requires the RCASP to confirm that a self-certification is consistent with the AML and KYC data already held on the user. If a user certifies tax residence in one country while your KYC file shows an address and identity documents pointing elsewhere, the self-certification fails the reasonableness test and must be cured before it can be relied upon. Because you already hold this data for MiCAR and AML purposes, the check is largely a reconciliation exercise, and firms handling beneficial-ownership data should align it with the Cyprus UBO register and beneficial-ownership compliance obligations.

The two-reminder / 60-day rule and blocking non-compliant users

Under CARF and DAC8, if a user does not provide a valid self-certification after two reminders within 60 days, the RCASP must block that user from carrying out reportable transactions on the platform until a valid self-certification is provided and validated. This blocking rule is a hard requirement, not a discretionary sanction. Your systems must therefore be able to track reminder counts, run the 60-day clock, and automatically restrict a non-compliant account. Build this workflow now, because manual enforcement across a live user base does not scale.

Exactly what data must you collect and report per user?

Per user, an RCASP must collect and report the user's full identity and tax-residence details together with aggregated annual values for their reportable transactions. The dataset mirrors CRS but is adapted for crypto, and getting the fields right at capture is what makes the eventual filing straightforward.

Individual user data fields (name, address, TIN, date and place of birth)

For an individual user you must collect and report the full legal name, residence address, every jurisdiction of tax residence, the TIN for each such jurisdiction, and the date of birth, with place of birth also required in defined cases. These fields must be validated against AML/KYC records under the reasonableness test. Missing or unverified TINs are a common failure point, so treat TIN collection as a gating step at onboarding rather than an afterthought.

Entity users and controlling persons

For an entity user you must collect the entity's identity and tax-residence data and, where the entity is a passive vehicle, look through to its controlling persons and report them too. This look-through prevents individuals from hiding behind corporate wallets. Identifying controlling persons draws directly on the beneficial-ownership analysis your firm already performs, so integrate the two data sets rather than running them separately.

Aggregated annual transaction values reported per user

The report contains aggregated annual values per user: for each reportable crypto-asset, the gross amounts and number of units for acquisitions, disposals, transfers in, transfers out and reportable retail payments. You do not report every individual transaction line, but you must have captured every line to build the aggregates accurately. This is why granular transaction logging from 1 January 2026 is non-negotiable.

How does DAC8 differ from the global CARF standard?

DAC8 differs from the global CARF standard mainly in its EU-specific features, most notably a EUR 50,000 threshold for reportable retail-payment transactions and its integration with the wider DAC exchange machinery. In substance the two are aligned, so a CARF-compliant system is most of the way to DAC8 compliance, but the EU-specific details matter for a Cyprus firm reporting under Law 38(I)/2026.

Thresholds: the EUR 50,000 retail-payment rule

DAC8 applies a EUR 50,000 threshold for reportable retail-payment transactions processed by a crypto-asset service provider, above which the transaction is in scope even if the recipient is not otherwise a reportable user. CARF, by contrast, imposes no general minimum reporting threshold, so every transaction is captured regardless of size. Cyprus adopts this EUR 50,000 figure exactly as set by Annex VI of the Directive, transposed without local deviation into Law 38(I)/2026, so the same threshold that applies across the Union applies in Cyprus. For Cyprus firms this means retail-payment processing needs its own threshold logic layered on top of general reporting.

Scope and stablecoin/e-money treatment differences

DAC8 contains EU-specific treatment of stablecoins and e-money that can diverge in detail from the OECD text, and the exact position depends on the Cyprus implementing law. Where DAC8 offers options on how far e-money and CBDC-adjacent products are covered, Cyprus's choices in Law 38(I)/2026 govern, and Annex VI of that law places central bank digital currencies and specified electronic-money products under the amended CRS financial-account regime rather than the crypto stream. Until the Cyprus schema and guidance are published, treat other stablecoins as in scope and document your reasoning for any exclusion.

Overlap with existing Cyprus crypto tax obligations

DAC8 reporting is separate from, and additional to, Cyprus crypto tax liability. From 1 January 2026 Cyprus taxes gains from disposals of crypto-assets at a flat 8% under a dedicated statutory regime, and that liability sits on the user, whereas DAC8 reporting sits on the RCASP. The two interact but do not replace each other, as our guide to cryptocurrency taxation in Cyprus for individuals and companies explains, alongside the broader Cyprus tax reform 2026 changes.

What are the penalties and risks of getting DAC8 wrong in Cyprus?

The penalties and risks of getting DAC8 wrong in Cyprus span financial penalties for reporting failures, licensing and reputational damage with CySEC and MiCAR, and personal accountability for the board and compliance officers. Beyond the direct financial penalties written into the law, the strategic risk to a regulated crypto business is significant enough to justify early investment in compliance.

Non-compliance and reporting-failure exposure

Non-compliance exposure includes penalties for failing to file, filing late, filing inaccurate data, or failing to collect valid self-certifications. Under Law 38(I)/2026 the Cyprus Tax Department can impose administrative penalties of up to EUR 5,000 for due-diligence failures, such as failing to collect or verify a valid self-certification, and up to EUR 10,000 for record-keeping, reporting and registration failures, including failing to file, filing late or filing inaccurate data. Firms should assume that a failure to obtain self-certifications and to enforce the blocking rule is itself a distinct breach, not merely a data-quality issue.

Reputational and licensing risk with CySEC/MiCAR

A DAC8 failure carries reputational and licensing risk because your MiCAR authorisation is granted and supervised by CySEC, which expects strong compliance culture. A tax-transparency breach can feed into the supervisory assessment of a firm's fitness and governance, even though DAC8 itself is administered by the Cyprus Tax Department. For a licensed CASP, the indirect regulatory consequence can outweigh any direct financial penalty.

Board and compliance-officer accountability

Ultimate accountability for DAC8 compliance rests with the board and the designated compliance officer, who are responsible for ensuring systems, self-certification workflows and reporting are in place. Directors should minute their oversight of DAC8 readiness and satisfy themselves that the retroactive data-capture position is under control. Documented governance is both a defence and a genuine risk-reduction measure.

What is your practical DAC8/CARF compliance roadmap to 30 June 2027?

Your practical roadmap to 30 June 2027 is to confirm RCASP status, close any live data-capture gap immediately, build the self-certification and reporting workflows, map your data to the reporting schema, and file on time with legal and tax support. The sequence matters, because the retroactive data-capture step is time-critical and everything else builds on clean data.

A step-by-step readiness checklist

1. Run and document a positive or negative RCASP determination for each Cyprus entity.
2. Confirm your onboarding is capturing valid self-certifications now, and remediate any gap back to 1 January 2026.
3. Implement the two-reminder, 60-day self-certification workflow with automatic blocking.
4. Reconcile self-certifications against AML/KYC data under the reasonableness test.
5. Capture granular transaction data sufficient to build annual aggregates per user.
6. Register with the Cyprus Tax Department and prepare the reporting file.
7. File the calendar-year 2026 report by 30 June 2027.

Systems, data mapping and reporting-schema build

The systems workstream is to map every required field to a source system and build extraction into the Cyprus Tax Department's reporting schema once published. Treat data mapping as the bridge between your live KYC and transaction systems and the eventual XML or structured file the CTA requires. Where holding structures are involved, coordinate this with any planning around holding crypto through a Cyprus International Trust so that reporting and asset-protection design are consistent.

When to bring in Cyprus legal and tax advisers

Bring in Cyprus legal and tax advisers now if you have any live data gap, any doubt over RCASP status, or any complexity in your token or user base. The cost of early advice is small against the exposure of a defective first filing or an uncured 2026 data gap. Advisers can also align your DAC8 build with your wider obligations under an overview of taxes in Cyprus.

How Philippou Law Firm can help

Philippou Law Firm advises Cyprus crypto-asset firms on the full DAC8 and CARF compliance lifecycle, from confirming RCASP status and diagnosing retroactive data gaps to building compliant self-certification workflows and preparing the first filing to the Cyprus Tax Department. Our lawyers work alongside your compliance and technology teams so that reporting, MiCAR licensing and Cyprus crypto tax planning fit together rather than pulling in different directions. If you operate a crypto business with any Cyprus nexus, contact us now, well ahead of the 30 June 2027 deadline, so that any data-capture issue can be addressed while it is still fixable.

This article is general information, not legal advice. Please seek advice on your specific circumstances before acting.