System Design: Mobile Check Deposit for a Consumer Banking App

Problem Statement

Design a production-grade Remote Deposit Capture (RDC) feature for a consumer banking mobile application in the U.S. This system must enable retail customers to deposit paper checks by capturing images via their mobile device. The solution must be secure, compliant with U.S. banking regulations (specifically Reg CC and Check 21), highly resilient, and scalable to meet the demands of a Tier 1 tech company.

Functional Requirements

• Image Capture and Guidance: The mobile application must facilitate on-device capture of both front and back check images. This includes providing guidance overlays to the user, auto-capturing images when optimal alignment, focus, and lighting conditions are met, and performing on-device prechecks for issues like glare, blur, edge detection, MICR line presence, and endorsement on the back of the check.
• Amount Entry and Validation: Users will manually enter the deposit amount. The server-side system must validate this amount using Optical Character Recognition (OCR) techniques (e.g., Courtesy Amount Recognition/Legal Amount Recognition - CAR/LAR) and cross-reference it with the MICR line context. The system needs to gracefully handle any mismatches.
• Duplicate and Limit Checks: The system must detect duplicate deposits within the institution, across different users, and even across different devices. Integration with external duplicate networks should be considered if available. Furthermore, the system must enforce various deposit limits: per-deposit, daily, and rolling limits, which may vary by user, account, or risk tier.
• Deposit Status Lifecycle: The system must define and manage a clear lifecycle for deposits, with distinct statuses and transitions. Examples include: Created → Uploaded → Processing → Accepted → Pending Hold → Available, or terminal states like Rejected/Returned.
• Notifications: Users should receive timely notifications regarding their deposit status. This includes in-app real-time updates, push notifications, and email alerts for events such as acceptance, holds applied, funds availability, rejections, and returns.
• Error Handling: The system needs robust error handling. This involves user-friendly retry mechanisms for capture and upload failures on the client side, server-side retries with exponential backoff for transient issues, and the use of dead-letter queues (DLQs) for handling poison messages.

Non-Functional Requirements

• Availability: The submission API must maintain 99.9%+ availability, while status read operations require 99.95% availability.
• Latency: Submission acknowledgements should have a P50 latency of less than 300 ms and a P95 latency of less than 800 ms. Backend processing, while near-real-time, can have an eventual completion time measured in minutes.
• Durability: Image and transaction data must achieve an extremely high durability target, specifically ≥ 11 nines for images (implying multi-region object storage) and strong transactional durability for ledger writes.
• Consistency: Strong consistency is required for critical operations such as idempotency checks, limit enforcement, and ledger updates. Eventual consistency is acceptable for less critical aspects like notifications and analytics.
• Observability: The system must provide comprehensive observability, including end-to-end traces, structured logs with PII scrubbing, SLO dashboards, and anomaly detection capabilities for failure rates and OCR quality metrics.

Risk and Compliance Considerations

• Fraud Prevention: Implement robust fraud prevention measures, including device fingerprinting, velocity limits, dynamic risk scoring, liveness/attestation checks during capture, endorsement verification, and integration with duplicate networks.
• Holds and Funds Availability: Adhere strictly to Reg CC-compliant schedules for funds availability. This includes implementing risk-adjusted holds, managing cutoff times, and providing clear disclosures to customers.
• Check 21 Compliance: Ensure compliance with Check 21 standards, particularly regarding image quality and exchange standards (e.g., X9.37 format), MICR integrity, and accurate CAR/LAR validation.
• Audit Trails: Maintain immutable, tamper-evident audit logs for all transactions and critical events, with retention policies (e.g., 7 years) as required by regulations.
• PII Protection: Implement comprehensive PII protection measures, including encryption in transit and at rest, strict access controls, data minimization principles, redaction/masking of sensitive data, and secure key management and rotation practices.

Architectural Scope

Your proposed end-to-end design should cover the following components and considerations:

• Mobile Client: On-device capture, guidance, and initial preprocessing (dewarping, glare/blur detection).
• Backend Processing Pipelines: MICR/OCR pipeline, endorsement verification, limits and risk scoring engine, duplicate detection across various scopes.
• APIs: Idempotent submission API.
• Asynchronous Processing: Mechanisms for asynchronous processing and reconciliation with core banking systems.
• Core Banking Integration: How the system interacts with the bank's ledger and other core services.
• Error Handling: Strategies for retries and dead-letter queues.
• Data Management: Data models, storage solutions (for images, transactional data, audit logs), and data retention policies.
• System Attributes: Scaling strategies, rate limiting, device fingerprinting, security architecture, monitoring, and testing strategies (e.g., sandbox environments, golden datasets, canary releases).