Multi-jurisdiction crypto tax for global platforms

A platform that operates in 195 countries with on-chain settlement, a native token, and a card product is, at any given moment, generating taxable events in dozens of jurisdictions simultaneously. The question is not whether the obligations exist. They exist. The question is whether the data architecture, the policy framework, and the reporting infrastructure are equal to identifying, calculating, and meeting them in the same period in which they arise.

The CFO who treats this as a tax compliance project visiting finance occasionally will discover, usually at the audit, that the obligations have been accruing without being met. The CFO who treats it as a finance architecture project with tax compliance as one output will discover that the system mostly handles itself.

The three obligations every global platform faces

For a platform handling crypto-asset transactions internationally, three categories of obligation operate in parallel.

• Indirect tax. VAT in the EU and equivalents elsewhere, applied to the supply of goods, services, or digital products. Crypto transactions can be inside or outside the VAT base depending on the nature of the supply, the location of the customer, and the entity's registration.
• Direct tax. Corporation tax on the entity's profits, including gains and losses on crypto-asset positions held or transacted during the period. The treatment differs by jurisdiction, by classification of the asset, and by the entity's specific facts.
• Information reporting. DAC7 in the EU, equivalent regimes elsewhere, requiring platforms to report seller information and transaction values to tax authorities. The reporting is a finance and data architecture obligation, not merely a legal one.

Each category requires its own data, its own calculation, and its own filing rhythm. The platform that builds the data architecture once, with all three in mind, runs a fundamentally cheaper compliance operation than the platform that retrofits each category as it becomes urgent.

VAT and the OSS scheme

The EU's One-Stop-Shop scheme allows a platform to register in a single member state and file VAT for B2C digital services supplied across the EU through that single registration. For a global platform with EU exposure, OSS is generally the right architecture, but it requires the underlying transaction data to be coded by customer location, by supply type, and by VAT treatment at the moment of transaction.

For crypto-specific transactions, several treatments matter:

• The exchange of cryptocurrency for fiat is, following the Hedqvist decision, exempt from VAT in the EU on the same basis as foreign currency exchange.
• The supply of digital services priced in crypto is generally subject to VAT in the customer's location, with the exchange rate at the moment of supply determining the VAT base.
• The retirement of a carbon credit on behalf of a customer is a separate supply with its own VAT treatment that depends on the precise structure of the offering.

Each of these treatments has to be applied at the transaction level. Retrospective reconstruction is possible but expensive. Real-time tagging is cheaper.

Direct tax: gain, loss, and the FX overlay

For the entity's own crypto-asset positions, each disposal produces a gain or loss that has to be recognised for tax purposes. The acquisition cost has to be tracked, the disposal proceeds calculated, and the gain or loss reported in the jurisdiction where the entity is taxable.

Two complications arise frequently:

First, the FX overlay. A crypto-asset position acquired in dollars and disposed of in dollars still produces a foreign currency gain or loss for an entity whose functional currency is euros. The dollar position has to be revalued at the closing rate of each period, and the closing balance has to be translated. The treatment of the FX component varies by jurisdiction.

Second, the identification convention. When the entity holds multiple lots of the same token acquired at different prices, the order in which lots are deemed to be disposed of — first-in-first-out, last-in-first-out, weighted average, specific identification — affects the gain or loss for the period. The convention has to be elected, applied consistently, and documented.

For a platform handling thousands of transactions a day across multiple wallets, the only practical answer is software that maintains the lot history, applies the convention, and produces the calculations at the cadence the tax authority requires. Spreadsheet reconstruction does not scale.

DAC7 and the reporting layer

The EU's DAC7 directive requires digital platforms to collect, verify, and report seller information and transaction details for sellers using the platform to supply goods, services, immovable property, or means of transport. The reporting is annual, but the data collection is continuous, and the verification requirements — including cross-checks against authoritative sources — are non-trivial.

For a crypto-enabled platform, DAC7 sits alongside MiCA reporting and any local financial-services reporting that applies. The data points overlap but are not identical. The architecture must extract the right population for the right report at the right time. Building a shared data backbone with multiple reporting views is the design that survives. Building separate pipelines for each report is the design that fails.

Where the architecture has to do the work

The data architecture for a multi-jurisdiction crypto-tax compliant platform has identifiable common components.

• Transaction-level metadata. Every transaction is tagged with the supply type, the customer location, the entity it belongs to, the FX rate at the moment of execution, and the regulatory population it sits in.
• Asset-level lot tracking. Every crypto-asset position has a documented acquisition history with cost, date, and source. Disposals draw from the history under the elected convention.
• Customer-level verification. Seller and buyer information is verified once, refreshed periodically, and made available to the reporting layer without manual reconstruction.
• Regulatory mapping. The mapping between transaction characteristics and regulatory population is maintained as a deliberate artefact, reviewed when regulations change, and version-controlled.
• Audit trail. The full transaction history, with the regulatory treatment applied at each step, is retained for the periods required by each jurisdiction.

Three principles that keep the architecture honest

First, code the treatment at the moment of transaction, not at the moment of reporting. Retrospective coding loses information that was available only in real time.

Second, treat the data architecture as a finance asset, not a tax-team utility. The same data feeds the management accounts, the financial audit, the regulatory reporting, and the strategic analysis. Investing in it is investing in all of those simultaneously.

Third, document the policy positions where the treatment is judgemental. The classifications that move the most tax — what is a digital service vs a financial service, what is the place of supply, what is the entity's economic activity in a given jurisdiction — are positions, not facts. They have to be defensible to multiple authorities applying overlapping rules.

This piece sits inside the CFO in blockchain framework. See also MiCA for the CFO and stablecoin treasury management. Lorna writes from practice at IMPT, where the platform operates in 195 countries. The verified page records what is and isn't published here.