What is Mojaloop - dispelling the myths & important messages

Events Mojaloop PI-13 OSS Community Meeting
#1

Monday January 25, 2021
11:20 AM UTC

Session Leads: Lesley-Ann Vaughan(@lavaughan), Paul Makin (@PaulMakin) and Steve Haley (@stevenhaley1)

Session Description: A discussion with a panel on how we should talk about mojaloop - through the lens of helping outsiders understand better what exactly it is when they know little going in to the conversation, or potentially have heard something untrue. With recent experience talking this through with regulators, existing hub operators, folk at DFS Hackathon – focused on real questions asked by decision makers.

Session Recording

Please post questions, suggestions and thoughts about this session in this thread.

Post by clicking the “Reply” button below.

#2

Liquidity improves, but growth requires smart borrowing. Do you see Mojaloop as a source of data for lenders to determine credit worthiness for micro or emerging business?

#3

I’m not sure that I understand the point about customer experience. What specifically should we be doing to improve it? One of the comparison points is with a mobile phone call - I never think about what network the person I’m calling belongs to. Shouldn’t we be disappearing in that way as far as the customer is concerned?

1 Like
#4

Who are the “hub operators” we keep referring to? Are they central banks (or central bank sanctioned entities), commercial entities, mobile money provider (DFSP) consortia or something else?

i.e. Who is the Mojaloop customer?

#5

Adding to both Michael and Adrian’s questions, who is the customer, how do we make the experience ubiquitous, and if just a hub or switch, the “users” need an end to end complete experience, if not Mojaloop how do you insure things are covered end end (recommendations, ecosystem participation, best practices etc).

#6

Aren’t we saying that from some perspectives the customer is the scheme, from other perspectives the customer is the DFSP, form still others it’s the DFSP’s customer…?

1 Like
#7

I am biased towards focus - the “customer” is the entity that pays for this software - others are their clients

#8

Well, the DFSP pays to join a scheme. We elide that by kind of asusming that central institutions will mandate it, which may be a problem for us… And the customer pays for it, because DFSPs generally aren’t charities…

#9

In addition to “lab” environment, with an always-on Mojaloop demo, we will talk this week about “Pilot in a Box” … a simplified, cloud-hosted Mojaloop, packaged for cloud-deployment to support pilot projects.

3 Likes
#10

yes - they pay the scheme owner - i.e. the DFSP is the client of the scheme owner - not the technology provider

#11

Yes that would be very helpful.

#12

I disagree: they pay. They pay because it costs them time, effort and money to join a scheme. They don’t pay the Foundation - but then nobody does…

#13

Is the scheme owner the same as the hub operator?

#14

Greg - I think this is an awesome point - sorry we didn’t get to it - but I think that centralized switching is the only way that micro businesses can own their own data and choose how to open it for credit worthiness to lenders

#15

For me, two they are separate functions sometimes (hopefully) in separate entities. Scheme owner owns the business (contracts with participants, regulated, sets rules and prices) and the scheme owner contracts to the hub operator to run it on a daily basis (tech ops, business ops, settlement, disputes). But @miller would be much better to delineate them

#16

I think that the operator operates the scheme on behalf of the scheme owner (though they may be the same entity…)

#17

there are more than 1 source of data for credit-worthiness purposes… esp in financial inclusion audience the most valuable data for credit scoring is often around phone usage more than digital transactions today.

so i think its a journey. the data could be valuable when there is a volume of it. to get a volume of it adopters need to think long and hard about why customers will convert from cash to digital. This is fundamental first to make the data valuable for this kind of purpose.

Add to that: we focus on data minimisation in the core hub design today. so the hub itself is effectively GDPR ready out of the box. For it to be useful for credit scoring - adaptation and extension would be needed by a scheme.

#18

The G20/ FSB / CPMI directives on cross border payments and interoperability will be a huge enabler , I think

#19

that’s the point. we are trying to disappear it. billateral and schemes that require complicated identifiers (like IBAN) make it hard to disappear that. it leaves custoemr with a complex experience.

but its more: if there are multilpe hops: customers get told they’ve successfully made a payment: not to the biller/merchant, but to that biller/merchant’s aggregator. That doesn’t lead to good consumer protection measures.

we’ve outlined this thinking in a document - our session was too short to get into the details!

#20

I think this is right. We think about three roles… Scheme governor, scheme owner, and scheme operator. The first is “who wrote the rules?” The second is who are the direct beneficiaries, and “who authorizes admissions, arranges for settlement, and sanctions misbehavior?” The third is really a system operator function, “who provides the lab and the lab coats to keep the system running?”

The important nuance is that the boundaries between these roles are not uniformly agreed. A system governor might also be the owner (in a central bank run system, e.g.). A scheme owner might be a consortium of commercial providers, who outsource operation. Other models include all three as a single entity or separate them all into different organizations.

But the roles are distinct.