Digitizing Payments Process Kit

Work Plan, Framework, and Practical Tools

United States Agency for International Development

Bill & Melinda Gates Foundation

TABLE OF CONTENTS
1. Introduction ............................................................................................................................................. 3
2. Background .............................................................................................................................................. 4
3. Work Plan ................................................................................................................................................. 6
3.1 Project Schedule ...........................................................................................................................................6
3.2 Project Stages ...............................................................................................................................................6
4. Digitizing Payments Process and Resources ............................................................................. 11
4.1 Digitization Process Flow ............................................................................................................................11
4.2 Document Reference Chart ........................................................................................................................15
5. Conclusion ............................................................................................................................................. 16
5.1 Benefits .......................................................................................................................................................16
5.2 Challenges and Mitigations ........................................................................................................................16
5.3 Key Lessons Learned ...................................................................................................................................17

Digitizing Payments Process Kit

February 20, 2014 Page 2 of 94
1. Introduction
Globally, governments, the development community, and the private sector distribute billions of
dollars in payments to individuals for salaries, supplier fees, social welfare stipends, cash-for-work
programs, emergency relief payments, and other purposes.1 Most of these disbursements are cash
transactions, presenting operational and security challenges, particularly in countries with limited
physical and financial infrastructure, as they require carrying cash in small denominations from
urban centers to remote rural areas. More specifically, cash payments can bear high financial and
social costs related to:
 Security – Individuals who carry large sums of cash, including merchants, couriers, payment
beneficiaries, and parents paying school fees, are targets of theft.
 Transparency and accountability – Cash cannot be tracked and, therefore, it is impossible
to document its disappearance. With mobile or electronic payments, transactions can be
tracked. A recent CGAP survey found that Mobile Network Operators (MNOs) are taking
oversight seriously, with each MNO having a dedicated staff to monitor and investigate
suspicious or unusual transactions.
 Transportation – Hiring couriers to safely transport bags of cash to disbursement sites can
be very expensive.
 Development – Moving cash from one location to another is expensive and time-
consuming, reducing profit margins and growth opportunities for private businesses and
development organizations. However, mobile money and electronic payments significantly
lower transaction costs and enable sustainable fee-for-service models.2

Shifting cash-based payments to electronic distribution methods creates considerable benefits for
individuals, communities, and economies. Mobile phone-based money systems reduce the costs of
transferring cash to remote populations, especially in areas with few financial institutions. Transfer
recipients have a relatively safe and reliable alternative to cash when receiving (and making)
payments, provided they have ready access to mobile money service providers.3 Further, research
on the impact of digital payment systems in Kenya suggests that households were able to increase
their access to financial services and informal private transfers between individuals, allowing them
to better manage financial shocks.4

To identify more effective ways of processing digital payments, Vital Wave, in partnership with the
Bill and Melinda Gates Foundation, conducted extensive research in Kenya, Tanzania and Uganda.
The aim of this research was to understand the stakeholder landscape and how mobile money
systems have been successfully utilized by organizations to make payments to their beneficiaries.
In Uganda, specifically, Vital Wave interviewed a cross section of local stakeholders in order to
understand the challenges and opportunities of using mobile money to make bulk payments.

Vital Wave then worked with six USAID implementing partners to assist them in making the
transition to digital payments for their beneficiaries. The project engaged key stakeholders,

1
Better Than Cash Alliance
2
USAID Blog, [Link]
3
Center for Global Development, Zap It to Me: The Short-Term Impacts of a Mobile Cash Transfer Program
4
Center for Global Development, Zap It to Me: The Short-Term Impacts of a Mobile Cash Transfer Program

Digitizing Payments Process Kit

February 20, 2014 Page 3 of 94
including USAID implementing partners and their beneficiaries, USAID Uganda Mission, MNOs,
payment aggregators, and Ugandan regulators. The project supported six USAID implementing
partners to transition away from cash payments in the field to bulk payments via mobile money.

This “Digitizing Payments Process Kit” describes the process and shares useful materials developed
to facilitate the transition to digital bulk payments by USAID implementing partners to their
beneficiaries. The Kit includes a work plan, process manuals, guidelines, and other resource
documents. It is intended to inform and guide USAID missions, donor agencies, implementing
partners, MNOs, Business Process Outsourcing vendors, or aggregators, and other interested
service or technology providers.

2. Background
This section provides a brief overview of access to mobile technology and electronic payments,
specifically in sub-Saharan Africa. This section also includes diagrams that capture the current
model and the recommended model for the distribution of bulk payments.

Technologies such as mobile phones and the Internet have enabled millions of new users to access
financial services in many developing countries. When technology is combined with business
processes, electronic payments can be made inexpensively and transparently.

However, in most of sub-Saharan Africa, only a small percentage of upper-income households use
card-based, online, or mobile banking and payment systems. Most consumers still pay with cash.
One study shows that more than 90% of retail transactions in parts of Kenya remain cash-based,
and Gallup’s survey of 11 countries in sub-Saharan Africa found that fewer than 20% of adults have
made bill payments or remittances via mobile money. 5

A lack of mobile technology is not the major obstacle to increasing mobile money penetration in
the region: two-thirds of adults in sub-Saharan Africa currently use mobile phones. Instead, mobile
money adoption is held back by the dearth of financial institutions, a discouraging regulatory
environment, lack of trust in banks or telecommunication providers, or a limited agent network.
For organizations that distribute large sums of money to diverse recipients, however, the benefits
of mobile money are clear. USAID, for example, argues that digital payments lead to broader
financial inclusion, as well as improvements in transparency, security, and cost savings for both
governments and intermediaries (banks).6

Digitizing payments has the potential to transform the way implementing partners make small
payments to beneficiaries around the world. In Uganda, where USAID is the largest donor, and
NGOs typically have multiple funding partners, a well-implemented digitization process can change
the way beneficiary payments are made, increasing operational effectiveness and financial
efficiency.

5
Sub-Saharan Africa: A major potential revenue opportunity for digital payments, McKinsey & Company
6
Ibid.

Digitizing Payments Process Kit

February 20, 2014 Page 4 of 94
Currently, many organizations are attempting to distribute bulk payments by working directly with
MNOs (see Figure 1). This model creates many redundancies, and implementing partners are not
able to perform many needed functions due to the limitations of the MNO platforms. As a result of
the inherent limitations posed by working with the MNOs, an alternative approach is proposed.
Working with an intermediary such as an aggregator simplifies operations, both to the
implementing partners and to USAID (see Figure 2). Further, this approach increases transparency
throughout the entire payments value chain.

This “Digitizing Payments Process Kit” provides useful resources for organizations to implement an
Aggregator Payment Model. Below, and in the Appendices, readers will find the organizing
process, framework and practical resources used in the Uganda Digital Payments project, with the
recognition that any digitization effort is unique and will be informed by country context,
stakeholder interests and other factors.

Figure 1 – Direct-to-MNO Payment Model Figure 2 – Aggregator Payment Model

Donor Donor

Implementing Implementing Implementing

Implementing Implementing Implementing Partner Partner Partner
Partner Partner Partner

MNO: Airtel/Warid MNO: Airtel/Warid MNO: Airtel/Warid Aggregator

MNO: MTN MNO: MTN MNO: MTN

MNO: Airtel/Warid MNO: MTN
MNO: Orange MNO: Orange MNO: Orange
MNO: Orange MNO: UTL
MNO: UTL MNO: UTL MNO: UTL

Beneficiaries
Beneficiaries

Digitizing Payments Process Kit

February 20, 2014 Page 5 of 94
3. Work Plan
This section provides a proposed project schedule and detailed project stages recommended for
the design, management, and implementation of a pilot digitization project. When entering a new
country, implementing a well-designed pilot that engages several key implementing partners is
critical.

3.1 Project Schedule

The project schedule provides a visual, five-month timetable to make the transition to digital
payments, from kickoff to review.

MONTH 1 MONTH 2 MONTH 3 MONTH 4 MONTH 5

Week 11
Week 10

Week 12

Week 13

Week 14

Week 15

Week 16

Week 17

Week 18

Week 19

Week 20
Week 2

Week 5
Week 3

Week 4

Week 6

Week 7

Week 8

Week 9
Week 1

Kickoff meeting
KICKOFF

Selection

Contracts

Training
PILOT

Test Pilot

Review PHASE 1 PHASE 2 PHASE 3 FINAL REVIEW

Kickoff meeting
Selection
Procurement and contractual arrangements with aggregators
Training
Review and iteration report
Pilot
Final Report

3.2 Project Stages

This section provides a detailed overview of activities at the week and month level across each
stage in the process of transitioning to digital payments. The project is broken down into four
stages: 1.) In-country Kickoff, 2.) Development and Testing, 3.) Pilot (further divided into three
phases), and 4.) Final Review. For each stage, a list of direct actions is provided, involving
coordination among a variety of stakeholders, to ensure the completion of each stage.

This work plan was developed for use in a pilot study involving several implementing partners. If,
however, a single organization wishes to implement mobile payments, it can follow this work plan
by omitting certain activities specific to the running of a pilot. Further, the work plan assumes
implementation by a third-party Project Manager. If, however, it is implemented directly by a
donor agency, specific donor coordination and approval tasks can be omitted. It should also be
noted that, while specific weeks have been allocated for review meetings with donors, review
meetings with implementing partners are to be held continuously throughout the project.

Digitizing Payments Process Kit

February 20, 2014 Page 6 of 94
Stage 1: In-country Kickoff

1.1 Introduce Project Team and Pilot to Stakeholders

The Project Manager meets with all key stakeholders to introduce the pilot, gauge interest, and
capture relevant data related to the pilot.

Timeframe Stakeholders Actions

Week 1 Donor agency, MNOs, payment Meet with key stakeholders to introduce the project team and discuss plan of
aggregators action
Week 1 Donor agency, implementing Kickoff meeting to introduce the pilot and answer questions from implementing
partners partners
Month 1 Regulators Meet with relevant regulators to discuss regulatory environment and introduce
pilot

1.2 Select Partners

Following consultations with MNOs and the donor agency and a call for applications, the Project
Manager selects payment aggregators (preferably three) and implementing partners (preferably
five).

Timeframe Stakeholders Actions

Week 1 Donor agency Meet with donor agency to discuss criteria of selection and application process

Week 1 Implementing partners, Launch application process for implementing partners and payment aggregators
payment aggregators
Week 2 Implementing partners Meet with each implementing partners to gain better understanding of their
operations
Week 3 Donor agency Select 5 implementing partners following consultation with donor agency

Week 3 Agency, Implementing partners Select 3 aggregator partners (1 preferred and 2 backups)

1.3 Negotiations
The Project Manager conducts negotiations over bulk payment pricing with MNOs and with
payment aggregators.

Timeframe Stakeholders Actions

All Months MNOs Hold discussions with MNOs over bulk discount

Week 3 Payment aggregators Negotiate bulk payment rate card with shortlisted payment aggregators

Weeks 3 – 7 MNOs, payment aggregators, Finalize agreements and aggregator integration schedules
implementing partners

Digitizing Payments Process Kit

February 20, 2014 Page 7 of 94
1.4 Identify Key Potential Risks
Following an evaluation of the landscape and meetings with stakeholders, it is advisable to identify
key risks, as well as a mitigation strategy or contingency plan for each risk.

Timeframe Stakeholders Actions

Month 1 MNOs, payment aggregators, Meet with stakeholders to identify key areas of potential risk
implementing partners
Month 1 MNOs, payment aggregators, Design action plan and develop strategies to mitigate against potential risks
implementing partners

Stage 2: Development, Testing and Change Management

1.5 Software Development and Technical Integration

Software is developed to meet requirements defined by implementing partners.

Timeframe Stakeholders Actions

Months 1 – 5 Payment aggregators, Consultation meetings with implementing partners and payment aggregators
implementing partners
Months 1 – 5 Payment aggregators Aggregators develop any necessary software under supervision of Project Manager

Months 1 – 5 Payment aggregators, MNOs Aggregators to update their APIs with MNOs where necessary to deliver on the
project requirements

1.6 Define New Payment Processes

Digital payment processes are developed with implementing partners and payment aggregators.

Timeframe Stakeholders Actions

Weeks 4 – 6 Implementing partners Meet implementing partners to document payment processes

Weeks 4 – 6 Implementing partners, Identify key areas of change needed for transition to mobile payment systems
payment aggregators

Weeks 4 – 6 Implementing partners, Meet with stakeholders to design digital process

payment aggregators, MNOs

