Skip to main content

Banks are finally embracing the Open Source movement


Historically banks have been hesitant to adopt open source software (i.e. software where source code is shared and made freely available). With traditional vendors like IBM, TIBCO, Oracle…​ strongly positioned in this industry, the move to open source has been slow. In recent years, forced by a rapidly changing business, banks are transforming their IT organizations considerably, adopting new technologies and methodologies like Cloud, microservices, Open APIs, DevOps, Agile and also Open Source (often these different adoptions enforce each other).
The Open Source movement has already reached a certain level of maturity. While 5-10 years ago, Open Source was still considered something of computer-nerds, idealists and small start-ups, today it has become mainstream. The recent acquisitions of open-source companies by large established corporate tech-vendors is the best proof of this evolution:
  • SalesForce bought MuleSoft for $6.5 billion in March 2018
  • Microsoft bought GitHub for $7.5 billion in October 2018.
  • IBM purchased Red Hat for $34 billion in 2019
At the same time these incumbent tech players are adopting a true open source strategy themselves. E.g. Microsoft, initially one of the most has adopted an open source strategy, since Satya Nadella became CEO in 2014, e.g.
  • Edge: the Edge browser is switching to the Google based open source Chromium platform
  • .NET framework: the full .NET framework was open-sourced on Git-Hub
  • Windows 10: built on open-source Progressive Web App technology
  • Windows 11: analysts speculate that the NT kernel would be (gradually) replaced by the Linux kernel
  • Azure platform: the most used operating system on Microsoft Azure is not Windows Server, but rather Linux
  • Open-source contribution: Microsoft has become the largest contributor to open source in the world (considerably more active that the second most active contributor, Google), with 20,000 Microsoft employees on GitHub and over 2,000 open-source projects
Nonetheless a consolidation movement in the open source space is still required. With thousands of different projects, usually only maintained by 1 company, it is difficult to speak of a real open-source community or ecosystem. A larger adoption of open-source software (both in usage and is contributing back) by large corporates together with a consolidation, will result in a smaller number of projects, but with larger communities.
Even though bank leaders are becoming convinced that leveraging open source technology is the future, banks will not transform over night to open source adepts. Just like introducing all other new technologies and methodologies, embracing open source software requires a cultural shift in the whole organization, which takes time and intensive change management.
The adoption will evolve according to two axes:
  • The involvement of the bank in the open source ecosystem
  • The type of open source products it is adopting
According to the first axe, the organization should evolve from Using open source up to Opening its own proprietary software:
  • Use: banks should adopt a strategy to give preference to open source software, where possible. This can be full solutions or open source components, which the bank glues together into the target custom-built application.
  • Contribute: the intensive usage of open source will surely lead to the identification of bugs and the implementation of valuable features on top of the open source software. Instead of building a quick-and-dirty patch, banks should learn to build a more generic and well-designed solution, which can be contributed back to the open source community. This will not only improve the bank’s corporate image, but will also allow the bank to profit from the testing and future extensions applied by the community on this implementation, ultimately improving future maintenance.
  • Open: the final step is to open the existing proprietary software of the bank. This is the most complex, as it is the most time intensive (all tentacles to other systems of the bank need to be nicely decoupled), most risky for the bank (banks fear that their code will be scrutinized in public, thus resulting in a brand risk and fear that potential security issues become exposed) and most difficult to convince all bank leaders (fear of giving away competitive advantage, i.e. the secret sauce).
The second axe is the type of open source product, which overlaps with the level of abstraction. Banks should first gain experience with low-level abstraction open source software, like databases (e.g. MySQL, Mongo DB, Cassandra and Postgres), middleware (e.g. WSO2, Kafka, Apache Camel, Envoy, Istio…​), operating systems (e.g. Linux and Kubernetes)…​ Gradually they should move up the stack to higher level of abstractions, like business process (e.g. jBPM) and task management tools, to finally use also open source for the financial core processes themselves (e.g. Cyclos, Mifos X / Apache Fineract, MyBanco, Jainam Software, OpenCBS, OpenBankProject, Cobis, OpenBankIT, Mojaloop). Ultimately all software of a bank should have at its core open-source software, with the exception of solutions exclusively offered via SaaS.
This evolution has definitely started already. Almost all banks are already using multiple open-source software solutions. Many banks are furthermore preferring open-source software over proprietary software, in vendor selection processes for new software. Especially the argument of avoiding vendor lock-in is used to defend this choice. Additionally, a growing number of banks is already contributing to existing open source projects or even open sourcing their own software, e.g.
  • Open source has been one of the core elements in Capital One’s (one of the largest credit card companies in the US) digital transformation journey over the past 6 years.
  • Goldman Sachs recently decided to open source its proprietary data modeling program Alloy
  • J.P. Morgan Chase released code on GitHub for multiple initiatives, e.g. its Quorum blockchain project.
  • Deutsche Bank open-sourced multiple projects, like Plexus Interop (from its electronic trading platform Autobahn) or Waltz (IT estate management)
  • …​
