Contents
What is Fintech?
First, what does Fintech mean? Well according to Oxford Dictionaries it means “computer programs and other technology used to support or enable banking and financial services”.
So how does that differ from other platforms? There are mainly four things that differ:
Architecture & Scalability
Security
Availability
Compliance
But let’s start from the beginning. When analyzing an extremely complex platform like mobile banking software, most of the times you come up with a list of “everything”, meaning that your list of “must-haves” will be something like:
100% Security
100% Flexibility
And so on…
That's a nightmare, it's like asking a kid what they want for Christmas, the answer you don’t want is “Everything”, but that’s what you get here. The platform must be solid, it must be manageable, it must be flexible so that you can build on top of it to customize pretty much all of the functionality that it has (and add new ones).
So, the first question you will have to answer is what technologies should you use? Well, you can use pretty much everything, the choices you have are pretty much unlimited, but when selecting from all the different technologies you can use, there are pitfalls. We strongly recommend you use technologies that have as much as possible from your wish list built in from scratch.
In this example, we will use a Microservice approach built on AWS. This is just one of many ways to build a Fintech platform, but it shows the mindset you need.
Fintech architecture & scalability
Our imaginary Fintech platform is built using the microservices approach in order to speed up deployment cycles, foster innovation and ownership, and improve the maintainability and scalability of software applications.
For the last several years, microservices have been an important trend in IT architecture. Microservices architecture is not a completely new approach to software engineering, but rather they are a collection and combination of successful and proven concepts such as agile software development, service-oriented architectures, API-first design, and continuous delivery.
Microservices include so many concepts that it is challenging to define it precisely. However, all microservices architectures share some common characteristics, as the following figure illustrates:
Decentralized – Microservices architectures are distributed systems with decentralized data management. They don’t rely on a unifying schema in a central database. Each microservice has its own view on data models. Microservices are also decentralized in the way they are developed, deployed, managed, and operated.
Independent – Different components in a Microservices architecture can be changed, upgraded, or replaced independently without affecting the functioning of other components. Similarly, the teams responsible for different Microservices are enabled to act independently from each other.
Do one thing well – Each microservice component is designed for a set of capabilities and focuses on a specific domain. If developers contribute so much code to a particular component of a service that the component reaches a certain level of complexity, then the service could be split into two or more services.
Polyglot – Microservices architectures don’t follow a “one size fits all” approach. Teams have the freedom to choose the best tool for their specific problems. As a consequence, Microservices architectures take a heterogeneous approach to operating systems, programming languages, data stores, and tools. This approach is called polyglot persistence and programming.
Black box – Individual microservice components are designed as black boxes, that is, they hide the details of their complexity from other components. Any communication between services happens via well-defined APIs to prevent implicit and hidden dependencies.
You build it, you run it – Typically, the team responsible for building a service is also responsible for operating and maintaining it in production. This principle is also known as DevOps. DevOps also helps bring developers into close contact with the actual users of their software and improves their understanding of the customers’ needs and expectations. The fact that DevOps is a key organizational principle for Microservices shouldn’t be underestimated because according to Conway’s law, system design is largely influenced by the organizational structure of the teams that build the system.
Let's take a look at one use-case where the microservices approach is perfect for a Fintech platform. Let’s say that you have 100 customers that use your platform, then the following happens:
Customer X wants to change something. There are four major options for us to make those changes:
Change a single instance of the platform for Customer X.
Change all instances but only allow access for the update to Customer X.
Create some type of scripting capability in the platform that allows Customer X to make their own changes.
Tell Customer X that it can't be done.
None of these options is a good way forward. You will end up with so many different platforms that you can't support Customer X in a good way, you would end up with so many versions of basically the same platform that if something would happen, you would not be able to assist in a good way. After a while, the platform would be huge and slow.
So how would a microservices architecture help? To answer that, lets first look at what microservices technology is. Here you can see a very simple eCommerce example of a Microservices Architecture:
The mobile apps and the web apps connect to one single API that then connects to the different services (you can ofc skip the API and go directly to the services, but this complicates things if it’s a large platform). Each service runs independently of other services. In the best of worlds, one single service has no idea about what other services do or how they function.
So, if you use this example and Company X wants to change some of their Shipping Services, they can simply build a Service that suits them and tell their platform to use that Service instead, in this example, use B.1.0.0. instead of A.1.0.0.
Not only does microservices technology eliminates significantly the complexity of the platform, but it also allows for a very simple way of upgrading the platform for specific companies.
Security
When it comes to a Fintech platform, security is one of the things that first comes to mind. But the security of a Fintech platform is different from security in other platforms. Let's compare with a blogging platform as we did earlier, if you have a blogging platform, you can allow every person (login) access to one blog where that person can write, publish, delete and so on. Simple as that. Your focus will probably be to keep unwanted people out (that is, people who shouldn’t have access).
In a Fintech platform things are way more complicated. If you are building a banking platform, for example, imagine who will have access to a single account. Its not just the person who owns the account, it’s also the bank manager, if it’s a corporate account, perhaps several people have access, and they have different types if access, the person that handles the books might need read rights only, while other might have the rights to transfer money (different amounts per different timeslots). Take a minute to think about your own bank accounts, who can do what?
This is where different roles come in, and how you treat these different roles. Our experience tells us one thing, you can never imagine all the roles that you will end up with in the beginning, you will always expand on the capabilities for the roles. So, make sure that the roles that you create are flexible and very easy to understand.
Why am we are talking about different roles in the security chapter? Because this is the base of your security, every role has to be secure, the different roles have to be able to do exactly what you want them to be able to do, at what time you want them to be able to do it, and in the right way. If you are using AWS, you have these security layers built in from scratch:
SOC 1/SSAE 16/ISAE 3402 (formerly SAS 70)
SOC 2
SOC 3
FISMA, DIACAP, and FedRAMP
DOD CSM Levels 1-5
PCI DSS Level 1
ISO 9001 / ISO 27001
ITAR • FIPS 140-2
MTCS Level 3
In addition, the flexibility and control that the AWS platform provides allow us to deploy solutions that meet several industry-specific standards, including:
Criminal Justice Information Services (CJIS)
Cloud Security Alliance (CSA)
Family Educational Rights and Privacy Act (FERPA)
Health Insurance Portability and Accountability Act (HIPAA)
Motion Picture Association of America (MPAA)
This is just very short about security and what you need to think about, we won’t go any further into this, but we hope you get the picture.
24/7 availability
A blogging platform (I know, but let’s stick to it) can be “down”, it’s not the end of the world. The reader will likely come back. If one of your users must push two times on “Publish” because there is a glitch, that’s fine. If you have a Fintech platform, this is not the case. You will need to be live all the time, there is no room for downtime. There are no such thing as a platform that is available 100% of the time, but you can get close, and for that period when the platform is down, you will have to plan for it. There are several ways of doing this. Customers are normally OK with planned downtime if they are told in advance, all major banking platforms have these planned downtimes. Glitches can also be acceptable (there shouldn’t be any, but we don’t live in a perfect world) but they have to be handled correctly. Let’s say that you are making a transfer and there is a glitch, the user has pressed the “send” button and nothing happens, the user must be informed that nothing has happened yet, in other words, the user must feel safe in pressing the button twice. This can be handled in several ways, the easiest way in this example would be to present the user with a small log on the screen showing everything that the user has done lately, this way the user can see if the transfer was made. But ofc, this can be handled in many ways.
There are many more use cases like this, but the biggest advantage of sticking to AWS is the availability rate which is close to 99%. It comes with plenty of options and opportunities to make your Fintech platform even more available by utilizing different apps, deploying the platform in several geographic locations, setting up "mirrors" and so on. As a Certified AWS partner, we can advise and implement the best practices of AWS architecture for Fintech, drop us a line for a free consultancy.
GDPR compliance
GDPR is a European privacy law. The GDPR is intended to harmonize data protection laws throughout the European Union (EU) by applying a single data protection law that is binding throughout each member state. The GDPR applies to all organizations that have an establishment in the EU or that offer goods or services to individuals in the EU when processing the “personal data” of EU residents. Personal data is any information relating to an identified or identifiable natural person.
One of the key aspects of the GDPR is that it aims to create consistency across EU member states on how personal data can be processed, used, and exchanged securely. Organizations will need to be able to demonstrate the security of the data they are processing and their compliance with the GDPR on a continual basis, by implementing and regularly reviewing robust technical and organizational measures, as well as compliance policies. Supervisory authorities will be able to issue fines of up to EUR 20 million, or 4% of annual worldwide turnover, whichever is higher. We won’t go any further into this, I’m sure you have read tons of material about it, let's just conclude that if you are building a Fintech platform, keep this in mind.
Certifications
This might not seem like a big thing, but after you have built your Fintech platform and are looking for customers/users, these questions will come up. If you are not sure how to implement this, make sure you find someone that can. This is one reason that we have selected AWS in this example, a lot of these features are built-in. Of course, it is not something that you can just “switch on” and then relax, it has to be dealt with and worked on. But it is much easier to do if you use AWS.
CJIS. AWS complies with the FBI's Criminal Justice Information Services (CJIS) standard. AWS signs CJIS security agreements with customers, including allowing or performing any required employee background checks according to the CJIS Security Policy.
Cyber Essentials Plus. Cyber Essentials Plus is a UK Government-backed, industry-supported certification scheme introduced in the UK to help organizations demonstrate operational security against common cyber-attacks. It demonstrates the baseline controls AWS implements to mitigate the risk from common Internet-based threats, within the context of the UK Government's "10 Steps to Cyber Security". It is backed by industry, including the Federation of Small Businesses, the Confederation of British Industry, and a number of insurance organizations that offer incentives for businesses holding this certification. Cyber Essentials sets out the necessary technical controls; the related assurance framework shows how the independent assurance process works for Cyber Essentials Plus certification through an annual external assessment conducted by an accredited assessor. Due to the regional nature of the certification, the certification scope is limited to EU (Ireland) region.
FIPS 140-2. The Federal Information Processing Standard (FIPS) Publication 140-2 is a US government security standard that specifies the security requirements for cryptographic modules protecting sensitive information. To support customers with FIPS 140-2 requirements, SSL terminations in AWS GovCloud (US) operate using FIPS 140-2 validated hardware. AWS works with AWS GovCloud (US) customers to provide the information they need to help manage compliance when using the AWS GovCloud (US) environment.
FISMA and DIACAP. AWS enables US government agencies to achieve and sustain compliance with the Federal Information Security Management Act (FISMA). The AWS infrastructure has been evaluated by independent assessors for a variety of government systems as part of their system owners' approval process. Numerous Federal Civilian and Department of Defense (DoD) organizations have successfully achieved security authorizations for systems hosted on AWS in accordance with the Risk Management Framework (RMF) process defined in NIST 800-37 and DoD Information Assurance Certification and Accreditation Process (DIACAP).
ISO 9001. AWS has achieved ISO 9001 certification, AWS’ ISO 9001 certification directly supports customers who develop, migrate and operate their quality-controlled IT systems in the AWS cloud. Customers can leverage AWS’ compliance reports as evidence for their own ISO 9001 programs and industry-specific quality programs, such as GxP in life sciences, ISO 13485 in medical devices, AS9100 in aerospace, and ISO/TS 16949 in Amazon Web Services Risk and Compliance May 2017 Page 11 of 81 automotive. AWS customers who don't have quality system requirements will still benefit from the additional assurance and transparency that an ISO 9001 certification provides.
ISO 27001. AWS has achieved ISO 27001 certification of our Information Security Management System (ISMS) covering AWS infrastructure, data centers, and services. ISO 27001/27002 is a widely-adopted global security standard that sets out requirements and best practices for a systematic approach to managing company and customer information that’s based on periodic risk assessments appropriate to ever-changing threat scenarios. In order to achieve the certification, a company must show it has a systematic and ongoing approach to managing information security risks that affect the confidentiality, integrity, and availability of company and customer information. This certification reinforces Amazon’s commitment to providing significant information regarding our security controls and practices.
PCI DSS Level 1. AWS is Level 1 compliant under the Payment Card Industry (PCI) Data Security Standard (DSS). Customers can run applications on our PCI-compliant technology infrastructure for storing, processing, and transmitting credit card information in the cloud. In February 2013, the PCI Security Standards Council released PCI DSS Cloud Computing Guidelines. These guidelines provide customers who are managing a cardholder data environment with considerations for maintaining PCI DSS controls in the cloud. AWS has incorporated the PCI DSS Cloud Computing Guidelines into the AWS PCI Compliance Package for customers. The AWS PCI Compliance Package includes the AWS PCI Attestation of Compliance (AoC), which shows that AWS has been successfully validated against standards applicable to a Level 1 service provider under PCI DSS Version 3.1, and the AWS PCI Responsibility Summary, which explains how compliance responsibilities are shared between AWS and our customers in the cloud.
So here we are at the end, we hope that we have triggered your interest, and given you a little bit of a scare when it comes to building a Fintech platform. It's not easy, but it’s always fun. If you have an idea, reach out, we are here to help.
