Crypto-asset Reporting Framework (CARF) 2026: Liechtenstein Deadlines, XML Schema & Penalties

Liechtenstein’s implementation of the Crypto-Asset Reporting Framework (CARF) entered into force in 2026, making the principality one of the early adopters of the OECD’s global standard for automatic exchange of tax information relating to crypto-asset transactions. Reporting entities, including licensed VASPs, trustees holding crypto assets, and certain brokers, now face annual submission deadlines in June, with the first automatic exchange of CARF data to partner jurisdictions scheduled for 2027. This article provides a practical compliance playbook covering who must report, which data elements are required, how to structure CARF XML files, the self-certification onboarding process, and the penalties that Liechtenstein’s tax authority (LLV) and financial regulator (FMA) may impose for non-compliance.

Quick-action summary for compliance teams:

• Confirm reporting status. Determine whether your entity falls within the CARF definition of a Reporting Crypto-Asset Service Provider.
• Map data elements to CARF XML fields. Begin extraction and validation of customer and transaction data against the OECD CARF XML schema.
• Calendar the June submission window. Set internal cut-off dates at least four weeks before the LLV filing deadline to allow for validation, corrections, and resubmission.

What Is CARF and Why Liechtenstein Implemented It

The Crypto-Asset Reporting Framework is an international standard developed by the OECD to close the tax-transparency gap created by the rapid growth of crypto-asset markets. Before CARF, the Common Reporting Standard (CRS) covered traditional financial accounts but did not capture transactions in decentralised or exchange-based crypto-asset ecosystems. The OECD published the CARF rules alongside the CRS revision 2026 amendments, creating a unified transparency architecture for both fiat and digital-asset holdings.

Liechtenstein, already a committed CRS jurisdiction and a signatory to the Multilateral Convention on Mutual Administrative Assistance in Tax Matters, transposed the OECD CARF standard into domestic law through its CARF Act and accompanying Regulation. The principality’s decision to adopt CARF early reflects both its established commitment to OECD tax-transparency initiatives and the significant presence of blockchain businesses operating under the Token and VT Service Provider Act (TVTG).

CARF Liechtenstein Deadlines & Exchange Schedule (2026–2027)

Compliance teams must anchor their project plans to the specific CARF Liechtenstein deadlines confirmed by the LLV. The timeline below sets out the key milestones from entry into force through the first international data exchange.

Industry observers expect the LLV to follow a pattern similar to CRS administration, where late submissions filed shortly after the deadline may attract administrative notices before escalating to formal penalties. Compliance teams should therefore build buffer time into their internal workflows, ideally completing XML generation by early May to allow a full month for validation, error correction, and any necessary resubmission before the June cut-off.

Who Must Report, Entities and Reporting Triggers

The CARF reporting requirements apply to Reporting Crypto-Asset Service Providers (RCASPs), a category defined by the OECD standard and transposed into Liechtenstein law. The practical scope extends beyond traditional exchanges to cover a range of intermediary activities. An entity is in scope if it conducts exchange services, transfer services, or safekeeping/administration of crypto assets on behalf of customers, and if it is resident in, incorporated in, managed from, or has a regular place of business in Liechtenstein.

Residency and Nexus Tests

A service provider triggers Liechtenstein reporting obligations where it meets any of the jurisdiction-nexus criteria above. For entities with multi-jurisdictional operations, the OECD CARF rules include tie-breaker provisions to avoid duplicative reporting. However, where doubt exists, the prudent approach is to report in each jurisdiction where a nexus is established and to coordinate with local counsel.

Entity-Type Comparison Table

Crypto-asset reporting framework obligations do not apply to closed-loop tokens that can only be redeemed with the issuer for goods or services, nor to central bank digital currencies (CBDCs). Stablecoins, however, are generally in scope where they function as a means of exchange or investment and are handled by an RCASP.

Reporting Scope: Required Data Elements and Mapping to the CARF XML Schema

The OECD’s CARF reporting requirements specify a defined set of data elements that must be captured for each reportable user and each reportable transaction. Liechtenstein’s implementing regulation follows the OECD standard closely, meaning that the data-element list below reflects both the international CARF rules and the domestic requirements enforced by the LLV.

Data Elements Overview

Reportable data falls into three categories: reporting-entity identification, reportable-person identification, and transaction and account data. The following table maps each human-readable field to its corresponding CARF XML element name and provides an illustrative example value.

Note that aggregated values may be required where a reportable person conducts multiple transactions of the same type during the reporting period. The OECD CARF standard permits, and in some cases requires, aggregation of gross proceeds and unit counts by transaction type and crypto-asset type within the same reporting period.

CARF XML Schema, Sample File, Field Mapping and Common Pitfalls

The CARF XML schema follows the structure established by the OECD for AEOI reporting. Reporting entities in Liechtenstein must generate XML files that conform to this schema before submission to the LLV. The high-level document structure uses a root element containing a message header and one or more account report records.

Illustrative XML Fragment

The following abbreviated fragment shows the core structure of a single CARF report record. It is illustrative and should be validated against the current OECD CARF XML Schema Definition (XSD) before use in production.

<CARFBody>
  <ReportingFI>
    <Name>Liechtenstein Crypto Exchange AG</Name>
    <TIN issuedBy="LI">FL-12345678</TIN>
    <ResCountryCode>LI</ResCountryCode>
  </ReportingFI>
  <AccountReport>
    <AccountHolder>
      <Individual>
        <Name>Max Mustermann</Name>
        <TIN issuedBy="AT">AT-987654321</TIN>
        <ResCountryCode>AT</ResCountryCode>
      </Individual>
    </AccountHolder>
    <AccountNumber>CARF-ACC-00042</AccountNumber>
    <TransactionRecord>
      <AssetType>BTC</AssetType>
      <TransactionType>Exchange</TransactionType>
      <GrossProceeds CurrCode="CHF">25000.00</GrossProceeds>
      <NumberOfUnits>0.75000000</NumberOfUnits>
    </TransactionRecord>
    <ReportingPeriod>2026-01-01 to 2026-12-31</ReportingPeriod>
  </AccountReport>
