Skip to content

Enterprise Detailed Specification: Customer Onboarding Process

Financial Economic Crime (FEC) Operating Platform

Audience: Business stakeholders, compliance officers, regulators, enterprise architects, software developers, onboarding analysts, KYC operations, sanctions analysts, EDD analysts, audit teams.

Chapter 1: Purpose and Scope

1.1 Purpose

This document defines the enterprise-grade specification for the Customer Onboarding Process within a Financial Economic Crime (FEC) operating platform.

Customer onboarding is one of the most critical control processes in a financial institution because it establishes the institution’s initial risk acceptance decision.

Every downstream control depends on onboarding quality.

If onboarding is weak:

  • prohibited customers may enter the institution,

  • sanctions exposure may be missed,

  • beneficial ownership may remain opaque,

  • customer risk ratings become unreliable,

  • transaction monitoring becomes less effective,

  • investigations become inefficient,

  • regulatory findings become likely.

This specification defines business requirements, process design, data architecture, workflow orchestration, controls, security, auditability, and technical requirements necessary to implement an enterprise-grade onboarding capability.

1.2 Scope

This specification covers:

  • onboarding process architecture

  • business variants

  • customer classification

  • workflow orchestration

  • data model

  • document management requirements

  • screening orchestration

  • risk rating orchestration

  • escalation routing

  • EDD branching

  • approval controls

  • audit requirements

  • SLA requirements

  • integration requirements

  • security requirements

  • technical implementation considerations

Out of scope:

  • transaction monitoring

  • post-onboarding case investigations

  • fraud onboarding controls (future integration)

Chapter 2: Business Definition

2.1 What Customer Onboarding Is

Customer onboarding is the regulated operational process through which a financial institution evaluates whether a prospective customer relationship may be established.

This is not merely a commercial intake process.

It is a formal risk acceptance workflow.

The institution must establish:

  • customer identity

  • legal existence

  • beneficial ownership

  • business purpose

  • expected relationship behavior

  • sanctions exposure

  • PEP exposure

  • adverse risk indicators

  • geographic exposure

  • ownership complexity

  • risk classification

  • policy eligibility

The final outcome is a formal acceptance decision.

Possible outcomes:

  • approved

  • approved with restrictions

  • approved subject to EDD completion

  • rejected

  • withdrawn

  • prohibited / blocked

2.2 Business Objectives

Primary objectives:

  • prevent onboarding of prohibited entities

  • comply with AML/CTF obligations

  • comply with sanctions regulations

  • establish accurate customer master data

  • assign risk-based controls

  • route high-risk cases appropriately

  • ensure consistency of decision-making

  • support auditability and regulatory review

Secondary objectives:

  • reduce onboarding cycle time

  • reduce analyst inefficiency

  • improve customer experience

  • minimize false escalations

  • standardize enterprise workflows

Chapter 3: Regulatory and Compliance Objectives

3.1 Regulatory Expectations

The onboarding process must support obligations related to:

  • Know Your Customer (KYC)

  • Customer Due Diligence (CDD)

  • Enhanced Due Diligence (EDD)

  • sanctions screening

  • beneficial ownership transparency

  • suspicious customer prevention

  • policy governance

  • auditability

  • retention obligations

  • explainable decisions

A regulator should be able to reconstruct:

  • what information was collected

  • what controls were executed

  • what policy version applied

  • what data sources were used

  • who approved the decision

  • what exceptions occurred

  • why acceptance occurred

3.2 Compliance Design Principles

Mandatory principles:

  • risk-based approach

  • explainability

  • reproducibility

  • segregation of duties

  • maker/checker controls

  • evidence preservation

  • policy traceability

  • override governance

Chapter 4: User and Actor Model

4.1 Human Roles

Relationship Manager

Purpose: Commercial initiation.

Responsibilities:

  • initiate customer request

  • provide business justification

  • collect business context

  • communicate with customer

Onboarding Specialist

Responsibilities:

  • intake review

  • workflow initiation

  • completeness verification

  • document coordination

KYC Analyst

Responsibilities:

  • customer verification

  • documentation validation

  • identity consistency review

  • ownership completeness review

