Modern Software Engineering Principles for Fintechs by Daniel Pilon at SumUp
- Erlang Solutions Team
- 7th Jun 2022
- 10 min of reading time
Daniel Pilon is a Software Engineering Manager at SumUp. Since 2007 he has worked across several industries before arriving in the fintech space. He has experience in many programming languages, such as C#, Java and JavaScript but since discovering Elixir and the power of functional programming a few years ago, he hasn’t looked back.
Right now he is building SumUp Bank, a complete digital banking solution to empower small merchants and simplify their financial needs.
We spoke to Daniel about his experiences using Elixir in the financial services domain, here’s what he had to say.
Financial services handle, in different ways, other people’s or companies’ money. It’s vital for the success of a fintech company that those clients can trust that their money will be handled without any unpleasant surprises and that they can use the services any time they need. For fintechs to be able to give this level of trust to their clients, they must start by first trusting their operation.
Given that fintechs don’t have the same level of resources and size as banks and incumbent Financial Services Institutions (FSIs) that have been established for decades – any problem that arises could be critical and difficult to determine and recover, should it need manual intervention. For these reasons, it’s really crucial to the business that the services that support the operation are up and available for the vast majority of the time.
There are many reputational and business risks that may arise from downtime or intermittence in availability. For example, if you’re a fintech that provides payment services, it might cause the client to be unable to pay for their shopping cart in a supermarket or online. When this occurs, clients lose confidence and will either stop using your services or even seek legal ways to repair their damage. This leads to reputational damage to your brand and metrics such as your Net Promoter Score (NPS).
There are several practices that are required in order to keep services up and to anticipate problems, such as building robust observability, having a comprehensive automated test suite, keeping track of MTTD (mean time to detect), MTTR (mean time to recover) and MTBF (mean time between failures) and always iterating over those metrics in order to learn what they say about the opportunities to enhance the company infrastructure.
When it comes to handling demand and being able to scale, it’s crucial that the company can statistically determine business expectations so that the engineering teams can decide the best approach for development. Without numbers it’s possible that engineers will either be too optimistic about the load the applications supports or will try to optimise early for a load that shouldn’t be expected in the short or mid-term, delaying deliveries and losing time to market. With the right information, engineers are empowered to decide what is important for the current status of the company and what can be done later, as well as having stress and load tests that can show how the system is behaving against the expectations.
What I like the most about using Why did SumUp use the Erlang ecosystem?
The Erlang ecosystem has been empowering SumUp since day one. We started as a payment solutions provider for small merchants and the core services that enabled us to scale our transaction processing power to the millions were mostly written in Erlang. Since SumUp’s mission is to enable small businesses to have access to digital payment solutions and most of our clients are transacting small amounts in their transactions, we needed confidence that we could take those transactions. They are vital to our client’s businesses, so they are vital for SumUp as well. Erlang and the BEAM VM gave us the highest level of confidence in this aspect, given that it is battle-tested for decades, it’s built to scale readily, it allows us to make concurrent processing easier and it has fault tolerance as a first-class citizen. But, most importantly, we need platforms where I/O intensive operations are handled well by design, so we can confidently process as many parallel payments as we need. The BEAM VM checks the boxes for all of the aforementioned aspects. Over time SumUp grew exponentially and now we are in a position of increasing our offer of financial products to clients, adding services such as digital banking and credit/lending. The building of a digital bank in Brazil started in 2019 when it was decided that the core language for our backend services would be Elixir. With Elixir, we continue to have everything that makes Erlang so powerful, but with a modernised syntax and mature tooling for production usage. At SumUp Bank we currently run Elixir in a microservices architecture, running on AWS with Kubernetes via EKS. Our services are backed by Postgres databases when needed, with data exposure via RESTful APIs. For asynchronous communication, we use AWS SNS/SQS. Our clients all connect to BFFs (Backends for frontends) built using GraphQL. This is all made possible by robust libraries that are available as open-source for Elixir applications, such as Phoenix, Ecto, Absinthe, ExAws and Broadway. Over these last two years of running a bank in production, we learnt that Elixir/Erlang was the best choice we could have made. We were able to start small, quickly run in production and scale as we needed. For example, it was not until we reached some scale that we started to prioritise asynchronous communication between services and it was simple and straightforward to move to this type of architecture with the help of a library like Dashbit’s Broadway. The Elixir/Erlang applications being lightweight and fault-tolerant also give us a lot of flexibility to use computational resources wisely, lowering our costs with infrastructure, while still providing outstanding throughput. Open-source has dramatically changed fintech and many other industries for the better. Personally, I can’t imagine us living in such a fast-changing and diverse world of options if not for the popularity and adoption of open-source. The speed at which companies are now able to deliver new technologies without the burden of having to reinvent the wheel or pay a huge amount for proprietary software is one of the foundations for such a transformation. In the Elixir community, contribution to open-source is just an organic aspect of how things work. When I started my journey, the community was something that really caught my attention. The energy and the willingness to help each other were way advanced when compared to my days with .NET or Java. Today, those technologies also have strong communities contributing to open-source, but it’s something that most people had to learn while it was happening. With Elixir, most of the general purpose libraries are open-source and they are very mature. I can cite that my experience writing code for financial services using Phoenix, Broadway, Ecto and others have been joyful and every time I had to seek help with the appropriate usage or with issues, I have found it. The power and synergy of the Elixir community are impressive as there’s always somewhere one can reach out in order to seek help or contribute. Of course, there are some areas where I think we still need to improve. For instance, some of the libraries that make the ecosystem stronger and that can ease the adoption of the language are not always highly maintained. The ExAws library is a great library to interact with AWS services. However, it was on the verge of being abandoned around 2020, when the original maintainer left the project. Now another maintainer stepped in and assumed the responsibility for the project, so it’s receiving contributions and being released. Also, financial systems commonly have to handle integrations with third parties which are not always straightforward RESTful APIs, or some other more commonly used technology for integrations. Integrations based on positional files, or SOAP are unfortunately still there. More established ecosystems, such as Java, have plenty of options for implementations in these scenarios, while in Elixir, given that it’s more recent, it’s not always the case. However, from my experience, this is a minor issue weighed against all the positives the language brings and hasn’t been a massive burden when this sort of requirement has arisen. It would be great if there were more companies using Elixir willing to give back to the open-source community for Elixir. Either via opening their internal libraries or via incentives for their developers to contribute when certain cases are not covered by existing libraries. Also, sponsoring projects that are open to receiving it would be a great way to allow the maintainers to have more focus on their libraries getting better and better. SumUp is a fintech company founded in 2012. Primarily a leader as a payment services provider, it has grown to be a multiproduct company, now offering other financial services, such as digital banking and lending. SumUp tech is all built as cloud-native applications, running mostly in Erlang/Elixir, Ruby and Go. A big thank you to Daniel for sharing his thoughts and experiences of Elixir, the Erlang ecosystem and innovation in fintech, you can connect with him via his LinkedIn profile. If you would like to speak about collaboration around telling the stories of using Elixir or Erlang in fintech, please reach out to Michael Jaiyeola (Erlang Solutions’ Fintech Marketing Lead) by email or on LinkedIn.How they used Elixir to build a fintech backend for SumUp Bank
The future of open-source in fintech and the Elixir community
About SumUp
Pawel Chrząszcz introduces MongooseIM 6.3.0 with Prometheus monitoring and CockroachDB support for greater scalability and flexibility.
Here's how machine learning drives business efficiency, from customer insights to fraud detection, powering smarter, faster decisions.
Phuong Van explores Phoenix LiveView implementation, covering data migration, UI development, and team collaboration from concept to production.