Deployment

Deployability via container

Interface

Fulfillment of Service API requirements

ALL in 23Q4 specification

Fulfillment of REQUIRED API related requirements in the Architecture BB specifications (ch. 5.1, 5.3, 5.4, 5.6, 5.13)

missing reference

Requirement Specification

Fulfillment of REQUIRED Key Digital Functionalities stated in the respective BB specifications

14/15 with 1 accepted deviation = ALL

Fulfillment of REQUIRED cross-cutting and functional requirements stated in the respective BB specifications

ALL cross cutting requirements
14+/17 functional requirements sections. See detailed breakdown below

Fulfillment of REQUIRED cross-cutting requirements stated in the Architecture BB specifications

15/16 Required

1 required being reviewed.

Must be deployable via container

Compliant

4.1 Payment Orchestration - Payments orchestration provides for end-to-end workflow across different sub-subsystems, enables asynchronous processing, and covers different payment types, use cases, account systems, and channels.

Mifos Payment Hub - EE contains customisable BPMN workflows

4.2 Voucher Management - The Payment Building Block will provide a voucher management system which is responsible for provisioning, storage, issuance, activation, redemption, validation, suspension, unsuspension, purging, and reporting on vouchers.

Voucher Management API to allow for voucher sub-systems implemented

4.3 Account Lookup Services (Account Mapper) - The account lookup directory service identifies the Financial Service Providers (FSP) where the merchant/agent/payee’s account is located.

The account lookup directory service or mapper simplifies payment routing and is an important component to avoid storing the payment information of the user in the social registry system and preserve the privacy and confidentiality of sensitive information pertaining to the beneficiary.

ID Account Mapper provides this functionality

4.4 Payment Request Initiation - The Payment Building Block must allow systems to initiate a payment request. This request could come from two sources: external or internal. An external source could be another GovStack Building Block (e.g. the Registration Building Block or Social Benefits Registry Building Block or Payroll).

Allows for source BB’s such as Registration via the IMBB to to initiate payment requests

4.5 Payment Gateway - The Payments Building Block should provide a payment gateway which allows different (digital) Financial Service Providers (FSPs) to interoperate.

Multiple DFSP’s or Switch’s can work with the Payment Hub EE solution.

4.6 Payment Portal - The Payments Building Block should provide a Payment Portal which allows users to manage thje full lifecycle of sending and receiving payments

Admin interface provided showing payment lifecycle

4.7 Event Management - The Payment Building block must support different events related to triggering specific actions on payment outcomes such as issuing receipts upon successful payment, automating payments in case of bulk transactions, passing information to other Building Blocks as necessary, and handling exceptional cases for instance user/system errors amongst others.

Supported

4.8 Reconciliation - The Payments Building block must implement functionality that provides both internal and external reconciliation services.

Both internal and external reconciliation is supported

4.9 Batch Processing - The Payments Building Block should provide batch processing services

PH-EE supports batch processing.

4.10 Scheduling Services - The Payments Building Block should provide scheduling services to perform tasks on a regular or repeated basis

Agreed by Payments Building Block to be covered by Scheduling BB.

4.11 Event Logging - Each component of the Payments Building Block should be capable of producing both application and transaction logs. This is important to ensure that the system can be adequately monitored and troubleshooting can be performed efficiently and effectively.

Logging in place

4.12 Audit Logging - Audit trails are required to provide assurance of the integrity of the requests received and actions taken on these requests. An audit trail is a chronological record of system activities that is sufficient to enable the reconstruction and examination of the sequence of environments and activities surrounding or leading to an operation, procedure, or event in a transaction from inception to final results.

Audit capabilities in place

4.13 Reporting Services - The Building Block should provide reporting services, which may consist of dashboards or analytics reports. These reports should be configurable based on user needs.

Supported through Kibana dashboards

4.14 Security Layer - The Payments Building Block must provide a security layer which protects the system at the transport and application levels. It provides the necessary APIs for encrypting the data in transit and when stored as well as the digital signatures used for API authentication.

4.15 Bulk Payment service - The Payments Building Block must provide bulk payment services. This bulk payment service is invoked in the case of G2P bulk disbursement.

Support for bulk/batch payments included

5.1.1 External Identification, Registration, and Enrollment Logic (REQUIRED)

The Payments Building Block assumes that all identification, registration, and enrollment logic is done externally and are compliant with regulated payments and banking systems within a jurisdiction.

