How to navigate dependencies in FinTech software development

Simply put, dependencies are third-party or internal artifacts your application uses to produce particular results. These can be libraries, tools, microservices, APIs your app uses, etc. These pre-built solutions speed up software development and let your team avoid reinventing the wheel. 

Benefits and risks of third-party dependencies

What’s good

The variety of libraries and tools allows small teams to develop websites and applications easily. Your team can skip building what's already a usual and repeated component in software and focus on innovating. Moreover, paving a new path just next to the beaten one leaves your team making the mistakes others learned from years ago — and extending time to market infinitely, overspending, and wasting effort.

Building on what's already there and adopting the hard-won insights of predecessors is what pushes innovation in FinTech and other industries. Otherwise, we would still be beating around the bush or ATM.

What to watch out for

Overusing dependencies, even if you select them carefully, can, at some point, open hell’s gates of risks.

One of them is dependencies conflicting with one another. The fewer dependencies your solution has, the better. Especially if you build serverless; in that case, your app has to be lightweight, and cold start times should be short for your clients to receive responses to their requests. 

Being careful when selecting dependencies pays off in less-to-no trouble. If you don’t check the trustworthiness of vendors, you may end up with data or funds stolen. Even reliable vendors can have vulnerabilities that may result in security issues.

Types of third-party dependencies

Libraries

Libraries allow your team to create web or mobile applications by providing source code for a component. There are open-source libraries, which you can use for free, and proprietary, or for private use libraries, which you may need to purchase and which might have specific terms of use.

When the team needs to process the Excel sheets from your clients, they are highly unlikely to investigate the organization of those documents and how they work. Instead, your team might use some standard library to parse those sheets into your application’s data structure. For Java, this would be the Apache POI library, which we widely use at INSART. 

Platforms

Platforms are pre-built, multiple-feature SaaS solutions that developers can use to add a specific feature to a solution. As libraries and tools, they may be free to use or fee-based. For instance, Firebase offers log-in components, deep links functionality, app data storage, etc.

Microservices

If your solution is built on microservices architecture, some of its services depend on one another. So, there is a kind of internal dependency in your infrastructure. 

APIs

Many FinTech solutions have payment gateways integrated at some point. Well-documented payment gateway APIs ensure your team can securely send requests to process your customers’ data.

Dependencies can also be categorized by usage:

Security dependencies constitute the relationships and links between components, processes, and entities within your solution’s cybersecurity ecosystem to safeguard digital assets, networks, and data.

Data-access dependencies are used for connecting to your database (you don’t want to reinvent the Java Database Connectivity (JDBC) API.)

Messaging dependencies like Apache Kafka for event-driven programming when you distribute data.

On top of that, you can come across frameworks that combine many dependencies. One of the most popular in Java is Spring, which makes developers’ lives easier and helps kickstart projects faster.

How to select dependencies

1. Identify your project needs. Think of which dependencies you might use. For starters, only pick those essential to your project at this specific point; later, you can add them gradually, paying maximum attention to each. As I said, too many dependencies multiply risks for your solution.

2. Do a research. Look for reliable options and alternatives and check vendors’ trustworthiness. Compare and prioritize by vendor support, community support, documentation, and frequency of updates. 

3. Check dependencies for compatibility with your existing codebase. Many old Java versions are still “alive,” running legacy software. But they are the reason these outdated systems lack compatibility with newer Java versions and need an upgrade. New libraries won’t get along with Java 9, and Java 21 (or Java 22, to be released in March) won’t match older libraries.

For instance, you build a feature that uses Java Virtual Threads, making your code more scalable in Java 21. If your code uses a thread synchronization feature from older Java versions — synchronized blocks, your virtual threads become pinned to your platform threads, which are less effective than the former. This transformation leads to your platform becoming overwhelmed and using more resources than expected. That’s why it’s always a good idea to double-check if your older libraries go well with newer ones that you want to use in your project.

4. Check the licenses. Some licensed dependencies may be ambiguous about the future of their libraries and leave a backdoor for changing the licensing of their library, etc. Such ambiguity may end up in a court issue for your company. Take the Google vs Oracle case in 2021, where the fairness of Google's use of a Java API was a subject of dispute in terms of computer code and copyright law.

Another case was Amazon’s web storage tool Elasticsearch changing the license to make it private. To give users an open-source option, the community, with the support of Amazon, later made a fork called OpenSearch. 

5. Run all your dependencies code in virtual, containerized environments. This is essential to secure your solution if any trouble starts dependencies-wise on the vendor’s side. Your DevOps team should help you organize your environment for isolated microservices or components of your application to secure its data.

Also, it’s worth keeping in mind that containers have their dependencies, too, so you should select them wisely and monitor them carefully to avoid facing more dependency vulnerabilities.

Documenting third-party dependencies

When a new microservice is created, it has to be capable of communicating with existing ones. To ensure that, use standard RESTful API documentation, frameworks like OpenAPI standard, designed for Java initially but now widely used with other languages. If you need additional setup for your microservices application, it must be documented so that developers new to the project know how to work with it. 

As for library dependencies, the best way to manage them is to use widely known dependency management tools like Maven or Gradle. Maven uses XML, while Gradle runs Kotlin or Groovy scripting language (see the example in code below).

It’s essential to use fixed, reliable versions of these tools, not some asterisk (*) versions — library updates can change their behavior and break your code. Also, it’s worth categorizing dependencies inside whichever tools you use by usage: e.g., these will be responsible for data access, these ones for unit testing, working with Amazon, etc. The same works for tools your app depends on: categorize and visualize them in an easily understandable way and provide a detailed overview of their functions in the project.

As for APIs, it’s worth checking how well they are documented before confining your team to using one. 

Example of project dependencies declaration in Gradle

Analyzing and monitoring third-party dependencies 

Monitoring dependencies helps prevent security incidents. There are several trusted solutions that can simplify that task for Java-based solutions. For example, OWASP Dependency-Check will help you spot any security vulnerabilities and suggest updating that particular dependency or looking for alternatives. SonarQube or other tools for static code analysis will help you analyze both your code and dependencies for vulnerabilities.

Another way to monitor your dependencies is by using bots, like Dependabot. This one is built into GitHub, has 24 repositories, and provides teams with automated dependency updates.

These tools should be a part of your development pipeline when your code is built, checking it for vulnerabilities and providing reports or stopping your code from being pushed forward when a critical vulnerability manifests so that it doesn’t appear on QA or production.

Summing up on dependencies

You are close to one hundred percent independence only when you build every bit of the solution on your own — all while your competitors propel their product to the front. So, picking the right dependencies while minimizing and isolating those you use is critical in the Fintech context now.

Balancing the benefits and risks, careful selection, compatibility checks, and constant monitoring are essential. For FinTech companies, building or finding a skilled software development team experienced in dependency management is not just a choice; it's a strategic necessity. 

If you want to stay ahead, stay secure, and empower your FinTech innovations with a team that understands the intricacies of dependency management, INSART is here to help. Schedule a call and meet us! We’ll gladly help you find the best solution for your challenge.