2.1 Training
Training materials are developed detailing digital payment processes and troubleshooting in a
user-friendly manner. Trainings for implementing partners are conducted by payment aggregators.

Timeframe Stakeholders Actions

Months 1 - 2 MNOs, payment aggregators Develop training materials

Month 2 Payment aggregators, Training session for implementing partners

implementing partners

Digitizing Payments Process Kit

February 20, 2014 Page 8 of 94
2.2 Test Software

Software that has been developed is tested to ensure it complies with specific requirements.

Timeframe Stakeholders Actions

Month 2 Payment aggregators, Testing of bulk payment software
implementing partners
Month 2 Payment aggregators Beta testing

Month 2 Payment aggregators Sign off User Acceptance Testing (UAT)

2.3 Encourage Internal Buy-in

Supporting internal buy-in is essential, so that implementing partners will receive support for their
change management processes. They will also benefit from sharing experiences with other pilot
partners and other successful organizations.

Timeframe Stakeholders Actions

Weeks 1 - 3 Implementing partners Communicate decision to transition to digital payments to home office, local and
field staff

Week 3 Implementing partners Set up team of finance staff to help stir the process forward

Month 2 Implementing partners Initiate change management processes and the development of digital payment
policies

Month 2 Implementing partners Communicate new policy clearly to field staff and draft presentation that staff
can start sharing with beneficiaries at trainings

Stage 3: Proof-of-concept – Limited Implementation

A three-month proof-of-concept stage is recommended. Payments can be made in a staggered

manner. It is recommended to carry out first test payments with staff. As confidence in the system
grows implementing partners can start to roll-out payments, starting with one training session, and
increasing in number over time, depending on the project needs and activity schedule. Reviews
should be held regularly with all stakeholders, as required.

Phase 1: Primary implementation

Timeframe Stakeholders Actions

Week 6 - 7 Implementing partners Identify targets for primary digital payment test

Week 7 Donor agency, implementing Review meeting

partners
Week 7 Payment aggregators, MNOs, Launch small number of test payments to staff
implementing partners
Weeks 7 – 11 Payment aggregators, MNOs, Implement changes according to review results
implementing partners

Digitizing Payments Process Kit

February 20, 2014 Page 9 of 94
Phase 2: Second iteration of implementation

Timeframe Stakeholders Actions

Weeks 9 - 10 Implementing partners Make first test payments to beneficiaries attending a small trainings session
in an urban area

Month 3 Payment aggregators, MNOs, Gradually increase number of payments made to target beneficiaries
implementing partners

Week 11 Donor agency, implementing Review meeting

partners

Weeks 11 – 16 Implementing partner field staff, Receive feedback from field staff and beneficiaries
beneficiaries

Weeks 11 – 16 Payment aggregators, MNOs, Implement necessary changes according to feedback received from review
implementing partners meeting and field staff

Phase 3: Third iteration of implementation

Timeframe Stakeholders Actions

Month 4 Payment aggregators, MNOs, Increase number of payments made to target beneficiaries
implementing partners
Month 4 Implementing partners Receive feedback from field staff and beneficiaries

Week 16 Donor agency, implementing Conduct monthly review meetings

partners

Week 16 – 21 Payment aggregators, MNOs, Implement changes according to feedback received

implementing partners

Stage 4: Final Review

The final review is conducted to share strategic recommendation with all stakeholders and to
develop useful materials for future transitions.

Timeframe Stakeholders Actions

Week 20 Implementing partners, payment Conduct overall review with key stakeholders
aggregators, MNOs and donor agency
Month 5 Project manager Revise and share materials useful for workshops in other donor
agencies
Month 5 Donor agency Present findings to donor

Digitizing Payments Process Kit

February 20, 2014 Page 10 of 94
4. Digitizing Payments Process and Resources
Vital Wave has identified four pillars that make up the process for transitioning to digital payments:
Digital Adoption, Beneficiary Data Collection, Payment Process and Reconciliation and Issue
Resolution (Figure 1, below). Each pillar represents a critical part of any digital payments policy and
must be carefully thought out. While digital adoption is a one-time process that provides the
foundation for switching to a digital payment system, all other pillars are continuously utilized
throughout the digital payment process and can be reviewed and improved as payments increase
and as an organization becomes comfortable with the process and aware of any inefficiencies.

This section provides a checklist of essential activities for each pillar, as well as a Document
Reference Chart that maps out practitioner resources by pillar and by stakeholder. The resources
listed in the Document Reference Chart can be found in the Appendix.

4.1 Digitization Process Flow

Figure 1. Four Pillars of Digital Adoption

Digitizing Payments Process Kit

February 20, 2014 Page 11 of 94
Digital Adoption

Digital Adoption involves the technical and operational adjustments to be made by implementing
partners and other mobile money stakeholders. It is time-consuming but crucial. It is necessary to
not underestimate the amount of time it takes to get the foundations for a transition right.

Digital Adoption Checklist

Design a plan for internal communication of transition to home office, local
office and field staff
Communicate decision to digital payments to home office, country office and
field staff
Secure the necessary approvals
Conduct procurement of aggregators through interviews, testing of systems and
due diligence
Collect all necessary documentation for account set up
Review and signing of contract by legal teams in local or home office
Training for all user of new payment system
Clarify account funding procedures and agree on deadlines for account funding
with aggregator
Set up user accounts
Update documentation used at trainings to capture mobile numbers of
beneficiaries
Update travel advance forms to capture mobile numbers of staff
MNOs invited to organization office to register staff for mobile money
Identify date for first test payment to staff
Field staff communicate new policy to beneficiary community
Beneficiaries encouraged to register for mobile money by field staff
MNOs invited to attend trainings to register participants and present on how to
use mobile money
First test payment made to beneficiaries community
Design plan for scaling of digital payments to all desired locations

Beneficiary Data Collection

Working to improve planning at the beneficiary data collection stage, the implementing partner
can reduce the amount of time and human resources required to make payments by improving
the accuracy of data. Beneficiaries should be warned well in advance that they will be paid using
mobile money, allowing them enough time to register for the service and to share their number
with program staff if they have not done so already.

For countries where beneficiaries must be registered for mobile money in order to receive
funds, beneficiaries can be asked if their phones ‘send and receive money,’ rather than if their
phones are ‘registered for mobile money.’ This reduces misunderstandings that may arise if
beneficiaries think that being registered for mobile money is the same as having a registered
SIM card.

Digitizing Payments Process Kit

February 20, 2014 Page 12 of 94
 Beneficiary Data Collection Checklist
Invitation sent to all training participants informing them they will be paid
using mobile money and requesting their mobile money-registered numbers
Program staff collects data including beneficiary names, titles, and mobile
money-registered phone numbers prior to training activity and sends to
finance staff for pre-verification.
In office: pre-verification and approval of beneficiary information by
finance staff
At training: beneficiaries provide field staff with name and numbers on day
of training
Beneficiary information sheet transferred to finance staff at HQ for final
verification and payment processing

Payment Processing and Reconciliation

The digital payment process mirrors the cash payment process in a number of ways, but instead of
transferring money to a bank, cash is transferred to the aggregator’s account. From an operational
standpoint, there is also a change in accounting procedures, as cash being sent to the field is no
longer treated as an advance but can be reconciled in real time.

Payment Processing Checklist

Calculate total amount to be paid out, including aggregator, MNO and
withdrawal charges
Transfer amount to aggregator account in accordance to pre-agreed
deadlines in order to ensure funds are available for payment
Alert aggregator of payment schedule
Create payment sheet on CSV or excel with name, number and amount to
be paid to each beneficiary and upload onto aggregator platform by finance
staff
Send payment sheet for verification
Verification of list of numbers and names against database and amount to
be paid carried out by finance staff
Approval of payment made by authorized staff
Beneficiaries receive notification alerting them to payment made on their
mobile money account
Print payment report for immediate reconciliation

Digitizing Payments Process Kit

February 20, 2014 Page 13 of 94
Issue Resolution

Once payments are made, there are a number of issues that may arise which will require quick
resolution. It is important that all staff using the system are prepared for the issues that may arise
and have a clear understanding of how to handle the situation and, should it be required, who to
escalate the issue to.

Issue Resolution Checklist

Discuss potential scenarios with aggregator and get clear understanding of
escalation procedures
Design escalation flow charts and circulate among finance staff
Maintain good communication with aggregator relationship manager and
alert immediately in the event of an issue

Digitizing Payments Process Kit

February 20, 2014 Page 14 of 94
4.2 Document Reference Chart

The Appendix of this Kit includes resources developed for the Digital Payments Uganda project.
The documents, forms, presentations and other resources can be used or adapted by implementing
partners, MNOs, aggregators, and donors looking to implement a transition to digital payments.
The document reference chart below organizes the relevant materials for each stakeholder across
each pillar of the digitizing payments process, and indicates where they can be found in the
Appendix, for easy reference.

Digital Adoption Beneficiary Data Payment Processing Reconciliation &

Collection Issue Resolution
Implementing Business Requirements Attendance Financial Model for
Partners Document, App. 1.1 Sheet for Costs and Savings,
Selection Criteria for Trainings, App. App. 3.1
Implementing Partners and 2.1
Scorecard, App. 1.2
Digitizing Payments Application,
App. 1.3
Description Accompanying
Digitizing Payments Application,
App. 1.4
E-mail Accompanying Digitizing Payment Sheet Payment Sheets in
Payments Application, App 1.5 for Trainings, Excel, App. 3.2
Board Resolution, App. 1.6 App. 2.2
Presentation for Beneficiaries on
Transition, App. 1.7

MNOs Instructional Manual on How to Screenshot of

Use Mobile Money, App. 1.8 Message Sent to
Beneficiary Phone,
App. 3.3
Mobile Money Agent Training
Curriculum, App. 1.9
Aggregators Aggregator Procurement Process Bulk Payment e-mail Sample Report,
and Selection Criteria, App. 1.10 Notification, App. App. 4.1
Request for Information, App. 3.4
1.11
User Acceptance Testing
Checklist, App. 1.12
User Acceptance Testing Sample,
App. 1.13
Proposed Bulk Payment Contract,
App. 1.14
Required Documentation to
Register, App. 1.15
Business Account Opening Form,
App. 1.16
Authorization Letter, App. 1.17
User Training Manual, App. 1.18

Digitizing Payments Process Kit

February 20, 2014 Page 15 of 94
5. Conclusion
While the process of transitioning to digital payments can be daunting, the potential of a successful
transition are worth the investment. This section summarizes the benefits, challenges, and key
lessons learned from a successful transition to digital payments.

5.1 Benefits

There are a number of benefits to be gained by moving away from cash payments, particularly
within the development community and in a developing-country context.
 Staff no longer have to travel to the field with a large amount of cash, thus reducing the
security and fraud risk
 Reduction of cash leakages through loss and/or theft, minimizing the overhead spent on
fraud prevention
 Digital payments make it possible for organizations to conduct real-time reconciliations of
payments made to beneficiaries as opposed to waiting for receipts to be sent from the field
and processed at HQ
 Aggregator platforms and reporting functions make it possible for organizations to have
more accurate financial records of payments made to field staff and training participants
 Audit trails and reporting functions increase accountability and transparency and improve
the quality of reporting that can be presented to donors

5.2 Challenges and Mitigations

The process of transitioning to digital payments is not an easy one. It requires internal
coordination, planning, training and capacity building, and relies on external and environment-
specific requirements. The table below describes common challenges in the transition to digital
payments and offers strategies to address these potential barriers.

Challenge Mitigation Strategies

Challenge 1: Capacity of mobile money Mitigation: Implementing partners should conduct due diligence
partners: Modest levels of customer service on MNOs and partner aggregators prior to developing a
and capacity of mobile money partners make partnership with particular focus on issue resolution and
issue resolution difficult escalation mechanisms

Challenge 2: Poor agent network and liquidity: Mitigation: Notify MNOs of any large payments taking place in
Outside urban centers agent availability and areas with low agent penetration to support agent liquidity
liquidity can undermine the opportunities of a and presence. Simultaneously develop strategies to facilitate
mobile money system by making it difficult for access of agents for beneficiaries such as organizing training
beneficiaries to cash out sessions close to mobile money agents

Digitizing Payments Process Kit

February 20, 2014 Page 16 of 94
Challenge 3: Poor network availability Mitigation: Start by rolling out payments to beneficiaries located
in areas where network coverage exists. Encourage beneficiaries
Some beneficiaries may be in areas where little
to check their mobile money account balances when they
to no network coverage exists. In times of
expect to receive funds, even without a notification messages.
network outage, notification messages informing
Implementing partners can also call beneficiaries to alert them
beneficiaries of payments made may not arrive.
that funds have been transferred.

