Automate KYC/AML Customer Onboarding for Financial Services with n8n + Claude Step-by-Step Guide

2. System Architecture

Eight components, each replaceable. The orchestration layer is self-hosted n8n inside the institution’s VPC so the security team can audit every external call. Postgres holds the case file, the evidence packs, and the WORM-style audit log partitioned by month. Encrypted S3 holds the raw documents. Nothing about a customer leaves the perimeter except hashed identifiers to ComplyAdvantage and the redacted prompt body to Claude (with zero-data-retention enabled).

The stack

Cost estimate (1,200 onboardings/month)

Compared to two full-time KYC analysts (~$140k/yr loaded each), the stack costs roughly 18% of the labor it displaces, and it works every weekend, every holiday, at peak quarter-end without overtime. The same orchestration approach plugs into our broader AI automation services.

Onboarding starts with a structured intake — name, DOB, SSN/ITIN (or non-US equivalent), address, occupation, source of funds, expected activity, and entity type. The customer also uploads a primary government ID and a proof-of-address document. Persona handles the front-end with liveness detection so a stolen ID image plus a static selfie cannot pass; on a successful capture Persona webhooks an encrypted bundle to n8n.

Intake fields the pipeline expects

• CIP fields: legal name, DOB, residential address, SSN/ITIN/passport. These satisfy 31 CFR 1023.220.
• Risk-relevant context: occupation + employer, source-of-funds narrative, expected monthly activity in dollars, expected counterparties (countries, instrument types).
• Entity flags: is this a beneficial-ownership-rule entity (FinCEN BO Rule)? List the 25%+ owners and the control prong.
• PEP self-declaration: the customer is asked, but the screening provider also runs an external check; mismatches are an EDD signal in their own right.

n8n webhook node — Persona payload

A single n8n Webhook node accepts the Persona payload. HMAC verification using the shared signing secret runs before the workflow does anything else; an invalid signature short-circuits to a 401 and writes a security-event row. The body contains the case ID, the structured fields, and pre-signed S3 URLs for each uploaded artifact.

{
  "event": "inquiry.completed",
  "case_id": "case_01HXYZABC...",
  "received_at": "2026-05-03T09:14:22Z",
  "signature": "sha256=...",
  "applicant": {
    "legal_name":     "Maria Elena Rodriguez",
    "dob":            "1984-07-12",
    "ssn_last4":      "4421",
    "address": {
      "street": "1485 Ocean Ave Apt 6B",
      "city":   "Brooklyn",
      "state":  "NY",
      "zip":    "11230",
      "country": "US"
    },
    "occupation":      "Independent consultant",
    "employer":        "Self-employed",
    "expected_monthly_activity_usd": 12000,
    "source_of_funds": "Consulting income + savings"
  },
  "entity": null,
  "pep_self_declared": false,
  "documents": {
    "primary_id":      "s3://kyc-vault/case_01.../id_front.jpg",
    "primary_id_back": "s3://kyc-vault/case_01.../id_back.jpg",
    "selfie":          "s3://kyc-vault/case_01.../selfie.jpg",
    "proof_of_address": "s3://kyc-vault/case_01.../utility.pdf"
  },
  "liveness_score": 0.97
}

Persona returns a liveness score and a verification verdict, but the institution still has to extract and normalize the data on the document for matching against the intake form and against the screening providers. Claude Sonnet’s vision capability reads the ID, returns structured fields, and flags suspicious artifacts (mismatched fonts, missing security features, edited regions). The extraction runs in parallel with the address-doc OCR.

What the extractor returns

Vision system prompt

Tested on a labeled sample of 4,200 historical IDs (clean, blurry, expired, edited) — pulled with privacy-team approval and re-redacted before any prompt iteration. The prompt explicitly forbids inventing fields not visible on the document.

You are an identity-document extraction engine for a U.S.
broker-dealer's KYC pipeline. You read government-issued ID
images and return strict JSON.

EXTRACT:
- document_type (passport | drivers_license | state_id |
  national_id | residence_permit)
- issuing_country (ISO 3166-1 alpha-3)
- issuing_authority (state or federal body, verbatim)
- full_name (as printed)
- dob (YYYY-MM-DD)
- document_number
- date_of_issue (YYYY-MM-DD if visible)
- date_of_expiry (YYYY-MM-DD if visible)
- mrz_machine_read (if MRZ band present)
- address_on_doc (if shown)

QUALITY SIGNALS — flag, do not refuse:
- font_kerning_inconsistent
- edge_ghosting_detected
- lighting_inconsistent_across_zones
- mrz_visible_field_mismatch
- security_feature_absent (hologram, microprint)
- image_blur_above_threshold
- document_appears_expired

