On this page

CVA Platforms

Cash and voucher assistance (CVA) delivery requires coordination across multiple technology layers: beneficiary management systems that determine eligibility and calculate entitlements, payment infrastructure that moves funds between financial service providers, orchestration engines that sequence payment workflows, and integration platforms that connect disparate systems. This benchmark evaluates four open source solutions addressing different components of the CVA technology stack.

This page does not cover commercial CVA management platforms such as RedRose, Mastercard Aid Network, or proprietary FSP solutions. See the related page mapping for adjacent benchmarks covering case management systems and beneficiary identity systems.

Assessment methodology

Tool assessments derive from official developer documentation, published API references, release notes, and technical specifications as of 2026-01-10. Feature availability varies by product tier, deployment model, or region. Verify current capabilities directly with maintainers during procurement. Community-reported information is excluded; only documented features are assessed.

Requirements taxonomy

This taxonomy defines evaluation criteria for CVA infrastructure components. Requirements are organised by functional area and weighted by typical priority for humanitarian and social protection contexts.

Functional requirements

Beneficiary management

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
F1.1	Beneficiary registration	Capture and store beneficiary demographic data, household composition, and vulnerability indicators	Full: configurable registration forms, household grouping, document attachment. Partial: fixed fields only. None: no registration capability.	Review registration module documentation; test form configuration	Essential
F1.2	Deduplication	Identify and manage duplicate beneficiary records to prevent double-dipping	Full: configurable matching rules, fuzzy matching, biometric integration. Partial: exact match only. None: manual review only.	Review deduplication documentation; check matching algorithms	Essential
F1.3	Eligibility determination	Apply rules to determine programme eligibility based on beneficiary attributes	Full: configurable eligibility criteria, proxy means testing, categorical targeting. Partial: single criteria type. None: manual assignment.	Review eligibility engine documentation; test rule configuration	Essential
F1.4	Entitlement calculation	Compute transfer amounts based on household composition, programme rules, and frequency	Full: configurable calculation formulas, household-size adjustments, top-ups. Partial: fixed amounts. None: no calculation.	Review entitlement documentation; verify formula flexibility	Essential
F1.5	Beneficiary grievance tracking	Record and manage complaints, appeals, and feedback from beneficiaries	Full: ticketing system, status tracking, resolution workflow. Partial: basic logging. None: no tracking.	Review grievance module documentation	Important
F1.6	Consent management	Capture, store, and manage beneficiary consent for data processing and programme participation	Full: granular consent types, withdrawal tracking, audit trail. Partial: single consent flag. None: no consent management.	Review consent documentation; assess GDPR alignment	Essential

Payment processing

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
F2.1	Payment instruction generation	Create payment orders from approved entitlements for transmission to FSPs	Full: batch generation, multiple FSP formats, scheduling. Partial: single format. None: manual creation.	Review payment generation documentation; check output formats	Essential
F2.2	Multi-FSP support	Route payments to multiple financial service providers based on beneficiary preference or location	Full: configurable FSP routing, failover, load balancing. Partial: single FSP. None: no routing.	Review FSP integration documentation; count supported providers	Essential
F2.3	Payment reconciliation	Match payment instructions with FSP confirmation to track disbursement status	Full: automated matching, exception handling, retry logic. Partial: manual reconciliation. None: no reconciliation.	Review reconciliation documentation; check automation level	Essential
F2.4	Payment reversal handling	Process failed, rejected, or returned payments with appropriate beneficiary notification	Full: automated reversal processing, reason tracking, re-queue capability. Partial: manual handling. None: no reversal support.	Review reversal documentation; check workflow automation	Important
F2.5	Real-time payment status	Track payment status from initiation through completion with beneficiary visibility	Full: real-time status updates, beneficiary portal/SMS notification. Partial: batch status updates. None: no status tracking.	Review status tracking documentation; check notification channels	Important
F2.6	Payment scheduling	Schedule recurring payments, advance payments, or time-bound disbursements	Full: flexible scheduling, calendar integration, pause/resume. Partial: fixed intervals. None: immediate only.	Review scheduling documentation; test recurrence patterns	Important

FSP interoperability

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
F3.1	Mobile money integration	Connect to mobile money providers for disbursement to mobile wallets	Full: documented integrations with major providers (MTN, Safaricom, Orange), sandbox testing. Partial: generic API only. None: no mobile money.	Review mobile money connector documentation; check provider coverage	Essential
F3.2	Bank transfer support	Execute transfers to bank accounts via ACH, RTGS, or instant payment rails	Full: multiple rail types, bank validation, fee handling. Partial: single rail. None: no bank transfers.	Review bank transfer documentation; check country coverage	Important
F3.3	Agent network disbursement	Enable cash collection at agent locations with authentication and receipt generation	Full: agent location API, beneficiary authentication, receipt generation. Partial: location list only. None: no agent support.	Review agent disbursement documentation	Context-dependent
F3.4	Voucher generation	Create electronic or paper vouchers redeemable at participating merchants	Full: voucher lifecycle management, merchant redemption, value tracking. Partial: basic voucher generation. None: no voucher support.	Review voucher documentation; check merchant integration	Context-dependent
F3.5	Cross-border payments	Execute international transfers with currency conversion and compliance handling	Full: corridor support, FX rates, compliance screening. Partial: limited corridors. None: domestic only.	Review cross-border documentation; check corridor coverage	Context-dependent

Programme management

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
F4.1	Programme configuration	Define programme parameters including duration, eligibility criteria, transfer values, and cycles	Full: multi-programme support, versioning, approval workflow. Partial: single programme. None: hardcoded parameters.	Review programme configuration documentation	Essential
F4.2	Cycle management	Manage payment cycles with beneficiary list generation, approval, and execution	Full: configurable cycles, list freeze, amendment handling. Partial: fixed cycles. None: no cycle support.	Review cycle management documentation	Essential
F4.3	Budget tracking	Monitor programme expenditure against allocated budget with alerts	Full: real-time tracking, commitment accounting, multi-currency. Partial: basic totals. None: no budget tracking.	Review budget documentation; check reporting granularity	Important
F4.4	Donor reporting	Generate reports meeting donor requirements for expenditure, coverage, and outcomes	Full: customisable report templates, automated generation, export formats. Partial: fixed reports. None: no donor reports.	Review reporting documentation; check template flexibility	Important
F4.5	Multi-programme coordination	Manage multiple concurrent programmes with shared beneficiary registry	Full: cross-programme deduplication, stacking rules, unified registry. Partial: separate registries. None: single programme.	Review multi-programme documentation	Important

