This article introduces a stack for banking-as-a-service, incl. the layers Infrastructure-as-a-service, Banking-as-a-Service and FinTech Application Services.

This article aims at providing an overview, setting FinTech services into a commercial and technical context.

During the 2010s, many financial services emerged which can be grouped as "Fintech". However it is regulations as the European Payment Services Directive, which promise to open the gateways for rapid growth through a legally enforced deregulation, as they break up the formerly monolithic services and turn them into distributed and decentralized Cloud-based value chains, where Banking is provided online as-a-service. An evolution like the Telecommunication sector during the 1990s and 2000s is likely to follow, with a fragmented, more dynamic, more competitive and more value-adding financial market.

What are Fintechs and what is Banking-as-a-Service?

The online journal FinTech Weekly defines FinTechs as

"a business that aims at providing financial services by making use of software and modern technology".

Simply put, FinTech is the marriage of technology and finance giving startups and service providers the ability to offer streamlined financial products/services that were previously only available through heavy-regulated, traditional financial institutions. Good examples of FinTechs who are changing how individuals and businesses deal with payment processing and borrowing money are Square, PayPal, Lending Club and Prosper. Today's and future FinTech startups are poised to revolutionize the banking industry and give traditional banks a run for their money.

Looking at a fully integrated financial service supply chain, we suggest to define the term Banking-as-a-Service as an

End-to-end process, ensuring the comprehensive completion of a financial service,
provided via the Internet on demand and managed within a specified timeframe.

Such a service implies the inclusion of

the financial service,
a management, deployment and delivery environment.
legal compliance with banking laws, provided through a player granted with a banking license
proper security mechanisms like strong authentication throughout the whole composed process, in compliance with laws of data protection within the concerned areas of jurisdiction.

What regulations are important?

Europe

Core to the Banking as a Service activities of Fintechs in Europe is the Payment Services Directive (PSD, 2007/64/EC), and in particular its 2nd amendment, known as PSD2, adopted in November 2015. PSD2 provides enhanced consumer protection in the context of online payment processes. The directive has been defined to ensure the coordination of national prudential regulation and supervision, the access of new payment service providers to the market, information requirements, and the respective rights and obligations of payment services users and providers.

The granting of banking license itself falls under the responsibility of the competent national authorities in the corresponding countries where a financial institution is registered (regulated in Directive 2013/36/EU in connection with Article 14 of Regulation (EU) No 1024/2013 of 15 October 2013). Following the principle of single authorisation, a financial institution which has been granted a license can provide the services throughout the whole European Single Market. Looking at requirements of authentication and potentially signed transactions, the eIDAS Regulation on electronic identification and trust services for electronic transactions in the internal market plays a vital role in throughout the whole end-to-end process.

Looking at role of online banks in the context of investment activities, the Markets in Financial Instruments Directive (Directive 2004/39/EC). may play a role. It is in force since November 2007 and governs the provision of investment services in financial instruments by online banks and the operation of traditional stock exchanges and alternative trading venues.

Assuming, that Banking-as-a-Service will not be limited to pure financial transactions, another directive potentially involved is the Insurance Distribution Directive or IDD (Directive 2016/97/EU) regulating the activities and online distribution of insurance products: intermediaries, insurance companies, their employees, bank-assurance, etc.

As the safe harbor agreement with US is still under revision there is a constraint on data storage: To be complaint with European data protection laws, customer data of financial institutions must not leave the area of jurisdiction.. In specific, a European bank would not be able to use an Infrastructure-as-a-Service (IaaS) provider from USA like AWS.

USA

In the USA, banking regulation is highly decentralized, regulated at both the federal and state level.

The U.S. Securities and Exchange Commission (SEC) has their hand in a lot of this, especially in investment/banking platforms such as Robinhood, Wealthfront, Acorns, etc. These platforms can't be backed by the Federal Deposit Insurance Corporation FDIC (which insures deposits, provides protection for investments, etc.), if the platform is not in compliance with SEC requirements for security.

It's still a topic that is controversely debated, as the bigger banks (e.g. Bank of America, Wells Fargo, HSBC, etc.) are highly regulated, while FinTechs have much more freedom to blaze ahead into cloud services, IoT, etc.

Haskell Garfinkel of PWC says that the financial services regulation in the U.S. builds on safety, soundness and consumer protection. In his view, regulators aim at balancing this with the plethora of innovation flooding in with the Fintech industry.

Asia