OUTPUT — strict JSON, no prose:
{
  "document_type": "...",
  "issuing_country": "USA",
  "extracted_fields": { ... },
  "quality_flags": ["..."],
  "tampering_likelihood": "low" | "medium" | "high",
  "extraction_confidence": 0.0-1.0
}

Rules:
- Never invent a field. Use null for unreadable values.
- Do not output the SSN if the document somehow shows one.
- Tampering is a flag for human review, NOT a rejection.

n8n HTTP request — vision call

{
  "method": "POST",
  "url": "https://api.anthropic.com/v1/messages",
  "headers": {
    "x-api-key": "{{ $credentials.anthropic.apiKey }}",
    "anthropic-version": "2023-06-01",
    "content-type": "application/json"
  },
  "body": {
    "model": "claude-sonnet-4-5",
    "max_tokens": 800,
    "system": "{{ $json.idExtractorPrompt }}",
    "messages": [
      {
        "role": "user",
        "content": [
          { "type": "image",
            "source": {
              "type": "base64",
              "media_type": "image/jpeg",
              "data": "{{ $json.idFrontBase64 }}"
            }
          },
          { "type": "text",
            "text": "Extract per the schema. Case_id: {{ $json.case_id }}" }
        ]
      }
    ]
  }
}

Once the identity is normalized, n8n posts the canonical name (plus DOB + country to disambiguate) to ComplyAdvantage or Refinitiv World-Check. The provider screens against OFAC SDN, the EU consolidated list, UK HMT, UN, and dozens of national lists, plus PEP databases and adverse-media indexing. The raw response is verbose and noisy by design — fuzzy matching pulls in many false positives. Claude reads each hit and explains in plain English why it is or isn’t a real match.

The screening pipeline

1. Name normalization — strip honorifics, transliterate non-Latin scripts, generate aliases for diminutives (“Bill” / “William”) with a deterministic library, not the LLM.
2. Primary screen — ComplyAdvantage with fuzziness 0.8, returns up to 200 candidate matches.
3. Disambiguation pass — Claude scores each candidate against DOB, nationality, occupation, and address. Returns confirmed_match / unlikely_match / requires_human.
4. Adverse media filter — keyword + named-entity filter on the article snippets. Material categories: financial crime, terrorism, sanctions evasion, fraud convictions. Tabloid noise is dropped.
5. Tier assignment — confirmed sanction or PEP routes to senior review; multiple adverse-media hits with material categories goes to EDD; no hits or only-noise hits clear.

Disambiguation prompt

You are a sanctions/PEP disambiguator for a U.S. broker-dealer
operating under FINRA Rule 3310 and the BSA. You are NOT making
the final clearance decision; you are scoring each candidate hit
against the verified customer profile so a human can act faster.

INPUT:
- verified_customer: { full_name, dob, citizenship,
                       residential_country, occupation }
- candidate_hits: [ { source_list, matched_name, dob_or_yob,
                       countries, role_or_designation,
                       last_updated, original_record_url } ]

FOR EACH candidate, output:
{
  "candidate_id": "...",
  "match_assessment": "confirmed" | "likely" | "unlikely" |
                      "false_positive" | "requires_human",
  "rationale": "1-2 sentences citing the discriminating fields",
  "discriminators_used": ["dob", "country", "occupation", ...],
  "evidence_quality": "high" | "medium" | "low"
}

RULES:
- DOB mismatch >5 years on a person sanction = false_positive
  unless the source is OFAC SDN with no DOB given.
- Common-name hit on adverse media without country/role match
  = false_positive.
- Any OFAC SDN exact match = confirmed regardless of other
  fields. Do not soften this.
- Refuse to clear: never output "confirmed false" for OFAC.
  Use "requires_human" if uncertain.
- Always cite which fields drove the call.

Risk tier comes from a written rubric, not a black-box scorer. The institution’s MLRO defines the inputs, the weights, and the thresholds in plain English; Claude applies them. Examiners can read the same prompt the model reads. When the rubric changes (a new high-risk geography, a tightened source-of-funds policy), one file changes and a CI deploy ships it — no model re-training, no vendor escalation.

The 6 risk dimensions

Risk-tier prompt

You score onboarding risk for a U.S. broker-dealer under
FINRA Rule 3310 and the BSA. The MLRO has set the rubric below.
Apply it literally. Do not invent risk factors not listed.

WEIGHTS (sum = 100):
- geography_risk        20
- customer_type_risk    15
- product_risk          15
- transaction_pattern   20
- screening_residual    20
- document_quality      10