Workflow automation

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
F5.1	Data transformation	Convert data between formats required by different systems in the CVA stack	Full: visual mapping, custom transformations, error handling. Partial: fixed mappings. None: no transformation.	Review transformation documentation; check format support	Essential
F5.2	Event-driven triggers	Initiate workflows based on system events such as registration completion or payment failure	Full: configurable triggers, multiple event types, conditional logic. Partial: limited events. None: manual initiation.	Review trigger documentation; check event coverage	Important
F5.3	Retry and error handling	Manage failed operations with configurable retry logic and error notification	Full: configurable retry policies, exponential backoff, alerting. Partial: fixed retries. None: no retry logic.	Review error handling documentation	Essential
F5.4	Audit trail	Maintain immutable log of all data movements and transformations	Full: comprehensive logging, tamper-evident, queryable. Partial: basic logging. None: no audit trail.	Review audit documentation; check log completeness	Essential
F5.5	Scheduling and orchestration	Coordinate timed workflows across multiple systems	Full: cron scheduling, dependency management, parallel execution. Partial: simple scheduling. None: no scheduling.	Review scheduling documentation	Important

Technical requirements

Deployment and hosting

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
T1.1	Self-hosted deployment	Deploy on organisation-controlled infrastructure for data sovereignty	Full: complete feature parity, documented deployment. Partial: feature limitations. None: SaaS only.	Review deployment documentation; compare feature matrix	Essential
T1.2	Container deployment	Support containerised deployment via Docker and Kubernetes	Full: official images, Helm charts, orchestration docs. Partial: community images. None: no container support.	Check container registries; review orchestration docs	Important
T1.3	Air-gapped operation	Function without internet connectivity for field deployment	Full: complete offline operation documented. Partial: degraded functionality. None: requires internet.	Review offline documentation; identify dependencies	Context-dependent
T1.4	High availability	Support redundant deployment eliminating single points of failure	Full: documented HA architecture, automatic failover. Partial: manual failover. None: single-instance.	Review HA documentation; check clustering support	Context-dependent
T1.5	Resource requirements	Published minimum and recommended hardware specifications	Full: detailed sizing guides by scale. Partial: minimum requirements only. None: undocumented.	Review system requirements documentation	Important

Scalability and performance

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
T2.1	Horizontal scaling	Add capacity through additional nodes rather than hardware upgrades	Full: documented horizontal scaling, load balancing. Partial: limited scaling. None: vertical only.	Review scaling documentation; check architecture	Context-dependent
T2.2	Batch processing capacity	Handle large payment batches (10,000+ beneficiaries) efficiently	Full: benchmarks published, async processing. Partial: size limits. None: no batch processing.	Review batch documentation; check published limits	Essential
T2.3	Concurrent user support	Support multiple simultaneous users without degradation	Full: published concurrent user limits, connection pooling. Partial: limited concurrency. None: single user.	Review performance documentation	Important
T2.4	Transaction throughput	Published transactions per second for payment processing	Full: benchmarks with methodology. Partial: general claims. None: no published data.	Review performance documentation; check benchmark methodology	Important

Integration architecture

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
T3.1	REST API	Programmatic access via REST API for integration	Full: comprehensive API, versioned, documented. Partial: limited coverage. None: no API.	Review API documentation completeness; compare to UI features	Essential
T3.2	API authentication	Methods for securing API access	Document supported methods: API keys, OAuth 2.0, OIDC, mTLS	Review API security documentation	Essential
T3.3	Webhook support	Push event notifications to external systems	Full: configurable webhooks, retry logic, payload customisation. Partial: limited events. None: polling only.	Review webhook documentation; check event coverage	Important
T3.4	Bulk data operations	Efficient large-scale data import and export	Full: batch APIs, streaming, async operations. Partial: size limits. None: record-by-record.	Review bulk operation documentation; check limits	Essential
T3.5	Pre-built connectors	Available integrations with common CVA ecosystem systems	List connectors: KoboToolbox, DHIS2, CommCare, Primero, etc.	Review integrations directory; verify maintenance	Desirable

Standards compliance

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
T3.6	Level One Project alignment	Conformance with Mojaloop/L1P interoperability specifications	Full: FSPIOP implementation, certified interoperability. Partial: partial implementation. None: no L1P alignment.	Review L1P compliance documentation	Context-dependent
T3.7	ISO 20022 support	Use of ISO 20022 financial messaging standards	Full: native ISO 20022, message mapping. Partial: conversion available. None: proprietary only.	Review messaging documentation; check message types	Context-dependent
T3.8	HXL tagging	Support for Humanitarian Exchange Language data tagging	Full: native HXL support, tagged exports. Partial: manual tagging. None: no HXL.	Review data standards documentation	Desirable

Security requirements

Authentication and access control

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
S1.1	Multi-factor authentication	MFA support for user accounts	Full: multiple MFA methods (TOTP, WebAuthn), policy enforcement. Partial: single method. None: password only.	Review authentication documentation; test MFA options	Essential
S1.2	Single sign-on	Federated identity via SSO protocols	Full: SAML 2.0 and OIDC, multiple IdP. Partial: single protocol. None: local auth only.	Review SSO documentation; check protocol support	Essential
S1.3	Role-based access control	Granular permissions based on user roles	Full: custom roles, field-level permissions, inheritance. Partial: fixed roles. None: basic user/admin.	Review RBAC documentation; assess granularity	Essential
S1.4	Segregation of duties	Enforce separation between registration, approval, and payment functions	Full: workflow-enforced separation, dual approval. Partial: role separation only. None: no segregation.	Review workflow documentation; check approval chains	Essential
S1.5	Session management	Controls for session duration, concurrent sessions, forced logout	Full: configurable policies, session visibility. Partial: limited controls. None: defaults only.	Review session documentation	Important

Data protection

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
S2.1	Encryption at rest	Data encrypted when stored	Full: AES-256, documented key management. Partial: encryption available but optional. None: unencrypted.	Review encryption documentation; verify key management	Essential
S2.2	Encryption in transit	Data encrypted during transmission	Full: TLS 1.2+ enforced. Partial: TLS available. None: unencrypted transmission.	Review transport security; test with SSL analyser	Essential
S2.3	PII handling	Controls for personally identifiable information	Full: data classification, masking, minimisation controls. Partial: basic masking. None: no PII controls.	Review PII documentation; check masking capabilities	Essential
S2.4	Audit logging	Comprehensive logging of data access and changes	Full: immutable logs, configurable retention, export. Partial: limited logging. None: no audit logs.	Review audit documentation; assess log completeness	Essential
S2.5	Data residency	Control over data storage location	Full: selectable regions, documented data flows. Partial: limited regions. None: undisclosed.	Review residency documentation; verify contractually	Essential

