Product Requirements Document¶

Enterprise Financial Economic Crime (FEC) Operating Platform¶

Version: 1.0 — Draft
Date: 2025-05-24
Status: Draft — For Review

Document History¶

Version	Date	Author	Changes	Impact on Downstream Docs
1.0	2025-05-24	—	Initial draft	Architecture, domain specs, implementation plan must be validated against this version

Traceability: See Traceability Matrix for the full mapping of PRD requirements → architecture decisions → domain specs → implementation tasks.

Executive Summary¶

The Enterprise FEC Platform is a configurable, modular, audit-grade operating platform for financial crime operations. It replaces fragmented compliance tooling with a unified environment where customer onboarding, screening, risk rating, and investigations are orchestrated as governed processes — not isolated applications.

The Problem¶

Financial institutions today operate with fragmented FEC environments: separate onboarding systems, disconnected screening tools, isolated transaction monitoring, and manual escalations. This creates excessive cost, weak auditability, inconsistent decision-making, and regulatory exposure.

The Solution¶

A unified platform where:

Processes orchestrate work — configurable workflows drive every FEC journey
Decision modules provide intelligence — screening, risk rating, network analysis as pluggable modules
Governance ensures control — immutable audit trail, segregation of duties, config versioning

MVP Scope¶

The MVP delivers one process end-to-end (customer onboarding) powered by three intelligence modules (name screening, risk rating, network analysis), governed by a configuration engine and immutable audit trail. This proves the "Operating System" thesis: if one process works with all architectural properties, the model scales to all processes.

Key Decisions¶

Decision	Rationale
Modular monolith, not microservices	Avoid distributed complexity before business value exists
Configuration over code	Business policy changes must not require deployment
Human-in-the-loop	No autonomous irreversible decisions in MVP
Audit-first architecture	Build audit from day one — retrofitting is impossible
One process in MVP	Depth over breadth. Prove the model, then scale.

1. Product Vision¶

1.1 What We're Building¶

A Financial Crime Operating System — not an AML application, not a sanctions tool, not a workflow product.

The platform enables financial institutions to design, execute, monitor, and govern financial crime workflows using configurable processes and pluggable intelligence modules. Business policy changes happen through configuration, not code deployment.

1.2 Core Design Principles¶

Principle	What It Means
Configuration over Code	Workflows, thresholds, approval rules, document requirements change without deployment
Modular Intelligence	Screening, risk rating, network analysis — each a pluggable module with a standard contract
Human-in-the-Loop	System assists analysts. Does not replace accountable decision-makers
Auditability by Design	Every decision reconstructable: who, what, when, why, which config, which inputs
API-First	UI consumes APIs. No business logic hidden in the frontend
Proportional Risk Treatment	Low-risk customers experience low friction. High-risk customers get deep scrutiny

1.3 What the Platform IS and IS NOT¶

IS	IS NOT
Configurable operating system for FEC processes	A point solution for one FEC function
Workflow orchestration with modular intelligence	A hardcoded process engine
Case management system for analysts	A CRM or customer service tool
Audit-grade, regulator-ready	A prototype or proof-of-concept
Institution-agnostic (configurable)	Hardcoded for one institution

2. Strategic Context¶

2.1 Business Drivers¶

Financial institutions face increasing regulatory, operational, and criminal complexity. Traditional FEC environments suffer from:

Fragmentation: Separate systems for onboarding, screening, monitoring, investigations
Duplication: Same customer reviewed multiple times across different tools
Inconsistency: Different business lines making different decisions for the same risk
Weak auditability: Cannot reconstruct past decisions end-to-end
Poor efficiency: Manual handoffs, repetitive data entry, no workload visibility

2.2 Strategic Goals¶