TIER MAPPING:
- low      0-29
- medium   30-59
- high     60-100
- escalate any case with confirmed OFAC, confirmed PEP,
  or confirmed sanctions evasion narrative regardless of total.

INPUT (JSON):
- verified_identity, declared_activity, expected_counterparties,
  screening_outcome, document_quality_flags

OUTPUT — strict JSON:
{
  "tier": "low" | "medium" | "high" | "escalate",
  "score": 0-100,
  "dimension_scores": { ...six fields... },
  "rationale": "3-5 sentences naming the strongest factors",
  "edd_required": true | false,
  "monitoring_recommendation": "standard" | "enhanced" | "frequent"
}

RULES:
- Cite at least one specific input field per dimension.
- "escalate" overrides numeric tier — never silently downgrade.
- Never recommend SAR; that decision is the BSA officer's.

The reasoning string lands in the case file as the model-generated portion of the risk assessment narrative. The reviewing analyst can adopt, edit, or reject it; the audit log captures both versions. Examiners get a clean side-by-side view of what the model said and what the human decided.

A SAR is filed by the BSA officer, never by an automated system. What the pipeline does is surface the patterns and the evidence in the form FinCEN expects, so the officer’s review time goes to judgement, not data assembly. The SAR-trigger detector runs against the case at onboarding and again on every monitored transaction batch.

SAR-relevant patterns at onboarding

• Identity inconsistency: name on ID does not match the intake form, multiple identities tied to one phone or device fingerprint, addresses linked to known mail-drop services.
• Source-of-funds implausibility: declared income inconsistent with funding amount, vague narrative (“savings”), unwillingness to clarify.
• Structuring indicators: initial funding pattern crafted to stay under 10k reporting thresholds, deposits arrayed across multiple accounts within 24h.
• Beneficial-owner opacity: declared owners refuse to provide ID, ownership chain runs through nominee services or shell-like entities.
• Geographic risk concentration: all funding from a high-risk jurisdiction with weak counterparty disclosure.

Trigger detector — JSON output

{
  "case_id": "case_01HXYZ...",
  "triggers_detected": [
    {
      "category": "structuring_indicator",
      "severity": "medium",
      "evidence": [
        "Three planned ACH credits of $9,500 over 4 days",
        "All from same originator under different memo lines"
      ],
      "fincen_red_flag_ref": "FIN-2014-A007 paragraph 3"
    },
    {
      "category": "source_of_funds_implausibility",
      "severity": "low",
      "evidence": [
        "Declared income $48k/yr",
        "Initial funding $185k titled 'savings'"
      ]
    }
  ],
  "recommended_action": "edd_with_sar_pre_review",
  "narrative_skeleton": "Customer opened account 2026-05-03..."
}

Three queues, three SLAs. Auto-clear cases never touch a queue at all — they get a confirmation email, a Salesforce record write, and an audit-log entry. Medium-tier (EDD) routes to compliance analysts with the model’s evidence pack pre-attached. High-tier and SAR-trigger cases route to the BSA officer with the file locked from any further automated action until they release it.

Routing matrix

Slack alert payload (high tier)

{
  "channel": "#bsa-priority",
  "blocks": [
    {
      "type": "header",
      "text": { "type": "plain_text",
                "text": ":rotating_light: High-tier KYC — case 01HXYZ" }
    },
    {
      "type": "section",
      "fields": [
        { "type": "mrkdwn",
          "text": "*Tier*nHigh (score 74)" },
        { "type": "mrkdwn",
          "text": "*Drivers*nPEP likely-match, geography risk, SoF gap" }
      ]
    },
    {
      "type": "section",
      "text": { "type": "mrkdwn",
                "text": "*Evidence pack:* ID extraction, screening rationale, risk dimensions, expected-activity calc — all pre-attached in the case file." }
    },
    {
      "type": "actions",
      "elements": [
        { "type": "button", "text": { "type": "plain_text",
          "text": "Open case" }, "style": "primary",
          "url": "https://compliance.internal/case/01HXYZ" },
        { "type": "button", "text": { "type": "plain_text",
          "text": "Reassign" }, "action_id": "reassign_case" }
      ]
    }
  ]
}

Salesforce Financial Services Cloud is the source of truth for the customer relationship, the household, the rep, and the compliance object that holds risk tier and review history. The n8n workflow upserts the customer, attaches the related contacts (beneficial owners, authorized signatories), updates risk tier on the compliance object, and writes a relationship to the case file. Plaid is called in parallel for funding-source verification and for a 24-month transaction-history pull that feeds the expected-activity baseline.

