Sequence Diagrams for Banking Systems: ATM, Online Banking, and Payment Flows

Banking systems are among the most common subjects for sequence diagram assignments and enterprise documentation. The flows involve multiple systems (ATM, core banking, authentication, fraud detection), strict error handling, and complex authorization rules. Here are four complete, copy-paste-ready sequence diagrams covering the most common banking flows.

Every diagram works in our free sequence diagram tool. Paste, render, export as PNG or SVG for your assignment or documentation.

1. ATM Cash Withdrawal: The Complete Flow

The classic software engineering assignment. This version includes card validation, PIN verification with retry limits, balance checking, and cash dispensing:

sequenceDiagram
    actor Customer
    participant ATM
    participant Bank as Bank Core System
    participant Fraud as Fraud Detection
    participant Account as Account DB

    Customer->>ATM: Insert card
    ATM->>Bank: Read card details
    Bank->>Account: Validate card
    alt Card valid
        Account-->>Bank: Card active
        Bank-->>ATM: Proceed

        loop PIN attempts (max 3)
            Customer->>ATM: Enter PIN
            ATM->>Bank: Verify PIN
            alt PIN correct
                Bank-->>ATM: Authenticated
            else PIN incorrect
                Bank-->>ATM: Try again
                ATM-->>Customer: Wrong PIN, retry
            end
        end

        Customer->>ATM: Select Withdrawal
        Customer->>ATM: Enter amount
        ATM->>Bank: Request withdrawal
        Bank->>Fraud: Risk check
        alt Low risk
            Fraud-->>Bank: Approved
            Bank->>Account: Check balance
            alt Sufficient funds
                Account-->>Bank: Balance OK
                Bank->>Account: Debit amount
                Account-->>Bank: Updated
                Bank-->>ATM: Approved
                ATM-->>Customer: Dispense cash
                ATM-->>Customer: Print receipt
            else Insufficient funds
                Account-->>Bank: Balance too low
                Bank-->>ATM: Declined
                ATM-->>Customer: Insufficient funds
            end
        else High risk
            Fraud-->>Bank: Flag transaction
            Bank-->>ATM: Additional verification required
            ATM-->>Customer: Please contact bank
        end
    else Card invalid
        Account-->>Bank: Card blocked
        Bank-->>ATM: Reject
        ATM-->>Customer: Card blocked, contact bank
    end

Notice the nested alt blocks. This mirrors real ATM logic: card valid? PIN correct? Low risk? Sufficient funds? Each gate must pass for the withdrawal to complete. The loop for PIN attempts shows the typical 3-try limit before the card is retained.

2. Online Banking Login with 2FA

Modern online banking involves multi-factor authentication. This diagram shows password authentication followed by OTP verification:

sequenceDiagram
    actor User
    participant Browser
    participant Web as Banking Web App
    participant Auth as Auth Service
    participant OTP as OTP Service
    participant Account as Account DB

    User->>Browser: Enter banking URL
    Browser->>Web: GET /login
    Web-->>Browser: Login page

    User->>Browser: Enter username + password
    Browser->>Web: POST /auth/login
    Web->>Auth: Verify credentials
    Auth->>Account: Find user
    Account-->>Auth: User record
    Auth->>Auth: Verify password hash

    alt Credentials valid
        Auth-->>Web: Primary auth OK
        Web->>OTP: Generate OTP
        OTP->>OTP: Send SMS/Email
        OTP-->>Web: OTP sent
        Web-->>Browser: Enter OTP page
        Browser-->>User: Request OTP

        User->>Browser: Enter OTP
        Browser->>Web: POST /auth/verify-otp
        Web->>OTP: Validate code
        alt OTP valid
            OTP-->>Web: Authenticated
            Web->>Auth: Create session
            Auth-->>Web: Session token
            Web-->>Browser: 200 + Set-Cookie
            Browser-->>User: Redirect to dashboard
        else OTP invalid
            OTP-->>Web: Invalid code
            Web-->>Browser: Error
            Browser-->>User: Wrong OTP, try again
        end
    else Credentials invalid
        Auth-->>Web: 401 Unauthorized
        Web-->>Browser: Error
        Browser-->>User: Login failed
    end

The flow has two authentication gates: password verification, then OTP verification. Both must pass. Notice that the error response for "wrong password" and "user not found" should be identical to prevent account enumeration. In a real banking system, there would also be account lockout after repeated failures.

Sell Custom Apparel — We Handle Printing & Free Shipping

3. Fund Transfer Between Accounts