Security certifications

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
S3.1	Security audit history	Evidence of independent security assessment	Full: published audit summaries, CVE tracking. Partial: internal audits. None: no audits disclosed.	Request audit evidence; check CVE database	Important
S3.2	Vulnerability disclosure	Process for reporting and addressing security issues	Full: public policy, responsible disclosure, timely patches. Partial: informal process. None: no programme.	Review security policy; check disclosure history	Important
S3.3	GDPR compliance features	Capabilities supporting GDPR compliance	Full: consent management, data export, erasure support. Partial: limited features. None: no GDPR features.	Review GDPR documentation; assess feature coverage	Essential

Operational requirements

Administration

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
O1.1	Administrative interface	Quality and capability of admin tools	Full: comprehensive web UI, bulk operations. Partial: limited UI. None: command-line only.	Review admin documentation; assess during trial	Important
O1.2	Multi-tenancy	Support isolated environments for different programmes or organisations	Full: logical or physical isolation, tenant-specific config. Partial: workspace separation. None: single tenant.	Review multi-tenancy documentation	Context-dependent
O1.3	Localisation	Support for multiple languages and regional formats	Full: UI translations, configurable date/number formats, RTL. Partial: limited languages. None: English only.	Review localisation documentation; check language count	Important
O1.4	Configuration management	Version-controlled configuration for reproducible deployments	Full: infrastructure as code, GitOps support. Partial: limited config export. None: UI only.	Review configuration documentation	Desirable

Monitoring and observability

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
O2.1	Health monitoring	Programmatic health check endpoints	Full: detailed health endpoints, component status. Partial: basic up/down. None: no health API.	Review monitoring documentation; test endpoints	Important
O2.2	Metrics export	Exposure of operational metrics for monitoring systems	Full: Prometheus/OpenTelemetry export. Partial: built-in dashboard only. None: no metrics.	Review metrics documentation; check formats	Important
O2.3	Alerting	Notification for operational issues	Full: configurable alerts, multiple channels. Partial: basic email. None: no alerting.	Review alerting documentation	Important

Backup and recovery

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
O3.1	Automated backup	Regular automated data backup	Full: configurable schedule, encryption, retention. Partial: manual only. None: no backup support.	Review backup documentation	Essential
O3.2	Point-in-time recovery	Restore to specific point in time	Full: granular PITR, documented RPO. Partial: daily snapshots. None: latest only.	Review recovery documentation	Important
O3.3	Disaster recovery	Documented procedures for catastrophic failure	Full: DR runbook, tested procedures. Partial: general guidance. None: no DR documentation.	Review DR documentation	Important

Support and maintenance

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
O4.1	Documentation quality	Completeness and accuracy of technical documentation	Full: comprehensive, current, searchable. Partial: incomplete. Poor: minimal.	Assess documentation during evaluation	Essential
O4.2	Community activity	Vitality of open source community	Metrics: contributors, commit frequency, issue response, governance	Review repository statistics	Important
O4.3	Commercial support	Availability of paid support options	Full: enterprise support, SLAs. Partial: consulting only. None: community only.	Review support options; check provider network	Context-dependent
O4.4	Release cadence	Frequency and predictability of updates	Full: regular releases, LTS options. Partial: irregular. None: sporadic.	Review release history	Important

Data management requirements

Import and migration

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
D1.1	Beneficiary data import	Import beneficiary records from external sources	Full: CSV, Excel, JSON import with validation. Partial: limited formats. None: manual entry.	Review import documentation; test with sample data	Essential
D1.2	Migration tools	Utilities for migrating from other systems	Full: migration guides for common sources. Partial: generic import. None: no migration support.	Review migration documentation	Desirable
D1.3	Data validation	Verification of imported data quality	Full: configurable rules, error reporting. Partial: basic type checking. None: no validation.	Review validation documentation	Important

Export and portability

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
D2.1	Complete data export	Export all beneficiary and transaction data	Full: comprehensive export, machine-readable formats. Partial: limited scope. None: no export.	Review export documentation; test completeness	Essential
D2.2	Export formats	Available output formats	List formats: CSV, JSON, XML, Excel, etc.	Review export documentation	Important
D2.3	Scheduled exports	Automated recurring data exports	Full: configurable schedules, destinations. Partial: manual triggers. None: on-demand only.	Review scheduling documentation	Desirable
D2.4	API-based extraction	Programmatic data extraction via API	Full: comprehensive read API. Partial: limited endpoints. None: UI export only.	Review API documentation	Important

Functional capability comparison

CVA stack positioning

Capability	OpenSPP	Mojaloop	Mifos Payment Hub EE	OpenFn
Primary function	Social protection MIS	Instant payment switch	Payment orchestration	Workflow automation
Beneficiary registry	●	✗	✗	✗
Eligibility determination	●	✗	✗	✗
Entitlement calculation	●	✗	✗	✗
Payment instruction generation	●	◐	●	✗
Inter-FSP clearing	✗	●	◐	✗
Settlement	✗	●	✗	✗
FSP connector framework	◐	●	●	✗
Data integration	◐	✗	✗	●
Workflow orchestration	◐	✗	●	●

Rating key: ● Full support | ◐ Partial support | ✗ Not supported

Assessment notes:

OpenSPP provides end-to-end social protection capability from registration through payment instruction but relies on external payment infrastructure for actual fund transfer
Mojaloop handles interbank/inter-FSP clearing and settlement but does not manage beneficiaries or programme logic
Mifos Payment Hub EE orchestrates payment workflows between account systems and payment switches but does not maintain beneficiary data
OpenFn connects systems and transforms data but does not provide CVA business logic

Beneficiary management

Req ID	Requirement	OpenSPP	Mojaloop	Mifos Payment Hub EE	OpenFn
F1.1	Beneficiary registration	●	✗	✗	✗
F1.2	Deduplication	●	✗	✗	✗
F1.3	Eligibility determination	●	✗	✗	✗
F1.4	Entitlement calculation	●	✗	✗	✗
F1.5	Grievance tracking	●	✗	✗	✗
F1.6	Consent management	●	✗	✗	✗

Assessment notes:

OpenSPP F1.2: Supports configurable deduplication rules via the OpenG2P registry module; fuzzy matching requires additional configuration
OpenSPP F1.3: Eligibility managers are extensible; organisations create custom eligibility rules via Python modules