Salesforce upsert (Composite API)

{
  "compositeRequest": [
    {
      "method": "PATCH",
      "url": "/services/data/v60.0/sobjects/Account/External_Id__c/case_01HXYZ",
      "referenceId": "acctRef",
      "body": {
        "Name": "Maria Elena Rodriguez",
        "RecordTypeId": "0125g000000XYZ_Individual",
        "skru_kyc_tier__c": "low",
        "skru_kyc_score__c": 22,
        "skru_kyc_rationale__c": "{{ $json.risk.rationale }}",
        "skru_screen_outcome__c": "clear",
        "skru_review_due_at__c": "2027-05-03"
      }
    },
    {
      "method": "POST",
      "url": "/services/data/v60.0/sobjects/Compliance_Case__c",
      "referenceId": "caseRef",
      "body": {
        "Account__c": "@{acctRef.id}",
        "skru_case_id__c": "case_01HXYZ",
        "skru_status__c": "auto_cleared",
        "skru_evidence_url__c": "s3://kyc-vault/case_01HXYZ/pack.json",
        "skru_audit_hash__c": "{{ $json.audit.hash }}"
      }
    }
  ]
}

Plaid funding verification

Plaid returns the verified bank account ownership (name on the account must match the customer), institution metadata, and a 24-month transaction history. The history is summarized into expected-activity bands and written back to the compliance object so that day-one transaction monitoring has a baseline. Customers without a Plaid-supported bank fall back to micro-deposit verification with a 1-3 business day delay; the case stays in pending state until the verification clears.

The BSA requires records of customer identification and verification be retained for 5 years after the account closes; SAR records have their own retention regime. More importantly for examiner readiness, every event in the case lifecycle needs to be reconstructible — what the model said, what the analyst overrode, who clicked approve, what evidence was attached. A standard append-only Postgres table with hash-chained rows gives a tamper-evident log without the cost of a full WORM appliance.

Audit log schema

CREATE TABLE kyc_audit_log (
  id              bigserial PRIMARY KEY,
  case_id         text NOT NULL,
  event_type      text NOT NULL,
  actor           text NOT NULL,
  actor_role      text NOT NULL,
  payload         jsonb NOT NULL,
  prompt_hash     text,
  model_version   text,
  prev_row_hash   text NOT NULL,
  this_row_hash   text NOT NULL,
  occurred_at     timestamptz NOT NULL DEFAULT now()
) PARTITION BY RANGE (occurred_at);

-- this_row_hash = sha256(prev_row_hash || event_type ||
--                        actor || payload::text || occurred_at)
-- An attempt to alter any historical row breaks the chain
-- on every subsequent row.

CREATE INDEX idx_audit_case  ON kyc_audit_log (case_id, occurred_at);
CREATE INDEX idx_audit_actor ON kyc_audit_log (actor,   occurred_at);

-- Read-only role for examiners
CREATE ROLE examiner_readonly;
GRANT SELECT ON kyc_audit_log TO examiner_readonly;
REVOKE INSERT, UPDATE, DELETE ON kyc_audit_log FROM PUBLIC;

What gets logged

• Case opened: intake fields hash, customer-facing IP, Persona inquiry id.
• ID extracted: model version, prompt hash, structured output, confidence, quality flags.
• Screening run: provider request id, candidate-hit count, disambiguator output for each.
• Risk tier assigned: rubric prompt hash, dimension scores, final tier, EDD flag.
• SAR trigger evaluated: categories detected, severity, FinCEN red-flag references cited.
• Human review: reviewer id, decision, override-of-model flag, justification text.
• Customer state changed: any transition between pending / approved / locked / closed.

Common Failures & Fixes

Four failure modes show up in nearly every deployment. Plan for them on day one — they are cheap to design around and ruinous to retrofit.

Failure 1: PEP false positives flooding the analyst queue

Symptom: The PEP list is broad — local council members, senior university officials, retired diplomats. A common name pulls 40 candidate hits and the analyst spends an hour clearing them manually.

Fix: Run the disambiguator (step 3) before the human ever sees the queue. Auto-clear hits with DOB mismatch greater than 5 years and country mismatch on the same record. Surface to the analyst only the candidates Claude could not rule out, with the discriminating fields highlighted. Track precision monthly to make sure the auto-clear isn’t drifting.

Failure 2: Vision extraction hallucinates a clean field on a tampered ID

Symptom: A subtly altered date of birth on a passport extracts cleanly, the screening clears, the customer onboards, the discrepancy is caught months later in a manual file review.

