Synthesized from 4 client documents (3,748 lines, 231 sections across business concept, ecosystem blueprint, onboarding spec, and engineering spec).
This document feeds the PRD. It extracts, categorizes, and prioritizes — it does not make final scope decisions. Those belong to the PRD.
1. Business Goals & Strategic Objectives
1.1 Primary Goals (from Business Concept + Blueprint)
| Goal |
Rationale |
| Prevent onboarding of prohibited entities |
Regulatory non-negotiable |
| Comply with AML/CTF obligations |
Legal requirement for any FI |
| Comply with sanctions regulations |
OFAC, EU, UN, local lists |
| Establish accurate customer master data |
Foundation for all downstream controls |
| Assign risk-based controls proportionally |
Risk-based approach required by FATF |
| Ensure consistency of decision-making |
One customer, one risk view |
| Support auditability and regulatory review |
Must reconstruct any decision from 5+ years ago |
1.2 Secondary Goals
| Goal |
Source |
| Reduce onboarding cycle time |
Business Concept, Onboarding Spec |
| Reduce analyst inefficiency |
Business Concept |
| Improve customer experience (low-risk = low friction) |
Business Concept |
| Minimize false escalations |
Engineering Spec |
| Standardize enterprise workflows |
Blueprint |
| Reduce duplicated customer reviews |
Business Concept |
| Better management visibility through MI/KPIs |
Blueprint |
1.3 Strategic Vision
"Move from siloed compliance tooling to enterprise financial crime orchestration."
"A Financial Crime Operating System — not an AML application, not a sanctions tool, not a workflow product."
- Shared customer intelligence across all FEC processes
- Consistent governance
- Reusable decision capabilities (modules)
- Configurable business-line workflows
- Modular operational expansion
2. MVP Boundary Recommendation (from Engineering Spec)
2.1 In MVP
| Domain |
P0 Priority |
Source |
| Customer Onboarding workflow |
P0 |
All 4 docs |
| Name Screening |
P0 |
All 4 docs |
| Customer Risk Rating |
P0 |
All 4 docs |
| Basic Network Analysis (ownership graph, linked entities) |
P0 |
Engineering Spec |
| Case Management (analyst workspace) |
P0 |
All 4 docs |
| Configuration Engine (workflows, thresholds, rules without code) |
P0 |
Blueprint + Engineering Spec |
| Audit Trail (immutable, append-only) |
P0 |
Blueprint + Engineering Spec |
| RBAC |
P0 |
Engineering Spec |
| Escalation workflow |
P0 |
All 4 docs |
2.2 Explicitly Excluded from MVP
| Domain |
Priority |
Reason |
| Transaction Monitoring |
P1 |
Complexity; needs event ingestion pipeline first |
| Transaction Screening |
P1 |
Real-time payment controls; separate infrastructure |
| SAR/STR Filing Automation |
P1 |
Needs transaction monitoring foundation |
| Fraud Modules |
P2 |
Separate domain; architecturally supported not built |
| Advanced ML Pipelines |
P2 |
Premature without data and baseline rules |
| Multi-jurisdiction Regulatory Engines |
P2 |
Start with one jurisdiction, generalize later |
| AI Copilots |
P2 |
Aspirational; needs stable platform first |
| Adverse Media NLP |
P2 |
Depends on external data sources |
2.3 Process Scope in MVP
From the onboarding specification — Customer Onboarding is the primary MVP process:
| Supported Variants |
In MVP |
| Retail Individual |
Yes |
| SME |
Yes |
| Corporate |
Yes |
| Correspondent Banking |
Yes |
| Private Banking |
Yes |
| Leasing / Specialized |
Configurable template |
Other lifecycle processes (periodic review, event-driven review, offboarding) are P1 — defined after MVP.
3. Functional Requirements by Domain
3.1 Workflow Orchestration
| ID |
Requirement |
Priority |
Source |
| WF-01 |
Configurable workflow templates (no code deployment required) |
P0 |
Blueprint §7, Eng Spec §3.1 |
| WF-02 |
Dynamic branching based on risk scores |
P0 |
Onboarding §9 |
| WF-03 |
Parallel task execution (e.g., screening + risk rating simultaneously) |
P0 |
Onboarding §9.2 |
| WF-04 |
Human task creation (manual approvals, reviews) |
P0 |
Onboarding §4.1 |
| WF-05 |
SLA timers with breach actions (reminder → escalation → reroute) |
P0 |
Onboarding §11 |
| WF-06 |
Retry policies for failed module executions |
P0 |
Eng Spec §7 |
| WF-07 |
Compensation/rollback logic |
P1 |
Eng Spec §7 |
| WF-08 |
Subprocess insertion |
P1 |
Onboarding §12 |
| WF-09 |
Workflow versioning (running instances continue on old version) |
P1 |
Blueprint §7 |
3.2 Customer Onboarding (Primary MVP Process)
| ID |
Requirement |
Priority |
Source |
| ON-01 |
Application intake with customer classification |
P0 |
Onboarding §6, §8 |
| ON-02 |
Data capture: identity, legal entity, ownership, business purpose |
P0 |
Onboarding §7 |
| ON-03 |
Document collection with mandatory/optional logic per customer type |
P0 |
Onboarding §8 |
| ON-04 |
Identity validation (individual + legal entity) |
P0 |
Onboarding §9 |
| ON-05 |
UBO identification and ownership capture |
P0 |
Onboarding §9 |
| ON-06 |
State machine: NEW → INTAKE → DATA_COLLECTION → … → APPROVED/REJECTED |
P0 |
Onboarding §8 |
| ON-07 |
Configurable document requirements per customer type and jurisdiction |
P0 |
Onboarding §12 |
| ON-08 |
Fast-track path for low-risk customers |
P0 |
Onboarding §9.2 |
| ON-09 |
Remediation loop for incomplete documentation |
P0 |
Onboarding §9.2 |
| ON-10 |
Customer status: approved, approved with restrictions, rejected, withdrawn, prohibited |
P0 |
Onboarding §2.1, §6.2 |
3.3 Name Screening
| ID |
Requirement |
Priority |
Source |
| NS-01 |
Match customer identity against sanctions lists |
P0 |
Blueprint §3.2 |
| NS-02 |
Match against PEP lists |
P0 |
Blueprint §3.2 |
| NS-03 |
Match against internal watchlists |
P0 |
Blueprint §3.2 |
| NS-04 |
Exact match and fuzzy match |
P0 |
Eng Spec §9 |
| NS-05 |
Alias matching |
P0 |
Eng Spec §9 |
| NS-06 |
Transliteration support |
P1 |
Eng Spec §9 |
| NS-07 |
Match disposition: no-match, potential-match, confirmed-match |
P0 |
Blueprint §3.2 |
| NS-08 |
Auto-disambiguation for obvious false positives |
P1 |
Blueprint §3.2 |
| NS-09 |
Analyst triage and adjudication workflow |
P0 |
Blueprint §3.2 |
| NS-10 |
Integration with external sanctions data providers |
P0 |
Onboarding §13 |
3.4 Customer Risk Rating
| ID |
Requirement |
Priority |
Source |
| RR-01 |
Configurable rules engine (not hardcoded) |
P0 |
Eng Spec §10 |
| RR-02 |
Risk factors: geography, customer type, ownership complexity, PEP exposure, product exposure |
P0 |
Eng Spec §10, Business Concept §7 |
| RR-03 |
Output: Low / Medium / High risk bands |
P0 |
All docs |
| RR-04 |
Rationale trace — every contributing factor explainable |
P0 |
Eng Spec §10 |
| RR-05 |
Methodology versioning |
P0 |
Blueprint §7 |
| RR-06 |
No ML initially (rules-based only for MVP) |
P0 |
Eng Spec §10 |
| RR-07 |
Risk reassessment on data change |
P1 |
Blueprint §3.1 |
3.5 Case Management
| ID |
Requirement |
Priority |
Source |
| CM-01 |
Case creation from workflows (onboarding review, screening escalation, etc.) |
P0 |
Blueprint §3.4 |
| CM-02 |
Queue management with assignment and reassignment |
P0 |
Onboarding §4.1, §12 |
| CM-03 |
Case lifecycle: created → assigned → investigating → escalated → decided → closed |
P0 |
Blueprint §3.4 |
| CM-04 |
Evidence aggregation and attachments |
P0 |
Blueprint §6 |
| CM-05 |
Case notes (timeline, not overwrite) |
P0 |
Blueprint §6 |
| CM-06 |
Escalation routing within case (Level 1-5) |
P0 |
Onboarding §10 |
| CM-07 |
Decision logging with rationale and actor |
P0 |
Blueprint §3.4 |
| CM-08 |
SLA tracking and breach notifications |
P0 |
Onboarding §11 |
| CM-09 |
Single-pane analyst workspace (customer profile + alerts + evidence + decisions) |
P0 |
Blueprint §11 |
| CM-10 |
Case types: onboarding review, sanctions investigation, customer review, EDD review, QA review |
P0 |
Business Concept §9 |
3.6 Network Analysis (MVP Scope)
| ID |
Requirement |
Priority |
Source |
| NA-01 |
Ownership graph visualization (parent → child → subsidiaries) |
P0 |
Eng Spec §11 |
| NA-02 |
Linked entity discovery (shared addresses, directors, identifiers) |
P0 |
Eng Spec §11 |
| NA-03 |
Relationship traversal (who owns what and through whom) |
P0 |
Eng Spec §11 |
| NA-04 |
Do NOT build advanced graph intelligence in MVP |
P0 (constraint) |
Eng Spec §11 |
3.7 Configuration Engine
| ID |
Requirement |
Priority |
Source |
| CF-01 |
Workflow definitions configurable without code |
P0 |
Blueprint §7, Eng Spec §3.1 |
| CF-02 |
Threshold management (risk score cutoffs, SLA timers) |
P0 |
Blueprint §7 |
| CF-03 |
Approval matrices (who approves what, at what level) |
P0 |
Blueprint §7 |
| CF-04 |
Document requirement rules (by customer type, jurisdiction, product) |
P0 |
Blueprint §7 |
| CF-05 |
Routing rules (who gets which case, based on what criteria) |
P0 |
Blueprint §7 |
| CF-06 |
Configuration versioning with promotion pipeline (dev → test → prod) |
P0 |
Blueprint §7 |
| CF-07 |
Rollback capability |
P0 |
Eng Spec §13 |
| CF-08 |
Configuration change audit trail |
P0 |
Eng Spec §13 |
| CF-09 |
Impact analysis before promotion |
P1 |
Blueprint §7 |
3.8 Escalation
| ID |
Requirement |
Priority |
Source |
| ES-01 |
5-level escalation model (analyst → senior → EDD → compliance → executive) |
P0 |
Onboarding §10, Blueprint §4 |
| ES-02 |
Configurable escalation triggers (risk score, sanctions hit, PEP, missing docs, etc.) |
P0 |
Onboarding §10 |
| ES-03 |
Routing by business line, jurisdiction, alert type, risk score, workload, analyst skill |
P0 |
Blueprint §4 |
| ES-04 |
Escalation deadline management with breach actions |
P0 |
Onboarding §11 |
| ES-05 |
Segregation of duties enforcement in escalation chain |
P0 |
Blueprint §4 |
3.9 Audit & Governance
| ID |
Requirement |
Priority |
Source |
| AU-01 |
Immutable, append-only audit log |
P0 |
Eng Spec §15, Blueprint §8 |
| AU-02 |
Track: who, what, when, why, source inputs, config version, module outputs |
P0 |
Eng Spec §3.4 |
| AU-03 |
Every workflow state transition logged |
P0 |
Onboarding §15 |
| AU-04 |
Every decision logged with rationale |
P0 |
Onboarding §15 |
| AU-05 |
Every module invocation logged (request + response) |
P0 |
Blueprint §5 |
| AU-06 |
Every configuration change logged |
P0 |
Eng Spec §15 |
| AU-07 |
Deterministic replay — reconstruct any decision from N years ago |
P0 |
Eng Spec §16, Blueprint §8 |
| AU-08 |
Segregation of duties enforced (analyst ≠ approver ≠ auditor) |
P0 |
Business Concept §10, Onboarding §14 |
| AU-09 |
Four-eyes principle for high-risk decisions |
P0 |
Business Concept §10 |
| AU-10 |
Override governance — every override logged with justification |
P0 |
Onboarding §12 |
| AU-11 |
Policy version traceability — which policy version was active at time of decision |
P1 |
Onboarding §3 |
4. Non-Functional Requirements
| ID |
Requirement |
Source |
| NF-01 |
Responsive UI — analyst workflows must not block |
Onboarding §16 |
| NF-02 |
Screening response within seconds |
Onboarding §11 (30min SLA for analyst review implies near-real-time screening) |
| NF-03 |
Concurrent workflow execution — multiple analysts processing simultaneously |
Onboarding §16 |
4.2 Security
| ID |
Requirement |
Source |
| NF-04 |
Role-Based Access Control (RBAC) |
All docs |
| NF-05 |
Multi-Factor Authentication (MFA) |
Onboarding §14, Blueprint §9 |
| NF-06 |
Encryption in transit (TLS) |
Onboarding §14, Blueprint §9 |
| NF-07 |
Encryption at rest |
Onboarding §14, Blueprint §9 |
| NF-08 |
Field-level access control for sensitive data |
Onboarding §14 |
| NF-09 |
Privileged access monitoring |
Onboarding §14 |
| NF-10 |
SSO readiness |
Eng Spec §14 |
4.3 Reliability
| ID |
Requirement |
Source |
| NF-11 |
Retry logic for failed module executions |
Eng Spec §7 |
| NF-12 |
Graceful degradation when external services unavailable |
Onboarding §16 |
| NF-13 |
High availability — platform remains operational during failures |
Blueprint §13 |
4.4 Observability
| ID |
Requirement |
Source |
| NF-14 |
Structured logging |
Blueprint §13 |
| NF-15 |
Metrics (workflow throughput, SLA breaches, decision volumes) |
Blueprint §13 |
| NF-16 |
Distributed tracing for request correlation |
Blueprint §13 |
4.5 Maintainability
| ID |
Requirement |
Source |
| NF-17 |
Modular architecture — each capability independently deployable |
Onboarding §16, Blueprint §13 |
| NF-18 |
Configuration changes must not require code deployment |
Eng Spec §3.1 |
| NF-19 |
Versioned APIs |
Eng Spec §16 |
4.6 Usability
| ID |
Requirement |
Source |
| NF-20 |
Low click count for analyst tasks |
Onboarding §16, Blueprint §13 |
| NF-21 |
Intuitive workflows — analysts should not need training for basic tasks |
Blueprint §13 |
| NF-22 |
Single-pane investigation view (customer + alerts + evidence + decisions in one place) |
Blueprint §11 |
4.7 Compliance & Retention
| ID |
Requirement |
Source |
| NF-23 |
Audit records retained per regulatory minimum (5-10 years depending on jurisdiction) |
Onboarding §3, Blueprint §8 |
| NF-24 |
Evidence preservation — documents linked to decisions |
Onboarding §3.2 |
| NF-25 |
Data privacy compliance (GDPR, local equivalents) |
Blueprint §8 |
5. Integration Surface
| From |
To |
Purpose |
| Onboarding workflow |
Name Screening |
Screen customer at onboarding |
| Onboarding workflow |
Risk Rating |
Calculate customer risk score |
| Onboarding workflow |
Network Analysis |
Map ownership structure |
| Case Management |
Audit Service |
Log all case actions |
| Configuration Engine |
All modules |
Supply active config version |
5.2 External Integrations
| Integration |
Purpose |
Priority |
| Sanctions list providers (OFAC, EU, UN) |
Name screening data source |
P0 |
| PEP list providers |
PEP detection |
P0 |
| Corporate registries |
Legal entity verification |
P0 |
| Identity verification providers |
Individual identity validation |
P0 |
| CRM |
Customer relationship context |
P1 |
| Customer Master |
Existing customer records |
P1 |
| IAM / SSO |
Authentication and authorization |
P1 |
| Document repository |
Secure document storage |
P1 |
6. User & System Actors
6.1 Human Roles (from Onboarding Spec §4.1 + Blueprint)
| Role |
Primary Responsibility |
| Relationship Manager |
Commercial initiation; provides business context |
| Onboarding Specialist |
Intake review; workflow initiation; document coordination |
| KYC Analyst |
Customer verification; document validation; ownership review |
| Sanctions Analyst |
Screening adjudication; true hit confirmation |
| EDD Analyst |
Deep due diligence; ownership complexity; source of wealth |
| FCC Reviewer |
High-risk approvals; policy exceptions; sanctions governance |
| Supervisor |
Workload balancing; SLA monitoring; escalation handling |
| Audit Reviewer |
Process verification; control assurance; reconstruction |
6.2 System Actors (from Onboarding Spec §4.2 + Blueprint §5)
| System Actor |
Function |
| Workflow Orchestration Engine |
Drives process state transitions |
| Customer Classification Engine |
Determines customer archetype and template |
| Document Validation Engine |
Validates mandatory/optional documents |
| Identity Verification Service |
Validates individual and entity identity |
| Name Screening Engine |
Matches against watchlists |
| PEP Screening Engine |
Detects politically exposed persons |
| Customer Risk Rating Engine |
Calculates risk score and band |
| Entity Resolution Engine |
Links related entities |
| Network Analysis Service |
Maps ownership and relationships |
| Notification Engine |
Sends reminders, escalations, customer comms |
| Audit Service |
Records all events immutably |
| Policy Validation Engine |
Enforces config version compliance |
| Configuration Engine |
Serves active config to all modules |
7. Domain Model — Canonical Entities
From the Onboarding Spec §7 and Blueprint §6, the following entities recur across all documents:
| Entity |
Core Purpose |
In MVP |
| Customer |
Top-level party (individual or organization) |
P0 |
| Individual |
Natural person (officers, UBOs, retail customers) |
P0 |
| LegalEntity |
Registered organization |
P0 |
| OwnershipRelationship |
Parent → child with ownership % and control type |
P0 |
| Account |
Financial account linked to customer |
P0 |
| Document |
Identity docs, incorporation certs, etc. |
P0 |
| ScreeningResult |
Output of name/sanctions screening |
P0 |
| RiskAssessment |
Risk score, band, factors, methodology version |
P0 |
| WorkflowInstance |
Running instance of a workflow template |
P0 |
| Task |
Work item assigned to a human or system |
P0 |
| Decision |
Formal decision (approve, reject, escalate) with rationale |
P0 |
| Case |
Investigation container linking tasks, evidence, decisions |
P0 |
| Alert |
Generated by monitoring/screening modules (P1 — post-MVP) |
P1 |
| Transaction |
Financial transaction (P1 — needed for tx monitoring) |
P1 |
| RegulatoryFiling |
SAR/STR filing record (P1) |
P1 |
8. Key Terminology
| Term |
Definition |
Source |
| FEC |
Financial Economic Crime |
All docs |
| KYC |
Know Your Customer |
All docs |
| CDD |
Customer Due Diligence |
Onboarding §3 |
| EDD |
Enhanced Due Diligence (deep investigation for high-risk) |
Onboarding §3 |
| UBO |
Ultimate Beneficial Owner |
All docs |
| PEP |
Politically Exposed Person |
All docs |
| SAR / STR |
Suspicious Activity Report / Suspicious Transaction Report |
Blueprint §3.5 |
| SoD |
Segregation of Duties |
Onboarding §3.2 |
| AML / CTF |
Anti-Money Laundering / Counter-Terrorist Financing |
All docs |
| Bounded Context |
DDD term: a logical boundary within which a domain model applies |
Eng Spec §3.6 |
| Decision Module |
A pluggable analytical capability with a standard contract |
Blueprint §5 |
| Configuration over Code |
Business rules changeable without software deployment |
Eng Spec §3.1 |
9. Open Questions & Ambiguities (from Client Docs)
These need resolution in the PRD or architecture phase:
| # |
Question |
Why It Matters |
| 1 |
Is this a single-tenant or multi-tenant platform? The docs mention "multi-institution deployment capability" (Blueprint §1.2) but also suggest a single institution context. |
Drives data isolation, deployment model, and RBAC design |
| 2 |
Which jurisdiction's regulations apply first? The docs reference multiple jurisdictions but don't specify a starting point. |
Determines onboarding rules, retention periods, reporting obligations |
| 3 |
What's the expected volume? (customers/day, concurrent analysts, screening requests/sec) |
Sizing for infrastructure and performance targets |
| 4 |
How deeply should the "network analysis" go? Docs say "basic" for MVP but don't define the cutoff. |
Risks scope creep |
| 5 |
Is there an existing customer master system to integrate with, or is this greenfield? |
Drives data migration and integration complexity |
| 6 |
The escalation model has 5 levels — are all 5 needed in MVP or are levels 4-5 P1? |
Simplifies first delivery |
| 7 |
What's the deployment target? Cloud? On-prem? Both? The Eng Spec says "cloud-agnostic" and "on-prem" — these are very different operational models. |
Drives infrastructure choices and CI/CD design |
| 8 |
Should the MVP support only customer onboarding as a process, or should periodic review be included? |
Defines the minimum viable process surface |
| 9 |
Real-time screening vs. batch? The onboarding process uses near-real-time, but transaction screening (post-MVP) is real-time. |
Temporal vs. streaming architecture decisions |
10. Summary of What Feeds the PRD
| PRD Section |
Informed By |
| Executive Summary |
§1 — Business Goals, §1.3 — Strategic Vision |
| Product Scope & MVP |
§2 — MVP Boundary, §9 — Open Questions |
| User Personas |
§6 — Human & System Actors |
| Functional Requirements |
§3 — Requirements by Domain |
| Non-Functional Requirements |
§4 — NFRs |
| Domain Model |
§7 — Canonical Entities |
| Integrations |
§5 — Integration Surface |
| Compliance Requirements |
§4.7 — Compliance & Retention |
| Risks & Open Items |
§9 — Open Questions |
Inventory compiled from:
- FecEcosystemBusinessConceptDocument.md (734 lines)
- EnterpriseFecEcosystemBlueprint.md (1,040 lines)
- CustomerOnboardingEnterpriseSpecification.md (1,062 lines)
- EnterpriseFecPlatformEngineeringSpec.md (912 lines)
Total source: 3,748 lines / 231 sections across 4 documents.