Skip to content
Home » Posts » Part 2: Enabling Instant Payment Participation

Part 2: Enabling Instant Payment Participation

This entry is part 2 of 2 in the series Building WynePay

This is part 2 in a blog series; in the previous blog “Building WynePay to address financial inclusion in Myanmar” we outlined why enabling the participation of financial institutions is important to address financial inclusion. Now we dig deeper into some obstacles encountered when enabling large-scale participation of various sizes and classes of financial institutions, and the corresponding solutions designed to address these obstacles.

In summary, there are risks, technical expertise, and cost barriers that must be overcome to enable broad-based inclusive participation in real-time payments. Making use of open-source Mojaloop as the payment hub, and open-source Payment Manager as the participation support tool combined with an inclusive governance structure, we were able to address these multi-layered and complex problems and overcome these barriers. By the end of this blog, you will better understand the benefits of a Mojaloop implemented Inclusive Instant Payments (IIPS) and the participation tools that support efficient operation, and how this help reduces participation costs and reduces business and technical risks.

If you want to discuss this further we would love to hear about your project; contact a member of our team today.

The problem

Enabling large-scale participation of financial institutions in a real-time payment network has multiple layers of difficulty and complexity. Making it practical and economically feasible for the smaller financial institutions to participate is a challenge when we are aiming for equitable inclusion. They have smaller budgets, less time, a small operations support team, and are less likely to have the required technical and business expertise. These institutions need to overcome barriers in order to participate. Achieving integration can be costly and service integration is an ongoing OPEX commitment which adds additional cost. A technical barrier can exist as building a real-time connection into a backend system requires specialist expertise from multiple disciplines. Managing the technical and business risks is vital to ensure that risks do not become barriers to the opportunities that interoperability unlocks. Additionally, it is important that the solution is kept current with changing trends to ensure that costs stay low and that the solution can evolve with markets. 

Let’s look at how the Mojaloop participation tools solve these challenges.

The solution – Mojaloop and Payment Manager

In the first part of our blog series, we discussed Mojaloop and the Level-one project principles it aligns to that are designed to support financial inclusion.

But for each hub at the center, there are many more financial service institutions needed to connect to make it successfully meet its inclusive objectives. Payment Manager, an open-source tool for financial institutions and fintechs, makes connecting to Mojaloop easier while encapsulating best practices for integration. 

Mojaloop’s Distributed Security Model (DSM)

A central concept in Mojaloop is the Distributed Security Model (DSM). This model puts the security controls in the control of the Participant DFSPs who are most at risk. I.e. empowering those at risk to have control over that risk. This does put the onus of managing the security in the hands of the Participant DFSPs. Some organizations require more tooling and support than others, so a variety of best-practice connectors are supported within the Mojaloop community. Payment Manager is the deployment configuration that provides the most support and thus an important tool for smaller financial institutions.

Payment Manager

The Payment Manager’s security configuration and maintenance are automated. This means that moving from a development box into a production with full security enabled is a seamless experience. Payment Manager additionally provides other functions that are all designed to reduce participation burden. Payment Manager provides:

  1. Visibility for operational support, 
  2. A simplified integration process, 
  3. Eases upgrades enabling continuous improvement and evolution to the changing market needs.

It is through the combination of Mojaloop and Payment Manager that we are able to provide a solution that addresses all the participation barriers.

What benefits does the solution provide?

With this solution, an organization participating in a Mojaloop Scheme can be sure that payments for their clients are painless, flexible, and immediate with transparent costs. Receiving and making payments is a critical but costly part of the business. For example, if the organization provides small loans, then the benefit is a significantly easier and lower cost payment method compared to the manual collection of the loans, and significantly easier and lower in cost compared to building and maintaining bi-lateral integrations with multiple wallet providers. 

The Payment Manager tool reduces the participation burden for financial institutions and fintechs by addressing the barriers. Payment Manager reduces the cost to make these real-time payments by saving time while integrating, operating, deploying, and upgrading. Payment Manager supports the management of risk for participants by using best-practice security tools and storing them appropriately with RBAC access. Payment Manager reduces staff reskilling costs and delays by providing process automation tools.

Hub operators also benefit from the use of Payment Manager by participants. Payment Manager supports quick and responsible participation which frees up hub support staff and enables transaction volume growth while following best practices for managing risk. Additionally, Payment Manager simplifies the hub upgrade process which supports the evolution of the system.

Overcoming the cost barrier

Being inclusive of a variety of financial institutions by definition means that the ecosystem is non-homogeneous with financial institutions differing in both class and size. Providing equitable access to all participants comes with some challenges, one of them being how to create an ecosystem that is cost-effective for small financial institutions. 

Small financial institutions can greatly benefit from connecting to Mojaloop as access to easy, interoperable payments solve a costly problem they may have. Building and maintaining a connection to Mojaloop comes at a cost, and it is important that a cost-benefit analysis determines a positive value proposition. This challenge becomes harder for smaller institutions as they have lower volumes with lower revenue, benefit less, and therefore need to have lower costs.