Sanctions Analyst

Responsibilities:

  • screening adjudication

  • sanctions escalation

  • true hit confirmation

EDD Analyst

Responsibilities:

  • deep due diligence

  • ownership complexity review

  • source of wealth review

  • enhanced investigation

Financial Crime Compliance Reviewer

Responsibilities:

  • high-risk approvals

  • policy exception decisions

  • sanctions governance

Supervisor

Responsibilities:

  • workload balancing

  • SLA monitoring

  • escalation handling

Audit Reviewer

Responsibilities:

  • process verification

  • control assurance

  • audit reconstruction

4.2 System Actors

Automated actors:

  • workflow orchestration engine

  • customer classification engine

  • document validation engine

  • identity verification service

  • sanctions screening engine

  • PEP screening engine

  • risk rating engine

  • entity resolution engine

  • network analysis service

  • notification engine

  • audit service

  • policy validation engine

Chapter 5: Customer Archetypes

The process must support configurable onboarding models.

5.1 Retail Individual

Characteristics:

  • low ownership complexity

  • fast onboarding

  • limited document requirements

5.2 SME

Characteristics:

  • moderate ownership complexity

  • moderate due diligence

5.3 Corporate

Characteristics:

  • high ownership complexity

  • UBO transparency required

  • document-heavy workflow

5.4 Correspondent Banking

Characteristics:

  • highest complexity

  • deep due diligence

  • extensive approvals

5.5 Private Banking

Characteristics:

  • wealth scrutiny

  • reputational risk sensitivity

5.6 Leasing / Specialized Business Lines

Characteristics:

  • business-specific entities

  • product-specific rules

Chapter 6: Entry and Exit Criteria

6.1 Entry Criteria

Mandatory:

  • application created

  • customer type identified

  • business line identified

  • jurisdiction identified

  • minimum intake dataset available

Optional:

  • RM sponsorship

  • business pre-approval

6.2 Exit Criteria

Success:

  • approved

  • approved with restrictions

Negative:

  • rejected

  • withdrawn

Exceptional:

  • compliance block

  • sanctions prohibition

  • legal stop

Chapter 7: Canonical Data Model

7.1 Customer Entity

Attributes:

  • customer_id

  • customer_type

  • segment

  • business_line

  • status

  • expected_activity_profile

  • onboarding_date

  • relationship_status

Relationships:

  • 1:N Accounts

  • 1:N Cases

  • 1:N Risk Assessments

  • 1:N Documents

7.2 Individual Entity

Attributes:

  • person_id

  • first_name

  • surname

  • aliases

  • date_of_birth

  • nationality

  • residence_country

  • tax_residency

  • occupation

  • source_of_wealth

  • source_of_funds

  • pep_flag

  • pep_level

Attributes:

  • entity_id

  • legal_name

  • trade_name

  • registration_number

  • incorporation_country

  • legal_form

  • industry_code

  • incorporation_date

7.4 Ownership Relationship

Attributes:

  • relationship_id

  • parent_entity

  • child_entity

  • ownership_percentage

  • control_type

  • effective_dates

  • confidence_score

7.5 Document Entity

Attributes:

  • document_id

  • type

  • issue_date

  • expiry_date

  • validation_status

  • source_channel

  • storage_reference

7.6 Screening Result

Attributes:

  • screening_request_id

  • screening_type

  • screened_subject

  • matched_entity

  • match_score

  • rationale

  • disposition

7.7 Risk Assessment

Attributes:

  • assessment_id

  • methodology_version

  • risk_score

  • risk_band

  • contributing_factors

  • timestamp

7.8 Workflow Instance

Attributes:

  • workflow_instance_id

  • workflow_template_id

  • template_version

  • current_state

  • created_at

7.9 Task

Attributes:

  • task_id

  • task_type

  • assignee

  • queue

  • due_date

  • escalation_deadline

7.10 Decision

Attributes:

  • decision_id

  • decision_type

  • actor

  • rationale

  • timestamp

  • evidence_refs

Chapter 8: State Machine Model

