Our Project
Credit card fraud affects thousands of individuals worldwide, and is the cause of billions of dollars of damages. Many banks and services have “fraud preventative measures”, however, we found through interviews that these were not enough. The money was still lost, and customers had to go through a lengthy process to get it back. We wanted to make an app that prevented that. We would do that by introducing two-factor authentication at transaction time. This meant that credit card fraud could be stopped at the source without having to lose any money to scammers first.
For our app, we split the work across the two quarters of our Senior Project. First, we worked on gathering potential customer testimonies to help develop features of our app. These interviews helped us as we designed and prototyped a Figma. Our second quarter was spent doing simultaneous front- and back-end development
Our App
The main problem that we are trying to solve with our app is how to give people an efficient way of blocking fraudulent transactions and give users better visibility of their finances. A solution to this issue would be to notify a user when activity occurs on their account. In our solution, it allows the user to confirm whether or not the activity was made by them. If it was not, then the transaction would be cancelled and labeled as fraud. To give our user’s better visibility of their finances, we would provide a place for users to keep their account information and allow them to make budgets and see recent activity on their accounts.
Our Figma
Our figma design consisted of two iterations. The first design allowed us to think creatively and see the basic functionality of what our app should be able to do. This design was very verbose and seemed out of touch with current app design standards. This was confirmed during our usability testing, and we took this feedback and decided to implement some changes.
We made these changes in our second iteration. Most notably, we added an “inner-screen” component, reduced the verbosity, and designed better navigation. The “inner-screen” component is crucial as it organizes information and fills white-space. Reducing word count makes using our app less cluttered. Filling out forms and processing information is more efficient as a result. Navigation was redesigned to a stack navigator. This made navigation less awkward meaning a user could use our app more easily. Overall, our designs on the second iteration are a blueprint for how we developed our app.
1st Iteration vs. 2nd Iteration for Fraudulent Transactions
1st Iteration vs. 2nd Iteration for Account Information
The Development Process
This project followed a “sprint” strategy where we held various meetings. We held daily “stand-ups” to discuss work we accomplished that day and any paintpoints we hit. We also held a weekly in-depth retrospective meeting (or “retro”) where we discussed work. This meeting also was a time for us to organize work that we would tackle next week. Lastly, we held optional weekly meetings with Dr. Peterson on Fridays. These meetings allowed us to present our progress to Dr. Peterson, as well as diagnose any issues we needed help addressing.
For development we decided on React-Native for our front-end and Spring Boot for our back-end. We chose React-Native to be able to develop a portable app for both iOS and Android. We also decided to use Spring Boot because Brad had experience using it during a previous internship.
Front-End Development
As mentioned prior, we decided to use React Native because of its ability to write code that is portable for iOS and Android. It also came as a benefit that our team had experience with React in previous projects.
Despite the capability to write React Native code in an object oriented way, we decided to write the frontend code functionally. Writing the code functionally has some major benefits. The first being is that it lets us use React’s hooks. Hooks are a way of doing state management directly from React rather than relying on a provider like Redux to do it for us. Hooks simplify React’s lifecycle events. We relied on the use of two hooks, useState and useEffect. The useState hook assigns the value that we pass into the hook and then uses lambda calculus to give us a function that we can use to modify the variable. This hook acts like the constructor if we were writing our code in an object oriented way, but gives us so much more in return. The useEffect hook allows us to use state without a provider. In the hook, we can pass a function that would allow us to make calls to our backend and update state automatically based on the variables passed into the dependency array. This function replaces the componentDidMount and componentDidUpdate functions with one function that does both in one go. While this might not be beneficial for all use cases, it was definitely beneficial for ones where the logic for updating and mounting are the same. Functional programming allowed us to speed up the development of our app and make improvements on areas that might be at first glance overlooked.
To make the app match mockup faster, we decided to use React’s version of Material UI, React Native Paper. This library includes all of the components that the group had used during the design phase of development. By using a library like React Native Paper, it speeds up the duration of development. Rather than designing components completely, we could use what the library offers and customize the component to match our mockup. By using a library like this, it allows us to get really close to mockup really fast and spend more time implementing key features instead.
Backend-development
The backend is built using Spring Boot, a technology Brad became well-acquainted with during his previous internship. We developed the REST Services in Spring allowing Brad to use the experience he gained on the job for our app. This let us focus on learning how to use and integrate the APIs we used for the app.
From Amazon Web Services (AWS) we implemented DynamoDB and Simple Notification Service (SNS). In Dynamo, we set up four (4) tables: _Users, Accounts, Budgets, _and Transactions. Each table was paired with standard CRUD operations, and some special API endpoints are in place where the front-end required. For SNS, an email is sent to the user after different actions (i.e when a new bank account is connected to a user). We also used the Plaid API, a very popular banking API which lets developers connect a user’s banking information in an application. Our app uses Plaid’s Account-Link and Transactions API to connect a user to their bank institutions and to retrieve live data of transactions made with that account. We experienced many learning curves during development, but our split workflow let us divide-and-conquer our app \
As mentioned before, our workflow had Stanley working solely on the front-end and Brad working solely on the back end. This let us quickly build and test new endpoints that were needed for the front-end. With this workflow, new prototypes for how to return data for the user could be swiftly developed.
Future improvements to the app
While we are happy with our work, we believe there are many improvements to add. The biggest improvement being the two-factor authentication at transaction time. We were not able to implement this feature into our prototype. Mastercard also worked on putting this type of technology into their cards, but they ultimately abandoned the project once Covid-19 hit.
A few other features for improvement include functioning user authorization features, a working React-Native Android build, and SMS push-notification. We actually set our sights really far and wide, and we had to learn how to scale down issues we wanted to tackle. While we wanted to hit all of these for our personal metrics, Dr. Peterson was very helpful in keeping us on track during our Friday meetings.
Another feature which is missing from the app is a user creation process. For testing and prototyping, we created endpoints for the creation and persistence of new users in the Dynamo Database. However, for the ease of implementation we decided to omit this in our proof-of-concept. This feature is one of the first that would be included in any future work on this app.
Summary of development experience
At the end of the day, we were able to develop a prototype for a fintech app. This was accomplished by splitting the work into components that we knew how to accomplish, and a solid strategy for maintaining the quality of work and work ethic all along the way. This project was a great way for us to close the books on their time spent at Cal Poly.
Who We Are
Brad Iglesia and Stanley Armstrong are two students graduating with the Cal Poly Computer Science class of 2021.
Brad Iglesia will be completing his degree with a minor in Entrepreneurship, and has spent much of his time as a hackathon organizer for Cal Poly’s major hackathons—SLO Hacks and Camp Poly Hacks.
Stanley Armstrong will be completing his degree in Computer Science, and has spent time as an organizer for SLO Hacks and as a student researcher finding optimal properties for polymer reactions.