KYC software development: how do you build a compliant and fast KYC process in 2026?

The head of compliance at a growing European payments company receives two reports on the same Monday. The first comes from growth: 40% of people who start opening an account never finish, and most of them drop out at the identity check. The second comes from the internal audit: the sanctions screening engine generated so many alerts in the last quarter that the team closed some of them without a proper review. The CTO has a third problem: the KYC vendor’s contract expires in six months, and the board wants to know whether it is time to build their own system.

These three problems are really one. A KYC process that is too strict loses customers; one that is too loose loses licences. Between the two sits software — and its architecture decides whether the company can grow without hiring an analyst for every thousand new customers.

2026 and 2027 are a particularly important moment to rethink it. The EU AML Regulation applies from 10 July 2027, banks must accept the EU Digital Identity Wallet by 24 December 2027, and generative AI has made forged documents and deepfake selfies cheap. Below we describe what a modern KYC system consists of, which regulations shape it, how much it costs to build or buy, and which metrics show that it works. This article is not legal advice — the interpretation of obligations for your institution belongs to your compliance and legal teams.

What is KYC and how do CIP, CDD and EDD differ?

KYC (know your customer) is the umbrella term for everything a financial institution does to know who it is dealing with and whether the relationship is legitimate. In regulations, KYC is broken down into more precise obligations, and the software you build has to map onto them.

• Customer identification — collecting identity data (name, date of birth, address, identity document number) and verifying it against reliable sources. In the United States, this is the Customer Identification Program (CIP) required by Section 326 of the USA PATRIOT Act.
• Customer due diligence (CDD) — the standard set of measures: identification and verification, identifying beneficial owners of legal entities, understanding the purpose and intended nature of the relationship, and ongoing monitoring.
• Enhanced due diligence (EDD) — stricter measures for higher-risk customers: politically exposed persons (PEPs), customers linked to high-risk third countries, complex ownership structures or unusual transactions. EDD typically means additional documents, a source-of-funds check and senior management approval.
• Simplified due diligence (SDD) — reduced measures for demonstrably low-risk situations, allowed only where the risk assessment justifies it.

For a software team, the key conclusion is that KYC is not a single check at onboarding. It is a lifecycle: identification at the start, risk classification, periodic reviews, event-driven updates and monitoring of behaviour. A system designed only for the first step becomes a bottleneck at every subsequent one.

KYC is also only part of a wider anti-money laundering (AML) and counter-terrorist financing (CTF) programme. Transaction monitoring, suspicious activity reporting and sanctions compliance all consume the data that KYC collects. If that data is incomplete or inconsistent, the rest of the programme works blind — as we will see in the case of one of the largest AML penalties in history.

Which regulations shape KYC systems in 2026 and 2027?

The regulatory landscape for KYC in Europe is changing more in these two years than in the previous decade. Four sets of rules matter most for software design.

The EU AML package. In 2024 the EU adopted Regulation (EU) 2024/1624 (AMLR), the directly applicable “single rulebook”, which applies from 10 July 2027. It replaces differing national implementations with one set of requirements. The accompanying directive (EU) 2024/1640 (AMLD6) must be transposed by the same date. The new Anti-Money Laundering Authority (AMLA), based in Frankfurt, started operations on 1 July 2025 and from 2028 will directly supervise about 40 large, high-risk financial institutions across the EU.

Several AMLR provisions translate directly into system requirements:

• Periodic review cycles — customer data must be updated at least annually for high-risk customers and at least every five years for others. The system must schedule reviews, not wait for a customer to show up.
• Beneficial ownership — the threshold is now “25% or more” of shares or voting rights, instead of “more than 25%”. A data model that stores ownership as a boolean flag will not survive this change.
• A cash payment limit of EUR 10,000 across the EU, with lower national limits still applying where they exist.

National law. In Poland, the Act of 1 March 2018 on counteracting money laundering and terrorist financing has been in force since 13 July 2018. Administrative penalties for legal entities can reach the equivalent of EUR 5 million or 10% of turnover, or up to twice the benefit obtained where it can be established. Until July 2027 national acts like this remain the primary source of obligations; afterwards they will be adapted to the AMLR.

eIDAS 2.0. Regulation (EU) 2024/1183 entered into force on 20 May 2024. By 24 December 2026, every Member State must provide at least one certified EU Digital Identity Wallet, and by 24 December 2027, regulated private-sector entities — including banks — must accept it. For KYC this is a fundamental shift: identity data can arrive as verified, cryptographically signed attributes instead of a photo of a document.