The move of some banks to open-source proprietary software seems strange at first sight, as software has become more and more a competitive edge of a bank. Nonetheless banks have a lot to gain in using (adopting) open source and contributing to it:
  • Using open source software:
    • Lower costs: avoid the exuberant annual software license costs paid to software vendors.
    • Reduce time-to-market: allowing developers to bolt together pre-existing modules rather than having to create them all from scratch, allows to considerably reduce development time.
    • Easily customizable: open-source software can be customized, allowing to provide the golden mean between buying a software package from a vendor (quick time-to-market, but limited customization possibilities) and internally custom-built software.
    • No vendor lock-in
    • Lower learning curve for new joiners
  • Contributing and opening open source software:
    • Good for corporate image (giving back to the community)
    • Transparency: open-source software is intrinsically more secure than proprietary software, where the code is kept a secret.
    • Easier hiring of resources, as IT resources like to work on open-source and good potential candidates can be identified by looking at public commits of externals to the bank’s open-source projects
    • Motivation: often IT resources at banks feel a lack of social commitment. Contributing back to open source can give them a feeling of proud and giving back to community.
    • Cultural accelerator: open source communities promote collaboration, almost always remote and often across different time zones and cultures. Collaborating in such an environment will make bank IT’ers better and more adapted for future evolutions.
    • Gain from testing and extensions built by contributors outside the bank
    • Facilitates collaboration between different banks on shared concerns like KYC (Know Your Customer) and AML (Anti-Money Laundering)
Even though these advantages are hard to ignore, it’s not all rosy. It is therefore no wonder, there is still a lot of reluctance against open source, specifically against contributing and opening proprietary software.
  • Contractual and legal: a variety of different open-source software license models exist. Using open source can therefore be a serious challenge to ensure compliance with all terms and conditions of the license model. Such uncertainty can be a huge constraint for a large bank. Luckily more and more tools appear on the market (e.g. FOSSA, DejaCode, WhiteSource, Code Janitor), which allow to monitor and follow-up the compliance on open-source licenses.
  • Support: banks fear a lack of support in case of issues when using open source. For many open-source tools, commercial firms are offering corporate support, resolving this limitation. If not, the bank IT teams should engage with the open-source community to resolve an issue. Although this is more complex than raising an incident to the support desk of an IT vendor, such engagement will often lead to a faster and better resolution of the issue.
  • Compliance and security: while ultimately open-sourcing code will lead to more secure software, when first publishing your source code on the internet, there is a risk that criminals can find loopholes in the code.
  • Give away competitive advantage: although this is definitely true for differentiating services, the majority of internal banking software is commodity software, which doesn’t provide any differentiation. Open sourcing these applications can free up resources to work on real value-added services.
  • Brand risk: banks fear that open-sourcing bad software can do more harm than well, with regards to corporate branding.
If banks massively adopt open-source, one can wonder if Fintechs offering innovative software services to banks are not doomed to fail. Luckily Fintechs have already evolved from an annual license model to more modern models of partnerships. With the adoption of the cloud and elastically-scalable hardware and the notion of "a user" becoming more and more vague (due to multi-channel architectures and the rise of Open APIs), the concept of paying an annual license for corporate software has become difficult to defend and negotiate (licenses based on number of servers/CPUs or number of named/concurrent users have become obsolete). Instead software licenses costs are being replaced by different partnership models, like:
  • PaaS (Platform as a Service), SaaS (Software as a Service) and Baas (Business as a Service) models
  • "Open core" models (also called Dual-licensing), where the core of the software is delivered for free and open-source, while tooling specifically for large corporations are license based
  • Support model: pay a party for access to a support desk and providing updates on when new versions should be installed
  • Realize profits from a service model, e.g. training services, implementation services, customizations to the open source software at request of the bank…​