Fix: Always cross-check the MRZ band against the visible field zone; mismatches are an automatic EDD trigger. Run the extraction twice with different prompt phrasings and require agreement on the high-stakes fields (name, DOB, document number). Keep a sample of cleared documents in a monthly QA review where a human re-extracts a 3% sample and compares to the model output.

Failure 3: Re-screening drift on existing customers

Symptom: A customer was clean at onboarding. Two years later they’re elected to a foreign legislature, ComplyAdvantage updates the PEP record, but nothing in the institution’s stack reacts because the original screening was a one-shot call.

Fix: Subscribe to ComplyAdvantage’s monitored-list webhooks for every onboarded customer. The provider notifies on any list change touching a name in your portfolio; n8n re-runs the disambiguator and re-tier. Material changes route to the BSA officer on the same day. The audit log captures the delta so the next examiner sees a continuous record, not a point-in-time snapshot.

Failure 4: Treating model-vs-analyst disagreement as a defect

Symptom: The team starts adjusting the prompt every time an analyst overrides Claude’s tier, chasing 100% agreement. The prompt becomes a Frankenstein of edge-case overrides and stops generalizing.

Fix: Disagreement is the feature, not the bug. Track agreement rate as a metric, but do not target 100%. Use overrides to find systematic gaps (a high-risk geography missing from the rubric, a customer-type weight that’s off) and patch the rubric in the prompt; do not patch the prompt to match a single analyst’s instinct. Review the override log monthly with the MLRO present.

Compliance: FINRA Rule 3310, BSA, FinCEN & GLBA

A KYC pipeline lives inside a dense regulatory perimeter. FINRA Rule 3310 sets the AML program standard for broker-dealers; the BSA and its FinCEN regulations define recordkeeping, CTR, and SAR obligations; the GLBA (with the FTC Safeguards Rule and the SEC’s Regulation S-P) governs how non-public personal information is stored and shared. State-level regimes (NYDFS Part 500 in particular) layer additional cybersecurity and incident-reporting requirements. Treat compliance as architecture, not a checklist.

What Claude sees (and doesn’t)

• Sees: name as printed on the ID, DOB, document number, address, declared occupation, declared activity bands, screening hits, document image (only on the vision call, not on the risk-scoring call).
• Doesn’t see: SSN/ITIN in full (ever — only the last-4 mask), bank account numbers, transaction details beyond aggregated bands, internal Salesforce IDs, employee names beyond the reviewing analyst.

FINRA Rule 3310 specifics

Rule 3310 requires a written AML program, a designated AML compliance officer, ongoing training, and an annual independent test. The pipeline supports each: the prompts and the rubric live in version control as the written program, the audit log evidences ongoing monitoring, the override-tracking log evidences that the AMLCO is engaged, and the independent test is run by extracting a stratified sample from the audit log and re-performing the controls.

BSA and FinCEN obligations

• CIP (31 CFR 1023.220): identity collection and verification within a reasonable time after first interaction. The pipeline targets sub-4-hour completion.
• CDD beneficial ownership rule: 25%+ owners and one control-prong individual on entity accounts. The intake form enforces these fields; the screening runs on each.
• SAR filing: within 30 days of detection, 60 if a subject is unknown. Trigger detection, evidence assembly, and BSA-officer routing happen on day one of detection.
• Recordkeeping: 5 years post-relationship for CIP, 5 years for SAR-related records, indefinite for OFAC matches under enforcement. Audit log partitioned monthly with retention policy enforced at the partition level.

GLBA + Reg S-P safeguards

• Encryption at rest: Postgres TDE, S3 with KMS keys held inside the institution’s account; vendor never holds raw documents.
• Encryption in transit: TLS 1.3 only, mutual TLS for vendor APIs where supported.
• Access controls: RBAC on n8n credentials, short-lived role assumption for the AI service, MFA on every human access path, just-in-time elevation for SAR-tier records.
• Incident response: 30-day GLBA breach window per FTC Safeguards (and the 72-hour NYDFS clock for covered entities) is a hard deadline; the audit log feeds the discovery query.

Measured Results — 90 Days In

Numbers from a real implementation at a U.S. mid-size broker-dealer (350 new accounts/month, a 4-person compliance team, one BSA officer) after the first full quarter on the new pipeline. No change in onboarding volume or risk appetite during the test — the lift comes from prioritization, evidence pre-assembly, and the audit-log discipline.

The headline metric inside the compliance team is auditor-readiness. Pulling a complete file for an examiner used to take three to four hours per case; with the audit log it’s sub-30-second SQL. The next FINRA cycle examination concluded with no findings on the AML program, the first year that’s happened in this firm’s history.

Implementation Timeline & Cost

FAQ