By implementing best practices such as Infrastructure-as-Code (IaC), our tools abstract the highly complex, manual processes required of financial institutions (FIs) to connect to fintechs and real-time payment networks. In the US, we work with banks and credit unions to abstract banking core data and connect quickly to fintechs via PortX – the “fintech hub” for financial services. We leverage open source technology and IaC to build solutions such as Payment Manager OSS – reducing the intricacy of onboarding payment networks like Mojaloop and eliminating technical dependencies for banks and microfinance institutions (MFIs) in developing countries. By following this approach, FIs and MFIs can deploy a real-time payment network in a matter of days or weeks whereas complex infrastructure can result in months of testing and retesting. Here, we’ll describe the solution we developed to reduce Mojaloop onboarding time from an 8-week process to only 3 hours.
There is no one-size-fits-all infrastructure in the Mojaloop community
It’s important to distinguish between the different use cases that exist for infrastructure within the Mojaloop community. From the developer who is just checking out Mojaloop to a production-grade national switch, this diversity introduces varying degrees of technical requirements:
For the Developer who wants to kick the tires, there are at least three routes to engage with the platform:
-
- Particularly for future System Integrators (SIs) looking to support onboarding for FIs, we partnered in the community to build the Testing Tool Kit (TTK) which mocks the Mojaloop switch and other participants. Along with Payment Manager OSS, there is a local containerized solution.
- For the Potential Switch Developer whose team needs to experiment with a full development environment, the community supports a mini-loop version.
- Lastly, there is a community sandbox environment for development purposes hosted by the Mojaloop Foundation.
For a Potential Adopter or a Hackathon where there are multiple users or participants wanting to assess a “real world PoC” experience, there is an IaC solution that stands up a dedicated Sandbox. Currently, this is based on AWS, but the application can be configured to work with other cloud providers or support on-prem custom deployments. Recent developments separate the cloud-specific components so community members can easily provide an Azure (see more about Azure later) or GCP bootstrap.
For Production environments, the IaC above provides the basis for a national switch PoC with options that include IaC from Mojaloop or a vendor-specific quick start. For a full Production Grade Switch, we can work with your internal infrastructure team to configure and evolve the IaC to provide production capabilities for fault tolerance, security, and throughput.
Core IaC development principles for building inclusive financial services
The sandbox infrastructure for Mojaloop has evolved over the years. The initial sandbox Mojaloop infrastructure was built on AWS and it remains the default cloud provider of choice for the base architectural layer of the IaC solution. Additionally, we developed the IaC by utilizing components chosen by Mojaloop early adopters.
Over time, we have gradually replaced many of those tools with best-of-breed open source and cloud-native components and adhere to the following core development principles in our architectural approach to ensure that IaC promotes financial inclusion.
Core development principles of the Sandbox IaC:
- Open source and standards-based components
- Cloud provider-agnostic – creates a pluggable way for other cloud providers to leverage the IaC and deliver new solutions to the community
- Fit-for-purpose and sufficient to run Fake Money/Fake Rails PoCs.
- Pluggable architecture to achieve multi-cloud capability
- Support lower resource requirements – multi-cloud, pluggable capability can include bare-metal.
- Eliminate all manual steps (scripts/etc from a CI/CD and IaC execution perspective) to provision switch
- Provide upgrade path for most components
By following these design principles, all of the capabilities within the open source project can be tested without relying on licensed components. Additionally, anyone can use this approach as a starting point for their infrastructure without licensing issues.
Layered architecture of components enables standardization and reuse
Layer one
The IaC environment is a layered terraform of modules. The first layer builds the VMs (cloud provider-specific), and the remainder of the architecture is a mostly cloud-agnostic design. In the sandbox environment, this first layer houses the AWS-specific base infrastructure code (EC2, IAM, NLBs, etc). The next step is to create the Kubernetes cluster using the base infrastructure previously built. We chose to utilize Kubespray to provision Kubernetes, which supports multiple cloud providers.
Layer two
The second layer contains the terraform to deploy the Helm charts providing the base Kubernetes support to the rest of the application layer. The configuration of these components has dependencies on the first layer such as the IAM/Route53/S3/KMS details.
The components in this layer include the following:
- Hashicorp Vault – Secrets management
- Cert Manager / External DNS – Abstract DNS considerations and certificate generation
- Nginx Ingress Controllers
- Storage Providers – PVC provisioning
Layer three
Everything built on top of these two layers is cloud-agnostic – providing components that do not create dependencies on any one cloud provider.
The third IaC layer contains pluggable cloud-agnostic components:
- WSO2 ISKM (moving to keycloak) and API Manager (moving to ambassador/ORY)
- HAProxy – forward proxying requests to DFSP callbacks with configurable MTLS
- Connection Manager
- Mojaloop Finance Portal (leveraging micro front-ends and ORY identity management and access control)
- Loki stack with Prometheus and Grafana
This approach has dramatically reduced the onboarding time through standardization and reuse. Porting to a new cloud provider requires only customizing the first two layers which are specific to that provider.
The results of layered IaC
The early versions of Mojaloop infrastructure took anywhere between six to eight weeks to establish. This required three fully-dedicated resources: an infrastructure engineer, an application engineer, and an API gateway SME. That’s up to 960 man-hours!
Today, thanks to open source tools and IaC, we can build a Mojaloop pre-production lab from scratch, create the infrastructure, deploy the application stack, onboard simulators, and run the health check in a fully-automated process that takes only three hours!
We quickly and affordably connect FIs to real-time payments and fintechs
The Payment Manager OSS solution allows SIs to benefit from standardized security and operational components while building out core connectors that deliver the benefits of Mojaloop participation to their FI customers. These benefits include open-loop interoperability with all classes of institutions, push payments, non-repudiability in the transfer process, and ultimately no reconciliation burden. If you would like to learn more, see how partners like Thitsaworks are creating core connectors and onboarding MFI’s in less than a month.
The IaC solution is an example of how we are accelerating access to Mojaloop for FIs and MFIs. We follow the same approach for banks, credit unions, MFIs, ATM networks, and central banks globally to accelerate access to financial services. If you would like to learn more about how we help all types of financial institutions scale their infrastructure capabilities to participate in real-time payment networks, connect to fintech partners, or create a sub-national or national interoperable network, start a conversation with our team today.
