From Days to Hours: What KYC Onboarding Actually Looks Like at Scale

You know that feeling when a new account opening just… sits.

Three days. Maybe more. The KYC process churned through manual steps, scattered across Slack threads and provider portals and someone’s spreadsheet. The customer waiting. The ops team juggling.

Most fintech teams think their KYC bottleneck is the ID check. It’s not.

The ID check takes seconds. What takes days is everything around it.

Onboarding Regulatory Reality Check

Before we get into workflows, let’s name what’s making this hard, from an European perspective:

AMLD6 (EU): Requires ongoing monitoring, beneficial ownership verification, and risk-tiered due diligence. It’s not a one-time check — it’s a living process.

PSD2: Adds strong customer authentication layers on top of identity verification. The compliance surface keeps growing.

Proper accreditation (like ACPR in France): For regulated entities like Qonto, critical processes require a two-step validation model. No shortcuts.

The short version: KYC isn’t optional, and the requirements don’t simplify as you scale. They multiply.

The ID Check Takes Seconds. The Coordination Takes Days.

Document collection varies by country. Entity types change what you need. Beneficial ownership structures are messy — and inconsistently documented. Re-KYC triggers are poorly defined, often buried in a Slack thread or someone’s memory.

The regulatory rule is the easy part. The operational overhead is what hurts.

When you’re processing 4,000 account openings per week, like Qonto’s Head of Onboarding shared on our podcast, even a small amount of manual coordination per case adds up fast. That’s when KYC stops being a compliance problem and becomes an operational crisis.

KYC as an Orchestration Problem

Here’s the reframe that changes everything.

While onboarding can look like a verification flow issue, it is an orchestration problem. If you take KYC and KYB into account, you’re coordinating between:

Each of these has dependencies. Each can fail or stall. And the branching logic (what to do when a beneficial owner is flagged, or when a document is unreadable, or when a jurisdiction requires a second verification step) is probably gathering dust in a knowledge base, or, worse, exists only in oral form.

Until you make it a workflow. That you constantly adapt.

Forest is the Orchestration Layer for Fintech Onboarding

This is exactly what Forest Workflows is built for.

Forest is the ops orchestration layer that lets fintechs run compliance and business operations across any supplier, any database, with humans and AI agents working together. And your data never leaves your infra.

That last part matters more than most people realize. When you’re handling KYC data (passports, proof of address, beneficial ownership structures) you can’t afford to route sensitive applicant information through a third-party SaaS layer you don’t control. Your regulators don’t care about your vendor’s security certifications. They care about yours.

Forest Workflows runs on your stack. Two types of tasks power every step:

→ Native tasks: direct operations on your own database. Customer records, document metadata, account status, risk flags, all staying exactly where they are. No exports, no copies, no sync lag.

→ MCP Connector tasks: external API calls, orchestrated by Forest through your infrastructure. Onfido for IDV. ComplyAdvantage for screening. The call goes out, the result comes back, the full exchange is logged in your own DB.

No copy-paste between systems. No tab-switching. No “someone export that spreadsheet.”

The workflow is the ops interface. Humans handle the judgment calls. AI agents handle the pattern recognition and document fetching. Forest handles the plumbing; and the audit trail.

The same pattern is laid out, step by step, on the KYC operations page.

The Country Problem: how to adapt onboarding per regulator?

Country-specific compliance is the real bottleneck no one talks about in vendor pitch decks.

Qonto runs separate KYC workflows for 8 European markets including France, Belgium, Germany and Italy. While Qonto’s team is aiming to reuse certain parts, these are not variations on the same flow but genuinely separate workflows, each with different:

→ Required document types

→ Accepted verification providers

→ Approval thresholds and escalation logic

→ Regulatory reporting requirements

Bringing the process knowledge in the operating tool works: after deploying Forest workflows in their Belgium pilot, they achieved 100% compliance rate.

And a similar approach in Italy is helping demonstrate operational capability to regulators, directly supporting market re-opening.

This is not a product feature story. This is what compliance teams actually need: a way to codify country logic without writing custom code every time a new market opens up.

In Forest Workflows, each country variant is a separate workflow that shares the same underlying logic where possible (with sub workflows), and branches where it doesn’t. One canvas per market. No custom code. No engineering sprint every time compliance requirements shift in a new jurisdiction.

