Design mobile check deposit system

System Design: Mobile Check Deposit for a Consumer Banking App

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

Walk through the full design end to end: requirements, architecture, data models, APIs, and the operational concerns (scaling, security, monitoring, testing) that make it production-ready.

Clarifying Questions to Ask Guidance

Before designing, scope the problem with the interviewer:

Scale : How many active users and deposits per day should we plan for? What does peak traffic look like (paydays, weekday mornings)?
Clearing model : Do we operate our own clearing/presentment, or sit behind a sponsor bank / BaaS partner that handles actual check presentment?
Account scope : Single account per user, or multiple accounts? Do we support business checks or only personal?
Availability product : Do we offer instant (paid) funds availability, or is a Reg CC hold acceptable for the baseline experience?
What counts as "done" : Is a successful deposit a final credit, or a provisional credit subject to return (clawback for weeks on NSF/altered/stop-payment)?
Compliance surface : Which holds, disclosures, and audit-retention requirements are in scope (Reg CC schedules, Check 21 image exchange, BSA/AML monitoring)?

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, and endorsement presence on the back.
Amount entry and validation
- User enters the amount; the server validates it via OCR (CAR/LAR) and MICR context, handling mismatches.
Duplicate and limit checks
- Detect duplicates within the institution and across users/devices ; integrate with external duplicate networks where available.
- Enforce per-deposit, daily, and rolling limits by user / account / risk tier.
Deposit status lifecycle
- A status model with clear transitions, e.g. Created → Uploaded → Processing → Accepted → Pending Hold → Available , plus Rejected / Returned .
Notifications
- In-app real-time updates, push, 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 the submission API; 99.95% for status reads.
Latency : submission acknowledgement P50 < 300 ms and P95 < 800 ms; near-real-time processing with eventual completion on a minutes-scale.
Durability : ≥ 11 nines for images (multi-region object storage); transactional durability for ledger writes.
Consistency : strong for idempotency, limit checks, and ledgering; eventual acceptable for notifications and analytics.
Observability : end-to-end traces, structured logs with PII scrubbing, SLO dashboards, and 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 and at rest, access controls, data minimization, redaction/masking, and key management and rotation.

Architecture Scope

Propose an end-to-end design that ties the requirements above into a working pipeline. Beyond the functional behavior already specified, explicitly address:

Image preprocessing (dewarp, glare/blur detection) and endorsement verification
Limits and risk scoring
Idempotent submission API
Asynchronous processing and reconciliation
Core banking integration and ledgering

Then discuss the supporting concerns: data models, APIs, storage, scaling, rate limiting, device fingerprinting, security, monitoring, and testing strategies (sandbox, golden datasets, canary releases).

Constraints & Assumptions

State these explicitly if the interviewer does not pin them down:

Scale anchor : ~5M users, ~2% daily deposit rate → ~100k deposits/day (~1.2/s mean), provisioned for a ~50× payday/morning burst . Status reads dominate writes (clients poll/subscribe) and should be cache-served.
Image footprint : front + back ≈ 2 images × ~1 MB ≈ 2 MB/deposit; plan derivatives (archival + OCR-optimized + thumbnail) and cold/WORM tiering after the active window.
Clearing : assume a sponsor-bank / clearing partner handles actual presentment; we capture the item and present its image asynchronously — we are not clearing in real time.
Provisional credit : a "successful" deposit is a provisional, held credit subject to return ; availability is gated by a Reg CC-compliant hold, not granted instantly.
SLA targets : submission ack P95 < 800 ms (ack = "received & queued"); full adjudication is asynchronous (seconds-to-minutes, longer for manual review).

What a Strong Answer Covers Premium

Follow-up Questions Guidance

Be ready for deeper probes after the main design:

A late duplicate hit or risk signal arrives after you've accepted a deposit but before the hold releases. How does your state machine and ledger handle downgrading or clawing back funds without a double-spend?
OCR returns conflicting amounts — the courtesy box (CAR), the written line (LAR), and the user-entered amount all disagree. Which wins, and when do you auto-approve vs. route to manual review?
How do you detect the same physical check deposited twice across two different users/devices? What's your exact-match key, and how do you also catch a re-photographed check (and which index supports that lookup)?
At 100× the deposit volume during a holiday payday spike, what breaks first — the OCR workers, the ledger primary, object storage, or the status-read path — and how does your design degrade gracefully rather than drop deposits?