How to build a digital bank – find your footing
In episode 2, we continue with building a digital bank. In the previous one, we looked at definitions, challenges, solutions. Now we will dive into general concepts and insights that should help you find your footing.
The general concept of “Financial Technology” is services, business models, products, or software that are used for carrying out banking operations. This is nothing new since banks have been relying on software for banking operations for decades, however, banks have been relying on waterfall project life cycles to produce their private closed-source solutions.
The context of FinTech today has changed to include more modern and open approaches to software development and aims to provide services that compete with existing banking service models and offer a better user experience. We can see this already in modern day banking applications and websites that allow for a wide range of digital operations and focus on ease of use. Just think of your bank’s mobile app.
FinTech companies have been pushing the envelope and exploring “bankless” banking experiences and with the arrival of PSD2, this technology is being re-invented. The applications go beyond banking transactions; they also encompass insurance, credit checks, loans, investment, and deeper insights on financial risk management.
In terms of value, investment in this technology has increased by 4,236.55% from $930 million in 2008 to $39.4 billion in 2017. For the first half of 2018, this number is already at 41.7 billion. The largest segment for investment for 2018 is above $20 million meaning that projects have become larger and more expensive. This growth trend is expected to continue. A quick look at Google trends shows an increased general interest in this field. Interestingly, related searches include blockchain, big data, and artificial intelligence.
Expect to hear this term more frequently in the upcoming months and years.
PSD2 AND OPEN BANKING
The “Payment Services Directive” is an EU directive, or legal act, that regulates payment service providers and provides unified customer protection and legal rights and obligations for financial institutions across the EU and the EEA.
The directive was revised and in January 2018, the PSD2 directive came into effect and it obliges banks to provide APIs so that their parties can build their own services for managing finances, but does not include any specifications for these APIs.
Having a publicly available API means that third parties can build banking applications that interface with a specific bank’s back-end, and carry out financial operations.
With the lack of a clear API specification though, individual banks can still have different APIs which makes these third-party applications either specific to a single bank or overly complex as they would need to support multiple APIs for multiple banks.
This is true if we’re considering building a financial application that is required to make insights or transactions across multiple accounts in multiple banks, but, for the purpose of building a digital bank, it is sufficient to build one application for one bank’s infrastructure or platform.
As a solution to the problem above, the Open Bank Project was born. It is a BaaP, Banking as a Service, which offers an open source API and Application for banks and financial institutions. It supports all the necessary operations and pushes for wide adoption among banks across Europe. Unfortunately, it is yet to become the standard, and according to this article, there are over 30 banking APIs in use, so building an interoperable solution can be a challenge.
The main focus of this article series is to identify a solution for building a digital-only bank so it is necessary to clarify this concept before going further. The concept of digital banking is to deliver a full range of banking services over the internet, citing speed of operations and reducing operating costs as the main advantages.
A quick look at some of the leading digital-only banks shows how banks with as little as 21 employees can offer customers a bank account, debit card, and currency exchange services — a simple banking experience after a signup process that can take 10 minutes or less and is free of charge. Many services offer a real IBAN account and can easily replace the need for having brick-and-mortar bank accounts. Moreover, several digital banks offer features such as overdrafts, loans, insurance, deposits interest, forex trading, and rewards programs.
Some restrictions apply as to who can open such accounts. As part of the validation step, users are required to be residents or citizens of specific countries. This is either due to legal constraints or to avoid risks. This places heavy importance on validating the identity of the account owner.
The web components of a digital bank are mostly straightforward. A marketing-heavy website with fresh visuals and possibly some video elements should serve as an introduction to the service and convert visitors towards signing-up.
Storing user data is done through SDK.finance’s API and it is stored in their secure infrastructure. The account validation can be done on this level, or more commonly on the application level. The rest of the banking-related operations occur on the mobile applications, or optionally, can also be present on the web.
It is a good idea to include a FAQ section given that this is a new concept and users will often come with questions.
For the most part, any modern web development stack or framework is sufficient for these purposes. As for the option of carrying out banking operations on the web application, depending on how the mobile applications will be built, React Components from the mobile applications can be repurposed to build the banking component of the web application.
The main focus of mobile applications is performing banking operations and act as mobile wallets. To ensure the widest possible user adoption, it is highly recommended to support both Android and iOS devices. These applications need to be robust, intuitive to use and have lightning-fast response speeds.
Ideally, these applications should be written in the native languages, Objective C or Swift and Java or Kotlin, to ensure maximum performance and stability, which is required for a smooth user experience. This obviously requires more development resources and man-hours and necessitates the maintenance of two entirely separate code bases.
React Native offers the possibility of creating reusable components that are shared across platforms.
There is still a necessity of writing native code, but at least the front-end component can be reused. This approach also allows repurposing those components to build one unified user-experience across mobile and desktop applications.
The downside of React Native is performance, but a banking application does not require heavy processing, and for our purposes, this is a viable solution.
Front-end performance should not be an issue since the operations are as simple as querying and displaying data. Back-end performance, however, needs to be able to handle hundreds of operations per second. The actual number varies, of course, based on the number of users, but by design, the back-end and infrastructure should be scalable enough to handle a huge number of concurrent requests.
This is a deal breaker when it comes to user experience.
SDK.finance can be hosted on AWS and can also be hosted on a client’s server. Our preference is towards an AWS solution given its high performance and scalability features, but, if legal requirement necessitates that all data and operations be in a specific location, the platform can accommodate the requirement.
Assuming an AWS solution, they offer a development instance, which is a basic setup, a staging instance, which copies the full infrastructure of the production environment: load balancers, application servers, documents storage, etc…, and the production environment. Instance sizes can be configured to fit our needs.
In all cases, performance needs to be profiled and benchmarked throughout the development lifecycle in order to avoid unpleasant surprises close to the launch date.
More about SDK.finance, the application is written in Java. Although this may sound old school, Java offers excellent performance, security, and stability.
The platform offers general functionality of user registration and account management, as well as performing banking operations like transferring fund, balance checks, and currency exchange. The platform is built to be integrated with a custom front-end, and other third-party tools that are necessary for compliance, reporting, fraud protection, and more.
The platform also supports multiple roles, called Actors, with different security privileges and access to different operations. Additional information on the platform functionality can be found here.
The platform is PCI DSS compliant, which means that it qualifies to be used for issuing branded credit cards. Other than that, the platform complies to 4 other ISO certifications that are focused around digital security and user protection.
With the largest mega-component already meeting security standards, the applications should be built with the same standards in mind to ensure an end-to-end solution that is secure.
Without getting into the details of legal compliance, we can expect additional requirements to arise to satisfy certain legislation. We can expect the need to comply with GDPR. SDK.finance already is, but the web and mobile applications need to comply as well. We can also expect country-specific regulations regarding data retention, tax laws, reporting, and other requirements specific to business accounts. These topics are beyond the scope of this article.
The next part
In the next part, we will explore SDK.Finance in-depth, delving into the features and functionalities of the platform. We will touch on the topics of back office, user account management, banking features, messaging, customer support and APIs.
Scandiweb is a full-stack digital agency with expertise in FinTech, digital marketing, and eCommerce. If you have a problem or a question, we’ll be happy to find you an answer, just drop us a line at firstname.lastname@example.org!