GROUP ASSIGNMENT

CT108-3-1-PYP
Python Programming
INTAKE CODE
NP1F2507IT

Python programming (PYP)

HAND OUT DATE: 22 September 2025

HAND IN DATE: 19 December 2025

Submitted by: Submitted to:

Sansar Chhetri (NP070995) Mr. Bishal prasad Kurmi
Satya Raj Joshi (NP070996)
Raj Kumar Tiruwa (NP070980)
 1. Acknowledgement
We would like to sincerely thank Mr. Bishal Prasad Kurmi, our lecturer, for all of his

help, support, and insightful criticism during the course of this assignment. His helpful advice

and concise explanations of programming concepts were crucial to the accomplishment of our

Banking Service System project. We have grateful thoughts for the university because it offers

what we need and the place to raise our coding plus problem solution abilities. During a

homework, we managed to work with Python codes so that we could put theory into practical

working in actual things.

Lastly, we would like to thank the group members Sonar Chhetri, Raj Kumar Tiruwa, and Satya

Raj Joshi for their cooperation and teamwork, which were essential to the successful completion

of this project.
 Table of Contents
1. Acknowledgement.......................................................................................................................2
2. Abstract........................................................................................................................................6
3. Introduction..................................................................................................................................7
4. Input validation and program logic..............................................................................................8
4.1 Email validation logic............................................................................................................8
4.2 Password validation logic......................................................................................................8
4.3 New credentials validation....................................................................................................9
4.4 Balance withdraw logic........................................................................................................10
5. Aim and Objectives....................................................................................................................11
5.1 Aim.......................................................................................................................................11
5.2 Objectives.............................................................................................................................11
6. Feasibility Study........................................................................................................................11
6.1 Technical Viability...............................................................................................................12
6.2 The viability of operations...................................................................................................12
6.3 Financial Viability................................................................................................................12
7. Programming concept implemented..........................................................................................13
7.1 Functional Programming......................................................................................................13
7.2 File Handling........................................................................................................................14
7.2.1 Read Mode (r)...............................................................................................................14
Key Characteristics:...............................................................................................................14
7.2.2 Write Mode (w).............................................................................................................15
7.2.3 Append Mode (a)...........................................................................................................15
8. Assumptions and limitations......................................................................................................16
8.1 Assumptions.........................................................................................................................16
8.2 Limitations...........................................................................................................................17
9. System design............................................................................................................................18
9.1 Folder structure description.................................................................................................18
9.1.1 The root(main) directory:.............................................................................................19
9.1.2 [Link].......................................................................................................................20
 9.2 Cred_files folder..................................................................................................................20
9.2.1 [Link] :.....................................................................................................................21
9.2.2 [Link]..........................................................................................................................22
9.2.3 [Link]...........................................................................................................................23
9.2.4 [Link]..............................................................................................................23
9.3 Functions folder...................................................................................................................24
9.3.1 Admin_feature.py..........................................................................................................26
9.3.2 Admin_feature_validation.py........................................................................................27
9.3.3 Cli_utils.py....................................................................................................................27
9.3.4 Customer_features.py....................................................................................................28
9.3.5 Staff_feature.py.............................................................................................................29
9.3.6 Intital_login_mail_checker.py.......................................................................................30
9.3.7 [Link].......................................................................................................................31
10. Flowcharts................................................................................................................................32
10.1 overall system flowchart....................................................................................................32
10.2 Admin feature flowchart....................................................................................................33
10.3 Staff features flowchart......................................................................................................34
10.4 users features flowchart.....................................................................................................36
11. Pseudocodes.............................................................................................................................37
11.1 Overall system pseudocodes..............................................................................................37
11.2 Pseudocode of admin features............................................................................................39
11.3 Admin feature validation....................................................................................................41
11.4 Staff feature........................................................................................................................43
11.5 customer /user feature........................................................................................................49
12. Testing......................................................................................................................................54
12.1 Tests related to login..........................................................................................................54
Testing the range and the valid values....................................................................................54
................................................................................................................................................55
Testing for the admin login.....................................................................................................55
Testing for the staff login.......................................................................................................56
Testing for user login..............................................................................................................57
 Testing for the account creation.............................................................................................58
Future Enhancements.....................................................................................................................59
Conclusion.....................................................................................................................................60
Work breakdown matrix................................................................................................................61
References......................................................................................................................................62
 2. Abstract

The Banking management system is a user-based application designed to automate core

banking functionalities like user authentication, financial transactions, and generating financial

reports. Utilizing the two widely utilized python modules in OS and date time, the system stores

the customer data using a text file storage system. In this banking management system, there are

some key features like a secure login system using a strong password for the initial login by the

admin or the staff. The admin already has login credentials, and admin creates login credentials

for the staff. Here are also some features that customers can generate statements, can deposit an

