This is part 3 of a series on how to develop a fintech app. You can read part 1 here and part 2 here.

Imagine this scenario: You’ve spent the last year working to develop a new fintech application that helps users to better manage their personal finances and pay off their debts. You and your team have dedicated countless hours to building an app and experience that is intuitive and easy for your target audience, Gen Z, to keep track of their spending, find personalized offers and deals to help them save money, and ultimately start planning for their futures. And now the day has arrived: launch day. Your app is ready to go live for the public.

After the first month of your app being live, you start to see an uptick of downloads and people signing up to use your app. Your whole team is ecstatic to see how all the time and thought you invested in the process of development seems to be paying off – until you start getting feedback that the app isn’t working for a handful of users, particularly users who aren’t members of big-name traditional banks. Your team works diligently to try to troubleshoot the issues so that these people can utilize your app, but as the days go by, the problem just seems to get worse, and more and more potential users start deleting their accounts, removing your app from their devices, and leaving bad reviews. What once seemed like such a promising and successful launch has become a disaster, and you find yourself backpedaling to try mitigate the damage that’s been done.

According to the US Bureau of Labor Statistics, 10% of all startups end up failing within their first year of existence, and that number only increases over time. In the end, it’s estimated that 90% of those startups won’t exist at all in 10 to 20 years. While there are many reasons for an app to fail, one of the most obvious ones is if it doesn’t work well for a large contingency of users. For a fintech app, one of the worst possible scenarios is that your users cannot easily connect their financial institution(s) to your platform.

Yet with over 4,200 FDIC-insured banking institutions in the United States alone, it’s no wonder that you’ve run into problems when users are trying to connect less traditional institutions to your app. Is there any way you could have avoided this? The short answer is, yes. If you partner with the right financial API platform and conduct extensive testing before launch, you should be able to avoid the disaster of the scenario above.

In this article we’ll be focusing on one of the most crucial steps in the entire app development process: testing. We’ll discuss not only what kinds of testing should be done but also the best way for testing to be completed to ensure the success of your fintech app. Let’s dive in.

A QUICK REVIEW

In the first article of this series, we explained in broad terms the typical process for developing an app:

1. Coming up with an idea
2. Designing your product
3. Designing the interface and starting coding
4. Testing your App
5. Marketing your app to your intended users and sending it to App Stores
6. Continuing with ongoing maintenance and improvements

While all of these steps play a part in the eventual success of your app, #4 and #6 are particularly important (and technical) and need to be given special attention. And with both of those steps, it’s extremely important to partner with the right kind of API platform in order to have your best chance of success. Without testing, troubleshooting, and ongoing maintenance, your fintech app simply won’t survive.

DIFFERENT KINDS OF APP TESTING

As a developer, you already know there are various types of testing that needs to be done before you can launch your app. We’ll look briefly at some of the different kinds of testing that should be conducted, before landing on the discussion of data testing. With each kind of testing, you essentially are determining if sample inputs produce the expected resulting outputs so that you can predict the what it will be like for users navigate around your app.

FUNCTIONAL TESTING

Throughout the entire development process you’ll most likely be running functional tests, i.e. can your app actually do what it’s built to do? You want to conduct ongoing functional tests for every software component of your app – does the login software successfully create user accounts and log them in when their credentials are inputted? When users click on buttons to perform tasks, will they navigate to the correct screen/interface? These are the kinds of questions functional tests can answer.

Functional Testing typically follows this process:

1. Set specific testing goals: what specifically is your app supposed to be able to do?
2. Create testing scenarios: determine what situations the goals from above should be attainable
3. Create testing data: this is information that simulates real use conditions that could be used in the above scenarios
4. Establish test cases: for each input of data, what are the desired results?
5. Run the test cases through the app
6. Review the results: how do the actual results from the tests compare to the expected or desired results?
7. Make adjustments as necessary

SECURITY TESTING

Application Security Testing (AST) is another crucial part of app development. Robust AST helps your app to be resistant to security attacks in various settings. Because of the nature and prevalence of security breaches today, AST is an automated process that usually covers several kinds of sub-categories of testing, like static and dynamic application security testing, interactive application security testing, software composition analysis, and much more.

DATA TESTING

While data testing is technically a type of functional testing like we covered above, because fintech apps depend on financial data (which is highly sensitive and comes from countless different institutions), we want to spend some time talking in depth about how data testing should be done.