Goal	Measured By
Prevent onboarding of prohibited entities	Zero sanctions violations from onboarding misses
Comply with AML/CTF obligations	Audit pass rate on regulatory inspections
Assign risk-based controls proportionally	Correlation between risk band and scrutiny applied
Ensure consistent decision-making	Decision variance across analysts for same-type cases
Support auditability and regulatory review	Time to reconstruct any decision from 5 years ago
Reduce onboarding cycle time	Median time from intake to decision
Improve analyst productivity	Cases processed per analyst per day

2.3 Long-Term Vision¶

The MVP establishes the platform foundation. Post-MVP expansion (directional, not committed):

v2: Transaction monitoring, periodic review, event-driven review, SAR filing prep
v3: Transaction screening, ML-based alert prioritization, advanced graph intelligence
v4+: Fraud modules, AI copilots, multi-jurisdiction engines, customer self-service

3. MVP Definition & Scope¶

3.1 The MVP Thesis¶

If we build one process (customer onboarding) with full architectural integrity — configurable workflows, pluggable intelligence, immutable audit, RBAC — we prove the platform model. Multiple shallow processes prove nothing.

3.2 In Scope: 7 Capabilities¶

#	Capability	What MVP Delivers
1	Workflow Orchestration	Configurable onboarding templates, dynamic branching, parallel execution, human tasks, SLA timers, retry logic
2	Customer Onboarding	Full lifecycle: intake → classification → data capture → document collection → screening → risk rating → network check → analyst review → EDD → compliance approval → decision
3	Name Screening	Exact + fuzzy matching against sanctions and PEP lists. Analyst adjudication workflow for potential matches
4	Customer Risk Rating	Rules-based scoring engine. Low/Medium/High bands. Configurable factors and thresholds. Full rationale traceability
5	Network Analysis	Ownership graph visualization. Linked entity discovery (shared directors, addresses, identifiers). Basic relationship traversal
6	Case Management	Case lifecycle: created → assigned → investigating → escalated → decided → closed. Queue management. Append-only notes. Evidence attachments. Single-pane analyst workspace
7	Audit & Governance	Immutable append-only audit log. Deterministic replay. Segregation of duties enforcement. Config versioning with rollback

3.3 Out of Scope (Deferred)¶

Capability	Why Not MVP	Target
Transaction Monitoring	Requires event ingestion pipeline, real transaction data	v2
Transaction Screening	Real-time payment controls — separate infrastructure	v2
SAR/STR Filing	Depends on transaction monitoring	v2+
Fraud Modules	Separate domain, different detection models	v3+
ML Models	Premature without operational data. Rules-based is sufficient	v2+
AI Copilots / NLP	Requires stable platform + LLM governance	v3+
Periodic / Event-Driven Review	Important but not the proving process	v2
Multi-Jurisdiction Engine	Start with one jurisdiction, generalize after	v2+

3.4 Customer Archetypes — All Supported via Configuration¶

Archetype	In MVP?	Approach
Retail Individual	✅	Fast-track, low friction
SME	✅	Moderate complexity
Corporate	✅	The proving case — complex ownership, UBO transparency
Correspondent Banking	✅	Highest complexity, deep EDD
Private Banking	✅	Wealth scrutiny, PEP sensitivity
Leasing / Specialized	✅	Configurable template

3.5 Integration Surface (MVP Minimum)¶

Must integrate (P0): Sanctions list providers, PEP list providers, at least one corporate registry, identity verification provider
Should integrate (P1): Document repository, SSO/identity provider
Out of scope: CRM, core banking systems, payment switch

4. Users & Stakeholders¶

4.1 Human Roles¶

Role	Primary Responsibility	Daily Volume
Relationship Manager	Initiate onboarding, provide business context, communicate with customer	Multiple initiations/day
Onboarding Specialist	Intake review, document coordination, workflow initiation	10–30 reviews/day
KYC Analyst	Identity verification, ownership validation, document review	5–15 reviews/day
Sanctions Analyst	Screening adjudication, true hit confirmation	5–20 alerts/day
EDD Analyst	Deep due diligence, ownership complexity, source of wealth	1–5 deep dives/week
FCC Reviewer	High-risk approvals, policy exceptions, sanctions governance	1–3 approvals/day
Supervisor	Workload balancing, SLA monitoring, escalation handling	Continuous + 2–5 interventions/day
Auditor	Process verification, control assurance, audit reconstruction	Periodic (weekly/monthly)