Payment processing

Req ID	Requirement	OpenSPP	Mojaloop	Mifos Payment Hub EE	OpenFn
F2.1	Payment instruction generation	●	◐	●	✗
F2.2	Multi-FSP support	◐	●	●	✗
F2.3	Payment reconciliation	◐	●	●	◐
F2.4	Payment reversal handling	◐	●	●	✗
F2.5	Real-time payment status	◐	●	●	✗
F2.6	Payment scheduling	●	✗	●	◐

Assessment notes:

OpenSPP F2.2: Supports multiple payment managers but requires FSP-specific connector development
Mojaloop F2.1: Generates transfer requests per FSPIOP specification; does not generate bulk payment files
Mifos Payment Hub EE F2.3: Uses Zeebe workflow engine for reconciliation orchestration
OpenFn F2.3: Can orchestrate reconciliation workflows across systems but does not provide native reconciliation logic

FSP interoperability

Req ID	Requirement	OpenSPP	Mojaloop	Mifos Payment Hub EE	OpenFn
F3.1	Mobile money integration	◐	●	●	◐
F3.2	Bank transfer support	◐	●	●	◐
F3.3	Agent network disbursement	◐	●	●	✗
F3.4	Voucher generation	◐	✗	✗	✗
F3.5	Cross-border payments	✗	●β	◐	✗

Assessment notes:

Mojaloop F3.1: Reference implementations exist for major mobile money providers; production connectors require DFSP-specific development
Mojaloop F3.5: Cross-network (FX) API in active development as of late 2024
OpenSPP F3.4: Voucher management module available but less mature than payment modules
OpenFn F3.1/F3.2: Adaptors available for some payment providers (Stripe, PayPal); humanitarian FSP coverage limited

Programme management

Req ID	Requirement	OpenSPP	Mojaloop	Mifos Payment Hub EE	OpenFn
F4.1	Programme configuration	●	✗	✗	✗
F4.2	Cycle management	●	✗	●	✗
F4.3	Budget tracking	●	✗	✗	✗
F4.4	Donor reporting	◐	✗	◐	◐
F4.5	Multi-programme coordination	●	✗	◐	✗

Assessment notes:

OpenSPP F4.4: Standard reports available; custom donor report templates require development
Mifos Payment Hub EE F4.2: Payment cycles managed via BPMN workflows in Zeebe
OpenFn F4.4: Can aggregate data from multiple sources for reporting but does not generate reports natively

Workflow automation

Req ID	Requirement	OpenSPP	Mojaloop	Mifos Payment Hub EE	OpenFn
F5.1	Data transformation	◐	✗	◐	●
F5.2	Event-driven triggers	◐	●	●	●
F5.3	Retry and error handling	◐	●	●	●
F5.4	Audit trail	●	●	●	●
F5.5	Scheduling and orchestration	◐	✗	●	●

Assessment notes:

OpenFn F5.1: Visual workflow builder with extensive data transformation capabilities; 70+ pre-built adaptors
Mifos Payment Hub EE F5.2/F5.5: Zeebe provides BPMN-based workflow orchestration with sophisticated event handling
OpenSPP F5.4: Comprehensive audit logging inherited from Odoo framework

Technical capability comparison

Deployment and hosting

Req ID	Requirement	OpenSPP	Mojaloop	Mifos Payment Hub EE	OpenFn
T1.1	Self-hosted deployment	●	●	●	●
T1.2	Container deployment	●	●	●	●
T1.3	Air-gapped operation	◐	✗	◐	●
T1.4	High availability	●	●	●	●
T1.5	Resource requirements	●	●	◐	●

Deployment details:

Tool	Platform	Container support	Minimum resources	Recommended production
OpenSPP	Linux (Ubuntu 22.04+)	Docker Compose, Kubernetes	4 CPU, 8GB RAM, 50GB storage	8 CPU, 32GB RAM, 200GB storage
Mojaloop	Linux, Kubernetes required	Helm charts, official images	16 CPU, 32GB RAM, 100GB storage	32+ CPU, 64GB+ RAM, distributed
Mifos Payment Hub EE	Linux, Kubernetes preferred	Helm charts, Docker images	8 CPU, 16GB RAM, 50GB storage	16 CPU, 32GB RAM, 100GB storage
OpenFn	Linux (Debian/Ubuntu)	Docker, official images	2 CPU, 4GB RAM, 20GB storage	4 CPU, 8GB RAM, 50GB storage

Assessment notes:

OpenSPP T1.3: Can function offline for data entry; payment processing requires connectivity
Mojaloop T1.3: Designed for always-connected real-time operation; not suitable for disconnected deployment
OpenFn T1.3: Lightning supports offline work queuing; jobs execute when connectivity restored

Integration architecture

Req ID	Requirement	OpenSPP	Mojaloop	Mifos Payment Hub EE	OpenFn
T3.1	REST API	●	●	●	●
T3.2	API authentication	OAuth 2.0, API key	OAuth 2.0, mTLS	API key, OAuth 2.0	API key, OAuth 2.0, OIDC
T3.3	Webhook support	◐	●	●	●
T3.4	Bulk data operations	●	◐	●	●
T3.5	Pre-built connectors	◐	-	●	●

API details:

Tool	API documentation	Rate limits	Versioning	SDK availability
OpenSPP	docs.openspp.org/developer_guide	Configurable (self-hosted)	Odoo version-based	Python (Odoo client)
Mojaloop	docs.mojaloop.io/api	Configurable	FSPIOP versioned	JavaScript SDK
Mifos Payment Hub EE	mifos.gitbook.io/docs/payment-hub-ee	Configurable	Path versioning	Java client libraries
OpenFn	docs.openfn.org	Configurable (self-hosted)	Semantic versioning	JavaScript CLI

Assessment notes:

OpenSPP T3.5: CommCare integration documented; additional connectors require custom development
Mojaloop T3.5: Not applicable; provides APIs that connectors integrate with rather than providing connectors
OpenFn T3.5: 70+ adaptors including DHIS2, Primero, CommCare, Salesforce, ODK

Standards compliance

Standard	OpenSPP	Mojaloop	Mifos Payment Hub EE	OpenFn
Level One Project/FSPIOP	✗	●	●	✗
ISO 20022	✗	◐	◐	✗
HXL tagging	✗	✗	✗	◐
FHIR	✗	✗	✗	●
OpenHIE	✗	✗	✗	●

Assessment notes:

Mojaloop ISO 20022: Roadmap includes ISO 20022 migration; not currently native
OpenFn HXL: Can process and generate HXL-tagged data through custom job scripts
OpenFn FHIR/OpenHIE: Native FHIR adaptor and OpenHIE compliance for health system integration

Security capability comparison

Authentication and access control

Req ID	Requirement	OpenSPP	Mojaloop	Mifos Payment Hub EE	OpenFn
S1.1	Multi-factor authentication	●	●	●	●
S1.2	SSO integration	SAML, OIDC	OIDC	OIDC	SAML, OIDC
S1.3	Role-based access control	●	●	●	●
S1.4	Segregation of duties	●	●	●	●
S1.5	Session management	●	●	●	●

MFA methods supported:

Tool	TOTP	WebAuthn/FIDO2	Push	SMS
OpenSPP	●	●	✗	✗
Mojaloop	●	◐	✗	✗
Mifos Payment Hub EE	●	✗	✗	✗
OpenFn	●	●	✗	✗

Data protection

Req ID	Requirement	OpenSPP	Mojaloop	Mifos Payment Hub EE	OpenFn
S2.1	Encryption at rest	AES-256	AES-256	AES-256	AES-256
S2.2	Encryption in transit	TLS 1.2+	TLS 1.2+	TLS 1.2+	TLS 1.2+
S2.3	PII handling	●	●	◐	●
S2.4	Audit logging	●	●	●	●
S2.5	Data residency	●	●	●	●

Assessment notes:

OpenSPP S2.3: Protection data module provides enhanced PII handling for vulnerable populations
Mifos Payment Hub EE S2.3: Handles payment account identifiers; beneficiary PII typically held in upstream systems
OpenFn S2.3: Data retention policies configurable; dataclip wiping available for sensitive workflows

Security certifications

Certification/Practice	OpenSPP	Mojaloop	Mifos Payment Hub EE	OpenFn
Independent security audit	●	●	●	●
Vulnerability disclosure programme	●	●	●	●
CVE tracking	●	●	◐	●
GDPR compliance features	●	●	◐	●
DPG certified	●	●	●	●

Assessment notes:

All four solutions are certified Digital Public Goods
OpenSPP: Security practices inherited from Odoo framework plus OpenG2P security guidelines
Mojaloop: Dedicated security workstream; comprehensive threat modelling documented

Operational capability comparison

Administration

Req ID	Requirement	OpenSPP	Mojaloop	Mifos Payment Hub EE	OpenFn
O1.1	Admin interface quality	●	◐	◐	●
O1.2	Multi-tenancy	●	●	●	●
O1.3	Localisation	25+ languages	Limited	Limited	10+ languages
O1.4	Configuration management	●	●	●	●

Assessment notes:

OpenSPP O1.1: Full Odoo-based admin interface with extensive customisation options
Mojaloop O1.1: Business Operations Framework provides admin UI; primarily API-driven
OpenFn O1.1: Lightning v2 visual workflow builder with comprehensive project management

Monitoring and support

Aspect	OpenSPP	Mojaloop	Mifos Payment Hub EE	OpenFn
Health endpoints	●	●	●	●
Metrics format	Prometheus	Prometheus	Prometheus	Prometheus
Log export	●	●	●	●
Documentation quality	Good	Excellent	Good	Excellent
Community forum	● Active	● Active	● Active	● Active
Commercial support	Consulting partners	Member organisations	Mifos Initiative	OpenFn Inc.

Individual tool assessments

OpenSPP

Type: Open source
Licence: LGPL-3.0
Current version: 17.0.1.2.1 (Batanes release)
Deployment options: Self-hosted (Docker, Kubernetes), managed cloud via partners
Source repository: https://github.com/OpenSPP
Documentation: https://docs.openspp.org

Overview

OpenSPP provides a modular social protection management information system built on the Odoo 17 enterprise framework. The platform addresses the complete social protection lifecycle from beneficiary registration through programme management to payment instruction generation. Three integrated products compose the offering: SP-MIS for programme administration, Social Registry for beneficiary data coordination, and Farmer Registry for agricultural-social protection convergence.

The architecture builds upon OpenG2P (Open Government to Person) core modules, extending them with humanitarian and agricultural-specific functionality. This inheritance provides mature registry capabilities while allowing OpenSPP to focus on CVA-specific requirements. Organisations can deploy individual modules matching their needs while maintaining interoperability with existing systems through REST APIs and the Odoo integration framework.

Development is led by a consortium of implementing partners with active deployments across Asia and Africa. The project achieved Digital Public Good certification and maintains alignment with Digital Public Goods Standard principles including user-centricity, modularity, and interoperability.

Capability assessment for CVA

OpenSPP delivers the strongest beneficiary management capabilities among assessed solutions. The eligibility manager framework supports proxy means testing, categorical targeting, and custom eligibility rules implemented as Python modules. Entitlement calculation handles household composition adjustments, geographic variations, and top-up calculations. The cycle management module generates beneficiary lists, manages approval workflows, and tracks disbursement status.

Payment integration requires external infrastructure. OpenSPP generates payment instructions but does not execute transfers directly. Organisations connect OpenSPP to payment switches (such as Mojaloop) or FSP APIs through payment manager modules. Pre-built connectors exist for some mobile money providers; others require development.

The platform handles protection-sensitive data through configurable access controls and field-level security. Integration with Primero for case management and KoboToolbox for field data collection is documented, though production implementations require configuration effort.

Key strengths:

Complete beneficiary lifecycle management from registration through payment tracking
Extensible eligibility framework supporting complex targeting criteria
Multi-programme coordination with shared registry and deduplication
Mature Odoo framework provides enterprise features (reporting, workflow, audit)
Active development community with regular releases

Key limitations:

Odoo expertise required for customisation and module development
Payment execution requires integration with external payment infrastructure
Limited out-of-box FSP connectors; most require custom development
Resource-intensive deployment compared to lighter-weight solutions
Learning curve for non-Odoo developers

Deployment and operations

Self-hosted requirements:

Operating system: Ubuntu 22.04 LTS, Debian 12
Database: PostgreSQL 14+
Runtime: Python 3.10+, Odoo 17
Minimum resources: 4 CPU, 8GB RAM, 50GB storage
Recommended production: 8 CPU, 32GB RAM, 200GB SSD

Deployment complexity: Medium-High. Docker Compose deployment documented for development; production Kubernetes deployment requires Odoo operations experience.

Operational overhead: Medium. Odoo maintenance patterns apply including database backups, module updates, and customisation management.

Upgrade path: Follows Odoo version releases. Migration between major Odoo versions (e.g., 16 to 17) requires planning and testing.