account above Rs 1000 for saving, and withdraw the same amount at least 1000. The system

allows users to check balance, print statements, change passwords with the same staff to create

an account for the new customer to register, view all customer details, update customer details,

and generate statement for the customers. The system prioritizes data integrity and user

experience with the help of menu-driven interface and rigorous input validation.
 3. Introduction

Nowadays software systems are very crucial for organizations, because they help manage

data in a correct manner and with high efficiency. Since many work processes like employee

management or handling banking tasks have now turned digital, it is very important to use a

software program that is secure, stable and well designed. This project assignment emphasizes

the implementation Programming concepts for building real-life menu-driven system in Python

language. Furthermore, this project focuses on problem solving abilities and use modular

programming, work with files and validate inputs by following said rules.

The system designed for this assignment tries to demonstrate actual organization workflow by

using role-based access control and how users interact with system being implemented. This

project specifically deals with banking tasks and management, which includes registering new

customers, handling accounts, and dealing with the money transfers. Each user must log in, and

only a certain number of chances are allowed for security reasons. For managing the data usage

of text files has been done, so the information is saved and can be loaded again as databases or

visual interfaces are not used currently. In short, this approach kind of focuses on simplicity

rather than complexity.

This assignment aims at making students better at programming concepts like the functions ,

lists, file handling and making sure things are correct, and also, it tries to make sure that the

students cultivate good coding habits, like proper indenting and the naming of variables that

make sense, also identifying what is going on in codes.

 4. Input validation and program logic

4.1 Email validation logic

Figure 4.1:Email validation logic

Initially, the program checks the validity of an email address or its lack by checking the

simplest attributes of an email. such as its length and whether it has the precise number of

characters: single '@' sign, a dot, and a valid top-level domain (TLD). The email is then split into

two sections: the username and the domain; these are verified to the proper structure. Once the

format has been confirmed, the email will be searched in the records of the admin, staff, and

user, and in case a match is found, the program will give out a successful response; otherwise,

the email will be rejected.

4.2 Password validation logic

Figure 4.2: password validation logic
 First of all, the program gets the credentials of the program administrator, staff

members, the users, and places them into separate lists according to their respective files. then

the password is checked with the lists of passwords stored from the dedicated files of different

types of users. When the function gets a match, the function returns True therefore granting

access otherwise returns False thereby not allowing access to the users.

4.3 New credentials validation

Figure 4.3:New credentials validation logic
 The logic checks the staff or customer information that is new by loading the already

existing personnel or customer information into the system. It then checks all the data input into

the format, required length, and duplicates; hence, appropriate email verification is contained. In

case of any errors, the information is not accepted, in case no errors are found, the information is

accepted and stored successfully.

4.4 Balance withdraw logic

Figure 4.4 Balance withdraw logic.
 Withdrawal logic will authenticate the user account and the amount requested, determine

whether the balance is adequate after retaining a minimum required, deduct the amount of the

balance, update customer information, and record the transactions.

5. Aim and Objectives

5.1 Aim

The aim of this project assignment is to design a secure and efficient Banking Service

System that automates account managerial system, facilitate accounts managerial transactions,

and generate valid reports to the Admin, Staff and Customers using the system.

5.2 Objectives
The objective of this assignment is to implement a secure login system for Admin, Staff,

and Customers with limited login attempts to ensure security of the application Furthermore, it is

allowing Admin to manage staff accounts, and view details, and generate customer statements.

Similarly, allow Staffs to register new customers, update account details, and generate statements

for specified periods. The customers are allowed to deposit, withdraw, reset passwords, and

generate account statements while ensuring that they users can only withdraw the permitted

amount. Similarly, the system ensures data persistence using text files with proper validation to

prevent logical errors, provides a user-friendly menu-driven interface for smooth interaction with

the system.

6. Feasibility Study

To determine whether the suggested Banking Service System is workable, efficient, and

feasible given the limitations, a feasibility study was carried out. Technical, operational, and

financial viability are all covered in the study.

6.1 Technical Viability
Because Python is a popular and dependable programming language, the Banking Service

System is technically feasible. Only two built-in modules are needed for the system: date time

and OS, both of which are easily found in typical Python installations. The program does not

require sophisticated database systems because it stores data in text files. This method guarantees

portability and simplicity while fulfilling the assignment requirements. The application is

modular, menu-driven, and doesn't require sophisticated hardware or software to run on any

system that supports Python. Therefore, the system is completely implementable and feasible

from a technical standpoint.

6.2 The viability of operations

The menu-driven and user-friendly design of the system makes it simple for

administrators, employees, and customers to interact with it. Users are guided through various

operations, including account creation, deposits, withdrawals, and report generation, by clear

menu options. Security and usability are improved by authentication techniques like password

