Class Diagram for Banking System: Full UML Example with Mermaid Syntax

Banking systems are a classic object-oriented design exercise — they have enough complexity to be interesting, enough real-world familiarity to be intuitive, and enough standard entities that the diagram structure is widely agreed upon. Bank account class diagrams appear in every OOP textbook for good reason.

This post provides a complete, realistic UML class diagram for a banking system broken into logical subsystems, with Mermaid syntax you can paste directly into the free Badger Class Diagram tool.

Core Entities: Customer, Account, and Transaction

classDiagram
  class Customer {
    +String customerId
    +String firstName
    +String lastName
    +String email
    +String phone
    +Date dateOfBirth
    +String nationalId
    +openAccount(type String) Account
    +getAccounts() List
    +updateContact(data) void
  }
  class Account {
    <<abstract>>
    +String accountNumber
    +float balance
    +Date openedDate
    +String status
    +deposit(amount float) void
    +withdraw(amount float) bool
    +getBalance() float
    +getStatement(from Date) List
  }
  class SavingsAccount {
    +float interestRate
    +int minBalance
    +calculateInterest() float
  }
  class CheckingAccount {
    +float overdraftLimit
    +float monthlyFee
    +processOverdraft(amount) void
  }
  class Transaction {
    +String transactionId
    +float amount
    +String type
    +DateTime timestamp
    +String description
    +String status
    +getReceipt() String
  }
  Customer "1" --> "1..*" Account : owns
  Account <|-- SavingsAccount
  Account <|-- CheckingAccount
  Account "1" *-- "0..*" Transaction : records

Account is abstract — no one opens a generic "account," they open a savings or checking account. SavingsAccount and CheckingAccount are concrete implementations. Transactions belong exclusively to an Account (composition).

Loans and Credit Products

classDiagram
  class Loan {
    +String loanId
    +float principalAmount
    +float interestRate
    +int termMonths
    +Date startDate
    +String status
    +calculateMonthlyPayment() float
    +makePayment(amount float) void
    +getRemainingBalance() float
  }
  class PersonalLoan {
    +String purpose
    +bool isSecured
  }
  class MortgageLoan {
    +String propertyAddress
    +float propertyValue
    +float downPayment
  }
  class LoanPayment {
    +String paymentId
    +float amount
    +float principal
    +float interest
    +Date paymentDate
  }
  Loan <|-- PersonalLoan
  Loan <|-- MortgageLoan
  Loan *-- LoanPayment
  Customer "1" --> "0..*" Loan : applies for

Sell Custom Apparel — We Handle Printing & Free Shipping

Cards and Payment Methods

classDiagram
  class Card {
    <<abstract>>
    +String cardNumber
    +String cardholderName
    +Date expiryDate
    +String cvv
    +String status
    +activate() void
    +block() void
    +isValid() bool
  }
  class DebitCard {
    +Account linkedAccount
    +float dailyLimit
    +makePayment(amount float) bool
  }
  class CreditCard {
    +float creditLimit
    +float currentBalance
    +float minimumPayment
    +float apr
    +makePayment(amount float) bool
    +getStatementBalance() float
  }
  Card <|-- DebitCard
  Card <|-- CreditCard
  DebitCard --> Account : linked to
  Customer "1" --> "0..*" Card : holds

Branch and Staff Structure

classDiagram
  class Branch {
    +String branchId
    +String branchCode
    +String address
    +String city
    +String phone
    +getStaffCount() int
    +getActiveAccounts() int
  }
  class BankEmployee {
    +String employeeId
    +String role
    +String department
    +Date hireDate
    +login(credentials) bool
  }
  class Teller {
    +int transactionsToday
    +processDeposit(account, amount) void
    +processCashWithdrawal(account, amount) void
  }
  class LoanOfficer {
    +List activeApplications
    +reviewApplication(loan) bool
    +approveLoan(loan) void
    +rejectLoan(loan, reason) void
  }
  Branch *-- BankEmployee
  BankEmployee <|-- Teller
  BankEmployee <|-- LoanOfficer
  LoanOfficer "1" --> "0..*" Loan : approves

Transfers and Wire Payments

classDiagram
  class Transfer {
    +String transferId
    +float amount
    +String currency
    +DateTime initiatedAt
    +String status
    +String reference
    +execute() bool
    +cancel() bool
    +getStatus() String
  }
  class InternalTransfer {
    +Account sourceAccount
    +Account destinationAccount
    +validate() bool
  }
  class WireTransfer {
    +String routingNumber
    +String receivingBankName
    +String receivingAccountNumber
    +float fee
    +String swiftCode
    +submitToNetwork() bool
  }
  Transfer <|-- InternalTransfer
  Transfer <|-- WireTransfer
  Customer "1" --> "0..*" Transfer : initiates
  InternalTransfer --> Account : from
  InternalTransfer --> Account : to

Transfers are polymorphic — internal transfers move money between accounts in the same bank, while wire transfers go to external institutions. Both share the base Transfer class (status, amount, reference) but have different execution logic.

Frequently Asked Questions

Is this class diagram suitable for a software engineering assignment on a banking system?

Yes. The structure covers all major banking entities typically required. Adjust the scope to match your specific assignment requirements — you may need to add or remove subsystems depending on the features specified.

Why is Account shown as abstract in this diagram?

Because in a real banking system you always open a specific account type (savings, checking, money market) — there is no such thing as a generic "account." Marking Account as abstract enforces this constraint: you can only instantiate subclasses.

How do I draw these diagrams in the free online tool?

Copy any Mermaid code block above and paste it into the Badger Class Diagram tool. The diagram renders live. Click Export PNG to download a clean, watermark-free image.

What relationship should I use between Customer and Account?

A directed association with cardinality: Customer "1" --> "1..*" Account. A customer must have at least one account, and an account belongs to a customer. Composition is not appropriate here because accounts can be transferred or joint-owned.