Let’s dig deeper into the smaller institution costs, and discuss how costs are reduced using Mojaloop and Payment Manager.

  1. Cost to reskill staff
    Mojaloop has a fantastic training program that covers any initial training requirements. These courses are free to take and are enough to provide the necessary background on which further self-study can be based.
  2. Cost of getting connected
    • The choice of using Payment Manager massively reduces the time and effort it takes to build a best-practice integration with the institution’s core banking system. A connection that has previously taken months is now completed in days.
    • A SaaS-hosted solution is commonly chosen to minimize the deployment effort and the technical expertise required.
    • Mojaloop has an efficient liquidity requirement model and this reduces the liquidity cost to connect.
  3. Cost of participating aka maintaining a connection and doing transactions
    By design, Mojaloop addresses the reconciliation and dispute costs and Payment Manager encapsulates those design elements. The use of Interledger allows the Payer and Payee DFSPs to validate in a non-repudiable manner the transfer prior to releasing funds. This reduces the reconciliation and dispute effort because the transfer records each DFPS holds are sufficient to do this independently meaning that most queries are resolved with a single organization.

Overcoming the technical barriers

The Payment Manager with the SaaS-hosted deployment using a standard core integration requires little additional technical expertise within a financial institution’s team while still keeping the integration capability within the administrative boundary of the financial institution thus removing technical barriers.

Overcoming the risk barriers

At INFITX we have demonstrated that it is possible to manage risks when costs are reduced. Defining best practice is an important tool to manage risks.  Best practices can be easy to implement, inexpensive, and secure. Let’s explore that concept more by grouping the risks into categories and explaining how the Mojaloop and Payment Manager together address these risks.

The risks associated with a financial institution participating in an interoperable payment switch can be categorized as reconciliation and dispute, technical security, internal and systemic, or participant-specific risks.

Reconciliation and Dispute Risk

This risk refers to the process where all participant organizations involved in transactions settle funds between them. Disputes in this reconciliation process are a costly business risk that Mojaloop mitigates through design. For more information please refer to the Settlement Management Guide business documentation and the Mojaloop Training Program where the courses describe how this is achieved.

Technical Security Risk

Technical Security Risk is the risk of a cyber-attack or data breach on your organization. Mojaloop manages this risk by moving the burden of security to the financial institution connecting to the scheme. This is empowering and correct but means that participant organizations must own and take control of the security elements of Mojaloop.
The Mojaloop security model is described in detail in our contribution to the Mojaloop Training Program in the Moja104 Course. In summary, Mojaloop uses layered cryptography that together provides the environment to participate safely. 

  1. OAuth with IP whitelisting is used to gain access to the endpoints. 
  2. Mutual TLS encrypted tunneling to ensure that all data sent is secured. 
  3. JWS to cryptographically validate the origin of a message and to ensure that it isn’t tampered with. 
  4. ILP to cryptographically present and then accept the terms of the agreement between parties in a transfer. 
  5. An application-based Idempotency and state control to ensure process integrity is kept. 

Together these form a comprehensive, secure design solution for transactions that meet the non-repudiation requirements of Mojaloop.
Payment Manager is the technical solution that, by making use of automation tools, supports each participant to ensure that the layered technical security solution is implemented easily and follows best practices.

Internal Risks

These are risks that do arise from poor systems or poor performance by employees or lax internal control systems that can lead to fraud or accidents in live production. Managing this risk is largely about how financial institutions are organized, who within that organization can make decisions and the mechanism around making those decisions.
Payment Manager and Mojaloop have a default configured role-based access control to support the financial organization in building the operational controls within the organization to manage this risk. Payment Manager and Mojaloop additionally support the management of this risk by providing activity logs that can be audited.

Systemic or participant-specific risk

This risk is associated with the collapse of an entire financial system or the collapse of a particular participant. There is

  1. Reconciliation Risk 
  2. Liquidity Risk

The Mojaloop real-time payment switch is strong in its response to help manage these risks. Mojaloop is customizable with some optional out-the-box defaults that manage these risks directly. It supports a pre-funded real-time ledger, has a settlement mechanism that settles between parties every day or more frequently with a process that can be automated, uses a reserve commit phased approach for each transfer, and is designed so that similar reserve and commit phases can be implemented when building the participant intersystem integrations.

Standardized onboarding strategy led by local system integrator partners

In order to ensure sustainability in a financial ecosystem, it is important to partner with local system integrators, and it is through this partnership that the current integration process has and continues to evolve. Building standards are an important part of this partnership, as it provides standardized solutions with well-understood risks that can be selected and applied. Standard integration financial flows for specific use cases have evolved, with standard supportive API’s and a standard testing harness design to support the integration commissioning.

The journey ahead

This journey is at the beginning and shows clearly what is possible. As more participants join the initiative, and as more use cases roll out, the system and organizations will continue to evolve into a solution that continues to make a real difference. Operating at scale reduces unit cost, but only with efficient operational tooling that enables the organization to maintain a lean, efficient Operations team. 

Please contact us…

Join the conversation