resets and login validation. Additionally, after three unsuccessful login attempts, the system

terminates to prevent unauthorized access and handles invalid inputs. As a result, the system can

be used in a small-scale banking setting and is operationally feasible.

6.3 Financial Viability

There are no costs associated with the Banking Service System; this is economically

viable. Instead of using expensive database systems, it stores data in text files using open-source

Python software. There is no need for other new devices and building up was done on the current

computers. This allows system to be low cost also fitting very well for smaller businesses or for

those interested in academic areas.

 7. Programming concept implemented

To guarantee dependability, maintainability, and adherence to the assignment

requirements, the Banking Service System was created utilizing fundamental Python

programming concepts. The system uses functions, file handling, and data structures efficiently

while taking an organized and modular approach. Together, these ideas improve the application's

scalability, efficiency, and clarity.

7.1 Functional Programming

One major concept that is used for building the system would be functional programming.

All independent and functional pieces compile to form a complete application with every piece

responsible for a distinct task (Downey, 2015). The functions that are used in the project

assignment are as follows:

1. User authentication (login for customers, employees, and administrators)

2. Account creation and customer registration

3. Transactions involving deposits and withdrawals

4. You can reset your password.

5. Statement of account creation

6. User input is checked for verification purposes.

Each function does one clear task and talks to others only through parameters and return

values, avoiding global variables as required. That makes bugs easier to find and lets you add

features later without changing the entire system. Modular programming also follows best

practices: it encourages code reuse, cuts redundancy, and makes testing more efficient.
 7.2 File Handling
File handling is a core part of the Banking Service System since all data management

is done with text files. Python’s file operations are used to store and retrieve the files

(Matthets, 1992). Similarly, the text files in our program store the following things as

mentioned below:

• Admin, staff, and customer details

• Customer account balances

• Transaction history (deposits and withdrawals)

• Login credentials

The system uses read (r), write (w), and append (a) types of modes for managing data with

more security and proper accuracy.

The different modes in file handling are explained as follows:

7.2.1 Read Mode (r)

The read mode is used when data needs to be retrieved from a file without modifying it.

In this mode, the file must already exist; otherwise, Python raises a File Not Found Error.

Purpose in the Banking Service System:

· Check login details of admin, staff, and customers.

· Getting the customer account information like an account number, kind of account, and

how much money is left.

· To read previous transaction records for account review and auditing.

Key Characteristics:
• Opens the file for reading only.

• Does not allow writing or modification of file content.

• Ensures data safety, as no accidental changes can occur.

• Useful for data validation and authentication processes.

7.2.2 Write Mode (w)

When writing mode is active, it makes a new file or removes everything from old one and

then writes added information. The data of the old file is deleted first.

Purpose in the Banking Service System:

 To update customer balances after deposits or withdrawals.

 For changing information in accounts, like changing the password or types of accounts.

 For saving updated details into the files again after the tasks are processed.

Important Features:

· Just open a file for writing content.

· Deletes what was inside before so added content is written from scratch.

· Python itself makes a new file if it is not there already.

· Requires validation checks to prevent data loss.

7.2.3 Append Mode (a)

Append mode helps to include fresh data at the last place of a file, not disturbing what

was already inside previously. If the file is not found, Python will make a new one. Purpose in

the Banking Service System:

• To record transaction history such as deposits and withdrawals.

• To store timestamps for each transaction.

• To maintain an audit trail for security and accountability.

Key features:

· Files containing the customer data are read when doing validation for logins.

· The transaction information gets appended in transaction files and they have time stamps.

· Updated balances are written back to files after each transaction.

This approach keeps data persistent after the program stops, meeting the requirement to store

everything in text files. Validation checks are applied to prevent incorrect or inconsistent data

from being written.

8. Assumptions and limitations

The development of the Banking Service System happens by taking many assumptions

and some limitations. These were identified during system analysis and design to ensure that the

scope of the project remains realistic and aligned with the assignment requirements.

8.1 Assumptions
The following assumptions were made while designing and implementing the system:

· All users (Admin, Administrative Staff, and Customers) will provide accurate and valid

information during registration and login processes.

· It is being assumed that in single-user environments the system is only accessed by one

user so multi-users are not allowed on the system together.

 · All text files where information gets stored are believed to be safe and that manual

changes outside of the program do not happen. The Admin account credentials are

predefined and known only to authorize personnel.

· A unique and sequential account number is automatically generated for each customer

and no duplication occurs.

· Customers maintain the required minimum balance (Rs. One thousand (1000) for Savings

accounts and Rs. 1500 for Current accounts) as enforced by the system.

· The system assumes that the system date and time are correct, as they are used for transaction

records and statement generation.

· Users have basic computer knowledge to interact with a menu-driven command-line interface.

8.2 Limitations

Although all the assignment guidelines are met still the system has some limits.

