To deliver any solution, you need to understand first what problem you are trying to solve, what you are trying to sell, and to whom. For example, there is no point in delivering a payment solution to remote rural customers in Africa or Latin America based on a smartphone solution. It will not work, as feature phones are still dominant: you will need to have a USSD solution to be successful.
Another important consideration is whether to have a full programming capacity. In the fintech universe, you can have a supplier for everything, from customised programming to the purchase of standard solutions for many problems such as onboarding, KYC (know your customer requirements), AML (anti money laundering) monitoring, credit underwriting and tracking, and accounting and reports. These solutions can be combined into different shapes and forms, creating your unique solution, using the block architecture mentioned earlier. Later in the process, you may even consider bringing some of these services in-house as it becomes more cost effective or a strategic differentiator.
The same applies to understanding data storage requirements in terms of volume and location. Some countries now legislate that data must be stored within the country boundaries, and compliance may have extra costs as, for instance, global cloud providers do not have a physical presence in many countries, so one must instead rely on local suppliers. These will almost inevitably be more expensive.
What you should avoid at any cost is trying to digitalise existing traditional bank processes. You will end up with the worst of both worlds, with a clunky process that mixes digital and physical, requiring too much back-and-forth. This also affects innovation and new product developments at established banks. When working on a new project or opportunity, established banks often use the same people, the same providers, and the same structure, so it’s no wonder they end up with no true differentiation.
One of the competitive advantages of new fintech start-ups is not having to deal with issues and constraints of legacy systems or sunk investments (when firms stick to bad investments just because the money has already been spent). Fintechs can build true digital processes from scratch at a fraction of the cost to incumbent banks. This leads to another advantage, which is cost efficiency. While established banks run at a cost-to-income ratio of around 55 percent, fintechs run at close to 30 percent.
Once you have identified all the requirements to deliver a solution, and separated each stage into block, you should define what will be done in house and what will be delivered by a third party. It is then about building the capabilities to place the blocks together. Each solution will be different, depending on where the company is based and the targeted customers.
So, always think of your solutions from a digital experience point of view.
Financial regulators create specific requirements for financial services based on the scope, size and risk of the business model. Although fintech innovation is broadly welcomed, fintechs by nature operate in the heavily regulated financial market, so it’s very important to have a good understanding of the minimum regulatory requirements for each solution you are trying to create.
As this is an evolving environment, you will sometimes face different variations of the same challenges, and you’ll need to make a call on how to proceed while staying alert to changing rules and dynamics.
A good example is the Brazilian Central Bank and the new – and very successful – instant payment system called PIX. The central bank is changing its rules and requirements based on the ongoing experience of the implementation and gradually incorporating new features and rules. If you are in such an environment, you need to adapt and be ready to take advantage of any change.
Here the blend of generations in a fintech structure plays an important role in building the business, combining innovation, technology and experience. Rather than waiting for the launch of rules and regulations that will affect your model, experienced professionals can build solutions to comply with “the spirit of the regulation”. Regulations for new models will arrive, so it’s a smart move to pre-empt them. Of course, common sense always plays a role here.
We must talk about minimum business requirements. Sometimes Fintech entrepreneurs forget they are building a financial institution which will be subject to regulation, and where there are inherent risks to the business. Depending on the perspective from which a fintech is created, some start-ups will quickly find themselves in a difficult position because they have neglected basic business dynamics. These dynamics could involve basic balancing or funding requirements, risk appraisal, recovery tools, and so on.
For example, any seasoned banking professional understands the need for a lending solution to secure a stable flow of funding as the portfolio grows. This is not always the case with fintech start-ups, which seem to believe that they will find a solution as they go. The same situation can happen with “unexpected” levels of credit delinquency, limited re-insurance contracts, or even the size of service bills from third-party providers when transaction numbers have not been properly scoped. (Providers normally charge fees based on number of transactions). Not all investors will accept such mistakes. Many great ideas have failed because of a failure to understand the basic dynamics of the proposed solution.
It is crucial to understand the path to profit. We can look at some fintechs that act as digital banks as an example: their challenges in getting to a profitable scale were nontrivial. On average, customers at new digital banks held 1.5 products, compared to five for traditional banks, but that has changed in the last few years with digital banks broadening their offerings. In addition, fintechs acting like digital banks often initially rely on transaction fees and commissions for the bulk of their revenues (rather than profits from lending), and only a few have been successful in having customers sign up for a subscription or fee account. On the other hand, incumbent banks generate income from multiple sources beyond transaction fees, such as packaged accounts, commercial and consumer credit products, mortgages, and investments.
As a result, some fintechs “providing digital bank services” have a cash-burning business model that requires continual investor funding. Fintechs that are skewed towards customer acquisition (as opposed to seeking a profitable business model from the start) are particularly challenged. In times of contracting funding environments, many fintechs “providing digital bank services” cannot sustain a cash-burning business model in the medium term. Instead, they must turn to focus on expanding their revenue engines, coupled with a shift in customer acquisition strategy to pursue more economically viable segments.
Fintechs generally use partnerships to speed up implementation of the requirements to deliver the solution and offer a variety of products and services to its customers. The use of partnerships is key to a fintech’s ability to bring solutions fast and at a reasonable cost, and make a positive impact on customers. Fintechs can offer services and products using their provider’s license, infrastructure, and relationship with regulators. These partnerships with providers of ‘banking as a service’ or BaaS offerings allow fintechs to offer current accounts, wallet accounts, savings accounts and all the related services such as statements and balances.
The BaaS model allows any business to build a financial brand and embed financial services into its customer experience, as shown in the illustration. But while this makes it easy to build and start a fintech business, it is important that the fintech keeps control or ‘owns’ the customer experience and ensures that specific requirements are incorporated in the systems, regardless of how many services are outsourced.
FJ Image 1
Fintechs that provide banking services usually start with a BaaS solution to deliver the non-core solution and the regulatory requirements and licenses. As the business grows that may change.
There are other established forms of partnerships beyond BaaS.
CaaS, Credit as a Service, is a process where specialist companies provide all or parts of credit services from underwriting to collection. There’s IaaS, or Insurance as a Service, where an insurance company can provide from underwriting to the policy service, or specific parts of the process. There’s SaaS, software as a Service, when companies can provide all kinds of coding and programs maintenance and updates on specific processes within a company proposition; and there’s also Data Storage as a service. There are companies that can supply a full portfolio of white label products that can be sold under the fintech’s brand.
In summary, the concept of “as a service” enables fintechs to source specific components – the blocks that we referred to earlier – for the delivery processes and requirements of the solution from third party companies, linked to their systems via APIs. We will talk about APIs as we progress.
Normally the “as a service” contract enables a fintech to use the supplier’s license to sell its products and services. This helps it to initially avoid all the high costs and extensive bureaucratic processes related to obtaining licenses in the financial industry. Fintechs, to increase revenue, can expand their portfolio of solutions through distribution contracts, selling other companies’ products and services for a commission.
The “as a service” agreements are normally remunerated by a fee per transaction.
Fintechs make wide use of “as-a-service” agreements, enabling new companies and solutions to have very fast time to market, from idea to delivery. The fintech focuses on the core of its solution, developing only what is core for it and acquiring everything else from “as a service” companies.
Today as the delivery processes of products and services can be unbundled, split into modules, some fintechs specialise in supplying parts of the overall process of delivery of services and products. So, there are fintechs that provide only credit analysis for the underwriting process, fintechs that only provide sources of funding for credit (and serving as a bridge between investors and fintechs needing funding), and others that are focused only on the credit appraisal, pricing and loan management, as an example.
In summary, partnerships enable fintechs to concentrate on their core offering and to reach the market faster than traditional Financial Services companies, which would normally build all the processes and capabilities in house.
APIs are one concept that is central to the effort of partnerships and building in blocks.
APIs are sets of rules and protocols that allow different software applications to communicate with each other. They act as intermediaries, enabling one system to interact with another by requesting and exchanging data or functionality in a standardised way. There are alternatives for APIs, like; File-Based Integration, Data Base Sharing, ESBs (centralised data hub), Point to Point integration, and others. However, these all tend to have issues with costs, security, speed, data integrity, scalability and debugging when compared to APIs. That’s the reason APIs are the chosen method to establish the various links that fintechs need with their suppliers (or “as a service” providers).
APIs provide:
Normally, fintech start-ups do not have external funding until the pilot, when they will have something more tangible to show to potential investors. So, it is fundamental for you to understand how much money you need at this stage, so you can perform your test of concept and pilot and have a solid proposal to show to potential investors.
To properly budget, the decisions regarding the business model and architecture must be taken into consideration. This means deciding how much will be built internally vs. acquired from third parties, as this usually means a trade-off between higher set-up costs (to build in-house) vs. higher cost per transaction (acquiring from a provider). As the business grows, it makes sense to start building in-house some services previously acquired from a third party, as the cost is mostly based on the number of transactions or customers. The point here is to estimate if the founders will be able to fund the business up to the pilot phase, otherwise, the business will need to look for external funding.
There are many ways to have money flowing into your idea, which we will discuss next.