Challenge 4: Internal resistance to change Mitigation: Implementing partners should communicate with
home office, key decision makers and accounting staff of
Staff and beneficiaries may resist change to
decision to transition to digital payments early. Implementing
payment systems.
should be ready to address concerns and answer questions.
Once this is done an efficient service needs to be delivered for
beneficiaries to accept and embrace mobile payments as a
better alternative.

Challenge 5: Beneficiary data collection Mitigation: Develop internal processes that improve the quality
of data collected, such as collecting beneficiaries’ numbers
The data collection process can be time
prior to an event. Where possible, utilize software tools to
consuming, labor intensive and subject to error.
simplify the beneficiary data collection by electronically
Incorrect numbers and delays in transferring
collecting beneficiary phone numbers, thus improving
beneficiary data to HQ for payment processing
reliability and timeliness of data collected.
can delay payments.

Challenge 6: Payment delays due to technical Mitigation: Alert aggregator partners of payment schedule and
issues ensure that aggregator communicates any plans for upgrades
and/or foreseen technical issues in advance to assist planning.
Technical problems related to network outages
Unless confident in partners’ ability to carry out issue resolution
and/or internal upgrades on the part of the MNO
over the weekend, avoid making payments on a Friday.
or aggregator may lead to payment delays.

5.3 Key Lessons Learned

Based on Vital Wave’s experience in Uganda, the following key lessons were crucial for the
successful transition to a digital payments system:

 Organizations should conduct thorough due diligence of aggregator partners, paying

particular attention to their technical know-how, customer service and responsiveness.
 Engage the home office early, especially accounting staff, as there may be concerns that
require attention and delay the roll-out process.
 Do not underestimate the amount of time needed to build internal buy-in, agree on and
sign contracts, and set up user accounts.
 Conduct pre-tests with staff for testing the system internally, creating internal buy-in and
reducing the risk of beneficiary resistance.
 Make small incremental payments before rolling out to a large number of beneficiaries.
 Improve planning mechanisms and internal communication between finance and program
staff and communicate payment plans to partner aggregator regularly.

Digitizing Payments Process Kit

February 20, 2014 Page 17 of 94
6. Appendix
This section includes tools that can be used or adapted by implementing partners, MNOs,
aggregators, and donors looking to implement a transition to digital payments. Please reference
the Document Reference Chart in Section 4.2 above, and the table below, to navigate the resources
that follow.

Appendix 1.1 – Business Requirements Document..........................................................................................19

Appendix 1.2 – Selection Criteria for Implementing Partners and Scorecard..................................................26
Appendix 1.3 – Application for the ‘Digitizing Payments for USAID Beneficiaries in Uganda’ Program ..........27
Appendix 1.4 – Project Description Accompanying Digitizing Payments Application ......................................31
Appendix 1.5 – E-mail Accompanying Digitizing Payments Application ..........................................................32
Appendix 1.6 – Board Resolution .....................................................................................................................33
Appendix 1.7 – Presentation for Beneficiaries on Transition to Digital Payments ..........................................34
Appendix 1.8 – Instructional Manual on How to Use Mobile Money ..............................................................36
Appendix 1.9 – Mobile Money Agent Training Curriculum ..............................................................................39
Appendix 1.10 – Aggregator Procurement Process and Selection Criteria ......................................................46
Appendix 1.11 – Request for Information ........................................................................................................47
Appendix 1.12 – User Acceptance Testing Checklist ........................................................................................53
Appendix 1.13 – User Acceptance Testing Sample ..........................................................................................56
Appendix 1.14 – Proposed Bulk Payment Contract..........................................................................................58
Appendix 1.15 – Required Documentation to Register....................................................................................71
Appendix 1.16 – Business Account Opening Form ...........................................................................................72
Appendix 1.17 – Authorization Letter ..............................................................................................................74
Appendix 1.18 – User Training Manual ............................................................................................................75
Appendix 2.1 – Attendance Sheet for Trainings ...............................................................................................86
Appendix 2.2 – Payment Sheet for Trainings ...................................................................................................87
Appendix 3.1 – Financial Model for Costs and Savings ....................................................................................88
Appendix 3.2 – Payment Sheets in Excel ..........................................................................................................90
Appendix 3.3 – Screenshot of Message Sent to Beneficiary Phone .................................................................92
Appendix 3.4 – Bulk Payment E-mail Notification ............................................................................................93
Appendix 4.1 – Sample Report .........................................................................................................................94

Digitizing Payments Process Kit

February 20, 2014 Page 18 of 94
 Digital Adoption: Implementing Partners

Appendix 1.1 – Business Requirements Document

United States Agency for International Development

Bill and Melinda Gates Foundation

Business Requirements Document (BRD)

1. Introduction

1.1 Document Purpose

The purpose of this document is to describe business requirements of the Bulk Payment
Aggregation solution, which is comprised of applications, services, processes, and policies to
facilitate the distribution of bulk payments from USAID implementing partners to their
beneficiaries.
Business requirements for major enhancements to an existing application
Business requirements for new application development
Business requirements for replacement application development
Business requirements for a request for proposals (RFP)

1.2 Intended Audience

Digitizing Payments Process Kit

February 20, 2014 Page 19 of 94
The intended audience for this document includes implementing partners, Mobile Network
Operators (MNO’s), Business Process Outsourcing vendors (or aggregators), and other interested
service or technology providers.

1.3 Project Background

Extensive work in the global development community has identified the important role technology
has to play in achieving affordable access to, and use of, financial services by the poor. In addition,
when technology is combined with business processes, electronic payments can be made
inexpensively and transparently.

This project aims to change the way non-

governmental organizations (NGOs) and projects in Uganda make small payments to beneficiaries.
USAID is the lead donor in the country, and many NGOs have multiple funding partners. If
successful, those NGOs and USAID could change the way beneficiary payments are made in
countries beyond Uganda.

Currently, many organizations are attempting to distribute bulk payments by working directly with
MNOs (see Figure 1, upper right). This model creates many redundancies, and implementing
partners are not able to perform many needed functions due to the limitations of the MNO
platforms.

As a result of the inherent limitations posed by working with the MNOs, an alternative approach
has been proposed. Working with an intermediary such as an aggregator simplifies operations and
lowers costs, both to the implementing partners and to USAID (see Figure 2, lower right). Further,
this approach increases transparency throughout the entire payments value chain.

1.4 Business Goals/Objectives

The objective of the project is to demonstrate the financial

and operational feasibility of digital payments for USAID Donor

implementing partner programs in Uganda through the

implementation of a proof-of-concept project. Implementing Implementing Implementing
Partner Partner Partner

1.5 Stakeholders
Aggregator

Key stakeholders with vested interest in the project outcomes

are: MNO: Airtel/Warid MNO: MTN

1) USAID implementing partner beneficiaries MNO: Orange MNO: UTL

2) USAID implementing partners

3) Uganda mobile network operators (MNOs) Beneficiaries

4) Uganda payments aggregators

5) Uganda MNO banking partners

Digitizing Payments Process Kit

February 20, 2014 Page 20 of 94
 6) USAID Uganda Mission
7) USAID Washington, DC
8) Bill and Melinda Gates Foundation

1.6 Dependencies on Existing Systems

The success of the project depends on the ability of MNOs to continue to accept bulk payment
requests and funds, distribute bulk payments to individual subscribers, and to make their
application program interface (APIs) available to bulk payment aggregators. The pricing and tariff
schedules are a key dependency for those who initiate bulk payments and for end users
(beneficiaries) who receive payments.

The project also depends on a consistent and predictable regulatory environment that allows
appropriate access to beneficiary payment systems and mobile phone tools in a manner that is
attractive to end users, as well as institutions that initiate bulk payments.

The delivery of payments and services is dependent on several factors, including MNO network
availability, agent presence and liquidity, the acceptance of mobile payments by merchants or
other service providers, and the ubiquity and reliability of Internet access so that implementing
partners can access payment portals and tools used by payment aggregators.

1.7 Assumptions

The following assumptions are integrated into the planning of the project:
1) A sufficient number of USAID implementing partners will participate in the proof-of-
concept project to make the outcomes measurable and relevant to a larger community,
including implementing partners outside Uganda.
2) Aggregators will be interested in developing solutions to meet the needs of implementing
partners at no cost to the project.
3) MNOs will consider alternative pricing models (volume-based discounts, for example) to
enhance financial viability.
4) Systems integration between the aggregators and MNOs will be completed in a timely
manner.
5) Aggregators will be willing to make the changes to their front-end, middleware and
platform integration APIs to meet the needs of the implementing partners.
6) Aggregators will be willing to adopt a volume-based pricing model, reducing costs for
higher volumes of transactions.

2. Functional Requirements

2.1 Requirements Summary

Digitizing Payments Process Kit

February 20, 2014 Page 21 of 94
This section describes the functional requirements for each participant in the digital payments
value-chain. The functional requirements may affect applications, processes, policies, or
procedures. All functional requirements must be addressed to achieve a functional digital
payments system.

2.2 Implementing Partner Business Requirements

The USAID implementing partners currently are delivering payments to their beneficiaries via non-
digital methods. To adopt digital payments, the following requirements should be fulfilled.
1) Implement new training curricula
a. Internal training: Operations manuals and training for procedures on how
to use web-based payments portal provided by aggregator of bulk
payments
b. Internal training: Processes for initiation (scheduling), verification and
releasing of digital payments
c. Internal audit: Validation of payment delivery, balancing of bank accounts
to digital payment ledgers, balancing of MNO (via aggregator) ledgers to
payment requests
d. Field training: Initiation of payment requests via portal or mobile devices
e. Field training: Validation of delivery of services or goods which trigger
scheduled payments

2) Implement processes
a. Preparation of electronic bulk payment beneficiary repositories containing:
i. National ID or other unique identifying number
ii. Name
iii. Phone number
b. Design payment programs for specific interventions/activities:
i. Payment program
ii. Beneficiary
iii. Schedule of payments (date, time and amounts)

3) Implement payment hierarchy with appropriate levels of controls and authorities to initiate,
review, and approve bulk payments.

2.3 Aggregator Business Requirements

Aggregators who successfully implement the requirements listed below will be in a position
to work with implementing partners to accept and distribute bulk payments.
1) Reporting
a. Payment activity summary (successful and undelivered) and details including
transaction numbers organized by:
i. Specific date

Digitizing Payments Process Kit

February 20, 2014 Page 22 of 94
 ii. Specific week
iii. Specific month
iv. Specific year
v. Date range
vi. Beneficiary
vii. Beneficiary data (organized by name, phone number, and National ID)
viii. Others as specified
b. Customer service reports by
i. Date
ii. Disposition code
iii. Beneficiary name, national ID, and phone number

2) Web portal functions

a. Payment scheduling that generates a unique ID for:
i. Single payments (one-time or recurring)
1. Direct entry of recipient information into portal
ii. Bulk payments (one-time or recurring)
1. Direct entry of recipient information into portal
2. Upload of data file (CSV or other mutually agreed format)
3. From database maintained on portal on behalf of implementing partner

3) Customer support
a. Receive beneficiary customer service requests relating to payment issues
b. Maintain a log of requests, disposition and resolution date, including a unique ticket
number, date, time, beneficiary name, phone number and other pertinent information
c. Catalog all support tickets based on disposition codes

4) Mobile portal functions based on appropriate level of access

a. Ability to view payment status by entering scheduled payment ID
b. Ability to modify (pause, cancel, and release) scheduled payments for use by field
personnel at the conclusion of intervention or project

5) Pricing
a. Volume-based activity
i. Aggregator to provide pricing schedule based on volume of payments by
month or in total
b. Rate card for system enhancements or new features
c. Pricing for hosting databases

6) Data security
a. Encryption methods to be industry standard and compliant with Ugandan
regulations for privacy and security
b. Physical storage in compliance with Ugandan regulations for privacy and security,
and in a manner that grants access only to authorized personnel

7) User security

Digitizing Payments Process Kit

February 20, 2014 Page 23 of 94
 a. Implementing partner will be issued a master ID for use in managing authentication
and access by partner employees or contractors
b. Payment portal will provide at least three levels of access:
i. Master: Ability to access all transactions, reports, and databases. Master
ID will be able to add users, alter authentication levels, and remove
users in addition to all functions in the Designate level
ii. Designate: Ability to view scheduled payments, review and release
payments that have been scheduled, request and review all reports on-
line, print all reports in addition to all functions in the Basic level
iii. Basic: Ability to prepare and upload payments to the portal, review
certain reports on-line, and review specific transactions in support of
customer service activities
c. Payments portal will provide multiple layers of authentication (multi-hierarchy) to
limit access to features and functions