· This system cannot be used by more than an single user or accessed at same time by

multiple users. It was created for only one person to utilize. Data is stored in plain text

files, which may not be suitable for large-scale or real-world banking applications.

· Password encryption and advanced security mechanisms are not implemented due to

assignment constraints.

· The system works only by using command-line interface (CLI), and there is no graphical

user interface in it.

· The software does not let users do an online transaction or anything that uses networks.

Error handling is limited to basic validation and does not include advanced exception

logging.

· The system is not integrated with external banking systems or databases.

 · The transaction history size may affect performance if the text files become very large.

9. System design

The system has a Modular Design in that functions are segregated into different user roles

(Admin, Staff, Customer). Data is stored in Flat File Database format because data is always

available even when the program has been closed.

9.1 Folder structure description

Figure 2: Folder structure.

9.1.1 The root(main) directory:
Figure 4: Primary project folder
 This signifies the primary project folder that holds all the source codes, data files, and

add-ons required during the execution of the system.

9.1.2 [Link]

This is the main entry point of the overall program from where an user can get access to

all the features of the system according to the roles as defined in the program. This module is

situated under: Python_group_project_LBEF/admin_feature.py

Figure 5: main entry point of the system

9.2 Cred_files folder

Figure 6: Cred file structure
 It is a folder where data files are stored as text data which the system uses to authenticate
and keep records of them.

Contents of the folder:

9.2.1 [Link] :
This contains the credentials that are associated with the administrators of the financial
institution.
Figure 7: Admin file structure
9.2.2 [Link]
The file is mainly dedicated for storing the information of the costumers using the
system.

Figure 8: Staff file structure

9.2.3 [Link]

[Link]
Stores account user/customer information
Figure 9: User text structure

9.2.4 [Link]
Stores are records of transactions done by the user.
Figure 10: Transaction text structure
9.3 Functions folder
Figure 11: Function structure

Here, the various modules of the project are contained in this folder. The code has to be

made into various modules in order to improve the readability, maintainability, and reusability of

the code.
9.3.1 Admin_feature.py
It is located in the location: functions/admin_feature.py and it is responsible for

managing all the administrative functions like managing the staffs, the users and handling the

admin features. This function has all the functionalities that will get triggered when the user

Figure 123: admin feature file

9.3.2 Admin_feature_validation.py

The file is placed in: functions/admin_feature_validation.py This file

has the functions like validate_staff_details() ,and the main responsibility of this
function is to validate the credentials that the staff will be entering while registering for
managing all the administrative functions like managing the staffs, the users and handling the
admin features.
Figure 4: 135: validate functions

Figure 13: flow chart of overall system

9.3.3 Cli_utils.py

This contains the functions like clear_screen() which is responsible for clearing
the screen, when needed. The diagram showing how the function is accessed is shown below.
Figure 14 6: clear screen function
Figure 15: accessed method of the functions

9.3.4 Customer_features.py

This file contains all the functionalities associated to the customers suing the system. the

entry point of all the features of the staffs is the users_menu() which will further expand

to other functions as per the need and the choice of the users.

Figure 16: customer feature

Figure 17: accessing and access function.

9.3.5 Staff_feature.py
This file contains all the functionalities associated to the staff accessing the overall

system. The entry point of all the features of the staffs is the staff_menu() which will

further expand to other functions as per the need and the choice of the staffs.

Figure 18: staff feature

9.3.6 Intital_login_mail_checker.py

This module contains a function called as mail_checker() which is responsible for

validating the initial logins of the users, admins or the staff trying to access the management

system. Once the initial credential validation is passed then the system can access the

function.

Figure 19: login_mail_checker file

9.3.7 [Link]

The module, [Link], contains various functions dedicated to different roles such as the

the admin, staff,or the customers. This function acts a entry point to access the features of

different types of login as per the user type. The primary functions of this module are as

follows:
  admin_login()
 Staff_login()
 User_login()
Figure 720: different functions under login module

10. Flowcharts

Flowcharts are logical steps that a user follows. In this project, there are two critical flows that

are used to secure and maintain financial accuracy it also includes the flowchart of the three

components of this project i.e. Admin, staff, and customer (K. Charntaweekhun and S.

Wangsiripitak,, 2006).

10.1 overall system flowchart

Figure 21: flow chart of overall system
10.2 Admin feature flowchart
Figure 22: flowchart for Admin feature
 Form the given flow chart Admin is responsible for whole management system and has

the credentials of creating staff account can view staff and customer records as the same time

search records through the help of ID or email also can update the staff details and manager

overall system’s data after actions of overall functions of Admin menu it can return back to the

main system through the logout functions.

10.3 Staff features flowchart

Figure23 8: flowchart staff feature.

Staff can act like an operational user who can operate the user's accounts; it has all the