4.2 System Personas¶

The platform must also behave as if these automated actors exist:

Workflow Engine — drives process states, routes tasks, enforces SLAs
Name Screening Engine — matches against watchlists
Risk Rating Engine — calculates risk scores
Network Analysis Engine — maps ownership and relationships
Configuration Engine — serves active config to all modules
Audit Service — records every event immutably
Notification Engine — sends reminders, escalations, updates

5. Core Journeys¶

5.1 Journey 1: Corporate Customer Onboarding (The Proving Case)¶

Full path: RM submits application → Onboarding Specialist reviews intake → Parallel: screening + risk rating + doc validation + network analysis → Sanctions Analyst adjudicates potential PEP match → KYC Analyst verifies ownership structure → Risk Rating returns HIGH → EDD Analyst conducts deep due diligence → FCC Reviewer approves with conditions → Customer activated → Full audit trail complete.

This journey validates: workflow orchestration, parallel execution, screening adjudication, risk-based branching, ownership graph, document management, EDD escalation, approval controls, immutable audit.

5.2 Journey 2: Retail Customer Fast-Track¶

Low-risk individual. Automated classification → automated screening (no match) → automated risk rating (LOW) → no analyst review required → Onboarding Specialist approves. Total time: < 30 minutes.

Validates: fast-track routing, low-friction UX, proportional risk treatment.

5.3 Journey 3: Sanctions True Hit¶

Screening returns confirmed OFAC match. Case automatically frozen. Sanctions Analyst confirms. FCC Reviewer + Legal review. Decision: PROHIBITED. Customer locked.

Validates: critical escalation, automated blocking, sanctions governance.

5.4 Journey 4: Supervisor Workload Management¶

Supervisor sees team dashboard: 3 analysts overloaded, 1 case approaching SLA breach. Reassigns case. Workload balanced. SLA risk resolved.

Validates: queue management, reassignment, dashboard visibility.

6. Functional Requirements¶

35 P0 requirements across 10 domains. Each requirement has a unique ID (FR-XX-NN), priority, dependencies, and testable acceptance criteria.

6.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.

6.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.

6.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.

6.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.

6.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.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.

6.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).

6.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.

6.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).

6.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.

6.11 Requirement Summary¶

Domain	P0 Count
Workflow Orchestration	7
Customer Onboarding	6
Name Screening	3
Customer Risk Rating	3
Case Management	5
Network Analysis	2
Configuration Engine	3
Audit & Governance	3
RBAC & Security	2
Notification	1
Total	35

6.12 Critical Path Dependencies¶

Configuration Engine → Workflow Engine → All Other Modules → Case Management → RBAC → Audit (cross-cutting)

The Configuration Engine must be built first because every other module depends on it for rules, thresholds, and templates.

7. Non-Functional Requirements¶

31 measurable NFRs across 8 categories. Every NFR has a specific metric and measurement method — no vague "should be fast" statements.

7.1 Performance & Scalability¶

NFR-P01 — UI Responsiveness¶

Requirement: Any page in the analyst workspace must render within 2 seconds (p95) under normal load (up to 50 concurrent analysts).

Measurement: Lighthouse / Web Vitals on key pages: case list, case detail, analyst workspace.

Rationale: Analysts spend their entire day in the platform. Sub-2-second interactions prevent fatigue and maintain workflow momentum.

NFR-P02 — Screening Response Time¶

Requirement: Name screening against external watchlists must return a result within 5 seconds (p95).

Measurement: Timed from module invocation to response received by workflow engine.

