Mojaloop Community Central: Mojaloop Foundation

A Practical Blueprint for Merchant Payments with Mojaloop

Paul Makin — Thu, 17 Sep 2026 16:50:10 +0000

The Mojaloop Community has published the first formal release of the Mojaloop Merchant Payments Overview, providing adopters with a practical description of how merchant payments can be implemented alongside an existing Mojaloop deployment.

The document brings together the key components, architecture and operating considerations needed to support merchant payments while keeping merchant-specific functions separate from the core Mojaloop Hub.

Read the Mojaloop Merchant Payments Overview

Bringing Merchant Payments to Mojaloop

Merchant payments are an important use case for inclusive instant payment systems, but accepting a payment at a merchant involves considerably more than simply transferring funds. Merchants need to be registered and identified, appropriate know your business (KYB) checks need to be undertaken, payment acceptance mechanisms need to be provided, and schemes need to address operational and fraud risks.

The Merchant Payments Overlay is designed to provide these capabilities without adding them to the core Mojaloop Hub. The overlay brings these elements together into an architecture that adopters can adapt to their own regulatory, commercial, and operational environments.

A Flexible Merchant Registry

At the heart of the model is a Merchant Registry. Merchants are onboarded by authorized registering/acquiring DFSPs, with appropriate KYB checks undertaken before a unique Merchant ID is issued.

That identifier can then be made available to the Mojaloop-based IIPS as a routable alias, while the merchant’s DFSP maintains the definitive mapping between the Merchant ID and the account into which payments are received.

Importantly, the model does not prescribe a single way to operate the registry. The document describes both centralized and federated approaches, allowing adopters to select a model appropriate to their scheme governance and market structure.

Supporting QR-Based Acceptance

The overlay also provides a practical route to QR-based merchant acceptance. The current open-source implementation uses static QR codes, minimizing the technology required at the merchant premises. The customer scans the QR code using their DFSP’s smartphone application and enters the transaction amount.

The architecture can also be extended to dynamic QR codes, where the amount and other transaction information are incorporated into a QR code generated for an individual purchase. Numeric Merchant IDs can additionally support customers using USSD and feature phones, extending the model to a wider range of payment scenarios.

Security at the point of acceptance is also addressed. The overview describes how cryptographic signatures and a scheme-level trust model can protect QR codes against substitution or tampering. They also allow the customer’s application to verify that a QR code was issued under the authority of a participating DFSP and the scheme.

Keeping Merchant Functions Separate

For adopters, one of the main benefits of this approach is separation of concerns.

Mojaloop continues to provide interoperable routing, liquidity management and real-time funds transfer, while the overlay handles merchant-specific functions and merchant payment scheme rules. This separation allows a merchant payments service to evolve without introducing unnecessary complexity into the underlying IIPS.

The result is an approach that gives adopters a way to add merchant payments capabilities while maintaining a clear division between the core payment infrastructure and the functions specific to merchant acceptance.

Looking Ahead with LEIs

The document also points to future possibilities. Work with the Global Legal Entity Identifier Foundation (GLEIF) is extending the model to incorporate legal entity identifiers (LEIs) into merchant onboarding and payment addressing.

This creates opportunities to automate elements of KYB, strengthen merchant identity verification and, particularly for cross-border payments, use a globally recognized legal-entity identifier alongside the scheme-specific Merchant ID.

A Starting Point for Adopters

For organizations considering merchant payments, the Mojaloop Merchant Payments Overview provides more than a description of a feature. It sets out a starting architecture and operating model that can be adapted to local requirements while retaining a clear principle: keep merchant-specific complexity at the edge, and use Mojaloop for what it does best — the interoperable movement of funds between participating DFSPs.

For Mojaloop adopters looking to support merchant payments, the overview provides a practical foundation for understanding how these capabilities can fit alongside an existing Mojaloop deployment.

Read the Mojaloop Merchant Payments Overview

Recommending READ COMMITTED as Mojaloop's Default MySQL Isolation Level