authority to access the user's accounts. Based on the given flow chart staff can register customer

details, generate customer statement with it view all the customer records. Each staff member has

a choice-based flow and returns to the staff menu and completions of all the task related to its

functions with the use of logout methods it can direct back to the main system starting phase.
10.4 users features flowchart
Figure 24: flowchart user menu/ customer features.
 The Customer is the final user of banking services system whose data are managed by the

[Link] the flowchart perspective, customer details are created, updated, and accessed by

staff, while transactions are used to generate account statements. Customer can control the

system but interact through staff and Admin operations.

11. Pseudocodes

With the help of pseudocode, we can describe the complicated "Business Rules" of the

bank without showing the mess of syntax. This pseudocode includes the three components of the

system i.e. Admin, staff and customers. With the overall system flowchart which helps the know

that the overall system works (Nicholas Bennett, 27 January 2025).

11.1 Overall system pseudocodes

START

IMPORT os, datetime.

FUNCTION main_menu():
DISPLAY "1. Login"
DISPLAY "2. Exit"
GET choice
IF choice == 1 THEN login()

FUNCTION login():
INPUT account_number, password
IF account_number exists in "[Link]" AND password matches:
IF password == "default123":
CALL change_password()
 CALL account_dashboard(account_number)
ELSE:
DISPLAY "Invalid Credentials"

FUNCTION account_dashboard(acc_num):
WHILE true:
DISPLAY "1. Deposit", "2. Withdraw", "3. Statement", "4. Logout"
GET choice
IF choice == 1:
INPUT amount
balance = balance + amount
UPDATE "[Link]"
RECORD transaction in "[Link]" (date, type, amount)

IF choice == 2:
INPUT amount
min_bal = (acc_type == "Savings") ? 1000 : 1500
IF (current_balance - amount) >= min_bal:
balance = balance - amount
UPDATE "[Link]"
RECORD transaction
ELSE:
DISPLAY "Transaction denied: Minimum balance violation"

IF choice == 3:
INPUT start_date, end_date
READ "[Link]"
 FILTER transactions by date range
CALCULATE total_deposits, total_withdrawals
PRINT Statement Report

IF choice == 4: BREAK
END

11.2 Pseudocode of admin features

MODULE AdminFeature:
Import random, datetime, os, AdminValidation

FUNCTION create_staff():
GENERATE random 6-digit staff_id
GENERATE temporary password using "LBEF-stf" + random 4-digits
CAPTURE current date for account_created_date

INPUT name, email, address, contact_number, nationality, citizenship_number

// Call Validation Module

isValid = CALL AdminValidation.validate_staff_details(...)

IF isValid IS True:
OPEN "[Link]" in APPEND mode
WRITE all collected staff attributes (id, email, password, etc.)
APPEND record separator "---"
DISPLAY success message and staff credentials
 ELSE:
DISPLAY "Data could not be written due to validation failure"

FUNCTION view_all_details():
DISPLAY Sub-menu: 1. View Staff, 2. View Users
INPUT choice

IF choice == 1:
IF "[Link]" exists:
READ and DISPLAY entire content of "[Link]"
ELSE IF choice == 2:
IF "[Link]" exists:
READ and DISPLAY entire content of "[Link]"

FUNCTION print_customer_records():
IF "[Link]" does not exist: RETURN error

READ "[Link]" and SPLIT by "---"

DISPLAY formatted table header (Name, Email, Created On)

FOR each record found:

PARSE lines to extract 'name', 'email', and 'created_on'
PRINT extracted data in aligned columns
DISPLAY total customer count

FUNCTION search_by_id_or_email():
INPUT search_key (ID or Email)
 SET found_status = False

// Search Staff File

READ "[Link]", SPLIT into records
FOR each record:
IF search_key exists in record:
DISPLAY record and SET found_status = True

// Search User File

READ "[Link]", SPLIT into records
FOR each record:
IF search_key exists in record:
DISPLAY record and SET found_status = True

IF found_status IS False:
DISPLAY "No matching records found"

FUNCTION admin_menu():
LOOP INFINITELY:
DISPLAY Admin Options (Create Staff, View All, Print Records, Search, Logout)
INPUT choice
EXECUTE corresponding function based on choice
IF choice == 5: EXIT loop

11.3 Admin feature validation

MODULE AdminValidation:
IMPORT string, mail_checker
 // Initialization Logic
OPEN "[Link]" for READING
FOR each line:
IF line contains "email", "password", or "name":
STORE values in global lists (staff_emails, staff_passwords, etc.)

FUNCTION validate_staff_details(name, email, contact, password, citizenship, address,

nationality):

// Name Check
IF name is numeric OR length < 2 OR contains special characters:
DISPLAY "Invalid Name Error" and RETURN False

