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.
Insufficient Testing
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…
Unsanitized Data
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.
Wrong Performance Goals
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:
Being too bare metal
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.
Being too high level
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.
Poorly Maintainable Software
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.
Mismatched Development and Production
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.
Insecure Practices
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!
Runtime Monitoring
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.
Gold Standard Results
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:
- You've improved your algorithm and have better results. You
should manually verify that these are better, and then update the
gold standard results.
- You've made a mistake, regressed the results, and need to fix
it.
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.
Conclusion
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.
Do you like this blog post and need help with Next Generation Software Engineering, Platform Engineering or Blockchain & Smart Contracts? Contact us.