United States. FinCEN’s Customer Due Diligence Rule, issued on 11 May 2016 with a compliance date of 11 May 2018, requires covered financial institutions to identify and verify beneficial owners of legal entity customers, on top of the CIP requirements. Companies serving US customers need a data model that handles both regimes.

A fifth regulation affects the biometric part of KYC: the EU AI Act. Annex III lists remote biometric identification as high-risk, but explicitly excludes AI systems used for biometric verification whose sole purpose is to confirm that a person is who they claim to be. A standard selfie-to-document match therefore does not automatically become a high-risk AI system — but the data it processes remains special-category data under the GDPR.

What does the architecture of a modern KYC system look like?

A mature KYC system is not one application but a set of cooperating components around a shared customer profile. In the projects we see, the architecture that scales best separates what is checked from how the result is decided.

Component	What it does	Typical implementation
Onboarding front end	Collects data and documents, guides the customer, handles drop-offs and resumption	Own web and mobile app
Orchestration and workflow	Decides which checks to run, in what order, with what fallbacks	Own service or workflow engine
Document verification	Reads the document (OCR, MRZ, NFC chip), checks security features	Specialised vendor
Biometrics and liveness	Matches selfie to document photo, detects presentation and injection attacks	Specialised vendor
Sanctions and PEP screening	Matches names against sanctions lists, PEP and adverse media databases	Data vendor plus own matching and tuning
Beneficial ownership	Retrieves company registry data, builds the ownership graph	Registry APIs plus own logic
Risk scoring	Classifies the customer (low, medium, high) using explainable rules	Own rules engine
Case management	Queues alerts and manual reviews, records decisions and justifications	Own or vendor tool
Ongoing monitoring	Re-screens the customer base, triggers reviews on events and deadlines	Own scheduler plus vendor data
Audit and evidence store	Keeps an immutable record of every check, input, version and decision	Own, append-only storage

Three design principles matter more than the choice of individual components.

The customer profile is the single source of truth. Every check writes its result to one profile with a clear history. When a regulator asks why a customer was classified as low risk three years ago, the system must reproduce the data, rules and versions used at that moment.

Orchestration is configurable. Different products, countries and risk levels require different paths: a low-risk retail customer may complete onboarding with a document and liveness check, while a company with a complex structure needs a registry check, ownership analysis and a human review. If these paths are hard-coded, every regulatory change becomes a development project. As in our article on BPMN 2.0 in practice, modelling the process explicitly before building it saves weeks of rework.

Vendors are replaceable. Document verification, biometrics and screening data are commodities that change price and quality. An abstraction layer between orchestration and vendors lets you switch or combine providers without rewriting the process — and gives you negotiating power at contract renewal.

How do document verification, biometrics and liveness detection work, and where do they fail?

The identity verification step is where most customers experience KYC and where most fraud attempts happen. It usually consists of three checks.

Document verification reads the identity document — through OCR and the machine-readable zone (MRZ) or, increasingly, the NFC chip in passports and ID cards — and checks whether the document is genuine: security features, fonts, layout, consistency of data between fields. Reading the chip is the strongest method, because its data is signed by the issuing state and cannot be altered without breaking the signature.

Face matching compares a selfie with the photo in the document or chip. Liveness detection checks that the selfie comes from a live person in front of the camera, not a printed photo, a screen replay, a mask or a synthetic video.

The threat landscape here has changed rapidly. According to Entrust’s 2025 Identity Fraud Report, based on data from September 2023 to August 2024, a deepfake attempt occurred every five minutes, digital document forgeries rose by 244% year on year and, for the first time, digital forgeries (57%) overtook physical counterfeits. The 2026 edition shows that deepfakes account for one in five biometric fraud attempts, deepfake selfies rose by 58% in 2025 and injection attacks grew by 40% year on year.

Injection attacks deserve particular attention in design. Instead of holding a fake in front of the camera, the attacker feeds a manipulated video stream directly into the application — through a virtual camera, an emulator or a modified app. Liveness detection that only analyses the image will not catch it. Defence requires device and session integrity checks, detection of virtual cameras and emulators, and certified presentation attack detection tested according to ISO/IEC 30107-3.

Practical conclusions for the software team:

• Prefer the chip over the photo wherever the document and device allow NFC reading.
• Treat liveness as a security control, not a UX feature. Ask vendors for independent test results against both presentation and injection attacks.
• Design fallbacks. Some customers will fail automated checks for legitimate reasons — poor lighting, an old document, a disability. The system needs a path to manual review or video identification that does not force them to start from scratch.
• Record everything needed for evidence. Store the result, confidence scores, vendor and model versions — while keeping raw biometric data only as long as strictly necessary.