2.4 MNO Business Requirements

1) Pricing
a. Negotiated rate card based on volume-based pricing for bulk payments

2) Agent Network
a. Negotiated rate card or subsidized for cash out for beneficiaries
b. Liquidity management based on bulk payment targets

3. Data Retention and Archiving

The successful aggregator will maintain all transaction data on behalf of the implementing partner for
as long as is allowable by law and Ugandan regulations. Copies of the data, protected by password,
will be provided to the implementing partner upon request in either printed or digital format.

4. Availability Requirements

The aggregator payments portal will be available to the implementing partner on a full-time basis
(365 days/year, 24 hours/day) with the exception of outages for system upgrades and enhancements,
to be scheduled during non-business hours and in pre-agreement with implementing partners. The
Aggregator will provide a schedule of maintenance periods to all implementing partners.

The Aggregator will maintain a help line for use by implementing partners to report outages to the
aggregator. Finally, the Aggregator will publish and adhere to a Service Level Objective policy that
clearly outlines the aggregator policies and processes which will be taken to restore service.

5. Revision Log

Digitizing Payments Process Kit

February 20, 2014 Page 24 of 94
 Date Version Change Reference Reviewed by

Digitizing Payments Process Kit

February 20, 2014 Page 25 of 94
Appendix 1.2 – Selection Criteria for Implementing Partners and Scorecard

The implementing partner selection process followed five steps: Pre-screening, Notification, Formal
Application, Pre-Selection, and Selection. The process was developed in close consultation with the
USAID Uganda Mission.

Formal
Pre-Screening Notification Application Pre-Selection Selection

• USAID and Vital • USAID informed all • Formal application • Vital Wave vetted • Vital Wave and
Wave reviewed a 15 shortlisted send by Vital Wave all applications and USAID selected 5
list of 99 candidates of to 15 candidates conducted implementing
implementing upcoming call for launched with a call interviews with 12 partners
partners and applications, for applications shortlisted
shortlisted 15 encouraged their candidates • Selected partners
candidates participation and • Interested partners were notified
gauged interest submitted
applications

Points Selection Criteria IP 1 IP 2 IP 3 IP 4

20 Implementing Partner demonstrates elevated levels of risk or previous difficulties with cash disbursement 0 0 0 0

15 Implementing Partner makes bulk payments to beneficiaries currently 0 0 0 0

15 Implementing Partner has relatively high average transaction amounts and high frequency of bulk payments 0 0 0 0
Implementing Partner has shown an interest in implementing digital payments for making beneficiary payments and for the purpose of addressing
10 risk associated with cash payments 0 0 0 0

10 Implementing Partner has a productive relationship with USAID Uganda 0 0 0 0

10 Implementing Partner maintains adequate service delivery controls pertaining to disbursements 0 0 0 0

10 Implementing Partner has more than 2 years left in their project/activity 0 0 0 0
Preferred: Implementing Partner has a country office or partner in another country (or a member of staff) that has already undergone the
5 transition to mobile payments 0 0 0 0

5 Preferred: Implementing Partner beneficiaries are in close proximity to functioning agent (for interview) 0 0 0 0
100 0 0 0 0

1: Very Poor - IP does not fulfil criteria

2: Poor - IP fulfils criteria only minimally
3: Moderate - IP shows some but not all requirements to fulfil criteria
4: Good - IP shows most but not all requirements to fulfil criteria
5: Excellent - IP demonstrates all requirements to fulfil criteria

Digitizing Payments Process Kit

February 20, 2014 Page 26 of 94
Appendix 1.3 – Application for the ‘Digitizing Payments for USAID
Beneficiaries in Uganda’ Program

Application for Assistance and Guidance in the Digitalizing Payments Program

Please submit all applications via email (MS Word or PDF) to [insert Project Coordinator e-mail] by
[insert date], [insert time] East African Time.

Note:
a) All information provided in this application is strictly confidential.
b) The timeliness of your application will be taken into consideration.
c) The space given under each category of the application is indicative of the amount of
information needed. Applicants are encouraged to use as much space as needed.
d) Should you have any questions regarding this application process or program, please
contact the Project Coordinator at [insert Project Coordinator e-mail].

Date of Application: ____________________________________________

Section A: Contact Information

Name of organization

Name of activity/project

Type of organization running the activity/project

(CBO/NGO/private company/other – specify)
Name of the chief of party

Office location

Office phone number

Mobile phone number (chief of party)

Fax

Email

Website

Key contact person – name and designation

Contact number of key contact person

Digitizing Payments Process Kit

February 20, 2014 Page 27 of 94
Section B: Application

1. Rationale/Need Justification

Describe in detail the situation/circumstances that have led to the decision to digitize payments.
Provide as much supporting information as possible.

2. What is your project/activity’s experience with making bulk payments in cash to

beneficiaries?

Describe the situations that require bulk payments, how often bulk payments are made, the
average amount of each transaction, and the number of beneficiaries who receive payments.

3. Has your project/activity faced any risks or previous difficulties with cash payments?

4. What tools does your project/activity use to ensure the adequate service delivery or
controls pertaining to cash payments?

Digitizing Payments Process Kit

February 20, 2014 Page 28 of 94
5. Does your project/activity have a country office or partner in another country or member
of staff that has already undergone the transition to mobile payments?

If yes, please explain.

6. Project Beneficiaries
To whom is your project/activity making bulk Service providers and vendors
payments? Staff in the field
Tick as appropriate Beneficiaries in the field
Where are your project/activity’s beneficiaries
located?
How many beneficiaries does your project/
activity make bulk payments to and how often?
How would you characterize the use of bulk High Frequency/Low Amount
payments in your project/activity? High Frequency/High Amount
Tick as appropriate Low Frequency/Low Amount
Low Frequency/High Amount

7. Details of the Proposed Team for Project Implementation

Please provide information on the key staff proposed for the project with relevant technical skills
and responsibilities within the proposed project. Provide as much background information as
possible (CVs if available).

Name Proposed Total Working Currently working with

Position Experience your organization (Y/N)

8. Sharing of Information*

In order for us to better understand how your organization works, are you willing to share:

Yes No
I. Financial data, down to transaction levels? Tick as appropriate
II. Internal processes and procedures? Tick as appropriate

Digitizing Payments Process Kit

February 20, 2014 Page 29 of 94
* Please note that all information provided is confidential.
Section C: Application Checklist and Declaration

Yes No
All sections of the applications have been filled as per given directions

To the best of my knowledge, I declare that all the above information is true and accurate.

Sincerely,

Name: ____________________________

Position: ___________________________

Signature: __________________________

(To be signed by authorized party)

Digitizing Payments Process Kit

February 20, 2014 Page 30 of 94
Appendix 1.4 – Project Description Accompanying Digitizing Payments
Application

Digitizing Payments for USAID Beneficiaries in Uganda Program

I. Project Description

Vital Wave, a professional services firm contracted by the Gates Foundation on behalf of USAID/
Uganda, will work with 4-6 USAID implementing partners to assist them in making the transition to
digital payments for their beneficiaries. Vital Wave has conducted extensive research in Kenya,
Tanzania and Uganda to understand the stakeholder landscape and how mobile money systems
have been and can be used by organizations to make payments to their beneficiaries. In Uganda
specifically, Vital Wave has worked closely with USAID to interview a cross-section of local
stakeholders in order to understand the challenges and opportunities of using mobile money to
make bulk payments.

This project will be a pilot study with the 4-6 selected partners. If successful, it has the potential
to change the way NGOs and projects in Uganda and East Africa make payments to beneficiaries.

Participation in the pilot will provide implementing partners with support and guidance for moving
away from cash payments in the field to making bulk payments via mobile money. The 4-6
selected implementing partners will:
 receive support for developing new digital payment operational and financial processes
 receive training, manuals and support on how to use mobile bulk payment platforms
 gain and learn from the knowledge acquired by Vital Wave through extensive research
conducted in East Africa
 benefit from experience with troubleshooting and best practices learned by organizations
that have succeeded in transitioning to digital payments in other East African countries
 be supported in their relations and dealings with MNOs and aggregators
 benefit from the availability of software developed to support the digital payments
transition in a secure and user-friendly way

Reviews will be conducted monthly between implementing partners, Vital Wave and USAID to
report on the progress of the pilot and identify, learn from, and apply lessons learned.

Digitizing Payments Process Kit

February 20, 2014 Page 31 of 94
Appendix 1.5 – E-mail Accompanying Digitizing Payments Application

Dear USAID Implementing Partners,

Please find attached the application for participation in the 'Digitizing Payments for USAID
Beneficiaries in Uganda' program. The deadline for submission of applications is [insert date and
time].

Successful projects and/or activities will benefit from support and guidance in transitioning from
cash to mobile money when making bulk payments to beneficiaries.

Your projects/activities have already passed the initial pre-screening stages of the application
process. Following submission of applications, a kickoff meeting will be held and
shortlisted candidates will be interviewed. 4-6 Implementing Partners will be selected for the
program.

Should you have any questions on the application process or program please contact the Project
Coordinator at [insert Project Coordinator e-mail].

We look forward to receiving your applications.

Kind regards,

Name: ____________________________

Position: ___________________________

Digitizing Payments Process Kit

February 20, 2014 Page 32 of 94
Appendix 1.6 – Board Resolution

THE REPUBLIC OF UGANDA

IN THE MATTER OF THE COMPANIES ACT CAP 110
AND
IN THE MATTER OF [NGO]

ORDINARY RESOLUTION

At a meeting of the Board of Directors of the company on the [Date], be it resolved as follows:

1. THAT [NGO] shall as recommended by USAID/Uganda join the ‘Digitizing Payments for
USAID Beneficiaries in Uganda’ Project as coordinated by Vital Wave.
2. THAT as a prerequisite for this service to become operational this resolution is so
hereby made to facilitate this with the Aggregator who will be identified by
USAID/Uganda and Vital Wave.
3. THAT the Board liability shall be limited to passing this resolution.
4. THAT the financial instruments of this project be signed as per [NGO] financial
management policy.
5. THAT this resolution be filed with the Uganda Registration Services Bureau.

DATED at Kampala on [Date].

Signed By:
[NGO] Board of Directors

No. Name Title Approved Not Approved

1.

2.

3.

4.

5.

Digitizing Payments Process Kit

February 20, 2014 Page 33 of 94
Appendix 1.7 – Presentation for Beneficiaries on Transition to Digital
Payments

USE OF MOBILE MONEY7

Background:

USAID has requested its partners to consider making payments using a mobile money system.
After a successful introduction of mobile money payments with six USAID partners, the program
will be expanded to other partner organizations.

Current challenges faced:

a) Usually the sum to be paid out is a large amount, posing the risk of traveling and working with a
lot of cash.
b) Administratively, it’s challenging to gather all beneficiaries in one place to pay them after a
workshop has closed and the recipients have begun to disperse.
c) Also, it consumes a lot of time to make payments to many people
d) There is no guarantee that the person registered is the one who collects the payment, since
many participants may not have IDs.

How it will work

a) Participants will be required to register their mobile numbers for a mobile money payment
system.
b) Participants will then register their numbers with the program staff for the database.
c) When participants are invited for a workshop, they will be required to register. As the
workshop is taking place, the [insert name of activity] will carry out their verification before
releasing the money to the registered mobile number.
d) The [insert name of activity] will receive reports to show all the transactions that have been
made.

Benefits to:

[insert name of activity]

a) No risk on the side of [insert name of activity], since staff will no longer carry large sums of
money.
b) [insert name of activity] will be able to view reports of all payments made to the attendees
of any event.
c) There are reduced challenges in managing the payment of beneficiaries (i.e., no queues, no
need for signatures or identification, etc.).
d) There is less susceptibility to fraud or loss of money.

7
SDS Programme, 2013.

Digitizing Payments Process Kit

February 20, 2014 Page 34 of 94
Beneficiaries
a) Fewer delays in payments
b) Reduced risk of one participant signing for money meant for another.
c) Avoid the inconvenience of queuing up for a payment.
d) No risk of carrying cash from a workshop to home.
e) Enjoy all the benefits of having a mobile wallet.

Note: All mobile money transfers will include agent’s fees (i.e., recipients will receive the full
amount they would have previously received in cash).

Digitizing Payments Process Kit

February 20, 2014 Page 35 of 94
 Digital Adoption: MNOs