Megan Cannon — Thu, 03 Sep 2026 19:04:07 +0000

Recommending READ COMMITTED as Mojaloop's Default MySQL Isolation Level
August 2026 - a recommendation from the Mojaloop core team to Mojaloop adopters and the wider community.
TL;DR
While investigating deadlocks reported against a Mojaloop deployment, we traced the cause to MySQL's default transaction isolation level, REPEATABLE READ, and found that switching to READ COMMITTED fixed two problems in the same deployment:

Incoming transfers were being blocked by the close settlement window process.
A long-standing deadlock in central-ledger's timeout handler (transfer timeout sweeps colliding with live transfer inserts) disappeared. We've already updated the reference example-mojaloop-backend chart in mojaloop/helm to set this correctly (PR merged post v17.2.0). In addition, one pre-requisite for this to work is the central-settlement version v17.4.0 .

This post explains the root cause, why we think it should be your production default too, and exactly how to make the same change on your own deployment - safely, reversibly, and without waiting for a future Mojaloop release.

The problem
Mojaloop's core write path (central-ledger) and its settlement path both hit the same InnoDB tables - transferStateChange, transferTimeout, and participantPosition - under MySQL's default isolation level, REPEATABLE READ.
Two symptoms showed up together:
● Settlement blocking live traffic. The close settlement window process - which scans and aggregates over ranges of transfers to close out a window - was taking shared locks that live incoming transfers then queued behind. Under load, transfer processing latency would spike every time a settlement window was closed.
● A timeout-handler deadlock. The cron-based timeout sweep runs an INSERT … SELECT to pull expired transfers. Under REPEATABLE READ, that statement takes shared next-key locks on the index range it scans - a normal part of how InnoDB prevents phantom reads at that isolation level. Those locks collided with live, in-flight transfer commits landing in the same index range at the same moment.
Both symptoms have the same root cause: REPEATABLE READ's phantom-read protection is implemented with locking (gap locks / next-key locks on range scans), and Mojaloop's write path is
dense enough, on the same narrow set of hot tables, that those locks become contention rather than protection.

Why REPEATABLE READ is the wrong default here
REPEATABLE READ exists to give a transaction a consistent snapshot across multiple statements - so if you SELECT the same range twice in one transaction, you see the same rows both times, and to guarantee that, InnoDB locks the gaps between index records to stop other transactions inserting into them.
Mojaloop's hot-path transactions don't need that guarantee:
● Transfer processing is short-lived: read position, apply a delta, write, commit. There's no multi-statement read-then-read-again pattern in the transfer path that depends on a frozen snapshot.
● Consistency where it actually matters: participant position balances - is enforced by explicit row locking (SELECT … FOR UPDATE) and unique constraints, not by gap locks preventing phantom rows.
● The thing that was relying on wide range scans (settlement aggregation, timeout sweeps) doesn't need repeatable-read semantics either - it needs to not block the write path while it scans.
READ COMMITTED removes the gap-lock behavior on non-matching rows for these scans (InnoDB still takes locks on rows it actually examines and modifies, just not the gaps around them). That's the entire fix: less locking on ranges, same row-level consistency guarantees where they're enforced explicitly.

