KYC for Fintech: the Minimum Compliance Stack for Remote Onboarding under AMLD5 and EBA Guidelines
A European fintech today onboards almost every customer remotely. No branch, no counter, no handshake: the relationship begins with a face on a screen and a document photographed by a phone. That model is what makes the product scalable, and it is also where two internal teams quietly pull in opposite directions. The product team wants the shortest possible path from download to first transaction, because every extra step costs conversion. Compliance wants the opposite: enough friction, and enough evidence, to survive an AML inspection. The first MVP usually ships with the product team winning. The gaps that got deferred then resurface later as fines, remediation projects and frozen accounts.
So the real question for a CTO or compliance officer building this is narrow and practical: what is the minimum KYC for fintech onboarding stack that satisfies AMLD5 and the EBA Guidelines without killing conversion? Digital KYC fintech onboarding is not one product you buy. It is a stack of five distinct components, each producing a specific output, and most early compliance problems come from collapsing them into a single vendor or skipping one entirely. This guide maps the five components, says who typically provides each, and shows what breaks when one is missing.
Why remote customer due diligence is the critical point for a fintech
Remote customer due diligence is the critical point because it is the moment a fintech accepts legal responsibility for knowing who its customer is, with no physical contact to fall back on. Everything downstream (the account, the card, the transfers) inherits whatever was verified, or not verified, in those first two minutes. A weak onboarding does not just let in one bad actor: it creates a structural liability that an auditor or a court can examine years later.
This pressure is not abstract. Regulators have concentrated their attention on remote onboarding precisely because it is where fraudsters have concentrated theirs. A fintech that treats KYC verification as a UX problem to be minimized, rather than a compliance and evidence problem to be solved, is building on a fault line.
The regulatory layers: AML directives, the single rulebook and EBA guidelines
European AML obligations now sit in three layers, and a fintech needs to satisfy all of them. The base layer is the Fifth Anti-Money Laundering Directive, Directive (EU) 2018/843 (AMLD5), which explicitly legitimized electronic and remote identification for customer due diligence, including identification through eIDAS-based electronic identification means. AMLD5 is what made fully remote onboarding legally viable in the first place.
The second layer is the 2024 AML package, which moves the core rules from directives into a directly applicable regulation. The Anti-Money Laundering Regulation, Regulation (EU) 2024/1624 (AMLR), becomes the single rulebook applicable from 10 July 2027, and among other changes it lowers the threshold for occasional-transaction CDD from EUR 15,000 to EUR 10,000. The new Anti-Money Laundering Authority (AMLA), based in Frankfurt, has been operational since 1 July 2025 and will drive supervisory convergence across the bloc.
The third layer is the supervisory detail. The EBA Guidelines on the use of remote customer onboarding solutions (EBA/GL/2022/15), applicable since 2 October 2023, set out what a compliant remote onboarding process should actually contain: how to capture and assess the customer's identity, how to ensure the document and the person match, and how to record the whole process so it can be reviewed. For a fintech, these guidelines are the closest thing to a checklist of what the KYC process must demonstrably do.
The cost of gaps: fines and synthetic identity fraud
The cost of getting this wrong has two faces: enforcement and fraud, and they reinforce each other. On enforcement, the numbers are no longer theoretical. Starling Bank was fined GBP 28.96m by the UK's Financial Conduct Authority in 2024 for financial crime control failings tied to its rapid growth, and according to industry analysis, global AML fines reached roughly USD 3.8bn in 2025. Most of these penalties trace back to controls that were too weak for the volume and speed at which the institution was onboarding.
On the fraud side, the attack surface of remote onboarding is widening fast. According to industry reports, deepfakes accounted for around 7% of fraud attempts in 2024 and are trending toward roughly 11% by early 2026, while synthetic identity fraud, which stitches real and fabricated data into a plausible new person, has become the largest first-party fraud category at around 21%. The FATF Horizon Scan published in December 2025 explicitly recognizes deepfakes as a tool used to bypass customer due diligence controls. None of this means a fintech needs to chase the latest forgery technique. It means the onboarding process has to verify presence and identity robustly, then preserve proof of exactly what was captured and when.
The minimum KYC compliance stack in five components
The minimum compliant stack has five components: (1) document recognition with OCR and liveness verification, (2) PEP and sanctions screening, (3) digital identity through eID schemes and the EUDI Wallet, (4) verbalized archiving with hash, timestamp and chain of custody, and (5) transaction monitoring with traceable alerts. Each one answers a different regulatory expectation, produces a different output, and usually comes from a different type of vendor. Treating them as one undifferentiated "KYC solution" is the most common way compliance gaps slip through.
The table below sets out the five components: their function, the concrete output each must produce, who typically provides it, and what is at risk if a fintech leaves it out.
| Component | Function | Key output | Who typically provides it | Risk if missing |
|---|---|---|---|---|
| 1. Document recognition (OCR + liveness) | Read the ID and confirm a live, present human | Extracted data fields plus a liveness/match result | Identity verification vendors (IDV) | Forged or stolen documents pass; presentation attacks succeed |
| 2. PEP and sanctions screening | Check the customer against watchlists and PEP databases | Screening hit/clear result with match details | Screening and AML data providers | Onboarding a sanctioned party or an unscreened PEP; direct regulatory breach |
| 3. Digital identity (eID, EUDI Wallet) | Verify identity via recognized electronic identification | Authenticated identity assertion | eID schemes, wallet providers | Reliance on weaker self-asserted data; missed simplification opportunity |
| 4. Verbalized archiving (hash, timestamp, chain of custody) | Certify and preserve what was captured, with evidential value | Hash and timestamp per session, traceable record | Data authenticity / forensic certification platforms (via API) | No defensible proof of integrity if onboarding is later challenged |
| 5. Transaction monitoring | Detect suspicious activity after onboarding | Risk-scored alerts and case records | Transaction monitoring vendors | Ongoing-monitoring obligation unmet; suspicious flows go unreported |
1. Document recognition: OCR and liveness verification
Document recognition is the entry point of KYC verification: it reads the identity document and confirms that a real, living person is presenting it in real time. OCR extracts the structured data (name, document number, date of birth, expiry) from a photographed ID and checks document features for tampering. On its own, OCR proves nothing about who is holding the document, which is why liveness detection sits next to it.
Liveness detection, more precisely Presentation Attack Detection, distinguishes a genuine live face from a photo, a video replay, a mask or a synthetic rendering. The reference standard here is ISO/IEC 30107-3, which defines how to measure presentation attack detection performance through metrics such as APCER and BPCER, with independent accredited testing as the credibility benchmark. The practical takeaway for a fintech: ask vendors for evidence of independent testing against this standard, rather than accepting "liveness" as a marketing label. This component is what stands between your onboarding and the synthetic-identity and deepfake attacks described above.
2. PEP and sanctions screening
Sanctions and PEP screening checks every applicant against the relevant watchlists before the relationship opens, and then continues to check throughout its life. At minimum this means screening against the EU Consolidated Sanctions List and, where the fintech has US exposure, the OFAC Specially Designated Nationals (SDN) list. A hit against a sanctions list is not a risk score to weigh: it is a hard stop.
Politically Exposed Persons sit in a different category. A PEP is not prohibited, but a PEP relationship triggers Enhanced Due Diligence: senior-management sign-off, establishing the source of funds and wealth, and closer ongoing monitoring. So screening is not a one-time gate at onboarding but a recurring obligation, because lists change and a clean customer today can become a sanctioned or politically exposed one tomorrow. Under-scoping this component is among the most direct ways to commit a regulatory breach, since onboarding a sanctioned party is a violation regardless of intent.
3. Digital identity: eID schemes and the EUDI Wallet
Digital identity lets a fintech verify a customer through recognized electronic identification rather than relying on documents and selfies alone. AMLD5 already permits the use of eIDAS-based electronic identification means for customer due diligence, which gives this route explicit legal standing. National eID schemes across member states provide one path; the framework is now being unified and upgraded.
The change to plan for is eIDAS 2.0, Regulation (EU) 2024/1183, in force since 20 May 2024, and the European Digital Identity (EUDI) Wallet it introduces. Every member state must offer citizens a wallet by the end of 2026. For onboarding, the EUDI Wallet promises a high-assurance identity that a customer can present once and reuse, which compresses the verification step and lifts conversion at the same time. A fintech building its stack today should design component 1 so that a wallet-based identity can slot in as an alternative path rather than a rebuild, because the customers arriving in 2027 will increasingly expect it.
4. Verbalized archiving: hash, timestamp and chain of custody
Verbalized archiving is the component that turns a completed onboarding into defensible evidence. The first three components verify the customer; this one preserves proof of what was verified, exactly as it was, at a precise moment. Without it, a fintech can perform flawless verification and still be unable to demonstrate, months or years later, that the captured data has not been altered and that it was acquired when the records claim.
The relevant reference is ISO/IEC 27037, the international standard for the identification, collection, acquisition and preservation of digital evidence, which formalizes the concept of chain of custody. Applied to onboarding, it means each session should be captured, fixed with a cryptographic hash, stamped with a trusted time reference, and kept in a way that leaves that integrity verifiable and traceable. This is the difference between having records and having an audit trail that holds up under challenge. It is also the component most often missing from a first MVP, because it produces nothing the customer sees and nothing the product team asked for.
5. Transaction monitoring with traceable alerts
Transaction monitoring extends due diligence beyond onboarding into the entire customer lifecycle. AML obligations do not end when the account opens: the fintech must watch transactions for patterns that suggest money laundering or fraud, generate alerts, investigate them, and report where required. A clean onboarding followed by no monitoring leaves the largest part of the obligation unmet.
What matters here is not just the alert but its traceability: each alert should carry the data that triggered it and the record of how it was handled, so the institution can show a supervisor a coherent, reviewable history. This connects back to component 4. Monitoring produces evidence continuously, and that evidence is only as defensible as the integrity controls wrapped around it. A fintech that can produce alerts but cannot prove when they were raised, or that their underlying data is intact, has monitoring in name only.
How is onboarding data certified with evidential value?
Onboarding data is certified with evidential value by capturing the acquisition with a forensic method, sealing it cryptographically, and binding it to a trusted timestamp, so that the record's integrity and exact moment of acquisition can be proven later. This is the role TrueScreen plays as component 4 of the stack. TrueScreen is a Data Authenticity Platform: it does not perform OCR, liveness, screening or identity verification, and it is not a trust service provider that issues certificates. It certifies and verbalizes the onboarding acquisition through an API, applying a timestamp and an electronic seal through qualified trust service providers integrated via API, and returns a hash and timestamp for each session. The acquisition is performed with a forensic method and retained in a traceable way aligned with the principles of ISO/IEC 27037, giving the record evidential value. Consider a fintech facing a dispute over a remote onboarding: the customer claims they never opened the account. With TrueScreen, the fintech can demonstrate the integrity of the captured data and the exact moment of acquisition, turning a contested record into defensible proof.
What TrueScreen certifies, and what it does not
TrueScreen sits downstream of the identity-verification layer and integrates with it via API. The identity vendor confirms who the person is; TrueScreen certifies that the resulting record was captured at a specific time and has not been altered since. The two are complementary, not competing. The separation matters in practice. An IDV vendor's job is to maximize the accuracy of the match. The certification layer's job is to make the captured session independently verifiable, even by a third party who trusts neither the fintech nor the vendor. Keeping certification distinct means a fintech avoids asking a single verification tool to also vouch for its own evidence, which is exactly the kind of circular dependency a court or auditor will discount.
How to compose the stack by fintech growth stage
A fintech does not need all five components at full depth on day one, but it does need a plan for all five, sequenced to its growth stage and risk exposure. The right composition at seed stage is different from what a regulated scale-up requires. The most expensive mistake is building so that adding a later component means re-architecting the earlier ones.
At seed stage, with limited volume and often a single jurisdiction, a fintech typically starts with components 1 and 2 (document recognition with liveness, plus sanctions and PEP screening) because these are the non-negotiable gates that keep obviously bad actors out and prevent the most direct regulatory breaches. Even here, component 4 should be designed in, even if lightly, so the onboarding evidence exists from the first customer rather than being reconstructed later.
At scale-up stage, volume and cross-border activity make the gaps expensive. Transaction monitoring (component 5) becomes essential as transaction count grows, ongoing screening must be automated rather than periodic, and the audit trail from component 4 becomes the thing that lets the compliance team answer a supervisor quickly instead of scrambling. This is also the stage where designing for the EUDI Wallet (component 3) starts to pay off in conversion.
At the regulated stage, holding a payment or e-money authorization, all five components must operate at audit-grade depth, with documented processes, independent testing evidence for liveness, and a defensible chain of custody for every onboarding and every alert.
Unlike a single-vendor suite that bundles these functions and asks you to trust one provider's word for the whole chain, a layered stack keeps each function independently verifiable and replaceable. If a screening provider's data proves weak, you swap it without touching your evidence layer. If your IDV vendor changes, your historical onboarding records stay provable, because their integrity was certified by a separate component. The layered approach costs more coordination up front. What it buys is resilience, supervisory credibility, and the freedom to upgrade any single component as the regulatory baseline keeps rising.