Appendix 1.8 – Instructional Manual on How to Use Mobile Money

Digitizing Payments Process Kit

February 20, 2014 Page 36 of 94
Digitizing Payments Process Kit
February 20, 2014 Page 37 of 94
Digitizing Payments Process Kit
February 20, 2014 Page 38 of 94
Appendix 1.9 – Mobile Money Agent Training Curriculum

Digitizing Payments Process Kit

February 20, 2014 Page 39 of 94
Digitizing Payments Process Kit
February 20, 2014 Page 40 of 94
Digitizing Payments Process Kit
February 20, 2014 Page 41 of 94
Digitizing Payments Process Kit
February 20, 2014 Page 42 of 94
Digitizing Payments Process Kit
February 20, 2014 Page 43 of 94
Digitizing Payments Process Kit
February 20, 2014 Page 44 of 94
Digitizing Payments Process Kit
February 20, 2014 Page 45 of 94
 Digital Adoption: Aggregators

Appendix 1.10 – Aggregator Procurement Process and Selection Criteria

Aggregators were selected from a shortlist of integrated and certified aggregators presented by
the MNOs. Yo! Payments, Pegasus and Cellulant were selected as aggregators.

The aggregator selection process followed five steps: Pre-screening, Notification, Request for
Information, Pre-Selection, and Selection.

The aggregator selection criteria were informed by the Business Requirements Document, which
synthesized implementing partner requirements and the results of research carried out by Vital Wave.

Selection Criteria Weight

Aggregator has an existing connection with the two largest MNOs 15
Aggregator has an existing bulk payments solution 15
Aggregator is currently servicing clients on the bulk payments solution 15
Aggregator meets all the BRD requirements 15
Aggregator shows capacity to handle the transaction volume 5
Aggregator is a Limited Liability Company (LLC) 5
Aggregator has been in operations for over two years 5
Aggregator has adequate business continuity management 5
Aggregator has adequate staff 5
Aggregator is financially stable 5
Aggregator has a flexible pricing arrangement 5
Aggregator has a good relationship with a top-tier bank 5
Aggregator has other services that may be beneficial to the project (SMS, USSD, WAP) 5
Highest Possible Score: 105

Digitizing Payments Process Kit

February 20, 2014 Page 46 of 94
Appendix 1.11 – Request for Information

Aggregator

Request for Information (RFI)

Digitizing Payments in Uganda Program

Prepared by: Sieka Gatabaki

Prepared for: MNO Certified Aggregators
Date Submitted: October 4, 2013

Project Sponsor: Bill and Melinda Gates Foundation

Client Acceptor: Bryce Edgar
Engagement Manager: David Sessions
Lead Analyst: Leah Gatt
Advisor: Sieka Gatabaki

Confidentiality
All information included in this RFI is confidential and only for the recipient knowledge. No
information included in this document or in discussions connected to it may be disclosed to any
other party.

Introduction and purpose of the RFI

With this RFI we request information regarding your company and your products/services. The
same information will be gathered from different companies and will be used to evaluate which
aggregators will be selected for the Digitizing Payments in Uganda Program.

Scope
Specific information is requested according to the form below.

RFI procedure
To answer this RFI please fill in the attached form. The contact person/s listed below is available for
assistance if needed. All questions should be submitted in email to the contacts below and
responses shall be shared with all applicants.

How to deliver the answer

Send the attached form in PDF format by email to [insert project coordinator’s email)

Timeframe

Digitizing Payments Process Kit

February 20, 2014 Page 47 of 94
This is the timeframe for the RFI submission and evaluation
[Insert Date] – The RFI is sent out
[Insert Date] – Last date for questions
[Insert Date] – Last date for submission of answer
[Insert Date] – Final aggregator(s) chosen for prototyping and tests
[Insert Date] – Start of project

Background Description

Project Context

This project aims to change the way non-governmental organizations (NGOs) and projects in
Uganda make small payments to beneficiaries. USAID is the lead donor in the country, and many
NGOs have multiple funding partners. If successful, those NGOs and USAID could change the way
beneficiary payments are made in Uganda and throughout East Africa.

Currently, many organizations are attempting to distribute bulk payments by working directly with
MNOs. This model creates many redundancies, and implementing partners are not able to perform
many needed functions due to the limitations of the MNO platforms.

As a result of the inherent limitations posed by working with the MNOs, an alternative approach
has been proposed. Working with an intermediary such as an aggregator simplifies operations and
lowers costs, both to the implementing partners and to USAID. Further, this approach increases
transparency throughout the entire payments value chain.

Digitizing Payments Process Kit

February 20, 2014 Page 48 of 94
Requirements

Aggregators who successfully implement the requirements listed below will be in a position
to engage with implementing partners to accept and distribute bulk payments.

1) Reporting
a. Payment activity summary (successful and undelivered) and details including
transaction numbers organized by:
i. Specific date
ii. Specific week
iii. Specific month
iv. Specific year
v. Date range
vi. Beneficiary
vii. Beneficiary range (organized by name, phone number, and National ID)
viii. Others as specified
b. Customer service reports by:
i. Date
ii. Disposition code
iii. Beneficiary name, national ID, and phone number

2) Web portal functions

a. Payment scheduling that generates a unique ID for:
i. Single payments (one-time or recurring)
1. Direct entry of recipient information into portal
ii. Bulk payments (one-time or recurring)
1. Direct entry of recipient information into portal
2. Upload of data file (CSV or other mutually agreed format)
3. From database maintained on portal on behalf of implementing
partner

3) Customer and Implementing Partner support

a. Receive beneficiary customer service requests relating to payment issues
b. Maintain a log of requests, disposition and resolution date, including a unique
ticket number, date, time, beneficiary name, phone number and other pertinent
information
c. Catalog all support tickets based on disposition codes
d. Develop and deliver a train the trainer course on the bulk payments system and
processes.
e. Provide training materials and guidelines for each implementing partner.

4) Mobile portal functions based on appropriate level of access

a. Ability to view payment status by entering scheduled payment ID
b. Ability to modify (pause, cancel, and release) scheduled payments for use by field
personnel at the conclusion of intervention or project

Digitizing Payments Process Kit

February 20, 2014 Page 49 of 94
 5) Pricing
a. Volume-based activity
i. Aggregator to provide pricing schedule based on volume of payments by
month or in total
b. Rate card for system enhancements or new features
c. Pricing for hosting databases

6) Data security
a. Encryption methods to be industry standard and compliant with Ugandan
regulations for privacy and security
b. Physical storage in compliance with Ugandan regulations for privacy and security,
and in a manner that grants access only to authorized personnel

7) User security
a. Implementing partner will be issued a master ID for use in managing authentication
and access by partner employees or contractors
b. Payment portal will provide at least three levels of access:
i. Master: Ability to access all transactions, reports, and databases. Master
ID will be able to add users, alter authentication levels, and remove
users in addition to all functions in the Designate level.
ii. Designate: Ability to view scheduled payments, review and release
payments that have been scheduled, request and review all reports on-
line, print all reports in addition to all functions in the Basic level
iii. Basic: Ability to prepare and upload payments to the portal, review
certain reports on-line, and review specific transactions in support of
customer service activities
c. Payments portal will provide multiple layers of authentication (multi-hierarchy) to
limit access to features and functions
d. Generally accepted password policies to be applied for all users including but not
limited to, minimum password length, password complexity, password aging, initial
password change, and user account lockout and password history.

Digitizing Payments Process Kit

February 20, 2014 Page 50 of 94
Qualifications

Mandatory

1. The aggregator must have integrated to one or more of the top MNO mobile money
providers in Uganda
2. The aggregator must have a running bulk payments solution in place
3. The aggregator must be a limited liability company
4. The aggregator must have backup and redundancy capabilities

Optional

1. The aggregator should have been in business for more than two (2) years
2. The aggregator should have a 24-hour call center
3. The aggregator should have audited reports for the last financial year
4. The aggregator should be registered with the Uganda Communications Commission as a
content service provider

Aggregator Questionnaire

Question Response
Company name
Company address
Company website
Main products/services

Mobile Network Operators your have completed

integrated with
Mobile Network Operators your are integrating to
and timelines
Main market/customers
Ownership structure with ownership distribution in
percentage
Structure of mother corporation, joint ventures,
subsidiaries, partnerships or other relevant
relations
Number of years in business
Company location(s)
Describe your business continuity management

Employees
Technical
Training

Digitizing Payments Process Kit

February 20, 2014 Page 51 of 94
 Financial information
Last year turnover
Last year gross margin
Last year profit/loss
Escrow bank name and relationship manager
contacts

Contact person responsible for answering this RFI

Telephone
Email
Capacity conditions today
(maximum number of transactions/ clients)
Anticipated capacity conditions within 12 months
Requirements listed in the RFI that cannot be met

Proposed pricing rate card based on estimated

transaction bands
(e.g. 0-1,000 transactions - 0.5% of value or UGS 100;
1001-10,000 – 0.4% of value, etc.)
Description of products or services that are
already delivered to customers today, and could
be comparable to what is requested in this RFI

Reference customers using comparable products

or services (including contact information)

Digitizing Payments Process Kit

February 20, 2014 Page 52 of 94
Appendix 1.12 – User Acceptance Testing Checklist

User Acceptance Test (UAT)

Digitizing Payments in Uganda Program

Confidentiality

All information included in this UAT is confidential and only for the recipient knowledge. No
information included in this document or in discussions connected to it may be disclosed to any
other party.

Purpose of the UAT

This UAT has been designed to test the critical functions of the Aggregator portal and ensure it
meets the Business Requirements Specifications prior to presentation to the end users.

Scope

All test cases in the UAT are derived from the relevant Business Requirements Specifications.

Test Cases

1. Reporting

Pass Fail
Does the system provide Payment activity summary (successful and undelivered)
and details including transaction numbers organized by:
i. Specific date
ii. Specific week
iii. Specific month

iv. Specific year

v. Date range

vi. Beneficiary
vii. Beneficiary range (organized by name, phone number, and
National ID)

Digitizing Payments Process Kit

February 20, 2014 Page 53 of 94
 2. Web Portal Functions

Payment scheduling that generates a unique ID for: Pass Fail

I. Single payments (one-time or recurring)

i. Allows for direct entry of recipient information into portal

II. Bulk payments (one-time or recurring) Pass Fail

i. Direct entry of recipient information into portal

ii. Upload of data file (CSV or other mutually agreed format)

iii. From database maintained on portal on behalf of implementing

partner

3. Mobile portal functions based on appropriate levels of access

Pass Fail
a. Ability to view payment status by entering scheduled payment ID

b. Ability to modify (pause, cancel, and release) scheduled payments for use by
field personnel at the conclusion of intervention or project

4. User security

Pass Fail
a. Implementing partner will be issued a master ID for use in managing
authentication and access by partner employees or contractors

b. Payment portal will provide at least three levels of access:

i. Master: Ability to access all transactions, reports, and databases.

Master ID will be able to add users, alter authentication levels,
and remove users in addition to all functions in the Designate
level.

Digitizing Payments Process Kit

February 20, 2014 Page 54 of 94
 ii. Designate: Ability to view scheduled payments, review and
release payments that have been scheduled, request and review
all reports on-line, print all reports in addition to all functions in
the Basic level

iii. Basic: Ability to prepare and upload payments to the portal,

review certain reports on-line, and review specific transactions in
support of customer service activities

c. Payments portal will provide multiple layers of authentication (multi-

hierarchy) to limit access to features and functions

d. Generally accepted password policies to be applied for all users including but
not limited to, minimum password length, password

e. complexity, password aging, initial password change, user account lockout

and password history

Sign off

Project Advisor Signatures

Lead Analyst

Aggregator

Digitizing Payments Process Kit

February 20, 2014 Page 55 of 94
Appendix 1.13 – User Acceptance Testing Sample

Digitizing Payments Process Kit

February 20, 2014 Page 56 of 94
Digitizing Payments Process Kit
February 20, 2014 Page 57 of 94
Appendix 1.14 – Proposed Bulk Payment Contract

AGREEMENT FOR A MULTIPLE PAYMENTS SOLUTION USING THE ‘AGGREGATOR

PAYMENT PLATFORM’ E-COMMERCE SOLUTION

BETWEEN

[AGGREGATOR]

AND

[NGO NAME]

Drawn By

Legal Department
‘Aggregator’
Plot _______, ___________ Road,
P. O. Box _____________________
Kampala, Uganda
Tel: (+256) _________________________

Digitizing Payments Process Kit

February 20, 2014 Page 58 of 94
THIS AGREEMENT is made on the …………… day of …………………. Two Thousand and Fourteen

