AI for banking and fintech: KYC, AML, risk, customer service

A KYC department in a fintech company handles five thousand onboardings per month. Each client submits an ID, address confirmation, and bank statement in various formats, with varying scan quality—sometimes a photo taken from an awkward angle with a phone. Someone has to open all these, verify them, manually enter the data into the CRM system, and decide whether the document is legible enough to proceed. With five thousand cases per month, this amounts to dozens of man-hours just for data entry. This is where AI delivers measurable value. The problem arises when someone promises "fully automated KYC without human involvement" or "AML that blocks accounts on its own." That’s a different conversation—one that touches on consumer rights, RODO, and the AI Act. Below, we separate fact from fiction, without making promises that can’t be kept in a regulated sector.

The first area where real returns are achievable is converting identity documents, address proofs, and bank statements into structured records. OCR reads text from images, while a language model extracts specific fields: first and last name, document number, date of birth, address, IBAN.

On clean, standard documents (modern ID cards, bank printouts), a well-tuned data extraction pipeline achieves over 90% accuracy at the field level. For phone photos, older documents with inconsistent layouts, or foreign documents, accuracy drops and can be unpredictable without testing on a representative sample of real documents. That’s why you can’t assume the extracted date of birth is always correct: for fields affecting the process, a human confirms, and the system displays the document snippet from which the value was derived.

How to ensure quality and structure of source data so the pipeline has something to work with is covered in data governance for AI. Data extraction from documents in other contexts is discussed in AI for document analysis.

Anti-money laundering is an area where AI makes a real difference compared to purely rule-based systems. A rule-based approach requires someone to know in advance what threshold to set. An anomaly detection model learns the distribution of normal activity and flags deviations before anyone can configure a rule.

The architecture we use operates in layers. The rule-based layer catches simple breaches (amounts exceeding limits, countries outside the whitelist). The statistical layer detects smurfing—many small transactions intentionally designed to stay below the threshold. The model layer, based on a classifier trained on transaction history, assesses the likelihood of suspicious activity and generates a risk signal with an explanation of which features contributed. The detailed multi-layer architecture, including the cold-start problem, is described in AI for fraud and anomaly detection.

Here’s what’s often glossed over in presentations: the false positive rate in AML is a real operational cost. Compliance analysts spend time reviewing alerts that turn out to be legitimate transactions. Typical ML-based AML systems achieve precision in the 20-40% range, meaning 60-80% of alerts are false positives requiring manual dismissal. This is still better than purely rule-based systems, which generate even more false positives, but it shouldn’t be ignored when designing analyst teams.

The non-negotiable boundary: reporting to financial authorities (STR/SAR), account closure, and transaction denial are irreversible actions that require a human decision with full justification in the audit log.

Creditworthiness assessment is arguably the most regulated area of AI applications in finance. AI can calculate a score, compile risk signals, and prepare a justification for the analyst. It cannot independently reject a loan application for an individual without human intervention.

The reasons are both legal and practical. Legal: automated decisions with legal effects on individuals require the right to human intervention under Article 22 of RODO. Practical: a model trained on historical data may perpetuate discriminatory patterns if past decisions were biased (e.g., higher rejection rates for specific demographic groups or regions).

Explainability of decisions is a requirement, not an option. The analyst approving or rejecting an application must understand which signals pushed the score up or down: SHAP values for gradient boosting models show the contribution of each feature to the assessment. This is also a requirement of the AI Act for high-risk systems, and creditworthiness assessment systems for individuals are explicitly listed in Annex III.

DPIA (Data Protection Impact Assessment) is required before deploying automated profiling for credit purposes, before anything goes into production. The data governance framework we apply to such systems is detailed in data governance for AI.

The fourth area is handling customer inquiries: application status, required documents, product terms, complaint procedures. An assistant grounded in regulations, fee schedules, and FAQs reduces the burden of repetitive queries on consultants.

Principles we don’t compromise on in this context: the assistant must be anchored in the institution’s actual documents, because a model without this grounding can fabricate contract terms that don’t exist. When a question involves an individual financial decision, a complaint with legal liability, or account blocking, the assistant escalates to a human. Human oversight here is both a regulatory requirement and a matter of customer trust in the institution.

The architecture of this assistant is based on the same principles as the systems described in AI for insurance: knowledge extraction from documents, guardrails to prevent improvisation, and human handoff for sensitive matters.

Banking and fintech are sectors where regulations precisely define which AI applications are high-risk. Creditworthiness and credit scoring systems for individuals are explicitly listed in Annex III of the AI Act (point 5b). AML systems that affect access to financial services may fall under the same classification. It’s worth confirming the classification for a specific use case with a lawyer before anything goes into production.

Practical implications of being classified as high-risk:

• Technical documentation must include a model description, training data sources, quality metrics, known limitations, and retraining procedures. It must be updated with every significant model change.
• Explainability of decisions. Every decision with a negative impact on the customer must be explainable: which signals contributed, how the customer can appeal.
• Human gate as a technical requirement, not just procedural. The system must enable human intervention, not just declare it in documents.
• Post-deployment monitoring. The AI Act requires active tracking of system quality on production data and documented procedures for detected degradation.

RODO and personal data protection (PII) are separate layers of requirements: transaction data and identity documents are personal data requiring a legal basis for processing, minimization, TTL retention, and a data processing agreement when using external models. Obligations under the AI Act and RODO for companies implementing AI systems are outlined in AI Act and RODO 2026.

The entry point we see as most balanced for the regulated financial sector: one narrow problem with measurable cost and low regulatory risk. Typically, this is data extraction from one type of KYC document or routing customer queries to the right service queue. We don’t start with credit risk or AML as the first project.

Then, a pilot runs alongside the current process in shadow mode: AI prepares and flags, while humans still decide. We measure real accuracy on a sample of actual documents before anything operates independently. Only when the numbers are known and accepted do we gradually expand, maintaining a human gate wherever decisions about money or customer access are involved.

We don’t recommend this, and in many cases, the law doesn’t allow it. Article 22 of RODO grants individuals the right not to be subject to decisions with legal effects based solely on automated processing. Credit scoring systems are high-risk under the AI Act, requiring human oversight and explainability. AI calculates the score and prepares the justification; the analyst makes the final decision.

It depends on the quality and standardization of the documents. On clean, Polish identity documents, a well-tuned data extraction pipeline typically achieves over 90% accuracy at the field level. For phone photos, foreign documents, or older layouts, accuracy drops, so fields affecting the process are always confirmed by a human, and the system shows the source document snippet.

ML-based AML systems typically achieve precision in the 20-40% range, meaning 60-80% of alerts are false positives requiring manual review by an analyst. This is still better than purely rule-based systems but requires adequate analyst staffing and alert prioritization. Classifier thresholds are set to minimize total operational cost, not maximize sensitivity.

Credit scoring systems for individuals are explicitly listed in Annex III of the AI Act as high-risk systems. AML systems affecting access to financial services may fall under the same classification. Obligations include technical documentation, DPIA, decision explainability, active monitoring, and the right to challenge decisions via human intervention.

Yes, this is a design decision, not a technical necessity. Identity and transaction data can be processed by locally hosted models (self-hosting) or by a provider with EU processing guarantees and a RODO-compliant data processing agreement under Article 28. In the regulated financial sector, it’s worth making this decision consciously at the start of the project, as it determines the entire architecture and scope of the DPIA.