I have worked with fintech companies around the world for the past four years, offering them customized infrastructure support while in turn gaining unprecedented insight into the growth of the industry. While fintech began as a disruptive industry with the ‘humble’ intention to revolutionize the financial services industry, I’ve watching it explode and rock the status quo in tech hubs around the world.
While I saw some fintech companies achieve great success, I saw many others fell into the same traps — or “deadly sins” — that began happening all over the world time and time again. I learned that virtually any fintech-related company — Payment Service Providers (PSP), Digital Banks (neoBank), and Peer to Peer Lending platforms, etc. — will be able to save time, cut costs, increase flexibility, and ultimately find the great success they are all searching for when they are aware of and can avoid these ‘sins’.
I’ve laid out the first three of these seven deadly sins, along with examples of companies that have fallen into their vices, below.
Pride: Refusing to Use Existing Tools
If fintech companies refuse to build their platforms using current technology or open-source options, they risk running on outdated technology that no one understands. If they want to scale up, they risk having a legacy platform that blocks the entire company from becoming agile.
Let’s look at Boohoo, a fictional fintech company that operates multiple data centers. Like most companies that started early on the tech scene, they had to build their own management platform as there was not a lot of software available to run their large Internet applications or manage their large amounts of hardware.
Boohoo’s first data center was built to suit their initial requirements. However, as they grew and expanded, their data center needs changed, and they began experiencing technical issues. Enter, a fork in the road: did they want to enhance and build on their first platform, or start over with something completely different?
Ultimately, instead of fixing their current technology, they decided to build something completely new for the second data center. They would build it right this time, it would fix all of their problems, and then they would migrate everything from the old platform to the new and everything would work seamlessly. Right?
In the end, this proved to be very difficult for support engineers. Not only did they have to code for multiple APIs to facilitate communication between the data centers and their legacy platform, but they had to support other software that was built on top of their existing platforms. Troubleshooting any particular team’s software became a nightmare, and the entire Boohoo operation became inefficient and overly complicated.
If existing tools and open-source technology had been utilized, Boohoo could have fixed their problems from the start and grown their data centers in unison — and by doing so, effectively eliminated their outdated data, obscure patches, and massive inefficiencies.
Gluttony: Ignoring Scope and Capacity
If scope and capacity are not taken into consideration, fintech companies risk killing dashboard performance — making troubleshooting actual issues almost impossible.
The next example comes from fintech company we will call Hipster. This company that started out small and experienced such rapid growth that their front end peak traffic numbers became a benchmark for the low point after only a few months. Everything had been built so quickly that there had been no time to implement network metrics. A decision was made to instrument everything and just turn it on.
When they began, Hipster used an in-house metrics platform built on OpenTSD and ran on an Hbase cluster. Their network team set everything up and began shipping metrics without telling anyone. This resulted in over 2,000 network ports that sent every frame to the Hbase cluster (which was already being used to monitor critical systems that were running the site).
This resulted in a complete fall over of the cluster. The sheer volume of new metrics killed the dashboard performance for everyone, which then made troubleshooting actual issues almost impossible.
The lesson: fintech engineering requires capacity planning. There is no unlimited resource. No matter what provider you are using — an internal resource, cloud provider vendor, etc. – planning needs to happen at every stage.
Envy: The Desire for a More Exciting Project
It is essential to keep day-to-day work simple and effective. This easier said than done in fintech, where engineers are constantly attempting to implement the newest disruptive technology to try and be industry front movers.
Take this lesson from fictional company Pink Shoe Linux. This company wanted to migrate from a bespoke document publishing system to Docbook (Docbook authors material for online and printed documents in XML). A major advantage of the program is that it generates multiple outputs — for example, an instructor course manual with quiz answers and a corresponding student version with no answers.
Pink Shoe Linux was already using many Docbook features, but with a proprietary built system that needed to be maintained by the people who were authoring the coursework. The decision was made to migrate to an open source standard tool chain for Docbook called Publican. The advantage of Publican was that there was no need to maintain internally built tools, as there were already available resources from within the organization.
An engineer was chosen to complete the project, and it was estimated that the task would take a few weeks to get the toolchain working, define the workflow, and write up some documentation.
After several weeks went by, other engineers noticed that the code, as it was written, was able to function with or without Docbook. Digging into the situation further revealed that the original engineer working on the project had always wanted to write his own publishing system, and had taken this as an opportunity to do just that. In order to meet the company’s requirements, he had added in the ability to support Docbook.
The result was a new tool that replaced the old one and mostly worked with Docbook — but it also lacked a critical feature needed to export portable translation objects. These translation objects were sent to a translation company so that documents could be imported in multiple languages.
In the end, most of the existing code was thrown out so that the standard tool could be implemented by the deadline. What should have been a relatively simple project ended up with months of work in the garbage.
The most successful fintech companies have a thoughtful infrastructure strategy at the heart of all of their projects. If you haven’t encountered one of the above sins already, I hope that this article can serve as a warning so you don’t look back and end up thinking “I wish I did this differently”.