Design a personal finance aggregator

Quick Overview

This question evaluates skills in large-scale system design including API and third-party integrations, data ingestion and normalization, transactional consistency and idempotency, security and privacy controls, data modeling for multi-currency financial records, and operational concerns like alerts and budgeting.

Design a personal finance aggregator

Company: Perplexity

Role: Software Engineer

Category: System Design

Difficulty: hard

Interview Round: Technical Screen

Design a personal finance aggregation platform similar to Mint that connects to banks, credit cards, and loans to ingest transactions and balances. Specify the API/ingestion approach (aggregator vs. direct connections, OAuth/OFX), data normalization and deduplication, categorization and budgeting services, alerting/notifications, reconciliation and idempotency, privacy and security controls (encryption, tokenization, PCI scope), scalability and storage design, failure and latency handling for third-party APIs, and a consistent data model supporting multi-currency and recurring bills.

Overview: This question evaluates skills in large-scale system design including API and third-party integrations, data ingestion and normalization, transactional consistency and idempotency, security and privacy controls, data modeling for multi-currency financial records, and operational concerns like alerts and budgeting.

|Home/System Design/Perplexity
Perplexity logo
Perplexity
Aug 13, 2025
hardSoftware EngineerTechnical ScreenSystem Design
26
0

System Design: Personal Finance Aggregation Platform (Mint-like)

Context

Design a consumer-facing platform that aggregates a user's financial data across banks, credit cards, loans, and other institutions. The system ingests balances and transactions, normalizes data, categorizes spending, supports budgeting, and provides alerts. Assume a modern technical screen context and aim for a pragmatic, production-ready design.

Assumptions (minimal):

  • Scale: 1–5M users, each with 2–6 linked accounts; daily ingestion volume in the tens of millions of transactions.
  • Data freshness: near-real-time via webhooks where available; otherwise periodic polling (e.g., hourly to daily).
  • Regions: initially single region with future multi-region readiness.

Requirements

  1. API/ingestion: choose aggregator vs. direct connections; authenticate via OAuth/Open Banking where possible; legacy OFX if needed.
  2. Data processing: normalization and deduplication across sources; consistent signs and timestamps.
  3. Categorization and budgeting: rules/ML categorization; budgets by category with rollovers and sharing.
  4. Alerts/notifications: thresholds, anomalies, upcoming bills; delivery via push/email/in-app.
  5. Reconciliation and idempotency: pending-to-posted transitions, retries, and exactly-once semantics.
  6. Privacy/security: encryption, tokenization, consent, PCI scope minimization.
  7. Scalability/storage: service boundaries, data stores, partitioning, and caching.
  8. Failure/latency handling: third-party API slowness/outages, rate limits, backoff, and graceful degradation.
  9. Data model: consistent schema supporting multi-currency and recurring bills/subscriptions.

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...

Browse More Questions

More System Design•More Perplexity•More Software Engineer•Perplexity Software Engineer•Perplexity System Design•Software Engineer System Design