ASEAN Payments

interoperability Study
Project Update

30th Sep 2022

A QUICK RECAP

1. ASEAN wants to create cross border payments interoperability- member countries have entered into bi-lateral
arrangements for cross border connectivity of their Instant Payment Systems. However, there is a need for a
multilateral platform to allow ALL ASEAN member countries to be connected.
2. BISIH’ Project Nexus seeks to provide a multilateral platform for countries which already has Instant
Payment Systems - ASEAN is keen to be the pilot region to adopt Nexus, upon the successful completion of its
CONTEXT Proof of Concept stage.
3. For ASEAN countries with no IPS, there is however a need to validate an alternative/parallel solution and
determine if it can interoperate with Nexus
4. For that we are conducting technical feasibility study with Mojaloop. Mojaloop is a non-profit open-source
platform by Bill & Melinda Gates Foundation that serves as a reference model for creating cost effective
interoperable payments platforms

1. Validate that Mojaloop can be a possible option for the countries with no IPS in place
2. Validate that for IPS-ready countries which decided on Nexus as their platform, that Nexus can be connected to

OBJECTIVES Mojaloop and vice versa

3. Define a roadmap for implementation which will include options for all ten member countries connectivity

© Oliver Wyman 2
NEXUS POC WILL CONCLUDE IN LATE 2022; MOJALOOP HAS BEEN LIVE IN A FEW
MARKETS

Nexus is a service that connects domestic instant payment systems Mojaloop is an open source software for Instant Payments Clearing built
(IPSs) to enable individuals and businesses to make cross-border payments specifically to help central banks and hub operators drive financial inclusion by
that reach their destination in 60 seconds or less. lowering costs for IPS and increase flexibility by removing dependencies on
ABOUT US foreign software vendors

A proof of concept among the following countries has proven the concept Began as a PoC in 2017, now a hardened system supported by a well funded
is technically feasible foundation supported by Google, Rockefeller Foundation, UN and the Bill and Melinda
- Singapore, Gates Foundation with a network of system integrators and community of over 700
- Malaysia and o TIPS – Bank of Tanzania national payment system built entirely in-house using
Where are - Eurozone
Mojaloop
they in the The PoC will conclude late 2022 and will deliver a technical standard, a draft
o Mowali – West Africa joint venture of Orange and MTN to bring wallet
interoperability to over 20 countries and 150 million wallets
journey payment scheme, and working software (although further work would be required
before it is ready for live payments). o R-NDPS - Rwandan government has begun a project to upgrade existing P2P
switch to Mojaloop for merchant and PISP use cases.

o Country has an established domestic IPS o Financial institutions with basic core banking solutions and consumer
applications
o IPS has a robust risk management framework that eliminates credit
risk between financial institutions during the settlement cycle (eg o Basic central bank settlement functions, preferably at least once per day
Mandatory prefunding, collateral or immediate settlement in central bank money)
o Hub operator regulated to operate instant clearing and settlement
Criteria o Banks and PSPs adhere to the Nexus scheme and are able to
comply with sanctions screening requirements

© Oliver Wyman Source: Discussion with BISIH team and Mojaloop 3

IPS READY COUNTRIES CAN CONNECT DIRECTLY WITH NEXUS & OTHERS CAN LEVERAGE
MOJALOOP TO BECOME DOMESTIC IPS-READY

1. Central Bank 2. Messaging 3. Current Cross-border 4. FUTURE PLANS - Cross-

Domestic IPS PROTOCOL Payments Border payments
Vietnam NAPAS 247
(NAPAS is the Hub Operator.
•
•
ISO 8583
ISO 20022
Fund Transfer
• PayNet (Malaysia)
The SBV is the biggest • NITMX (TH) Potential option to
shareholder of NAPAS) NAPAS already have solution to • LaosVietBank (Laos)
interoperate between ISO8583 directly connect with
QR Payment
and 20022 format
• Thailand
Nexus
Deep-dive needs to be
conducted to understand if
Cambodia BAKONG (Shared Wallet) +
They need to build a switch for
ISO 20022 NBC have assigned sponsoring
bank (ACLEDA) to support cross-
Bilateral connection with
• IPS has a robust risk
• Thailand – Prompt Pay
management framework
cross-border payments border switching and settlement • Vietnam – Napas • Banks and PSPs adhere to
to communicate with • Laos – LampNet the Nexus scheme
counterparts