BETWEEN

1. ‘AGGREGATOR’ a limited liability company incorporated in accordance with the Laws of Uganda and having its
registered office at Plot ………., …………….Kampala, and of Post Office Box Number …………………………….., Kampala,
Uganda, (hereinafter referred to as “AGGREGATOR” which expression shall where the context so admits include
its successors and assigns) of the one part;

AND

2. ‘NGO NAME’ a limited liability company incorporated in the Republic of Uganda whose principal place of business
is at Plot ………., …………….Kampala, and of Post Office Box Number …………………………….., Kampala, Uganda,
(hereinafter called “the CLIENT” which expression shall except where the context otherwise provides include its
successors and assigns) of the other part.

WHEREAS

1. Aggregator is duly authorised Telecom Payments Aggregator to operate payments aggregation services and offer
associated services and value added services in Uganda.

2. CLIENT is engaged in the provision of NGO Services in the Republic of Uganda.

3. THE CLIENT is desirous that AGGREGATOR facilitates the disbursement of payments to its customers, employees,
business associates, agents or any of the CLIENT’s nominees (the “third party”) as shall be indicated by the CLIENT
from time to time through Aggregator’s Payments platform.

4. AGGREGATOR has agreed to offer the CLIENT a solution to facilitate the disbursement of payments to third parties on
behalf of the CLIENT which involves the use of Aggregator’s Payments service subject to the terms and conditions
hereinafter contained.

2. Aggregator and the CLIENT confirm that they have the requisite authority and capacity to enter into and give effect to
this Agreement.

Digitizing Payments Process Kit

February 20, 2014 Page 59 of 94
NOW THIS AGREEMENT WITNESSETH AS FOLLOWS:

1) DEFINITIONS

Unless the context otherwise provides, the following terms whenever used in this Agreement document shall have the
meanings given here below:

‘Aggregator Account’ means an E-Value Account held by Aggregator.

‘Bank Account’ means a bank account held with any of the Commercial Banks in Uganda.

‘Cash Payment Service’ shall mean the service extended to the Third Party through Aggregator, for the disbursement
of payments through the Aggregator payments service, in accordance with Aggregator’s operating procedures.

‘CLIENT’s Aggregators Payment Platform Account’ shall mean the CLIENT’s designated Aggregator account
number as shall be advised by the CLIENT, where all payments shall be made through and where Aggregator will be
crediting E-value. It shall also mean an account on the Aggregator Payment Platform system with E-value equivalent
to real-money deposited in the Aggregator Payment Platform Account by the CLIENT to be used for payments of the
third party.

‘E-Value’ means the electronic value recorded in an E-Value Account, such electronic value representing that E-Value
Account holder’s entitlement to an equivalent amount of the Real Money held in the Bank Account.

‘Force Majeure’ shall mean any event or circumstance which affects either party and is not within the reasonable
control (directly or indirectly) of the Party affected, to the extent that such event or circumstance or its effects cannot
be prevented, avoided or removed by such party acting in accordance with Prudent Operating Practice. “Force Majeure”
shall include each of the following events and requirements:

i) Any act of war (whether declared or undeclared), invasion, armed conflict or act of foreign enemy, blockade,
embargo, revolution, riot, insurrection, civil commotion, act of terrorism, or sabotage provided that any such
event occurs within or directly involves the Republic of Uganda.

ii) Any act of God including but not limited to lightning, fire, earthquakes, volcanic activity, floods, storms,
cyclones, typhoons, or tornadoes.

iii) Epidemics or plagues.

iv) Explosions or chemical contamination (other than resulting from an act of war).

v) Labour disputes including strikes, go-slows or lockouts that are extended beyond Aggregator’s control or are
widespread or nation-wide; except where the same is occasioned by Aggregator’s default.

vi) Change in Law to the extent that it will adversely affect any party’s performance of its obligations under this
Agreement.

‘Instruments’ shall mean Electronic Funds Transfer (EFT).

‘Operating Procedures’ shall refer to the procedures and processes through which payments shall be remitted from
the CLIENT to the Third Parties through the Aggregator Payments Solution.

‘Real Money’ means Uganda Shillings being the lawful currency of the Republic of Uganda.

‘Services’ shall mean any services provided by Aggregator pursuant to this Agreement.

‘Third Party’ shall mean anyone receiving payment from the CLIENT.

Digitizing Payments Process Kit

February 20, 2014 Page 60 of 94
2. SCOPE OF SERVICES

2.1 The Payment Service shall be based on Aggregator’s Mobile Commerce Platform.

2.2 The Aggregator Payments Solution has now been developed by Aggregator to collect information that
allows for the remittance of CLIENT’s payments through the Aggregator Payments Solution.

3. DURATION

This Agreement shall remain in force unless and until terminated by either party in accordance with the provisions
of Clauses 9 to 10 hereinafter appearing.

4. FEES AND CHARGES

4.1 In consideration of Aggregator providing the Services herein described, the CLIENT shall pay Aggregator
the Transactional Fees set out in the Schedule attached hereto to as Annex 1 and incorporated herein by
reference (including subsequent revisions thereof approved in the manner provided for by amendments
to this Agreement).

4.2 The parties expressly agree that the Transactional Fees shall be solely determined by Aggregator and
Aggregator retains the right upon Seven days’ notice to the CLIENT to review the Transactional Fees as
it shall deem fit.

4.3 The Transactional Fees in Annex 1 shall however apply until any new charges are agreed upon by the
parties.

5. COLLECTION AND TRANSMISSION OF MONIES

5.1 Aggregator will avail the application for payments processing to the CLIENT’s designated computers.

5.2 CLIENT shall be provided by Aggregator with the Aggregator Payments Solution Account on which
Aggregator will credit E-value equivalent to Real Money paid to Aggregator.

5.3 Prior to launching the Service captured herein the parties shall carry out tests (to a satisfactory level) to
confirm the compatibility and use of acceptable file formats with regard to the Service as being suitable
for the proper functioning and performance of each party’s obligations under this Agreement.

5.4 The payments by the CLIENT will be executed via Aggregator’s Core Application system that will be
interfaced with a connection to the CLIENT computer system for purposes of providing the payment
particulars to CLIENT.

5.5 Aggregator will provide the CLIENT with full details of all payments through the connection in accordance
with the Operating Procedures and process flow in the Annex 1 hereto.

5.6 Aggregator undertakes to ensure that the information posted through the connection is accurate and
up to date; however Aggregator shall not be liable to the CLIENT for any loss that the CLIENT may suffer
in the event that such information is tampered with by the CLIENT staff or such other third parties who
may gain un-authorized access thereto or for any incorrect information provided by the Persons
/suppliers PROVIDED THAT Aggregator shall be liable for any losses that arise from the negligence or
breach of contract of Aggregator’s employees, agents and/ or independent contractors.

5.7 Aggregator further undertakes to indemnify and keep the CLIENT fully indemnified from any losses;
expenses, costs damages arising from such negligence or breach of contract.

Digitizing Payments Process Kit

February 20, 2014 Page 61 of 94
6. STANDARD OF PERFORMANCE

6.1 Aggregator shall perform the services and carry out it’s obligations under this Agreement with all due
diligence and efficiency in accordance with the generally accepted techniques and practices commonly
recognized by the industry.

6.2 The CLIENT acknowledges that the Service is not fault free and the quality and availability of the Service
may be affected by factors outside the control of Aggregator such as local geographic or physical
obstructions atmospheric conditions and other causes of radio interference as well as faults in other
telecommunication networks to which the Network is connected or dependent. The Network and the
Service may also from time to time require upgrading modification maintenance or other works that may
also result in the Service or any part thereof becoming temporarily unavailable. Pegasus however
undertakes to act on such interferences promptly.

7. OBLIGATIONS OF THE CLIENT

7.1 Inform the Third Party in a sufficiently prominent manner about Aggregator’s solution as a payment
channel for the CLIENT payments.

7.2 Advise Aggregator promptly in the event of any changes in or re-organization of the CLIENT and any
other relevant departments, which may have a material implication on the operations of this Agreement
as envisaged by Clause 11.3 herein.

7.3 To ensure appropriate system safeguards are in place to protect the unauthorized access to and/or use
of or tampering with information held by the CLIENT in connection with this Agreement.

7.4 Subject to Clause 5.6 above, the CLIENT will Indemnify and keep Aggregator indemnified against all
losses, claims, demands, actions, proceedings, costs and expenses, of whichever nature, arising as a
consequence of Aggregator carrying out its obligations under this Agreement. Such indemnity shall
include but not limited to, any loss that Aggregator may suffer arising out of the transmission of
confidential information in accordance with the agreed procedures and guidelines annexed hereto.

7.5 Adhere to all relevant statutory provisions with regard to tax and all other relevant statutory payments
PROVIDED THAT Aggregator shall not be liable for any default occurring from non-observance of any
statutory provisions by the CLIENT and the CLIENT holds Aggregator fully indemnified against any default
occurring from non-observance of any statutory provisions.

7.6 Notwithstanding any other clause herein the CLIENT undertakes to indemnify and keep Aggregator fully
indemnified from any losses; expenses, costs damages arising from such negligence or breach of contract
occasioned by the CLIENT, its employees and/or its duly authorised agents.

8. OBLIGATIONS OF AGGREGATOR

8.1 To advise the CLIENT promptly in the event of any changes in or re-organization of Aggregator and any
other relevant departments, which may have a material implication on the operations of this Agreement
as envisaged by Clause 11.3 herein.

8.2 To ensure appropriate system safeguards are in place to protect the unauthorized access to and/or use
of or tampering with information held by Aggregator in connection with this Agreement.

8.3 Subject to the other provisions of the Agreement Aggregator shall indemnify the CLIENT against any
losses suffered by the CLIENT as a result of any disconnection of supply to any person/supplier arising
from the error or omission of Aggregator. The value of the Indemnity will be limited to the value of the
loss in question.

Digitizing Payments Process Kit

February 20, 2014 Page 62 of 94
9. TERMINATION - GENERAL

Either party may terminate the Agreement without prejudice to the antecedent rights and obligations accruing to
either party for any reason provided that such termination is communicated to the other Party by way of a written
notice and provided that such notice is given three (3) months to the date of termination PROVIDED THAT the
CLIENT shall not make any payment to the Third Party at least three (3) consecutive working days to the date of
termination.

10. TERMINATION BY NOTICE

The Agreement may be terminated by notice from either party in its entirety in the following instances:

a) By either party giving Three (3) months notice in writing at any time of the intended termination.

b) By either party in the event that the other party commits or permits any material breach of any term of
this Agreement and fails to remedy such breach within Thirty (30) days of receiving a request in writing
from the other party to remedy such breach.

11. AUTOMATIC TERMINATION IN CERTAIN CIRCUMSTANCES

11.1 The Agreement shall forthwith terminate if at any time any party becomes incapable of acting, or is
adjudged bankrupt or insolvent, or files a voluntary petition in bankruptcy or makes an assignment for
the benefit of its creditors or consents to the appointment of a receiver or other similar official of all or
any substantial part of its property or admits in writing its inability to pay or meet its debts as they mature
or suspends payment thereof, or if a resolution is passed or an order made for the winding up or
dissolution of either parties or if a receiver, administrator or other similar official of such Agent or all
or any substantial part of its property or if any order of any court is entered approving any petition filed
by or against it under the provisions of any applicable bankruptcy or insolvency law, or if any public
officer takes charge or control of either party or its property or affairs for the purpose of rehabilitation,
conservation or liquidation so as to render this Agreement impossible to perform.

11.2 If any law is passed for the de-establishment of any party so as to render this Agreement impossible to
perform.

11.3 In the event of any changes in and or re-organization of Aggregator or the CLIENT which may have a
material implication on the operations of this Agreement, rendering the implementation thereof to be
impossible.

12. EFFECT OF TERMINATION

12.1 Any termination of the Agreement in whole or in part however occasioned shall not affect any accrued
rights or liabilities of either party, nor shall it affect the coming into force or continuance in force of any
provision hereon which is expressly or by implication intended to come into or continue in force on or
after such termination.

12.2 In the event of termination the CLIENT shall be entitled to payment of all monies collected on behalf of
the CLIENT by Pegasus.

12.3 In the event of termination Pegasus shall be entitled to all payments of fees due up to the effective date
of actual termination.

Digitizing Payments Process Kit

February 20, 2014 Page 63 of 94
13. LIMITATION OF LIABILITY