How should sanctions and PEP screening be built to avoid drowning in false positives?

Sanctions and PEP screening compares each customer — and their beneficial owners — against lists such as the EU consolidated sanctions list, the US OFAC Specially Designated Nationals list, UN lists and commercial databases of politically exposed persons and adverse media. The regulatory requirement is simple; the engineering problem is not.

Names are ambiguous. The same person can appear with different transliterations, diacritics, word orders and spellings; common names generate matches with hundreds of innocent people. Screening engines therefore use fuzzy matching, and fuzzy matching produces false positives — alerts that analysts must review and close. Every alert costs analyst time, and the audit finding from our introduction, alerts closed without proper review, is a typical result of an untuned system.

The approach that works combines four elements:

1. Better input data. Matching on name plus date of birth, nationality and identifiers dramatically narrows the candidate set compared with name-only matching. This is a data-model decision made at onboarding, not a screening setting.
2. Name-aware matching. Transliteration rules for Cyrillic, Arabic and Asian scripts, handling of diacritics and name order, and different thresholds for different list types.
3. Measured tuning. Match thresholds should be changed on the basis of a test set with known true and false matches, and every change documented — a regulator will ask why the threshold is where it is.
4. Structured case management. Analysts need the matched record, the reasons for the match and the customer’s data side by side, plus mandatory justification fields. That turns closing an alert into an auditable decision.

Screening also has to run continuously, not once. Sanctions lists change without notice, and a customer who was clean at onboarding may be designated tomorrow. The system must re-screen the whole customer base against list updates and route new matches into the same case management process.

How do risk scoring and ongoing monitoring turn KYC into perpetual KYC?

Traditional KYC was periodic: identify the customer, file the documents and review them every few years. Perpetual KYC (pKYC) replaces fixed cycles with continuous updates triggered by events — while keeping the minimum review deadlines the law requires.

The core of this approach is risk scoring. Each customer receives a risk level based on factors such as customer type, country, product, delivery channel, PEP status, ownership structure and expected activity. For supervised institutions, the scoring model must be explainable: you need to be able to show which factors produced a given score. That is why many institutions use transparent rules or scorecards, sometimes supplemented by machine learning models for specific signals, rather than a black-box score.

Risk scoring drives the rest of the process:

• The review cycle — at least annually for high-risk customers and at least every five years for others under the AMLR.
• Event-driven reviews — a change of address or ownership, a new sanctions match, adverse media, or activity inconsistent with the declared profile.
• The level of scrutiny — which transactions trigger alerts and which products are available.

The cost of neglecting ongoing monitoring became visible in October 2024. TD Bank pleaded guilty in the United States to Bank Secrecy Act violations and conspiracy to commit money laundering, agreeing to pay approximately USD 3.09 billion in penalties across the Department of Justice, the Federal Reserve, the OCC and FinCEN. The plea agreement pointed to a failure to substantively update the transaction monitoring programme from at least 2014 to 2022 and to monitor trillions of dollars of transactions. The OCC also imposed an asset cap. Technology was not the only failure, but a monitoring system that was not updated for years was at the centre of it.

Build or buy: when does it pay to develop your own KYC software?

The build-versus-buy decision for KYC is rarely all or nothing. Almost no one should build document verification or liveness detection from scratch — that requires specialised machine-learning teams, large training datasets and certification testing. The real question is how much of the rest you own: orchestration, risk scoring, case management, monitoring and the audit trail.

To make the trade-off concrete, we modelled two options for a fintech onboarding 10,000 new customers a month (120,000 a year), with the active customer base growing from an average of 60,000 in year one to 300,000 in year three. Vendor prices are assumptions for illustration — replace them with the quotes you receive. Team rates are midpoints from our body leasing rate benchmark for 2026 (for example PLN 220 an hour for a senior backend developer), at 145 billable hours per person-month and 4.30 PLN per EUR.

• Option A — buy a KYC platform. Assumed EUR 2.50 per onboarding (documents, liveness and screening), EUR 0.30 per customer per year for ongoing monitoring and a EUR 30,000 annual platform fee. Integration by two backend developers, a QA engineer and a quarter of an architect for three months; then half a backend developer and a quarter of a QA engineer to run it.
• Option B — build the core, buy components. Assumed EUR 1.50 per document and liveness check, EUR 0.05 per screening and a EUR 40,000 annual screening data subscription. Nine months of building by a team of three backend developers, a frontend developer, a QA engineer, a DevOps engineer, a compliance analyst, half an architect and half a data scientist; then a run team of 2.5 people.

Three-year cost (PLN)	Option A: buy platform	Option B: build core
Initial build or integration	298,375	2,298,030
Year 1 total	2,057,345	4,189,790
Year 2 total	1,913,770	1,917,560
Year 3 total	2,068,570	1,943,360
Three-year total	6,039,685	8,050,710
Cost per onboarding over three years	16.78	22.36

At this volume, buying is cheaper by about PLN 2 million over three years. By year three, however, the annual cost of option B is already lower, because vendor fees in option A grow with the customer base. Scaling both options proportionally, they break even at roughly 20,000 onboardings a month. Below that, a platform usually wins on cost; above it, owning the core starts to pay off.

Cost is not the only criterion. Building the core makes sense when KYC is a competitive differentiator (for example, onboarding speed in a crowded market), when you operate in many jurisdictions with different rules, when you need full control over audit evidence, or when vendor lock-in is a strategic risk. Buying makes sense when time to market is critical, the team has no compliance engineering experience, or volumes are modest. The general framework is described in our article on build versus buy decisions for software.

Which metrics show that a KYC process works?

A KYC process has two customers: the person opening an account and the regulator. Metrics must cover both, otherwise optimising one side silently damages the other.

Conversion and experience:

• Onboarding completion rate — the share of started applications that finish. Signicat’s “Battle to Onboard” survey of 7,600 European consumers found that 68% had abandoned a financial application at some point, up from 63% in 2020; the main reasons were time to apply, the amount of personal information required and changing their mind (21% each).
• Time to onboard — median and 90th percentile, from the first screen to an active account.
• Straight-through processing rate — the share of customers onboarded without manual review.
• Drop-off by step — which screen or check loses the most customers.

Risk and compliance:

• False positive rate in screening — the share of alerts closed as not relevant, measured per list and per rule.
• Alert handling time and backlog — how long alerts wait and how many exceed internal deadlines.
• Review cycle compliance — the share of customers whose periodic review is overdue.
• Fraud caught and missed — confirmed fraud detected at onboarding versus discovered later.
• Audit findings — number and severity of findings related to KYC.

The value of improving conversion is easy to estimate. If 10,000 people start an application each month and the completion rate rises from 60% to 65%, that is 500 more customers a month without any additional marketing spend — while the same changes must not increase fraud losses or review backlogs.

How do you protect personal data and meet GDPR requirements in a KYC system?

A KYC system processes some of the most sensitive data a company holds: identity documents, biometric templates, addresses, sometimes information on political exposure or source of funds. AML law requires the institution to collect and keep it; the GDPR requires it to minimise and protect it. The architecture has to satisfy both.

Biometric data used to uniquely identify a person is special-category data under Article 9 of the GDPR. Processing it requires a legal basis, and a data protection impact assessment (DPIA) is practically unavoidable for a system that combines large-scale identity verification with biometrics. In practice:

• Separate retention rules by data type. AML rules require records to be kept for a defined period after the end of the relationship; raw selfie videos and images used only for liveness checks usually do not need to be kept that long. Store the result and evidence, delete the raw material as soon as the purpose is achieved.
• Encrypt and segment. Identity documents and biometric data belong in separate, encrypted storage with narrow access and full access logging.
• Control vendor data flows. Check where your vendors process data, whether they use it to train their models and what happens to it when the contract ends.
• Design for data subject rights. The system must be able to show the customer what data it holds and why, while respecting AML restrictions on disclosing suspicions.

Security of the KYC system itself is part of compliance. An identity database is an attractive target, so the practices described in our article on DevSecOps in 2026 — threat modelling, dependency scanning, secret management, penetration testing — apply here with particular force.

What does the EU Digital Identity Wallet change for onboarding from 2027?

The EU Digital Identity Wallet may change KYC more than any other technology since video identification. Instead of photographing a document and proving liveness, a customer will be able to share verified identity attributes — name, date of birth, nationality, address — issued by the state and cryptographically signed.

For KYC systems, this has three consequences.

A new onboarding channel, not a replacement. From 24 December 2027, banks and other regulated entities must accept the wallet, but not every customer will have one, and customers from outside the EU will still need document-based verification. The system must support both paths and treat the wallet as one of several identification methods in the orchestration layer.