Brunei None None None • Going though technology

selection process
• In process of creating hub with
3 local banks

Myanmar None None None Central Bank issued RFP for

RTP system in 2020 but has not Potential option to
gone forward
have Mojaloop as
Pending Validation
domestic IPS
Laos
Pending Information (assuming Laos in not IPS ready)

© Oliver Wyman The other 5 countries already have plans to connect to Nexus (SG, MY, ID, PH, TH). 4
THERE ARE TWO POTENTIAL OPTIONS TO MAKE COUNTRIES IPS READY WITH MOJALOOP

1 2
Mojaloop as a Domestic IPS Mojaloop as a Central Hub

What it is What it is
Domestic
Brunei Mojaloop IPS • A separate domestic IPS, enabled by Brunei • A central, multi-tenanted hub with common
Mojaloop, for each country. scheme, allowing countries to transition to their
own national instance (if needed)
Mojaloop
LAOS
Domestic
Mojaloop IPS
How it works Central LAOS How it works
Hub
• Each country will have its own scheme locally • The central hub will be located in a business
operated by a hub operator. safe jurisdiction with strong data protection and
governance mechanisms in place
Domestic • Connections between schemes (interoperability)
Myanmar Mojaloop IPS will be implemented via Nexus Myanmar • Interoperability across these countries will be
implemented via Mojaloop

Mojaloop Case Study: Mojaloop Case Study:

Bank of Tanzania and its implementation of a domestic IPS Mowali and its implementation of the central hub*

Bank of Tanzania is implementing a domestic IPS based on Mojaloop technology, self- Mowali was set up as a joint venture between two Mobile Network Operators based on
hosted in the country. Their mission is to allow anyone in Tanzania to pay anyone else in Mojaloop technology, hosted in the cloud. Their mission is to make paying a customer
Tanzania without the sender needing to know which institution holds the receiver’s account. across networks as easy and cheap as calling a customer across networks.

• Liabilities are settled in central bank funds. • Liabilities are settled in commercial bank funds

• Small institutions can join via aggregators and can use proxy settlement accounts if they • It connects participants in domestic markets and across jurisdictions.
are not allowed accounts at the central bank. • It manages currency conversion internally at the level of individual transfers, using PvP
• It will connect all licensed deposit-holding institutions in Tanzania, including MFIs and guarantees to remove exposure and settling daily.
SACCOs. There are 56 Tier 1 and 2 institutions in Tanzania • 9 institutions onboarded, 15 candidates in pipeline, including 6 networks of networks

*Currently running as single scheme for multiple jurisdictions.

© Oliver Wyman 5
WHILE OPTION 2 IS MORE COST-EFFECTIVE AND FASTER TO IMPLEMENT, DETAILED
REGULATIONS AROUND DATA SOVEREIGNTY NEEDS TO BE STUDIED IN DETAIL
1 2

Mojaloop as a Domestic IPS Mojaloop as a Central Hub

• Cost to setup and run individual local instances will be higher in • A central hub will be more operationally cost-efficient due to it being
Cost comparison to a central hub run by a single operator centrally

• Relatively slower rollout due to deployment across multiple

• Higher level of control over the speed of rollout and implementation in
geographies with different capabilities and infrastructure
a centralised hub. There is an option to have a common scheme
• Requirement to fully define a national scheme before participants can (Nexus-ready) before national schemes are fully defined.
Speed-to-Market onboard to it
• Onboarding time for a participant is currently approximately one month.
• Typical timeline to deploy is 6-12months (but may vary depending
• It will also allow interoperability across these jurisdictions
upon regulatory approvals, scheme design)

• Significantly more difficult to implement a central hub due to data

