What is Mojaloop - dispelling the myths & important messages

it was coming later in the conversation!

hopefully we kind of got there:

  • DFSPs in a consortium (minimium = 3, ideally a mix of bank and non-bank!) need to want to solve the problems of moving money efficiently and effectively in service of end customers (who could be individuals, MSMEs or larger businesses/governments)

  • someone needs to run the technology (hub operator)

  • we believe that this consortium is a good fit for us if they believe in:
    … open loop (easy for another DFSP to join)
    … customers come first and a good ux will lead to deeper adoption (eg centralised directory services)
    … consumer protection & regulatory compliance can be simpler through shared utility services (eg shared FRMS, shared regulatory reporting mechanisms, transaction limit checking imposed by regulations actively part of the design)

No-one pays Mojaloop foundation (other than its members, a whole different business model to what we are talking about here.)
Hence I stay away from the word “customer”
I have used “adopter” - as in the consortium (scheme) + hub operator that choses the Mojaloop way.

How they pay each other (or not) is not in our control as the Mojaloop Foundation/Community

1 Like

this will come through over the course of today:

  • scheme is responsible, governments are part of the design process
  • technology can support, and good to involved technology actors in the conversation (rather than suppler/vendor involved only at the end)
  • open source way is a different approach

Hi Peter, yes! The CPMI guidance on financial market infrastructure has been a guiding influence on the system design. As we look at cross-border/cross-currency, we are developing the Payment-vs-Payment model to simplify the needs of two systems in different markets, and to enable intermediaries in a competitive way.

And Coil is working on early thinking about Delivery-vs-Payment: the way to simultaneously exchange digital goods for digital payment, seamlessly in real time. Interledger is the foundation, and paying for digital goods (like airtime, PayGo solar credits, a football ticket, …) are the general use case.

These two models are explored by BIS/CPMI and we want to build on their excellent thinking.

i think in Africa this line is blurry today between scheme and payment system. there is an interesting paper on this from Charles Niehaus: Charles Niehaus on LinkedIn: Futures for Mobile Money Interoperability in Africa | 28 comments

some interoperability switches are acting as both, effectively (with the risk of not being sufficiently neutral and/or “making do” with available APIs in aim of getting it done swiftly… is it future facing partnership? not always).

And sometimes one of the scheme participants are running the infrasturcture (with risk of monopoly/not sufficiently neutral)

Question for the panelists: Can you please tell us what is your definition of sandbox vs pilot?

No-one pays Mojaloop foundation (other than its members)

hence i stay away from the word “customer”
I have used “adopter” - as in the consortium (scheme) + hub operator that choses the Mojaloop way.

how they pay each other (or not) is not in our control as the Mojaloop Foundation/Community

This will sing through deeply in product council sessions as the big ask!

they might not pay Mojaloop Foundation or even an external company like ModusBox, but they have to pay someone to get the code up and running and keep it running - even if that is internal someones

Good question - we are currently trying to define it. For me:

Sandbox - fake money, fake rails, non-production participants
Pilot - real money, real rails, likely manual business and technical operations - and likely a metered transaction rate to make that manual process feasible.

1 Like

Thanks! That’s a good starting place for me.

this is the kind of conversation we’re having at the product council and trying to bring it alive with examples, specifically. Sandbox is an incredibly loaded term! We’re trying to focus on “whats the job to be done” with different environments.

I always associated a Sandbox environment with a test environment. But as to whether it is mainly for Business Acceptance or User Acceptance or both has been the bone of contention in my experience.

1 Like

absolutely. there in reality are several test environents and different levels of fidelity for different testing purposes too. Another illustration i use that comes from a “jobs to be done” lens here: