Sign up

Ultimate guide · Compliance + engineering

EU fintech B2B onboarding checklist

18 steps across legal-entity verification, beneficial ownership, sanctions, ongoing monitoring, and audit. AMLD5/6 baseline, opinionated, free.

Updated 28 October 2026

How to use this

This is the checklist we wish existed when we were building B2B onboarding for an EU fintech. It's organized by phase — Pre-onboarding, At-onboarding, Post-onboarding — with each step calling out: what regulators expect, what most teams build, and what we recommend now in 2026 with modern API tooling. Skip nothing without writing down why.

The compliance baseline is the EU 5th and 6th Anti-Money-Laundering Directives (Directive (EU) 2018/843 and 2018/1673), GDPR Article 6(1)(c) for legal-obligation processing, and PSD2 strong customer authentication where it applies. National transpositions vary; this checklist captures the convergent core.

Phase 1 — Pre-onboarding (before the customer signs up)

1. Risk policy + customer-acceptance criteria

Document who you will and will not onboard. Sanctioned jurisdictions, prohibited sectors (gambling, adult, weapons, MSBs depending on your license), prohibited corporate structures (bearer-share companies). The AMLD5 risk-based approach requires this is in writing before any customer arrives.

2. Privacy notice + LIA / consent flow

GDPR Article 13 transparency. Specify: data collected, purposes, lawful basis (typically Article 6(1)(c) for AML processing + 6(1)(b) for contract performance), retention periods, third-country transfers if any. Publish at /privacy and surface a summary at the onboarding form.

3. Vendor DPAs + sub-processor list

You will use vendors (KYC platform, sanctions API, document storage, email, Slack). For each: GDPR DPA in place, sub-processor disclosure, EU residency or SCC, deletion process. Maintain a vendor register.

4. Audit-trail spec

Decide BEFORE go-live what every onboarding event logs and where it goes. Minimum: timestamp, event type, actor (user / system / vendor), input data hash, decision, evidence references. An immutable append-only store (Postgres append-only table with RLS, or a dedicated event store).

Phase 2 — At onboarding (the user is filling the form)

5. Identifier collection + format validation

Collect the corporate identifier appropriate to the country: NIF (Spain), SIREN (France), Companies House number (UK), CRO number (Ireland), KRS number (Poland), organisation number (Norway), Y-tunnus (Finland), organisationsnummer (Sweden), enterprise number (Belgium), MBS or OIB (Croatia), CVR number (Denmark), registry code (Estonia), IČO (Slovakia), UID (Switzerland), registration number (Latvia), registration number (Cyprus), CUI (Romania), juridinio asmens kodas (Lithuania), corporation number (Canada), ACN or ARBN (Australia), corporate number (Japan), company number (Israel), UEN (Singapore), NIT (Colombia), unified business number (Taiwan), IČO (Czech Republic), CNPJ (Brazil), CUIT (Argentina), LEI (Germany) or a state-prefixed number such as NY-4424185 (United States). Validate format and checksum locally before anything else. See our Python tutorial for Spanish NIFs.

6. Registry resolution

Confirm the company is registered, currently active, and pull metadata. With Prometiam: GET /companies/search?nif=…&country=ES then GET /companies/{id}. Returns name, legal form, address, capital, founding date, and current officers.

7. Reject prohibited statuses

Reject onboarding for companies in dissolved, liquidation, or insolvency status. Optionally flag recently incorporated (under 6 months) for additional review.

8. Beneficial-ownership collection

Self-declaration of UBO chain: every natural person owning ≥25% directly or indirectly, plus senior managing officials if no 25% owner exists. Capture as a structured tree, not free text.

9. KYC of every UBO + officer

For each named individual: government-issued ID, proof of address, liveness check. Use a dedicated KYC vendor (Sumsub, Veriff, Onfido). Prometiam covers the company side; pair it with one of these for the natural-persons side.

10. Sanctions screening — entity + every named individual

Screen the legal entity name and every UBO/officer name against EU consolidated, UN, OFAC, UK, Australia (DFAT), FR gels, plus the US Consolidated Screening List. With Prometiam (sanctions screening is in beta): /sanctions/screen?name=&threshold=85. See our JavaScript tutorial and the sanctions screening use case.

11. PEP + adverse-media screening

Politically-exposed persons: a separate vendor (ComplyAdvantage, Refinitiv World-Check, Dow Jones Risk & Compliance). Screen every UBO and senior officer.

