Financial Technology, or FinTech, is a relatively new aspect of the financial industry, which focuses on applying technology to improve financial activities. This has the potential to open the doors to new kinds of applications and services for customers, as well as more competitive financial technology.
However, like all new technologies, there are mistakes lurking. In contrast to software domains like end-user web apps or mobile application development, a software bug in FinTech may not just lead to annoyed users. In the wrong piece of software, bugs can result in hundreds of millions of dollars lost.
The list below are some of the most common mistakes we see in software projects in general—and FinTech software development in particular—that you should watch out for when launching into the FinTech sector.
This applies to many software projects: you need thorough testing. It’s not sufficient to simply test your software manually, spot-check the results, and ship it. You need automated tests which include success cases, failure cases, and many more. Instead of reiterating the points here, I’ll point to our blog post on multifaceted testing.
While this applies to software development in general, it’s worth reiterating in the context of FinTech. A mistake here can in the worst case lead to a devastatingly bad financial transaction and massive financial loss. Ensuring bugs don’t slip in with modifications to the code is absolutely vital.
Of course, in FinTech, sometimes it’s not the code that changes, but the data. Which brings us to…
One common theme in FinTech projects is the wide array of data pulled in, and its variable quality and formats. You may be interacting with anything to live feeds from a stock exchange, legacy file formats pulled from a mainframe, Microsoft Access databases, or the Twitter firehose.
We recommend cleaning up, or sanitizing, all data you pull into your application. Use strict parsing rules that don’t, for example, replace malformed data with default values. You want a monitoring solution that will notify you if one of your data feeds suddenly begins generating data in a format you can’t understand.
At FP Complete, we’re big fans of the Haskell programming language, which makes it easy to model your FinTech data with the type system and write powerful parsers for consuming various feeds.
Are you writing a real-time trading engine? How about a monthly batch processing job? Are you processing terabytes of data per minute, or a few hundred kilobytes every hour? Obviously, these are all very different goals!
Some software engineers will tend towards optimizing their code, even at the cost of readability and maintainability. Others make the opposite trade-off. In order to properly determine where to set your gauge on this spectrum, you need to understand the needs of your software.
Don’t fall into the traps of either premature optimization or architecturally slow software.
And related to this are two more common mistakes:
Real-time software often cannot be written in garbage collected languages. You may need to perform manual memory management instead. In some cases, you can get better performance by hand-rolling your own assembly instead of trusting the compiler. Sometimes the operating system will be a bottleneck, and you’ll want to reimplement parts of the network stack in your own code.
Each of these decisions can give you better performance. But they also introduce significant risk to your codebase in the form of security bugs and maintenance nightmares.
Going bare metal can be great, but only do it if you have to.
There are some wonderful, high-level frameworks out there for writing financial software. These can abstract away the boring details so you can focus on the big picture.
Each time you abstract away a problem, however, you may be sacrificing performance. Sometimes significant performance. I do not exaggerate when I say I’ve seen high-level approaches (such as Excel + Access) providing results in an hour, when a well written C++ or Haskell program could generate the same results in 10 seconds.
Going high level is great, but don’t sacrifice too much performance.
The nature of FinTech software is that requirements will almost certainly change over time. You’ll want to perform a new analysis. There will be a new financial instrument available to model. Whatever the case is, you’ll likely need to modify your code going forward.
To deal with these changing requirements, we recommend designing your software from the beginning with extensibility in mind, and relying on a combination of strong type systems and thorough testing to make major refactorings an annoyance instead of a herculean task.
Imagine you’re developing on your Windows 10 system with a 32-bit compiler. You’ve tested your algorithm thoroughly, everything works perfectly, and you ship your code off to your operations team to move into production. And boom, the software crashes (or, worse, loses your company a bunch of money). Turns out, the Linux 64-bit system you deployed to didn’t like your code very much.
We recommend on all projects, including FinTech, to standardize your development, Continuous Integration (CI), Quality Assurance (QA), and production environments, as much as possible. Make CI the official arbiter of truth: it doesn’t matter if the tests pass on your machine if they fail on CI.
Leverage technologies like virtualization and containerization to isolate differences in hardware and system libraries.
It’s much better to discover these problems as early as possible. And ideally long before it hits production.
All software needs to take security into account. But insecure
practices in FinTech can be especially damaging. A recent
string
of cryptocurrency hacks demonstrate how easily large
sums of money can be lost to a security bug.
There are documented best practices for most types of software. For example, if your FinTech project has a web frontend, make sure you’re addressing OWASP’s common vulnerabilities, like cross-site scripting (XSS) and SQL injection attacks.
Wherever possible, use languages (like Haskell and Rust) and tools (like linters and memory exploit checkers) to eliminate classes of bugs and automate the security auditing of your codebase. It’s not a replacement for intelligent programming, but it doesn’t hurt!
You need to know as soon as something goes wrong. We mentioned the possibility of signaling data feed parse failures above. It’s not sufficient to have your software notice this; you need to actively monitor your systems and set up alerting to be notified when something goes wrong.
You hope your system never loses you a million dollars a minute. But if it does, you better hope you get alerted quickly.
For data analysis projects, you can identify some set of “correct” results for a given set of input. We recommend writing a set of “gold standard” tests, which regularly test the output of your software for that given set of input. If you get a discrepancy, either:
In the latter case, you just avoided a major nightmare of tracing back where something went wrong months later. In the former case: maybe you’ll have some more ammunition for asking for a bonus.
There are obviously many other mistakes that can be made in FinTech software, but these are the top 10 that we think you should keep in mind. As we mentioned above, we strongly recommend choosing great tools and languages to make your FinTech projects successful. Great devops, solid CI, and a wonderful language like Haskell all play into making your project a success.
We’ve helped many companies adopt these approaches to improve their software projects. Find out how our consulting services can help make your FinTech software a success.
Subscribe to our blog via email
Email subscriptions come from our Atom feed and are handled by Blogtrottr. You will only receive notifications of blog posts, and can unsubscribe any time.
