EU merchants adding crypto rails face a two-sided challenge: scale payments while staying audit-ready. With DORA (Digital Operational Resilience Act) reshaping incident preparedness and AML rules tightening around wallet screening and monitoring, you need a compliance posture that’s practical, consistent, and visible to auditors. This guide is a pragmatic blueprint to meet expectations without wrecking your checkout UX.
The compliance pillars
- KYT (Know Your Transaction) & wallet screening
- Transaction monitoring & case management
- Data retention, access control, and auditability
- Operational resilience (DORA): incident response, testing, vendor oversight
KYT & wallet screening: stop risk before it starts
Screen inbound addresses against sanctions and risk lists pre-authorization:
- Policy thresholds: Block, allow, or review depending on risk score and ticket size.
- Lists & oracles: Use reputable providers; document your selection and update cadence.
- Edge cases: Over-/under-payments, expired quotes—ensure the flow re-screens when funds actually land.
Best practice: Keep policy controls in config, not code. As rules evolve, you can update without redeploying.
Transaction monitoring: from flags to cases
Monitoring must be continuous and explainable:
- Rules & scenarios: Rapid repeats, structuring, velocity spikes, suspicious geographies.
- Case creation: Auto-escalate to manual review with all context (order, tx hash, wallet history).
- Resolution paths: Approve, deny, refund; capture rationale for audits.
- Metrics: Time to decision, false-positive rate, and reviewer workload.
Refunds, reversals, and proof
No card chargebacks means you need clear refund SOPs:
- Re-verify refund wallet ownership (signed message, one-time code).
- Stablecoin refunds standardize value and accounting.
- Link evidence: Order, original tx, risk checks, reviewer notes, refund tx.
Auditors will ask for traceability. Build it into your ledger.
DORA: operational resilience for payments
DORA expects resilience across incident prevention, detection, response, and recovery:
- Playbooks: Document severity thresholds, comms plans, and recovery steps.
- Testing: Run periodic tabletop exercises on payment outage, provider downtime, chain congestion.
- Vendor management: Assess gateway partners, uptime SLAs, status pages, and breach notification timelines.
- Post-incident learning: Keep a register of incidents and mitigations.
Data governance & privacy
- Retention: Define how long you keep transaction and risk logs.
- Access control: Role-based access (RBAC), SSO, and audit logs for sensitive actions.
- Data locality: Know where data is stored and under what lawful basis.
Making compliance invisible (to customers)
- Screen behind the scenes; don’t push KYC on low-risk, low-value orders.
- Localize the checkout and refunds pages; keep messages simple (“Your payment window expired—get a new quote”).
- Provide self-serve refund status to cut support load.
Team and tooling
- Compliance owner: Defines policies, signs off on changes.
- Payments ops: Executes reviews, monitors queues, tunes rules.
- Engineering: Integrates KYT hooks, webhooks, and export pipelines.
- Auditor package: Export templates, policy docs, vendor attestations.
Quick-start compliance checklist
- KYT pre-auth + continuous monitoring enabled
- Risk thresholds documented and reviewed quarterly
- Refund SOP with re-verification
- DORA incident playbooks + test schedule
- RBAC/SSO and audit logs in place
- Exportable, immutable transaction records
FAQs
Do we need KYC for buyers?
Often not for low-risk, low-value orders. Use risk-based controls and escalate only when thresholds trigger.
What will auditors want to see?
Policies, evidence that they’re enforced (logs), and traceable transactions from order to settlement.
How do we handle sanctioned hits?
Block, record, and retain; follow your escalation policy and local obligations.
