CARF Data Mapping Checklist

CARF/DAC8 reporting readiness depends on high-quality mapping of customer identity, tax residence/TIN, asset classification, transaction lifecycle data, and consistent valuation/FX rules. This checklist helps CASPs build a repeatable, validation-ready mapping model.

Goal

Prepare a CARF/DAC8-ready reporting dataset by mapping CASP customer and transaction data into a consistent structure that supports validation, reconciliation, and repeatable XML output generation.

Pre-requisites

  • Confirm which business lines/services are in scope for CARF/DAC8 reporting
  • Identify the authoritative systems for customer identity, onboarding/KYC, and transaction/ledger data
  • Decide the reporting perimeter (entities/platforms/branches) for the reporting period
  • Define a stable transaction identifier strategy for de-duplication across cycles
  • Confirm valuation and FX conversion methodology (sources, timestamps, rounding rules)
  • Establish a residence/TIN data model that supports multiple residencies where applicable

Workflow Steps

  • Lock in-scope activities and reportable events

    Define which services and transaction types are reportable under your implementation (trades, transfers, custody movements, etc.).

    Failure mode: inconsistent scoping causes under/over-reporting and rework.

  • Map customer identity (individual vs entity)

    Ensure required identity fields exist and are normalized (names, DOB/incorporation details, addresses, identifiers).

    Failure mode: incomplete identity data blocks reporting or triggers remediation.

  • Map tax residence and TIN model

    Support multiple residencies and link each residence to the correct identifier(s); normalize ISO country codes.

    Failure mode: residence/TIN mismatches are common validation failures.

  • Map account relationship and control/ownership context

    Ensure the reportable person/entity is correctly linked to accounts/wallets and (where required) beneficial ownership context is consistent.

    Failure mode: unclear linkage leads to incomplete party reporting and follow-ups.

  • Map crypto-asset classification

    Standardize asset identifiers/symbols and map products to consistent internal categories (spot, derivatives where applicable, etc.).

    Failure mode: misclassification creates wrong reportable-event tagging and inconsistent valuations.

  • Map transaction lifecycle fields

    Standardize transaction timestamps, type codes, direction, quantities, fees, and counterparties (where available).

    Failure mode: inconsistent timestamps and missing mandatory fields break business-rule validation.

  • Define valuation methodology and FX rules

    Define valuation methodology and FX rules

    Failure mode: inconsistent valuation leads to reconciliation gaps and disputes.

  • Create stable transaction identifiers and de-duplication logic

    Ensure each reportable transaction has a stable unique ID across systems and resubmissions.

    Failure mode: duplicates multiply during corrections and high-volume feeds.

  • Run pre-output validation checks

    Validate mandatory fields, code lists, residence/TIN consistency, and logical checks (e.g., quantity/value not negative where not expected).

    Failure mode: relying only on XML validation is too late.

  • Reconcile totals and volumes before submission

    Compare counts and value totals vs internal ledgers and customer statements to detect gaps early.

    Failure mode: silent omissions lead to repeated remediation cycles.

Checklist

  • Scope locked (services + reportable events)
  • Customer identity fields complete and normalized
  • Residence + TIN model supports multiple residencies and ISO codes
  • Account/wallet linkage to reportable persons is consistent
  • Asset identifiers and classification standardized
  • Transaction timestamps/type/direction/fees mapped consistently
  • Valuation + FX method documented and repeatable
  • Stable transaction IDs implemented; de-duplication tested
  • Pre-output validation passed (mandatory fields + consistency checks)
  • Reconciliation completed against internal ledgers/statements

How REGREP supports this

REGREP supports CARF/DAC8 readiness by structuring customer and transaction inputs into a consistent reporting model, applying validation checks to reduce common failures (identity, residence/TIN, valuation, duplicates), and supporting traceable transformation into standardized reporting outputs.

Last Reviewed: 2026-02-23

This page provides high-level regulatory reporting information for operational and technical context only and does not constitute legal, tax, or compliance advice.