The CLIENT shall exclude Aggregator from liability for any loss that occurs due to any of the events of Force
Majeure as defined herein. Aggregator shall not be liable under any circumstances for any incidental or
consequential loss or damage or any damages for negligence and its liability shall be expressly limited to the
performance of the service provided by this Agreement unless otherwise agreed by mutual consent.

14. RESOLUTION OF DISPUTES

14.1 Any dispute or disagreement arising between the Parties in relation to this Agreement shall, upon the
request of one Party to the other, be referred to a senior manager of each Party who shall meet within
Fourteen (14) days of such notice in good faith in order to determine whether the matter referred to
them is capable of resolution and, if so, to resolve the matter between them.

14.2 If such senior managers shall fail to reach agreement within a reasonable time and in any event within seven
(7) days of first meeting, any such dispute shall be referred to a senior executive nominated by the chief
executive officer (or equivalent) of each of the Parties who shall meet in good faith within fourteen (14)
days of such dispute or disagreement being so referred in order to determine whether the matter referred
to them is capable of resolution and, if so, to resolve such matters.

14.3 This clause and any discussion of senior personnel which takes place hereunder shall not prejudice any right
or remedy which any Party may ultimately have should the matter fail to be resolved by such discussions.

14.4 If any such dispute or disagreement cannot be settled in accordance with the foregoing provisions of this
Article, the dispute shall be referred on election of either Party (the "Notice of Arbitration") to arbitration
by a single arbitrator to be appointed by agreement between the parties or in default of such agreement
within 14 days of service of Notice of Arbitration upon the application of either party, by the Executive
Director of the Centre for Arbitration and Dispute Resolution (CADER).

14.5 Such arbitration shall be conducted in Kampala in accordance with the provisions of the Arbitration and
Reconciliation Act, Cap 4, Laws of Uganda 2000 or its successor legislation.

14.6 To the extent permissible by law, the determination of the arbitrator shall be final, conclusive and binding
upon the parties hereto.

14.7 Pending final settlement or determination of a dispute, the parties shall continue to perform their subsisting
obligations hereunder.

14.8 Nothing in this Agreement shall prevent or delay a party seeking urgent injunctive or interlocutory relief in
a court having jurisdiction.

15. CONFIDENTIALITY

15.1 The Parties acknowledge that during the course of this Agreement they may have access to financial,
legal, marketing, technical and other knowledge and information pertaining to each other’s business
affairs as necessary under this Agreement (hereinafter referred to as “Confidential Information”).

15.2 Each Party agrees to keep the Confidential Information confidential and agrees that it shall not without
the prior written consent of the owner of the Confidential Information, disclose such Confidential
Information either directly or by its representatives, persons /suppliers and/or agents, to any person or
in any manner whatsoever, in whole or in part. The Parties agree that the Confidential Information shall
not be used by the Parties or their representatives, persons /suppliers and/or agents other than in
connection with this Agreement. Moreover the Parties shall be responsible for any breach of this clause
by their representatives, persons /suppliers and/or agents.

Digitizing Payments Process Kit

February 20, 2014 Page 64 of 94
 15.3 The Parties agree that the Confidential Information shall so remain until such information becomes part
of public domain through no fault or breach of this Agreement or the same is required by a body
mandated under law to request for the same.

16. ASSIGNMENT

Neither party shall assign or otherwise transfer any of its rights under this Agreement or any interest herein without
the prior written consent of the other party and any such attempted assignment or transfer without the other
party’s consent shall be void and of no effect.

17. GOVERNING LAW

This Agreement shall be governed by the Laws of Uganda.

18. WAIVER

The waiver by either party of any breach of any of the provisions of this Agreement shall not be construed as a
waiver of any succeeding breach of the same or other provisions, nor shall delay or omission on the part of the
aggrieved party to exercise or avail itself of any right, power or privilege that it has, or may have hereunder operate
as a waiver of any breach or default by the other party.

19. NOTICES

19.1 Any notice, request or consent required or permitted to be given or made pursuant to this Agreement
shall be in writing. Any such notice, request or consent shall be deemed to have been given or made
when delivered in person to an authorized representative of the party to whom the communication is
addressed, or when sent by registered mail, telegram or facsimile to such party at the following address;

For CLIENT:
The Managing Director
(NGO Name)
Plot …….., ……………….. Road,
P. O. Box …………………………,
Kampala, Uganda
Tel: (+256) ………………………..

For AGGREGATOR:
The Managing Director
(Aggregator Name)
Plot …….., ……………….. Road,
P. O. Box …………………………,
Kampala, Uganda
Tel: (+256) ………………………..

19.2 Notices will be deemed to be effective as follows:

a) In the case of personal delivery, on delivery.

b) In the case of registered mail, seven days from the date of registration, subject to the confirmation of the
sender.

c) In the case of telegrams, facsimiles e-mail 24 hours from the date of the confirmed transmission.

Digitizing Payments Process Kit

February 20, 2014 Page 65 of 94
 19.3 A Party may change its address for notice hereunder by giving the other Party notice of such change
pursuant to this clause.

20. GENERAL

20.1 This Agreement constitutes the entire Agreement between the Parties and supersedes any previous
Agreement or relationship in respect of the same matter.

20.2 A variation of this Agreement is valid only if it is in writing and signed by or on behalf of each Party.

20.3 Except where this Agreement provides otherwise, the rights and remedies contained in it are cumulative
and not exclusive to rights or remedies provided by law. The failure by either Party to enforce at any time
or for any period any one or more of the terms or conditions of this Agreement shall not be a waiver of
them or of the right at any time subsequently to enforce all terms and conditions of this Agreement.

20.4 If any provision of this Agreement is declared by any judicial or other competent authority or an arbitrator
appointed hereunder to be void, illegal, or otherwise unenforceable, the Parties shall amend that
provision in such reasonable manner as achieves the intention of the Parties without illegality.

21. COUNTERPARTS

This Agreement may be executed in any number of counterparts, each of which shall be deemed an original.

[SPACE DELIBERATELY LEFT BLANK]

Digitizing Payments Process Kit

February 20, 2014 Page 66 of 94
IN WITNESS WHEREOF, the duly authorized representatives of the parties hereto have set hereunto their respective hand
and or seals on date herein above mentioned.

SIGNED for and on behalf of ______________________________________by:

[Aggregator name]

MANAGING DIRECTOR

Name: _____________________________

Signature: ____________________________

Date _____________________________

In the presence of:

DIRECTOR/COMPANY SECRETARY

Name: _____________________________

Signature: _____________________________

Date: _____________________________

SIGNED for and on behalf of _____________________________________ by:

[NGO name]

DIRECTOR

Name: _____________________________

Signature: _____________________________

Date: _____________________________

In the presence of:

DIRECTOR/COMPANY SECRETARY

Name: _____________________________

Signature: _____________________________

Date: ___________________________

Digitizing Payments Process Kit

February 20, 2014 Page 67 of 94
 ANNEX ONE

TRANSACTIONAL FEES

Aggregator Payments Solution Telecoms Charge Aggregator Charge

(Per Transaction in UGX) (Per Transaction in UGX)

Bulk Payments
TBD
TBD

Notes:

The Transactional Fees above are exclusive of all applicable taxes.

Digitizing Payments Process Kit

February 20, 2014 Page 68 of 94
 ANNEX TWO

OPERATING PROCEDURES AND PROCESS FLOW

1. SCOPE OF DOCUMENT

The purpose of this document is to outline the process of Aggregator Bulk Payment Service for Aggregator Merchants,
improve and manage expectations, clarify responsibilities and build the foundation for a win-win relationship between
the Pegasus Technologies Ltd herein referred to as ‘Aggregator’, and the CLIENT using the facility, as well as its clients
(customers).

2. OBJECTIVES OF AGGREGATOR BULK PAYMENT SERVICES

Aggregator Bulk Payment Solution enables organizations (clients) to send money in the form of E-Value to multiple
recipients. The service was designed to assist clients in:

1. Payment of salaries and wages.

2. Payment of suppliers for goods and or services supplied.

3. Payment of winners’ cash prizes in Consumer Promotions.

This greatly reduces their costs in cash handling in terms of Bank charges, security and other Administrative costs.

3. SERVICE DETAILS

3.1 Acquisition

A prospective client may be proactively approached by Aggregator or seek Aggregator Bulk payment services from
Aggregator.

3.2 The CLIENT will be required to submit the following documents to Aggregator for the
purposes of KYC (Know Your Customer)

a) Duly filled Aggregator Payments Solution Application form.

b) Duly signed commercial contract between Aggregator and the CLIENT.

3.3 Implementation of the Aggregator Bulk Payment Solution

o Aggregator will then activate a Aggregator Payment Solution account for the client, with an account number
supplied to the customer. The account will appear in any Email/SMS that customers will receive when funds
have been transferred to their account on Aggregator Payment Solution.
o The client will be required to deposit cash in the Trust Account. (details to be specified in communication to
the client ).this money will be allocated to the CLIENTS’ Aggregator account by Aggregator Treasury team.

o The client can choose to have access to the solution implemented in their premises through either

I. Internet Modem

II. Public Internet Protocol

Digitizing Payments Process Kit

February 20, 2014 Page 69 of 94
3.4 Features of Aggregator Bulk Payment Account

o It is a virtual Aggregator Money Account available in the Aggregator Payments platform.

o Its operations are limited to the Aggregator Payment Platform System available on a PC or internet enabled
mobile phone through a web browser.

o The account created can only be used for sending funds to multiple recipients using the Aggregator Payment
Platform application.

3.5 Transactional Process

1) Funds must be available from the Client’s Aggregator Account.

P/S. Recipients of funds must be registered in the Aggregator Payment Platform system

2) CLIENT creates a register on an Excel/CSV file with the telephone numbers of the recipients as well as the
corresponding amounts to be paid.

3) This register is then saved as a “CSV” file.

4) CLIENT logs into the Aggregator Payment Platform portal and onward to the client’s Aggregator Payment
Platform account.

5) The CSV file is then uploaded onto the Aggregator Payments Platform System.

6) CLIENT’s Aggregator Payments Platform Payments Authoriser clicks send.

7) The Aggregator Payments Platform payments system will then pick information from the file and send funds
as allocated to the respective recipients.

8) Recipients can CASH OUT / withdraw money either in part or full at the nearest telecom agent.

P/S: The CLIENT will be responsible for errors associated with sending funds to the wrong recipients; this is because the
client has the full responsibility to ensure that the csv file created tallies with the list of intended recipients.

Digitizing Payments Process Kit

February 20, 2014 Page 70 of 94
Appendix 1.15 – Required Documentation to Register

1. Certificate of registration

2. Certified copy of certificate of charter/resolution/constitution or equivalent

3. Document specifying allocation of rights (who will have access to accounts and what each
of their rights are)

4. Certified copy of Statement of Particulars of Directors/Members/Partners

5. Copies of identification for the directors

6. Aggregator form

Digitizing Payments Process Kit

February 20, 2014 Page 71 of 94
 Appendix 1.16 – Business Account Opening Form

APPLICATION AND REGISTRATION FORM

FILL IN WITH BLOCK CAPITAL LETTERS

Applicant’s (Organization’s)
Full Legal Name

Name of Building …………….…….. Plot No. & Street ……………………………….…….…

Landlord’s Name …………………………………..…….

Postal Address …………………………………………….…………

Town …………………………………….

Registered Address Office Tel. Contact ………………………………………..

Fax ………………………………………………….

Office Email Address ……………...………………….

Contact Person Name …..……………………………..

Contact Person Email ……………….………….…..

Contact Person Mobile…………………………………
Nature of Business

Yo! Payments Account Details Account Number .............................................................................................................

