Compliance Evaluation: Mifos- Payment Hub
Content
Tool Description
Mifos Payment Hub - Enterprise Edition has be extensively updated to included Account Mapper, Batch Payment, Voucher Management API’s and be compliant with the Govstack Specification of the Payment Building Block. Mifos Payment Hub is used in deployments around the world and incorporates BPMN flows to enable payment orchestration.
Evaluation Status
Status | Insert Jira Link |
---|---|
Date | 2024-04-02 |
Reviewer | David Higgins |
Software Version | v1.13.0 |
Specification Version | |
Compliance Level | Declined Pending Level 1 Level 2 |
Software Attributes
Logo |
|
---|---|
Name | Mifos - Payment Hub - Enterprise Edition (PH-EE) |
Website | |
Documentation | |
BBs used for Evaluation |
Evaluation Summary
| Criterion | Fulfillment |
---|---|---|
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 | |
Fulfillment of REQUIRED cross-cutting requirements stated in the Architecture BB specifications | 15/16 Required 1 required being reviewed. |
Deployment Compliance
Requirement | Fulfillment | Comment |
---|---|---|
Must be deployable via container |
| Compliant |
|
|
|
Interface Compliance
Test Harness Result
Currently pending resolution of Test Harness issues by GovStack Testing team.
API Requirements from Architecture Specifications
See requirements (5.1, 5.3, 5.4, 5.6, 5.13) below under “Architectural Cross-Cutting Requirements”
Requirement Specification Compliance
Please copy and paste all REQUIRED requirements from the respective BB specification Gitbook repository into this list. All RECOMMENDED requirements are optional. We are working on a automated procedure.
Key Digital Functionalities
Requirement | Fulfillment | Comment |
---|---|---|
4.1 Payment Orchestration - |
| Mifos Payment Hub - EE contains customisable BPMN workflows |
4.2 Voucher Management - |
| 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 - |
| Allows for source BB’s such as Registration via the IMBB to to initiate payment requests |
4.5 Payment Gateway - |
| Multiple DFSP’s or Switch’s can work with the Payment Hub EE solution. |
4.6 Payment Portal - |
| Admin interface provided showing payment lifecycle |
4.7 Event Management - |
| Supported |
4.8 Reconciliation - |
| Both internal and external reconciliation is supported |
4.9 Batch Processing - |
| PH-EE supports batch processing. |
4.10 Scheduling Services - |
| Agreed by Payments Building Block to be covered by Scheduling BB. |
4.11 Event Logging - |
| Logging in place |
4.12 Audit Logging - |
| Audit capabilities in place |
4.13 Reporting Services - |
| Supported through Kibana dashboards |
4.14 Security Layer - |
|
|
4.15 Bulk Payment service - |
| Support for bulk/batch payments included |
BB Cross Cutting Functionalities
Requirement | Fulfillment | Comment |
---|---|---|
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. |
BB Functional Requirements
Requirement | Fulfillment | Comment |
---|---|---|
6.1 Payment Orchestration 6 Functional Requirements | bb-payments 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 |
Architectural Cross-Cutting Requirements
Requirement (source: v1.0 of https://govstack.gitbook.io/specification/architecture-and-nonfunctional-requirements/5-cross-cutting-requirements ) | Fulfillment | Comment |
---|---|---|
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 |