Higher assurance, fewer forgery risks. Signed attributes cannot be edited like an image of a document, which reduces exposure to digital forgeries and deepfakes at the identification step. Risk shifts to other areas: account takeover, social engineering and misuse of genuine identities.

Integration work that starts now. Accepting the wallet requires support for the technical standards defined in the implementing acts adopted from November 2024, registration as a relying party, and changes to consent and data-handling flows. Institutions that start in 2027 will be implementing under deadline pressure.

The European context is broader than the wallet: open banking and digital finance regulation are reshaping the whole sector, as we describe in our guide to digital transformation in finance.

What team do you need to build and run a KYC platform?

A KYC platform sits at the intersection of software engineering, security, data and regulation. Teams that treat it as a standard web project usually discover the missing competencies during the first audit.

A typical team for building the core (option B above) includes:

• Backend developers with experience of workflow systems, integrations and data consistency — the orchestration and audit trail are only as reliable as their design.
• A frontend or mobile developer focused on the onboarding flow, since that is where conversion is won or lost.
• A compliance analyst who translates regulations and internal policies into rules, risk factors and test cases. This role is most often missing, and its absence shows up as rules that nobody can explain.
• A QA engineer with test automation skills, working with realistic test data: edge-case names, documents from many countries, ownership structures.
• A DevOps engineer responsible for environments, monitoring, secrets and the ability to deploy regulatory changes quickly and safely.
• An architect — part-time is often enough — for vendor abstraction, data model and security.
• A data scientist — also part-time — to calibrate risk scoring and screening thresholds and measure their effect.

Such profiles are scarce, especially people who combine engineering with AML experience. That is why many institutions combine a small in-house core team, which owns the rules and the relationship with the regulator, with external specialists brought in for the build phase and peaks in regulatory change. We describe how this works in banking and fintech in our glossary entry on body leasing in the financial sector.

How do you plan a KYC system roadmap before 2027?

With the AMLR applying from July 2027 and wallet acceptance required by December 2027, the next twelve to eighteen months are the window for planned change rather than emergency projects. The maturity model below helps assess where your KYC system is today and what the next step should be:

Area	Level 1: manual	Level 2: automated	Level 3: orchestrated	Level 4: perpetual
Identity verification	Document photos reviewed by staff	Vendor document and liveness check	Several methods (chip, video, wallet) chosen by risk	Wallet-ready, injection attack protection, measured fraud rates
Screening	Manual list checks	Automated screening at onboarding	Tuned matching, structured case management	Continuous re-screening of the whole base, measured false positive rate
Risk scoring	Individual judgement	Static rules	Configurable, explainable model with versioning	Event-driven score updates
Reviews	Ad hoc	Fixed cycles in a spreadsheet	Scheduled by risk level in the system	Event-driven plus AMLR minimum cycles
Beneficial ownership	Declarations only	Registry lookup	Ownership graph with “25% or more” logic	Monitored for changes
Audit trail	Documents in folders	Logs per tool	Central, immutable evidence store	Reproducible decisions with rule and model versions
Vendors	One, hard-wired	One, via API	Abstraction layer, replaceable	Several combined by cost and quality
Metrics	None	Volume and backlog	Conversion, false positives, handling time	Balanced dashboard of conversion and risk

The key takeaways:

1. KYC is a lifecycle, not a check. Design for reviews, events and monitoring from the start, not only for onboarding.
2. The AMLR sets concrete system requirements from July 2027 — review cycles, the “25% or more” ownership threshold and a single rulebook across the EU.
3. Deepfakes and injection attacks make liveness a security control. Test vendors against both, and prefer chip reading where possible.
4. Buy components, own decisions. Document and biometric checks are commodities; orchestration, risk rules and the audit trail are where control matters.
5. Build versus buy depends on volume. In our example, a platform is cheaper at 10,000 onboardings a month, and the options break even at about 20,000.
6. Measure both sides. Completion rate and time to onboard must be tracked together with false positives, backlogs and fraud.

At ARDURA Consulting we have been building software and IT teams for clients in Poland, Europe, the Middle East and the USA for more than ten years, including for banks and fintechs. We help design KYC architecture, provide backend, QA, DevOps and data specialists for the build phase and strengthen in-house teams ahead of regulatory deadlines through fintech IT staffing and software development.

If you are planning changes to your KYC system before the AMLR and the EU Digital Identity Wallet deadlines, talk to our team. We can review your current architecture against the maturity model above and estimate what the next level would take.