Integration capabilities

Integration	Type	Documentation
CommCare	Native connector	Documented, maintained
KoboToolbox	REST API	Documented
Primero	REST API	Reference architecture
eSignet	OIDC	Documented
Keycloak	OIDC	Documented
MOSIP	REST API	Reference architecture

OpenSPP exposes comprehensive REST APIs following Odoo patterns. Custom integrations use the standard Odoo external API with JSON-RPC or XML-RPC protocols. Webhook support is available through Odoo automation rules.

Cost analysis

Deployment model	Infrastructure cost (small)	Infrastructure cost (medium)
Self-hosted cloud	$150-300/month	$500-1,500/month
Self-hosted on-premises	Hardware + admin time	Hardware + admin time
Managed (via partner)	Varies by partner	Varies by partner

Cost factors:

No licensing cost (LGPL-3.0)
Infrastructure scales with beneficiary count and concurrent users
Customisation requires Python/Odoo development expertise
Partner network available for implementation support

Mojaloop

Type: Open source
Licence: Apache 2.0
Current version: Congo v16.0.0 (named release)
Deployment options: Self-hosted (Kubernetes required)
Source repository: https://github.com/mojaloop
Documentation: https://docs.mojaloop.io

Overview

Mojaloop provides reference implementation software for instant payment system interoperability. The platform enables Digital Financial Service Providers (DFSPs) to exchange payments through a central hub that handles clearing and settlement. The Bill & Melinda Gates Foundation’s Level One Project created and released the software in 2017 to reduce technical barriers to financial inclusion.

The architecture centres on a central ledger service coordinating transfers between connected DFSPs. Components handle identity lookup (Account Lookup Service), fraud management, transaction routing, and settlement. All communication follows the Financial Service Provider Interoperability (FSPIOP) API specification, ensuring standardised interactions regardless of the underlying DFSP technology.

Mojaloop operates as payment infrastructure rather than an application. Organisations do not interact with Mojaloop directly; instead, DFSPs (banks, mobile money operators, microfinance institutions) connect to Mojaloop switches to offer interoperable payments to their customers. For CVA, a humanitarian organisation’s payment partner connects to the Mojaloop switch, enabling disbursement to any wallet or account on the connected network.

Capability assessment for CVA

Mojaloop addresses the payment infrastructure layer of CVA operations. When a humanitarian organisation needs to disburse cash to beneficiaries holding accounts at multiple FSPs, a Mojaloop switch enables single-connection access to all participating providers. This eliminates the need for bilateral integrations with each FSP.

The platform does not manage beneficiaries, calculate entitlements, or generate payment lists. These functions reside in upstream systems (such as OpenSPP) that produce payment instructions. Payment Hub EE or similar orchestration layers translate these instructions into Mojaloop API calls.

Mojaloop’s value for CVA depends on deployment context. In countries with national instant payment systems built on Mojaloop (Tanzania TIPS, Philippines Higala), humanitarian organisations benefit from existing infrastructure. In contexts without Mojaloop deployment, the substantial investment required to establish a switch limits applicability.

Key strengths:

Proven instant payment infrastructure with national-scale deployments
Standardised FSPIOP APIs ensure consistent integration patterns
Comprehensive settlement and clearing functionality
Active foundation governance with major financial inclusion stakeholders
Extensive documentation and testing tools

Key limitations:

Substantial deployment complexity requiring Kubernetes expertise
Not applicable without participating DFSPs; requires ecosystem development
No beneficiary management or CVA programme logic
Resource-intensive infrastructure requirements
Requires DFSP integration development for each participant

Deployment and operations

Self-hosted requirements:

Operating system: Linux (container-based)
Orchestration: Kubernetes 1.21+ (required)
Database: MySQL 8+, TigerBeetle (optional for performance)
Message queue: Kafka
Minimum resources: 16 CPU, 32GB RAM, 100GB storage
Recommended production: 32+ CPU, 64GB+ RAM, distributed cluster

Deployment complexity: High. Production deployment requires Kubernetes expertise, security hardening, and HA configuration. Infrastructure as Code (IaC) v5.0.0 provides deployment automation.

Operational overhead: High. Operates critical financial infrastructure with corresponding monitoring, incident response, and change management requirements.

Upgrade path: Named releases (Acacia, Zambezi, Congo) with documented migration. Release cadence tied to Program Increment cycles.

Integration capabilities

Integration point	Protocol	Documentation
DFSP connection	FSPIOP API	Comprehensive
Settlement	Settlement API	Comprehensive
Account lookup	ALS API	Comprehensive
Admin operations	Administration API	Comprehensive
Reporting	Reporting API	Available

Mojaloop does not “integrate” with other systems in the traditional sense. It provides APIs that DFSPs implement connectors against. The SDK Scheme Adapter reference implementation demonstrates connector patterns for DFSPs connecting their systems to a Mojaloop switch.

Cost analysis

Mojaloop deployment typically occurs at national or regional level with costs borne by scheme operators, central banks, or consortia rather than individual humanitarian organisations. Direct deployment by a humanitarian organisation is atypical.

Component	Consideration
Infrastructure	Enterprise Kubernetes cluster (significant)
Integration	DFSP connector development per participant
Operations	24/7 operations team for financial infrastructure
Governance	Scheme rules, regulatory compliance

Mifos Payment Hub EE

Type: Open source
Licence: MPL-2.0 (Mozilla Public License)
Current version: 1.13.0
Deployment options: Self-hosted (Kubernetes preferred), cloud deployment
Source repository: https://github.com/openMF (ph-ee-* repositories)
Documentation: https://mifos.gitbook.io/docs/payment-hub-ee

Overview

Mifos Payment Hub Enterprise Edition provides payment orchestration middleware connecting account management systems to real-time payment switches. The platform abstracts payment system complexity behind a consistent API, enabling core banking systems and wallets to participate in instant payment networks without direct integration work.

The architecture uses Zeebe (Camunda’s workflow engine) to orchestrate payment workflows defined in BPMN notation. Connectors handle communication with external systems: account management system connectors link to core banking platforms (Fineract, Mifos X); payment system connectors interface with switches (Mojaloop). Channel connectors enable mobile apps and other interfaces to initiate transactions.

The Mifos Initiative developed Payment Hub EE with grants from DIAL and the Gates Foundation to create an end-to-end open source architecture for digital financial services. The platform complements Mifos X and Apache Fineract core banking systems, though it can connect to other account management systems through custom connectors.

Capability assessment for CVA