Fostering such an open ecosystem of Fintechs and banks will ultimately lead to better products and services for everyone. Banks must realize that technology is at the heart of their business. They should therefore try to copy the success formulas of the large tech-giants, i.e. attracting the best people, leveraging existing software, flat organizational structures and methodologies supporting rapid change (like DevOps, Agile…​). Adopting an open source strategy can be a strong lever to reach this goal.

Comments

Popular posts from this blog

Transforming the insurance sector to an Open API Ecosystem

1. Introduction "Open" has recently become a new buzzword in the financial services industry, i.e.   open data, open APIs, Open Banking, Open Insurance …​, but what does this new buzzword really mean? "Open" refers to the capability of companies to expose their services to the outside world, so that   external partners or even competitors   can use these services to bring added value to their customers. This trend is made possible by the technological evolution of   open APIs (Application Programming Interfaces), which are the   digital ports making this communication possible. Together companies, interconnected through open APIs, form a true   API ecosystem , offering best-of-breed customer experience, by combining the digital services offered by multiple companies. In the   technology sector   this evolution has been ongoing for multiple years (think about the travelling sector, allowing you to book any hotel online). An excellent example of this

Are product silos in a bank inevitable?

Silo thinking   is often frowned upon in the industry. It is often a synonym for bureaucratic processes and politics and in almost every article describing the threats of new innovative Fintech players on the banking industry, the strong bank product silos are put forward as one of the main blockages why incumbent banks are not able to (quickly) react to the changing customer expectations. Customers want solutions to their problems   and do not want to be bothered about the internal organisation of their bank. Most banks are however organized by product domain (daily banking, investments and lending) and by customer segmentation (retail banking, private banking, SMEs and corporates). This division is reflected both at business and IT side and almost automatically leads to the creation of silos. It is however difficult to reorganize a bank without creating new silos or introducing other types of issues and inefficiencies. An organization is never ideal and needs to take a number of cons

RPA - The miracle solution for incumbent banks to bridge the automation gap with neo-banks?

Hypes and marketing buzz words are strongly present in the IT landscape. Often these are existing concepts, which have evolved technologically and are then renamed to a new term, as if it were a brand new technology or concept. If you want to understand and assess these new trends, it is important to   reduce the concepts to their essence and compare them with existing technologies , e.g. Integration (middleware) software   ensures that 2 separate applications or components can be integrated in an easy way. Of course, there is a huge evolution in the protocols, volumes of exchanged data, scalability, performance…​, but in essence the problem remains the same. Nonetheless, there have been multiple terms for integration software such as ETL, ESB, EAI, SOA, Service Mesh…​ Data storage software   ensures that data is stored in such a way that data is not lost and that there is some kind guaranteed consistency, maximum availability and scalability, easy retrieval and searching

IoT - Revolution or Evolution in the Financial Services Industry

1. The IoT hype We have all heard about the   "Internet of Things" (IoT)   as this revolutionary new technology, which will radically change our lives. But is it really such a revolution and will it really have an impact on the Financial Services Industry? To refresh our memory, the Internet of Things (IoT) refers to any   object , which is able to   collect data and communicate and share this information (like condition, geolocation…​)   over the internet . This communication will often occur between 2 objects (i.e. not involving any human), which is often referred to as Machine-to-Machine (M2M) communication. Well known examples are home thermostats, home security systems, fitness and health monitors, wearables…​ This all seems futuristic, but   smartphones, tablets and smartwatches   can also be considered as IoT devices. More importantly, beside these futuristic visions of IoT, the smartphone will most likely continue to be the center of the connected devi

PSD3: The Next Phase in Europe’s Payment Services Regulation

With the successful rollout of PSD2, the European Union (EU) continues to advance innovation in the payments domain through the anticipated introduction of the   Payment Services Directive 3 (PSD3) . On June 28, 2023, the European Commission published a draft proposal for PSD3 and the   Payment Services Regulation (PSR) . The finalized versions of this directive and associated regulation are expected to be available by late 2024, although some predictions suggest a more likely timeline of Q2 or Q3 2025. Given that member states are typically granted an 18-month transition period, PSD3 is expected to come into effect sometime in 2026. Notably, the Commission has introduced a regulation (PSR) alongside the PSD3 directive, ensuring more harmonization across member states as regulations are immediately effective and do not require national implementation, unlike directives. PSD3 shares the same objectives as PSD2, i.e.   increasing competition in the payments landscape and enhancing consum