// Email Check
IF email already exists in staff_emails list OR is invalid format:
DISPLAY "Invalid Email Error" and RETURN False

// Contact Check
IF contact is not numeric OR length != 10 OR already exists:
DISPLAY "Invalid Contact Error" and RETURN False

// Password Complexity Check

IF password length < 8: RETURN False
IF password missing Uppercase, Lowercase, Digit, or Special Char:
DISPLAY "Weak Password Error" and RETURN False

// Citizenship Check
 IF citizenship exists OR is not numeric OR length < 5:
DISPLAY "Invalid Citizenship Error" and RETURN False

// General Formatting
IF address or nationality are numeric OR too short:
DISPLAY "Format Error" and RETURN False

// Empty Field Check

IF any input is only whitespace:
DISPLAY "Empty Field Error" and RETURN False

RETURN True (If all checks pass)

11.4 Staff feature

BEGIN
// Define Global File Paths
SET staff_file = 'cred_files/[Link]'
SET user_file = "cred_files/[Link]"
SET TRANSACTION_FILE = "cred_files/[Link]"

// MODULE: Register Customer

FUNCTION register_customer():
DISPLAY "--- Register Customer ---"
INPUT name, email, nationality, age_input
TRY:
CONVERT age_input TO integer (age_int)
EXCEPT ValueError:
DISPLAY "Invalid age format"
RETURN

INPUT raw_type
IF raw_type IS "s" OR "savings" THEN
SET account_type = "Savings"
ELSE IF raw_type IS "c" OR "current" THEN
SET account_type = "Current"
ELSE:
DISPLAY "Invalid account type"
RETURN

IF age_int < 18 THEN

DISPLAY "Customer must be at least 18 years old"
RETURN

SET account_number = CALL generate_account_number()

IF account_number IS NOT VALID THEN
DISPLAY "System Error: Invalid account number generated"
RETURN

SET password_val = RANDOM integer between 1000 and 9999

SET default_password = "LBEF-usr" + password_val
SET balance = 0
 SET created_date = GET current date in "YYYY-MM-DD"

ENSURE directory "cred_files" exists

OPEN user_file in APPEND mode:
WRITE account_number, email, name, account_type, password, balance, date

DISPLAY "Account created successfully"

DISPLAY account_number, default_password
END FUNCTION

// MODULE: Update Customer Details

FUNCTION update_customer_details():
INPUT search_acc
IF user_file DOES NOT EXIST THEN:
DISPLAY "No records found"
RETURN

READ user_file content

SPLIT content by "---" into record_list
SET updated_records = Empty List
SET found = False

FOR EACH record IN record_list:

PARSE record lines into dictionary (customer_data)
 IF customer_data['account_number'] MATCHES search_acc THEN
SET found = True
DISPLAY "1. Update Type, 2. Update Password, 3. Update Email"
INPUT choice
IF choice == "1" THEN INPUT new type -> UPDATE customer_data
IF choice == "2" THEN INPUT new password -> UPDATE customer_data
IF choice == "3" THEN INPUT new email -> UPDATE customer_data

CONVERT customer_data back to string format

APPEND to updated_records

IF found IS True THEN:

OPEN user_file in WRITE mode:
FOR EACH record IN updated_records:
WRITE record + "---"
DISPLAY "Details updated"
ELSE:
DISPLAY "Account not found"
END FUNCTION

// MODULE: Generate Statement

FUNCTION generate_statement():
INPUT acc, start_date, end_date

TRY:
 CONVERT start_date, end_date TO datetime objects
EXCEPT:
DISPLAY "Invalid date format"
RETURN

// Step 1: Find Customer Info

SEARCH user_file for acc
IF found: STORE name and balance

DISPLAY Statement Header (Account Info and Period)

SET totals (deposits=0, withdrawals=0, count=0)

// Step 2: Process Transactions

IF TRANSACTION_FILE EXISTS THEN:
OPEN TRANSACTION_FILE:
FOR EACH line:
SPLIT line into (t_acc, type, amount, date)
IF t_acc == acc AND date is within range THEN:
INCREMENT count
DISPLAY line details
IF type is "DEPOSIT" THEN ADD amount to deposits
ELSE ADD amount to withdrawals

DISPLAY Totals (Deposits, Withdrawals, Net Change)

END FUNCTION
// MODULE: View All Customers

FUNCTION view_all_customers():
IF user_file DOES NOT EXIST THEN RETURN

DISPLAY Table Headers

READ user_file and SPLIT into records
FOR EACH record:
PARSE data (acc, name, email, type, balance)
DISPLAY formatted row
DISPLAY total count
END FUNCTION

// MAIN EXECUTION LOOP (Staff Menu)

WHILE True:
DISPLAY "1. Register, 2. Update, 3. Statement, 4. View All, 5. Logout"
INPUT choice

