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 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 N26 or Capital One. A user enters personal details, receives a verification email, completes identity checks, and within minutes has a 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. Interviewers use this question to test whether you can design ACID-critical workflows that cross service boundaries, handle asynchronous steps (email delivery, KYC vendor calls, card provider integration), and maintain data integrity under retries and surges.

Key Requirements

Functional

• User registration -- Users sign up with an email and basic personal details and receive a verification message
• Email verification -- Users verify their email via a link or one-time code, including resend capability and handling of expired or invalid tokens
• Automatic account opening -- Upon successful verification, the system provisions a bank account and initiates a payment card order
• Onboarding status tracking -- Users view their current status (pending verification, account opened, card ordered) and receive notifications at each milestone

Non-Functional

• Scalability -- Handle thousands of concurrent signups during marketing campaigns without degrading the experience
• Reliability -- Zero tolerance for duplicate accounts or card orders; system must recover gracefully from partial failures at any step
• Security -- PII encrypted at rest and in transit; verification tokens are short-lived and rate-limited; endpoints protected against brute-force attacks
• Consistency -- Strong consistency for account creation and financial operations; eventual consistency acceptable for status notifications

What Interviewers Focus On

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

1. Multi-Step Workflow Orchestration

Signup is not a single transaction but a sequence of steps that span multiple services and external vendors: registration, email delivery, verification, KYC check, account creation, and card ordering. Each step can fail independently, and the system must recover without leaving the user in an inconsistent state.

Hints to consider:

• Model the onboarding flow as a state machine with well-defined transitions: registered, email-sent, verified, kyc-passed, account-opened, card-ordered
• Use a durable workflow engine or saga pattern to coordinate steps, persist progress, and resume from the last successful state after a failure
• Implement compensating actions for each step (for example, if card ordering fails after account creation, do not roll back the account but instead retry card ordering)
• Store workflow state in a transactional database alongside the user record to avoid split-brain scenarios

2. Idempotency and Duplicate Prevention

Users may click the verification link multiple times, submit the registration form twice, or retry during a timeout. Without safeguards, these retries can create duplicate accounts or trigger multiple card orders.

Hints to consider:

• Generate a stable idempotency key (derived from email address for registration, or from user ID plus step name for downstream actions) and check it before executing any side effect
• Use unique database constraints on email address and account identifiers to enforce at-most-once creation at the storage layer
• Make each workflow step idempotent so that re-executing it after a crash produces the same result without duplicate side effects
• Return the existing result for a duplicate request rather than an error, so the user experience remains smooth

3. Verification Token Security

The email verification step is a security-sensitive surface. Weak token generation or lax validation can allow account takeovers or enumeration attacks.

Hints to consider:

• Generate cryptographically random tokens (at least 128 bits of entropy) with a short TTL (for example, 15 minutes)
• Store tokens as hashed values in the database so a database breach does not expose valid tokens
• Rate-limit verification attempts per IP and per email to block brute-force attacks
• Invalidate the token immediately upon successful verification to prevent replay

4. External Service Integration

KYC vendors, email providers, and card fulfillment services are external dependencies with variable latency, rate limits, and failure modes. The system must handle these gracefully.

Hints to consider:

• Call external services asynchronously via a durable message queue so that a slow vendor does not block the user-facing API
• Implement circuit breakers and exponential backoff for each external integration
• Use webhooks or polling to receive asynchronous results from vendors (for example, KYC pass/fail decisions)
• Store all external call results in an audit log for compliance and debugging

5. Scaling Under Marketing Spikes

Product launches and promotional campaigns drive sudden surges in signup traffic. The system must absorb these spikes without dropping requests or creating long queues.

Hints to consider:

• Use a queue-based admission pattern where registration requests are accepted quickly and processed asynchronously
• Auto-scale the worker fleet that processes verification and onboarding steps based on queue depth
• Cache frequently read data (for example, onboarding status) to reduce database load during high-traffic periods
• Implement graceful degradation: if a non-critical service (for example, the welcome email) is slow, continue the core onboarding flow and retry the email later

Suggested Approach

Step 1: Clarify Requirements

Ask about the expected signup volume (steady state and peak), which identity verification steps are required (email only, phone, government ID, selfie), whether the system needs to support multiple account types (checking, savings, joint), and what compliance frameworks apply (KYC, AML, GDPR). Confirm whether the card ordering step blocks the user from using their account or if the account is usable immediately. Establish SLAs for each onboarding stage.

Step 2: High-Level Architecture

Sketch the major components: a registration API that accepts user details and enqueues the onboarding workflow, a workflow orchestrator that drives the state machine through each step, an email service for sending verification messages, a verification service that validates tokens and advances state, a KYC integration service that calls external vendors, an account service that provisions bank accounts in the core banking ledger, a card service that initiates card ordering with the fulfillment provider, and a notification service that keeps users informed. Back these with a Postgres database for transactional user and account records, a Redis cache for tokens and rate limiting, and Kafka for reliable event delivery between services.

Step 3: Deep Dive on the Onboarding Workflow

Walk through the happy path. The user submits the registration form; the API validates inputs, writes a user record with status "registered," generates a verification token, and publishes a "send-verification-email" event to Kafka. The email service consumes the event and calls the email provider. The user clicks the link; the verification service validates the token, advances the user to "verified," and publishes a "user-verified" event. The KYC service consumes this event, calls the vendor, and upon a pass result publishes "kyc-passed." The account service consumes that event, opens the account in a database transaction, and publishes "account-opened." The card service consumes that event and initiates the card order. At each step, the workflow state is persisted so that a crash at any point allows resumption from the last committed state.

Step 4: Address Secondary Concerns

Cover security by encrypting PII fields at rest using field-level encryption, enforcing TLS for all communication, and storing verification tokens as salted hashes. Discuss compliance by maintaining an immutable audit log of every state transition and external vendor interaction. Address monitoring by tracking conversion rates at each funnel stage (registered to verified to account-opened to card-ordered), alert on anomalous drop-off rates, and measure end-to-end onboarding latency. Touch on testing by using idempotent sandbox modes for external vendors during development. If time allows, discuss multi-region deployment for global banks with data residency requirements.

Real Interview Insights

Candidates at N26 report that the interviewer specifically asked them to design a signup system that sends a verification email, opens a bank account, and orders a card. The focus was on how these steps are coordinated reliably and how the system handles partial failures. Capital One interviews on similar topics emphasize ACID guarantees, security for mass transactions (for example, payday spikes), and the ability for users to hold multiple accounts.