Your app is designed to interact with thousands of different data sources through APIs, so it’s crucial to test those connections before your app is live for users. Robust testing ensures that the ongoing data exchange between financial institutions and your app are reliable and accurate. The problem is, data testing is not necessarily an easy thing to do. Each API for each financial institution has its own data interface (also called data format or data schema), which means a lot of different tests must be done to ensure that your app will work for users no matter what financial institution they use.

How do you actually conduct testing on your APIs and data? Most developers choose to use a testing sandbox, which is a controlled environment that’s designed to imitate the actual product environment. (By the way, Pentadata has built an interactive sandbox that you can play with to see how our APIs work, without having to write a single line of code. You can try it out here.) In the sandbox, you can execute tests on isolated components of your software and APIs to see how they work. Yet while sandboxes are great tools to help you try out how a specific platform works (see our last article about API integration here), they’re not a great way to actually test your data. If you use a sandbox for testing your data, you will most likely be running synthetic or simulated data through your software, which can cause several problems.

THE PROBLEM WITH USING A SANDBOX

Typically, financial data vendors offer a sandbox to conduct testing with dummy data instead of actual data. If you go looking for alternative sources of data to perform your data, you’ll find primarily the same thing: synthetic data sets. These data sets are considered to be synthetic because vendors add “noise” to existing data in order to anonymize it and keep it random.  But anytime you’re using data that’s not 100% real, there are limitations. Any attempt to anonymize data takes away some key elements from it, so you can’t get the full picture of what will happen when users use your app.

Simply put, choosing to test with synthetic data can be a recipe for disaster in production. It’s true that conducting your testing with dummy/synthetic data sets can help you identify obvious weaknesses in your app, but it won’t cover the whole range of data possibilities users may encounter when your app is actually live. Your testing won’t be as thorough as it could be, and that could lead to major problems later for you and your users, just like the scenario in the introduction of this post.  

A BETTER OPTION FOR DATA TESTING

So what’s better than using synthetic data to test your fintech app? Using real data, of course! You may be thinking, well yes of course using real data is better than using fake data, but how would I actually get real data before my app has launched? We’ll spend the rest of this article discussing how that’s possible and answering other common questions that may come up when considering this option.

In order to use live data for testing, you’ll need to do a pre-launch pilot of your app with a specified number of approved users (yes, we’re talking real people here). These “pre-users” will connect their financial accounts to your app in the same way you intend users to when your app is actually live. That makes it possible for you to run a diverse range of tests on how the API connections work (or don’t work) before your app is public.

Privacy is obviously a concern since your app will run individuals’ actual financial data through the pilot pre-launch. But in the same way that live apps must explicitly state their privacy practices (including what data they’re accessing and what they’re doing with it), you too in your pilot will explicitly state what data you’ll be using in order to run tests, analyze the results, and improve your app. All it takes is a series of statements addressing those ideas that potential pre-users can read and then choose to opt in. If they do choose to participate, their data is called consumer-permissioned data, which is the best data you can possibly use to test your app.

Maybe an even more urgent question for you as a developer, however, is how do you know that this consumer-permissioned data will be an accurate representation of your larger intended audience? The most reliable way to ensure that is to work with an API platform that also helps with testing. You’ve probably already worked with a platform to establish the APIs for your app, so why not consider using them to also conduct your testing? Instead of using dummy data sets that have been modified and anonymized, some API providers, like Pentadata, can give you access to live data from real people since we have connections through our existing APIs. The data you get from us is 1) permissioned by the user, 2) kept private through our existing platform that follows stringent security practices, but 3) is also 100% intact, so that when you run the various tests needed for your app, the results are as close as possible to what it will be like when your app is actually up and running.

This all sounds great, doesn’t it? But you may be wondering, can I afford to do testing this way? Users who opt in to pre-launch pilots like the ones we’re suggesting will want to get paid for allowing you to use their data, and rightfully so. So you should plan to offer them some kind of financial compensation in exchange for their data. The cost-per-person varies from project to project, however, so you can reach out to us to find out our more specific recommendations based on your needs.

CONCLUSION

As a developer, you put your heart and soul into your app. In order to ensure its success for the long-term, in this article we argued that robust testing is crucial – particularly data testing for fintech apps. Instead of using synthetic data for testing like most developers, there’s a better option available to you in live, consumer-permissioned data. Through working with an API platform like Pentadata, you can access diverse and quality data that actually represents your intended user audience.  The more you can troubleshoot before your app’s launch, in order to find and address bugs your app may experience with real users, the better chance your app has to live a long and successful life!

If you want to talk more about how Pentadata’s APIs can help build and test your app, reach out to us today!