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

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