Know Your Customer - As a Service
KYC as a Service
Know Your Customer (KYC) is a regulatory requirement for any business that holds money or moves it on behalf of people. Building a compliant onboarding flow from scratch — identity document checks, liveness detection, sanctions screening, PEP lists — is expensive, slow, and requires maintaining your own compliance program.
With bunq's KYC as a Service, you delegate that entire process to a regulated bank. bunq handles the verification, stores the compliance record, and issues a verified user that your platform can immediately act on.
The paradigm
When a new user signs up to your platform, you create a sub-user via the bunq API and kick off the KYC flow. bunq guides your user through identity verification (document upload + liveness check). Once verified, that user gets a bunq identity tied to your platform — ready to open accounts, receive payments, and use cards.
You never handle raw identity documents. bunq does the regulated heavy lifting; you get a simple boolean: verified or not.
Key things to understand:
Sub-user model. Each end-user on your platform maps to a bunq sub-user object. KYC status lives on that sub-user.
Verification is asynchronous. After initiating KYC, use a callback URL to receive the result rather than polling.
Retries and failure states. A user can fail verification (e.g. blurry document) and retry. Your integration should handle
PENDING,VERIFIED, andREJECTEDstates.Regulatory scope. bunq's KYC covers EU individuals. For corporate onboarding (KYB) or non-EU users, contact your bunq BaaS account manager.
Flow overview
Your platform bunq API
───────────── ────────
POST /user → Creates sub-user shell
POST /kyc-request → Triggers identity verification flow
← Callback: KYC_RESULT (VERIFIED / REJECTED)
GET /user/{id} → Fetch verified user objectRelevant API endpoints
Create a sub-user
Get user details / KYC status
Set a callback URL for events
Callback payload
When verification completes, bunq sends a POST to your registered callback URL. The payload includes the user ID, the new KYC status, and a timestamp. Always verify the X-Bunq-Server-Signature header before processing.
Common integration patterns
Pattern 1 — Verify before account creation. Gate monetary account creation on VERIFIED status. This is the safest approach and the most common for financial-product builders.
Pattern 2 — Optimistic onboarding. Let users start a limited flow (e.g. receive a payment link) before full KYC, and upgrade their permissions once verified. Requires careful UX design to avoid confusing users about what they can and can't do yet.
Last updated
Was this helpful?