IF choice == "1" THEN CALL register_customer()

ELSE IF choice == "2" THEN CALL update_customer_details()
ELSE IF choice == "3" THEN CALL generate_statement()
ELSE IF choice == "4" THEN CALL view_all_customers()
ELSE IF choice == "5" THEN
DISPLAY "Logged out"
BREAK loop
 ELSE:
DISPLAY "Invalid choice"
END

11.5 customer /user feature

BEGIN
// GLOBAL CONFIGURATIONS
SET user_file = "functions/cred_files/[Link]"
SET TRANSACTION_FILE = "functions/cred_files/[Link]"

// -------------------------------------------------------------------------
// HELPER: parse_customer_data(content)
// -------------------------------------------------------------------------
FUNCTION parse_customer_data(content):
SPLIT content by "---" into records
SET customers = EMPTY LIST
FOR EACH record IN records:
CLEAN record
IF record is empty CONTINUE
INITIALIZE customer_data with default keys (account, email, name, etc.)
SPLIT record into lines
FOR EACH line IN lines:
IF "=" is in line:
SPLIT line into key, value
UPDATE customer_data[key] with value
IF customer_data has account_number:
ADD customer_data to customers list
RETURN customers
END FUNCTION

// Feature: Save_customer_data(customers)

FUNCTION save_customer_data(customers):
OPEN user_file in WRITE mode
FOR EACH customer IN customers:
FOR EACH key, value IN customer:
WRITE "key=value"
WRITE "---"
CLOSE file
END FUNCTION

// Feature : save_transaction(account, type, amount)

FUNCTION save_transaction(account, type, amount):
ENSURE directory for TRANSACTION_FILE exists
FORMAT transaction_block with account, type, amount, and current date
OPEN TRANSACTION_FILE in APPEND mode
WRITE transaction_block
CLOSE file
END FUNCTION

// FUNCTION: deposit()

FUNCTION deposit():
 INPUT acc, amount
IF amount <= 0 THEN DISPLAY "Invalid amount" AND RETURN
IF user_file does not exist THEN DISPLAY "Error" AND RETURN

READ user_file content

SET customers = CALL parse_customer_data(content)
SET found = FALSE

FOR EACH customer IN customers:

IF customer account matches acc:
SET found = TRUE
CALCULATE new_balance = current_balance + amount
UPDATE customer balance and last_logged_in date
CALL save_customer_data(customers)
CALL save_transaction(acc, "DEPOSIT", amount)
DISPLAY "Success" and new balance
BREAK loop

IF NOT found THEN DISPLAY "Account not found"

END FUNCTION

FUNCTION: withdraw()

FUNCTION withdraw():
INPUT acc, amount
IF amount <= 0 THEN DISPLAY "Invalid amount" AND RETURN
READ user_file and CALL parse_customer_data
 FOR EACH customer IN customers:
IF customer account matches acc:
IF balance < amount THEN DISPLAY "Insufficient balance" AND RETURN
UPDATE customer balance (subtract amount)
CALL save_customer_data(customers)
CALL save_transaction(acc, "WITHDRAW", amount)
DISPLAY "Success"
RETURN
DISPLAY "Account not found"
END FUNCTION

FUNCTION: check_balance()

FUNCTION check_balance():
INPUT acc
READ user_file and CALL parse_customer_data
FOR EACH customer IN customers:
IF customer account matches acc:
DISPLAY Name, Account Type, and Balance
RETURN
DISPLAY "Account not found"
END FUNCTION

FUNCTION: print_statement()
FUNCTION print_statement():
INPUT acc
DISPLAY Header (Account, Name, Balance)

CALL parse_transactions(acc)
FOR EACH transaction:
DISPLAY date, type, and amount
IF type is "DEPOSIT" ADD to total_deposited
ELSE ADD to total_withdrawn

DISPLAY Summary (Total transactions, total in, total out)

END FUNCTION

FUNCTION: change_password()

FUNCTION change_password():
INPUT acc, old_pw, new_pw
READ user_file and CALL parse_customer_data
FOR EACH customer IN customers:
IF customer account matches acc:
IF customer password matches old_pw:
UPDATE customer password to new_pw
CALL save_customer_data(customers)
DISPLAY "Success"
ELSE:
DISPLAY "Incorrect old password"
RETURN
 DISPLAY "Account not found"
END FUNCTION
MAIN MENU: user_menu()

WHILE TRUE:
DISPLAY "1. Deposit, 2. Withdraw, 3. Balance, 4. Statement, 5. Password, 6. Logout"
INPUT choice
IF choice == "1" THEN CALL deposit()
ELSE IF choice == "2" THEN CALL withdraw()
ELSE IF choice == "3" THEN CALL check_balance()
ELSE IF choice == "4" THEN CALL print_statement()
ELSE IF choice == "5" THEN CALL change_password()
ELSE IF choice == "6" THEN BREAK loop
ELSE DISPLAY "Invalid choice"
END WHILE

