Introduction
There isn’t a silver bullet or panacea for building a great FinTech product or service. The FinTech ecosystem is highly regulated and integrated but at the same time fast moving. Larger financial institutions are willing to play ball with young, innovative companies and provide them with a mature user base in exchange for robust, innovative and secure products.
Young FinTech companies have to pay attention to security, availability, redundancy and several other factors, in order to punch above their weights.
Here are some guiding principles that can be applied to the technology your company is building:
Integration Friendly
No system exists in isolation. Systems exchange information all the time with each other, reinforcing each other’s value in the ecosystem. In FinTech, it’s common to integrate with payment gateways such as Stripe or PayPal, market data providers such as Morning Star or Xignite, and user financial data providers such as Yodlee. If you’re building a financial product, bear in mind that integration with commonly used providers adds value to your product, and reduces the switching cost for potential clients.
Enterprise Ready from Day One
Startup X writes code in a state of perpetual growth and/or panic. They down gallons of energy drinks, and chant in unison – “Move Fast and Break Things”. As these companies start garnering interest from mature clients who insist on due diligence and certain checks and balances, a new sense of panic breaks out. Code is rewritten, errant business logic is obscured or thrown away – and engineers find themselves writing more and more unmaintainable code to keep the lights on.
Startup Y insists on crafting their product with care and attention to detail. They schedule downtime where they clean up and improve parts of their code, upgrade their code quality and reflect on how to do things better. They move slower than Startup X, but spend time on security, scalability, and correctness. They spend time testing parts of their code and tuning performance. Startup Y is enterprise-ready from day 1, combining cutting-edge technology with the maturity of a large financial institution.
Unrealistic timelines and schedules encourage Startup X like behaviour, a successful product is a marathon and not a sprint. Spending a little more time up front and doing things correctly is worth more in the long run than sprinting in panic.
Security from the ground up
FinTech companies often have access to their client’s sensitive personal and financial information. It’s part of your fiduciary duty to protect and safeguard this information to the best of your ability. It’s absolutely essential to have engineers who have worked in information security (InfoSec) roles as a part of your team. The last thing you want is a bunch of hackers auctioning your client’s personally identifiable information (PII) on the darknet. Trust me, it happens.
As your company grows, and you hire client service executives, engineers, and product managers – it’s important to manage access control. No one should have access to servers, client data or other sensitive information if they don’t need it. Activity logs should also be maintained for business users and customers so that they can be revisited if necessary.
This is more of a day two concern, and not very important when you’re starting to build your product. Infosec strategy goes hand in hand with the “Being Enterprise Ready” guideline discussed earlier.
Using the right tools and encryption standards and staying up to date with the latest vulnerabilities and exposures is a good way to start implementing security processes and infrastructure.
The Devil is in the Details
The industry loves buzzwords such as “Blockchains”, “API”, “Microservices” or the rather long “React redux front-end powered by Golang microservices running on load balanced twin docker instances on the cloud”. The complexity (and the real beauty) of technology, lies in the details.
Good engineers spend years honing their skills, and polishing their craft so that the products they build are close to perfect. As a non-tech co-founder, you should try to understand how the different pieces of the puzzle fit together, and why your tech co-founder is taking certain decisions. Not only will it give you confidence when you’re meeting other companies or VC’s, but also help you hire better technical team members.
UI/UX
UI/UX is subjective and there are several schools of thought regarding what constitutes a good UI/UX. The only rule of thumb that comes to mind is, “design for your users”. If you’re selling under the hood, business software that doesn’t face users, the focus is on low latency, high reliability, and scalability. If your product faces users, the focus should be user delight, comfort, and intuitiveness. Here are are few good resources for more information on design.
- The Design of Everyday Things – Donald A. Norman
- Lean UX – Jeff Gothelf and Josh Seiden
- Design for Hackers – David Kadavy
Flexible Deployment
B2B software products should offer several deployment options such as shared infrastructure or onsite deployment. Certain institutional customers might have stringent regulatory requirements and need all software to be deployed in their own data centers. Others might be more flexible and prefer a deployment on the cloud on either shared or dedicated servers. Atlassian, An Australian technology company got this right very early on with their issue tracking product – JIRA.
Continuous Integration, Monitoring, and Testing
Good software companies release code frequently and have tools to monitor their deployment for bugs or failures. Application monitoring and testing should be part of your release workflow so that you can improve your product quickly and test it soon after. Having engineers who have an understanding of developer operations (DevOps), site reliability and end to end testing will add a layer of stability to your product. This best practice will allow you to scale faster, and make your product enterprise ready.
A good example of this is the discount brokerage Robinhood. Robinhood has a lean security and DevOps team of experienced engineers who’ve set up a massively scalable trading app with advanced security and compliance features.
A platform state of mind
Good products often transition into platforms, creating ecosystems of modules or apps that serve users. Not all products go the platform route and go on to build successful revenue streams as standalone products or a suite of products. However, every now and then, we see a product evolve into a platform over time.
The benefits of building a platform is democratizing the ownership and quality assurance of the platform while providing more products and services on top of the platform.
Even if you choose not to allow third-party companies to build apps on your platform, treating your core product as a platform will allow you to build more modular software that can be sold separately, or as part of a combined solution to the end user.
An example of this is Stripe. Stripe’s suite of products including Connect, Atlas, and Subscriptions make it easy for entrepreneurs to set up businesses in the US, transact with users, access user data securely, as well as pay corporate taxes correctly. Stripe has moved from being just a payment gateway to being a platform for international business.
Conclusion
This list is by no means exhaustive, but a primer on how to start thinking about FinTech products and accounting for some common pitfalls such as scalability, security, and robustness. Building a good FinTech product requires equal parts engineering wizardry, data-driven sales as it does discipline and best practices.
I originally wrote this for Startupbootcamp's blog.