12. Director-network risk check

Do any of the named officers control multiple recently-dissolved companies? A directing person with 5+ recent dissolutions is a strong fraud signal. See the director-network use case for the pattern.

13. Source-of-funds / source-of-wealth declaration

For high-risk customers (high transaction volume, PEP-controlled, complex offshore structures), capture an SoF/SoW declaration with supporting evidence. Skip for low-risk customers per the risk-based approach.

Phase 3 — Decision + post-onboarding (the next 24 hours)

14. Risk-score computation + decision

Combine signals: jurisdiction risk, sector risk, transaction-volume estimate, sanctions hits, PEP hits, director-network signals. Output a numeric score and one of auto-approve / manual review / auto-reject. Document the rule.

15. Manual review queue with structured evidence

For the medium-tier customers, reviewers see the full evidence pack — registry data, sanctions hits, KYC documents, director-network exposure, the risk-score breakdown — in one screen. Reviewer's decision is logged with their identity and the supporting reasoning.

16. Customer-comms (approval / pending / rejection)

Clear, non-templated communication for each outcome. Approved customers get the next-step welcome flow. Pending customers get a "we're reviewing" message with an SLA. Rejected customers get the legally-required notice — without disclosing the specific reason in cases where doing so would tip off a possibly-malicious actor.

Phase 4 — Ongoing (forever, while the customer is active)

17. Continuous registry-event monitoring

Watch every onboarded customer for material registry events: capital changes, director changes, dissolution filings, address moves, name changes. With Prometiam: a daily cron on /company-events/search joining against your customer list. See our Cloudflare Workers tutorial for the implementation pattern.

18. Periodic re-screening + record refresh

Re-run sanctions screening on every customer quarterly minimum (monthly for high-risk). Refresh the company record on any monitored event. Re-run KYC on any UBO change. Document the periodic review in the customer's audit trail.

The Prometiam-shaped stack (the part we cover)

Prometiam covers steps 5, 6, 7, 10, 12, 17 of this checklist out-of-the-box. The remaining steps need a KYC vendor, a PEP/adverse-media vendor, your own risk engine, and your own compliance workflow.

Recommended companion stack for the non-Prometiam parts:

  • KYC of natural persons: Sumsub, Veriff, Onfido, or Persona
  • PEP + adverse media: ComplyAdvantage, Refinitiv World-Check, or Dow Jones
  • Document storage: any GDPR-compliant store with at-rest encryption — typically S3 with EU-resident bucket + KMS
  • Workflow + queue: Temporal, Inngest, n8n, or build on Postgres state machines
  • Audit log: append-only Postgres table with RLS, or a dedicated event store

Three pitfalls we keep seeing

  • Treating onboarding as one-time. The continuous-monitoring step is where most KYB programs fall down. The customer who passed last June may match a sanctions list this October. Build the monitoring loop on day 1, not on the first regulator finding.
  • Optimizing for false-negative-zero on sanctions. A 50-threshold sanctions screen drowns reviewers in noise that the real attacker disguises a real hit inside. Calibrate to your population — see the threshold-tuning section of the sanctions screening use case.
  • Logging the customer's PII in plaintext. Hashes and references in the audit log; the raw data lives only in the encrypted-at-rest customer record. Easier to comply with right-to-erasure too.

FAQ

Is this legally binding?
No — opinionated baseline. Validate with a compliance officer.

Non-EU customers?
The EU baseline is here. Add FATCA/CRS for US persons and additional sanctions screens as needed.

Can I skip manual review for low-risk customers?
Yes — risk-based approach is explicitly allowed under AMLD5.

How long should I retain onboarding records?
5 years after end of customer relationship under AMLD5 (Article 40).

Frequently asked questions

Is this checklist legally binding?
No — this is an opinionated engineering-and-compliance checklist that aligns with AMLD5/6, GDPR, and PSD2 baseline expectations. Treat it as a starting point, not legal advice. Validate the final policy with a qualified compliance officer.
Does this work for non-EU customers?
The compliance steps are designed for multi-country obliged entities. Onboarding non-EU customers usually requires extra steps (FATCA / CRS for US persons, additional jurisdictional sanctions checks). Add these as Tier-2 steps after the EU baseline.
Can I skip the manual review for low-risk customers?
Yes — risk-based approach is explicitly allowed under AMLD5. Build a risk score from the registry signals + sanctions hits + sector codes, and only manually review the medium-and-above tier.