FlowKit

Automating KYC checks and AML/CTF vigilance at customer onboarding with n8n

Published 2 September 2026 · 5 min read

Since the AMLA (the EU's anti-money-laundering authority, operational out of Frankfurt since 2025) came into force alongside the 2024 AML regulatory package, customer due diligence at onboarding no longer tolerates guesswork: identify the client, identify the beneficial owner, screen against sanctions lists, flag politically exposed persons (PEPs), document all of it, and be able to justify it at any time to your regulator. For a fintech, a wealth management firm, or any smaller regulated business, this workload often falls on one or two people juggling a spreadsheet and manual lookups against official lists — a process that holds up under neither volume nor scrutiny. A 2024 study by Bakry, Alsharkawy and Farag published in the Journal of Supercomputing ("Automatic suppression of false positive alerts in anti-money laundering systems using machine learning", see on Google Scholar) puts a number on the problem that shapes the whole topic: in AML systems built on simple rules, the overwhelming majority of generated alerts are false positives, which swamp compliance teams without ever mapping to a real risk. A well-built n8n pipeline doesn't pretend to eliminate that noise — it sorts it, before it ever reaches a human.

What AML/CTF due diligence requires at onboarding

Financial regulation and supervisory guidelines structure customer due diligence around a handful of concrete obligations, whatever the regulated sector:

  • Identify the client and, where applicable, the beneficial owner: ID document, articles of incorporation for a legal entity, ownership chain beyond a control threshold.
  • Screen against sanctions and asset-freeze lists (EU, UN, OFAC lists depending on international exposure) and flag any politically exposed person status, which requires enhanced vigilance without automatically barring the relationship.
  • Determine a risk profile (low, standard, enhanced) that drives how intensive the vigilance is and how often it gets reviewed.
  • Document every step and every decision, including cases where enhanced due diligence concludes the relationship should continue despite a match — silence on an unresolved match is exactly what an audit flags first.

Why automated screening changes the equation

The study cited above is about transaction monitoring, but its lesson maps directly onto onboarding screening: a system built on rigid rules (loose name matching, no context) generates a volume of alerts nobody can seriously work through by hand — and it's precisely when volume outpaces human capacity that true positives drown in the noise. Automation only earns its place if it attacks that bottleneck: query the screening API systematically (instead of a manual lookup someone forgets on a busy day), pre-qualify the match with the context available, and route to a human only what genuinely deserves attention — as covered in our guide to building an AML-grade audit trail with n8n and Supabase for the traceability that should accompany every decision.

Building the KYC check in n8n, step by step

The skeleton reuses the same building blocks as the Compliance & Audit Pack (€149), adapted to the onboarding journey:

  1. Collect the client's and beneficial owner's identity with the guided questionnaire bot: identity, articles of incorporation, ownership chain for a legal entity. A structured conversational flow avoids the missing fields a static form too often lets slip through.
  2. Screen through a dedicated API: an HTTP Request node queries a sanctions and PEP screening service — for example OpenSanctions's /match/default endpoint (or /match/sanctions and /match/peps to narrow the scope) — with the client's name, date of birth and country as input. Store the API key following the principles in our guide to securing API credentials in n8n — never in plain text inside a Set node.
  3. Pre-qualify the match without deciding alone: a Structured Output Parser downstream of an AI node structures the similarity score, the reason for the match (name, date of birth, alias) and a readable summary, then an IF node routes to human approval via a Wait node in Slack whenever the score clears a low threshold — better too many human reviews than too few on this topic.
  4. Log the decision to the audit trail with the Supabase audit logging workflow: the risk profile assigned, whether the match was dismissed or confirmed, who made the call, and the timestamp. That table, not a stray email, is what answers a regulator asking why a given client was accepted despite a partial match.

Screening on an ongoing basis, not just at onboarding

Sanctions lists and PEP status change constantly: a client cleared in January can appear on a list in July, with nothing prompting a fresh look on its own. A Schedule Trigger that reruns screening across the entire client base periodically — monthly for a standard risk profile, more often for an enhanced one — closes that gap. The same pack's automated follow-up workflow flags files whose periodic review is overdue and notifies the person responsible; for a large volume of clients to rescreen, respect your API provider's rate limits per our guide to rate limiting AI APIs in n8n, and wire in an Error Workflow so a screening batch never fails silently.

Common pitfalls

  • Screening only once, at onboarding. Without periodic rescreening, vigilance stops exactly where it should keep running: for the life of the relationship.
  • Letting a score threshold decide alone. An automated similarity score pre-qualifies a match; it never replaces a reasoned decision by an authorized person on an ambiguous case.
  • Not documenting dismissed matches. A regulator who finds an untraced match in an accepted client's file sees a gap, even when the underlying decision was justified.
  • Underweighting beneficial-owner data. Screening only the legal representative, without tracing the ownership chain, lets through exactly the kind of structure AML rules target.

Where to go from here

KYC/AML screening shares the same backbone as every other compliance workflow built with n8n: a structured conversational protocol, an append-only Supabase audit trail, and scheduled follow-ups — already covered for a GDPR processing register or DORA compliance. The Compliance & Audit Pack (€149) ships these building blocks ready to adapt to your onboarding journey. For organizations handling particularly sensitive data, our comparison of n8n self-hosted vs. cloud helps decide where the instance running these checks should live; and if your compliance team also gets its regulatory alerts by email, the FlowKit Complete Bundle (€269 instead of €347 bought separately) pairs this pack with the Inbox AI Pack (€79) and the RAG Assistant Pack (€119).

FAQ

Frequently asked questions

Can n8n replace a dedicated KYC platform?

For an SME, an early-stage fintech, or a firm subject to AML/CTF rules with a reasonable volume of onboardings, n8n orchestrated around a screening API (OpenSanctions or equivalent) covers the essentials: identification, sanctions/PEP screening, risk classification and an audit trail. A bank or a volume of several thousand customers a month justifies a dedicated KYC tool instead, with graph-based monitoring and proprietary scoring — n8n still earns its place there orchestrating the alerts and reporting around that tool.

Is automated screening enough to prove compliance?

No. AML/CTF rules require a documented risk-based approach: automated screening identifies possible matches, but qualifying a hit (true positive, false positive, moderate-risk PEP) and deciding whether to enter or continue the relationship remain human decisions, owned and logged in your audit trail. Automation cuts the triage work, not the responsibility for the decision.

Is it enough to screen once, at onboarding?

No — that's the most common mistake. Sanctions lists and PEP status change continuously, and a client who was clean at onboarding can appear on a list six months later. AML/CTF vigilance is a continuous obligation: periodic rescreening of the client base, not a one-off check at first contact.

What do I do when the screening API returns an ambiguous score?

Never let a score threshold decide an ambiguous case alone: systematically route mid-range scores to human review rather than picking an arbitrary auto-clear cutoff. The workflow can pre-qualify and summarize the match to speed up the review, but the decision stays documented and signed off by an authorized person.

Bundle FlowKit Complet

€269