Rationale: Screening happens during onboarding — the customer (or RM) is waiting. 5 seconds is an acceptable pause; longer feels like a system hang.

NFR-P03 — Concurrent Workflow Execution¶

Requirement: The platform must support at least 100 concurrent workflow instances (onboarding cases in progress simultaneously) without degradation.

Measurement: Load test with 100 parallel onboarding workflows, each with screening, risk rating, and network analysis invocations. No API timeout failures.

Rationale: A mid-size compliance team of 8-12 analysts processes dozens of cases simultaneously. 100 concurrent provides comfortable headroom for MVP.

NFR-P04 — Audit Log Write Throughput¶

Requirement: The audit log must sustain at least 1,000 events per second write throughput.

Measurement: Load test with burst of audit events. No event loss; no write timeouts.

Rationale: Every module invocation, state transition, and user action generates at least one audit event. A complex corporate onboarding with parallel tasks can generate 50+ events in seconds.

7.2 Security¶

NFR-S01 — Encryption in Transit¶

Requirement: All communication between client and server, and between internal services, must use TLS 1.2 or higher. HTTP must redirect to HTTPS.

Measurement: TLS certificate validation. Penetration test confirms no unencrypted endpoints.

NFR-S02 — Encryption at Rest¶

Requirement: All persistent data (database, file storage, audit logs) must be encrypted at rest using AES-256 or equivalent.

Measurement: Verify encryption enabled at storage layer. Key management documented.

NFR-S03 — Authentication Strength¶

Requirement: Password policy must enforce: minimum 12 characters, at least one uppercase, one lowercase, one digit, one special character. Passwords must not be in common password lists.

Measurement: Policy enforced at registration and password change. Integration test verifies breached-password rejection.

NFR-S04 — Session Security¶

Requirement: User sessions must expire after 30 minutes of inactivity. Authentication tokens must expire after 8 hours (maximum workday). Failed login attempts lock account after 5 failures for 15 minutes.

Measurement: Integration tests verify session timeout and lockout behavior.

NFR-S05 — Field-Level Access Control¶

Requirement: Sensitive fields (date of birth, identification numbers, PEP status) must be maskable per role. The Auditor role must see all fields; the Supervisor role should not see DOB or ID numbers unless actively investigating.

Measurement: Role-based field visibility matrix tested for every role.

NFR-S06 — Privileged Access Monitoring¶

Requirement: Any access to sensitive customer data by Admin or privileged roles must generate an audit event with: who accessed, what data, when, and from which IP.

Measurement: Audit log search confirms privileged access events are recorded.

7.3 Reliability & Availability¶

NFR-R01 — System Uptime¶

Requirement: The platform must achieve 99.5% uptime during business hours (8am-8pm, local time, weekdays). Planned maintenance excluded.

Measurement: Uptime monitoring with 1-minute health check interval.

Rationale: 99.5% means ~30 minutes of acceptable downtime per week. Higher availability (99.9%+) is post-MVP. MVP is single-deployment — don't overpromise.

NFR-R02 — Graceful Degradation¶

Requirement: If an external service (sanctions list provider, corporate registry) is unavailable, the workflow must not fail. Instead: mark the dependent task as BLOCKED, notify the operator, and allow the workflow to continue on other parallel tracks. When the service recovers, retry the blocked task.

Measurement: Integration test with mocked external service downtime.

NFR-R03 — Data Durability¶

Requirement: Once an audit event is written to the log, it must survive system restarts, crashes, and power loss. No audit events may be lost.

Measurement: Kill process mid-write. Restart. Verify no missing or corrupted audit events.

NFR-R04 — Retry with Backoff¶

Requirement: Transient failures (network timeout, database deadlock) must retry up to 3 times with exponential backoff (1s, 2s, 4s). On final exhaustion, the task enters error state with operator notification.

Measurement: Integration test injects transient failures; verifies retry behavior and final state.

7.4 Observability¶