In comparison with Europe, Asia has the big disadvantage of high fragmentation of areas of jurisdiction. As workaround, Skinner suggests that FinTechs plug into national Banking-as-a-Service hub, using their nationally regulated and licensed face to the customers

Africa

Having been largely unserved, by traditional banking, FinTechs in Africa are not disruption anything but rather providing an original financing solution in a largely untapped market of highest demand. As an example, MFS Africa provides a cross-border mobile money gateway, reaching 120 million wallets. Africa's FinTech market is highly based on mobile connection which puts the market under a dual challenge, with highly fragmented markets of national jurisdiction, regulating the mobile telecommunication and the financial market.

Australia

As criticized in a recent article by The Australian, government regulation in Australia is lacking behind global developments, missing to push data sharing and interwoven supply chains via open APIs to the FinTech community, as provided e.g., in the European Payment Services Directive.

What is the Cloud-based infrastructure?

In the 2010, the team around Alex Lenk at the Karlsruhe Institute of Technology structured "the Cloud" as described in the stack below.

Cloud Computing Stack after Alexander Lenk et al.

Looking at it from the bottom, even the Internet is based on hardware. This basic compute and storage environment is virtualized, meaning it is made accessible to external professional users, agnostic of the specific hardware used.

This virtualization is called Infrastructure-as-a-Service or simply IaaS. Beyond the pure hardware, it includes services such as security mechanisms, escalation and recovery routines or compliance to national law and regulations.

On top you may find a Platform-as-a-Service (PaaS). Such a PaaS provides an environment where services can be programmed (programming environment) and executed. These services may be third party services (SaaS, explained hereafter), which can be plugged onto the platform like lego services on a logo mounting plate.Alternatively, the platform can provide API, which are interfaces allowing to execute services which are not hosted on the banking platform.

A good example is Salesforce, where specific software development kits are provided to adapt software services and to execute them in the Salesforce environment.

Why do the PaaS providers often provide a programming environment?
This has several reasons. First they need to be able to properly communicate with the Platform's interfaces. Second, to insure availability, the platform operator needs to check automatically whether a service is available or not. In a prescribed and properly defined software architecture the PaaS can simply ping the services, and those which are not responsive can be switched off or made invisible.

Last it is a question of security. The PaaS provider would be unable to see what happens in a black box software, especially when it is hosted in a different environment. Prescribing the architecture through programming environments or SDKs allow to look into the service and detect or rule out any malicious script in the first place. In a banking context this will be very important. A (banking-)-PaaS which can 100% prevent data-breach and cyber-fraud will be as secure as a monolythic bank.

Software-as-a-Service (SaaS) are all software services that can be plugged onto the platform, using standardized interfaces (APIs). In the Salesforce example, they could be any commercial service, from a financial service to an accountancy service, communicating via the platform.

In fact, SaaS could also live without a PaaS platform. However, such platforms often make life easier as interfaces are standardized between all the services that are using it. And they provide whole set of advantages that we will discuss later in the banking context. We will talk about platform-free concepts in the outlook.

There are in addition the cross-sectional services, which we find across all layers. They are

Business Support Services (Monitoring, Billing, Authentication, User-Management)
Administration Services (Deployment, Monitoring, Life Cycle Management).

The challenge is that some of these services need to cooperate across layers, e.g., user-authentication.

The Banking as a Service Stack (BaaS)

"Digital Bank"-author Chris Skinner suggests the following BaaS stack :

The underlying infrastructure-as-a-service is given by a "classical" licensed and regulated bank.

On top of such a regulated bank, Skinner sees a centralized Middleware which he calls Bank-as-a-Service. Plugged onto this Bank-as-a-Service are decomposed banking services, an ecosystem of Fintech-startups and service providers.

However the dynamic development in the FinTech world turned this model obsolete. The reason: tech-companies like Solaris provide the Middleware of Bank-as-a-Service but own a license to operate as a regulated bank in the same time. This means they do not need the underlying basement of a classical bank anymore. In the Solaris case, the German Federal Financial Supervisory Authority (BaFin) has granted tech company Solaris Bank a full German banking license.

Andreas Bittner, the managing director of Solaris Bank describes the Banking-as-a-Platform layer as follows:
"Our services are like Lego bricks: our partners can pick the bricks they require and assemble custom solutions to fit their business needs. Partners can access Solaris Platform services via our easy-to-implement API."

