Starting a fintech company

Over the last decade I’ve been immersed in financial technology. There is so much value to be added, and so much to understand. My startup BVNK has taken me on a journey and I have learned a lot of lessons. This article is the distillation of those lessons I wish I had read when I was starting my company.

When I started on this path the industry was super closed - there was no open banking, no real explainers on how the financial system worked, no clear idea even on what standards were used - everything was a mission. However, as the years rolled on things became more open and finding information became easier.

My company is building core banking systems for banks (new and existing) and as a result need to know about a lot of the financial system, with questions like which parties are involved, what are the requirements, who exactly are you targeting? As a result, I’ve come to understand the fintech industry deeply as a whole.

This article is meant to serve as a high-level primer to starting a fintech company. After reading this, you should have an understanding of the requirements for an idea you have including: where you sit in the value chain, who you need to talk to when selling, what permissions you need to operate and what a good go to market might look like.

If you have any feedback, questions or comments on this article feel free to get in touch with me at hi@ksred.me.

Where do you sit in the value chain

Many of the fintechs being started focus on offering the consumer some sort of product. Lately, the popular verticals have been investment (managed or “invest your spare change”), budgeting, and financing (short-term loans). These are generally the easiest to do as most people have direct experience here, you are building something for yourself so can easily adjust the product based on your experience.

The second group being focused on are Small and Medium Enterprises (SMEs). Banking solutions for SMEs have been notoriously bad while there has been a solid increase in tooling for this market (accounting, invoicing, payments). There’s a strong market need to integrate this new tooling in to the banking experience to make life easier for SMEs.

But the above use cases are such a tiny part of what happens to get to that end result. There are hundreds of places along the way where value can be added. Let’s go through an example to illustrate: the onboarding of a user in a bank.

When signing up to a new bank account, there is a bunch of required information you send to the bank. Some of this information is text only, some of it is documentation to be uploaded, and sometimes you need to go in to the bank in person (shock!). This is the typical, high-level journey of opening a bank account:

Alice (the customer) decides to open a bank account with ACME Bank.
Alice sends the bank her details: full name, date of birth, address, contact details, ID/social security/passport number. Sometimes she sends a lot more information, but this is normally the minimum.
Alice sends the bank documents to prove she is who she says she is and she stays where she says she stays.
Bob (ACME employee) validates these documents, either manually or through some trusted third-party.
Once these documents are validated, Bob processes the account opening.
Alice is notified that her account is open.

The above is nothing new, but there are already some clear places to add value along the way. Let’s dive in to one part in particular: Bob processing the documents. Within this step alone, there are several ways value can be added:

Process management. Bob is made to do things in a certain way due to the processes of his bank and the technology at his disposal. Could these processes be changed? If technology can assist here, by making this process more fluid or cutting out unnecessary steps, that would be a huge help to Bob.

Document storage. These documents need to be stored somewhere. A lot of the time, these documents are still only stored as paper. A document storage solution could be used where digital copies of these documents are safely kept offsite, digitised and version controlled, also allowing for easy search and retrieval on request.

Validation partners. Each application has two pieces of information that need to be proved through documentation: identity and address. A system could be used that integrates multiple third-party sources of truth (e.g. government identity services, local address checking services) to validate the documents sent and prove or disprove, even within a degree of certainty, the authenticity of the documentation.

AML check partners. Each application needs to be checked to see if the individual opening the account should be allowed to open an account. The exclusion lists contains:

Names of known terrorists
Politically exposed persons (PEP)
Financials checks
Sanctions, watch and black lists

There are a number of systems out there that help with validating these checks, but a lot of them are legacy. Are they API driven? Do they do real-time? What is their costing like? There is a lot of ground to find some differentiation here.

OCR technology. Most of the time during client onboarding, Bob would enter in the details from the application (usually a paper form) manually in to the system. This is time consuming and prone to error. OCR technology could be used to extract the relevant data not only from the application, but also from any attached documentation. Going further, software could be built that then fills in this information for Bob during the process. 10 minutes saved per onboarded person a year, multiplied by the number of new customers, and further multiplied by the cost of the employee makes for an easy argument.

With each of the above ideas entire businesses can be made. There are countless examples of taking one piece of a process and building multi-million dollar businesses around it.

The above process can also be applied to any task in any industry, there are thousands of ways to add value in today’s world.

Who to talk to when selling

Knowing who you need to talk to when selling is surprisingly difficult. This depends on who your target audience is (B2C or B2B) as well as where the integration points are.

Business to Customer (B2C)

If you are looking to sell directly to a customer, for example a budgeting application, you might have little involvement with banks. Most business applications would also fall under this category, for example an accounting application, as the same relation to the bank applies - both customers and business are clients of the bank. There are a few options here with different levels of difficulty.

If they have implemented Open APIs, you can start integrating and testing immediately. This is the easiest option by far.

Speak to: their new business team for startups, if they have one.

If they have APIs which are not open, you will need to get onboarded as a vendor in order to get the documentation and access required. Onboarding can take months, and if you want to integrate with more than one bank you’ll have to be onboarded to each bank. This would also probably mean there would be N different API integrations to do as they generally do not follow the same standards.

Speak to: their new business and compliance teams to get onboarded. You’ll probably need to sell your solution in to the bank, for that you need to speak to the technical team to get an understanding of what changes (if any) are required for them, as well as the business team to motivate why your solution should be integrated.

If they have no APIs, then you will need to look at other ways to integrate your solution. This could be getting a data dump at certain intervals, building a bridge between your system and theirs, or reading data from a read-replica of their database. There are a number of ways to get this done, and while this is harder than not having any API to integrate with it is by no means impossible.

Speak to: their new business team and compliance to get onboarded. You’ll need to sell your solution in to the bank and get a deep understanding of the technical requirements from their end as well as yours. Speak to their technical team, especially architects and technical leads, to get the insight you need to understand the cost to the bank (in man hours) as well as the cost to yourself. Once that is understood, you need to make a business case. Here you need a champion internally to push why this project should be undertaken by the bank.

Business to Business (B2B)

If you are looking to sell to a bank and have the bank be the customer of your software, it gets a little tougher. An example of a product here would be an Anti-Money Laundering module, a CRM system or an OCR document processing solution. For products in this sphere, getting in to the bank becomes a little more complicated.

A good first stop is the business. By speaking to the business, you can get feedback on whether or not they think it is a good idea and if it is currently needed by the bank. Remember: all budgets come from the business and all technical products have a business case, so if you don’t have buy in at this level selling your product will be very difficult. You would look for some tentative interest here, only enough to get you to the next stage of the process.

Speak to: if you are speaking to a small bank, the higher up the better. C-suite executives are great, followed by heads of departments. If you can get an intro that’s ideal, otherwise a phone call or a cold email will do. If it’s a bigger bank, then you would have better luck trying the heads of the relevant departments your solution caters to (on the business side).

The next stop would be the users of the product within the bank. Work through the relevant contacts, do interviews and clearly understand what will be required technically to land your product in to the bank. Understand what your product has and doesn’t have, the associated costs for getting to a place where you can land, as well as how long the process might take.

Speak to: for Fintech companies, this is generally the IT department. However, if your solution is a CRM tool it would also be the customer services department. You should try and cover all key users of your product in this round.

With an initial buy in from business, an understanding of the requirements to get your product in a place to land, you can now put together a formal proposal. The proposal will depend on the bank’s requirements, your product strategy and your go to market, but should be in a near final state including all relevant information.

Speak to: go back to the business and go through your proposal before formally submitting it. This would normally be the same people you engaged with initially, and they would your champion within the business. They will motivate to get budget for your product and help you get through any of the hurdles you’ll face (like becoming a vendor, any due diligence on the company, etc).

What permissions do you need

Every market has its own set of regulations around what permissions you need in order to do certain pieces of financial activity, whether that is accessing a user’s data, providing payments, or holding funds. We can apply some broad-brush strokes to give an idea of what you should expect, depending on your product. In all cases, you should probably reach out to your regulator to get guidance.