PH-EE complies with this.

5.1.4 Statutory and Operational Requirements (REQUIRED)

The Payments Building Block assumes that the statutory and operational requirements around accounts (i.e. know your customer/anti-money laundering/counter-terrorist financing) must have been completed by an outside system, which is capable of communicating that status in appropriate timeframes.

PH-EE complies with this

5.1.6 Validation (REQUIRED)

The Payments Building Block should have the ability to validate against a set of external systems for the status of an account, account address and routing information, confirmation of payment, and various error conditions of accounts and specific payments.

PH-EE complies with this

5.1.9 Budget Availability (REQUIRED)

Budget availability must be checked before voucher creation is requested.

The PH-EE solution does this

5.1.11 Payment Systems (REQUIRED)

Payment systems in the market, either provided by a public entity, a quasi-public entity, or a purely commercial player, are required for the functioning of this Building Block

The PH-EE requires a payment system in order for end-end transactions to occur.

5.1.12 Settlement (REQUIRED)

Settlement (gross or net) must be handled externally to this Building Block

Whilst the PH-EE supports the settlement process, settlement is external.

5.1.13 Security (REQUIRED)

The Payments Building Block must meet the security requirements described in the Security Building Block.

The PH-EE solution has documented security process’s and procedures and deployment guides.

5.1.14 API Mechanisms (REQUIRED)

The Payments Building Block should meet the mechanisms for consuming and publishing APIs as described in the Information Mediator Building Block.

The PH-EE solution has API’s suitable for consumption by the Information Mediator Building block

5.1.15 Architecture (REQUIRED)

The Payments Building Block must meet the requirements described in the Architecture Building Block.

No Architecture Building Block exists in GovStack however the PH-EE solution is inline with the Mandatory requirements defined in the Architecture and Nonfunctional Requirements as of its V1.0 specification.

6.1 Payment Orchestration https://govstack.gitbook.io/bb-payments/7-functional-requirements#id-6.1-payment-orchestration 37 Required sub-requirements

Mifos uses configurable BPMN workflows to support payment orchestration. It has provision for audibility and can aggregate payments to individuals it can also sub batch by payee DFSP. Logging capabilities and data structures are in place.

6.2 Voucher Management https://govstack.gitbook.io/bb-payments/7-functional-requirements#id-6.2-voucher-management 8 Required sub-requirements

a Voucher management API is created in line with the API specification

6.3 Account Lookup Services (Account Mapper) https://govstack.gitbook.io/bb-payments/7-functional-requirements#id-6.3-account-lookup-services-account-mapper 0 Required sub-requirements

Mifos solution incorporates an ID Account Mapper compliant with all statements in this section.

6.4 Payment Request Initiation https://govstack.gitbook.io/bb-payments/7-functional-requirements#id-6.4-payment-request-initiation 3 Required sub-requirements

The Mifos solution is compatible with all “Required” requirements

6.5 Payment Gateway https://govstack.gitbook.io/bb-payments/7-functional-requirements#id-6.5-payment-gateway 3 required sub-requirements

PH-EE has the capability to connect multiple DFSP’s it can also work with a chosen Government DFSP. Note the PH-EE is not a switch.

6.6 Payment Portal. https://govstack.gitbook.io/bb-payments/7-functional-requirements#id-6.6-payment-portal-recommended Recommended only

Mifos solution includes a payment portal to allow administration of the system which meets a lot of the recommended requirements

6.7 Event Management https://govstack.gitbook.io/bb-payments/7-functional-requirements#id-6.7-event-management 0 Required sub-requirements

Mifos solution does maintain a timestamp which would meet the statements in this section

6.8 Reconciliation https://govstack.gitbook.io/bb-payments/7-functional-requirements#id-6.8-reconciliation-recommended Recommended only

Mifos solution meets the requirements within this section and provides deployment guidance for the implementor in how to ensure time-sync between BB’s.

6.9 Batch Processing https://govstack.gitbook.io/bb-payments/7-functional-requirements#id-6.9-batch-processing-recommended Recommended only

Mifos solution is designed for and around Batch processing.

6.10 Scheduling Services https://govstack.gitbook.io/bb-payments/7-functional-requirements#id-6.10-scheduling-services 6 Required sub-requirements

This is inconsistent with other parts of the Govstack Specification which says scheduling is outside of the BB. the Mifos solution does not undertake scheduling.