Is this safe? What to check before you flip the switch
READ COMMITTED is not a free lunch - it changes semantics, and you should confirm these are true for your deployment before rolling it out:
● No code relies on repeatable snapshots within a transaction. Audit anything that runs more than one SELECT against the same range inside a single DB transaction expecting the second read to match the first (some reporting/reconciliation jobs are the usual suspects - the live transfer/settlement path in central-ledger is not one of them).
● binlog_format is ROW or MIXED. Statement-based replication is unsafe under READ COMMITTED because the same statement can legitimately produce different results depending on timing. ROW/MIXED (MySQL's default since 5.7.7) sidesteps this entirely - if you've explicitly forced STATEMENT anywhere, stop and fix that first.
● Nothing pins the isolation level per-connection. We confirmed database-lib (central-ledger's DB layer) has no afterCreate hook or per-connection isolation override - it inherits whatever the server default is. If your fork or a service you run does pin isolation level in application code, that code wins over the server default and won't be affected by this change either way - check for it so you know what you're actually changing.

Results
After the change: no recurrence of the timeout-handler deadlock, and closing a settlement window no longer visibly stalls incoming transfer throughput. This isn't a partial mitigation - the locking mode that caused both symptoms is gone.

What we've already changed upstream
The example-mojaloop-backend chart in mojaloop/helm already reflects this recommendation on its MySQL primary (which is provided for reference).
This alone doesn't change your production database. example-mojaloop-backend is a demo composition, not a values file any real deployment inherits automatically - if you're running Mojaloop in production, you almost certainly maintain your own values.yaml, and it needs the same change applied deliberately. That's what the rest of this post walks through.

How to change it on your own deployment
Below are the detailed steps for the configuration changes, once you’ve confirmed using central-settlement version v17.4.0 . This change (below) is server-wide, not central-ledger-only.

Test it live, no persistence, reversible in one command
SET GLOBAL transaction_isolation = 'READ-COMMITTED';
This affects new connections only - sessions already open keep their old isolation level until they reconnect. It does not survive a MySQL restart. This is the right first step: flip it, let connection pools cycle, watch your deadlock/lock-wait metrics, and revert with the same command if anything looks wrong.
Check current state at any time:
SELECT @@GLOBAL.transaction_isolation, @@SESSION.transaction_isolation;
Make it durable without a restart (MySQL 8.0+)
SET PERSIST transaction_isolation = 'READ-COMMITTED';
SET PERSIST writes the value to mysqld-auto.cnf in the data directory and applies it immediately and globally - no pod restart, no downtime. It survives a MySQL process restart too, as long as the data directory itself persists.
That last clause matters more than it looks. If your MySQL data directory doesn't persist across pod restarts - an ephemeral volume, common in dev/test deployments - mysqld-auto.cnf disappears the moment the pod is recreated, and you silently fall back to REPEATABLE READ. SET PERSIST alone is not enough on ephemeral storage - you need step 3 as well.
Bake it into your persistent server configuration (durable across restarts)
SET PERSIST only helps if the data directory it writes to survives. Either way, the isolation level should end up in whatever configuration your MySQL server loads on startup, so a redeploy, a restore, or a fresh replica doesn't quietly revert to REPEATABLE READ.
If you're running the Bitnami MySQL Helm chart (used by the Mojaloop reference deployment):
mysql:
primary:
extraFlags: "--transaction-isolation=READ-COMMITTED"
(An alternative, primary.configuration, fully overrides the default my.cnf - only worth it if you're already overriding the full config for other reasons, since you'd need to carry forward every default setting alongside the isolation line.) Apply with helm upgrade --install -f values.yaml.
If you're running MySQL another way - a self-managed server, a different Helm chart, or a managed service like RDS/Aurora/Cloud SQL - the mechanism differs but the target is the same: set transaction-isolation=READ-COMMITTED under [mysqld] in my.cnf, or the equivalent parameter in your provider's DB parameter group, and apply it through whatever config-management path you already use for that server.
Either way, this restarts the MySQL primary. On a single-primary/standalone topology that's a brief write-unavailability window, so schedule it like any other maintenance-window change: apply SET PERSIST first for immediate effect, then land the durable config change, so you get zero-downtime and durability without the two steps needing to be simultaneous.
Verify and monitor
SHOW VARIABLES LIKE 'transaction_isolation';
SELECT * FROM performance_schema.data_locks; -- confirm gap-lock behavior is gone on hot ranges
SELECT * FROM information_schema.INNODB_TRX; -- watch for long-running transactions post-change
Watch deadlock counters (SHOW ENGINE INNODB STATUS, or whatever you already scrape into Prometheus) before and after - you're looking for the timeout-handler-vs-live-insert deadlock signature to stop appearing entirely, not just get rarer.

Rollback
SET GLOBAL / SET PERSIST back to REPEATABLE-READ (or RESET PERSIST transaction_isolation to drop the override and fall back to compiled default), and revert whatever persistent configuration you changed in step 3. Nothing about this change is one-way.

A note to the community
This is a recommendation, not a mandate - you don't need our sign-off to try it, and every deployment is free to make this change on its own timeline. That said, if you're running Mojaloop in production and know of a reason REPEATABLE READ semantics are load-bearing somewhere we haven't audited - a reporting job, a reconciliation flow, a fork with different transaction boundaries - we'd like to hear about it, so we can document the exception for others weighing the same change.

🚀 Announcing Mojaloop v17: Powering Cross-Border Instant Payments 🌍

Samuel Kummary — Wed, 02 Apr 2025 14:41:33 +0000

The Mojaloop Foundation is excited to announce Mojaloop v17.0.0 — a game-changing update that expands Mojaloop beyond domestic instant payments.

🔥🔥🔥 With cross-border capabilities, including currency conversion and inter-scheme interoperability, Mojaloop now enables seamless transactions across different payment networks. This unlocks regional payment systems, supports cross-border trade, and drives financial inclusion on a global scale. This significant update now also supports FX and ISO20022 messaging.

Discover how v17 will shape a more inclusive future for payments: https://brnw.ch/21wRJED

Welcome thread for new members

Samuel Kummary — Tue, 01 Apr 2025 17:50:45 +0000

Welcome to Mojaloop community central!

Feel free to say hi and ask any questions that can help you get onboarded on to Mojaloop!

Call for System Integrators: Join Our April Accelerator Program Cohort

Simeon Oriko — Mon, 17 Mar 2025 07:28:50 +0000

Applications are now open for the Mojaloop Foundation’s new Accelerator Program virtual cohort. Starting in April, this cohort is designed specifically for system integrators who are ready to expand their skills and make a lasting impact in the fintech and payments sectors.

The Mojaloop Accelerator Program is a comprehensive training program aimed at building a robust network of local System Integrators (SIs) that supports the deployment, customization, and maintenance of Mojaloop-based Instant and Inclusive Payment Systems (IIPS) across Africa and beyond.
Participants will gain practical skills, engage with Mojaloop workstreams, and collaborate on solutions that promote financial inclusion.

Learn more about the program in our recent blog, and join our information session on Wednesday, 27 March 2025 for more details on the April cohort.

Applications are due on Friday, 4 April at 11:59 PM UTC.

Apply Now

Adapting for Impact: Strategic Shift for vNext

Paul Makin — Mon, 23 Dec 2024 09:57:09 +0000

The Mojaloop Foundation has been diligently working to make vNext a potential release candidate, as outlined in Paul Makin's "Process Towards vNext Adoption”. Significant progress has been made since the release of the Beta code, thanks to the dedicated efforts of ThitsaWorks in addressing tasks from the structured list created to guide vNext toward release candidate status. Their contributions include improving definition documents, unit testing, and the deployment process.

Why the change?

At the same time, challenges have surfaced:

Resource Constraints: Despite ThitsaWorks’ efforts, advancing vNext has been constrained by a scarcity of dedicated resources.
Refinement of vNow: In the intervening time since the inception of vNext, the previously identified limitations of the vNow codebase, such as in the area of performance, have largely been addressed, strengthening vNow’s foundations.
Momentum of vNow: With deployment projects under way with the vNow codebase, and many potential adopters showing strong interest in deploying Mojaloop—evidenced by the participation of 15 Central Banks at the recent Mojaloop convening in Kigali—the reality is that new features are being developed for vNow. This further compounds the functional gaps between vNow and vNext, with features like ISO 20022, foreign exchange and interscheme support being planned for migration to vNext, further impacting timelines for vNext’s readiness for production beyond the previously-identified issues around code readiness and documentation.
TigerBeetle’s Integration: Initially envisioned as a key benefit of vNext, this integration has not been completed, and the TigerBeetle team has now committed to integrating TigerBeetle directly into vNow.

Taken together, these factors have prompted a re-evaluation of the strategy for vNext.

What’s the new strategy?

To ensure resources are used effectively and align with customer needs, the Foundation is introducing a revised approach:

Feature, Component, and Principle Migration: vNext itself is not being abandoned, instead its strengths will be incorporated into vNow over time. Features, technical components, and principles incorporated into vNext will be analyzed for their potential to enhance vNow. For example, security improvements and concepts from the various portals will be prioritized for migration. This ensures that vNext’s innovations continue to inform and improve Mojaloop. Two dedicated workstreams have been established to oversee this process:
- “Mojaloop Evolution” will focus on identifying those vNext elements that would most benefit Mojaloop, and refactor them for the vNow codebase. This workstream will comprise members from the Mojaloop Community.
- “TigerBeetle Integration” will be dedicated to integrating TigerBeetle into the Mojaloop central ledger, and exploring new approaches to settlement. As well as members from the Mojaloop Community, this workstream will be supported by the TigerBeetle team.

All analyses and implementations will be reviewed by the Design Authority (DA) before coding begins.

Continuous Reference Architecture Review: Insights from the vNext development process have underscored the importance of evolving the approach to reference architecture reviews. Moving forward, each impactful new feature implemented in Mojaloop will prompt a re-evaluation of the reference architecture to identify opportunities for improvement. A catch-up process will also address recently implemented features like foreign exchange to assess their architectural implications.

The Mojaloop Community will continue to operate a stable roadmap and release programme which adopters can rely on and plan around, while focusing available resources on the most impactful changes. This strategy has been approved by both the Mojaloop Technical Governance Board (TGB) and the DA.

The Foundation is actively seeking community members eager to contribute to strengthening Mojaloop and driving continuous improvement of the platform.

If you are interested in joining either of the new workstreams, please refer to the details below:

For any questions or to explore opportunities to contribute, please contact James, Paul, or Julie.

2024 Community Governance Elections

Simeon Oriko — Mon, 18 Nov 2024 12:56:25 +0000

Nominations for the Mojaloop Community Council and Change Control Board, as well as voter registration, are now open. Community members have until Friday November 22 to either nominate someone or self-nominate for the available positions and register to vote. A complete election timeline is provided below.

The Design Authority elections were held earlier this year in order to start working under the new DA charter as soon as possible. Results will be announced soon.

To qualify to make a nomination or vote in this election, you must have been an active contributor to the Mojaloop Open Source Software, and/or the Mojaloop ecosystem for at least one year.

Qualifications for Community Council

The Community Council serves as the Mojaloop Community’s governing body, tasked with setting strategic goals and resolving any conflicts that arise.

Council members will serve a one-year term, with the option for re-election.

To be eligible to run for a seat, candidates must demonstrate a strong understanding of the Mojaloop Community and ecosystem. You will also need to be an active contributor to Mojaloop’s mission and abide by the Mojaloop Community Code of Conduct.

Change Control Board Qualifications

The Change Control Board (CCB) plays a key role in advancing the adoption of the Mojaloop Specification. Its focus is on enhancing clarity, ensuring consistency across implementations, balancing current implementations and future changes, and reducing both deployment and maintenance costs. The CCB is also responsible for protecting the integrity of the Mojaloop family of API specifications, ensuring they align with the Level One Principles.

Members of the CCB will serve a one-year term, with the possibility of re-election.

To be eligible for a seat on the Change Control Board, candidates must demonstrate a solid understanding of the Mojaloop codebase and have been actively engaged in workstreams for at least a year before their nomination. You will also need to abide by the Mojaloop Community Code of Conduct.

The Change Control Board is offering one position for election, the CCB Rapporteur, who must meet the following qualifications:

Should be an expert in financial services (DFSP expert).
Thorough understanding of Mojaloop Design Principles.
Thorough understanding of Level One Principles.
Thorough understanding of Mojaloop family of APIs (FSPIOP, settlement, Administration, 3PPI, reporting).
Ability to understand product requirements from Mojaloop adopters, implementers (including potential ones) and translate them into designs, APIs, technical requirements as needed.
Ability to understand technical designs and implementations to ensure alignment with Mojaloop specifications.
Ability to critically analyze change requests proposed to provide reviews and feedback.
At least a year of presence in the Mojaloop Community.
Time commitment to do these for the required duration (one year).
Commitment to the Mojaloop Code of Conduct and other policies.

Timeline

The following timeline details the dates and milestones in the election and transition process:

Call for nominations and registration to vote: November 15 – 22, 2024
Voting period: December 9 – 13, 2024
Announcement of election results: January 6, 2025
Transition week: January 6 – 10, 2025

Register and Make Nominations

The Mojaloop Community has had an incredibly productive year, thanks in large part to the dedicated members of the Community Governance Committees. Your involvement and contributions have been invaluable. Now, it’s time to elect new leaders to guide these groups forward.

Please fill out this form to register to vote in the Mojaloop Community Governance Elections and to nominate or self-nominate representatives for the two committees.

We look forward to your active participation in this process. If you have any questions about this process, please contact Simeon Oriko at soriko@mojaloop.io.

MOJA101 and SCHEME101 Training Courses Updated

Simeon Oriko — Thu, 17 Oct 2024 04:17:25 +0000

If you’re curious about how Mojaloop works, we’ve recently updated two courses with the help of payments experts Glenbrook Partners. These updates incorporate new terminology and fresh content to reflect changes in the market — we’ve also improved the user experience.

Our courses are open to anyone interested in how Mojaloop works, and are available online for free. You can find a detailed course structure guide on our training page that explains the goals and intended audience for each course.

MOJA 101

MOJA 101 is the Mojaloop Training Program’s foundational course, designed to give you a thorough introduction to Mojaloop, including its origins and purpose. The course is intended for all audiences and is divided into two sections.

In the first section, you’ll explore the fundamentals — starting with instant (or “real-time”) payments, key terminology, and the benefits associated with these systems. It also introduces the Level One Project, which serves as a framework for discussing inclusive instant payments and creating financial systems for everyone, regardless of income level.

The second section dives deeper into the roles and responsibilities of the various groups involved in building a system aligned with the Level One principles. It clarifies each participant’s role and how they collaborate within the broader ecosystem.

SCHEME 101

This non-technical course offers an in-depth exploration of Mojaloop-based payment systems, known in the industry as “schemes.” You’ll gain a comprehensive understanding of the structure and components of a scheme, including its ownership model, participation framework, and the process for developing scheme rules. Additionally, the course covers the business rationale for establishing and managing a scheme, along with practical steps for implementation.

While the SCHEME 101 course is open to all, it is specifically designed for individuals directly involved in creating a scheme, as well as advisors and advocates promoting the adoption of Mojaloop payment schemes in their region. Learners are encouraged to complete MOJA 101, the introductory course in the Mojaloop Training Program, before diving into SCHEME 101.

Courses Now Available in Our Training Program

The Mojaloop Foundation provides a comprehensive training program at no cost. Visit our training page for an in-depth look at the courses, along with a diagram designed to help you identify the ideal starting point based on your role.

Explore Our Two New Mojaloop Training Program Courses: HUB 204 & DFSP 204

Simeon Oriko — Mon, 30 Sep 2024 12:20:58 +0000

Introducing two new courses in our free Mojaloop training program: Hub 204 and DFSP 204. These courses feature brand-new content and build on our existing training roadmap, designed to deepen your understanding of Mojaloop.

While our courses are open to anyone interested in how Mojaloop works, these two are specifically tailored for professionals in key roles within hub operators and financial institutions. On our training page, you’ll find a detailed breakdown of the roles each course is designed for — whether you’re a business owner, project lead, technical architect, or developer.

HUB 204: Hub Security Overview

Ideal for security professionals and system architects, this course equips you with the knowledge to manage and enhance Mojaloop’s hub security.

The course is tailored for professionals focused on securing Mojaloop’s payment hub infrastructure. It provides a deep dive into the core secure design principles that extend beyond the Mojaloop switch and offers a detailed overview of the Mojaloop hub security architecture.

Participants will explore the operational processes and safeguards needed to maintain hub security and compliance. You’ll also learn how Mojaloop implements authentication, authorization, and secure communication protocols. The course covers how transaction flows are protected within the Mojaloop ecosystem, ensuring data confidentiality, integrity, and non-repudiation. Additionally, it outlines the essential requirements for securely onboarding digital financial service providers (DFSPs).

DFSP 204: Mojaloop DFSP Security Overview

This course delves into the Mojaloop security architecture and is designed for integration architects and operations teams at DFSPs. Participants will gain deep insight into the security protocols and controls adopted by DFSPs operating within a Mojaloop hub.

The course explores key processes and technical requirements for securely connecting your systems to the Mojaloop hub while understanding the DFSP’s role in maintaining security and non-repudiation across transactions.

By the end of the course, participants will have a clear understanding of a DFSP’s responsibilities in securing transactions and ensuring integrity. They will also understand DFSP security controls within the Mojaloop hub and be able to navigate the integration steps and security measures for DFSP connection.

Find These Courses in Our Training Program

The Mojaloop Foundation offers a full training program — available for free. Our training page provides a complete overview of the program, and a diagram to make it easier for you to decide the best place to start for your role.

New Design Authority (DA) Charter

Simeon Oriko — Mon, 16 Sep 2024 15:00:25 +0000

In recent months, the Technical Governing Board (TGB)convened a task force led by @bushj to re-examine the DA charter. This process involved soliciting input and feedback from across the Mojaloop community.

That process has concluded with the TGB recently voting to accept the proposed changes. See announcement on the [Mojaloop Blog here](https://mojaloop.io/new-design-authority-charter-2024/

Overall, the new charter better reflects Mojaloop’s alignment with the best practices at world-class software development companies that ensure reliability, resilience, security, and regulatory compliance. There is also more emphasis on the close working relationship with the Product Council and ensuring that any changes to Mojaloop reflect the wider financial services and regulatory landscape. The new charter also provides more detail about the requirements for technical and business risk management processes, as well as end-to-end traceability, that will streamline future audits by regulatory authorities.

You can read the complete text of the new Design Authority charter here.

Path to release quality

Samuel Kummary — Mon, 29 Jan 2024 09:47:30 +0000

Mojaloop guidance on the path from Experimental, Alpha / Beta (quality, processes) to release quality:

Documentation
- Readme page of all repos to follow the template and provide for sections where applicable:
- Overview of functionality
- Instructions to run the service independently
- Instructions to run tests
- Configuration options (env variables, etc to be set)
- Known issues
- Links to documentation for details on product features, functionality
- FAQs
- Sequence diagrams with varying level of detail
- Detailed deployment documentation, stand-alone and where applicable with/alongside Mojaloop platform
Continuous Integration, Continuous Deployment (CI/CD) steps to include
- Unit tests with coverage following Mojaloop standards
- Integration tests
- Functional tests (if applicable)
- Lint checks: link: https://docs.mojaloop.io/community/standards/guide.html#config-files (eslintrc.js)
- Code coverage check (limit doesn’t have to be 90% for Beta, can be lower)
- Vulnerability checks
- Image scan
- License checks / audit
- Note: Can use existing template on other current release level repos for reference
GitHub
- Main branches to be protected (Primary branches to be named “main”)
- PR tiles to use “conventional commit” standard (integrated with CI/CD) (Link: - - https://docs.mojaloop.io/community/standards/creating-new-features.html )
- Codeowners to be added to all repos part of the core platform
- Codeowners approval required for merges
- No skipping CI steps for commits in general
Project issues
- Issues to follow story template
- Well defined acceptance criteria required
- Acceptance criteria and priority of issues to be confirmed during prioritization / refinement meetings with input from Product (owners/managers).
- Encouraged to use: size estimate, task list, sprint / milestone, release, Epic
- Stories to have information needed to navigate through changes needed on GitHub repos (Links to PRs, etc)
- Issues to be closed after Product Owner confirmation
- All artifacts, design decisions to be publicly available on Mojaloop GitHub
Releases & Testing
- Helm charts needed for all services
- Need well defined test collections along with provisioning collections that cover all the features supported.
- Release notes to contain (at a minimum):
- High level summary
- API versions supported
- Individual service versions (with links)
- Bug fixes
- Testing instructions
- Known issues
- Breaking changes if any
- Release cadence to be discussed with Release co-ordinators and Product teams.
- Assess deployment options prior to releases and ensure tests, deployment instructions are in-line with releases as they’re made.

Contribute to create new courses for the Mojaloop Training Program and update existing ones

Simeon Oriko — Mon, 22 Jan 2024 13:40:02 +0000

The Mojaloop Foundation’s Training Program is taking a significant leap forward, and we want our vibrant Community to be a part of this journey.

The Mojaloop Community is thrilled to announce new opportunities for members to contribute to our course development — an initiative that not only supports the growth of Mojaloop but also empowers you, as a Community member, to share your knowledge and expertise.

We’re looking for teams to:

Revamp existing courses with fresh insights (you can find the full descriptions on our Training Courses page):

MOJA 102 — Expands on MOJA 101 and covers fundamentals of the DFSP interoperability API.
MOJA 103 — Gives you a deeper understanding of how Mojaloop works from a technical perspective, focusing on the open source side.
MOJA 104 — Shows how Mojaloop solves issues related to confidentiality, integrity, and security of payment processing.
Scheme 101 — Provides a non-technical but detailed look at Mojaloop schemes including ownership, participation, rules, and the business case for operation.
DFSP 101 — Explores why a digital financial service provider (DFSP) should use Mojaloop, and a variety of considerations for business and project owners.
DFSP 209 — Builds on DFSP 101 to provide practical steps for performing technical operations (TechOps) support functions.
HUB 101 — Explores the architecture of Mojaloop and explains the interplay between the scheme, the hub, and the platform.
HUB 209 — Provides an overview of the Mojaloop tools, processes, and operations for hub operators or potential hub operators.
TTK 101 — Reviews the basic features of the Mojaloop Testing Toolkit (TTK) and its usages.

Craft entirely new training modules:

Executive Series Courses — Provides potential adopters with adequate information to make decisions on Mojaloop deployments.
HUB204 — Provides an overview of Mojaloop security and security operations for hub operators or potential hub operators.
DFSP 204 — Provides DFSPs an overview of Mojaloop security and security operations.
Third-party payment initiation (3PPI) / Payment Initiation Service Provider (PISP) — Reviews roles and functionality of Third-Party Payment Initiation (3PPI) and Payment Initiation Service Providers (PISP) in Mojaloop.

No matter which type you choose, your contribution can make a monumental impact. Imagine your work helping to shape the skills and knowledge of others in the world of financial technology.

Who We’re Looking For

Are you part of a team of dynamic experts? Do you have unique insights into digital financial service provider (DFSP) implementations or deep knowledge of hub operations? Now’s the time to step forward. Your voice and expertise can help shape the future of digital financial services.

Join us on this exhilarating path of community driven education. Dive into the details of our bidding process, understand the content requirements, and learn how your work will contribute to a larger goal — a more inclusive and efficient digital financial ecosystem.

These opportunities are open to Mojaloop Community members and also to non-members, as long as they have extensive knowledge about Mojaloop software. We are also offering payment for successful completion of course work:

Up to $1,500 for updates to existing courses.
Up to $3,000 for the creation of new courses.

Important Dates

Bid Submissions: 22nd January to 9th February 2024
Bid Reviews: 12th February to 23rd February 2024
Announcement of bid winners: 26th February 2024
First Workstream Call with all bid winners: 29th February 2024

If you’re not already a part of the Mojaloop Community you can learn more about joining our community and our training program.

Let’s build something remarkable together. Sign up via our form to start your journey as a Mojaloop course contributor!