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

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