Functional Requirements Catalog¶
Status: Draft — feeds the PRD. Organization: By bounded context. Every requirement has a unique ID, priority, and testable acceptance criteria. Priority: P0 = MVP must-have. P1 = post-MVP / v2. P2 = future.
1. Workflow Orchestration (Cross-Cutting)¶
FR-WF-01 — Configurable Workflow Templates¶
As a platform administrator, I want to define onboarding workflow templates without writing code, so that business lines can customize their onboarding process independently.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | Configuration Engine (FR-CF-01) |
| Acceptance Criteria | 1. Admin can define a workflow template via a configuration interface (not in source code). 2. Template definition includes: states, transitions, conditions, parallel branches, human task definitions, SLA timers. 3. Change to a template does not require platform restart. 4. Template version is stored and traceable. |
FR-WF-02 — Dynamic Branching¶
As a workflow designer, I want to define conditional branches based on runtime data, so that high-risk customers follow EDD paths and low-risk customers are fast-tracked.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | Risk Rating module (FR-RR-01) |
| Acceptance Criteria | 1. Branch condition can reference: risk score, screening result status, customer type, jurisdiction, document completeness. 2. IF/ELSE/ELSE IF logic supported. 3. Branch decision logged in audit trail with all evaluated conditions. |
FR-WF-03 — Parallel Task Execution¶
As a workflow designer, I want to define tasks that execute in parallel, so that screening, risk rating, and document validation can run simultaneously rather than sequentially.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | None |
| Acceptance Criteria | 1. Multiple tasks can be triggered simultaneously from a single state. 2. Workflow waits for ALL parallel tasks to complete before transitioning (or specified N-of-M). 3. Individual task failures do not block other parallel tasks. |
FR-WF-04 — Human Task Management¶
As a workflow designer, I want to insert human approval/review steps into automated workflows, so that critical decisions are made by accountable individuals.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | Case Management (FR-CM-01), RBAC (FR-SC-01) |
| Acceptance Criteria | 1. Human task appears in assigned user's queue. 2. Task has configurable form (approve/reject, provide rationale, upload evidence). 3. On completion, workflow resumes from the next state. 4. Task has SLA timer — breach triggers escalation. |
FR-WF-05 — SLA Timers and Breach Actions¶
As a supervisor, I want every human task to have a configurable deadline with automatic breach escalation, so that no case sits unattended past regulatory time limits.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | Notification Engine (FR-NT-01) |
| Acceptance Criteria | 1. Admin configures SLA duration per task type (e.g., "KYC review: 1 day"). 2. System sends reminders before breach (configurable: 50%, 75%, 90% of SLA). 3. On breach: task escalates to supervisor queue. 4. SLA timers pause when waiting for customer (WAITING_EXTERNAL state). |
FR-WF-06 — Retry and Error Handling¶
As a platform operator, I want failed module invocations to retry automatically, so that transient failures do not block entire workflows.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | None |
| Acceptance Criteria | 1. Configurable retry count per module type. 2. Configurable backoff strategy (fixed, exponential). 3. On all retries exhausted: workflow transitions to error state, task assigned to operator. 4. Original and retry attempts logged in audit trail. |
FR-WF-07 — Workflow Instance State Machine¶
As a system architect, I want every workflow instance to follow a well-defined state machine, so that its lifecycle is predictable and auditable.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | None |
| Acceptance Criteria | 1. States: NEW, INTAKE, DATA_COLLECTION, DOCUMENT_COLLECTION, VALIDATION_PENDING, SCREENING_PENDING, RISK_ASSESSMENT_PENDING, ANALYST_REVIEW, EDD_REVIEW, COMPLIANCE_APPROVAL, APPROVED, REJECTED, CLOSED, ON_HOLD, WAITING_EXTERNAL. 2. Every state transition logged. 3. Invalid transition attempts blocked and logged. |
2. Customer Onboarding¶
FR-ON-01 — Application Intake¶
As a relationship manager, I want to submit a new customer onboarding application, so that the onboarding process can begin.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | Workflow Engine (FR-WF-01) |
| Acceptance Criteria | 1. RM fills intake form: customer name, type (individual/corporate), jurisdiction, product interest, expected activity. 2. RM can attach initial documents. 3. On submit: system auto-classifies customer type and selects workflow template. 4. Confirmation returned with application reference ID. |
FR-ON-02 — Customer Classification¶
As a system, I want to classify customers into archetypes based on intake data, so that the correct workflow template and document requirements are applied.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | Configuration Engine (FR-CF-01) |
| Acceptance Criteria | 1. Classification uses: customer type (individual/legal entity), jurisdiction, business line, product. 2. Supported archetypes: Retail Individual, SME, Corporate, Correspondent Banking, Private Banking, Leasing/Specialized. 3. If classification ambiguous, human task created for Onboarding Specialist. 4. Classification decision logged with input data and selected archetype. |
FR-ON-03 — Document Requirements Engine¶
As a platform administrator, I want to configure mandatory and optional documents per customer archetype and jurisdiction, so that each customer type has the right evidence requirements.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | Configuration Engine (FR-CF-01) |
| Acceptance Criteria | 1. Admin defines document types per archetype (e.g., "Corporate — Netherlands" requires: chamber registration, incorporation certificate, shareholder register, director IDs, UBO declaration). 2. Document marked as mandatory or optional. 3. Workflow blocks progression until all mandatory documents validated. 4. Expired documents flagged (e.g., passport expired). |
FR-ON-04 — Identity Validation¶
As a KYC analyst, I want the platform to validate customer identity automatically where possible, so that I only review exceptions.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | External identity verification provider |
| Acceptance Criteria | 1. Individual: name + DOB + document number validated against identity provider. 2. Legal entity: registration number + incorporation country validated against corporate registry. 3. Result: VERIFIED / MISMATCH / UNAVAILABLE. 4. MISMATCH creates analyst task. UNAVAILABLE marks for manual verification. |
FR-ON-05 — UBO Identification¶
As a KYC analyst, I want to capture and verify the ultimate beneficial ownership structure, so that hidden ownership risk is surfaced.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | Network Analysis (FR-NA-01) |
| Acceptance Criteria | 1. Analyst can input ownership: parent entity → child entity with ownership %. 2. System flags when total declared ownership < 100%. 3. System flags when intermediate entities prevent UBO identification. 4. UBO threshold configurable (default: 25%). 5. Ownership structure visualized as graph. |
FR-ON-06 — Onboarding Decision¶
As a FCC reviewer, I want to record a formal acceptance decision with rationale, so that the institution's risk acceptance is documented and auditable.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | Audit (FR-AU-01) |
| Acceptance Criteria | 1. Possible decisions: APPROVED, APPROVED_WITH_RESTRICTIONS, APPROVED_PENDING_EDD, REJECTED, WITHDRAWN, PROHIBITED. 2. Each decision requires rationale (mandatory field). 3. APPROVED_WITH_RESTRICTIONS requires restriction description. 4. Decision logged with actor, timestamp, config version, and evidence references. |
3. Name Screening¶
FR-NS-01 — Match Against Watchlists¶
As a compliance officer, I want the platform to screen customer names against sanctions, PEP, and internal watchlists, so that prohibited individuals are detected before account opening.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | External sanctions/PEP data providers |
| Acceptance Criteria | 1. Screens against: sanctions lists (OFAC, EU, UN, local), PEP lists, internal watchlists. 2. Input: full name, aliases, DOB, nationality, identifiers. 3. Output: match status (NO_MATCH, POTENTIAL_MATCH, CONFIRMED_MATCH) + confidence score + matched list entry details. |
FR-NS-02 — Matching Algorithms¶
As a system architect, I want the screening module to support exact and fuzzy matching, so that both obvious hits and close variations are caught.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | None |
| Acceptance Criteria | 1. Exact match: name identical (case-insensitive, whitespace-normalized). 2. Fuzzy match: name similarity ≥ configurable threshold using edit distance/phonetic algorithm. 3. Alias matching: all known aliases checked against all list entry aliases. 4. Transliteration support: Latin-alphabet variants matched (P1 for non-Latin scripts). |
FR-NS-03 — Analyst Adjudication¶
As a sanctions analyst, I want to review potential screening matches and adjudicate them, so that false positives are cleared and true hits are escalated.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | Case Management (FR-CM-01) |
| Acceptance Criteria | 1. POTENTIAL_MATCH creates a task in the sanctions analyst queue. 2. Analyst sees: matched name, list details, customer details, similarity score. 3. Actions: CLEAR (false positive — requires rationale), CONFIRM (true hit — escalates), REQUEST_INFO (asks for more data). 4. All adjudications logged with full context. |
4. Customer Risk Rating¶
FR-RR-01 — Rules-Based Scoring Engine¶
As a compliance officer, I want the platform to calculate customer risk scores using configurable rules, so that risk classification is consistent, explainable, and adjustable without code.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | Configuration Engine (FR-CF-01) |
| Acceptance Criteria | 1. Risk factors configurable: geography risk, customer type risk, ownership complexity, PEP exposure, product risk, industry risk. 2. Each factor contributes a weighted score. 3. Output: numeric score + risk band (LOW / MEDIUM / HIGH). 4. Thresholds configurable (e.g., score < 30 = LOW, 30-60 = MEDIUM, > 60 = HIGH). 5. Every contributing factor and its weight traceable in output. |
FR-RR-02 — Risk Rating Traceability¶
As an auditor, I want to see exactly why a customer received a specific risk rating, so that the rating is defensible under regulatory review.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | Audit (FR-AU-01) |
| Acceptance Criteria | 1. Risk rating output includes: methodology version, all factors evaluated, each factor's score, total score, band, threshold limits. 2. "Show rationale" button in UI expands to full factor breakdown. 3. Rating stored immutably — subsequent re-ratings create new records, not overwrites. |
FR-RR-03 — Risk-Based Routing¶
As a workflow designer, I want to route high-risk customers to EDD automatically, so that enhanced scrutiny is applied consistently.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | Workflow Engine (FR-WF-02) |
| Acceptance Criteria | 1. HIGH risk band → workflow branches to EDD path. 2. MEDIUM → workflow proceeds to analyst review. 3. LOW → fast-track (skip or shorten analyst review). 4. Routing rules configurable per business line. |
5. Case Management¶
FR-CM-01 — Case Lifecycle¶
As a case manager, I want every investigation to follow a structured lifecycle, so that cases are never lost or forgotten.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | Workflow Engine (FR-WF-01) |
| Acceptance Criteria | 1. States: CREATED → ASSIGNED → IN_PROGRESS → PENDING_REVIEW → ESCALATED → DECIDED → CLOSED. 2. All state transitions logged with timestamp and actor. 3. Case cannot be closed without a decision. |
FR-CM-02 — Queue Management¶
As a supervisor, I want to view and manage my team's case queues, so that I can balance workload and prevent SLA breaches.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | RBAC (FR-SC-01) |
| Acceptance Criteria | 1. Supervisor sees: cases per analyst, aging cases, SLA status, case types. 2. Filter by: analyst, case type, priority, status, age. 3. Reassign case: transfers to another analyst with full context. 4. Bulk reassignment supported. 5. Reassignment logged in audit trail. |
FR-CM-03 — Evidence and Notes¶
As an analyst, I want to attach evidence and write case notes, so that my investigation is documented for future review.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | None |
| Acceptance Criteria | 1. Upload documents/evidence to case. 2. Write notes — append-only (no editing or deleting previous notes). 3. Each note timestamped and attributed to author. 4. Notes visible in chronological timeline view. |
FR-CM-04 — Analyst Workspace¶
As an analyst, I want a single-pane workspace showing everything I need for investigation, so that I don't switch between multiple screens.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | All integrated modules |
| Acceptance Criteria | 1. Workspace shows: customer profile, alert/risk summary, screening results, ownership graph, document panel, notes timeline, decision panel. 2. All panels update in real-time as investigation progresses. 3. Analyst can take action (approve, escalate, request info) from within workspace. |
FR-CM-05 — Escalation Routing¶
As a workflow designer, I want to define configurable escalation paths, so that cases reach the right person at the right level.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | Configuration Engine (FR-CF-01), RBAC (FR-SC-01) |
| Acceptance Criteria | 1. 5-level escalation: L1 (analyst) → L2 (senior) → L3 (EDD) → L4 (compliance) → L5 (executive). 2. Configurable triggers per level (risk score, sanctions hit, PEP, missing docs, analyst request). 3. Routing rules: by business line, jurisdiction, alert type, workload, analyst skill. 4. Escalation chain preserved in audit trail. |
6. Network Analysis¶
FR-NA-01 — Ownership Graph¶
As a KYC analyst, I want to visualize the customer's ownership structure as a graph, so that I can quickly understand complex ownership chains.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | Customer data (FR-ON-05) |
| Acceptance Criteria | 1. Visual graph: parent → child nodes with ownership percentages on edges. 2. Supports multi-level chains (A owns B owns C). 3. Nodes color-coded: customer (blue), UBO (green), intermediate entity (gray), unknown (red). 4. Click a node to see entity details. |
FR-NA-02 — Linked Entity Discovery¶
As a KYC analyst, I want the platform to discover entities linked through shared attributes, so that hidden connections are surfaced.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | None |
| Acceptance Criteria | 1. Discovers links via: shared director, shared address, shared phone/email, shared registration agent. 2. Links shown as dashed edges in graph. 3. Analyst can confirm or dismiss discovered links. |
7. Configuration Engine¶
FR-CF-01 — Workflow Configuration¶
As a platform administrator, I want to create and modify workflow definitions without code deployment, so that business process changes are fast and safe.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | None |
| Acceptance Criteria | 1. Admin UI for workflow definition: states, transitions, conditions, tasks, SLA timers. 2. Save creates new version (immutable — previous versions preserved). 3. Promote version through environments: DRAFT → TEST → PROD. 4. Running workflow instances continue on their original version. |
FR-CF-02 — Threshold and Rule Configuration¶
As a compliance officer, I want to configure risk thresholds, approval rules, and document requirements, so that the platform adapts to policy changes without developer involvement.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | None |
| Acceptance Criteria | 1. Configure risk score thresholds (LOW/MEDIUM/HIGH boundaries). 2. Configure approval matrices (who approves what type of decision at what level). 3. Configure document requirements per customer type and jurisdiction. 4. All changes versioned and auditable. |
FR-CF-03 — Versioning and Rollback¶
As a platform administrator, I want to version all configurations and roll back if needed, so that bad changes don't cause compliance failures.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | Audit (FR-AU-01) |
| Acceptance Criteria | 1. Every config change creates a new immutable version. 2. Version history viewable: who changed what when. 3. Rollback: reverts active config to a previous version. 4. Rollback itself is a versioned change (creates new version). |
8. Audit & Governance¶
FR-AU-01 — Immutable Audit Log¶
As a regulator, I want every system action to be recorded in an immutable log, so that I can reconstruct any decision from any point in time.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | None |
| Acceptance Criteria | 1. Every workflow state transition logged. 2. Every module invocation logged (request + response + config version). 3. Every human decision logged (who, what, when, rationale). 4. Every configuration change logged. 5. Every data access logged (P1). 6. Log is append-only — no updates, no deletes. 7. Log entries have unique sequential IDs. |
FR-AU-02 — Decision Reconstruction¶
As an auditor, I want to replay the exact sequence of events that led to a decision, so that I can verify the process was followed correctly.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | FR-AU-01 |
| Acceptance Criteria | 1. Given a case ID or customer ID, auditor can view the full event timeline. 2. Timeline shows: every state transition, every module invocation with inputs/outputs, every human action. 3. Auditor can verify: which config version was active, which policies applied, which data sources were used. 4. Export audit package as PDF/JSON for regulatory submission. |
FR-AU-03 — Segregation of Duties¶
As a compliance officer, I want the platform to enforce segregation of duties, so that no single person can both investigate and approve their own work.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | RBAC (FR-SC-01) |
| Acceptance Criteria | 1. Case creator cannot approve the case. 2. Analyst who investigated cannot be the FCC reviewer. 3. Auditor role has read-only access. 4. Violation attempts are logged and blocked. 5. Override requires secondary approval with documented rationale. |
9. RBAC & Security¶
FR-SC-01 — Role-Based Access Control¶
As a security administrator, I want to assign roles that control what users can see and do, so that access follows the principle of least privilege.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | None |
| Acceptance Criteria | 1. Predefined roles: RM, Onboarding Specialist, KYC Analyst, Sanctions Analyst, EDD Analyst, FCC Reviewer, Supervisor, Auditor, Admin. 2. Each role has a set of permitted actions. 3. Admin can create custom roles. 4. Access denied returns clear error (not a crash or blank screen). |
FR-SC-02 — Authentication¶
As a user, I want to log in securely, so that only authorized users access the platform.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | None |
| Acceptance Criteria | 1. Username + password authentication. 2. Session timeout after configurable idle period. 3. Failed login attempts logged. 4. Account lockout after N failed attempts (configurable). 5. MFA support (P1 — SSO integration). |
10. Notification & Communication¶
FR-NT-01 — Notifications¶
As a user, I want to receive notifications about tasks assigned to me and SLA warnings, so that I never miss a deadline.
| Attribute | Detail |
|---|---|
| Priority | P0 |
| Dependencies | None |
| Acceptance Criteria | 1. In-platform notifications (bell icon with badge count). 2. Notification types: task assigned, SLA warning, escalation, case status change. 3. Notifications persist until acknowledged. 4. (P1) Email notifications for offline users. |
11. Requirement Summary by Priority¶
| Domain | P0 Count | P1 Count | Total |
|---|---|---|---|
| Workflow Orchestration | 7 | 0 | 7 |
| Customer Onboarding | 6 | 0 | 6 |
| Name Screening | 3 | 0 | 3 |
| Customer Risk Rating | 3 | 0 | 3 |
| Case Management | 5 | 0 | 5 |
| Network Analysis | 2 | 0 | 2 |
| Configuration Engine | 3 | 0 | 3 |
| Audit & Governance | 3 | 0 | 3 |
| RBAC & Security | 2 | 0 | 2 |
| Notification | 1 | 0 | 1 |
| Total | 35 | 0 | 35 |
Note: All MVP requirements are P0. P1 requirements will be added during v2 planning. This catalog focuses on the MVP surface because the PRD needs to nail the minimum scope before expanding.
12. Requirement Dependencies Graph¶
flowchart LR
CF[Configuration Engine] --> WF[Workflow Engine]
WF --> RR[Risk Rating]
WF --> NS[Name Screening]
CF --> RR
CF --> NS
CF --> NA[Network Analysis]
WF --> NA
WF --> CM[Case Management]
RR --> CM
NS --> CM
NA --> CM
CM --> AU[Audit<br/>ALL modules log]
CM --> RBAC[RBAC<br/>ALL modules check]Critical path: Configuration Engine must be built first, then Workflow Engine. All other modules depend on these two.
Catalog derived from: Requirements Inventory §3, Onboarding Spec §12, Blueprint §5/§7, Engineering Spec §7-13.