Redefining the banking-as-a-service stack, based on Lenk's Cloud-Stack and including the new developments in the FinTech world, we can suggest the following new structure:

IaaS

The basic infrastructure services can be provided by an infrastructure-as-a-service provider (e.g. AWS in the USA or Profitbricks in Europe). Many of them are available on demand. they do not need to be specifically "FinTech".

The IaaS provider is using the lowest layer which is physical Hardware.

BaaP (Bank as a Platform)

On top of IaaS we would find a Banking as a Platform (BaaP). This BaaP could be a fully licensed bank (like the Solaris Bank). But it could also be a FinTech which includes external licensed banking services from a classical regulated bank.

Some licensed bank position as a BaaP. The Open Bank Project provides a universal technical interface allowing to connect banks' core banking systems and banking apps from a massive ecosystem of FinTech companies.

On top of this Banking-as-a-Platform layer, the apps will be simply "plugged in". The services could be either deployed within the BaaP's servers are connected as external services through message protocols.

Data-security is a crucial role of the BaaP. They need to provide the monitoring functions which enable seamless and secure operations across domains and across applications.

An important aspect, authentication, will be discussed later in the article.

FinTech SaaS

FinTech SaaS are all atomic or composite software-based financial services which are made available on-demand.

When provided via a BaaP, they need to be compliant to the BaaP's requirements.

Depending on the constraints set by the BaaP, they might either work externally (conformity achieved through a Software Development Kit SDK, provided by the BaaP) or they are physically deployed within the BaaP. In that case they would be programmed (or adapted) within the BaaP's Programming Environment.

Interesting is that in addition to application services by FinTech startups, financial services of other banks can be plugged onto the BaaP to orchestrate new composed services (composite application services). I.e. in the European Community, the Payment Service Directive enforces an opening of API (by end 2017). In consequence, traditional banking services could be virtualized (sourrounded by some Cloud-service wrapping) and provisioned within a composite application service. In contrast to the infrastructure services from the IaaS layer below, these FinTech application services are centered about banking and finance.

The challenge of the BaaP is to make sure that none of the plugged-in services will contradict with the regulations, imposed by the national or regional supervising authorities.

HuaaS

Humans-as-a-Service represent the top layer in our suggested stack. This layer may currently not be important. However services by Cloudworkers, virtualized into FinTech services might represent a growing segment in the financial service market. We might imagine that labor intense services like insurance management or investment portfolio management could be delegated into countries with low labor costs, and integrated as services. The end-user will not see the difference between a purely automated service and a service that includes HuaaS.

Consequences and Possible Developments

An interesting consequence of such a decomposed stack is that the front-end to the customer could be accomplished in various ways. Either the BaaP providers appears directly as a bank to its customers. In that case it needs to provide a front-end user interface to the end-customers, including all the necessary features like user interface, user authentication etc. To the end-customer, the bank would appear like any other online bank, where services are seamlessly integrated and presented in one homogeneous user interface.

The second option is that the bank operates as white label bank. In such case one Software-as-a-Service provider on top of the BaaP will operate as front-end to the end-customer. This opens a plethora of possibilities for other companies (e.g., grocery stores) including banking services into their portfolio.

White Label Banking

The challenge for a platform provider is always to attain the critical mass, meaning to find enough customers in the first place to sign up. The strategy needs to place the front-end to the customers into an environment that already provides a sufficient amount of users. A good example could be

chains of hypermarkets, discount department stores or grocery stores
existing online portals which already have a sufficient "critical mass" of signed up users at their disposition
creating networks of user-groups, by allying a multitude of smaller user clusters and aggregating them to a big enough inital group-size.

As you might have noticed, we rather stress the customer side, as the service providers can be relatively easy orchestrated in, once a suitable amount of potential users can be exhibited.

Discussing the Advantages of an Integrated Approach with BaaP vs. Single Service Offering