Payment Hub EE addresses the orchestration layer between CVA management systems and payment infrastructure. When OpenSPP or another MIS generates payment instructions, Payment Hub EE can sequence the resulting transactions, manage batch processing, handle errors and retries, and reconcile completion status.

The platform’s BPMN-based workflow engine provides flexibility for complex payment scenarios. G2P (Government to Person) payment workflows are documented, including bulk disbursement patterns relevant to humanitarian cash transfers. The modular connector architecture allows integration with various FSPs beyond the reference Mojaloop connector.

Integration with upstream beneficiary management systems requires custom development. Payment Hub EE does not maintain beneficiary registries or programme logic; it executes payment instructions received via API or bulk file upload.

Key strengths:

BPMN workflow engine enables complex payment orchestration
Pre-built Mojaloop connector reduces integration effort
Multi-tenant architecture supports shared service models
Active development with regular releases
DPG certified with humanitarian use case focus

Key limitations:

Requires Zeebe/Camunda expertise for workflow customisation
Account management connector development needed for non-Mifos systems
Limited pre-built connectors for humanitarian ecosystem systems
Documentation depth varies across components
Kubernetes deployment adds operational complexity

Deployment and operations

Self-hosted requirements:

Operating system: Linux (container-based)
Orchestration: Kubernetes (preferred) or Docker Compose
Database: MySQL 8+
Workflow engine: Zeebe (included)
Minimum resources: 8 CPU, 16GB RAM, 50GB storage
Recommended production: 16 CPU, 32GB RAM, 100GB storage

Deployment complexity: Medium-High. Helm charts available for Kubernetes deployment. Lab environment provided for evaluation.

Operational overhead: Medium. Zeebe cluster requires monitoring; payment workflows require operational oversight.

Upgrade path: Semantic versioning with release notes documenting breaking changes.

Integration capabilities

Integration	Type	Status
Mojaloop	Native connector	Production
Mifos X/Fineract	Native connector	Production
Mobile money (reference)	Connector template	Reference
Channel (mobile app)	API	Documented
Bulk file processing	API	Production

API details:

REST APIs for transaction initiation, status, and administration
Callback webhooks for async notifications
Bulk upload API for batch processing

Cost analysis

Deployment model	Infrastructure cost (small)	Infrastructure cost (medium)
Self-hosted cloud	$200-400/month	$600-1,200/month
Mifos lab environment	Free (evaluation)	N/A

Cost factors:

No licensing cost (MPL-2.0)
Zeebe cluster sizing affects infrastructure cost
Connector development for non-standard integrations
Mifos Initiative provides community support; commercial support via partners

OpenFn

Type: Open source
Licence: LGPL-3.0
Current version: Lightning v2.14.8
Deployment options: SaaS (openfn.org), self-hosted (Docker/Kubernetes)
Source repository: https://github.com/OpenFn/lightning
Documentation: https://docs.openfn.org

Overview

OpenFn provides a workflow automation platform for data integration and system interoperability. The platform enables organisations to connect applications, automate data flows, and orchestrate multi-step processes without building custom integration code. Lightning (v2), released in 2024, introduced a visual workflow builder lowering the technical barrier to integration development.

The architecture separates workflow definition from execution. Users design workflows through the web interface, specifying triggers, transformations, and destination systems. The runtime engine executes workflows using adaptors (pre-built connectors) that handle authentication and API interaction with target systems. Over 70 adaptors cover common humanitarian and development sector systems.

OpenFn specifically targets non-profit and government organisations, with deployments across 40+ countries. The platform achieved DPG certification and maintains active community engagement through forums, documentation, and regular releases.

Capability assessment for CVA

OpenFn functions as integration infrastructure connecting CVA ecosystem components. When organisations operate separate systems for registration (KoboToolbox), case management (Primero), beneficiary tracking (DHIS2), and payments, OpenFn synchronises data between them. This reduces manual data entry, ensures consistency, and enables automated workflows.

Typical CVA integration patterns include:

Registration data from mobile collection tools to beneficiary management systems
Eligibility updates triggering payment list generation
Payment status from FSPs updating programme monitoring systems
Aggregated programme data to donor reporting platforms

OpenFn does not provide CVA business logic (eligibility, entitlements, payment processing). It moves and transforms data between systems that implement this logic. The platform adds value in fragmented technology landscapes where multiple point solutions must interoperate.

Key strengths:

70+ pre-built adaptors covering humanitarian sector systems (DHIS2, Primero, CommCare, ODK)
Visual workflow builder reduces technical barrier
Both SaaS and self-hosted deployment options
Strong error handling with retry logic and alerting
Active development with frequent releases

Key limitations:

Not a CVA platform; provides integration infrastructure only
Limited direct payment provider adaptors
Custom adaptor development requires JavaScript expertise
SaaS pricing based on workflow execution volume
Complex multi-system integrations require technical design

Deployment and operations

Self-hosted requirements:

Operating system: Linux (Debian/Ubuntu)
Runtime: Elixir, PostgreSQL
Container: Docker (optional)
Minimum resources: 2 CPU, 4GB RAM, 20GB storage
Recommended production: 4 CPU, 8GB RAM, 50GB storage

Deployment complexity: Low-Medium. Docker deployment straightforward; production configuration requires attention to worker scaling and credential management.

Operational overhead: Low. Managed SaaS option eliminates operational burden; self-hosted requires standard application operations.

Upgrade path: Semantic versioning with documented changelog. Migration from v1 to Lightning (v2) supported.

Integration capabilities

Adaptor	Status	CVA relevance
DHIS2	Production	Programme monitoring
Primero	Production	Protection case management
CommCare	Production	Mobile data collection
ODK	Production	Mobile data collection
Kobo	Production	Mobile data collection
Salesforce	Production	CRM/donor management
FHIR	Production	Health system integration
HTTP (generic)	Production	Any REST API

Workflow capabilities:

Trigger types: webhook, cron schedule, flow trigger
Data transformation: JavaScript-based with state management
Error handling: configurable retry, alerting, manual retry from UI
Audit: comprehensive run history with input/output visibility

Cost analysis

Deployment model	Cost
SaaS Free tier	$0/month (limited runs)
SaaS Starter	$50/month
SaaS Professional	Custom pricing
Self-hosted	Infrastructure only

Cost factors:

SaaS pricing scales with execution volume
Self-hosted eliminates per-run costs
Adaptor development for uncovered systems
Implementation services available from OpenFn and partners

Selection guidance

