Product Scope & MVP Boundaries¶
Status: Draft — feeds the PRD. Principle: Every boundary decision must be justified. Nothing is in by default.
1. Product Vision (One Sentence)¶
A configurable, modular, audit-grade operating platform for financial crime operations — starting with customer onboarding as the primary workflow, powered by pluggable screening, risk rating, and network analysis modules.
2. What the Platform IS¶
| Is... | Is NOT... |
|---|---|
| A configurable operating system for FEC processes | A point solution for one FEC function (e.g., "an AML tool") |
| A workflow orchestration platform with modular intelligence | A hardcoded process engine |
| A case management system for analysts | A CRM or customer service tool |
| An audit-grade, regulator-ready system | A prototype or proof-of-concept |
| Multi-process by design (onboarding, review, investigation) | Single-process only |
| Institution-agnostic (configurable per deployment) | Hardcoded for one institution |
3. MVP Definition: The Minimum Viable Platform¶
3.1 Core Principle¶
The MVP must demonstrate the "Operating System" thesis: one process fully working end-to-end, powered by reusable intelligence modules, governed by configurable rules, and fully auditable.
If the MVP only does onboarding but does it with all the architectural properties of the final platform, it proves the model. If it does multiple processes shallowly, it proves nothing.
3.2 What's IN Scope — 7 Capabilities¶
| # | Capability | Scope in MVP | Rationale |
|---|---|---|---|
| 1 | Workflow Orchestration | Configurable onboarding workflows, dynamic branching, parallel execution, human tasks, SLA timers | This is the backbone. Without it, nothing else works. |
| 2 | Customer Onboarding Process | Full onboarding lifecycle: intake → data capture → document collection → screening → risk rating → network check → analyst review → decision | The one process that proves the model. All customer archetypes supported via configurable templates. |
| 3 | Name Screening Module | Exact + fuzzy matching against sanctions and PEP lists. Match disposition workflow. | Simplest intelligence module. Proves the pluggable module contract. |
| 4 | Customer Risk Rating Module | Rules-based scoring engine. Low/Medium/High bands. Rationale traceability. | Proves the configurable rules engine. No ML needed for MVP. |
| 5 | Basic Network Analysis | Ownership graph visualization. Linked entity discovery via shared identifiers/directors/addresses. | Proves the graph capability without overbuilding. Keep to relationship traversal only. |
| 6 | Case Management | Case lifecycle: creation → assignment → investigation → escalation → decision → closure. Queue management. Notes (append-only). Evidence attachments. | Every analyst interaction happens here. The workspace. |
| 7 | Audit & Governance | Immutable append-only audit log. Every state transition, decision, module invocation, and config change logged. Deterministic replay. Segregation of duties enforced. | Non-negotiable. Regulators will ask for this. Build it from day one. |
3.3 What's EXPLICITLY OUT — Deferred to Post-MVP¶
| # | Capability | Why NOT in MVP | When? |
|---|---|---|---|
| 1 | Transaction Monitoring | Requires event ingestion pipeline, scenario definitions, and substantial data volume to be meaningful. Premature without real transaction data. | v2 |
| 2 | Transaction Screening | Real-time payment controls. Separate infrastructure path. Different latency requirements. | v2 |
| 3 | SAR/STR Filing Automation | Depends on transaction monitoring foundation. Regulatory filing format varies by jurisdiction. | v2+ |
| 4 | Fraud Modules | Separate domain. Different detection models, different workflows. Architecturally supported but not built in MVP. | v3+ |
| 5 | Advanced Graph Intelligence | MVP needs basic relationship traversal only. Cluster detection, hidden network discovery, centrality algorithms are v2+. | v2+ |
| 6 | Machine Learning Models | Premature without operational data. Rules-based models are sufficient, explainable, and regulator-friendly for MVP. | v2+ |
| 7 | AI Copilots / NLP | Aspirational. Requires stable platform + LLM governance framework first. | v3+ |
| 8 | Periodic Review Process | Important but not the proving process. Onboarding is the entry point for all customers — build that first. | v2 |
| 9 | Event-Driven Review | Depends on event infrastructure and rules that aren't built yet. | v2+ |
| 10 | Offboarding / Exit Process | Lower volume, lower risk. Can be handled manually initially. | v2+ |
| 11 | Adverse Media Analysis | Requires external data feeds and NLP. Complex integration, uncertain ROI for MVP. | v2+ |
| 12 | Multi-Jurisdiction Regulatory Engine | Start with one jurisdiction's rules. Generalize after proven. Designing for generalization is fine; building for all jurisdictions is not. | v2+ |
4. Customer Archetypes in MVP¶
All archetypes are supported as configurable templates — not separate code paths:
| Archetype | In MVP? | Notes |
|---|---|---|
| Retail Individual | ✅ | Simplest path. Fast-track low-risk flow. |
| SME | ✅ | Moderate ownership complexity. |
| Corporate | ✅ | Complex ownership, UBO transparency. The proving case. |
| Correspondent Banking | ✅ | Highest complexity. Tests escalation model. |
| Private Banking | ✅ | Wealth scrutiny, PEP sensitivity. |
| Leasing / Specialized | ✅ via config | Configurable template per business line. |
Design principle: The platform distinguishes between customer types via configuration, not code. Adding a new type means adding a new workflow template, thresholds, and document requirements — no deployment.
5. Integration Surface — MVP Minimum¶
5.1 Must Integrate (P0)¶
| Integration | Purpose | Reason |
|---|---|---|
| Sanctions list provider (OFAC, EU, UN) | Name screening data source | Without this, screening doesn't work |
| PEP list provider | PEP detection during screening | Core KYC/CDD obligation |
| Corporate registry (at least one) | Legal entity verification | Needed for corporate onboarding |
| Identity verification provider | Individual identity validation | Needed for individual/SME onboarding |
5.2 Should Integrate (P1 — late MVP or v2)¶
| Integration | Purpose |
|---|---|
| Document repository | Secure storage for onboarding documents |
| SSO / Identity Provider | Enterprise authentication |
| Email/SMS notification gateway | Customer and analyst notifications |
5.3 Out of Scope for MVP¶
| Integration | Reason |
|---|---|
| CRM | Not needed for core onboarding flow (RM can use the platform directly) |
| Core banking / Customer Master | Depends on existing institution systems; integration is institution-specific |
| Payment switch (for tx screening) | Post-MVP |
6. What "Done" Looks Like for MVP¶
The MVP is ready when all of the following are true:
- An analyst can process a corporate customer onboarding end-to-end — from application intake to approval/rejection, with all intelligence modules invoked automatically.
- The workflow is configurable, not hardcoded — changing approval rules, thresholds, or document requirements does not require code deployment.
- Name screening produces accurate match results — with analyst adjudication for potential hits.
- Risk rating produces Low/Medium/High scores — with traceable rationale for every contributing factor.
- Network analysis shows ownership structure — at least a parent-child-subsidiary view.
- Every decision is reconstructable — an auditor can trace from a decision back to: which config was active, what modules ran, what data was used, who approved.
- Segregation of duties is enforced — the person who creates a case cannot approve it; the person who approves cannot audit themselves.
- RBAC controls access — different roles see different capabilities.
7. Explicit Non-Goals for MVP¶
These are things we intentionally choose NOT to optimize in MVP:
| Non-Goal | Why |
|---|---|
| Multi-tenancy | Start single-tenant. Design tenant-awareness but don't implement isolation. |
| Multi-language UI | English only. I18n infrastructure later. |
| Self-service onboarding for customers | Analyst-driven only. Customer portal is v2+. |
| Real-time performance | Near-real-time is sufficient. Sub-second screening is post-MVP. |
| High availability / failover | Single deployment. HA architecture designed but not implemented. |
| CI/CD pipeline with blue-green deployments | Manual deployments acceptable for MVP. |
| Full test coverage | Target 80%+ for business logic. Integration tests for critical paths. |
| Mobile UI | Desktop web only. |
8. Risks of This MVP Definition¶
| Risk | Mitigation |
|---|---|
| "Only onboarding" may not convince stakeholders of platform thesis | Prove the architecture, not the feature count. A well-architected onboarding platform with pluggable modules IS the thesis. |
| Corporate onboarding is complex — may take longer than expected | Start with Retail individual flow first. Add archetypes incrementally. |
| External integrations (sanctions lists, registries) may be hard to stabilize | Abstract behind interfaces. Use mock/test providers during development. |
| Audit requirements may grow during development | Design the audit model for extensibility from day one. |
9. Post-MVP Roadmap (Directional Only)¶
This is NOT a commitment — it's a signal of the sequence after MVP success:
| Phase | Capabilities |
|---|---|
| v2 | Transaction monitoring, periodic review, event-driven review, SAR filing prep, third-party integrations |
| v3 | Transaction screening, ML-based alert prioritization, advanced graph intelligence, adverse media |
| v4+ | Fraud modules, AI copilots, multi-jurisdiction engines, customer self-service portal |
Scope definition derived from: Requirements Inventory §2, Engineering Spec §2/§20, Blueprint §14.