(Create account online at
[Link] Username …........................................................................................................................

Name …………………………………………………………[Link]…………………………

Particulars of Directors/ Name …………………………………………………………[Link]…………………………

Partners/Members/Trustees
Name …………………………………………………………[Link]…………………………

Name …………………………………………………………[Link]…………………………

Tax Registration Number TIN Number …………….....……………..

VAT Number …………...……………………..
Copy of Certificate of Incorporation/Equivalent Statutory Registration
Document
Copy of Trading License (if applicable)
Required Documents
Copy of at least 1 Director’s ID Card (Managing Director)

Copy of Memorandum/Articles of Incorporation or Equivalent Charter

Additional Information

Digitizing Payments Process Kit

February 20, 2014 Page 72 of 94
I hereby confirm that the information provided above is true and correct and I wish to obtain a Yo! Payments
Business Account. I confirm that I have read and fully understood the terms and conditions available on the
website [Link] I also understand that this Registration Form and the attached terms and
conditions constitute a binding Agreement between me and Yo! Uganda Limited.

For and on behalf of the Applicant

Name _______________________________ Signature ___________________________ Date_____________________

Email Address ___________________________________ Mobile Number __________________________________

Official Stamp/Seal

Verification: I certify that all requisite information has been provided, and I have seen and verified the original
documents for which copies have been provided herewith. Applicant account may be upgraded to a Business
Account.

Yo! Uganda Limited Representative’s Name _________________________________ Signature ___________________

Email Address_____________________________________ Mobile Number ____________________________

Digitizing Payments Process Kit

February 20, 2014 Page 73 of 94
Appendix 1.17 – Authorization Letter

Dear Sir/Madam,

RE: AUTHORIZATION FOR USE OF YO! PAYMENTS ACCOUNT

Please accept my endorsement to use the [AGGREGATOR NAME] account number [ACCOUNT
NUMBER] for our internal business use.

The following individual(s) will be allowed FULL ADMINISTRATOR ACCESS to our account:
Full Names Email Address Telephone Number

The following individual(s) will be allowed VIEW ONLY access to our account:
Full Names Email Address Telephone Number

Any mobile money withdrawal transactions must be pre-approved by the following individuals on
behalf of the company using your "Email Authorization" feature:
Full Names Email Address Telephone Number

In the event that we make a request to withdraw funds from our [INSERT AGGREGATOR NAME]
account to a bank account, these are the details:
Bank Account Name:
Bank Account Number:
[OFFICIAL COMPANY SEAL]
Bank Name and Branch:
Bank Address:

Yours Faithfully,

[NAME]
[DESIGNATION]

Digitizing Payments Process Kit

February 20, 2014 Page 74 of 94
Appendix 1.18 – User Training Manual

Digitizing Payments Process Kit

February 20, 2014 Page 75 of 94
Digitizing Payments Process Kit
February 20, 2014 Page 76 of 94
Digitizing Payments Process Kit
February 20, 2014 Page 77 of 94
Digitizing Payments Process Kit
February 20, 2014 Page 78 of 94
Digitizing Payments Process Kit
February 20, 2014 Page 79 of 94
Digitizing Payments Process Kit
February 20, 2014 Page 80 of 94
Digitizing Payments Process Kit
February 20, 2014 Page 81 of 94
Digitizing Payments Process Kit
February 20, 2014 Page 82 of 94
Digitizing Payments Process Kit
February 20, 2014 Page 83 of 94
Digitizing Payments Process Kit
February 20, 2014 Page 84 of 94
Digitizing Payments Process Kit
February 20, 2014 Page 85 of 94
 Beneficiary Data Collection: Implementing Partners

Appendix 2.1 – Attendance Sheet for Trainings

NGO Organization Name_____________________________________________________________

Place of Activity_______________________________________________________________________
Details of Activity______________________________________________________________________
Activity Starting Date _______________ Activity Ending Date ___________________________
Name of Workshop Supervisor/Staff _________________ Signature _____________________

Participant ID No. Gender District Health Designation Telephone Signature

Name Facility

Digitizing Payments Process Kit

February 20, 2014 Page 86 of 94
Appendix 2.2 – Payment Sheet for Trainings

NGO Organization Name_________________________________________________________

Place of activity___________________________________________________________________
Description of activity____________________________________________________________
Date of activity___________________________________________________________________
Name of activity supervisor__________________Signature_________Date____________

No Participant Mobile Network Title Location Per Transport Total

Name number Diem amount amount
amount to pay

Digitizing Payments Process Kit

February 20, 2014 Page 87 of 94
 Payment Processing: Implementing Partners

Appendix 3.1 – Financial Model for Costs and Savings

Electronic Payments Transition Toolkit

Costing Utility Analysis

Contents
1. Costs of Non-Digital Payments
2. Costs of Digital Payments
3. Cost-Saving Analysis

Introduction & Analysis

Purpose

Across the world today, USAID implementing partners disburse millions of dollars in cash payments each year. These payments include salaries, payments to
vendors, payments to program participants, such as cash-for-work programs, emergency relief payments, and others. In 2012, USAID announced its commitment
to encourage the evaluation and use of electronic payments (e-payments) in development programs including its own, as a member of The Better than Cash
Alliance. USAID also has made the use of e-payments a priority in the Agency’s Implementation and Procurement Reform.

This Workbook is designed as reference tool and guide for organizations to conduct a comparative evaluation of the non-financial and financial costs of using
physical cash and e-payments in their programming and administration. The tool suggests categories of costs that organizations may incur in using cash and e-
payments. Organizations are encouraged to expand and modify the categories to fit a program’s profile. The Workbook also provides an analytical framework for
organizations to compare the identified costs of cash with the costs of transitioning and using e-payments.

Definitions

Non Digital Payments: Program related payments made using physical cash or checks.

Digital Payments or e-payments: Program related payments made using an e-payment process and not by use of physical cash or checks. Examples include
bank transfers (AFT), credit or debit card payments, and mobile money.

Instructions

Cost- Saving Analysis tab: An organization will need to collect and input the quantifiable costs of using cash payments and e-payments to complete the Cost-
Saving Analysis worksheet. This worksheet is designed to evaluate average costs on a monthly basis but can be modified to meet an organization’s program
needs. In order to complete this sheet:
1. Identify whether the expense is non-digital or digital in columns A and F. Columns A through E should be used the capture non-digital costs and columns F
through J should be used to capture digital costs.
2. Using the tabs titled 'Costs of Digital Payments' and 'Costs of Non-Digital Payments', identify the Cost Type that best captures the type of cost you are
quantifying.
3. Document the cost of the specific expense in UGX. This amount in USD will automatically calculate based on the value entered under UGX in columns C and H.
4. Include a detailed description of the event or occurence related to this expense.
5. Continue documenting each expense related to both digital and non-digital payments. Once completed, the Cost-Saving Analysis tab will produce a summary
of costs of using cash payments or e-payments in the program being evaluated.

Digitizing Payments Process Kit

February 20, 2014 Page 88 of 94
Costs of Non-Digital Payments
Financial Model for Digitizing Payments: Costs (Non-digital)

Cost Type Description

Cash payments: Couriers Amount paid to individual(s) who transport money to trainings, excluding per diems

Cash payments: Per diems for staff travelling to field Total value of per diems made to individual(s) traveling to the field
Cash payments: Accomodation for staff travelling to field Total value of hotel or other overnight accomadations made for staff traveling to the field
Total value of transportation (gas for motorbike or bus ticket, for example) for staff traveling to
Cash payments: Transportation for staff travelling to field
the field
Additional costs from having core staff in the field. For example, if another staff member needed
to work 2 additional hours in a given week to make up for the absence of staff member in the
Cash payments: Cost of having staff out of office
field, please include amount paid to the staff member who remained in the office for the
additional 2 hours.
Cash payments: Vehicle hire to distribute money in field Total cost of vehicle hire used to transport money in the field
Cash payments: Fuel for vehicle to distribute money in field Total cost of fuel for vehicle used to transport money in the field
Cash payments: Driver Total cost of driver for vehicle used to transport money in the field

Cash payments: Loss due to fraud Value of funds lost due to fraud

Cash payments: Loss due to theft Value of funds lost due to theft

Cash payments: Insurance) Cost of insurance against theft

Cash payment: Security company fee Cost of hiring a security company to accompany staff travelling to field with cash
Total value of transportation (gas for motorbike or bus ticket, for example) to bank to withdraw
Cheques: Travel to bank
cash
Cheques: Courier charges Amount paid to individual(s) who transport money from the bank, excluding per diems

Cheques: Head office processing Amount paid to head office staff for processing payments

Cheques: Field office delivery Cost of delivering cheque to field office

Total value of transportation (gas for motorbike or bus ticket, for example) to bank to cash
Cheques: Travel to bank
cheque
Total value of transportation (gas for motorbike or bus ticket, for example) to bank to withdraw
Banks: Transportation costs to bank
cash
Banks: Transfer charges Bank transaction costs

Costs of Digital Payments

Financial Model for Digitizing Payments: Costs (Digital Payments)

Cost Type Description

Mobile payments: Bulk payment charge Payment charged by mobile network operator to make bulk payment
Mobile payments: Withdrawal charge Withdrawal fees charged by mobile network operator to withdraw funds

Mobile payments: Technology bought Total cost of technology or software purchased in order to make bulk payments
Mobile payments: Aggregator charge Total cost of fee charged by aggregator to execute bulk payments

Mobile payments: Additional staff Total cost of salaries for additional staff hired to manage and facilitate digital payments

Mobile payments: Purchase of phones Total cost of phones purchased for organization staff or field officers to facilitate digital payments

Mobile payments: Purchase of SIM cards Total cost of SIM cards purchased for organization staff or field officers to facilitate digital payments

Total value of transportation (gas for motorbike or bus ticket, for example) for staff or beneficiaries
Mobile payments: Beneficary costs: Transport costs to agent
traveling to agent to withdraw funds

Digitizing Payments Process Kit

February 20, 2014 Page 89 of 94
Costs-Savings Analysis
Digitizing Payments: Cost-Saving Analysis

Amount in Amount Amount

Non-digital Cost type Description Digital Cost type2 Amount UGX Description 2
UGX in USD USD

0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0

Non-digital total costs (UGX): 0 Digital total costs (UGX): 0

Non-digital total costs (USD): 0 Digital total costs (USD): 0

Savings from non-digital system (UGX): 0 Savings from digital system (UGX): 0
Savings from non- digital system (USD): 0 Savings from digital system (USD): 0

Appendix 3.2 – Payment Sheets in Excel

Sample Payment Sheet

Digitizing Payments Process Kit

February 20, 2014 Page 90 of 94
Sample Breakdown of Bulk Payment

Digitizing Payments Process Kit

February 20, 2014 Page 91 of 94
 Payment Processing: MNOs

Appendix 3.3 – Screenshot of Message Sent to Beneficiary Phone

Digitizing Payments Process Kit

February 20, 2014 Page 92 of 94
 Payment Processing: Aggregators

Appendix 3.4 – Bulk Payment E-mail Notification

From: PEGPAY PAYMENTS INTERFACE [[Link]

Sent: 29 January 2014 15:14
To:
Subject: PEGPAY INTERFACE PAYMENT PROCESSED

Hello <name of approver>,

A payment has been processed by <name of verifier> and is pending approval

Payment BatchNo: 29012014-110

Digitizing Payments Process Kit

February 20, 2014 Page 93 of 94
 Reconciliation and Issue Resolution: Aggregators

Appendix 4.1 – Sample Report

Batch Number Contact Beneficary Name Amount MNO Fee Aggregator Fee Withdrawal Fee Payment No Date Network Status
26102013-1 256795925000 OKITO STEVE 100,000 390 130 1750 P00001 11/1/2013 MTN SUCCESSFUL
26102013-2 256759678944 NYAMBA JAMES 100,000 390 130 1750 P00002 11/1/2013 MTN SUCCESSFUL
26102013-3 256759678945 ARANYA GRACE 100,000 390 130 1750 P00003 11/1/2013 MTN SUCCESSFUL
26102013-4 256759678946 SEBUSI JOE 100,000 390 130 1750 P00004 11/1/2013 MTN SUCCESSFUL
26102013-5 256759678947 MUSCAT AGNES 100,000 390 130 1750 P00005 11/1/2013 MTN SUCCESSFUL
26102013-6 256759678948 GALISA MOLLY 100,000 390 130 1750 P00006 11/1/2013 MTN SUCCESSFUL
26102013-7 256759678949 BORGA PIPPA 100,000 390 130 1750 P00007 11/1/2013 MTN SUCCESSFUL
26102013-8 256759678950 NYAMBA STEVE 100,000 300 130 1750 P00008 11/1/2013 Airtel SUCCESSFUL
26102013-9 256759678951 OKITO AGNES 100,000 390 130 1750 P00009 11/1/2013 MTN SUCCESSFUL
26102013-10 256759678952 SEBUSI DEO 100,000 390 130 1750 P00010 11/1/2013 MTN FAILED - Unregistered
26102013-11 256759678953 MUSCAT DENIS 100,000 300 130 1750 P00011 11/1/2013 Airtel SUCCESSFUL
26102013-12 256759678954 OKITO MARK 100,000 300 130 1750 P00012 11/1/2013 Airtel SUCCESSFUL
26102013-13 256759678955 BORGA MARY 100,000 390 130 1750 P00013 11/1/2013 MTN SUCCESSFUL

Digitizing Payments Process Kit

February 20, 2014 Page 94 of 94