Design mobile check deposit system

Q: Design mobile check deposit system

This is a System Design interview question from Chime for Software Engineer roles. View the full question and solution on PracHub.

Q: How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

Question

System Design: Mobile Check Deposit for a Consumer Banking App

Context

Design a production-grade Remote Deposit Capture (RDC) feature that allows retail customers to deposit paper checks using a mobile app in the U.S. banking context. The system must be secure, compliant with U.S. regulations (Reg CC, Check 21), resilient, and scalable.

Requirements

Functional Requirements

Capture and guidance
- On-device capture of front and back images with guidance overlays.
- Auto-capture when alignment, focus, and lighting thresholds are met.
- On-device prechecks: glare/blur detection, edge and MICR line presence, endorsement presence on back.
Amount entry and validation
- User enters amount; server validates via OCR (CAR/LAR) and MICR context; handle mismatches.
Duplicate and limit checks
- Detect duplicates within institution and across users/devices; integrate with external duplicate networks if available.
- Enforce per-deposit, daily, and rolling limits by user/account/risk tier.
Deposit status lifecycle
- Statuses with clear transitions, e.g., Created → Uploaded → Processing → Accepted → Pending Hold → Available, or Rejected/Returned.
Notifications
- In-app real-time updates, push notifications, and email for acceptance, holds, availability, rejections, and returns.
Error handling
- User-friendly retries for capture/upload; server-side retries with backoff; dead-letter queues for poison messages.

Non-Functional Requirements

Availability: 99.9%+ for submission API; 99.95% for status reads.
Latency: P50 < 300 ms and P95 < 800 ms for submission acknowledgement; near-real-time processing with eventual completion minutes-scale.
Durability: Image and transaction data ≥ 11 nines for images (multi-region object storage); transactional durability for ledger writes.
Consistency: Strong consistency for idempotency, limit checks, and ledgering; eventual consistency acceptable for notifications and analytics.
Observability: End-to-end traces, structured logs with PII scrubbing, SLO dashboards, anomaly detection on failure rates and OCR quality.

Risk and Compliance

Fraud prevention: device fingerprinting, velocity limits, risk scoring, liveness/attestation checks, endorsement verification, duplicate networks.
Holds and funds availability: Reg CC-compliant schedules; risk-adjusted holds; cutoff times; disclosures.
Check 21: image quality and exchange standards (X9.37), MICR integrity, CAR/LAR validation.
Audit trails: immutable, tamper-evident logs; retention per policy (e.g., 7 years).
PII protection: encryption in transit/at rest, access controls, data minimization, redaction/masking, key management and rotation.

Architecture Scope

Propose end-to-end design covering: on-device capture and guidance; image preprocessing (dewarp, glare/blur detection); MICR/OCR pipeline; endorsement verification; limits and risk scoring; duplicate detection across users/devices; idempotent submission API; asynchronous processing and reconciliation; core banking integration and ledgering; error handling with retries and dead-letter queues. Discuss data models, APIs, storage, scaling, rate limiting, device fingerprinting, security, monitoring, and testing strategies (sandbox, golden datasets, canary releases).