Mojaloop Community Central: Kim

Mojaloop PI-21: Daily Wrap-up (Day #3)

Kim — Mon, 13 Mar 2023 10:53:01 +0000

Day #3: Mojaloop PI-21

Links from Today:
• Photos:
o CCHub: https://www.flickr.com/photos/mojaloop/albums/72177720306593574
o Day #1: https://www.flickr.com/photos/mojaloop/albums/72177720306567324
o Day #2: https://www.flickr.com/photos/mojaloop/albums/72177720306582537
• Mojaloop PI-21 Agenda & Presentations: https://mojaloop.io/decks
• Mojaloop Community Central: https://community.mojaloop.io/

Session Details:
• Welcome & Agenda, Paul Makin
o Pillar 3
 Ability to support multiple settlement models
 Interledger and extensions
o Pillar 4
 Core Development and maintenance
 G2P connect – integration
 Vnext progress and path forward
 Mojaloop APIs updates

• Cross Border Strategty
o Steve Haley
o Slide Deck
 Presentation to provde different alternatives and proposals to settlements
o Addressing – Arunjay Katakam, UNCDF
 Imagine if each email you sent had a different pricing structure to it depending on who you were writing to, and that costs go higher the poorer your recipient is.
• Send money to anyone, anywhere just like you can call, message or email
 The directory of Proxy directories will:
• Connect participating Proxy directories
• Return validation of Proxy and the Legal Entity Identifier of recipients PSP
• Work on zero-knowledge proof
 Summary
• Speed up total interoperability
• Allow users to use an easy to remember proxy alias
• Increase adoption of digital payments
o Messaging – Michael Richards, Infitx
 If payments were philosophers
 Problem Statement
• Message definition proceeds from the ground up:
o Message definitions solve local interaction problems…
 …and expand in response to evolving local needs
• But it works from the top down:
o A message definition is a way of formalising payment relationships
o Payment practice must “conform” to message structure
o Which leads to nonconformist adaptations to local needs
• Every message structure is meaningful in a specific payment context.
o Using a message definition means participating in a payment system
o And that means: participating as an individual institution…
 … which can belong to more than one payment system.
 Problem Statement (cont)
• Every message definition exists in a tension between private needs and public conformity
• Adopting the inclusive approach (e.g. ISO 20022) merely displaces the expression of local needs to market practice definitions.
• Adopting the local approach (Nexus) means that financial institutions need to belong to different payment systems, and hence use different messages.
 Approach
• Interconnection between systems, not institutions
• Context extension by translation, not abstraction
• Solve the hierarchical specialisation problem of increasingly abstract definitions by transforming it into a conversion proble
o Settlement – Julie Guetta, Partior
 Problem
• Cross-border payments are still too costly, not transparently enough, too slow and with too limited access, resulting to high fees for the consumers and often lack of customer protection
• Actually the cost of processing cross-border payments is quite high, hence generally the high fees charged being charged to the customers
o The banks need to maintain relationships with other banks
o The banks need to have access to liquidity to settle transactions, which can be very tricky particularly for illiquid currencies
o The banks need to protect themselves against settlement risk
 Approach
• Understand how settlement can be done differently across different jurisdictions
o Option 1: Working on reginal CBDC
o Option 2: Integrating a settlement layer within Mojaloop and test a regional settlement with a pre-funded scheme, leveraging e-payments rails
o Option 3: Accelerate integration with regional projects that include a settlement layer
o Option 4: Investigate how Mojaloop can be used as a bridge between omnibus accounts
• Hypotheses we would like to prove
o Settlement can be done with fewer intermediaries so that the cost and risks are reduced
o Settlement can be done with limited involvement of a settlement bank
o Compliance – Paul Makin, Mojaloop Foundation
 Problem
• Cross Border Transactions are the most challenging in terms of regulatory compliance; technically, it’s easy(ish), if you can get over the question of trust, but regulatory challenges have killed many nascent services
• The FATF Recommendations provide a framework, focussed on AML, CFT, CPF
• With derived recommendations around CDD, transaction monitoring
• Banks have over-reacted to FATF; FATF have rowed back, but too late, and anyway those multi-billion $ fines confirm the banks’ suspicions
 Approach
• Develop a trust framework that extends to NBFIs
• Mojaloop can already manage this from the technical, transactional perspective, but needs to be extended
o Carry evidence of CDD compliance with/derived from the transaction
o To include evidence that the NBFI is itself compliant
 Compliance goes way, way beyond mere CDD compliance; need to develop an understanding of this in the NBFI community, and the financial community needs to provide them with the tools to demonstrate they comply
• Work with regulatory authorities to validate this approach
o Community members, PMs with Compliance Experience NEEDED!!!

• Application of Mojaloop Technology for Cross-Border, Wallet-to-Wallet Remittance: Singapore-Myanmar and Singapore-Philippines Corridors
o Min Tha Gyaw, CSO, ThitsaWorks
o Slide Deck
o Problem
 While many remittance options exist for overseas migrant workers in Singapore, options to reach rural areas, where many of the workers' families live, are complicated, expensive, and slow.
 It is impossible to send money directly to friends and family if they hold accounts at microfinance institutions, rural banks and most wallets.
o Goals
 To connect small financial institutions to real time payment networks to enable fast, convenient, and ubiquitous cross-border remittances.
 To create a replicable, scalable model for regional payment networks that can be taken to other markets, leveraging Singapore’s position as a regional innovation and financial hub.
 To explore opportunities to make remittance cheaper and faster for the Singapore-to-Philippines and Singapore-to-Myanmar corridors.
o Design Principles
 A catalyst for Financial Inclusion
 Design for target end users (rural, low-income residences)
 Speed to Market as a priority
 Replicable and Scalable Blueprint
o Multiple Alias Provider:
 Problem
• Typically, it is assumed that the identifiers used to locate the institution which administers a particular account are unique within a payment system.
• In some cases (for instance, an IBAN in the jurisdictions where they are used) this is a reliable assumption.
• In others (for instance, an MSISDN) it is not reliable.
• Users can belong to more than one mobile money service provider, or different family members might share a handset.
• Thus, the MSISDN does not uniquely identify a mobile money system.
 Solution
• Solving the problem for domestic transfer with Prefix Oracle:
o In a Mojaloop scheme, end user applications already allow the customer to select which Mobile Money System they want to send to.
• The sending party will have no idea which Mobile Money System owns the beneficiary’s account and their application won’t know about the alternative ones which are available.
o Settlement
 Problem
• The Mojaloop platform is only concerned with a single settlement structure.
• In a cross-border remittance, funds will typically arrive from another scheme on a timetable which is not related to the remittee (payee) scheme’s settlement timetable. This is likely to place significant liquidity pressure on the CNP as a settling participant in the remitter (payer) scheme.
• As a result, there is a requirement to distinguish between internal transfers and remittance transfers and settle them according to separate settlement models.
 Solutions (in a POC)
• Use an identifier type which is specific to external transfers (This would enable participants to register their customers separately for the receipt of remittances which would enable the participant to collect appropriate KYC but it would need modifications to the partyIdType)
• Use the subScenario element of the TransactionType object
o Next Steps
 Investigate technical challenges further
 To perform end-to-end testing (in certification environment) with full clearance of remitted funds within the allotted time frame.
 The settlement windows of respective payment schemes may not coincide, potentially resulting in credit risk to one of the settlement banks. Commercial and other risk-mitigation arrangements such as interbank credit lines can be leveraged to resolve these types of issues.
 A stronger focus on regulatory and compliance requirements.

• Mojaloop and ISO 20022
o Michael Richards
o Slide Deck
o What is ISO?
 “A single standardisation approach (methodology, process, repository) to be used by all financial standards initiatives” (ISO 20022 website)
 “ISO 20022 is an open global standard for financial information. It provides consistent, rich and structured data that can be used for every kind of financial business transaction.” (SWIFT)
o What is an ISO Definition?
 A set of dictionary definitions of data objects.
 A set of external codes which can be used in ISO 20022 definitions.
 A two-part Message Definition Report
 A series of message definitions
o Where we are now?
 We prepared a document describing the changes to pacs.008 that we required.
 We shared this document with the Payments SEG and they accepted it.
 An evaluation team has been formed to review the change proposals
o Active membership requires:
 Articulating the requirements of an IIPS in contrast with those of existing IOS 20022 participants.
 Understanding whether technical solutions proposed for the business requirements are well aligned with IIPS requirements (and invariants).
 Making and reviewing proposals.
 If you’re interested in becoming a member go here
o Lighter Touch Alternative
 To provide a forum where community members and interested parties can contribute to discussions in this area without making an intolerable time commitment
 Contact Michael Richards if you are interested: michael.richards@infitx.com
o Address Resolution Summary
 We’re using the ISO messages in a way which was not intended
 There is no bulk version of the ISO messages
 We may still want to extend ISO 20022 to manage directories
• The need to manage address resolution can be taken off the critical path for Mojaloop ISO 20022

• Interledger Update & Remittances with Rafiki and a Mojaloop CNP: a potential use case for The People's Clearinghouse
o Michael Richards, Andres Arauz
o Slide Deck
o Objectives:
 To demonstrate the ability to initiate a payment in a financial institution anywhere on an ILP network which results in a credit to a beneficiary’s account at a financial institution which is a member of a Mojaloop scheme.
 To make it easy for any Mojaloop scheme to add plug-and-play access between participants in the Mojaloop scheme and any financial institution that uses Rafiki
 To enable any financial institution that uses Rafiki to get access to any Rafiki-enabled Mojaloop scheme
o The interledger foundation (ILF)
 ILF is a non-profit, independent, grant-making foundation. We believe financial inclusion is a right, not a privilege, and financial systems should work for everyone, everywhere.
 We make a difference through building an ecosystem that enacts sustainable, systemic change, in financial services.
 We work for the collective good through open standards to enable inclusivity, with a people first approach and global community.
o What is Rafiki?
 An API-based protocol which hides the complexities of ILP-based streaming from participants. It enables:
• Simple Payments (paying a specific amount)
• Recurring Payments (subscriptions and pay-as-you-go)
• App-based Payments (connecting apps to your Interledger wallet, allowing them to make payments)
• Advanced Payments (including streaming payments and other novel use cases)
 It allows payments to be specified and executed en bloc, rather than at the interledger (or packet) level
o POC
 Allow wallets implementing the Rafiki protocol……
• to remit funds to beneficiaries whose accounts are held by participants in a Mojaloop system…
• without the sender needing to know which FI holds the beneficiary’s account…
• and using a pre-defined settlement route
o Real-world solution
 There are approximately 150 rural co-operative banks in Mexico who are members of a union of credit unions
• These rural banks will be participants in a Mojaloop network
 Their customers want to receive remittances from relatives working in the USA.
 There is an existing atomic settlement route between the USA and Mexico
 We want to enable users of mobile wallets in the USA to transfer funds to customers of rural co-operative banks in Mexico.
• Reminder: this is clearing funds. Settling happens elsewhere, though under our management.
 We will use Rafiki to enable any mobile wallet in the USA to connect to the Mojaloop network via a Cross-Network Provider.
 There is no FX conversion

• PCH Presentation
o Slide Deck
o Who are we?
 We’re creating a Clearinghouse based on AMUCSS’ current operating network of 140 community banks (mainly rural SOFINCOS & SOCAPS)
 The Clearinghouse will provide inclusive financial technology to that network, in order to connect it to SPEI and other networks
 And will provide a fast, cheap entry point for remittances to communities
 So that liquidity can become savings and be reinvested in the community.
o The people’s clearing house
 Account remittances and a digital payment ecosystem will provide additional liquidity to community banks, which can then lend more to communities
 Mojaloop Use Cases
• P2P: Towards a digital payment ecosystem
• Cross-border transfers: Towards account remittances
• Bulk transfer: Rural gov wages & social benefits
• 3PPI: App substitution for microbanks
o Demo
 Rafiki for connecting external Wallets to the Scheme using the Interledger Protocol
 A Cross-Network-Provider for calculating USD equivalent in Mexican pesos. This allows the Scheme to work only in pesos
 A Mojaloop Scheme that validates accounts, prepares quotes and executes transfers
 A Mojaloop Payment Manager that translates Mojaloop’s APIs into those of a Community Bank’s Core Banking
 A Core Banking platform created by AMUCSS for its network’s community banks
o Demonstration Transfer via CNP Lite

• CORE Update
o Sam Kummary, Miguel de Barros, David Fry
o Slide Deck
o What is Mojaloop
 Platform, hub and scheme
o Workstream Readout
 Publish Mojaloop v14
 Implement separation of external dependencies
 External passwords in value fields
 Develop RC for v15
o Goals for PI21
 Support for deployment
 Settlement enhancements
 Vnext support
 Bulk transfer updates
 Node LTS upgrade
o Mojaloop Platform
 Core
 3PPI connectors
 API gateway
 Supporting services
 Infrastructure
 Finance portal
 Monitoring support
o TTK updates
 Rule import/export
 Save and list reports
 Redesigned ttk definition report
 Enhancements to break on error
 Markdown support in metadata
o 15.1 Release Notes
o IAC updates

• G2P Connect/MOSIP Integration
o Slide Deck
o Paul Makin
o Objective: demonstrate the ability to send money to the account of someone registered with a MOSIP identity w/out knowing any details of their account
o Progress: Agreement w/ MOSIP, design work complete and move to a POC
o Direct integrations w/ Mifos (DFSPs and Mojaloop)
o The Oracle
 Mojaloop oracle is very flexible
 Try to route to people vs wallets or bank accounts
 MOSIP identifies people and part of G2P connect
o MOSIP is privacy Preserving
 A digital identity service that preserves privacy.

o Status
 Outstanding items – agree how a MOSIP token be represented
• Revised Settlement using Tiger Beetle
o Slide Deck
o Michael Richards, Infitx
o Jason Bruwer, Coil
o Settlement Today
 All transfers are recorded against a single Position account (per participant, per currency).
 The net debit cap for each account type, participant and currency is recorded as a separate entry.
 Only supports multilateral net and continuous gross settlements, but not bilateral net settlement.
 As a transfer completes, it is assigned to the currently open settlement window.
 Settlements are requested by selecting the IDs of the settlement windows to be included.
 Position accounts are updated by the amount of the settlement before the settlement completes.
o New Approach
 Support multiple settlement models and batches.
 All transfers are recorded against the appropriate settlement account (per participant, per currency).
 The net debit cap for each account type, participant and currency is recorded as a balance in the settlement account defined for the settlement model.
 The system supports multilateral deferred settlements and immediate gross settlements.
 As a transfer completes, it is assigned to the correct settlement batch based on its characteristics.
 Settlements are requested by selecting the settlement model and the characteristics of the settlement batches to be included.
 The same method should be used to query the state of settlement batches and request that they be settled, so that administrators can track the progress of a group of batches as well as settling them when they are complete.
 For deferred net settlements, position accounts and settlement accounts are updated by the amount of the settlement when the settlement completes.
 For immediate gross settlements, transfers are journaled across from the position account to the settlement account as they complete.
o

o PI-21 Goals
 Implement for vNext
 Implement for Central-Ledger
 Refine requirements
 Define tests cases
• Vnext
o Pedro Barreto; Elijah Okello, Jason Bruwer, Michael Richards, Rui Rocha, Josie Antunes
o Slide Decks
o Path to POC
o Scaling and Performance
 Provided the baselines and targets
o Reference Architecture
 Set of documents that captures the essence of the product and provides guidance to the implementation of its future versions
o Goals of reference architecture
 Cleaner and smaller codebases, less dependencies
 Easier to contribute and extend
 Easier to test, deploy and operate
 Secure, performant at scale and cost effective
 Mojaloop marketplace
o What is Vnext
 Different arch, built in parallel
 Same feature set
 When released we will have a standard upgrade mechanisms for SI’s and others
o Demo
 FSPIOP API, Account lookup, participants, accounts and balances
 Quotes, Transfers & Settlements
 Hub operator using central ledger
 20 microservices
o Roadmap
 Q2 2023 Alpha release
 End of June – any developer has the ability of trying vnext
o Workshops – starting March 23rd 12GMT (agile/sprint) – Paul M will be sending out the invite

• Majoloop API Update
o Sam Kummary, Henrik Karlsson, Migel de Barros, Michael Richardson, Julie Guetta
o Slide Deck
o Current CCB
 Henrick Karlsson
 JJ Geewax (rotating out)
 Julie Guetta
 Michael Richards
 Migel de Barros
 Sam Kummary
o API Versions
 1. FSP Interoperability (FSPIOP) API v1.1.1
• Changes to support notifications on failures,
 2. Settlement API v2.0
• No changes approved but proposed and being reviewed
 3. Administration API v1.0
• No changes approved but proposed and being reviewed
 4. Third-party Payment Initiation (3PPI) API v1.0
• 1.0 officially published and supported in implementation. v2.0 being finalized
 5. FX API - in design
• Mostly accepted; finalizing changes, reviews, PoC

Mojaloop PI-21: Daily Wrap-up (Day #2)

Kim — Thu, 09 Mar 2023 08:23:13 +0000

Day #2: Mojaloop PI-21

Links from Today:
• Mojaloop Azure Marketplace Deployment Steps: https://github.com/mojaloop/documentation-artifacts/blob/master/presentations/pi_21_march_2023/presentations/Mojaloop%20Azure%20Deployment.pdf (Every community member should try this)
• Registration process for Typology Database: https://github.com/mojaloop/documentation-artifacts/blob/master/presentations/pi_21_march_2023/presentations/how_to_register.pdf
• Mojaloop Community Central: https://community.mojaloop.io/
• Mojaloop PI-21 Agenda & Presentations: https://mojaloop.io/decks

Session Details:
• Welcome & Agenda, Paul Makin
o ROADMAP: https://docs.mojaloop.io/community/mojaloop-roadmap.html
 Adoption: Make it easier to deploy Mojaloop
 Scale: Make sure deployments have every opportunity to make themselves profitable
 Connection: to other payments services in the ecosystem
 Quality: Continuous development of a quality product.
o Today is about Piller #1: Making Adoption Easier

• Community Updates, Simeon
o Slide Deck
o Objectives
 Community dimensions and strategy
 Community Council Practical Responsibility
 Growth of OSS contributors
o Open Source culture
 Code moves us forward
 “Instead of debating for days whether a new idea is possible or what the best way to build something is, developers would rather just prototype something and see what works”.
o Mojaloop Speaker Bureau
 A group of people in our community who are approved by the Mojaloop Foundation to speak about Mojaloop at various conferences and events around the world.
 Annual application – 18-months, vetted by the executive director
 Applications open next week
o Mojaloop Community Central
 https://community.mojaloop.io/

• Piller #1: Make Adoption Easier
o Jane Stroucken, Infitx
o Slide Deck
o Workstream Objectives: Development of an outline with important milestones for the deployment of a new national or subnational payments Hub based on Mojaloop.
o TOOLS:
 Governance model for Schemes by Paul Makin - https://docs.google.com/presentation/d/1j9Gu0zinxPJLya7QrCV3_hrMDdb7Ib7BLhSZ1Yd8Rjo/edit?usp=share_link
 Mojaloop Training Program - https://mojaloop.io/mojaloop-training-program/
 INFITX Journey - THE SCHEME MVP GOALS JOURNEY https://infitx.com/capacity-building/supporting-an-inclusive-instant-payment-system-build/
 Mojaloop Lab – TBD
o Path to POC
 Define key stakeholders
 Define POC governance
 Define learning objectives for all stakeholders
• What do they need to know to support a decision?
• What do they need to know to assess value?
• What do they need to know to assess cost?
o Potential Learning Objectives
 Can banks and non-banks easily connect?
 What is the impact of non-bank operations?
 How does security work?
 How are settlement windows opens and closed?
 How are settlement instructions sent to the central bank?
 How quickly can a local system integrator learn to maintain Mojaloop?

• Fraud Risk Management System (FRMS) Update
o Greg McCormick, Johannes Foley, Justus Ortlepp
o Slide Deck
o FRMS Center of Excellence
 Mission: is to produce, software, systems, and education in order to counteract the lack of trust in digital payment systems and advocate for their widespread adoption and any needed changes to policies, regulations and laws by advocating for such with governments and the appropriate regulators.
o ACTIO System Capabiliites:
 Transaction monitoring is performed in real-time
 Designed with fledgling anti-fraud operations in mind, transactions are evaluated by a variety or rule processors that organizes detected behaviour into typologies
 Designed with fledgling anti-fraud operations in mind, transactions are evaluated by a variety or rule processors that organizes detected behaviour into typologies
 Interaction with Actio is via RESTful APIs
o ACTIO Demonstration
 The interior functions of the platform are not visible through a traditional user interface.
 When implemented, your transaction platform will route transaction messages to the ACTIO API in real-time.
 ACTIO will evaluate each transaction according to its configured rules and typologies and deliver an assessment of any fraudulent behaviour detected in the transaction.
 The outcome of an evaluation will be communicated to the Transaction Platform and also to your in-house case management system for investigation.
o Typologies IN Actio
 30 typologies are pre-configured in the ACTIO platform
 35 rules have been implemented in the ACTIO platform
o Participate/Get involed:
 If you would like to participate in the ACTIO field-test and have access to your own sandbox instance of ACTIO, or if you would just like to join our community, send an email to actio@frms.io

• Azure and Market Place Deployment Update
o Jason Gregory, Tom Daly, Kim Walters
o Slide Deck (Microsoft) & Azure Deployment
o Multiple Deployment Options:
 Manual Using Docs
 Mini-loop
 IaC
 Mojaloop on Azure Marketplace (Azure AKS native)
 Azure Stack Hub
o Progress by the end of the PI
 Update Azure Marketplace to deploy Mojaloop v15.
 Add Azure deployment to Mojaloop getting started docs
 OpenSource existing Mojaloop work : helm charts / ARM templates etc
 Stretch : Simplify deployment on Azure Stack HUB
o Rwanda Training
 Demonstrated deploying Mojaloop onto Azure native
• Emphasis was on just how easy it is.
• Pointed out where to save money (api mgmt SLA etc)
 Showed Mojaloop running on Azure stack hub: On stack hub in Liquid Telecom DC in Kigali !
• Emphasis was on data soverignty and security also familiarity of Azure native and Azure stack hub.
• Incredible the way Jason and Mark (Microsoft) made this happen : < 24 hrs earlier I was saying too hard, not enough time. BUT they got me everything needed, access, all sorts of help and in <6 hrs we got it done.
o Mojaloop Azure Deployment Steps: https://github.com/mojaloop/documentation-artifacts/blob/master/presentations/pi_21_march_2023/presentations/Mojaloop%20Azure%20Deployment.pdf

• Fintech Sandbox Update
o Sam Kummary
o Slide Deck
o FRMS slack link - https://join.slack.com/t/frmscoe/shared_invite/zt-1qw18ap4h-ubZSxJuzseHwO6fPFiC08Q
o Objectives
 1. Deploy a Mojaloop sandbox v14.1.0 (or greater) using IaC (access approved by MLF)
 2. Strategy for connectivity to fintechs, MLF product users and hackathon participants
 3. Onboard at least one fintech for a PoC demonstration
 4. Maintenance of the sandbox for refreshing versions, upgrades
o Progress
 1. Mojaloop sandbox with v14.1.0 deployed using IaC
 2. Access approved / requested to two SI/s fintechs by ML Foundation and provided
 3. Onboarded fintech(s) to the Fintech Sandbox
 4. Maintenance of the sandbox for refreshing versions, upgrades
o Goals
 1. Accessibility of sandbox (self-service portals if feasible or another scalable model)
 2. Refresh sandbox with latest Mojaloop release (v15.0.0)
 3. Cost optimizations (scripts to spin-up, shut-down as needed and narrow down footprint;
 define scenarios to have smaller footprint for low usage scenarios)
 4. Document capabilities of tools in the Mojaloop ecosystem (IaC, Miniloop, ML Toolkit).

• Merchant Payments
o Paul Baker
o Slide Deck
o Objectives: Develop process flows and epics for the merchant registration portion of merchant payments. To include mechanisms to support tiered KYB/KYC and merchant registration/acquiring by DFSPs.
o This is a critical workstream and as noted one of the most important USE case. –
 WE NEED COMMUNITY VOLUNTEERS
 Strong, committed devs who want to make merchant payments (QR, USSD, merchant initiated, customer initiated, RTP, PISP etc) a reality for multiple deployments
 This will become a high priority need overnight, one night soon, and we need to be ready
 Strong support from the Mojaloop product team is available; Product Council will provide guidance

• Journey to Contribution (TTK as a support tool)
o Paul Baker, Elijah Okello, Sam Kummary
o Slide Deck
o Toolkit (TTK)
 Connecting systems & Building PoCs
• Exploring; Simulating; Demonstrating APIs & (new) use-cases
 Development against an API
• OpenAPI definition validation; mocking & monitoring
 Start with working test case; develop component to replace API calls
• Validating APIs
o Mojaloop TTK Wider adoption
 APIs are where the digital public goods projects meet.
 Need to demonstrate interoperability between the systems.
 Having a combined and shared understanding is useful
 Open API definitions
 Sequence diagrams
o Survey feedback link
o Future Options:
 Hub mode state stores
 Explicit test configuration
 Asserts
 Test Report delivery/storage
 Tying mock rules to tests by using open tracing standards.
 Puggable micro-front end demonstration UI
 OR More feature enhancements

• Bulk Payments
o Paul Baker
o Slide Deck
o Objective: Payment Management support for bulk enhancements IAC
 Payments mgr helm using latest SDK
 IAC deploys payments mgr
 Bulk deployments tests have been added to IAC
o Support new uses cases
 Salary payments
 Social disbursements
o DEMO: https://drive.google.com/file/d/1PYuDUNOyr62XLgduTEZGFqcYDQOU5IrL/view?usp=share_link
o Future enhancements (HUB)
 Enable reserve commit integrations
 Bulk discovery
 Performance of switch
 PISP bulk
 Transfer Dashboard

• Technical Updates and Contribution to Mojaloop Community
o Aung Thaw Aye (CTO, ThitsaWorks)
o Slide Deck
 About ThitsaWorks
• Digitize
• Payments
• Insight
• Access
 Journey
• Microfinance use cases
• Cross border remittance
• Digitization agriculture payments and lending
• Merchant interoperability
 Products and Technology Solutions
• Hub operations – Waynepay
• Cross border remittance
• Wallet interoperability
• Future enhancements
 Learnings
• Tons of success along the way
• Still costly to run (low transactions & expensive infrastructure)
o Adoption to increase/Costs need to be reduced
 Mojaloop ENGINE can be used to build different things
• YOUR clients will be the best source of insight for what to build
 Building an environment:
• Internet Connectivity can be limited
• Power / Electricity can be inconsistent
• Not all end users will have smart phones – and many users will share one

• Not all DFSPs are adequately digitized (i.e. core banking, API capabilities, etc.)
• Internal capacity of DFSPs can be constrained
• Regulatory reporting requirements can be extensive (and multiple regulators)
• Infrastructure preference of DFSPs (or that of regulators) can varies (lack of standardization)
 Deployment: Moving to Managed Services
• Reporting Requirements (Regulatory and MIS) – Heavy
• DFSP Portal (Real-time Settlement Transparency)
• Performance / Stability of Hub
• Data Analytics (Predictive)
• FRMS (Fraud Risk Management System)
• Redundancy / Disaster Recovery (DR – regulatory requirement in some areas)

• Cy Lab
o Andrew Musoke
o Slide Deck
o Motivation for the evaluation
 Rate of financial inclusion is hindered when financial providers operate in silos.
 Mojaloop is an open source reference model for payment interoperability
 How easy and secure-by-default is the deployment by a non-expert adopter?
o Deployment and Security
 Multi-environment deployments and upgrades.
 Documented experience and recommendations
 Community engagements.
 Security tests with VAPT team
 Developing use-cases
o Experiences
 All components tested are open source and open standards.
 API documentation was not centralized.
 Simulator invaluable for sanity checks and practical understanding of the flow.
 Helm deployment needed tweaking out-of-the-box.
 Separate networking from the helm chart. Allow flexibility in ingress type.
 Need for infrastructure automation scripts for bootstrapping.
 Logging and monitoring tools out-of-the-box were comprehensive.
 Encourage community to share unique deployment experiences
 Need security best practices and recommendations for deployment.
 One week with helm charts version v13.0.2. Vs few hours with mini loop v4.1.
o MojaShop
 A mobile app that utilizes Mojaloop will be implemented to facilitate cafeteria payments in CMU-Africa

Mojaloop PI-21 Daily Wrap-up (Day #1)

Kim — Wed, 08 Mar 2023 08:31:27 +0000

Welcome to Day #1 of the Mojaloop PI-21 Community event in Kigali, Rwanda and online

As a reminder, wear your Mojaloop t-shirt, and we will do a group photo immediately after the last session tomorrow.

Important Links:
• Mojaloop Presentations: https://mojaloop.io/decks
• Documentation: http://mojaloop.io/documentation
• Slack: https://join.slack.com/t/mojaloop/shared_invite/zt-1qy6f3fs0-xYfqfIHJ6zFfNXb0XRpiHw
• Mojaloop Code (Github): https://github.com/mojaloop

Session Details:
• Introduction to Level One Principles
o Matt Bohan, Gates Foundation
o Slide Deck
o Level One Project Goal
 Low Price to Users – positively impact the lives of poor people
 Low Cost - useful
 Safe - Inclusive
 Used – Ubiquitous
o Mojaloop Goals
 We want payments to reach everyone
 We believe that RTRPS are the lowest cost way to make that happen
 We believe that our L1P principles help drive the lowest cost
 Advance the industry
• Similar features, capabilities and rules
• Connections between implementations
• Serve the needs of the people, and of businesses
 Experience from the markets and your broad base of implementations and prospects
 Sharing information
 Security and fraud management
• Gender research
• Ecosystem development

• Welcome
o Paula Hunter, Executive Director Mojaloop Foundation
o Slide Deck
 Mission: Increase financial inclusion by empowering organizations creating interoperable payments systems to enable digital financial services for all.
 600+ community members, in 47 countries
 The Mojaloop Foundation, with the funding and support of our sponsors will continue to advance the features and capabilities of the platform and support the community committed to our mission.
 The Team
• Simeon Oriko, Director of Community
• Steve Haley, Market Development and Partnerships
• Desire Kachenji, Manager of Grants and Partnerships
• Paul Makin, Product Management
• Megan Cannon, Community Operations
 Top Priorities
• Deployment Success
• Product Alignment to Market Requirements
• Continued Growth in our Community
 Steve Haley, Mojaloop Roadmap: https://docs.mojaloop.io/community/mojaloop-roadmap.html
• Make it easier to deploy Mojaloop
• Make sure deployments have every opportunity to make themselves profitable
• Connect to other payments services in the ecosystem
• These three pillars are underpinned by a fourth workstream, that of continuous development of a quality product.
o Robert Ochola, CEO of AfricaNenda
 Highlight work done at the CCHub
 Bootcamp on the Mojaloop Open Source Software for Fintech Companies and Open Source Developers
• 1. Fintech companies based in Kigali
• 2. Open-Source enthusiasts and developers based in Kigali
• 3. ccHub community members
 15 Mojaloop Deployments Completed
 Empower the next generation of SI’s and engineers in Rwanda

• Word from RISA - Innocent Muhizi
o Importance of Payments in Rwanda
o Open Source opportunity
o Power of merchants/payments
 Innovation
 Data insights
 Analyze trends for policy makers
o Cross-border
 Enable of cross-border payments is significant and Mojaloop can enable this
 Addressing the inhibitors and addressing solutions
o Encourage everyone to participate and be willing to fail and learn

• Tanzanian Instant Payment System: A discussion with the Bank of Tanzania delivery team on the journey to build TIPS
o Jane Stroucken, Infitx
 Innocent Ephraim, FSDT
 Mutashobya Mushumbusi (Muta), Bank of Tanzania (BoT)
 Elibariki A. Sekajingo (Eli), Bank of Tanzania (BoT)
o Can you go back to the beginning and reflect on the problems that necessitated the introduction of TIPS? What are the steps that you had on this journey?
 Muta: There was challenges in banking: It was taking too long for services, it was costly for users and there was integration challenges
 Muta: We took the time to understand the needs of Tanzania and determine approaches. Created a roadmap of where we were and where we wanted to reach.
o Can you share the different challenges that you faced during the implementation that may have been prevented had you done things differently? How different?
 Eli: One of the challenges was the onboarding of participants took longer than planned (have over 45 banks).

 Challenge for some to adopt and understand the flow and ensure this was planned for and budget for
 General adoption required to win their goodwill, working with regulators was a challenge as we struggled to build something for everyone
 As the implementor timelines are not accurate as there is a longer process for bringing people along; understanding the benefit of the process is sometimes harder for the receipts as they are focused on the end goal
o TIPS is considered one of the first national implementations of RTP, how would other countries have first-hand experience/learning from TIPS implementation?(Muta)
 Muta: TIPs and BoT are open to sharing our experiences; We will be here for the entire week to share our experiences and learn about how we can help support and partnership; We plan to document our journey so others can learn more about instant payments and avoid some mistakes.

• Building the Perfect Pilot – panelist discussion
o Steve Haley, Mojaloop Foundation
 Himi Deen Toure, Prime Minister Office Prime Minister - Guinea
 Afazad Kalisa, PMO RSwitch Ltd
 Nyi Aye, CEO ThitsaWorks Solutions Myanmar Co., Ltd.
 John Muthoria
o Pilot and POCs: How do we cut down the time for pilots to learn what we need to and move to the next phase:
 Nyi: POC vs Pilot. POC is internal – Pilot is when we expanded beyond our company and involved and testing with real live money with selective users.
 Himi: Financial Shared services – there are 20 banks with 180 services, 25 MFIS, 5 operators for 14 milion people – with different stakeholders, it is not easy to align them on the same goals. Starting the pilot we had discussions with the prime minister to get them involved. 2) they had conversations to set the goals for the POC, we learned from AfricanNenda
 Afazad: POC is a HOW we will implement change or an idea to prove this out. Once you move to pilot and is working within a period of time, you can move it out further. The pilot for us was 2 years. The pilot is a monitoring phase.
 Steve: POC as technical testing, Pilot is in a production environment for financial institutions
o What are we trying to learn:
 Niyi: The need for instant payments is very real but there is a greater need for interopablity. Microfinance loans and support for vendors was needed in the begging
 Himi: We have 25 microfinances in Guinea and many don’t have a core bank systems.

 Afazad: once there are multiple stakeholders involved and they get alignment we can discuss interopability and its meaning – but we typicaly have different opinions on how to implement it.
 John: Relationship between DFSP and the vendor – you need to first convince the DFSP that this implementation is critical – so they can then discuss and convince their vendors.
o What are some of the challenges of integrating different levels of DFSPs
 Niyi: Created several levels of advisory – all the organizations signed a commitment and we ha regular meetings with them. The core group we ensured they became part of the journey
o What involvement does the central bank have in the POC? How much real testing should happen at the POC level?
 Himi: In Guinea, financial inclusion is challenging. For our POC we aligned different stakeholders and we established a steering committee to ensure involvement at the highest level. At this stage we did not include everyone and we only picked 8 partners: 2 banks, 2 MFIs, 2 Mobile, etc so show quick wins first. We start slow with partners and then built out a national system
 Afazad: Discussed the importance of scheme rules that gov’t the actions, ensure security, Understanding the advantages of the central bank. The team looked at the opportunities and helped to enure the goals for stakeholders and participants. The end user is the most important player and show them what they are gaining from this (cost, time, convenience)

• Mojaloop Accelerator Program Progress and SI’s Contribution
o Desire Kachenje, Mojaloop Foundation
o Murakoze Wallet
o Slide Deck
 Alain Kajangwe, WiredIn LTD
 What is Murakoze
• A customer experience rating & feedback platform
• A service Queue Management System
 Why a Wallet?
• Moving away from Cash/SIM
• To hide Payer account information from Payee
• Ability to pay from my different wallets and accounts
 Implementation Plan/details
• Wallet to airtel money, and others
• RTP-based solution
• 3rd Party payment initiated
• Leveraged the Mojaloop Payments Flow
 Demo: Blandine Kaneza
• Provided demo on how they implemented code
• Knowledge on Mojaloop and contributed back to Open Source
• Made some major improvements to the code on payments manager an the hub portal
 Challenges
• Limited UI customizations options, this is on some of the options like. Requires a lot of effort to make user interface changes that should normally be given in environment configurations of application configurations.
• Not so clear mapping between fspids and they are actual generic names. We would like to be able to have fspid but able to be mapped to a human readable FSP name like MTN, Bank of Kigali and so on.
• APIs are not very well documented. Sometimes we would struggle to understand what the actual fields mean and that wouldn't necessarily be explicitly called out in API documentations (Swaggers).
• Hard for us to understand fees structure in Mojaloop. Fun fact (We still don’t know the difference between payeeFspFee & payeeFspCommission)
o Orion Systems Update
 Jean Claude Karasira, PADEBO Consulting LTD
 Slide Deck
 Attended the accelerator program
 Do deployment of mini-loop, payments manager
 Developed the Payments manager core connectors and setup an Account
• Account Lookup
• Quoting service
• P2P transfer
 Continue with bulk services, and merchant payments

• Interoperability Case Study (Rwanda & Kenya)
o Michael Mbuthia
o Slide Deck and Video
o Discussed plans on how they did this
 Answering the why
o Kenya
 Interoperability Journey
• 90% payments are still in cash
• 10% payments using cashless systems
 Value Proposition
• Innovation
• Efficiency and Cost
• Customer Value
• Risk Mgmt
• Financial Inclusion
 PesaLink: numbers after the launch
• The product morphed into S witch
• Available to any licensed DFSP in the country. This includes banks and licensed non-banks
o Rwanda
 Challenge: Currently if you are an MTN Mobile money subscriber you are unable to pay an Airtel Money subscriber
 Blue-print: Centralized National Switch, available to any licensed DFSP in the country. This includes banks and licensed non-banks.
• Aligned to Level One Principles
 Developed Use Cases – and building the merchant payments on the Mojaloop System
 6 months for eKash
• 1.3 million users registered
• 146% monthly growth
• 1.1 million transactions
o Recap: Key elements for Successful IIPS
 Why: what is the gap in the market?
 Governance Model: A clear and fair governance model to balance cooperation with competition among participants
 Economic Model: An economic model that incentivizes all stakeholders
 Operational Model: An operational model that safely and reliably connects participants:
• Sustainable
• low cost
• “Low to acquire, deploy and operate”

• Setting Up an operations Team
o Pyae Phyo Lwin, ThitsaWorks
o Slide Deck
o Mojaloop Deployment and DFSP Onboarding experience in Myanmar (Hub Operator’s perspective)
 Team Setup: Setting up organization structure, job scope, recruitment, training and ensuring resources
 Readiness for Onboarding: learn API, scheme rules, define testing, workflow and develop onboard checklist, create test plan
 Readiness For Settlement: Make agreement of settlement steps between hub operator and settlement bank, Define the Net Debit Cap, scheduled settlement time, Develop SOP for daily settlement process, report specificiation and finance portal
 Customer Service: Create service desk portal, Define general issue types to add in portal, Prepare service desk user guideline, support workflow, Develop SOP for customer service process
o Experience of Onboarding DFSPs
 Onboarding steps: discussion w/ DFSPs, Testing, Feasibility checks, integration specs, conduct testing (end-to-end testing critical)
 Challenges
• MFI (3 to 6 months)
o Phone number standard format in MFI backend system

o Repetitive tasks like credentials and payment type creation when the restore process in MFI’s core banking system
o Re-communicate with MFI for Incorrect payment type configuration (Payment type deletion (or) renaming in MFI’s core banking system)
• Wallet (1 to 6 months)
o Lack of Amount reserved feature (2-phase commit) – causes frequent refund process
o Communication challenge on requesting repetitive tasks regarding the changes in MFI logos and names

• Common
o Require proper guidance on clear understanding of DFSP’s API documentation
o Lesson Learned from Friendly User Testing (1.0 & 2.0)
 Insufficient liquidity of DFSPs
 Insufficient balance error (Wallet has limited minimum balance of 1000Ks in the client’s wallet)
 Amount edition in Wallet
 Certificate expiration
 Wallet 5-minute business rule
 API issue
 PVC issue related to TechOps
 Credentials permission
 Core Banking System EOD/EOM process
 Connection issue
 Incorrect Payment Type configuration
 Incorrect Core Connector configuration
 Issue related with wallet update version

• Finding Harmony: Establishing Interoperable Standards for Payments amongst DPIs for G2P and Social Protection
o Slide Deck
o Ed Cable - (Mifos Initiative)
 Karim Jindani - (Paysys Labs)
 Wes Brown (DIAL)
 Vijay Mauree (ITU)
 Vijay Vujjini (Co-Develop Fund)
o Goals
 Visions for Standards and Interoperability & the Status in Harmonizing Them
• Be aware and informed of these ongoing efforts, how they're being aligned, and their latest progress.
 Payments Building Block - Closer Look at One Standard & the Role of DPGs & DPIs
• Understand the APIs being defined for the Pay-BB standard, and considerations that were made in the design of the API and how DPGs/DPIs are instantiating that standard.
 Looking to the Future - Practical ways DPGs/DPIs can interact with the standards
and collaborate effectively
• Discover what's next and the impact these standards will have on catalyzing adoption and fueling collaboration.
o G2P Connect: Mission of this effort
 A technology architecture blueprint with a plug-and-play architecture (allowing for choice of components) with built in privacy & security
 A set of integration specifications to ensure interoperability across the systems supporting G2P delivery
 An integration sandbox to support the development of solutions adhering to the blueprint and specifications
o GovStack
 Multi-stakeholder, community driven initiative, focused on accelerating national digital transformation worldwide, and drawing expertise from contributors across the private sector, civic society and governments all over the world.
 What is GovStack: deliver reusable digital services at scale with a greater return on investment.
o Payments BB
 Vision for payments building block
 Provides an architecture and functional specifications for implementing G2P and P2G payments
 Leverages digital public goods
 Based on open source software
 Provides a standard set of Open APIs for implementing G2P and P2G payments
o Context
 The GovStack initiative is seeking to implement a demonstration/Proof-of-Concept (PoC) of the “Payments” Building Block (PAY-BB) as part of its Sandbox environment.
 The Payments Building Block consists of components that enable multiple government payments use cases in a generic manner.
 The actual use cases include Government to Person (G2P) and Person to Government (P2G).
 The payments BB cover components that can be used to deliver the key functionalities and to connect to existing systems in the market, but does not contemplate building a new payments scheme
o Future
 Implementing Standards
• What role do DPGs play in instantiating them? How is that occurring right now? How can DPGs practically get involved?
 Collaboration
• How will these standards enable better collaboration? Any good examples that you've seen to date?
 Vendor Ecosystem
• How are you addressing the challenges to adoption, maintainability and sustainability of projects and solutions?
 Adoption & Country Engagement
• How will your efforts scale adoption? How are governments and multilaterals involved? How do we drive proper stewardship & contribution from governments?
 Sustainability
• What risks/challenges come from increased interest? How are you ensuring your efforts translates into ensuring health, vitaliy, maintainability of DPGs and not just more standards to adhere to?
• Wrap-up
o Steve Haley – business day wrap-up
 Understanding lessons learned
 Importance and learnings from POCs and pilots
 Reduce the cost and the barrier to participation.
 Importance of merchant payments
o Simeon
 Workstream report-outs/updates