Canonical lifecycle:

NEW → INTAKE → DATA_COLLECTION → DOCUMENT_COLLECTION → VALIDATION_PENDING → SCREENING_PENDING → RISK_ASSESSMENT_PENDING → ANALYST_REVIEW → EDD_REVIEW → COMPLIANCE_APPROVAL → APPROVED → REJECTED → CLOSED

Exceptional states:

  • ON_HOLD

  • WAITING_EXTERNAL

  • POLICY_EXCEPTION

  • ESCALATED

Chapter 9: Process Orchestration Model

9.1 Canonical Process Flow

  1. Application initiation

  2. Customer classification

  3. Workflow template resolution

  4. Data capture

  5. Document collection

  6. Identity validation

  7. Ownership capture

  8. Name screening

  9. Risk rating

  10. Optional network analysis

  11. analyst review

  12. EDD branch

  13. compliance approval branch

  14. final decision

  15. closure

9.2 Example Flow: Corporate Lending Customer

Inputs:

  • corporate customer

  • Netherlands

  • lending product

Workflow template selected: Corporate_NL_Lending_Onboarding_v1

Required documents:

  • chamber registration

  • incorporation certificate

  • shareholder register

  • director IDs

  • ownership declaration

Parallel orchestration:

Track A: Identity validation

Track B: Screening

Track C: Risk rating

Track D: Ownership mapping

Decision branches:

IF sanctions probable hit → compliance escalation

IF ownership complexity high → EDD

IF documentation incomplete → remediation loop

IF low risk → fast-track review

Chapter 10: Escalation Model

Level 1: Analyst Review

Triggers:

  • incomplete documentation

  • data mismatch

Level 2: Senior Review

Triggers:

  • analyst uncertainty

  • ambiguous ownership

Level 3: EDD

Triggers:

  • high risk score

  • PEP exposure

  • ownership complexity

Level 4: Compliance

Triggers:

  • sanctions probable match

  • policy exception

Triggers:

  • prohibited jurisdictions

  • exceptional legal concerns

Chapter 11: SLA Model

Illustrative requirements:

  • intake validation: 4 hours

  • document validation: 1 day

  • screening review: 30 minutes

  • analyst review: 1 day

  • EDD review: 2 days

  • compliance approval: 1 day

Breach actions:

  • reminder

  • supervisor escalation

  • workload rerouting

Chapter 12: Functional Requirements

Workflow:

  • configurable workflow templates

  • dynamic branching

  • subprocess insertion

  • parallel orchestration

  • loops and retries

Tasking:

  • queue routing

  • assignment

  • reassignment

  • workload balancing

Document management:

  • upload

  • validation

  • expiry checks

  • mandatory document logic

Decision orchestration:

  • synchronous module calls

  • asynchronous module calls

  • timeout handling

Controls:

  • approvals

  • SoD

  • override governance

Notifications:

  • reminders

  • escalations

  • customer requests

Chapter 13: Integration Requirements

Internal:

  • CRM

  • customer master

  • IAM

  • document repository

External:

  • sanctions providers

  • PEP providers

  • corporate registries

  • identity verification providers

Chapter 14: Security Requirements

  • RBAC

  • MFA

  • encryption in transit

  • encryption at rest

  • field-level access control

  • privileged access monitoring

  • secure document access

Chapter 15: Audit Requirements

Mandatory audit events:

  • workflow initiation

  • state transitions

  • task assignments

  • module invocation

  • module outputs

  • user decisions

  • approvals

  • overrides

  • document access

  • config version used

Chapter 16: Non-Functional Requirements

Performance:

  • responsive UI

Scalability:

  • concurrent workflow execution

Reliability:

  • retry logic

  • graceful degradation

Auditability:

  • deterministic replay

Usability:

  • low click count

Maintainability:

  • modular architecture

Chapter 17: Acceptance Criteria

Accepted when:

  • onboarding templates configurable

  • document rules configurable

  • screening integration operational

  • risk rating operational

  • escalation logic operational

  • audit replay successful

  • approvals enforce SoD

  • analysts complete end-to-end onboarding successfully