END

12. Testing

12.1 Tests related to login

Testing the range and the valid values

Figure 25: test of the initial login of the system
Figure 26: testing for the invalid values

Testing for the admin login

Figure 27: admin login testing
Figure28: Successful login of the admin account

Testing for the staff login

Figure29: Testing for the staff account creation
Figure 30: Successful login of staff

Testing for user login

Figure 93: Testing for the user login
Testing for the account creation
Figure 32: testing for staff account creation by the staff (unsuccessful)

Figure 104: Error while re-opening the file already opened.

 Future Enhancements

The project assignment system can be used for a purpose of learning but, still there exists a room

present for further improvement. One of the aspects to be improved is to integrate a database in

place of using the text files. Although the text files are not difficult and are also easy for one to

learn but when many users exist or have many transactions, management becomes and the

security of the database come as a major concern. Security, maintainability, easy access, and

also higher efficiency is achieved if the database is used.

Another aspect for improvement is the user interface of the system. Currently, the system

implements the menu-driven approach for getting inputs from the users, but if there were a

simple graphical user interface or a web-based interface then it would be making the system feel

more convenient ,and easier to use as well. Similarly, hardening the security of the system is

another area that still has room for improvement. Features like encrypting the generated

credentials or including new add-ons such as the OTP verification would make the banking

management system to be more secure and safer for data protection.

Although as the current requirement of the project, these changes are not essential. However,

when these features would be added then the overall system can be close to the real- world

application, would be more secure, and the system can be more scalable too.

Although as the current requirement of the project, these changes are not essential. However,

when these features would be added then the overall system can be close to the real- world

application, would be more secure, and the system can be more scalable too.
 Conclusion

This Python Banking Service System assignment assisted our group in learning actual how-

banking solutions can be implemented via the programming logic. Although, at first, managing

all user roles was confusing but after dividing the roles into Admin, Staff and Customer features

among team, the whole arrangement was more obvious and efficient. Each and Every role had

their own duties that makes managing the system simpler and makes things a lot safer for all

users. This kind of modular approach helped us understand how to separate responsibilities of

different people and make sure everything very smoothly. The clarity of roles also increased

efficiency in the overall system. And the security of data was improved because each role can

access only relevant parts. Overall, this project gave good experience about real-world

application of programming concepts and logic.

The project demonstrated that sometimes it is not about designing something that is important

with the help of sophisticated tools. With the help of Python language and simple text files, there

was nothing left to do, but set in limits on the login and balances to create a system that can

demonstrate the true life banking system. This approach may not be enough in the banks that

operate on large scale but to learn, the reasoning was easier to comprehend and able enough to

satisfy the need.

In short, this project assignment did not just limited us to coding. It allowed us to consider

security aspects, also the user experience and data consistency. Not only this, we also got better

in team works and learned problem solving kind of in more effective way.
 Work breakdown matrix.

Contributions

Students Name Presentation Implementation Documentations

Rajkumar Tiruwa Introduction of Customer features: Abstract,

(NP070980) the presentation,  Deposit money from the Flowcharts,
Feasibility study, respective accounts, maintaining Pseudocode,
conclusion a minimum balance of 1000. testing and
 Withdraw the balance from the validation, and
account. system
 Allowing users to check balance implementation
from their account.
 The customers are allowed to
print statements, change their
password, and if they want, they
can log out of their account.

Satya Raj Joshi Conclusion, Staff features: References,

(NP070996) Aims and a. Registering new customers for Acknowledgement,
objectives, and the system. Feasibility study,
software and b. The details of the customers can Assumptions and
hardware be updated if needed (such as limitations,
requirements changing password or deleting programming
the account) concepts used in
c. The staff can generate the the project.
statements of the customers.
d. The staff can view all the
customers.
e. If the staff wants, then they can
log out of the system.

Sansar Overview of the Admin features: Cover page,

Chhetri(NP070995) system, features a. The admin can create staff Table of contents,
of the system, accounts. Aims and
Flowchart and b. The staff can view all the objectives,
demo of the customer details Folder structure
project c. The staff can print out the description,
customer records. conclusion,
d. The staff can search the further
accounts of the staffs, perform enhancements,
the update on the accounts such workload matrix
as editing the existing records or
remove the existing staffs.
e. When the staff is done, he can
logout from the system.
 References

K. Charntaweekhun and S. Wangsiripitak,. (2006). Visual Programming using Flowchart. IEE.

Matthets, E. (1992). Python crash course : a hands-on, project-based introduction to
programming . No Starch Press.
Nicholas Bennett. (27 January 2025). Introduction to Algorithms and Pseudocode. researchgate.