In theory, a single service provider could also offer its atomic service to the end customer. But he would risk to fail, because of a lack of a suitably large portfolio of services to offer. Also composed services are more likely to provide and end-to-end value proposition in an efficient way (as service providers do not need to develop all required peripheral services like e.g., authentication but can orchestrate these into a workflow around the own service contribution.

From a technical perspective, a centralized banking platform (BaaP) would promise lots of simplifications, such as standardized programming environments or Software Development Kits (SDKs)

Also, BaaPs will be likely to provide a higher level of trust than a small player in the market.

In addition, there are a multiple commercial advantages.

Such a Platform-as-a-Service could provide a single interface to the end-customer (the actual user of the banking services), pooling all the many services of the external FinTechs which are part of the value chain. Such a service would promise to be much more dynamic than a classical monolithic bank, as it would benefit - just like the internet in a smaller version - from a decentralized process of value creation.
Competiting services could be offered, and the better ones survive the selection process of user-driven ranking processes.

A banking as a service platform could also benefit from dynamic network effects, which are effects generated around the platform, driven by the ecosystem. Let us imagine the following scenario: a user is using the platform, so once being signed up, he or she would feel inclined to also use other services, offered in the platform (just as done in the Amazon portal).

Reasons are

effectiveness (already signed up and implemented payment and supply structures)
trust (a bigger entity can easier establish trust as compared to many service providers competing on an atomic environment of countless small service providers, also security mechanisms like the programming environment may be established)

The fact that services may "easily" find users, may incite more service providers to come on-board. More service offers could motivate more customers to sign up. So the whole system gets into a dynamic growth process.

BaaS - Security

Statistics show that cyber criminality emerged into a major threat to banking in general. A threat that is already massive in monolithic banks with few entrance gateways for cyber-crime risks to grow exponential in composed service structures, where cyber-criminals may try to get access in every single service. Each service needs to be properly firewalled against malicious intrusion.

A major challenge to security is the interweaving of many domains and apps, which may be required to create a rich end-to-end service. A user once authenticated should use this authentication during his journey throughout all apps and domains. The cryptography pioneers at Cryptomathicin Cambridge speak of the 3 degrees of freedom in digital banking, involving

identity federation across domains
identity propagation across apps
and
the level of authentication

Outlook

The whole banking market is still in its startposition (given that regulations like PSD2 will soon be set into force). As compared to the phase of deregulation in the telecommunication market, we can expect the emergence of new business models where today nobody is yet thinking of.

Enhanced Security

On the security side, we suggest to make the inclusion of electronic signing (qualified electronic signatures) compliant to the European eIDAS Regulation mandatory. Standards like PAdES and in particular XAdES (published by the European Telecommunications Standards Institute) will allow to secure end-to-end transactions in several dimensons.

signed code by authenticated FinTech SaaS providers will document the service's origin and will avoid that code is tampered with.
signed transactions with authenticated originators.

BaaS without BaaP?

The W3C, driven by Tim Berners-Lee and research scientists around the world (e.g., the Knowledge Management research team around Rudi Studer) are researching the concept of semantically described relationships and services, which are machine-readable and which could allow to dynamically compose end-to-end processes. As Berners-Lee pointed out during the World-Wide-Web Conference 2012 in Lyon, this new concept could make platforms unnecessary in the future.

It could be an interesting chain of thought to imagine an interplay of semantic web, digital signing and digital authentication. Perhaps this could bring us a highly dynamic, effective and secure new digital banking world . . .

References

Read more articles on FinTechs in VentureSkies' blog section.
Read more on the services and packaged solutions which VentureSkies offers for FinTechs.
PSD2 Directive - DIRECTIVE (EU) 2015/2366 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 25 November 2015 on payment services in the internal market, amending Directives 2002/65/EC, 2009/110/EC and 2013/36/EU and Regulation (EU) No 1093/2010, and repealing Directive 2007/64/EC (2015), The European Parliament and the Council of the European Union.
DIRECTIVE 2007/64/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 13 November 2007 on payment services in the internal market amending Directives 97/7/EC, 2002/65/EC, 2005/60/EC and 2006/48/EC and repealing Directive 97/5/EC (2007), The European Parliament and the Council of the European Union.
Selected articles on Authentication (2014-16), by Heather Walker, Luis Balbas, Guillaume Forget and Dawn M. Turner
A tech company with a banking license: solarisBank offers the first banking platform for the digital economy (2016), Philip Blankennagel, Manager PR & Marketing, Solaris Bank
Selected articles on Electronic Signing and Digital Signatures (2014-16), by Ashiq JA, Guillaume Forget, Peter Landrock, Torben Pedersen, Dawn M. Turner and Tricia Wittig
Overview of APIs and Bank-as- a-Service in FINTECH (2016), by Chris Skinner
What’s Inside the Cloud? An Architectural Map of the Cloud Landscape (2009), by Alexander Lenk, Markus Klems, Jens Nimis, Stefan Tai (KIT) and Thomas Sandholm (HP-Labs)

Blog

Banking-as-a-Service - what you need to know