kyc-customer-onboarding

name: kyc-customer-onboarding description: > Performs customer KYC (Know Your Customer) verification and onboarding for commercial banking, including identity verification, document collection, risk assessment, sanctions screening, and account activation. industry: financial-services sub-sector: commercial-banking function: compliance version: 1.0.0 authors:

• name: Tyms url: https://tyms.com supported_locales:
• UG tags:
• kyc
• onboarding
• compliance
• aml
• customer-verification complexity: intermediate reference_framework: primary: name: "BIAN (Banking Industry Architecture Network)" version: "13.0" mapping: "Party Reference Data Management, Customer Offer, Party Authentication" secondary: name: "APQC Banking PCF" mapping: "8.1.1 Establish KYC/CDD, 8.1.2 Perform due diligence"

KYC Customer Onboarding

Purpose

This skill enables an AI agent to guide and execute the customer KYC (Know Your Customer) verification and onboarding process for commercial banking operations. It covers the end-to-end workflow from initial customer identification through document collection, risk assessment, sanctions screening, approval routing, and account activation. The skill encodes regulatory compliance requirements, reporting obligations, and audit standards that govern KYC operations across jurisdictions.

When to Use

• New customer account opening (individual or business)
• Periodic KYC review or re-verification when a scheduled review date is reached
• Customer upgrade requiring enhanced verification (e.g., from basic to full account)
• Trigger-based enhanced due diligence following a suspicious activity indicator
• Onboarding a customer acquired through a merger, acquisition, or portfolio transfer
• Re-onboarding a previously offboarded customer who wishes to resume the relationship

Process Overview

Step 1: Customer Identification

• Collect customer identity information including full legal name, date of birth, nationality, and contact details
• Determine customer type: individual, sole proprietor, corporate, NGO, trust, or other legal entity
• Determine the required verification level based on customer type and initial risk indicators: simplified, standard, or enhanced
• Capture the declared purpose of the account and expected transaction profile
• Record the channel through which the application was received (branch walk-in, online, agent-assisted, referral)
• Assign a unique application identifier and timestamp the start of the process

Step 2: Document Collection & Verification

• Request required identity documents based on customer type and locale requirements
• For individuals: national identity card, passport, or other government-issued photo ID
• For businesses: certificate of incorporation, memorandum and articles of association, tax identification certificate, trading license, board resolution, and beneficial ownership declaration
• Verify document authenticity using automated verification where available (e.g., national ID database API)
• Cross-reference document details against the information provided in Step 1
• Assess document quality and legibility; request resubmission with quality guidelines if documents are unreadable
• For business accounts: trace beneficial ownership to ultimate beneficial owners holding 25% or more
• Store verified documents in the document management system with classification tags and retention metadata

Step 3: Risk Assessment

• Score customer risk based on the following factors: customer type, geographic location, product type, expected transaction volume, source of funds, industry or occupation, and any adverse information
• Apply risk scoring rules to produce a numeric risk score (0-100) and a risk classification (low, medium, or high)
• Flag high-risk indicators that require enhanced due diligence: cash-intensive businesses, cross-border activity with high-risk jurisdictions, complex ownership structures, or unusual transaction profiles
• Determine the approval authority level required based on the risk classification: auto-approve for low risk, compliance officer for medium risk, senior compliance or committee for high risk
• Document the risk factors and scoring rationale for the audit trail

Step 4: Screening

• Screen the customer (and all beneficial owners for business accounts) against international sanctions lists: United Nations, OFAC, EU, and locally mandated lists
• Check against Politically Exposed Persons (PEP) databases, including domestic and foreign PEP lists
• Screen for adverse media coverage related to financial crime, fraud, corruption, or terrorism
• Record each screening result individually with the list name, match confidence, and timestamp
• For positive matches: classify as confirmed match, possible match, or false positive
• For possible matches: queue for manual review by a compliance officer with match details

Step 5: Approval / Escalation

• Auto-approve low-risk customers who meet all criteria: valid identity verified, documents collected, risk score below threshold, all screenings clear
• Route medium-risk applications to a compliance officer for review with the full case file
• Escalate high-risk applications to senior compliance officer or compliance committee with detailed risk assessment and screening results
• For any PEP match (confirmed or possible): require human review at approver level regardless of overall risk score
• For any confirmed sanctions match: block the application immediately and trigger a suspicious activity report
• Record the decision (approved, rejected, escalated), the decision maker (auto-system, operator, reviewer, approver, committee), and a written rationale
• For rejections: record the specific rejection reason and notify the customer with permitted information only

Step 6: Account Activation

• Confirm that all KYC requirements have been satisfied: identity verified, documents collected and verified, risk assessed, screenings completed, and approval obtained
• Activate the account in the core banking system with the appropriate account type and product configuration
• Set transaction limits based on the assigned KYC level (simplified, standard, or enhanced)
• Schedule the next KYC review date based on the risk classification: 12 months for high-risk, 36 months for medium-risk, 60 months for low-risk
• Generate the compliance package containing all verification records, screening results, risk assessment, and approval documentation
• Send account activation confirmation to the customer through their preferred communication channel

