From your current KYB workflow to production

KYB implementation rarely starts with a blank sheet of paper.

Most teams already have a process. Business information arrives somewhere. Verification providers run checks. Analysts review exceptions. Decisions get recorded. CRM, case-management, or internal systems need the final status.

Some of that process may live in software. Some may live in spreadsheets, inboxes, PDFs, internal tools, or knowledge held by the compliance team.

That changes the implementation problem.

The first task is not configuring a new platform. It is understanding how a KYB decision is actually made today, then deciding which parts should become structured, automated, connected, and reviewable.

A good implementation preserves the controls that matter while removing the handoffs and manual work that do not.

‍

Stage 1: Map the current workflow

Before configuring rules or connecting an API, map the current process from intake to final decision.

The useful question is not simply, What checks do we run?

It is, How does information become a decision?

The gaps often appear between the formal steps.

A registry lookup may already be automated, but someone copies the result into a spreadsheet. Screening may run automatically, but a potential match is assigned manually. The final decision may be correct, but its rationale lives in a separate note or chat thread.

Mapping those handoffs reveals where workflow automation creates more value than simply adding another automated check.

This is also why Detelio recommends mapping systems, handoffs, evidence requests, review steps, approval authorities, recurring exceptions, and audit requirements before increasing automation. See KYB Automation Is Not Auto-Approval.

‍

Stage 2: Choose the first workflow

One of the easiest ways to make implementation unnecessarily difficult is to design the final-state architecture before the first meaningful workflow has run successfully.

A better starting point is one representative onboarding journey. That might be low-risk SME onboarding, merchant onboarding for one market, crypto counterparty verification, one business-customer segment, or one product or jurisdiction.

Once the first workflow behaves correctly, additional customer segments, jurisdictions, providers, and decision paths can be layered onto a working control model rather than designed in isolation.

‍

Stage 3: Turn written policy into executable workflow

A written policy can say that higher-risk businesses require enhanced review.

A working system needs considerably more precision.

It has to determine which signals increase risk, which combinations trigger escalation, which evidence becomes mandatory, who receives the case, who can approve it, and what rationale must be recorded.

The purpose is not to automate judgement out of KYB. It is to make the repeatable parts of policy explicit so routine cases behave consistently and exceptions reach the people responsible for judgement.

The European Banking Authority's remote-onboarding guidance reflects the same underlying principle: firms should use sound, risk-sensitive onboarding processes and assess the adequacy and reliability of the technology supporting them. See the EBA guidance.

‍

Stage 4: Decide where Detelio fits into the existing stack

Implementing a KYB platform does not necessarily mean replacing the verification providers or operational systems already in use.

The more useful question is: Which system should own each part of the process?

‍

A practical architecture often looks like this:

Verification & risk data → Detelio: Policy → Decision → Workflow → Evidence → CRM / compliance operations / case management / audit

‍

Three implementation patterns are common.

Hosted workflow

Useful when the team wants to move quickly without embedding the full experience into its own application from day one.

API-led workflow

Useful when customer onboarding remains inside an existing product and Detelio needs to operate behind that experience.

Hybrid workflow

Useful when some intake or review happens inside Detelio while status, decisions, events, or evidence synchronize with existing systems.

‍

The architecture should follow the operating model, not the other way around.

Detelio supports this through its API, Integrations, and Data Coverage layers.

‍

Stage 5: Design the exception paths before launch

Clean cases are useful for demonstrating that the workflow works.

Exceptions reveal whether the implementation works.

Test situations such as:

• registry information conflicts with submitted data
• required evidence is missing
• ownership cannot be resolved
• screening produces a potential match
• a provider returns incomplete data
• a risk threshold is crossed
• a reviewer overrides a recommended outcome
• a downstream system is temporarily unavailable
• a monitoring event changes the original risk picture

Every important uncertainty needs somewhere to go. The workflow should make clear who owns the exception, what additional evidence is required, whether escalation is necessary, and what needs to be recorded before the case can continue.

The implementation is ready when uncertainty has a defined destination.

‍

Stage 6: UAT should test decisions, not just endpoints

A successful API response does not prove that a KYB workflow is ready for production.

UAT should test what happens when real policy, data, people, and exceptions meet.

Happy path

Can a straightforward, low-risk business move through the expected workflow?

Policy path

Do higher-risk signals change requirements and routing correctly?

Exception path

What happens when information is missing, inconsistent, or inconclusive?

Human path

Can reviewers escalate, override, request evidence, and record rationale?

Evidence path

Can the team reconstruct why the final decision was made?

Integration path

Do statuses, events, and decisions reach downstream systems correctly?

Monitoring path

Does a meaningful change trigger the expected review?

Testing should verify control behaviour, not merely technical connectivity.

‍

Stage 7: Plan migration around what needs to remain operational

Teams moving from spreadsheets, internal tools, or another KYB platform often begin with the assumption that every historical artifact needs to be recreated inside the new workflow.

A better migration exercise separates three questions.

What must remain accessible?

Historical customer records, supporting evidence, approvals, timestamps, and other material required by regulation or internal retention policy.

What must become operational?

Active customers, current risk classifications, review dates, monitoring status, ownership information, and data that future decisions depend on.

What can remain archived?

Historical material that needs to be retained but does not need to drive current workflow logic.

The appropriate migration and retention model depends on applicable regulation, internal policy, data architecture, and the firm's record-keeping obligations.

‍

Stage 8: Move to production progressively

Implementation time depends on workflow complexity, provider setup, integration dependencies, policy configuration, and internal approval processes.

As a current Detelio benchmark, full API integrations with CRM and case-management systems typically take around 2–4 weeks including UAT, while hosted workflows can start considerably faster.

The goal should not be to switch everything on simultaneously.

‍

A safer progression is:

Configure → Test → Pilot → Production → Expand

‍

Once one workflow is stable, the same operating model can expand into additional customer segments, markets, providers, and monitoring requirements.

What should each side bring to implementation?

The implementation moves faster when responsibilities are clear from the start.

‍

Production is the beginning of the control lifecycle

KYB systems do not remain static after launch.

Policies change. Thresholds change. New customer types appear. Providers change. Monitoring creates new cases. Reviewers discover recurring exceptions. New jurisdictions introduce different requirements.

A useful implementation therefore needs to remain configurable after production rather than freezing the organisation into the architecture designed on day one.

After launch, teams should review exception volumes, override patterns, false positives, review times, monitoring triggers, policy changes, and additional integration needs.

FATF has similarly noted that new technologies can make AML/CFT measures faster and more effective when adopted responsibly and supported by suitable governance. See FATF's work on new technologies for AML/CFT.

‍

KYB implementation pre-launch checklist

The implementation is successful when the team can move from a business application to a reviewable decision without losing policy, evidence, accountability, or downstream state along the way.