How BaaS Providers Handle Onboarding: the Multiplication Effect

It gets more complex when you’re not the regulated entity but  when you’re the infrastructure layer enabling others to operate banking services. Which is the case for Banking-as-a-Software (BaaS) providers.

Swan, a BaaS that’s been a Forest customer for years, enables 150+ software companies to embed banking into their products. Each of those companies has end-users who need onboarding (KYC/KYB). 

“Finding the right balance between customer friction and checks against fraud is the key challenge. To scale fast, we need to really limit the customer friction… but fraudsters hear about us.”

— Maxime de Juniac, Swan

That tension — speed vs. control — is the defining challenge of fintech operations at scale. Move too fast and you let fraud through. Move too slow and you lose legitimate customers before they finish onboarding.

The answer isn’t to pick a side. It’s to make the workflow smart enough to apply different friction levels based on risk signals. Low-risk applicant from a known device in a low-risk jurisdiction? Straight-through processing. Unusual beneficial ownership structure with a high-risk country flag? Human review, second verification step, escalation trail.

Same workflow engine. Different branches.

How AI Agents Run Inside Your Onboarding Workflow

AI agents are doing real work inside onboarding queues now. They read passports and proof of address, extract structured data, enrich an application against public registries, and propose a risk score before an analyst opens the case.

What changed is where they run. An agent that reads a customer’s passport is handling the same data your analysts handle, so it answers to the same controls. On Forest, each agent step is a task in the workflow like any other. Your team sets what the agent can read, what it can write, and which decisions still need a human. Every action it takes lands in the same audit trail as your reviewers’, with the full causal chain attached.

Forest runs as both an MCP Client and an MCP Server, which gives your team two ways to put an agent in the flow.

Your workflow calls out. A step in the onboarding flow hands the case to an agent platform, waits for what comes back, and carries on. The agent does the reading or the enrichment. Your workflow keeps the sequence.

Your agents call in. An agent you already run reads a case from Forest, writes to it, or advances it to the next step. It works through the same roles and permissions as your analysts, so what it can touch is what you granted it.

As the logic gets more complex, auditable and configurable workflow design gets more critical. An agent that cannot be inspected is an agent your regulator will ask about.

Making the Case for Secured Workflows in Onboarding

For anyone who needs to make a business case internally:

→ Efficient: from 3–5 days to 3–6 hours, typical reduction in KYC/KYB onboarding time with structured workflows

→ Compliant: Able to reach 100% compliance rate at scale

→ Battle-proven: 4,000 account openings/week processed at Qonto

Every one of these comes from a team that moved KYC from a one-time event to a standing process.

Workflow Pattern: KYC/KYB Onboarding in Forest Workflows

To help you get started, here is the basic Onboarding process.

You can also use our KYC Onboarding Skill file to feed your favorite LLM or AI agent tool.

Each step below maps directly to a task type in Forest Workflows. Native tasks run against your own database. MCP tasks call external providers — orchestrated by Forest, logged to your infra.

Human review, where analysts enter the flow

Steps 4 and 5 are where a person takes over. Medium and high-risk cases route to the analyst queue in Forest, with the full context on one screen: verification results, screening flags, the document package, and the rationale behind the risk score. Two-step validation applies for regulated categories (ACPR-compliant). Low-risk cases clear without a reviewer.

Keeping KYC current: re-KYC

Approval is the start of the obligation. Most teams run the rest of it as re-KYC: scheduled re-verification on a cadence set by risk tier, watchlist re-screening against the screening provider, and anniversary reviews on the file.

Each of those is the same six-step pattern on a timer rather than on a signup. In Forest, your team configures them as scheduled workflows: the refresh cadence per tier, the re-screening frequency, and what a new hit does to an account that is already live. Every change is timestamped in your DB, with the full audit trail retrievable on demand for regulatory inspection. Re-KYC runs as a process on the KYC operations page too, where it sits as perpetual KYC.

Escalation

This can be set up as a branch or a sub-workflow and will feed a dedicated approver inbox.

The whole pattern can be built once in Forest Workflows, then adapted to your needs, per country and entity type, without rebuilding from scratch each time, without an engineering sprint, without touching your core stack.

That’s the shift. From tribal knowledge to repeatable infrastructure.