NFR-O01 — Structured Logging¶

Requirement: All log entries must be structured (JSON format) and include: timestamp, service name, correlation ID, log level, message, and context.

Measurement: Sample log output verified as valid JSON with required fields.

NFR-O02 — Correlation IDs¶

Requirement: Every API request must receive a unique correlation ID. This ID must propagate through all downstream service calls and appear in all log entries and audit events for that request.

Measurement: Trace a request from API gateway → workflow engine → screening module → audit log. All entries share the same correlation ID.

NFR-O03 — Health Check¶

Requirement: Every service must expose a /health endpoint returning: service status (UP/DOWN), database connectivity, external service status, uptime.

Measurement: Health endpoint returns 200 with expected body.

NFR-O04 — Key Metrics¶

Requirement: The platform must expose: active workflow count, cases per status, average case age, SLA breach count (last 24h), screening requests per minute, error rate.

Measurement: Metrics endpoint or dashboard confirms all metrics available.

7.5 Usability¶

NFR-U01 — Low Click Count¶

Requirement: Common analyst tasks must not exceed 5 clicks from the case list to completion:

Approve a low-risk case: ≤ 3 clicks
Escalate a case: ≤ 2 clicks
Request additional document: ≤ 3 clicks

Measurement: Usability test with sample analyst workflows. Count clicks.

NFR-U02 — Error Messages¶

Requirement: All error messages must include: (1) what went wrong in plain language, (2) what the user can do about it, (3) a reference ID for support. No stack traces in the UI.

Measurement: Review every error path. No raw exception text visible to end users.

NFR-U03 — Loading States¶

Requirement: Every action that takes > 300ms must show a loading indicator (spinner, skeleton, or progress bar). Actions that complete in < 300ms may skip it.

Measurement: UI audit confirms no "dead clicks" — every button provides feedback within 300ms.

Requirement: (Post-MVP) Key analyst actions must be keyboard-accessible: navigate case list (↑↓), open case (Enter), approve (Ctrl+Enter), reject (Ctrl+Backspace).

7.6 Maintainability¶

NFR-M01 — Modular Architecture¶

Requirement: Each bounded context (onboarding, screening, risk rating, case management, etc.) must be a separate module with a clearly defined interface. Modules must not import from each other's internals.

Measurement: Architecture review. Dependency graph shows no circular dependencies between modules. Internal packages are not exported.

NFR-M02 — Configuration Over Code¶

Requirement: Business rule changes (thresholds, document requirements, approval matrices, workflow templates) must be changeable via the configuration engine without code deployment. Only infrastructure changes and new module capabilities require deployment.

Measurement: Demonstrate: change a risk threshold → active immediately in production without restart.

NFR-M03 — API Versioning¶

Requirement: All REST APIs must be versioned (e.g., /api/v1/onboarding). Breaking changes require a new version. Old versions supported for at least one release cycle.

Measurement: API changelog. Integration tests for both current and previous version.

NFR-M04 — Test Coverage¶

Requirement: Business logic must have ≥ 80% line coverage. Critical paths (onboarding flow, screening matching, risk scoring) must have ≥ 90% branch coverage.

Measurement: Coverage report from CI pipeline.

7.7 Compliance & Data Retention¶

NFR-C01 — Audit Retention¶

Requirement: All audit events must be retained for a minimum of 7 years from the date of creation. After 7 years, events may be archived to cold storage but must remain retrievable within 30 days.

Measurement: Verify oldest retained event is not automatically deleted before 7-year mark.

NFR-C02 — Decision Reproducibility¶

Requirement: For any decision made in the last 7 years, an auditor must be able to reconstruct: the exact inputs, the config version active, the modules invoked and their outputs, the actor, the timestamp, and the rationale — within 5 minutes of search.

Measurement: Timed audit exercise: pick a random case from 3 years ago, auditor searches and reconstructs. Must complete within 5 minutes.

NFR-C03 — Data Minimization¶