sovereignty issues, time and effort required to work around each
• Simpler for countries to run and maintain their own domestic IPS due jurisdiction’s data regulations. Mojaloop’s central data storage,
Regulations to the hub being operated and data processed locally, preventing any however, is minimal, and does not include PII as defined in PSD2
data sovereignty issues
• Note: Brunei has already indicated its feasibility and central bank can
resolve any outstanding issue if needed

• Simpler to manage a single central hub and operator, countries can

• Increased difficulty in ensuring appropriate governance across multiple
Governance jurisdictions
choose to transition to their own locally operated hub at any time in the
future

Legend: Low Difficulty Medium Difficulty High Difficulty

© Oliver Wyman 6
IN OPTION 1, COUNTRIES WITH MOJALOOP AS A DOMESTIC IPS WILL NEED AN INSTANCE OF
THE MOJALOOP-NEXUS GATEWAY TO INTEROPERATE, SAVING TIME AND EFFORT
WHAT IT IS
Deep-dive on
integration with nexus
Indonesia Vietnam to be conducted. At
(NAPAS) this stage it’s a broad 1. All 10 ASEAN countries interoperate through Nexus
(BI-FAST) assumption

2. Brunei, Laos, Myanmar

Need to • Domestic IPS for each country enabled by Mojaloop
understand
Malaysia ACI Worldwide CMA timelines and • Each country will have its own scheme locally operated by a
Nexus Gateway Nexus Gateway Cambodia technical aspect hub operator
(RPP)
(BAKONG) of ACLEDA
switch to
• Multi-instance local deployment of Mojaloop-Nexus gateway
ACI Worldwide will allow interoperability
Nexus Gateway evaluate if
Mojaloop can be 3. Cambodia
used instead
• Leverage existing Bakong system as domestic IPS. NBC has
requested ACLEDA to develop switch for x-border payments.
4. Vietnam
• NAPAS to be leveraged as Domestic IPS. Need to determine
Singapore Nexus Driven Payments Mojaloop Brunei feasibility to connect with Nexus
Vocalink
(FAST) Nexus Gateway
Nexus Gateway
Interoperability 5. Philippines, Thailand, Singapore
• Leverages existing domestic IPS. Vocalink based nexus
gateway needs to be established for interoperability
6. Malaysia, Indonesia
Mojaloop • Leverages existing domestic IPS. ACI Worldwide based nexus
Nexus Gateway
Vocalink gateway needs to be established for interoperability
Nexus Gateway

Thailand LAOS
Mojaloop
(Prompt PAY) Vocalink
Nexus Gateway
Nexus Gateway
KEY DEPENDENCIES / Open QUESTIONS
• Nexus adoption and timelines
• Integration feasibility of NAPAS-Nexus
PHILIPPINES Myanmar • ACLEDA Switch timelines to allow for x-border payments
Mojaloop Platform
• Settlement process differences b/w Mojaloop and Nexus

© Oliver Wyman 7
IN OPTION 2, A SINGLE CENTRAL MOJALOOP-NEXUS GATEWAY WILL BE REQUIRED TO CONNECT
WITH NEXUS TO ACHIEVE FULL INTEROPERABILITY
WHAT IT IS
c Deep-dive on integration with nexus to be conducted. b a Cost-effective option as central Mojaloop will a “Central” Mojaloop (ML) Hub for the Non-IPS ready countries
At this stage it’s a broad assumption be hosted centrally and will have single hub (Brunei, Laos, Myanmar). Central ML hub will be:
operator. Provides future flexibility to have
in-country local instance (if and when they • Cloud based & Centrally located – Mojaloop hub will be
Thailand want it ) centrally located in a business safe jurisdiction with
(Prompt strong data protection and governance mechanisms in
PAY) Vietnam place (Note: no sensitive customer data passes through
Singapore (NAPAS) the hub)
(FAST) • Run Scheme of Schemes: Central ML hub will run meta
scheme of schemes to allow interoperability the countries
Vocalink
Brunei • National Transition Plan: Countries will be able to
Nexus CMA transition, to their own scheme and instance whenever
Gateway Nexus Gateway they are ready an
Vocalink
Nexus
Gateway
b Central Nexus-Mojaloop gateway
Vocalink
Nexus
Nexus Driven Mojaloop One single Nexus-Mojaloop gateway to allow interoperability
PHILIPPINES Gateway Payments Central LAOS
Hub
Interoperability Central Mojaloop
nexus gateway
ACI Worldwide
c Nexus Driven Payments Interoperability
Nexus Gateway
To promote interconnectivity, BISIH has developed a model
ACI Worldwide for connecting national payment systems into a cross-border
Nexus Gateway Myanmar platform
Malaysia
(RPP)
Cambodia
Indonesia (BAKONG) KEY DEPENDENCIES /Open QUESTIONS
(BI-FAST) • From Previous Slide +
• Data Sovereignty issues for hub at central location
Mojaloop Platform Need to understand timelines • Governance and Operator of Central Mojaloop hub
and technical aspect of
ACLEDA switch to evaluate if
© Oliver Wyman Mojaloop can be used instead 8
 OPTION 2- DEEP DIVE INTO CENTRAL MOJALOOP HUB
