Nov 18, 2022 5 min read Startup

How to build a FinTech Platform - Part 1

Over the last 3 years and 8 months of my life I have been working for a FinTech startup. November 15th 2022 was my last day working at this company officially as the CTO. The following is a re-collection of things that I was involved in building.

Building a FinTech platform is extremely intricate. Given the nature of FinTechs being heavily regulated, there were many challenges that had to be technically solved.

I started working with the company in March of 2019 as a freelance consultant. After having done my assessment as the consultant I felt being an external consultant didn't give enough of a deep dive into the intricacies and not enough time to truly solve the challenges.

The company needed a platform and a team that would bring them to the next level. They needed to own the core platform that would power their entire suite of products. I told them that I needed to join the company as full-time CTO to achieve that vision. In April 2019 I was made the CTO of the company.

To truly understand the scope of what was asked. Let's first understand what are the ingredients that goes into a FinTech platform.

Know Your Customer

As engineers we are generally used to building user registrations. Knowing your Customer is a journey that starts with user registration but goes into much more detail than that. The process is designed ensure the following:

The customer registering is who they say they are
The documents supplied by the customer are legitimate and not fraudulent
The customer is low risk and conforms with the risk appetite of the company

The process of KYC is one of the main risk mitigation strategies used by financial institutions to manage the risk within the organization.

The above are the basic ideas behind KYC. In the next parts I will go into detail of all the various standards that exists and how it relates to the product of the company. Different criteria of product requires different levels of KYC. There is a document from NIST a government agency that outlines this in detail. In the following I will cover the various standards and where they apply in the context of the product. There are 2 standards I will cover in this post IAL and AAL.

IAL - Identity Assurance Level

The goal of IAL standard is to govern the procedure of ensuring that the person is who they say they really are. There are 3 levels for IAL

IAL 1 - There is almost no identity proofing with this level. You can compare this to signing up for social media. Maybe you confirm the email address using some automated verification.
IAL 2 - This is where the REAL identity proofing starts. This onboarding can happen remotely or in-person. There are checks in place to verify the identity of the customers signing up. I would say this level is where most of the fun is. We will explore this level of proofing in detail.
IAL 3 - This is where the customer is physically present. Most people have been through this procedure. When you sign up for a bank account you are mostly required to be present, you have to give a certain document which is physically verified by the bank teller before they open the account for you.

Each of these levels correlate to the 'confidence' score for any given company. If a company is 'confident' in the identity assurance the risk is low. If they are less confident the risk is high.

AAL - Authenticator Assurance Level

Once the customer has signed up. There is also a requirement to ensure that when the customer logs in to use the service that they are who they say they are. Certain mechanisms need to be in place to ensure customer accounts are secure and only accessible by the intended customer. This is what AAL governs.

AAL1 - This essentially means single factor authentication. The user logs in to the system with email and password or username and password of some kind.
AAL2 - This adds a second factor of authentication, generally known as 2FA or 2 factor authentication. The 2 factors involve the following:
- What you have - This could be an OTP password sent to the user's email or mobile device via SMS. It signifies that the user 'has' access to the email registered with the company or 'has' access to the device attached to the mobile number associated with the product. This can also be authenticator apps like google auth that generate a new OTP based on time. There are many wasy to implement this factor.
- What you know - This is the password that only the user knows.
AAL3 - This takes the authentication mechanism to the next level. It requires using some kind if physical hardware like YubiKey or some kind of device that only the user would have.

Core Banking

It's important to recognize that FinTech covers a broad range of products. It can mean many types of products. Here are some examples of FinTech products

Exchanges
Cross Border Payments
Payment Gateway
Banking
Loan / Credit
Digital Wallets

These are just a few examples. However the point to note is no matter how different these products may be, they all require what I regard as 'core banking' mechanism of some kind.

Core Banking refers to the term that some kind of ledger needs to be kept. Whether to store how much is owed to the company or how much the company owes the customer. Even in cross border payments where no money is 'persisted' and stored long-term a core banking engine of some kind to keep track of money movement is required. At any point in time it's important that once money enters the company's jurisdiction it is known to the stakeholders where every cent / dollar is. If things are stuck why are they stuck.

Transaction and Customer Monitoring

Every financial product requires some kind of license to operate. The license enables entities to hold customer's money or conduct procedures with the customer's money. With that license comes a lot of responsibility.

One of the requirements that come with every license is that it's mandatory to monitor transactions and customers to ensure that everything that happens is in compliance with the law.

Monitoring involves things like, but not limited to:

Ensuring daily / monthly limits are not exceeded
Ensuring all sender / receiver names are screened against sanctions database
Sanctions databases are kept up-to-date
Ensuring strange behavior like making multiple transactions to bypass limits are not allowed
Ensuring the risk factor of transactions flowing through the system does not exceed the risk appetite set by the internal policies.

Secure and Private

Regulators take this one very seriously. Any platform that is built to service customers under financial law is required to ensure that it is indeed secure. It's the responsibility of the people who build and maintain these systems to make sure it is secure and private.

Since everything I mentioned above requires that the systems hold and manage sensitive information such as customer documents, identity information and how much money each customer has or is passing through the system. It is critical that the right security protocols are followed to ensure only the right people have access to the right information.

Now that we've established the 'stack' of what is required at a high level. In the next part I will go into further detail on each of these components how they come up as technical challenges and how these problems were overcame.