Regulatory Compliance Framework
Regulatory Compliance Framework
Section titled “Regulatory Compliance Framework”CryptaCount is designed to produce data that satisfies three overlapping EU regulatory frameworks while remaining useful globally. The platform does not itself perform regulated activities — it provides the computational infrastructure that regulated entities (accounting firms, audit practices, licensed tax advisers) use to meet their obligations.
EU Regulatory Landscape
Section titled “EU Regulatory Landscape”DAC8 — Directive on Administrative Cooperation
Section titled “DAC8 — Directive on Administrative Cooperation”DAC8 extends the EU’s tax information exchange framework to crypto-assets. It requires crypto-asset service providers (CASPs) and intermediaries to report transaction and holding data to national tax authorities, who then exchange it across member states.
For CryptaCount’s users, DAC8 means their clients face new reporting obligations. The platform structures its data outputs to align with DAC8 reporting schemas, ensuring that the transaction data, holding periods, cost basis calculations, and gain/loss reports can be mapped to the required reporting formats.
MiCA — Markets in Crypto-Assets Regulation
Section titled “MiCA — Markets in Crypto-Assets Regulation”MiCA establishes a licensing and operational framework for crypto-asset service providers operating in the EU. While CryptaCount itself is not a CASP (it does not custody, trade, or transfer crypto-assets), its users often are — or serve clients who are.
The platform’s accounting outputs align with MiCA’s financial reporting requirements for licensed entities, including balance sheet treatment of crypto-assets, revenue recognition for crypto services, and regulatory capital calculations.
CARF — Crypto-Asset Reporting Framework
Section titled “CARF — Crypto-Asset Reporting Framework”CARF is an OECD standard for cross-border information exchange related to crypto-assets, analogous to CRS (Common Reporting Standard) for traditional financial accounts. It requires intermediaries to collect and report information on crypto-asset transactions to participating jurisdictions.
CryptaCount’s multi-jurisdiction tax profile system models CARF reporting requirements alongside domestic tax rules, enabling users to identify which transactions and holdings trigger CARF reporting obligations.
IFRS Alignment
Section titled “IFRS Alignment”For institutional users (businesses, funds, publicly reporting entities), the platform’s accounting methodology aligns with International Financial Reporting Standards:
- IAS 2 (Inventories) — Applied where crypto-assets are held as inventory (mining operations, market-making). NRV methods (NRV + FIFO, NRV + Weighted Average) implement IAS 2’s “lower of cost and net realizable value” principle.
- IAS 21 (Foreign Currency) — The FX translation methodology for non-USD reporting currencies follows IAS 21 guidance: monthly average rates for income/expense items, closing rates for balance sheet items.
- IAS 38 (Intangible Assets) — Relevant classification framework for crypto-assets held as intangible assets (the default IFRS treatment for most crypto-assets as of 2026).
- IFRS 13 (Fair Value Measurement) — Fair market value sourcing and hierarchy follows IFRS 13 principles for determining fair value of crypto-assets.
Luxembourg GAAP
Section titled “Luxembourg GAAP”For Luxembourg private companies (which are not required to use IFRS), the platform supports Luxembourg GAAP treatment. This is relevant because CryptaCount is Luxembourg-based and many of its initial clients are Luxembourg entities. Luxembourg GAAP treatment of crypto-assets differs from IFRS in several respects, particularly around revaluation reserves and impairment testing.
”Calculates but Doesn’t Decide”
Section titled “”Calculates but Doesn’t Decide””This principle is not a legal disclaimer — it is a foundational design decision that shapes every product feature.
The platform computes numbers: cost basis, fair market value, gains/losses, journal entries, rollforward schedules, tax-relevant amounts by jurisdiction. It does not make classification decisions that require professional judgment: whether a particular DeFi interaction constitutes a taxable event in a specific jurisdiction, whether a particular token should be classified as a security, or whether a specific holding period exemption applies.
This boundary is maintained throughout the product:
- Transaction types are automatically classified but always overridable by the user
- Jurisdiction tax profiles provide data (rates, rules, thresholds) but do not automatically generate final tax returns
- Reports are labeled as computational outputs, not as tax filings or regulatory submissions
- The platform explicitly surfaces areas where professional judgment is required rather than making silent assumptions
For the B2B audience (accountants, auditors, tax advisers), this is not a limitation — it is a feature. Professionals need tools that provide reliable data and computation, not tools that substitute their judgment. The platform enhances their efficiency without overstepping into their domain of expertise.