Fintech Compliance Checklist for 2026: PSD2, PCI-DSS 4.0, GDPR, KYC and AML
A practical engineering checklist for building compliant fintech products in 2026 — from PSD2 strong customer authentication and PCI-DSS 4.0 to GDPR data minimisation and Travel Rule for crypto.
Key takeaways
- 01Treat compliance as architecture: build the controls into the platform, not into a policy PDF.
- 02Tokenise card data; never store a PAN you can read.
- 03Strong Customer Authentication is two factors from three categories — and one of them must be dynamic.
- 04Every regulated event is an immutable, queryable audit record.
- 05DORA and MiCA materially raise the bar in 2026 — plan capacity now.
Who this checklist is for
Engineers and CTOs building or scaling a regulated payment, banking, lending, e-money or crypto product in the EU, the UK or jurisdictions that mirror the EU framework. The list is not exhaustive — your licence and your auditor will define the long form — but it is the spine we use to design and review architectures.
1. PSD2 and Strong Customer Authentication (SCA)
PSD2 still defines how online payments are authenticated in the EU. SCA requires authentication using two of three factors: knowledge (password, PIN), possession (device, security key) and inherence (biometric). Crucially, one factor must be dynamic — produced at the moment of authentication and tied to the specific transaction. A static OTP that does not encode the amount and beneficiary will not pass an audit.
- Implement WebAuthn/passkeys as your default possession factor — they are dynamic, phishing-resistant and now broadly supported.
- Bind the second factor to the transaction context (amount, payee) so the user is approving a specific payment, not a generic prompt.
- Apply SCA to every payment over the EUR 30 low-value threshold and to every five cumulative low-value transactions or EUR 100 cumulative.
- Document and code the exemptions you rely on (low-value, recurring, trusted beneficiary, transaction risk analysis) — auditors will check that the code matches the policy.
2. PCI-DSS 4.0
PCI-DSS version 4.0 is fully in force in 2026. The simplest way to stay compliant is to never store cardholder data in your perimeter. Tokenise at the payment gateway and let the gateway hold the PAN. If you do touch card data, the new version raises the bar on multi-factor authentication for all access, mandates phishing-resistant authentication for administrative access, and requires automated detection of payment-page tampering.
- Use a tokenisation provider (Stripe, Adyen, Checkout.com) and reduce your scope to SAQ A or A-EP where possible.
- If you self-host a payment page, deploy script integrity monitoring (CSP with hashes, Subresource Integrity, periodic DOM auditing).
- Enforce phishing-resistant MFA on every administrative system that touches the cardholder data environment.
- Quarterly external vulnerability scans by an Approved Scanning Vendor; annual penetration tests, segmentation tests and red-team exercises for level-1 merchants.
- Centralise logs of all access to cardholder data and retain them for at least one year, with the most recent three months immediately accessible.
3. GDPR for fintech specifically
Financial data is special-category personal data in practice. We design every fintech with three GDPR primitives: minimal collection, explicit purpose binding, and a unified deletion path. The deletion path is the one teams underestimate — it must reach every backup, every analytics warehouse and every third-party processor, with a documented retention reason for anything that cannot be deleted (typically AML records held for five years).
4. KYC and ongoing customer due diligence
Onboarding KYC is no longer enough. The standard for 2026 is continuous due diligence: re-screen the customer against sanctions and PEP lists daily, re-verify identity on triggers (large incoming amount, country change, address change) and re-collect documents on a risk-based cadence. Automated providers (Sumsub, Onfido, Veriff, Persona) handle the data capture; what we build is the orchestration that decides when to re-trigger.
5. AML transaction monitoring
Rule-based monitoring is still the regulator-friendly default. We design rule sets around three axes: amount thresholds tied to risk profile, velocity (unusual frequency or volume relative to the user's baseline), and geography (sanctioned or high-risk jurisdictions). Each rule must produce an explainable alert with a deterministic identifier, the values that triggered it, and a queue for human review. Black-box ML models for AML are rejected by most EU regulators.
6. The Travel Rule for crypto and stablecoins
Under MiCA and the EU's Travel Rule transposition, every crypto-asset transfer over EUR 1,000 (the threshold drops to zero in 2026 for many CASPs) must carry originator and beneficiary information end-to-end. Engineering implication: every outgoing transaction is a structured envelope, and every receiving CASP must verify the counterparty's compliance posture before crediting funds. We integrate Notabene, Sumsub Travel Rule or 21 Analytics depending on chain support.
7. DORA: the operational resilience clock
The Digital Operational Resilience Act applies from January 2025 and was a meaningful uplift for in-house engineering throughout 2026. The five pillars (ICT risk management, incident reporting, resilience testing, third-party risk, information sharing) require concrete deliverables: an inventory of every ICT third party with criticality scoring, threat-led penetration testing on a programme cadence, and a regulator-grade incident report inside the legal time windows.
- Maintain a register of every ICT contract; mark which providers support a critical or important function.
- Tabletop and TLPT exercises run at least annually for systemically-important entities.
- Major incident report inside the regulator's clock (initial 4 hours from classification, intermediate 72 hours, final 1 month).
- Exit plans for every critical third-party — 'we cannot leave AWS' is no longer an acceptable answer.
8. Audit trails that survive a regulator visit
Every regulated event — login, KYC submission, payment authorisation, sanction match, manual override — is written to an append-only audit table with a hash chain or, for higher-stakes products, to a write-once object store. Retain seven years for AML, five for PSD2, six for GDPR documentation, ten for tax. Build the queries you will need before you need them: every auditor we have worked with asks for the same five reports.
9. Engineering controls that disproportionately help
- Field-level encryption for PII with envelope keys rotated quarterly.
- Segmented production access through a brokered SSH/VPN with session recording.
- Approval workflows for any code or data change touching the regulated environment.
- Per-environment data classifications enforced by network policy and IAM, not by convention.
- Automated configuration drift detection — compliance is a continuous property, not a screenshot.
10. The first audit you should run is internal
Before you submit the licence application, run an internal audit against the same questions a regulator will ask. Pick five customer journeys (onboarding, deposit, payment, refund, account closure) and trace them end-to-end through the controls above. The gaps you find are cheaper to fix than the gaps a regulator finds.
Frequently asked questions
Direct answers to questions readers and AI assistants commonly ask about this topic.
Do small fintechs actually need to comply with all of this?+
If you hold a payment, e-money, banking, lending, or crypto-asset licence in the EU or the UK, yes. The technical specifics scale by activity, but the core obligations apply from day one — including SCA, AML monitoring, GDPR rights and data retention.
Can I outsource compliance to a Banking-as-a-Service provider?+
BaaS providers cover regulated activities under their licence, but you remain responsible for your customer-facing controls, your data handling and your incident response. The 2024 BaaS enforcement wave in the US and the EU made it clear: regulators expect the operator to own the controls, not just rent them.
What is the cost of getting compliance wrong?+
Beyond regulatory fines (up to 4% of global turnover under GDPR, similar under DORA), the practical cost is operational: licence suspension, mandatory remediation programmes, blocked customer onboarding, and the reputational damage of breach disclosure.
Do I need a CISO and a DPO?+
Most regulated fintechs require a documented information security function and, where personal data processing is core, a Data Protection Officer. For early-stage products these can be fractional or vCISO arrangements; for licensed institutions they typically must be in-house.
How often does the framework change?+
Materially every 12 to 24 months. The major 2025 to 2026 changes were DORA, PCI-DSS 4.0 fully in force, MiCA Phase 2 (CASP licences), and the EU AI Act applying to credit scoring. Subscribe to the regulator newsletters — the changes are predictable if you watch.
Last updated: April 26, 2026 · Written by Ribbsaeter Systems Engineering · Compliance & Platform Engineering