sequenceDiagram
    actor User
    participant Web
    participant Core as Core Banking
    participant Fraud
    participant Source as Source Account
    participant Dest as Destination Account
    participant Notify as Notification Service

    User->>Web: Initiate transfer (amount, destination)
    Web->>Core: Transfer request
    Core->>Fraud: Risk assessment
    Fraud->>Fraud: Check patterns, amount, destination

    alt Low risk
        Fraud-->>Core: Approved
        Core->>Source: Verify balance
        alt Sufficient funds
            Source-->>Core: Balance OK
            Core->>Dest: Verify recipient
            Dest-->>Core: Recipient valid

            Note over Source,Dest: Begin transaction
            Core->>Source: Debit amount
            Source-->>Core: Debited
            Core->>Dest: Credit amount
            Dest-->>Core: Credited
            Note over Source,Dest: Commit transaction

            Core-->>Web: Transfer complete
            Web-->>User: Success confirmation

            par Send notifications
                Core->>Notify: Email sender
            and
                Core->>Notify: Email recipient
            and
                Core->>Notify: SMS if high value
            end
        else Insufficient funds
            Source-->>Core: Balance too low
            Core-->>Web: Declined
            Web-->>User: Insufficient funds
        end
    else High risk
        Fraud-->>Core: Flag for review
        Core-->>Web: Pending verification
        Web-->>User: Transfer pending, expect call
    end

The "par" block at the end shows notifications going out in parallel. In production systems, these notifications are usually asynchronous via message queues. The diagram's "Begin transaction" and "Commit transaction" notes indicate that the debit and credit operations happen atomically. In a real core banking system, this is a critical requirement: both operations succeed or both roll back. A partial completion would be financially disastrous.

4. Online Bill Payment

sequenceDiagram
    actor Customer
    participant App as Banking App
    participant Core as Core Banking
    participant Biller as Biller Network
    participant Payment as Payment Gateway
    participant Account

    Customer->>App: Select Pay Bill
    App->>Biller: Get biller list
    Biller-->>App: Available billers
    App-->>Customer: Show billers

    Customer->>App: Select biller + enter account
    App->>Biller: Validate biller account
    alt Account valid
        Biller-->>App: Valid, show amount due
        App-->>Customer: Show bill details

        Customer->>App: Confirm payment
        App->>Core: Initiate payment
        Core->>Account: Verify balance
        Account-->>Core: Balance OK
        Core->>Payment: Send to payment gateway
        Payment->>Biller: Transfer funds
        alt Payment successful
            Biller-->>Payment: Confirmed
            Payment-->>Core: Payment complete
            Core->>Account: Debit amount
            Account-->>Core: Debited
            Core-->>App: Success
            App-->>Customer: Bill paid + confirmation number
        else Payment failed
            Biller-->>Payment: Rejected
            Payment-->>Core: Failed
            Core-->>App: Payment failed
            App-->>Customer: Error, try again
        end
    else Invalid account
        Biller-->>App: Account not found
        App-->>Customer: Invalid biller account
    end

Bill payments involve a third party (the biller) outside the bank's direct control. The diagram makes this interaction explicit. Notice the ordering: validate the biller account first, then show the bill, then confirm payment, then execute. Each step is a gate that can fail independently.

For more example diagrams covering e-commerce, library systems, and hospital scheduling, see our 8 sequence diagram examples guide.

Frequently Asked Questions

How do I draw a sequence diagram for an ATM system?

Include these participants: Customer (actor), ATM, Bank Core System, and Account DB. Show card insertion, PIN verification (with retry loop and alt blocks for correct/incorrect), withdrawal amount entry, fraud check, balance verification, and cash dispensing. The complete flow has multiple nested alt blocks for each validation gate.

What is the sequence diagram for online banking login?

Show User, Browser, Web App, Auth Service, OTP Service, and Account DB. The flow has two authentication gates: password verification first, then OTP verification. Use alt blocks for each gate to show both success and failure paths. Include session token creation after successful authentication.

How do you model a fund transfer in a sequence diagram?

Participants: User, Web, Core Banking, Source Account, Destination Account, Fraud Detection, Notification Service. Show risk assessment, balance verification, atomic debit/credit (with Note annotations for transaction boundaries), and parallel notification dispatch. Include alt blocks for insufficient funds and high-risk scenarios.

What are the key elements of a banking sequence diagram?

Multiple validation gates (alt blocks for each check), explicit fraud detection step, atomic transactions for debit/credit operations (Notes for transaction boundaries), parallel notifications (par block), and detailed error paths. Banking diagrams typically have more nested control flow than simpler examples.