A small bank that locks an account after three wrong passwords

The problem

Many beginner banking programs let anyone in. There is no login and nothing protects the balance, so they teach the arithmetic and skip the part that makes it a bank. Our intermediate programming course asked for a project that pulled several Java ideas together, so we chose a bank with passwords at its centre.

We also wanted it to feel like a program, not an exercise. Instead of typing into a console, you answer dialog boxes (Java's JOptionPane).

What we built

• Two classes with clear jobs. BankAccount holds one account's balance, password and history behind private fields. Bank keeps every account in an ArrayList, hands out account numbers from 1001 and moves money between accounts.
• A lock after three wrong passwords. The account locks itself, and only the admin menu can unlock it or reset the password.
• Everyday banking. Open an account with a first deposit, check the balance, deposit, withdraw (never below zero), transfer to another account and read the transaction list.
• An admin menu. Unlock or reset an account, or view all accounts, behind its own password.
• Input checks. Amounts and account numbers are checked before they are used, and every action ends with a message saying what happened.

How it turned out

It is a class project with no real users, so there are no figures to report. It runs from the dialog menus end to end, and the code is public.

Our idea paper promised five features: account creation, login, deposit, withdrawal and balance. The finished program has four more: the transaction history, transfers, the three-strikes lock and the admin menu.

What I would do differently

Everything lives in memory, so closing the program wipes every account; it needs a file or a database. Passwords are stored and compared as plain text and should be hashed. The admin password was written straight into the source, so in the public copy I replaced it with an obvious demo value. The amount check only accepts digits, which means 50.50 is rejected. And the paper promised try/catch validation where the code uses a hand-written digit check. A proper window with buttons and a table would also read better than a chain of dialog boxes.