Mojaloop HUB CAPABILITIES HoW WILL IT WORK?
• Option to setup a common scheme with simple rules and structure. Common
Centrally scheme will be designed to be Nexus-ready, accelerating participation
hosted and
single hub • Participant institutions can start going through the process of joining the
operator
scheme immediately

• Meanwhile, work can continue the definition of jurisdictional schemes (if

needed)

• When a jurisdictional scheme is ready:

• The appropriate participants can transfer from the central hub to the
new jurisdictional hub

• The jurisdictional hub can connect back to the central scheme to

support cross-jurisdictional transfers

• A single Nexus gateway manages interactions between the Mojaloop

schemes and the non-Mojaloop schemes

Foreign Exchange Process (Initial Hypothesis to be refined further)

• Currency conversion between schemes will be mediated through a reference

currency: the sending scheme will convert to the reference currency and the
receiving scheme will convert from it to its local currency

• This will provide continuous gross settlement for participants

• Quoting Services : Agreement of terms between the parties for transfer
• Directory Services: Resolves Aliases • Settlement will be backed by a correspondent banking model between the
• Settlement Services: Record obligations & Produces information for central bank settlement
central banks where the correspondent accounts are denominated in the
• Routing Services: Acts as reverse proxy; Each participant only speaks with right scheme and routes messages
reference currency
• Payment Manager: Manages security of messages, Connects to core banking
© Oliver Wyman 9
THERE IS AN INITIAL VIEW ON INTERCONNECTION B/W MOJALOOP AND NEXUS WITH SOME
OPEN QUESTIONS THAT NEEDS TO BE RESOLVED

HOW WILL IT WORK Open QUESTIONS

1. Mojaloop works by routing messages between participants: 1. Which institution(s) will function as the Nexus FX provider in
the hub does as little work as possible this example?
2. The Nexus gateway will appear to the Mojaloop as a service 2. How will the Liquidity Providers and the FX Provider(s)
provided by a participant institution settle with each other?
3. The participant institution will function as the Nexus Liquidity 3. The Mojaloop Nexus gateway will also need to
Provider… communicate directly with the Nexus FXP. We need to
define how this will happen ?
4. … so the participant institution can participate in the
Mojaloop settlement process…

5. … and can participate separately in the Nexus settlement

process via a separate settlement relationship with the
Nexus FX provider

