Business Process Workstream

Architectural Workstream

  • Workstream Purpose:
    • Reference Architecture: What the characteristics of the Mojaloop core system (features)
    • Baseline: What do we support today
    • Component Dependencies: How can we effectively plug in new components (TigerBeetle)
  • Approach
    • Identify Core components/features
    • Determine what we have now – roadmap of new technology investments
    • Identify model for taking component dependencies
  • Progress/Next Steps
  • Determine the Reference Arch
    • Do we have this now (baseline)
    • Is it part of the reference arch

Code Quality Workstream: PI 13 Objectives

  • Enhance security in functionality workstreams – FRM, PISP and Business Process workstream will be the area of focus for this PI.
  • Support major implementations – Mowali GDPR on hub operations and assist architect their AML requirement with an interim solution.
  • Improve data protection measures and controls – Logging, Secure Auditing and Forensics
  • Baselining of Mojaloop against industry standards – CIS benchmark on K8 security and OpenSSF alignment
  • Maintain and enhance secure DevOps/CI-CD practices – Continuous support and enhancements.
  • Improve communication and community engagement – Review the MBX training and align it with our documentation messaging.
  • Improve access control measures – IAM Model review and re-architecture.
  • Tackle infrastructure security starting with a cloud-based PAAS Model – Establish K8 security standard and policies and a reference implementation on AWS.
  • End to end Hub Security Monitoring – Establish a security monitoring framework for a Mojaloop based hub operations.
  • Test approved standards in a lab environment – Internal testing of security configurations in the CQS lab.
  • Support Overall Mojaloop Product Roadmap from the Product Counsel – Mainly demonstrate our security model in both a closed user group setup and a sandbox environment.

PISP: PI 13 Objectives

Core: PI 13 Objectives

  • Make Helm release v12.0.0
  • Continue follow-up on CGS feature to separate Rules Engine and other standardization (apply ML OSS standards)
  • Admin API standardization and initial API definition documentation
  • Reliable notifications – detailed design and implementation upon approval by DA
  • Cascaded timeouts design (for review by DA)
  • [Stretch] Helm enhancement – separate external dependencies

Testing Toolkit: PI 13 Objectives

  • Ability to distribute TTK as native desktop application for OSX, Linux and Windows platforms
  • Demonstration capabilities to demonstrate PISP, Settlement, Merchant Request to Pay and show accounts balances using TTK (in addition to P2P that is currently supported)
  • Improve reliability and coverage of tests (ensure results are always in sync with backend, frontend and results are consistent across runs)
  • Ability to use TTK as an FSP interacting with a Hub over mTLS​ (to support deploying TTK in a separate cluster) [dependent on payment manager OSS]
  • [Stretch] Automatic API provisioning for async APIs​ – ability to map callbacks and other config needed to onboard asynchronous APIs to the TTK for use
  • General maintenance and releases