Claude KYC Onboarding Checks for Banking Websites

AI KYC onboarding checks powered by Claude solve a problem that shows up in the audit findings of almost every banking group with more than one onboarding team: the same evidence gets a different answer depending on who reviewed it. A building society with a savings arm, a mortgage arm and a recently acquired digital brand may have three sets of analysts, three interpretations of the Customer Due Diligence procedure and three ways of writing up a file. Internal audit finds that a proof of address accepted in Leeds would have been rejected in Bristol, and the regulator cares only that the firm cannot show consistent application of its own policy.

The financial side is just as uncomfortable. Each onboarding analyst costs the group between £38,000 and £55,000 a year fully loaded, and a group opening 25,000 accounts a month across its brands may employ forty of them. Around half of their time goes on cases that are not risky at all, merely untidy: a scanned council tax bill with a crease through the postcode, an applicant whose passport shows a maiden name, a sole trader whose business address differs from the home address on the form. The other half goes on enhanced due diligence and periodic refresh, where the actual money-laundering risk sits.

Claude is used here as a reasoning layer between the firm's identity verification vendor and its analysts. It reads every piece of evidence in a file, applies the group's written policy the same way every time, produces a structured assessment with the specific rule behind each finding, and writes the file note. Nothing is approved by the model. The analyst sees a completed first draft of the work, checks it, and records the decision. This article describes how that integration fits a banking onboarding portal, where it pays off most, and what the components are.

Where Traditional KYC Onboarding Falls Short

Procedure documents are long, and analysts do not reread them for every case. A typical CDD procedure runs to sixty pages covering acceptable identity documents, address evidence, name change rules, high-risk jurisdictions, politically exposed persons, source-of-funds thresholds and the escalation matrix. In practice each analyst carries a personal summary in their head, and drift widens with every acquisition, new brand and new hire.

The file note is the second weak point. Under the Money Laundering Regulations a firm must be able to demonstrate why it was satisfied about a customer's identity, and the FCA expects that record to be intelligible to someone who was not in the room. Notes written under time pressure say "docs OK, cleared" or list the documents without explaining how the discrepancy in the address was resolved. When a skilled persons review lands, the group spends weeks reconstructing rationales that should have been written down at the time.

What Claude Adds to a Banking Onboarding Website

• Claude applies the group's written CDD procedure to each file in the same way, rather than each analyst's personal version of it.

• It returns a structured assessment in which every finding cites the specific policy clause that produced it, ready for the file note and for audit.

• It separates the untidy-but-safe cases from the genuinely risky ones so that senior analysts spend their time on enhanced due diligence.

Applying a long procedure to messy evidence

Claude handles long context well, which is what makes a sixty-page procedure usable as a live reference rather than a document nobody opens. The system prompt carries the relevant sections of the CDD procedure verbatim, the acceptable document matrix and the escalation rules. The user prompt carries the file: extracted text from each document, the vendor's authenticity and liveness results, screening outcomes, the form data and any earlier correspondence with the applicant.

The model reads the whole file at once and reasons across it. A maiden name on the passport is reconciled against the marriage certificate the applicant also uploaded. A business address that differs from the home address is matched to the Companies House extract in the same pack. A council tax bill with a damaged postcode is compared to the electoral roll result from the address verification service. The model says which evidence each conclusion rests on.

Structured findings with policy references

The integration requires Claude to answer in a fixed JSON structure. For each check there is an outcome, a confidence level, the documents relied upon and the clause of the procedure applied. There is a list of open questions the applicant must answer, a risk rating suggestion, a recommendation from a closed set, and a file note written in the group's standard format. The backend validates the structure before it is stored; a malformed answer is never shown to an analyst as if it were complete.

Because every assessment cites its clause, the quality assurance team can filter on any rule and see how it is being applied across all brands and offices. If clause 7.4 on address evidence is producing more open questions in one brand than another, that is visible in a week rather than at the annual audit. A policy change is a prompt change: the MLRO updates the procedure text and every subsequent case follows it.

Sorting the queue by risk rather than by arrival