© Oliver Wyman 10
HOWEVER, THERE IS CLEAR END POINT MAPPING BETWEEN THEM
Nexus endpoint Semantics Mojaloop endpoint (send) Mojaloop endpoint (receive)
GetSLD This step is necessary so that the Source Bank’s app knows Handled by CNP as part of Mojaloop Managed in sender CNP.
which information to ask the Sender for and can set up the address resolution request.
screens accordingly. For example, the app needs to know what
account formats or aliases are accepted and the maximum
payment size that can be sent to that country.
GetQuote The Source Bank can ask the Source Gateway for an FX rate Handled by CNP as part of Mojaloop Managed in sender CNP
quote (2). This can be in parallel to requesting the SLA above. agreement of terms request
GetAccount Before executing the payment, the Destination Account needs to GET /parties PUT /parties
be validated to ensure that (a) the account details or alias
provided by the Sender are correct and (b) the Destination Bank
and Recipient’s account can accept Nexus payments. Includes
name discovery
PreApproval All cross-border payments must be screened against sanctions This process is analogous to, though more Based on these assumptions, response will be
lists to ensure the payments are not financing terrorism, drug restricted than, the agreement of terms PUT /quotes.
trafficking or other illicit activities. Screening is the responsibility of process in the Mojaloop world. Based on the
the banks involved in the payment (specifically the Source Bank, assumption of an identification between the
Source Liquidity Provider, Destination Liquidity Provider and gateway and the liquidity provider, it will be
Destination Bank). Nexus does not perform screening itself, but it handled by the POST /quotes endpoint. The
does provide an API that allows these banks to communicate with CNPs will be able to reject payment on
each other so that they can approve (or reject) the proposed behalf of the liquidity provider.
payment before the payment instruction is made. The aim is to
undertake sanctions screening before any funds are moved (in
either the Source or Destination IPS) and to resolve any alerts or
matches against the sanctions list without human intervention,
wherever possible.
Payment execution The Source Bank can initiate the final payment instruction, which POST /transfers. Mojaloop has mappings for PUT /transfers. Mojaloop has mappings for the
initiates the transfer of funds. Note: in the Nexus world, this the Nexus pacs.008 message. Nexus pacs.002 message.
includes assumptions about settlement which are not necessarily
reliable for the Mojaloop/Nexus interface

© Oliver Wyman 11
MOJALOOP SECURITY AND INFRASTRUCTURE REVIEW

Scope of REVIEW So FAR Observations

Infrastructure and Security Components of Mojaloop ✓ The architecture standard is intended to be open-source platform agnostic – multi – cloud or
o Container on Kubernetes on premise (in data centre)
o Messaging on Kafka ✓ Encryption at Transit - Network security – TLS 1.2 mutual authentication.
o MySQL database ✓ User authentication using OIDC against IDP
o Forward proxy on HAProxy ✓ API – token based authentication using public-private certificates
o Reverse proxy/Load Balancer on NGNIX ✓ Monitoring and management – Prometheus and Grafana
o MongoDB for NoSQL ✓ Logs and Search – FluentD -> Elasticsearch
o Redis for Caching ✓ Helm Chart for Kubernetes application setup, installation
o Vault for token, certificate management ✓ Terraforms is used for Infrastructure provisioning
o API GW on WSO2 migrating to Broadcom ✓ Some of the components uses AWS managed services – Kafka, MySQL, MongoD
o VPN for Hub Administration

Pending items for review

Additional security controls for considerations
o For Security
o Network segmentation – public, private, db subnets, Dev, uat and network routing
o Threat detection and alerting o Banking and Government require end to end network encryption. Encryption at rest required for
o Account segmentation – different accounts for prod, uat, dev database, may require field level encryption for sensitive fields. Key identifier: account ID,
o Security Logs, Monitoring and Reporting names. Encryption also applies to backup//
o For Management
o Backup o Keys management require FIPS 142-3 HSM storage and management.
o Patch Management o All administrator screen require 2 FA authentication with Privilege Identity
o Release Management Management/Priveilege Access Management
o For Availability
o SLA – Availability, RTO, RPO o Logging require Database Activity Monitoring to log queries and database activities
o Design for High Availability
o WAF and NextGenFirewall (with packet inspection) require on the edge
o

© Oliver Wyman 12
Appendix
SOURCES

Content Link
Mojaloop Home Page https://mojaloop.io/

Mojaloop Documentation https://docs.mojaloop.io/

Nexus Home Page https://www.bis.org/about/bisih/topics/fmis/nexus.htm

Nexus Documentation https://docs.bis.org/nexus/

Vietnam NAPAS 247 https://napas.com.vn/en-us/for%20customers/for-banks-and-finance-companies/24-7-quick-interbank-funds-transfer-service-1-2.html

Cambodia Bakong Documentation https://bakong.nbc.org.kh/download/KHQR/integration/Bakong%20Open%20API%20Document.pdf

Singapore PayNow Fact Sheet https://abs.org.sg/docs/library/paynow_factsheet.pdf

