/
2026-04-15 Meeting notes

2026-04-15 Meeting notes

 Date

Apr 13, 2026

 Participants

  • Kibuuka, Arnold

  • Mauree, Venkatesen

  • David Higgins

  • Ali González

  • Elie Sawaya

 Goals

  • Review Payments Building Block specification alignment with GovSpec 2.0 architecture

  • Discuss composability approach for the Payments BB specification

  • Understand new requirement classification (observability and mutability)


  •  Brainstorm

  • Should the Payments BB be decomposed by use case (G2P, P2G, G2B, B2G) or by feature/functionality (vouchers, bulk processing, mobile money, etc.)?

  • What constitutes the “core” of the Payments BB given the financial inclusion mandate?

  • How to attract additional solution providers beyond Mutepfa?

 Discussion topics

Topic

Presenter

Notes

Topic

Presenter

Notes

Composability of Payments BB

David Higgins

  • Payments BB is one of the largest specs with the most requirements; difficult for solution providers to be 100% compliant.

  • Proposed a core + composable modules approach: core requirements for interoperability, plus optional feature modules (vouchers, account mapper, multi-currency, bulk processing, etc.).

  • Feature-based decomposition preferred over use-case-based, as it avoids requirement duplication and aligns with how solution providers think.

  • Use cases (G2P, P2G, etc.) would become appendices mapping to required feature modules rather than standalone spec sections.

Financial inclusion vs. composability


Mauree, Venkatesen

  • Voucher payments are essential for financial inclusion (enabling people without bank accounts to receive payments).

  • Concern: labelling vouchers or account mapper as non-core could undermine the original financial inclusion goals of the Payments

  • David added composability does not remove functionality; it lets implementers select the modules relevant to their context.

GovSpec 2.0 requirement classifications

Ali González

  • New classifiers: observability (testable vs. auditable) and mutability (extensible or not).

  • A parsing script has been built that converts current specs into a JSON structure (array of functionalities → array of requirements). Available in the architecture repo.

  • Parsed JSON highlights where observability and mutability values are missing (null). These gaps need to be filled.

  • Ali offered to convert the JSON into an Excel table to make it easier for the group to fill in missing fields.

  • Cross-functional requirements in the current spec do not match GovSpec 2.0’s definition; same issue exists across most BBs.

New spec template

Ali González

  • The old template led to a faulty compliance structure. A new template is being developed this quarter.

  • Ali is working with Payments, Workflows, Registrations, and Cross-functional ID working groups to co-develop the template

  • Template will be structured around composable functionalities, each with requirements that include observability and mutability.

Ethiopia international payments paper

Elie Sawaya

  • Paper on international payments for Ethiopia is being finalized; needed input from the social transformation cluster.

  • Expected to be ready for circulation and discussion by next week.

 Action items

@All – Review the parsed JSON file (shared by Ali in Teams chat) and the GovSpec 2.0 architecture spec before the Monday meeting
Kibuuka, Arnold – Send a meeting invite for Monday, Apr 20, 2026 at 4:00 PM CET to discuss what constitutes the core requirements. Confirm Oscar’s availability.
Ali González – Convert the parsed JSON requirements into an Excel table for the group to fill in the missing observability and mutability fields.
David Higgins – Share the Confluence link for the registries cross-functional requirements draft as a reference example. Cross Cutting Requirements Analysis | Proposed CFR section starting point based on this:
Elie Sawaya – Finalize and circulate the Ethiopia international payments paper by next week.

 Decisions

  1. The group will pursue a composability approach for the Payments BB specification (core + optional feature modules), but the exact definition of “core” still needs to be agreed upon.

  1. Feature-based decomposition is the preferred direction over use-case-based decomposition, to avoid duplicating requirements across sections.

  1. Use cases (G2P, P2G, G2B, B2G) will be retained as appendices/implementation guides that map to the relevant feature modules.

  1. The group will meet Monday, Apr 20, 2026 at 4:00 PM CET to finalize what belongs in the core.

 Related info

https://specs.govstack.global/architecture/5-specification-framework/5.3-requirements-model

https://codeberg.org/categulario/bb-spec-artifacts/src/branch/main/artifacts