With a validated assessment in hand, the platform routes each case. Files where every check passed and the vendor result was clean can be cleared by a rule the group has signed off, or placed in a light-touch queue for a quick human confirmation. Files with open questions go back to the applicant with a precise request, drafted by the model and approved by an analyst. Files with any high-risk signal, such as a PEP match, an adverse media hit or a source-of-funds explanation the evidence does not support, go straight to the enhanced due diligence team with the full reasoning attached.

The applicant-facing message matters more than it looks. A request that says "please upload a document dated within the last three months showing your name and current address, for example a bank statement or utility bill" resolves on the first attempt far more often than "additional documents required".

Best Use Cases for Claude KYC Onboarding

• Multi-brand banking groups and building societies that need one interpretation of policy across several onboarding teams and offices.

• Money transfer and remittance firms handling high volumes of applicants with foreign documents, name variations and complex address histories.

• Firms running periodic KYC refresh on existing customers, where the task is comparing old evidence with new rather than checking a single application.

Banking groups and building societies

A group with several brands usually inherited several procedures and is trying to converge them. Claude makes the converged procedure enforceable from day one, because every case in every brand is assessed against the same text. Quality assurance moves from sampling files after the fact to monitoring findings by clause.

The same structure supports the group's obligations under the Senior Managers and Certification Regime. The individual accountable for financial crime can show which version of the procedure was in force for any case, what the model found, who reviewed it and what they decided.

Money transfer and remittance firms

Remittance customers bring documents from dozens of countries, names transliterated in several ways and addresses that do not fit UK formats. Analysts at these firms are experts in exactly this variety, and their time is expensive. Claude takes the first pass: it identifies the document type, reads the extracted fields, notes that a Nigerian voter card is not on the acceptable list but an international passport is, and flags the name variation between the passport and the remittance form as a transliteration difference rather than a mismatch.

The analyst receives a file with the routine reconciliation done and the genuine questions highlighted. Throughput per analyst rises without lowering the standard.

Periodic refresh and ongoing monitoring

Refreshing KYC on an existing customer base is a different job from onboarding. The question is whether anything material has changed since the last review: address, ownership, expected activity, risk rating. Claude compares the previous file with the new submission and the transaction profile summary, lists the differences, and states whether each difference is explained by the evidence provided.

For a bank with 300,000 customers on a three-year refresh cycle, that is roughly 8,000 reviews a month. Having the comparison written up before an analyst opens the file changes the economics and makes the exercise consistent across the whole book.

Core Features of a Claude KYC Onboarding Website

• A file assembly layer that gathers documents, vendor results, screening outcomes and form data into one structured record per applicant.

• A reasoning layer where Claude applies the CDD procedure and returns a validated, clause-referenced assessment with a draft file note.

• A review layer with risk-sorted queues, applicant messaging, override tracking and reporting by clause, brand and analyst.

File assembly and evidence normalisation

Before the model is involved, a service pulls together everything known about the applicant: OCR output from each document with its quality score, the vendor's authenticity and liveness verdicts, sanctions and PEP screening results, the address verification response, the application form and any prior correspondence. Document images stay in the firm's own storage; the model sees text and codes only.

The service also normalises what it can deterministically. Dates are parsed, document types mapped to the acceptable list, expiry checked, and countries mapped to the group's risk classification. This gives the compliance team a clear line between what is rule-driven and what is assisted.

Reasoning and structured assessment

The backend constructs the prompt, calls Claude, and validates the JSON reply against a schema that mirrors the procedure. A schema failure triggers one retry and then a human fallback. Every stored assessment carries the procedure version, the prompt version and the model identifier, so the firm can always reproduce why a case was assessed as it was.

The prompt itself is owned by the compliance function. Developers build the mechanism; the MLRO's team maintains the procedure text within it and signs off changes. That boundary lets the group treat the integration as part of its control framework.

Review, override and reporting

Analysts work from queues sorted by risk and age. Each case opens with the model's assessment, the evidence it relied on and the draft file note. The analyst confirms, edits or overrides, and every action is timestamped against their identity. Overrides require a reason, and those reasons are reviewed monthly to decide whether the procedure text or the prompt needs adjusting.