Required Inputs

Outputs

Integration Points

Dependencies & Handoffs

Requires (inputs from other skills)

Triggers (outputs to other skills)

Workflow Position

[Customer Request / Periodic Trigger]
              |
              v
   [KYC Customer Onboarding]  <-- THIS SKILL
              |
              +-- Approved -----------> [Account Opening] --> [Product Onboarding]
              |
              +-- Sanctions Match ----> [Suspicious Activity Reporting]
              |
              +-- Rejected -----------> [Rejection Notification]
              |
              +-- EDD Required -------> [Enhanced Due Diligence]
              |
              +-- Business Approved --> [Beneficial Ownership Registry]
              |
              +-- Periodic Trigger ---> [KYC Review] (self)

Roles & Permissions

Segregation of Duties

Reporting

Key Performance Indicators

Data Points to Capture

Each execution of this skill should produce the following data points for reporting and analytics:

Suggested Reports

Alert Triggers

Error Handling

Failure Scenarios

Critical Rules

These rules must never be violated regardless of system state, operational pressure, or override requests:

1. Never approve without completed sanctions screening -- even if the screening service is down, the application must wait. No exception, no workaround.
2. Never auto-approve a PEP match -- all PEP matches (confirmed or possible) require human review at approver level regardless of the overall risk score.
3. Never delete or modify audit records -- the audit trail is immutable. No role, including admin, has permission to alter historical records.
4. Never bypass document verification -- identity documents must be collected and verified even if the customer is known from other banking relationships.
5. Never share screening results with the customer -- sanctions match, PEP match, and adverse media details are confidential and must not be disclosed to the applicant or any unauthorized party.
6. Never approve an application you initiated -- the operator who processes the case cannot also be the approver; segregation of duties must be enforced at all times.

Framework Alignment

Primary Framework: BIAN (Banking Industry Architecture Network) v13.0

This skill maps to three BIAN service domains that together cover the end-to-end KYC and customer onboarding process:

What BIAN defines: BIAN provides a service-oriented architecture framework that identifies approximately 300 service domains representing discrete business capabilities. For KYC, BIAN defines the high-level service boundaries, data entities, and inter-domain relationships. BIAN tells an enterprise architect which capabilities exist and how they relate to each other at the architecture level.

What BIAN does not define: BIAN does not prescribe locale-specific regulatory requirements, accepted identity documents, risk scoring methodologies, operational KPIs, error handling procedures, audit retention periods, SLA targets, or role-based approval workflows. These are left to the implementing institution.

What OpenIOM adds: This skill fills the gap between BIAN's architectural blueprint and production operations. It provides the step-by-step operational logic, locale-specific compliance requirements (via locale overlays), risk assessment criteria, screening procedures, reporting KPIs, data classification, error handling and fallback procedures, audit event definitions, SLA expectations, role definitions with segregation of duties, and validation scenarios that a platform needs to actually execute the KYC process. Where BIAN says "Party Reference Data Management exists as a service domain," OpenIOM says "here is exactly how to collect, verify, and manage customer identity data, what can go wrong, what to measure, and what to log."

Secondary Framework: APQC Banking PCF

This skill aligns with the following APQC Banking Process Classification Framework process areas:

APQC provides a hierarchical process taxonomy that complements BIAN's service-oriented view. Where BIAN organizes by capability, APQC organizes by process flow. Together they provide a complete picture: BIAN tells you which services are involved, APQC tells you where the process sits in the enterprise process hierarchy.

Notes

• BIAN service domain mappings are based on the publicly available BIAN Service Landscape v13.0. Detailed behavioral qualifiers and service operation mappings may require BIAN membership access for full validation.
• APQC Banking PCF process ID mappings are based on the publicly available process classification hierarchy. Detailed sub-process mappings may vary by APQC version.
• This mapping is considered stable for the v1.0.0 release. Community feedback and formal BIAN/APQC validation are welcome to refine the alignment.

Audit Requirements

Mandatory Audit Events

Every execution of this skill must log the following events for compliance and audit purposes:

Regulatory Retention Requirements

Retention periods vary by jurisdiction. The base requirement follows FATF recommendations. Locale overlays specify binding local requirements.

Note: Locale overlays provide the definitive local requirements for each jurisdiction. The table above is indicative and must be supplemented by the applicable locale overlay.

Audit Trail Access

Data Classification

Data Sensitivity Levels

All data points handled by this skill are classified for appropriate handling by implementing platforms:

Classification Definitions

Validation Scenarios

Platforms implementing this skill should verify correct behavior against the following scenarios:

Locale overlays may add additional validation scenarios specific to their jurisdiction. For example, the Uganda locale overlay includes scenarios for LC1 letters, mobile money KYC tier upgrades, and URA TIN verification failures.

SLA Expectations

Processing Time Targets

End-to-End Targets

SLA Breach Handling

Changelog