Role of a Business Analyst in CDD and EDD: Complete Guide

In the highly regulated domains of Banking, FinTech, and Financial Services, Customer Due Diligence (CDD) and Enhanced Due Diligence (EDD) are critical components of Anti-Money Laundering (AML) and Know Your Customer (KYC) compliance.

When financial institutions build or upgrade their onboarding and transaction monitoring systems, the Business Analyst (BA) acts as the essential bridge between legal/compliance teams (who understand the regulations) and the software engineering teams (who build the risk engines).

The BA’s Goal in CDD & EDD Projects

A Business Analyst ensures that the software system automatically enforces regulatory rules, accurately scores customer risk, and provides a seamless user experience without compromising legal compliance.

5 Core Responsibilities of a BA in CDD & EDD

1. Eliciting and Translating Regulatory Requirements

Compliance policies are often written in dense legal jargon. The BA must translate these policies into structured Functional Requirements and Business Rules.

• Example: Translating the legal rule “Identify all major shareholders” into the functional requirement: “The system shall require the upload of an Ultimate Beneficial Ownership (UBO) organogram for any entity holding $\ge$ 25% voting rights.”

2. Designing the Risk-Scoring Engine

The BA collaborates with Risk Officers to define the parameters that determine a customer’s risk score. The BA documents the decision matrix based on:

• Geographic Risk: (e.g., Is the user from a high-risk FATF jurisdiction?)

• Entity Type: (e.g., Is the client a charity, a shell company, or a casino?)

• Transaction Volume: (e.g., Are they transacting over $10,000 monthly?)

3. Mapping Process Workflows (AS-IS and TO-BE)

BAs create detailed BPMN (Business Process Model and Notation) flowcharts that dictate how a user moves through the system. They map the “Happy Path” (Standard CDD approval) and the “Exception Path” (EDD escalation).

4. Specifying Third-Party API Integrations

CDD and EDD rely heavily on external data providers. The BA writes API integration requirements for:

• Biometric & ID Verification: (e.g., Onfido, Jumio, or SumSub).

• Sanctions & Adverse Media Screening: (e.g., Dow Jones, Refinitiv World-Check).

5. Facilitating User Acceptance Testing (UAT)

Before the system goes live, the BA creates test cases alongside the Quality Assurance (QA) team. The BA ensures that the compliance officers (the end-users) validate that the EDD portal successfully blocks, flags, and routes high-risk profiles correctly.

CDD vs. EDD: How the BA’s Focus Changes

When working on these systems, the BA must design distinctly different user journeys for CDD versus EDD:

System Aspect	Focus in CDD (Standard Risk)	Focus in EDD (High Risk)
Primary Goal	Maximize automation & speed. Frictionless onboarding (Straight-Through Processing).	Maximize risk mitigation & data collection. Introduce necessary friction.
Requirement Complexity	Simple ID/Address verification, automated API database checks.	Complex workflows requiring Source of Wealth (SoW) and UBO unwrapping.
User Interface (UI)	Minimal screens (Upload ID $\rightarrow$ Take Selfie).	Multi-step document upload portals and dynamic questionnaires.
Approval Mechanism	100% System Automated (Algorithm-driven).	Manual intervention; requires a queue for MLRO/Compliance Officer sign-off.

Real-World Scenario: Designing an EDD Escalation Workflow

Project Context: A Neo-Bank is experiencing regulatory fines because their standard CDD system is failing to catch Politically Exposed Persons (PEPs). The BA is hired to design an automated EDD escalation workflow.

The BA’s Execution Steps:

1. Define the Trigger: The BA specifies that if the API screening tool returns a >85% name match on a global PEP list during standard CDD, the system must immediately halt automation.

2. System Action (FRD Specification): The BA writes: “FR-01: Upon receiving a PEP alert, the system shall change the application status to ‘EDD Review’ and restrict all transactional capabilities.”

3. Internal UI Design: The BA designs wireframes for the internal Compliance Dashboard, ensuring the analyst can see the exact news article or database hit that triggered the PEP alert.

4. Audit Requirement: The BA ensures that when the compliance officer clicks “Approve” or “Reject,” the system captures their ID, the timestamp, and a mandatory text field for justification, satisfying regulatory audit requirements.

 

Frequently Asked Questions (FAQs)

In the financial services sector, the Business Analyst (BA) plays a vital role in translating complex Anti-Money Laundering (AML) and KYC regulations into functional software requirements for CDD (Customer Due Diligence) and EDD (Enhanced Due Diligence) systems.

BAs are responsible for designing automated risk-scoring engines, mapping onboarding workflows, specifying third-party API integrations for sanctions screening, and ensuring complete regulatory audit trails.

---

📄 Business Analysis Documentation Hub

Explore where CDD and EDD workflows fit into the broader business analysis and requirements engineering landscape:

Knowledge Area	Deep-Dive Article	Why It Matters for a Business Analyst
Domain Deep Dives (FinTech)	Enhanced Customer Due Diligence (EDD)	Understand the core definitions, compliance triggers, and corporate UBO structures required for high-risk clients.
Requirements Engineering	What is a Functional Requirement?	Learn how to write precise, testable system logic rules for automated KYC document approvals and EDD escalations.
Documentation & Artifacts	Business Analysis Templates & Examples	Access standard templates for BRDs and FRDs to document regulatory compliance workflows.
Software Lifecycles	Understanding the Spiral Life Cycle Model	Explore risk-driven SDLC frameworks commonly used to develop highly secure, heavily regulated banking platforms.
Agile & Delivery Metrics	Understanding Sprint Burndown Chart	Track engineering progress when building complex compliance engines over multiple Agile sprints.