Trade-offs Are Inevitable in Software Delivery - Remember the CAP Theorem

In the world of financial services, the integrity of data systems is fundamentally reliant on   non-functional requirements (NFRs)   such as reliability and security. Despite their importance, NFRs often receive secondary consideration during project scoping, typically being reduced to a generic checklist aimed more at compliance than at genuine functionality. Regrettably, these initial NFRs are seldom met after delivery, which does not usually prevent deployment to production due to the vague and unrealistic nature of the original specifications. This common scenario results in significant end-user frustration as the system does not perform as expected, often being less stable or slower than anticipated. This situation underscores the need for   better education on how to articulate and define NFRs , i.e. demanding only what is truly necessary and feasible within the given budget. Early and transparent discussions can lead to system architecture being tailored more closely to realisti

An overview of 1-year blogging

Last week I published my   60th post   on my blog called   Bankloch   (a reference to "Banking" and my family name). The past year, I have published a blog on a weekly basis, providing my humble personal vision on the topics of Fintech, IT software delivery and mobility. This blogging has mainly been a   personal enrichment , as it forced me to dive deep into a number of different topics, not only in researching for content, but also in trying to identify trends, innovations and patterns into these topics. Furthermore it allowed me to have several very interesting conversations and discussions with passionate colleagues in the financial industry and to get more insights into the wonderful world of blogging and more general of digital marketing, exploring subjects and tools like: Search Engine Optimization (SEO) LinkedIn post optimization Google Search Console Google AdWorks Google Blogger Thinker360 Finextra …​ Clearly it is   not easy to get the necessary attention . With th

Low- and No-code platforms - Will IT developers soon be out of a job?

“ The future of coding is no coding at all ” - Chris Wanstrath (CEO at GitHub). Mid May I posted a blog on RPA (Robotic Process Automation -   https://bankloch.blogspot.com/2020/05/rpa-miracle-solution-for-incumbent.html ) on how this technology, promises the world to companies. A very similar story is found with low- and no-code platforms, which also promise that business people, with limited to no knowledge of IT, can create complex business applications. These   platforms originate , just as RPA tools,   from the growing demand for IT developments , while IT cannot keep up with the available capacity. As a result, an enormous gap between IT teams and business demands is created, which is often filled by shadow-IT departments, which extend the IT workforce and create business tools in Excel, Access, WordPress…​ Unfortunately these tools built in shadow-IT departments arrive very soon at their limits, as they don’t support the required non-functional requirements (like high availabili

Deals as a competitive differentiator in the financial sector

In my blog " Customer acquisition cost: probably the most valuable metric for Fintechs " ( https://bankloch.blogspot.com/2020/06/customer-acquisition-cost-probably-most.html ) I described how a customer acquisition strategy can make or break a Fintech. In the traditional Retail sector, focused on selling different types of products for personal usage to end-customers,   customer acquisition  is just as important. No wonder that the advertisement sector is a multi-billion dollar industry. However in recent years due to the digitalization and consequently the rise of   Digital Marketing , customer acquisition has become much more focused on   delivering the right message via the right channel to the right person on the right time . Big tech players like Google and Facebook are specialized in this kind of targeted marketing, which is a key factor for their success and multi-billion valuations. Their exponential growth in marketing revenues seems however coming to a halt, as digi

AI in Financial Services - A buzzword that is here to stay!

In a few of my most recent blogs I tried to   demystify some of the buzzwords   (like blockchain, Low- and No-Code platforms, RPA…​), which are commonly used in the financial services industry. These buzzwords often entail interesting innovations, but contrary to their promise, they are not silver bullets solving any problem. Another such buzzword is   AI   (or also referred to as Machine Learning, Deep Learning, Enforced Learning…​ - the difference between those terms put aside). Again this term is also seriously hyped, creating unrealistic expectations, but contrary to many other buzzwords, this is something I truly believe will have a much larger impact on the financial services industry than many other buzzwords. This opinion is backed by a study of McKinsey and PWC indicating that 72% of company leaders consider that AI will be the most competitive advantage of the future and that this technology will be the most disruptive force in the decades to come. Deep Learning (= DL) is a s