Malaysia DuitNow Home Page https://www.duitnow.my/

Thailand PromptPay Roadmap https://www.bot.or.th/English/PaymentSystems/PolicyPS/Documents/PaymentRoadmap_2021.pdf

Philippines InstaPay Home Page https://www.instapayph.com/

Indonesia BI-FAST Documentation https://apidevportal.bi.go.id/snap/api-services/transfer-debit/direct-debit-bi-fast

PayNow-PromtPay White Paper https://abs.org.sg/docs/library/PayNow-PromptPay_Linkage_White_Paper.pdf?sfvrsn=9

© Oliver Wyman 14
ABOUT Mojaloop
COMPONENTS OF THE MOJALOOP ECOSYSTEM
Mojaloop has payment managers to allow seamless integration with financial institutions core systems. By design, it is
catered for multiple financial institutions i.e. banks, mobile wallets, MFIs, central banks etc.

Mojaloop Hub
Payment
Bank Bank
Manager
Account
Lookup
Service

Transaction Settlement
Services Services

Mobile Payment Mobile

Wallet Ledgers Manager Wallet

3PPI Reporting

Portals
Payment
MFI MFI
Manager

Central
Bank

© Oliver Wyman 16
MOJALOOP DEPLOYMENT OPTIONS
Mojaloop provides multiple options to deploy, has tie-ups with Modusbox as a global SI or completely local implementation

1 Global SI implementation and maintenance

• Flexibility of deployment options allow

participants to decide the level of
Mojaloop guidance that they wish to receive from
2 Training Local SI implementation and maintenance Mojaloop
Program
• Sufficient guidance will be provided for hub
operators to operate Mojaloop
independently

3 Mentorship and handover

1. Deployment options are cloud native. However, capable of on-premise deployment.

© Oliver Wyman 18
MOJALOOP OPERATIONS OPTIONS
Mojaloop provides multiple options to operate, from global outsourcing options to local outsourcing

1 Global outsource operations

Mojaloop
2 Training Local outsource operations
Program
• Multiple operations options available for
hub operators to select based on their
needs and preferences
Mojaloop
3 Training Central bank operations
Program

4 Build, Operate, Handover/Hybrid

© Oliver Wyman 19
MOJALOOP PRODUCT OVERVIEW
Completely API driven architecture (RESTFUL-ish API)

• Mojaloop consists of:

– API Definitions
– A reference implementation of a central
switch
– A catalogues of ancillary tools to
accelerate setting up and joining a
scheme

© Oliver Wyman 20
TESTING TOOLKIT AS PAYER FSP, PAYEE FSP AND HUB
Mojaloop provides toolkits to simulate and test various participants to de-risk actual deployment

Target Users
Target Users
• Product / Business Users: Explore
APIs, Mojaloop use cases, Initiate • Developers: Onboarding, Exploration,
requests, Validate Scheme Rules or Development (Mocking), Integration
Regulatory compliance • Business Operations: Onboarding,
• QA teams: Regression Tests, Validating requests, monitoring
monitoring, debugging • Infrastructure, QA teams: As a
• Infrastructure teams: Scheduled test simulator for testing
jobs, post-install validation

Target Users
• Schemes: Simulation environment, Labs, Certification, Onboarding DFSPs
• DFSPs: Validating implementations, Simulate Switch
• Developers: Development support by Switch simulation, debugging, monitoring,
demonstration

© Oliver Wyman 21
MOJALOOP PRODUCT STRUCTURE
Containerized platform with a CI/CD construct
Quality Assurance Accelerators

Functional License, Payment Connection Oracle

Onboarding Simulators Testing toolkit Event SDK Business Operations Framework
tests Security, audit manager manager SDK

External interfaces

OAuth MTLS Interoperation API Third Party API Settlements API Administration API Reporting API Onboarding API

Supporting Components Core Components

Event Stream Processor Central-Services Third Party API

ALS Oracle: PathFinder Central-Settlements Mojaloop API adapter Mojaloop API adapter
(Logs, Error, Audit, (API –Operational adapter
(MSISDN Lookup) (API –Settlements) (API transfers) (API –Bulk Transfers)
Tracing) Admin) (API transfers)
Persistence