Requirement: The platform must not collect or store personal data beyond what is required for the KYC/CDD process. Document storage must have configurable retention — after customer offboarding, documents must be deletable per policy.

Measurement: Data inventory audit. No unnecessary PII fields.

NFR-C04 — Right to Access / Right to Erasure¶

Requirement: (P1 — when GDPR-applicable jurisdiction supported) The platform must support exporting all data for a given customer in a machine-readable format, and deleting all personal data on request, while preserving anonymized audit trail.

7.8 API Standards¶

NFR-A01 — Consistent API Design¶

Requirement: All REST APIs must follow these conventions:

Resource names: plural nouns (/cases, /customers)
HTTP methods: GET (read), POST (create), PUT (full update), PATCH (partial update), DELETE (remove)
Pagination: ?page=1&limit=50 with Link header for next/prev
Error responses: { "error": { "code": "CASE_NOT_FOUND", "message": "...", "refId": "abc-123" } }
Idempotency: POST/PUT/PATCH accept Idempotency-Key header

Measurement: OpenAPI spec validates all endpoints. Linter enforces conventions.

NFR-A02 — Rate Limiting¶

Requirement: API endpoints must enforce rate limits. Default: 100 requests per minute per user. Screening endpoints: 20 requests per minute (external service cost control).

Measurement: Load test exceeds rate limit. Verify 429 response with Retry-After header.

7.9 NFR Summary¶

Category	Count	Key Metric
Performance & Scalability	4	2s UI, 5s screening, 100 concurrent workflows, 1K audit events/sec
Security	6	TLS 1.2+, AES-256, 12-char passwords, 30min session, field-level masking
Reliability & Availability	4	99.5% uptime, graceful degradation, retry with exponential backoff
Observability	4	JSON structured logs, correlation IDs, health checks, metrics
Usability	4	≤5 clicks, plain-language errors, loading states, keyboard nav (P1)
Maintainability	4	Modular architecture, config-over-code, API versioning, 80% coverage
Compliance & Retention	4	7-year audit retention, 5-min reconstruction, data minimization
API Standards	2	Consistent REST conventions, rate limiting
Total	32

8. Integration Surface¶

8.1 Internal Integrations¶

From	To	Trigger
Onboarding Workflow →	Name Screening	At screening step
Onboarding Workflow →	Risk Rating	At risk assessment step
Onboarding Workflow →	Network Analysis	Conditional on ownership complexity
All Modules →	Audit Service	Every state transition, decision, invocation
All Modules →	Configuration Engine	At module invocation (get active config)

8.2 External Integrations (P0 — MVP Must-Have)¶

Integration	Purpose	Contract
Sanctions List Provider	Name screening data source (OFAC, EU, UN)	HTTP REST, batch list download + incremental updates
PEP List Provider	PEP detection	HTTP REST, similar contract
Corporate Registry	Legal entity verification	HTTP REST, lookup by registration number
Identity Verification Provider	Individual identity validation	HTTP REST, document + biometric verification

8.3 External Integration Pattern¶

All external integrations must be abstracted behind interfaces so providers can be swapped without changing business logic:

[Module] → [Provider Interface] → [Provider Adapter] → [External Service]
                                         ↳ [Mock Adapter] (for testing)

9. Open Questions & Decisions Pending¶

These require resolution before or during the architecture phase:

#	Question	Why It Matters	Proposed Resolution
1	Single-tenant or multi-tenant?	Drives data isolation, RBAC, and deployment model	Start single-tenant. Design for tenant-awareness. Implement multi-tenancy in v2.
2	Which jurisdiction first?	Determines regulatory rules, document requirements, retention periods	Propose EU/Netherlands as starting jurisdiction (based on client doc references). Single jurisdiction in MVP.
3	Expected volume?	Sizing for infrastructure, performance targets	Need client confirmation: customers/day, concurrent analysts, screening volume. Design for 100 concurrent workflows as baseline.
4	Greenfield or integration with existing systems?	Drives data migration, integration complexity	Assume greenfield for core FEC platform. Design integration points for customer master, CRM, and document repository.
5	Deployment target?	Drives infrastructure choices, CI/CD	Propose cloud-first (AWS or Azure) with Docker/Kubernetes. Design for portability. On-prem is post-MVP.
6	How many escalation levels in MVP?	Simplifies first delivery	Propose 3 levels for MVP: analyst → senior/compliance → executive. Levels 4-5 added in v2.
7	Should periodic review be in MVP?	Defines minimum process surface	No. One process (onboarding) is sufficient to prove the model. Periodic review is v2.

10. Success Criteria¶

10.1 MVP Completion Criteria¶

The MVP is complete when ALL of the following are demonstrable:

✅ End-to-end onboarding: An analyst processes a corporate customer from application intake to approval/rejection, with all intelligence modules invoked automatically.
✅ Configurable, not hardcoded: Changing a risk threshold, document requirement, or workflow step does not require code deployment.
✅ Screening works: Name screening detects sanctions/PEP matches. Analyst can adjudicate potential matches. True hits escalate.
✅ Risk rating works: Customers receive Low/Medium/High scores with traceable rationale showing every contributing factor.
✅ Network analysis works: Ownership structure is visualized as a graph. Linked entities (shared directors, addresses) are surfaced.
✅ Case management works: Analyst can view queue, open case, review evidence, write notes, make decisions, escalate.
✅ Audit trail complete: An auditor can reconstruct any decision: who acted, when, with what inputs, which config version, what modules ran, what they returned.
✅ Segregation of duties enforced: Case creator cannot approve. Analyst cannot audit own work. Violations are blocked and logged.
✅ RBAC controls access: Different roles see different capabilities and data. Unauthorized access returns clear denial.

10.2 Measuring Success¶

Metric	Target
Corporate onboarding time (median)	≤ 3 business days from intake to decision
Retail onboarding time (median)	≤ 30 minutes from intake to decision
Screening false positive rate	Analyst-cleared within 2 minutes for ≥ 90% of alerts
Audit reconstruction time	≤ 5 minutes for any case from up to 5 years ago
Config change deployment time	≤ 5 minutes from save to active in production

11. Risks & Mitigations¶

Risk	Likelihood	Impact	Mitigation
Corporate onboarding scope creep — complexity exceeds estimates	Medium	High	Start with Retail flow. Add Corporate incrementally. Time-box EDD features.
External integrations become bottleneck (sanctions lists, registries)	Medium	Medium	Abstract behind interfaces. Use mock providers during development. Test with real providers early.
Regulatory requirements change during development	Low	High	Design audit and config for extensibility. Don't hardcode jurisdiction-specific rules.
Team lacks FEC domain expertise	Medium	Medium	Client docs provide domain context. Compliance reviewer should be part of review cycle.
Modular monolith becomes tightly coupled	Medium	High	Enforce bounded context boundaries via code review and architecture tests. No cross-module internal imports.
Configuration engine complexity underestimated	Medium	High	Build minimal viable config first (thresholds + workflow templates). Add features incrementally.

12. Appendix: Document Map¶

Document	What It Contains
PRD (this document)	Executive summary, vision, scope, requirements, success criteria
Requirements Inventory	Raw extraction from 4 client documents
MVP Scope Definition	Detailed scope decisions with rationale per boundary
Personas & Journeys	8 human + 8 system personas, 4 detailed core journeys
Functional Requirements	35 P0 requirements (also inline in PRD §6)
Non-Functional Requirements	32 measurable NFRs (also inline in PRD §7)
Client Inputs	4 original client documents (symlinked)

PRD assembled from: Business Concept Document, Ecosystem Blueprint, Onboarding Specification, Engineering Specification — with our own scope decisions, prioritization, and measurement frameworks applied.