6.11 Event Logging https://govstack.gitbook.io/bb-payments/7-functional-requirements#id-6.11-event-logging 3 Required sub-requirements

Mifos solution has event logs to required levels of detail

6.12 Audit Logging https://govstack.gitbook.io/bb-payments/7-functional-requirements#id-6.12-audit-logging 11 Required sub-requirements

PARTIAL SEE EXPLANATION

Some of the requirements are specific to the implementation rather than the design of the solution. Mifos solution provides suitable audit capabilities where the requirement would be relevant to a candidate solution

6.13 Reporting Services https://govstack.gitbook.io/bb-payments/7-functional-requirements#id-6.13-reporting-services Recommended only

Most of these are relevant to implementation rather than the candidate solution

6.14 Security Layer https://govstack.gitbook.io/bb-payments/7-functional-requirements#id-6.14-security-layer 6 Required sub-requirements

The Mifos solution meets these requirements

6.15 Data Protection https://govstack.gitbook.io/bb-payments/7-functional-requirements#id-6.15-data-protection 0 Required sub-requirements

N/A

There are no identified Data Protection Requirements

6.16 Bulk Payment Service.https://govstack.gitbook.io/bb-payments/7-functional-requirements#id-6.16-bulk-payment-service-recommended Recommended Only

Mifos solution supports Bulk Payment Services

6.17 P2G Bill Payment https://govstack.gitbook.io/bb-payments/7-functional-requirements#id-6.17-p2g-bill-payments 0 Required sub-requirements

The Mifos solution has P2G payment API’s supported

6.17 Payments Building Block Components https://govstack.gitbook.io/bb-payments/7-functional-requirements#id-6.17-payments-building-block-components 0 Required sub-requirements

The Mifos solution matches the architecture detailed

5.1 Follow TM Forum Specification REST API Design Guidelines Part 1 (REQUIRED)

5.2 Follow TM Forum Specification REST API Design Guidelines Parts 2-7 (RECOMMENDED)

Partially - even though requirement only recommended

5.3 Communicate with other BBs only via API (REQUIRED)

All communication is via API’s

5.4 APIs must be Versioned (REQUIRED)

All API’s are versioned

5.5 Documentation must be Provided (REQUIRED)

All API’s are documented in the source Repo

5.6 Provide an OpenAPI specification (REQUIRED)

5.7 Building blocks must be deployable as a container (REQUIRED)

5.8 Include all deployment scripts (RECOMMENDED)

Helm charts are included for a number of examples

5.9 Comply with GDPR Principles (REQUIRED)

No relevant GDPR for this BB

5.10 Include Support for Capturing Logging information (REQUIRED)

As defined in the BB Spec

5.11 Use Web Hooks for Callbacks (REQUIRED)

5.12 Enforce Transport Security (REQUIRED)

5.13 GET and PUT APIs must be Idempotent (REQUIRED)

being reviewed

5.14 Use Stateless APIs wherever Possible to Enhance Scalability (RECOMMENDED)

Where ever possible this has been done. All in accordance with the BB Spec

5.15 Include Transaction/Trace/Correlation IDs (RECOMMENDED)

Essential for Payment BB and complied with

5.16 Include Clearly-Defined Key Rotation Policies (RECOMMENDED)

Not defined at the moment.

5.17 Databases should not Include Business Logic (RECOMMENDED)

Business logic is contained in the orchestration path (BPMN)

5.18 Use only Unicode for Text (REQUIRED)

5.19 Use ISO8601/UTC for Timestamps (REQUIRED)

Supported but determined by Implementation scenario

5.20 Building Blocks must be Autonomous (REQUIRED)

5.21 Use Secure Configuration (REQUIRED)

5.22 Design for Asynchronous First (RECOMMENDED)

Asynchronous first was a key design principle

5.23 Use Standardized Data Formats for Interchange (REQUIRED)

5.24 Use Existing Standards for Data Interchange, Where Available (RECOMMENDED)

5.25 Use I/O Sanitization (RECOMMENDED)

Partially - even though requirement only recommended

5.26 Provide a Compliance Test Mock/Example Implementation (OPTIONAL)

This can be done by deployment of the G2P sandbox Helm chart

5.27 Building blocks should be Localizable (RECOMMENDED)

Partially, the new UI supports localisation

5.28 Use NTP Synchronization (RECOMMENDED)

Supported but determined by Implementation scenario