diff --git a/docs/product/features/ml-feature-list.md b/docs/product/features/ml-feature-list.md index 3f5c3ea5..efec417a 100644 --- a/docs/product/features/ml-feature-list.md +++ b/docs/product/features/ml-feature-list.md @@ -65,7 +65,7 @@ Around the core illustrated in the above diagram there are a set of overlay serv - **ISO 8583 integration**, which allows ATMs (or an ATM switch) to be integrated with a Mojaloop Hub, for cash withdrawals; - [**MOSIP integration**](https://www.mosip.io), which allow payments to be routed to a MOSIP-based digital identity, rather than (say) a mobile phone number. -# Feature List +## Feature List This document presents a feature list which covers the following aspects of Mojaloop: @@ -87,6 +87,12 @@ This document presents a feature list which covers the following aspects of Moja - [**Invariants**](./invariants.md), setting out the development and operational principles to which any Mojaloop implementation must adhere. This includes the principles which ensure the security and integrity of a Mojaloop deployment.   +## Continuous Development +No software is ever finished, and Mojaloop is no exception. There are always new features to be considered, new APIs to be implemented, new portals to be added, and of course there is always ongoing maintenance, and security requires constant vigilance. + +The Mojaloop Roadmap addresses and prioritises these needs, placing them on a timeline, and defines them as a set of workstreams. Each of these work streams has a workstream lead, responsible for defining, managing and delivering the workstream to the Mojaloop Community. The workstream lead is supported by a number of contributors, who may be engineers helping to implement a feature, or those who can document the feature, or people helping to define the requirements. + +You can view the current set of workstreams and their latest status reports in the [**Continuous Development** section](./development.md). # About This Document @@ -106,6 +112,7 @@ This version of this document relates to Mojaloop Version [17.0.0](https://githu ## Document History |Version|Date|Author|Detail| |:--------------:|:--------------:|:--------------:|:--------------:| +|1.5|4th December 2025| Paul Makin|Added the "Continuous Development" sub-section| |1.4|28th August 2025| Paul Makin|Added the "Regulators' and Operators' Perspective"| |1.3|23rd June 2025| Paul Makin|Added the ecosystem text and diagram| |1.2|14th April 2025| Paul Makin|Updates related to the release of V17| \ No newline at end of file diff --git a/docs/product/features/workstreams/core.md b/docs/product/features/workstreams/core.md index 1ed42dd5..b360e53f 100644 --- a/docs/product/features/workstreams/core.md +++ b/docs/product/features/workstreams/core.md @@ -12,9 +12,15 @@ The management of the Mojaloop Core and the releases of the open source platform | Sam Kummary | Shashi Hirugade
Juan Correa | ## Latest Update (Summary) -PI 28 saw the successful delivery of Mojaloop v17.1.0, a clean release with no known vulnerabilities, accompanied by artefact provenance, a full SBOM, and coordinated improvements from related workstreams. +The codebase for 17.2.0 RC passes ~80% of automated tests across eight major collections; remaining tests are blocked by security-related changes to the Testing Toolkit. Once resolved, and once all security vulnerabilities are cleared, the release will proceed. -Looking forward, the team concluded that no breaking release (v18) would be made this year. Instead, work is underway on v17.2.0, a non-breaking enhancement release expected by the end of PI 29. This release will bundle multiple fixes and significantly improved performance at the SDK layer — unlocking up to 10x throughput improvements. In collaboration with the Performance Optimisation workstream, a key goal is to tie measurable performance outcomes to a specific release version, supported by reproducible testing scripts and metrics dashboards. The workstream also responded rapidly to a breaking upstream change by Bitnami, implementing a short-term fix and designing a long-term solution to restore Helm chart stability. +Version 17.2.0 will deliver: +- Major performance enhancements +- LEI support in merchant services +- Inclusion of Connection Manager in Helm +- Significant DRPP-originating bug fixes + +The team will evaluate in early 2026 whether the next release will be a minor revision or the TigerBeetle-based v18. ## Applicability @@ -23,4 +29,5 @@ This version of this document relates to Mojaloop [Version 17.1.0](https://githu ## Document History |Version|Date|Author|Detail| |:--------------:|:--------------:|:--------------:|:--------------:| +|1.1|4th December 2025| Paul Makin|Added latest update| |1.0|25th November 2025| Paul Makin|Initial version| \ No newline at end of file diff --git a/docs/product/features/workstreams/deployment.md b/docs/product/features/workstreams/deployment.md index 5497878d..38f3212c 100644 --- a/docs/product/features/workstreams/deployment.md +++ b/docs/product/features/workstreams/deployment.md @@ -12,7 +12,7 @@ The aim is to enable adopters to deploy Mojaloop easily, in the environment of t | James Bush | Tony Williams
Vanda Illyes
Sam Kummary
Paul Makin
Paul Baker
Michael Richards| ## Latest Update (Summary) -The Deployment Tools workstream focused on addressing a gap that emerged from increased IaC complexity: many schemes don’t require DRPP-scale infrastructure and are now underserved by the current deployment model. In response, the team began design of “IaC Lite,” a simpler, lower-cost deployment solution for production-quality Mojaloop environments. Early architecture work targets Proxmox (on-prem virtualisation), AWS, and GCP (GKE) — ensuring cloud-agnostic extensibility. Initial Terraform modules are under test in Mojaloop’s on-prem lab, and the team aims to release a community-testable version by end of November. Meanwhile, improved Helm charts are being developed and exercised through the performance and evolution workstreams, reflecting strong cross-stream alignment. +Recent DRPP contributions to IaC increased infrastructure costs by optimising for high-scale multi-instance deployments. To address the needs of smaller schemes, the team has developed a lightweight alternative—provisionally “IAC Lite.” Test deployments are running in AWS and on Foundation lab equipment. The objective is to deliver a streamlined, low-overhead, open-source deployment experience requiring minimal manual steps. ## Applicability @@ -21,4 +21,5 @@ This version of this document relates to Mojaloop [Version 17.1.0](https://githu ## Document History |Version|Date|Author|Detail| |:--------------:|:--------------:|:--------------:|:--------------:| +|1.1|4th December 2025| Paul Makin|Added latest update| |1.0|25th November 2025| Paul Makin|Initial version| \ No newline at end of file diff --git a/docs/product/features/workstreams/dispute.md b/docs/product/features/workstreams/dispute.md index 1f70c231..a68dbacc 100644 --- a/docs/product/features/workstreams/dispute.md +++ b/docs/product/features/workstreams/dispute.md @@ -12,9 +12,7 @@ Off the shelf alternatives generally assume that switches operate with limited d | Promesse Ishimwe | Derrick Wamatu | ## Latest Update (Summary) -The approach that was defined in previous PIs was that the best match for Mojaloop's requirements is the dispute management platform that has been developed by Switch, for use with their Mojaloop deployment. Switch then agreed to donate this to the Mojaloop open source, though it was clear that further work would be required to make the code adopter-agnostic. - -However, because of significant pressure on RSwitch to focus their attention on immediate operational matters, this workstream did not progress during PI28. It is hoped that this will be resolved during PI 29, and the process of generalisation can begin. +There was no update from the Dispute Management workstream in this cycle. Promesse was unable to attend the call, and no written update was provided. An update is expected at the next session once the workstream is able to report on current progress and priorities. ## Applicability @@ -23,4 +21,5 @@ This version of this document relates to Mojaloop [Version 17.1.0](https://githu ## Document History |Version|Date|Author|Detail| |:--------------:|:--------------:|:--------------:|:--------------:| +|1.1|4th December 2025| Paul Makin|Added latest update| |1.0|25th November 2025| Paul Makin|Initial version| \ No newline at end of file diff --git a/docs/product/features/workstreams/evolution.md b/docs/product/features/workstreams/evolution.md index b42416d5..cef5f646 100644 --- a/docs/product/features/workstreams/evolution.md +++ b/docs/product/features/workstreams/evolution.md @@ -12,7 +12,14 @@ This workstream has strategic importance; TigerBeetle is the next generation led | Michael Richards | James Bush
Lewis Daley
Sam Kummary
Paul Makin | ## Latest Update (Summary) -PI-28 marked a pivotal phase in Mojaloop’s architectural roadmap, as the core ledger refactor toward TigerBeetle integration continued. Designed to overcome throughput bottlenecks caused by SQL locking in MySQL, TigerBeetle offers event-driven, concurrency-safe ledgering with expected performance exceeding 10,000 TPS per participant — enough to support national-scale cashless economies. Work is being led by Lewis Daly, who also introduced deterministic testing into the core ledger codebase, enhancing verification under edge-case conditions. A production-ready TigerBeetle release is projected for Q1–Q2 2026. In parallel, the workstream revisited the forensic audit trail architecture, prompted by DRPP’s high-throughput requirements, and has now reached architectural consensus via the Design Authority. +### Forensic Audit +The forensic audit redesign is ready for implementation but awaits funding from forthcoming adoption projects. No significant progress is expected until mid-Q1 2026. +### New Accounting Model +The new accounting model is broadly agreed and represents a major shift toward alignment with international accounting standards. This addresses concerns raised by global institutions and enhances Mojaloop’s credibility as a financial infrastructure platform. The initial target is TigerBeetle, though the team has not yet decided whether a MySQL version of the new model will also be produced. +### TigerBeetle Integration +Given the accounting model’s increased complexity, TigerBeetle is the preferred ledger engine. Integration planning is underway, with work expected to begin before Christmas. +### Settlement v3 +Settlement v3 introduces deterministic settlement batches, addressing long-standing reconciliation challenges and enabling multi-scheme scalability. TigerBeetle will store settlement batch keys, while SQL components and admin APIs will require substantial enhancement to support model configuration, batch tracking, and settlement operations. ## Applicability @@ -21,4 +28,5 @@ This version of this document relates to Mojaloop [Version 17.1.0](https://githu ## Document History |Version|Date|Author|Detail| |:--------------:|:--------------:|:--------------:|:--------------:| +|1.1|4th December 2025| Paul Makin|Added latest update| |1.0|25th November 2025| Paul Makin|Initial version| \ No newline at end of file diff --git a/docs/product/features/workstreams/fintech_participation.md b/docs/product/features/workstreams/fintech_participation.md index 981dcf30..b670bf5d 100644 --- a/docs/product/features/workstreams/fintech_participation.md +++ b/docs/product/features/workstreams/fintech_participation.md @@ -12,11 +12,7 @@ It is hoped this will foster faster growing and ultimately larger and more inclu | Alain Kajangwe | Jean de Dieu Uwizeye
Bonaparte Ituze
Yvan Rugwe | ## Latest Update (Summary) -This workstream showcased a PISP demo system during September, highlighting integration of the third-party SDK for initiating Mojaloop Request-to-Pay flows in a simulated fintech environment. - -Initial demos used PISP v1 APIs, but the team is now working to upgrade the SDK to support PISP v2, including implementation of missing endpoints. However, PISP v2 is still incomplete on the switch side. Coordination is ongoing with the core PISP stream. While not yet a full-scale workstream, this collaboration is helping converge frontend fintech tooling with backend switch support. - -The next step is to prepare the codebase to be contributed to the Mojaloop open source repository. +There was no update from the Participation Tools for Fintechs (Open Banking) workstream in this cycle. Alain was unable to attend the call, and no written update was provided. An update is expected at the next session once the workstream is able to report on current progress and priorities. ## Applicability @@ -25,4 +21,5 @@ This version of this document relates to Mojaloop [Version 17.1.0](https://githu ## Document History |Version|Date|Author|Detail| |:--------------:|:--------------:|:--------------:|:--------------:| +|1.1|4th December 2025| Paul Makin|Added latest update| |1.0|25th November 2025| Paul Makin|Initial version| \ No newline at end of file diff --git a/docs/product/features/workstreams/lei.md b/docs/product/features/workstreams/lei.md index 465b0795..0c6ef90f 100644 --- a/docs/product/features/workstreams/lei.md +++ b/docs/product/features/workstreams/lei.md @@ -12,7 +12,7 @@ It also helps our credibility in cross-border merchant payments, and complements | Clare Rowley
Ololade Osunsanya | Michael Richards
Paul Makin
Shuchita Prakash
Sam Kummary
James Bush
Xiaodi Wang | ## Latest Update (Summary) -The LEI Addressing workstream has concentrated on preparing a merchant-presented QR code demo for MojaCom 29. The demo shows a merchant identified via a GLEIF-verified LEI, with the system retrieving real-time entity data from GLEIF’s API. Looking beyond the demo, the team plans to explore automated LEI generation during merchant onboarding via the Merchant Registry, and correct population of LEI tags within ISO 20022 message structures. Dialogue has begun with external actors, including CPMI and the financial messaging community, as LEI adoption increasingly intersects with regulatory and scheme-level design conversations. +Documentation is currently the primary focus. The workstream is integrating LEI-related process flows into the Introduction to Mojaloop document, and preparing to collaborate with the ISO 20022 workstream on additional message examples, especially a P2B use case featuring LEI as a beneficiary identifier. Broader questions around applying LEIs to DFSP identities have been deferred due to complexity and regulatory implications. ## Applicability @@ -21,4 +21,5 @@ This version of this document relates to Mojaloop [Version 17.1.0](https://githu ## Document History |Version|Date|Author|Detail| |:--------------:|:--------------:|:--------------:|:--------------:| +|1.1|4th December 2025| Paul Makin|Added latest update| |1.0|25th November 2025| Paul Makin|Initial version| \ No newline at end of file diff --git a/docs/product/features/workstreams/participation.md b/docs/product/features/workstreams/participation.md index d4d9c735..169b16e6 100644 --- a/docs/product/features/workstreams/participation.md +++ b/docs/product/features/workstreams/participation.md @@ -12,9 +12,8 @@ By making it easier for different types of DFSP to join a Mojaloop-based payment | James Bush | Sam Kummary
Yevhen Kryiukha
Paul Baker
Vijay Kumar
Phil Green
Steve Haley
Paul Makin | ## Latest Update (Summary) -The Participation Tools workstream has advanced the long-running effort to refactor and modularise the Mojaloop Connection Manager (MCM). The server component is now fully decoupled from the Mojaloop IaC stack and deployable via Helm into any Kubernetes environment. The onboarding journey has also been re-architected to remove dependency on HashiCorp Vault and Mojaloop’s IAM defaults, allowing standalone, flexible MCM deployments. Only the client-side MCM refactor remains, along with documentation. +The workstream continues to make progress on participant onboarding, driven by improvements to the Mojaloop Connection Manager (MCM). With MCM now decoupled from the IAC codebase, schemes can adopt it independently, broadening its utility. Documentation has emerged as the most urgent need; a dedicated technical writer is preparing comprehensive materials spanning MCM, Payment Manager, and the Integration Toolkit. Donated documentation from Infitx will be generalised for broader community use. New mini-guides have been published to simplify navigation of Mojaloop tooling. -A Docker Compose version of Payment Manager has been developed for smaller DFSPs, and community-facing documentation — including tool selection guidance — has been authored and reviewed. A generalised version of the DRPP system integrator (SI) onboarding guide is planned for future PIs. ## Applicability @@ -23,4 +22,5 @@ This version of this document relates to Mojaloop [Version 17.1.0](https://githu ## Document History |Version|Date|Author|Detail| |:--------------:|:--------------:|:--------------:|:--------------:| +|1.1|4th December 2025| Paul Makin|Added latest update| |1.0|25th November 2025| Paul Makin|Initial version| \ No newline at end of file diff --git a/docs/product/features/workstreams/performance.md b/docs/product/features/workstreams/performance.md index eace8bc7..d8446c1f 100644 --- a/docs/product/features/workstreams/performance.md +++ b/docs/product/features/workstreams/performance.md @@ -10,11 +10,10 @@ A whitepaper that demonstrates how Mojaloop exceeds the performance requirements | James Bush | Julie Guetta
Shashi Hirugade
Sam Kummary
Nathan Delma
Ablipay (Jerome, team)| ## Latest Update (Summary) -The Performance workstream has advanced steadily, having overcome early delays caused by the high cost footprint of Mojaloop’s infrastructure — a by-product of DRPP-driven IaC complexity. These constraints prompted a parallel effort to create IaC Lite (see the Deployment Tools workstream), while the performance team itself resumed tests in AWS with support from the core engineering team. +The workstream achieved a major milestone by reaching 1,000 TPS prior to the Nairobi convening. With replication enabled, throughput remains high (950 TPS). The team is now scaling to 2,000 and 2,500 TPS as part of the performance white paper, which will include concrete hardware sizing recommendations. Early TigerBeetle tests suggest dramatic performance improvement and reduced infrastructure cost. -Throughput-limiting issues in the SDK were identified and resolved, allowing performance tests to proceed, and the team has already demonstrated performance in excess of 1000 TPS, and expects further milestones int he near future. +Long-term storage tiering requirements were flagged as essential for regulatory data-retention obligations in high-volume schemes. -Data from these tests is being collected and analysed as input for a comprehensive performance white paper, intended to guide infrastructure sizing, scaling decisions, and cost-performance optimisation for scheme implementers. ## Applicability This version of this document relates to Mojaloop [Version 17.1.0](https://github.com/mojaloop/helm/releases/tag/v17.1.0) @@ -22,4 +21,5 @@ This version of this document relates to Mojaloop [Version 17.1.0](https://githu ## Document History |Version|Date|Author|Detail| |:--------------:|:--------------:|:--------------:|:--------------:| +|1.1|4th December 2025| Paul Makin|Added latest update| |1.0|25th November 2025| Paul Makin|Initial version| \ No newline at end of file diff --git a/docs/product/features/workstreams/pqs.md b/docs/product/features/workstreams/pqs.md index fa3635a1..81433b9a 100644 --- a/docs/product/features/workstreams/pqs.md +++ b/docs/product/features/workstreams/pqs.md @@ -10,7 +10,7 @@ This ensures the Mojaloop platform quality & security is maintained; vulnerabili | Sam Kummary | Juan Correa
Devarsh Shah
Shuchita Prakash
Shashi Hirugade | ## Latest Update (Summary) -The Platform Quality and Security workstream has maintained its focus on vulnerability management, CI/CD upgrades, and software integrity assurance. Mojaloop v17.1.0 was released with zero known vulnerabilities, and the team resolved high-profile issues such as the Axios vulnerability across libraries and services. All Helm charts now support digital provenance, and a comprehensive Software Bill of Materials (SBOM) is included in release metadata. CI pipelines are being modernised, and the team resumed efforts toward the OpenSSF/FLOSS self-assessment badge. Some objectives, including finance portal refactoring and integration of GitHub’s new code quality tools, remain active backlog items. +The team is working toward a year-end release candidate of 17.2.0, focusing on security hardening, dependency updates, and CI reliability. AI-powered tooling is now generating automated PRs for dependency updates across Mojaloop’s internal packages, significantly reducing manual workload. The Finance Portal requires a more comprehensive rewrite due to outdated technology. The workstream also assessed the Mojaloop IAC sandbox against the new QA Framework. ## Applicability @@ -19,4 +19,5 @@ This version of this document relates to Mojaloop [Version 17.1.0](https://githu ## Document History |Version|Date|Author|Detail| |:--------------:|:--------------:|:--------------:|:--------------:| +|1.1|4th December 2025| Paul Makin|Added latest update| |1.0|25th November 2025| Paul Makin|Initial version| \ No newline at end of file diff --git a/docs/product/features/workstreams/qa.md b/docs/product/features/workstreams/qa.md index 176acc86..09e81547 100644 --- a/docs/product/features/workstreams/qa.md +++ b/docs/product/features/workstreams/qa.md @@ -15,9 +15,7 @@ A QA Framework provides a consistent approach for stakeholders to assess the qua | Moses Kipchirchir | Denis Mariru
Brian Njoroge
Ei Nghon Phoo
Sam Kummary | ## Latest Update (Summary) -The team presented at MojaCom 29 and aims to position the QA self-assessment framework as a permanent component of Mojaloop implementation guidance. - -The QA Framework workstream reached its first delivery milestone with the rollout of a complete QA framework to adopters. The intent is now to validate the framework in a live environment before scaling it to wider adoption. +The draft QA Framework is now published on GitHub and Slack and available for immediate use by the community. Feedback from adopters will shape future refinement. Early discussions explore the possibility of an automated version of the framework to assess deployment quality as part of the deployment pipeline. Full automation remains a longer-term goal. ## Applicability @@ -26,4 +24,5 @@ This version of this document relates to Mojaloop [Version 17.1.0](https://githu ## Document History |Version|Date|Author|Detail| |:--------------:|:--------------:|:--------------:|:--------------:| +|1.1|4th December 2025| Paul Makin|Added latest update| |1.0|25th November 2025| Paul Makin|Initial version| \ No newline at end of file