Reporting is built around the clause references. Managers can see outcomes by clause, by brand, by document type and by analyst, along with first-pass resolution rates and time to decision.

Step-by-Step Integration Process

• Start by converging the procedure and defining the assessment schema with the MLRO, because the model can only be as consistent as the policy it is given.

• Build file assembly and the analyst review screen first, then introduce Claude as the reasoning step inside an existing workflow.

• Run a shadow period in which the model assesses live cases without routing them, and compare its findings with analyst decisions before going live.

Step 1: Define Onboarding Goals, Categories and Business Rules

The compliance and operations leads agree the single procedure that will apply across brands, the outcome categories the model may recommend, the risk signals that always escalate and the file note format.

Success measures are set at the same time: agreement rate between model and analyst on a historical sample, reduction in override rate over the first quarter, first-pass resolution of applicant requests, and audit findings on file quality.

Step 2: Design the User Journey for Applicants and Analysts

The applicant journey is adjusted so that precise document requests reach people while they are still in the flow, and so that a returning applicant sees exactly what is outstanding. The analyst journey is redesigned around the assessment rather than around a pile of PDFs, with the evidence, findings and note visible together.

If the model is unavailable or the reply fails validation, the case enters the standard manual queue with a flag.

Step 3: Connect Your Website Backend to Claude

The integration is implemented in the firm's backend, whether a Node service on Google Cloud, a Velo module on Wix Studio or an existing case management platform. The service assembles the file, calls the Claude Messages API with the procedure in the system prompt, validates the response and stores it. Keys live in a secrets manager; calls are logged with the case reference and never include document images.

A test harness of anonymised historical files with known outcomes is built alongside, and every prompt or procedure change is run through it before release.

Step 4: Save Results, Trigger Workflows and Keep Humans in Control

Validated assessments are written to the case record and drive routing, applicant messaging and dashboard updates. Automated clearance, where permitted, is recorded with the rule and version that allowed it. Every other outcome waits for an analyst.

The override loop is the control that keeps the system honest. Analysts can disagree with any finding, must say why, and those reasons feed the monthly review of the prompt and the procedure text.

Step 5: Measure Onboarding Quality and Improve Over Time

The first quarter is reviewed weekly against the agreed measures. Prompt and procedure changes are versioned and tested against the harness. Once the onboarding flow is stable, the same framework is extended to periodic refresh and to enhanced due diligence summaries, each with its own schema.

Security, Privacy, Cost Control and Long-Term Scalability

• Document images never leave the firm's storage; the model receives extracted text and result codes, and every call is logged for audit.

• Deterministic normalisation and rule-based clearance limit model calls to the cases that need reasoning, keeping cost proportional to complexity.

• The design supports UK GDPR data protection impact assessments, FCA record-keeping expectations and the accountability requirements of the Senior Managers regime.

Banks operate under UK GDPR, the Money Laundering Regulations, FCA supervision and, for card data, PCI DSS, and the architecture is designed to be explained to all of them. Data sent to the model is minimised to what the assessment needs, retention follows the firm's record-keeping schedule, and access to case data is role-based. Because no adverse decision is taken without an analyst, the ICO's rules on solely automated decisions with legal effect are not engaged, though the firm still documents the process in its data protection impact assessment.

Cost is proportional to the work. Files that are clean and complete cost nothing beyond the deterministic checks; files that need reasoning cost a few thousand tokens each, well below the analyst time they replace. The architecture scales from one brand to a group by adding schemas and procedure sections rather than rebuilding. Throughout, the principle is fixed: Claude drafts the assessment and the note; the firm's people confirm and decide.

Davydov Consulting scopes and builds this integration on the client's existing stack, whether that is Wix Studio with Velo, a Node and Firebase backend on Google Cloud, WordPress or a native mobile app. We begin with the procedure and the analyst workflow, add Claude as a validated reasoning step, and keep human sign-off in place for every decision that affects a customer. If your group is trying to make onboarding consistent across brands and teams, we would be pleased to discuss what a first phase could look like.