User data

If your product access or stores any user data, you’ll more than likely need to get some permission to do this. Depending on the data, the bars to get this authorisation aren’t too high. You will also need to keep in mind where you store the data. For a lot of territories you have to keep it within the borders of the country or union, and this sometimes means you can only use approved cloud providers.

Generally, if you can prove the security of your system, have auditing trails for the data as well as employees (who has access to the data, is it logged) and show good internal processes this should get you most of the way there.

Financial actions

When it comes to financial actions, like payments, managing portfolios, or other execution where value is transferred you’ll need to ensure additional checks and balances are in place. Luckily, the bar for this is not too high in most countries and normally only means additional security. If you’re holding sensitive data, especially PAN data (card details of a customer) you will need to ensure you comply with PCI DSS. Depending on your volume and the type of data you are storing here, a self-assessment might suffice.

Value storing

Value storage is the digital representation of monetary value. To some extent, this can be thought of as “bank lite” where you keep funds on behalf of users and they can transact using your system either through payments, deposits and/or withdrawals. Many neobanks start off this way, allowing them to test their proposition in a cost-effective way.

The bar gets raised even higher here, with additional focus on security and processes, as well as details of the team. Furthermore, there is normally a requirement for a given amount of funds the bank needs to have and hold aside. This could be £50,000 as a minimum, with an percentage of any total funds under your control reach a certain level. If you’re going this route, start conversations with regulators as early as possible.

There are alternatives to holding the license yourselves, like using a service provider who holds the license and allows you to use it, but it depends on your use case and product focus.

Interest bearing

There are further rules for any activity that involves interest, from savings accounts to loans to investments. In addition to all of the above, there will be checks on the team members as well as heightened financial requirements.

This is normally where banks make their money, especially recently with the decline in per transaction and monthly fees. In order to do this right, you need a very good understanding of your business model with mitigation plans in place.

Banking products

If you are selling your product to a bank, then you would need to look at your product in context of the above functionality to see where your solution would fall. You can ask yourself two questions to help understand your solution better: who owns the data and who holds the liability. These questions are normally great guiding posts for where your responsibility might fall and should get you most of the way to understanding your regulatory requirements.

What does a good go to market look like

There are entire books written on this topic, but I want to address some top line points which should give insight in to the fintech space in particular.

If you have a consumer facing product, your approach can be any number of avenues and the general rules apply. This could be word of mouth, advertising, partnerships, monetary incentives or anything in-between.

If you have a product you are selling to a bank, the go to market should take into account two main factors.

First, understand the risk your product poses within the organisation. A document management tool could have low risk if there are backups from existing systems. If it fails, then it’s not the end of the world. A general ledger product is critical to the functioning of a bank and if it fails there are huge costs to bear.

Second, understand the cost of implementing your product. The cost of implementation is not only the integration, licensing and support fees, it is also the time required from the bank to get the solution in place. If your product requires three persons time for four days a week over two months, that price effectively gets added to your product.

If your product is low risk and low cost, you could probably go in with the full solution from the outset. You sign the agreement, integrate and deploy to be fully in production.

If your product is high risk and high cost, you should first look at ways to lower the risk and cost. This could be having sufficient mitigation plans in place or lowering the requirement for the bank’s involvement. Next, you should look to phase the integration. Go in with a limited scope pilot to validate some aspects of your product and prove your worth. Move those pieces in to production and repeat the process until your product is fully live.

This is a much easier pill to swallow for the bank and will help you get in the door. If you try to go in with a high risk, high cost product right out of the gates your chances of landing are minimal. A part of the reason this is the case is personal risk. If your champion in the bank puts forward a solution and it fails, at the least their reputation is tarnished and at the most they get fired.

Summary

The fintech space is opening up, and possibilities will only accelerate as initiatives like Open Banking take hold. This is a super exciting time to be involved in this sector, and there are so many opportunities to create value.

Hopefully you got some helpful information from this post. If you’d like to get in touch, provide feedback, comments or have any questions, send me a mail at hi@ksred.me.