Decision framework

                              +------------------+
                              | What CVA stack   |
                              | component needed?|
                              +--------+---------+
                                       |
         +-----------------------------+-----------------------------+
         |                             |                             |
         v                             v                             v
+--------+--------+           +--------+--------+           +--------+--------+
| Beneficiary     |           | Payment         |           | System          |
| management      |           | infrastructure  |           | integration     |
+-----------------+           +-----------------+           +-----------------+
         |                             |                             |
         v                             v                             v
     OpenSPP                 +---------+---------+                OpenFn
                             |                   |
                             v                   v
                    +--------+-------+   +-------+--------+
                    | Payment switch |   | Orchestration  |
                    | (national)     |   | (DFSP/org)     |
                    +----------------+   +----------------+
                             |                   |
                             v                   v
                         Mojaloop        Mifos Payment Hub EE

Recommendations by context

Organisations needing beneficiary management

Primary recommendation: OpenSPP

OpenSPP provides the only assessed solution with native beneficiary registration, eligibility determination, and entitlement calculation. Organisations without existing beneficiary management systems should evaluate OpenSPP as the foundation of their CVA technology stack.

Requirements:

Odoo/Python development capacity for customisation
Integration development to connect to payment infrastructure
Infrastructure for self-hosted deployment or partner for managed hosting

Alternative: If beneficiary management exists in another system (e.g., Primero for protection cases), use OpenFn to integrate with payment systems rather than replacing the existing solution.

Organisations connecting to Mojaloop-based payment systems

Primary recommendation: Mifos Payment Hub EE

When the target payment infrastructure uses Mojaloop (national instant payment system, regional switch), Payment Hub EE provides the pre-built connector and orchestration layer to initiate and track payments.

Requirements:

Kubernetes deployment capability
Upstream system (OpenSPP or other) for beneficiary management
BPMN/Zeebe expertise for workflow customisation

Alternative: Direct integration with Mojaloop APIs if payment patterns are simple and organisation has development capacity.

Organisations integrating multiple CVA systems

Primary recommendation: OpenFn

When CVA operations span multiple systems (mobile data collection, case management, payment tracking, M&E) that require data synchronisation, OpenFn provides integration infrastructure without replacing existing solutions.

Requirements:

Clear data flow requirements between systems
JavaScript capacity for custom adaptor development if needed
Either SaaS subscription or self-hosted infrastructure

Alternative: Point-to-point integrations using native APIs if connecting only two systems with stable requirements.

National governments or payment scheme operators

Primary recommendation: Mojaloop

Governments establishing national instant payment infrastructure should evaluate Mojaloop as the payment switch enabling interoperability between DFSPs. This benefits CVA programmes by providing single-connection access to all participating FSPs.

Requirements:

National-scale infrastructure and operations capacity
Regulatory framework for payment scheme operation
Multi-stakeholder governance for scheme rules

Note: Individual humanitarian organisations do not deploy Mojaloop; they benefit from connecting to existing Mojaloop-based switches through participating FSPs.

Combined stack patterns

Pattern A: Complete open source CVA stack

+------------------+     +----------------------+     +------------------+
|                  |     |                      |     |                  |
|    OpenSPP       +---->+ Mifos Payment Hub EE +---->+    Mojaloop      |
|                  |     |                      |     |    Switch        |
| - Registration   |     | - Orchestration      |     |                  |
| - Eligibility    |     | - Retry logic        |     | - Clearing       |
| - Entitlements   |     | - Reconciliation     |     | - Settlement     |
| - Cycle mgmt     |     |                      |     |                  |
+------------------+     +----------------------+     +--------+---------+
                                                               |
                                                    +----------+----------+
                                                    |                     |
                                               +----v----+          +-----v----+
                                               |  Bank   |          |  Mobile  |
                                               |  DFSP   |          |  Money   |
                                               +---------+          +----------+

This pattern provides end-to-end open source infrastructure from beneficiary registration through payment settlement. Suitable for organisations with capacity to deploy and maintain all components, or governments building national social protection systems.

Pattern B: OpenSPP with direct FSP integration

+------------------+     +------------------+
|                  |     |                  |
|    OpenSPP       +---->+   FSP APIs       |
|                  |     |                  |
| - Registration   |     | - Mobile Money   |
| - Eligibility    |     | - Bank Transfer  |
| - Entitlements   |     | - Agent Network  |
| - Cycle mgmt     |     |                  |
+------------------+     +------------------+

Simpler pattern when connecting to FSPs directly (without interoperability switch). Requires payment manager connector development in OpenSPP for each FSP. Suitable when working with limited FSP partners in a single country.

Pattern C: Existing systems with OpenFn integration

+-------------+     +------------------+     +------------------+
|             |     |                  |     |                  |
| KoboToolbox +---->+                  +---->+ Beneficiary DB   |
|             |     |                  |     |                  |
+-------------+     |                  |     +------------------+
                    |     OpenFn       |
+-------------+     |                  |     +------------------+
|             |     |                  |     |                  |
|  Primero    +---->+                  +---->+ DHIS2 Tracker    |
|             |     |                  |     |                  |
+-------------+     +--------+---------+     +------------------+
                             |
                             v
                    +--------+--------+
                    |                 |
                    |  Payment FSP    |
                    |                 |
                    +-----------------+

Integration-first pattern when organisations already use established tools and need data synchronisation rather than replacement. OpenFn coordinates data flows; each system retains its function.

Resources and references

Official documentation

Tool	Documentation	API reference	Source code
OpenSPP	https://docs.openspp.org	https://docs.openspp.org/developer_guide	https://github.com/OpenSPP
Mojaloop	https://docs.mojaloop.io	https://docs.mojaloop.io/api	https://github.com/mojaloop
Mifos Payment Hub EE	https://mifos.gitbook.io/docs/payment-hub-ee	https://docs.mifos.org	https://github.com/openMF
OpenFn	https://docs.openfn.org	https://docs.openfn.org/adaptors	https://github.com/OpenFn

Relevant standards

Standard	Description	URL
Level One Project	Inclusive digital payment system design principles	https://leveloneproject.org
FSPIOP	Financial Service Provider Interoperability API specification	https://docs.mojaloop.io/api
CALP Glossary	CVA terminology and definitions	https://www.calpnetwork.org
Digital Public Goods Standard	Criteria for DPG certification	https://digitalpublicgoods.net

Resource	Publisher	Description
State of the World’s Cash 2023	CALP Network	CVA sector analysis and trends
Investigating Safe Data Sharing	CALP Network	Interoperability guidance for CVA
DCF Interoperability Principles	Donor Cash Forum	Data sharing principles for cash programming