A Synopsis on

Minimizing Number of Transactions Between Group

Submitted in partial fulfillment of the requirement for the award of the degree of
Bachelor of Technology
in
Computer Science & Engineering
Submitted By

Sankalp Varshney 2015272

Pridum Bhat 2015260
Paras Raj Dhar 2015254
Keshav Aman 2015246

Under the Guidance of

Ms. Neha Tripathi

Project Team ID : MP22MLAI08

Department of Computer Science and Engineering

Graphic Era (Deemed to be University)
Dehradun, Uttarakhand
October 2022

1
 Candidate’s Declaration
I/We hereby certify that the work which is being presented in the Synopsis entitled
Minimizing Number of Transactions Between Group in partial fulfillment of the re-
quirements for the award of the Degree of Bachelor of Technology in Computer Science
& Engineering in the Department of Computer Science and Engineering of the Graphic
Era (Deemed to be University), Dehradun shall be carried out by the undersigned under
the supervision of Ms. Neha Tripathi, Department of Computer Science and Engineering,
Graphic Era (Deemed to be University), Dehradun.

Sankalp Varshney 2015272

Pridum Bhat 2015260
Paras Raj Dhar 2015254
Keshav Aman 2015246

The above mentioned students shall be working under the supervision of the undersigned
on Minimizing Number of Transactions Between Group

Supervisor Head of Department

Internal Evaluation (By DPRC Committee)

Status of the Synopsis: Accepted/Rejected

Comments:

Name of Committee Members Signature with Date

1.
2.

2
Contents

1 Introduction & Problem Statement 4

2 Background & Literature Survey 6

3 Objectives 8

4 Hardware & Software Requirements 9

5 Possible Approaches & Algorithms 10

6 References 11

3
1 Introduction & Problem Statement
In a world where the number of financial transactions is expanding exponentially, keeping
track of and remembering all transactions an individual has participated in is increasingly
becoming difficult. This project team has all met a specific use-case of this example: one
individual pays for a specified product/service for themselves and everyone else in the or-
ganization. Someone else from the group pays the next time any transaction is necessary.
This technique also gives flexibility to all participants, allowing members to either pay the
complete sum to the accountable individual or pay for everyone in the following transac-
tion. However, this too can stem financial disarray. An example is provided in a corner case
below:

Keshav owes Sankalp 5120Rs

Keshav owes Pridum 350Rs
Pridum owes Sankalp 1400Rs
Pridum owes Paras 5610Rs
Sankalp owes Paras 6700Rs

A directed graph representing the transactions is used for convenience and ease of un-
derstanding. We can calculate the incoming and outgoing edges(transactions) from each
vertex(person) through the graphical representation.

Figure 1: Directed Graph Representation of Transactions

Keshav: 2 Outgoing Edges, 0 Incoming Edges

Pridum: 2 Outgoing Edges, 1 Incoming Edge
Sankalp: 1 Outgoing Edge, 2 Incoming Edges
Paras: 0 Outgoing Edges, 2 Incoming Edges

4
 In this instance, five edges have varying transaction amounts, with an average of 2-3
edges connecting to a vertex. Currently, each individual would like to remember at least all
the transactions they are involved in, but when the transactions multiply, it becomes pro-
gressively impossible to hold each transaction precisely. A naive solution to this becomes
noting all the transactions & keeping that ledger safe. This option, however, looks not as
beneficial, as we have to keep track of duplicate data. Minimizing all the transactions is
achievable so that all vertices stay linked with minimal edges. Minimizing the edges will
not only make the overall transactions plain and succinct but will make it much easier for
everyone to repay. Considering the above-given scenario, we can reduce the transactions in
the graph below.

Figure 2: Directed Graph Representation of Minimal Transactions

The minimum transaction graph gives a significantly simplified picture of the sender-
receiver interaction. The above-given graph now depicts the following transactions:

Keshav owes Paras 5470Rs

Pridum owes Paras 6660Rs
Sankalp owes Paras 180Rs

Keshav: 1 Outgoing Edge, 0 Incoming Edges

Pridum: 1 Outgoing Edge, 0 Incoming Edges
Sankalp: 1 Outgoing Edge, 0 Incoming Edges
Paras: 0 Outgoing Edges, 3 Incoming Edges

Now there are just three edges linking the vertices instead of five, an average of 1 trans-
action per individual. This simplified transaction graph makes it much more accessible for
the participants to be aware of their credits & debts.

5
2 Background & Literature Survey
Minimizing transactions, sometimes known as Minimizing CashFlow, is typically a well-
known & defined problem that has several applications besides the obvious. Popular mobile
applications like SplitWise are extensions of the same underlying ideology. However, in-
stead of delivering a speedy solution to the problem, splitwise needs all participants to sign
up and be part of a virtual group on the platform itself. This increases the time between
inputting a query and being provided with the output. Splitwise provides several more ca-
pabilities, such as implementing bespoke transactions, preserving a ledger in memory &
many more. However, for this significant project, we will not focus on repeating what has
been done previously; instead, we would like to focus more on speedy outcomes, lowering
the time between the input & the output.

