Four years ago, we had the opportunity to build our very first company. It went well (the business is still trading!). We made loads of mistakes, but learnt more in those four years than in the previous twenty. To sum the experience up in one sentence is difficult, but would be something along the lines of ‘a tough lesson in resource management’.
Our company was a digital banking, virtual IBAN and deliverable FX platform targeting the UK and European SME and e-commerce space. As founders we envisioned a global localisation solution, allowing businesses all over the world to trade as if they had a local presence in any jurisdiction they desired. As much as we tried, we never did come up with a good catchy phrase that accurately described our vision. We tried “Glocalisation” but could never get past the fact it just looked like a damn typo! Armed with hyper-entrepreneurial investor, a smattering of developers and some borrowed resource, off we went.
In 6 months we got our (not quite) MVP out the door. Delighted with our work, we began to plan how to get the product ready to go live when our investor decided he was tired of waiting. Whilst we were nervous to launch without a fully fledged product, it ended up being a fantastic baptism of fire. Theorising endlessly over what the customer wants is never as good as the real life customer shouting “this is what I want!” Attracting our first customers and creating revenue was a fantastic milestone for us and with the full support of our investor, we began to hire and build out a more substantial development team. Perhaps foolishly we thought if we can build X with n developers then as we add more to the team, output would follow in a linear relationship.
We were very wrong in two main areas. The first problem is what I call the ‘efficiency lag’. This, much like a gear change in a car, is where momentum and speed temporarily suffers as the cars slows during the gear shift. The only difference is in a car the lag is momentary and the ROI almost instant. Not so in business!
We knew it would take a bit of time to hire. What we didn’t factor in was the immediate and long lasting hit it would deliver to our existing deployment timelines. As non-technical founders, our tech resource was also our internal hiring resource. We had no way to assess skillset, experience technical fit. We couldn’t induct or train. And we certainly couldn’t bring them up to speed on the specific methodologies of our technical development. That meant our most experienced (and thus most valuable) tech assets’ output capacity became unavoidably impaired. By the time the new hires were up to speed, we were already forced into major revisions of our deployment timelines.
In total, the efficiency lag increased cost and degraded delivery speed by a total of 5 months. Only then did the original delivery rate resume. It took a further 4 months before our delivery speeds overtook our initial timelines. Therefore we were left in the difficult position of having to explain to investors why the requested cash injection – after three quarterly reports – had not impacted this year’s deliverables. An important lesson in forecasting and investor management was learned here, namely that more money does not always equal more speed.
The second challenge we faced is a more familiar concept. The concept of diminishing returns. As we began to position the business for scale, we realised the platform had become quite the beast. Having conducted a full tech and cost audit, we had realised that over 30% of our technology budget was being expended on pure maintenance. Every time we deployed a new product or migrated to a new provider, every time we implemented a forced regulatory alteration, or simply swept unforeseen bugs, there was a cost to it and a drain on our resource.
As we dug deeper, we realised a further 15% of our resource was simply handling integration maintenance. Every time a bank released a new feature, or upgraded their software; when a customer wanted to release a new feature that required minor adjustments, we were devoting time and energy to something that offered little to no value to our clients. Imperceptibly, over time we had become janitors of our own technology.
If our business was a New York apartment block, then we had become it’s ‘Super’. Our client’s didn’t care that their FX provider had implemented minor code alteration which resulted in Aussie Dollar wire delays. They didn’t care that how we screen payments in real time. They maybe didn’t even care that WE DID screen payments. Or that we were PSD2 compliant. Ultimately, the customer cared only about the ease and speed of the solution and the range of functionality.
We assessed our monthly spend, spend to date, our delivered product range and our conclusions were surprising to say the least. A total of 85% of our product spend was invisible to our customers. Worse, there were good features, necessary features, but they weren’t differentiators. Most customers don’t choose providers for their screening and sanction efficiency. They don’t choose one provider over another because of security environments, ledger maintenance or, audit records or web hosting scalability. They aren’t interested in internal liquidity management systems, or back office task automation. They want cool and unique interfaces, intuitive design, great client facing features. And we realised that we had compromised on what matters to customers because we COULDN’T compromise on what matters to regulators.
We realised that our business model, whilst executed well by us and many competitors, had at it’s very core a conflict of interest. And this (entirely necessary) conflict meant that without the mega-funding only available to a select few, we would never be able to focus all our energy on creating a product that – in its entirety – was devoted to the customer.
The financial services technology stack needs a rethink. We think the path forward is towards architecture aggregation.
In the 90s it happened with data. Cap/OpEx intensive server space prevented most innovation from flourishing in the space. Rackspace were early movers and transformed the market. Sowing seeds for smaller businesses to spin up innovative solutions without the capital burden of server maintenance. From there AWS ploughed the landscape far and wide, creating from a barren excess of capital waste, a fertile land for entrepreneurs the world over to create compelling solutions that could at once be deployed internationally.
Firebase took it even further for mobile development by providing a unified platform with built-in authentication, analytics, testing infrastructure, app messaging, monitoring, and much more.
Cloud platforms have ushered in a new era of innovation. The hallmark of their success has been the coining of a new term – the Unicorn – The Billion Dollar Startup.
By focusing on solving the problem of heavy lifting on commoditised products i.e. those that don’t differentiate you, AWS, GCP etc have enabled new entrants to grow exponentially by focusing resource on things that make a difference. But Fintech for everyone but a precious few has maintained an element of imperviousness to this trend.
Say goodbye to integration hell
You’ve had a great idea, raised some funds from investors and are trying to launch a financial technology company. You now need to find different vendors and cobble a solution together. After negotiating with at least three FX providers, 2 IBAN vendors, a few data aggregators and a KYC specialist you realise there is overlap across almost all solutions. You’re left with two choices, Firstly, build it yourself. I hope we’ve shown this is increasingly becoming a thing of the past. Secondly, go blindly with one provider and pin your success to them. Worst idea ever! Rule number one of financial services is make sure you have built in redundancy.
Yodlee or Plaid. Currency Cloud, Ebury or Banking circle. All excellent companies but with significant service overlap. You now have the complex challenge of combining these systems into a cohesive user experience. And the ever present challenge of maintaining connections to them all in the background.
After 6 months of the year researching and negotiating with vendors, the development team can finally start to build the integrations. Great engineers are hard to find and most of the best lack the domain expertise or operational experience needed to build a FinTech platform. Teams are stuck in workflow hell of trying to build an operational platform to monitor transactions, provide visibility for auditing and answering questions (customers tend to ask questions when they’re confused about what’s happening with their money), and tools for handling exception and reconciling data from disparate data sources.
After six months, the product is far behind schedule, the costs are ballooning, the development team is frustrated, and very little work has gone into building the company’s core IP.
This is exactly what happened to us and we know we are not alone in experiencing this pain.
Focus on your core product
Few business models and pitch decks tout the significance of smooth integrations and secure environments. It’s not what compels investors and customers. Competitor fintechs don’t succeed because they had a great money transfer mechanism. In the same way DevOps services like replication, encryption at rest, auto-scaling/auto-healing, are now commoditised, FinTech services like FX, money transfer, account verification, user-level auditing, ledgering systems, KYC are all things that need to work, but none of it needs to be built internally.
We started Integrated Finance after experiencing the pain building and deploying financial applications. We want to provide a unified and open platform that reduces the time taken to launch and development cost for businesses and results in enterprise-grade quality from day one.
If you’re innovating in financial services, let’s build something amazing together.
