DAC8 Due Diligence: Self-Certification and User Onboarding Data Changes

DAC8 does not begin at the reporting deadline. It begins at the moment a new user signs up, and most crypto platforms have built their onboarding flow as if it did not exist.

The reporting side of DAC8 gets the attention because it has a visible deadline and a schema attached. The due-diligence side is where the real engineering sits, and it is quieter. Council Directive (EU) 2023/2226 amends the administrative-cooperation directive to insert Article 8ad and Annex VI, and Annex VI Section III puts a specific obligation on the way you take on users: obtain a valid self-certification of tax residence and taxpayer identification number, and test it for reasonableness against what you already know. Those obligations apply from 1 January 2026, the date member states had to give effect to the transposed rules. If your onboarding flow captures an email, a name and a KYC document but no tax residence, every user who signed up before you fixed it is a gap you will be chasing by hand.

What DAC8 actually moves into onboarding

The directive applies to reporting crypto-asset service providers — both CASPs authorised under MiCA and the broader category of crypto-asset operators that are not MiCA-authorised but have reportable EU users. Whichever you are, Section III requires that a new individual or entity user provides a self-certification allowing you to establish their tax residence and TIN, and that you collect this as part of onboarding rather than after the fact. For entity users, you look through to controlling persons where the entity is a passive one, which means the data model has to hold not just the account holder but the natural persons behind it.

This is not the same data you gather for anti-money-laundering purposes, and treating it as such is the first mistake. KYC establishes identity and residential address. DAC8 needs tax residence — which can differ from where someone lives — and a valid TIN for each jurisdiction of residence. The two overlap enough to be confused and differ enough to matter.

Self-certification is a data-capture problem, not a form

The instinct is to add a checkbox and a free-text field and call it done. That produces certifications you cannot report against: TINs in the wrong format, residences that contradict the KYC file, entity accounts with no controlling-person data at all. The reasonableness test in Section III exists precisely to stop you accepting a certification you have good reason to doubt. If the KYC documentation says the user is resident in one jurisdiction and the self-certification claims another, you are expected to notice and resolve it, not record both and move on.

So the capture has to be structured. TIN format validated per jurisdiction. Residence cross-checked against the address and nationality already on file. A flag raised, not silently swallowed, when they disagree. This is where extending the onboarding data model early pays off — the same discipline that keeps a reporting store clean enough to trust is what stops your first DAC8 filing being a reconciliation exercise across half a million malformed records.

Validate at the point of KYC

The rule that saves you work is simple: no user completes onboarding without a valid, reasonable self-certification attached. Validate synchronously, at the point of KYC, so the data is either right on arrival or visibly flagged for follow-up. A minimal shape for that check:

# Onboarding self-certification validation (illustrative)
# Validate tax residence + TIN at KYC, and reasonableness-check
# the certification against identity data already on file.

import re

# TIN format patterns per jurisdiction (extend to your user base;
# these are indicative, not a substitute for the official rules).
TIN_PATTERNS = {
    "IE": r"^\d{7}[A-W]{1,2}$",     # Ireland PPS number
    "DE": r"^\d{11}$",             # Germany IdNr
    "FR": r"^\d{13}$",             # France SPI
    "CY": r"^\d{8}[A-Z]$",         # Cyprus TIC
}

def validate_self_certification(cert, kyc):
    """Return (is_valid, issues) for a user's self-certification.
    cert: {'residences': ['IE'], 'tins': {'IE': '1234567T'}}
    kyc:  {'address_country': 'IE', 'nationality': 'IE',
           'entity': False, 'controlling_persons': []}
    """
    issues = []

    if not cert.get("residences"):
        issues.append("no_tax_residence_declared")

    for jur in cert.get("residences", []):
        tin = cert.get("tins", {}).get(jur)
        pattern = TIN_PATTERNS.get(jur)
        if not tin:
            issues.append(f"missing_tin:{jur}")
        elif pattern and not re.match(pattern, tin):
            issues.append(f"malformed_tin:{jur}")

    # Reasonableness: declared residence should not silently
    # contradict identity data held from KYC (Annex VI, Sec III).
    known = {kyc.get("address_country"), kyc.get("nationality")}
    if cert.get("residences") and not (set(cert["residences"]) & known):
        issues.append("residence_conflicts_with_kyc_review")

    # Entity users: passive entities need controlling-person data.
    if kyc.get("entity") and not kyc.get("controlling_persons"):
        issues.append("entity_missing_controlling_persons")

    return (len(issues) == 0, issues)

The point of the reasonableness branch is not to reject a mismatch outright — dual residence and cross-border lives are legitimate — but to force a human decision and record it, rather than accept a contradiction blind.

The block rule has teeth

DAC8 does not leave enforcement to your good intentions. Where a user fails to provide a valid self-certification, the directive requires you to remind them, and if the certification is still not forthcoming after two reminders and 60 days from the initial request, you must prevent that user from carrying out reportable transactions. That is a hard control, not a nudge. It means your onboarding and account-state logic needs a timer, a reminder sequence and a transaction gate wired together — a user in the unresolved state cannot be allowed to trade as if nothing were pending. Firms that treat self-certification as advisory will find the gate is the part a supervisor asks to see working.

Re-certification triggers and the audit trail

A certification captured once is not captured forever. If a change of circumstances gives you reason to believe the original is unreliable — a new address in a different jurisdiction, a change of controlling person, a corporate restructuring — you are expected to obtain a fresh self-certification. So the onboarding data model has to carry a version history, not a single mutable field: what was certified, when, against which identity data, and what triggered each re-certification.

That history is the audit trail a tax authority will test. When the first reports flow — for the 2026 reporting period, exchanged between authorities in 2027, with the exact national filing date set by your transposing law — the question behind every figure is whether the underlying self-certification was valid and reasonably tested. The reporting engine is downstream of this; it can only be as good as the onboarding data feeding it, which is the same lesson that surfaces whenever anyone runs technology due diligence on a crypto platform and finds the tax data was never structured to be reported. If you have already built the reporting side of DAC8, the due-diligence layer is what keeps it honest.

Retrofit the onboarding flow now and every new user arrives reportable. Leave it, and you are not building a compliance function — you are scheduling a data-cleansing project for the week the first filing is due.