Event-Sidecar Central-Settlements Central-Services Central-Services Third Party API

ALS Oracle Templates Mojaloop API adapter
REDIS (Logs, Error, Audit, (Handler – Settlement (Handler – Transfer (Handler – Bulk adapter
(Identifier Lookup) (Handler – admin)
(SDK and cache) Tracing) Windows) Prepare) Prepare) (Handler – notifications)

MongoDb Central-Settlements Central-Services Central-Services Mojaloop API adapter Transaction Request

Email-notifier
(Event Processing Central Event Processor (Handler – Transfer (Handler – Transfer (Handler – Bulk Fulfil) (Handler – notifications) Service
(Handler- Email)
Data) Settlements) Position) (API - RTP)

MySql/Percona Central-Services Central-Services Account look-up

(Reference and Settlement Management Central Services
(Handler – Transfer (Handler – Bulk Service
transfer data) (Closing, reporting) (Handler – timeout)
Fulfil) Process) (API - RTP)

Kafka
Central Services
(Message streaming
(Handler – get
and persistence)
transfers)

Operational Monitoring

APM
(Distributed Tracing)

Test, build, Deploy

(NPM Repository)
Package Manager

Test, build, Deploy

Container Engine

AWS, Azure, On-

(Documentation)
Infrastructure
Infrastructure
Container

Docker Hub
Kubernetes

Repository)
abstraction

VuePress
NPM Org
IAC Tools