</CARFBody>

Common Validation Pitfalls

Errors in CARF XML files can trigger rejection by the LLV portal or, worse, result in inaccurate data reaching exchange partners. The following checklist highlights the most frequent issues encountered during schema validation.

Onboarding & Self-Certification for VASPs, Trustees and Fiduciaries

CARF self-certification onboarding is the operational foundation that enables accurate reporting. Before an RCASP can report on a customer, it must collect and verify identifying information through a due-diligence process that closely mirrors, and in some respects extends, existing CRS onboarding requirements.

Step-by-Step Onboarding Workflow

1. Update onboarding forms. Revise customer-facing account-opening documentation to include CARF-specific self-certification fields: tax residency declaration, TIN(s), and consent for data exchange.
2. Capture retrospective data. For customers onboarded before the CARF Act took effect, conduct a remediation exercise to collect missing TINs, residency declarations, and any updated identifying information.
3. Verify self-certifications. Apply reasonableness checks to self-certified data. Where information is inconsistent with existing KYC/AML records (for example, a declared tax residency that conflicts with the customer’s registered address), follow up with the customer and document the resolution.
4. Notify customers. Issue a privacy/data-sharing notice explaining that their information may be exchanged with foreign tax authorities under the crypto-asset reporting framework. This notice should reference Liechtenstein’s data-protection law and the CARF Act.
5. Maintain audit trail. Retain all self-certification forms, customer correspondence, and due-diligence evidence for the statutory retention period specified in the CARF Regulation.
6. Schedule periodic reviews. Reassess self-certifications at least annually or whenever a change-of-circumstances trigger (such as a change of address or new TIN) is detected.

Trustees and fiduciaries face an additional layer of complexity: they must identify the reportable persons behind discretionary structures, which may include settlors, beneficiaries, and protectors depending on the nature of the arrangement and the crypto-asset holdings involved.

CARF Penalties Liechtenstein, Enforcement & Practical Risk Mitigation

Liechtenstein’s CARF enforcement architecture follows the pattern established for CRS: the LLV administers reporting obligations, while the FMA exercises supervisory powers over licensed entities. Penalties may be imposed for a range of compliance failures, and the likely practical effect will be that repeat or material breaches attract escalating sanctions.

Best practice for risk mitigation includes appointing a dedicated CARF compliance officer, conducting a pre-submission dry run using the LLV’s validation tools (where available), and engaging specialist tax advisers to review the first-year filing. Entities seeking local expertise can consult the Liechtenstein lawyer directory, tax specialists for qualified practitioners.

CARF & MCAA, How Exchange Happens and What to Expect

Once the LLV receives validated CARF XML files from reporting entities, the data enters the intergovernmental exchange pipeline established under the OECD’s Multilateral Competent Authority Agreement (MCAA). The CARF MCAA Liechtenstein framework operates on the same principles as the CRS MCAA: competent authorities exchange data annually, subject to confidentiality safeguards and data-protection requirements set out in the Multilateral Convention.

Exchange Mechanics

Reporting entities do not select or control which jurisdictions receive data, this is determined by the exchange relationships that Liechtenstein has activated. Entities should monitor the OECD MCAA signatory list and any LLV announcements regarding newly activated bilateral exchange relationships.

Practical Checklist & Sample Submission Workflow

The following six-step workflow provides a template for internal compliance teams preparing their first CARF submission to the LLV.

1. Data collection (Compliance + IT). Extract all reportable-person records and transaction data from internal systems for the reporting period. Cross-reference against customer due-diligence files.
2. Data mapping and transformation (IT). Map extracted data to CARF XML field names using the data-element table above. Apply aggregation rules where required.
3. XML generation (IT). Generate the CARF XML file in accordance with the OECD XSD. Ensure UTF-8 encoding, ISO 8601 dates, and correct decimal precision.
4. Validation (Compliance + IT). Run the generated file through schema-validation tools. Check for duplicate records, missing TINs, and formatting errors. Remediate and regenerate as needed.
5. Submission (Compliance Officer / CRO). Upload the validated XML file to the LLV submission portal before the June deadline. Download and archive the submission confirmation receipt.
6. Record retention (Compliance). Store the submitted XML file, validation logs, submission receipt, and all supporting due-diligence documentation for the statutory retention period.

Conclusion, Acting on the Crypto-Asset Reporting Framework in Liechtenstein

The crypto-asset reporting framework (CARF) represents the most significant expansion of Liechtenstein’s automatic exchange of information regime since the original CRS implementation. With the CARF Act now in force, the June annual filing deadline is an operational reality for every in-scope VASP, trustee, and financial intermediary in the principality. Compliance teams that invest in robust data-mapping, schema-validation workflows, and updated onboarding procedures now will be best positioned to meet both the 2026 reporting requirements and the first international data exchange in 2027. Entities requiring localised guidance should consult qualified Liechtenstein tax practitioners to ensure their CARF implementation is complete, accurate, and audit-ready.

Sources

1. Liechtenstein Government (LLV), Official Tax Transparency and CARF Information
2. Finanzmarktaufsicht Liechtenstein (FMA)
3. OECD, Crypto-Asset Reporting Framework (CARF)
4. OECD, Multilateral Competent Authority Agreement (MCAA)
5. Australian Taxation Office (ATO), CARF and Domestic Reporting
6. Inland Revenue Department, Hong Kong, CARF Guidance