1. Executive Summary & Problem Scope The Smart Round-Up Recurring Investment Engine is an automated micro-investing feature designed to systematically harvest spare change from daily consumer transactions and sweep those funds into an investment portfolio. The core business value lies in driving continuous, low-friction capital inflows to maximize Assets Under Management (AUM) and user lifetime value (LTV). The primary pain point addressed is the behavioral barrier to entry: the target demographic often lacks both the initial capital for lump-sum investing and the discipline for scheduled, fixed-amount recurring deposits. Success for this initiative is strictly defined as achieving a 25% increase in monthly active deposits and a corresponding 25% increase in asset retention within two quarters post-launch. 2. Detailed User Persona & Journey Mapping Target Persona: "The Aspirational Micro-Investor" ⚬ Demographic: Gen-Z and Millennials (18–35). ⚬ Financial Profile: Low financial literacy, limited discretionary income, high transaction volume via debit/credit cards. ⚬ Primary Motivations: Building wealth passively without noticeable impact on daily lifestyle or cash flow. ⚬ Trigger Events: Swiping a linked card for everyday purchases (e.g., coffee, groceries, ride-shares). ⚬ End Goals: Achieving a funded investment portfolio via micro-commitments, obtaining psychological safety regarding financial futures. Journey Map: 1. Onboarding: User authenticates via React Native frontend, accepting the Round-Up value proposition. 2. Authorization: User securely links their primary spending institution via the Plaid API module. 3. Passive Accumulation: User conducts daily fiat transactions. The engine calculates the difference to the nearest whole dollar. 4. Execution Trigger: Accumulated spare change is tracked in a virtual ledger until it breaches the sweep threshold (e.g., $5.00). 5. Settlement: An ACH transfer is initiated via the backend broker API to fund the user's investment account, resetting the virtual ledger. 3. Functional Requirements & Agile User Stories Story 1: Secure Account Linking via Plaid As a retail micro-investor, I want to securely link my primary checking account using Plaid, so that the platform can monitor my daily transactions for round-up calculations. ⚬ Acceptance Criteria: ⚬ Given the user navigates to the "Funding" view in the React Native app, ⚬ When they select "Link Account for Round-Ups" and complete the Plaid Link OAuth flow, ⚬ Then the Node.js backend must exchange the public token for a permanent access token, store it securely in PostgreSQL, and return a success state to the UI. Story 2: Transaction Ingestion and Round-Up Calculation As a retail micro-investor, I want my everyday purchases rounded up to the nearest dollar automatically, so that my spare change accumulates in the background. ⚬ Acceptance Criteria: ⚬ Given the user has an active Plaid-linked checking account, ⚬ When a settled transaction webhook is fired from Plaid to the Express.js endpoint, ⚬ Then the engine must calculate the ceiling integer of the transaction amount, subtract the original amount, and credit the delta to the user's virtual round-up ledger. Story 3: Threshold-Triggered Investment Sweep As a retail micro-investor, I want my accumulated round-ups to automatically transfer into my investment account once they hit a $5 threshold, so that I avoid excessive micro-transfer fees and continuously fund my portfolio. ⚬ Acceptance Criteria: ⚬ Given the user's virtual round-up ledger balance is \ge $5.00, ⚬ When the ledger update transaction commits in PostgreSQL, ⚬ Then the Node.js microservice must immediately initiate an ACH debit for the total ledger amount, reset the ledger to $0.00, and generate a ledger audit trail. Story 4: Granular Pause/Resume Controls As a retail micro-investor, I want the ability to pause and resume round-up functionality with one tap, so that I maintain complete control over my cash flow during tight financial weeks. ⚬ Acceptance Criteria: ⚬ Given the user is viewing their Round-Up settings in the React Native frontend, ⚬ When they toggle the feature to the "Paused" state, ⚬ Then the backend must immediately halt ledger accumulation for incoming webhooks and bypass any pending sweeps until the toggle is re-enabled. 4. Non-Functional & Technical Requirements ⚬ System Architecture & Stack Integration: ⚬ Frontend: React Native handling local state mapping for ledger visualization and integrating the Plaid React Native SDK. ⚬ Backend: Node.js/Express RESTful microservices architecture handling webhook ingestion, ledger math, and ACH execution. ⚬ Database: PostgreSQL deployed in a highly available cluster. Usage of ACID-compliant transactions is mandatory for all ledger updates. ⚬ Latency & Performance: ⚬ The webhook ingestion to database write lifecycle must execute within a strict sub-200ms processing window. ⚬ To achieve this, Plaid webhook payloads will be immediately acknowledged (200 OK) and offloaded to an in-memory message broker (e.g., Redis) before asynchronous processing by Node.js worker threads. ⚬ Transaction Integrity (Zero Duplicates): ⚬ Strict idempotency is required. Every ingested Plaid transaction_id must be logged in a dedicated PostgreSQL table with a UNIQUE index. ⚬ Any duplicate webhooks for a known transaction_id must be silently dropped at the database level to ensure exactly-once processing of spare change. ⚬ Security & Data Privacy: ⚬ PCI-DSS Compliance: The system must not ingest, transmit, or store Primary Account Numbers (PANs). All financial routing operates strictly via Plaid tokenization. ⚬ Encryption: Plaid access_tokens and broker API keys must be encrypted at rest in PostgreSQL using AES-256-GCM. Decryption keys must be managed via a dedicated KMS (Key Management Service) and injected into the Node.js environment at runtime. 5. Edge Cases & Error Handling ⚬ Failure State 1: Plaid Webhook Network Timeout / Delivery Failure ⚬ Trigger: Plaid fails to reach the Express webhook endpoint, or the Node.js service is overwhelmed. ⚬ Fallback Behavior: Rely on Plaid's native retry logic. If the internal Redis queue fails to write to PostgreSQL, the payload is routed to a Dead Letter Queue (DLQ). A chron-based reconciler will query the Plaid /transactions/get endpoint nightly to backfill missed transaction IDs. ⚬ Failure State 2: Insufficient Funds (NSF) Pre-Sweep ⚬ Trigger: The virtual ledger hits $5.00, but a real-time Plaid /accounts/balance/get check reveals the linked checking account has an available balance <\$10.00. ⚬ Fallback Behavior: Abort the ACH sweep. Maintain the virtual ledger balance. Push a local notification via React Native informing the user: "Round-up paused due to low bank balance to protect against overdraft fees." Re-attempt the sweep upon the next transaction trigger. ⚬ Failure State 3: OAuth Token Expiration / Permission Mismatch ⚬ Trigger: The user changes their bank password, revoking the Plaid access token. The Node.js service receives an ITEM_LOGIN_REQUIRED error from Plaid. ⚬ Fallback Behavior: The backend flags the user_connections record as requires_reauth and pauses the round-up engine. The React Native frontend polls this state and renders a persistent banner requiring the user to launch Plaid Link in "update mode" to restore connectivity. ⚬ Failure State 4: Concurrency/Race Conditions on Ledger Updates ⚬ Trigger: Two webhooks for the same user process simultaneously, leading to a race condition where the $5.00 threshold is breached twice before the ledger resets. ⚬ Fallback Behavior: Implement pessimistic row-level locking (SELECT FOR UPDATE) on the user's ledger row in PostgreSQL during the threshold check and ACH execution sequence to serialize concurrent webhook processing. 6. Key Performance Indicators (KPIs) Metric Target Benchmark Measurement Method Monthly Active Deposits (MAD) +25% baseline increase Query PostgreSQL aggregate distinct users initiating \ge1 deposit per 30-day rolling window. Asset Retention Rate +25% baseline increase Measure percentage of total round-up AUM remaining on-platform 90 days post-deposit. Feature Adoption Rate 40% of MAU Ratio of active users with Plaid linked & Round-Ups toggled true vs. total MAUs. System Latency <200ms (p95) APM tooling (e.g., Datadog/New Relic) measuring webhook ingress to DB commit. Idempotency Failure Rate 0.00% Audit logs tracking duplicate transaction_id processing attempts vs. actual ledger mutations. NSF Prevention Success >98\% prevention Ratio of aborted low-balance sweeps to total ACH return codes for insufficient funds.