Design a signup system for a bank

Reference Answer

For a full example answer with detailed architecture diagrams and deep dives, see our Design Payment System guide. While the payment guide focuses on transaction processing, many of the same patterns around multi-step workflows, idempotency, and ACID guarantees apply directly to bank onboarding flows.

Also review the Message Queues and Databases building blocks for background on asynchronous processing and transactional storage.

Problem Statement

Design a bank signup system that allows users to create accounts with email verification, automatically opens their bank account upon successful verification, and initiates a payment card order. The platform must handle the full onboarding lifecycle from initial registration through identity verification, account provisioning, and card fulfillment.

Think of the account-opening flows at digital banks like Capital One, N26, or Revolut. A user enters their personal details, receives a verification email, completes identity checks, and within minutes has a fully provisioned bank account with a card on the way. The system must be secure, reliable, and compliant with financial regulations while providing a smooth user experience even during marketing-driven traffic spikes.

Key Requirements

Functional

• User Registration -- users submit personal details (name, email, address, SSN) and receive a verification email with a time-limited token or one-time passcode
• Email Verification -- users confirm ownership by clicking a link or entering a code; support resending verification and handling expired or invalid tokens
• Account Provisioning -- upon successful verification, the system automatically opens a bank account (checking or savings) and assigns an account number
• Card Ordering -- after account creation, the system initiates a debit or credit card order through a fulfillment partner
• Onboarding Status -- users can view their progress (pending verification, account opened, card ordered, card shipped) and receive notifications at each stage

Non-Functional

• Reliability -- each onboarding step must complete exactly once; no duplicate accounts or card orders even under retries and failures
• Security -- encrypt PII at rest and in transit; verification tokens must be short-lived and rate-limited to prevent brute force
• Scalability -- handle traffic spikes during marketing campaigns (10x normal registration volume) without degrading the experience
• Consistency -- strong consistency for account creation and card ordering; eventual consistency acceptable for status display and notifications

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Multi-Step Workflow Orchestration

The signup process spans multiple services and external vendors (email provider, KYC service, card fulfillment). Interviewers want to see how you coordinate these steps reliably, handle partial failures, and ensure the workflow can resume from any point.

Hints to consider:

• Model the onboarding as a saga or state machine with explicit states (registered, email_verified, kyc_passed, account_opened, card_ordered)
• Use a durable workflow engine (Temporal, Step Functions) or an outbox pattern with a message queue like Kafka to drive transitions
• Implement compensating actions for each step so failures can be rolled back or retried cleanly
• Persist workflow state in PostgreSQL so progress survives service restarts

2. Idempotency and Duplicate Prevention

Users may click verification links multiple times, marketing campaigns can trigger duplicate registrations, and network retries are inevitable. Interviewers probe how you prevent creating duplicate accounts or ordering multiple cards.

Hints to consider:

• Use unique constraints on email in PostgreSQL to prevent duplicate user records at the database level
• Assign idempotency keys to each workflow step so retries produce the same outcome
• Store verification tokens in Redis with TTL to enforce expiration and prevent replay attacks
• Make card ordering idempotent by including the account ID as a deduplication key with the fulfillment provider

3. Security and Compliance for PII

Bank onboarding involves sensitive data (SSN, address, date of birth). Interviewers expect comprehensive security measures and awareness of regulatory requirements.

Hints to consider:

• Encrypt sensitive fields (SSN, date of birth) at the application level before storing in the database using envelope encryption with AWS KMS or HashiCorp Vault
• Rate-limit verification endpoints to prevent enumeration and brute-force attacks
• Use short-lived tokens (15-30 minutes) for email verification and invalidate them immediately after use
• Log all access to PII with audit trails for regulatory compliance (BSA/AML, KYC requirements)

4. Handling External Service Failures

KYC vendors, email providers, and card fulfillment partners all have their own failure modes and latencies. Interviewers assess whether you can decouple these dependencies from the user-facing flow.

Hints to consider:

• Process KYC and card ordering asynchronously using background workers consuming from a message queue
• Implement circuit breakers around external calls to prevent cascading failures
• Use exponential backoff with jitter for retries and a dead-letter queue for permanently failed requests
• Provide users with status polling or push notifications so they are not blocked waiting for synchronous responses

Suggested Approach

Step 1: Clarify Requirements

Confirm the scope with your interviewer. Ask whether the system needs to support multiple account types (checking, savings, credit) at signup or just one. Clarify whether KYC/identity verification is in scope or can be treated as an external service call. Determine the expected registration volume and whether the system needs to handle international users with different compliance requirements. Ask about the card fulfillment timeline and whether virtual cards should be issued immediately.

Step 2: High-Level Architecture

Sketch the core components:

• API Gateway -- handles authentication, rate limiting, and request routing
• Registration Service -- accepts user details, validates input, stores user records in PostgreSQL, and publishes a registration event
• Verification Service -- generates and validates email tokens stored in Redis, triggers account provisioning on success
• Workflow Orchestrator -- coordinates the multi-step onboarding saga (verification, KYC, account creation, card ordering)
• Account Service -- provisions bank accounts with unique account numbers in the core banking database
• Card Service -- interfaces with the card fulfillment partner to order physical or virtual cards
• Notification Service -- sends emails, SMS, and push notifications at each stage
• Message Queue (Kafka) -- decouples services and enables reliable, at-least-once delivery between steps

Step 3: Deep Dive on Workflow Reliability

Walk through the critical path from registration to card ordering. When a user submits the registration form, the Registration Service writes the user record and a corresponding outbox event in a single PostgreSQL transaction. A CDC connector or polling publisher pushes the event to Kafka. The Verification Service generates a token, stores it in Redis with a 30-minute TTL, and sends the verification email. When the user clicks the link, the Verification Service validates the token, marks the user as verified in a single atomic update, and publishes a verified event. The Workflow Orchestrator consumes this event and drives the remaining steps: call the KYC service, create the bank account, and order the card. Each step is idempotent and recorded in a workflow state table. If any step fails, the orchestrator retries with backoff. If the KYC check fails permanently, a compensating action notifies the user and cleans up partial state.

Step 4: Address Secondary Concerns

Discuss how to handle traffic spikes from marketing campaigns by auto-scaling stateless services and using Kafka consumer groups to parallelize processing. Cover database sharding strategy if scale demands it (partition by user_id). Address monitoring: track registration-to-activation conversion rates, step completion latencies, and failure rates per external dependency. Set up alerts for verification token abuse, KYC service degradation, and card ordering backlogs. Finally, discuss disaster recovery with multi-AZ database replication and regular backup testing.

Real Interview Quotes

"Design a scalable banking application. You should be able to handle users and accounts (CRUD). Users can have more than 1 account, though they typically won't have more than a few. Security and ACID are a must. Be sure to optimize for mass transactions (I.E., payday)."

"Design a signup system for a bank which will send a verification email, opens a bank account and orders a card."