The background information that links to this project concept mainly concerns graphs.
The Graph Data Structure is primarily used to establish relationships between things or
nodes. Being increasingly popular by major businesses & services worldwide, graphs ex-
ecute algorithms concerning connectedness between nodes, for example, Facebook.
[1]On Facebook, everything is a node. That includes User, Photo, Album, Event, Group,
Page, Comment, Story, Video, Link, and Notes; anything that contains data is a node.
Every re-lationship is an edge from one node to another. Whether you publish a photo, join
a group, or like a page, a new edge is established for that relationship.

A graph can be of two types, directed and undirected. Our research focuses on directed
graphs since they may be utilized to depict the flow of currency or transactions. A person
cannot be in debt & concurrently owe money to the same individual. There might always be
several transactions between the two identities, but the net outcome decides who the loaner
& the loanee is. In this project, we aim to construct a relationship that accepts many trans-
actions between identities. However, the outcome only depends on the net transactions,
which may be abstracted and represented in a directed graph.

The algorithm associated with both graphs & this project is about minimizing the edges
of a directed graph. When we talk about limiting the number of edges yet still having all
components connected, the notion of MST, or Minimum Spanning Tree, arises. Minimum
spanning tree has direct use in the construction of networks. It is utilized in algo-rithms
approximating the traveling salesman problem, multi-terminal minimal cut problem, and
minimum-cost weighted perfect matching.

However, with an MST, we chose specific existing pathways to form a tree instead of
evaluating all possibilities. MST may be best appreciated with an example of maps; we de-
termine the shortest path that links to all nodes. However, this approach will not be enough
when working with transaction networks. In this project’s example, we do not pick a single

6
path that links all nodes; instead, we delete and build new edges with more straightforward
transactions. Creating new edges with simple transactions assists limit the total number of
edges. However, this proves we are headed on the proper path to solving the issue.

7
3 Objectives
In this project, we seek to design a program that may be used on a Phone or Computer to
enable users to identify minimal transactions necessary to solve their complex transaction
graph. The objectives can be further separated into functional & non-functional require-
ments

Functional Requirements:

1. Intakes Names of participants & various transactions through an interactive & dy-
namic User Interface

2. Outputs a minimal transaction graph to an interactive & dynamic User Interface

3. Ability to import & export graph data for future purposes, this happens with the ability
to serialise & deserialize data

Non-Functional Requirements:

1. Ability to present data through many mediums, i.e., Graph, Table, Ledger

2. Ability to exchange info with contacts using numerous channels, i.e. Email, SMS,
DirectLink

3. Ability to incorporate custom/personal remarks in the output data

4. Ability to have custom photos in place of nodes in both input & output data

8
4 Hardware & Software Requirements
We have opted to work on the project utilizing the .NET Framework. .NET allows us to
construct a dynamic front-end user experience while simultaneously giving good intercon-
nectivity to the backend. Further, the backend framework is powered by C#, which is also
a fantastic alternative. Since we will need to heavily employ Data Structures & construct
algorithms, utilizing an Object-Oriented Programming language such as C# will support
the same.

Hardware Requirements:

1. A Server (Presumably a computer with necessary softwares)

Software Requirements:

1. Visual Studio 2022

2. .NET Framework Core

3. .NET API Services

9
5 Possible Approaches & Algorithms
Before moving directly into the approaches, we must first establish all the criteria in simple
words, and thus then we can choose each and speak about the approaches to accomplish
them.

1. Dynamic Front End

To construct a dynamic front end utilizing the .NET framework, we must learn to apply
fundamental Markup languages to a webpage. We are making the webpage responsive for
both PCs and mobiles. Furthermore, we need to create data structures to keep the informa-
tion provided by the user in a fashion that requires little access to the structure to obtain the
ideal data—examples like utilizing HashMaps for mapping participants’ names with their
transaction histories.

2. Optimal Algorithm to decrease transaction graph complexity

Numerous algorithms may obtain a solution, but choosing and executing the fastest and
most efficient method separates a Great algorithm from all the good algorithms. We are
leaning towards applying greedy methods to decrease the transaction graphs for this project.
For example, we compute each participant’s net debits/credits and then identify the partic-
ipants with the most and most minor net debit/credit. This process of choosing the two
participants can either be implemented by an array, where we traverse the array to find the
least & most net scores, or we can create two PriorityQueues so that we would not have
to traverse the array multiple times, instead, we can pick the topmost elements from each
heap. This provides us with less computational time and faster results. Furthermore, we
then try to clear the balances of the two persons picked till we cannot lower the number of
transactions further. This method sounds abstract presently, but this will undoubtedly be
much more understandable while working on the project.

3. Servers & APIs

We want to incorporate servers & APIs into this project as it will provide an edge and a
unique experience compared to all other projects in a similar field. APIs may be used to
globalize the data, which implies that I can change the transaction graph from my interface,
which will then reflect onto every participant’s interface. This promotes the worthiness of
the system and helps keep all the participants up to date. We would also like to employ
servers to preserve the data created by the software so that the user may import and export
it to whichever system they like. Additionally, we would want to study the possibility of
serialization and deserialization of data so that we may store and transport data in an orderly
and efficient manner. 10
6 References
[1]Common Data Structures & their time complexities - Medium.
https://medium.com/@sathya26d94/common-data-structures-their-time-complexities-deab031888e5

11