(container
Circle-CI
Docker
EFK ElasticSearch / FluentId / Kibana Management
Helm

Prem
and CI/CD
(Log Search / collection / monitoring / tracing)
Orchestration
Promfana
(Metrics – Collection /Monitoring)
© Oliver Wyman 22
MOJALOOP IS AN OPEN-SOURCE CLOUD-NATIVE PAYMENT SWITCH
12 Factor Principles
A methodology for building modern, scalable,
portable and maintainable software-as-a-service
applications. Mojaloop’s microservice designs
are guided by these principles. Ref:
https://12factor.net/
Microservices
Mojaloop is build using loosely coupled services
with lightweight protocols used for inter-service
communication.
Containers
Microservices are containerised using Docker, a
OS-level virtualization run-time package
(application, configuration, etc), which isolates the
underlying application processes from one
another and the underlying host OS, and ensures
runtime consistency.
© Oliver Wyman
Event Driven
Mojaloop uses Apache Kafka, a highly
performant and distributed message streaming
platform that ensures all internal events are
durable. It reduces tight coupling between
microservices and guarantees ordered
processing.
Runtime
Mojaloop is build using Node.js, a unified
lightweight, asynchronous event-driven
JavaScript lightweight runtime which is highly
portable / scalable for both front-end and
backend applications.
Infrastructure Agnostic
Runs on Kubernetes, an open-source system for
automating deployment, scaling, and
management of containerized applications with
self-healing capabilities based on policies. It
provides a standard platform which supports on-
prem, on-cloud or hybrid deployment models.
Persistence & Caching
Utilising MySQL as on open source, and robust
persistence store.
Redis used as a performance caching solutions.
With MongoDB being used as an object-store for
bulk-processing.
Tracing & Log analysis
Utilises ElasticSearch, FluentD and APM to
collect/filter logs and tracing information for all
microservices, with. Kibana being used for
presentation of operational dashboards. These
technologies are fundamental to tracing and
troubleshooting issues.
Real-time Monitoring
Grafana and Prometheus are used for collection
and display of real-time operational metrics:
➜ Performance
➜ Health
➜ Alerts
23
MOJALOOP API CHARACTERISTICS

1 Service Oriented REST architecture

• Services are distributed: there is no central authority which executes a transfer
• Services imply actions as well as defining content
• Services are not fully stateless: some parts of the orchestration of a transfer rely on comparing states
• Clients decide common IDs

2 Uses http over tls and standard http calls

3 Json is used as data exchange format

4 Fspiop service interactions are synchronous

• A recipient will respond “immediately” to an HTTP call, only with 2xx or 4xx status codes
• All other errors are sent asynchronously in a PUT callback

1. API definition can be found in the Mojaloop FSPIOP specification https://docs.mojaloop.io/api/

© Oliver Wyman 25
MOJALOOP SECURITY
Mojaloop messages are exchanged over the internet and are protected by three mechanisms

1 mlts
• Mojaloop uses certificate-based MTLS.
• Each message transmitted is encrypted using a shared key.
• It can only be decrypted by another organisation in possession of the shared key.

2 non-repudiation
• The standard for non-repudiability is JWS
• The sender of a message signs its content using a private key.
• Key fields of the header and entire body of the message are signed
• The signature is transmitted as part of the message header
• The recipient compares the signature using the sender’s public key, and confirms that they match.
• All Mojaloop messages are signed except for the original discovery request.

3 Two-phase commit
• Uses the Interledger Protocol (ILP)
• The payee DFSP is responsible for setting the terms of the transfer, the payee DFSP signs the agreed content of the transfer using a private key.
• It passes the resulting signature (the fulfilment) through a public one-way hash and the hashed result (the condition) is returned to the payer DFSP.
• The payer DFSP and the switch retain the condition as they reserve funds during the transfer process.
• When the payee DFSP accepts the transfer, it returns the fulfilment to the switch and the payer DFSP.
• They can then pass the fulfilment through the same one-way hash and check the result.
• Since the response is verifiably from the payee, the other parties can be confident that the transfer has been completed successfully

© Oliver Wyman 26
Other SLIDES
CURRENT STATE OF DOMESTIC IPS AND CROSS BORDER PAYMENTS
Most ASEAN countries have focused on domestic instant payments systems (“IPS”) or digital wallets; few have started
bilateral cross border digital payments

Bilateral agreements Countries

GrabPay - Singapore <> Legend
1
GrabPay Philippines
BURMA
PayNow - Singapore <> Closed loop e-wallet to e-
2 LAOS
PromptPay Thailand wallet
Bakong e-wallet / Malaysia →
3 THAILAND
Maybank’s MAE Cambodia VIETNAM IPS (bank) to IPS (bank)
only CAMBODIA PHILIPPINES

4 PayNow – Singapore <>

DuitNow (planned) Malaysia
PayNow – Singapore <> Planned only, IPS to IPS
5 InstaPay (In Philippines MALAYSIA BRUNEI
discussion) SINGAPORE
DuitNow – Malaysia <>
6
InstaPay (planned) Philippines

INDONESIA

Key takeaways
• Currently, bilateral arrangements are either Bank account to Bank account payments (via linking of local IPS) or e-wallet to e-wallet closed loop
(GrabPay/GrabPay or BakongMayban to Bakong); others are only for merchant QR recognition (not covered here)
• Interoperability which promotes financial inclusion will need to have (1) bank-bank, (2) bank-ewallet, (3) ewallet-bank and (4) ewallet-ewallet connectivity
• Of the 90 total unique country <> country possibilities, only 8 (~9%) have agreements in place or planned for IPS connectivity

© Oliver Wyman 28
PROJECT SO FAR
We conducted 15+ meetings with Banking associations, BISIH, Mojaloop across 4 weeks to kick-start the feasibility study

Key stakeholders

Banking associations Bisih, project nexus

Sim Kiem Lee, Brunei Association of Banks Andrew McCormack
Brunei
Liaison Officer Centre Head

Sopheap Char, ACLEDA, Ben Dyson

SVP & Head of Product Project Lead for Nexus
Cambodia
Phal-Chalm Theany, ABC
Secretary General Benjamin Lee
Project Manager

Myanmar Aung San Phyo, KBZ Bank

Lead of Payment Operations
Mojaloop Foundations
Nguyễn Đăng Hùng, NAPAS
Vietnam Deputy CEO, Business Development Steve Haley
Thanh Hoang , NAPAS Director of Market Developments and Partnerships
Deputy Head, Business Development and Partnerships

Laos Pending Meeting Paul Makin

Director

Michael Richards
Financial Services Principal

© Oliver Wyman 29