Agency Banking Technical Score Sheet

Key
Other
Compliance Options Scores Compliance Scores
Options
Fully supported (F) F 30 Yes Y 5
Partially supported (P) P 15 No N 0
Not currently supported N 5
Cannot support (C) C 0

Requirements:
Industry Associations and Certifications:
(a) Please list all relevant industry associations and certifications your company belongs to. Please make
reference to the following certifications: Payment Card Industry (PCI) Compliance certifications; Payment
Application Best Practices (PABP); Payment Application Data Security Standard (PA-DSS) certification; and
Data Security Standard (PCI-DSS).
Does your proposed solution comply with all regulations mandated by all relevant payment card brands that
is, Visa, MasterCard, American Express and JCB (for the regions/countries listed above)?

Past Customers:
Has any corporate customer failed to renew a contract, or cancelled a contract before the end of the contract
period, with your company within the last five years?
If yes, please provide details for up to five (5) of such past customers.
Contract Cancellations:
Has your company initiated contract termination with any corporate client within the last 5 years?

THIRD PARTY SUPPLIERS, SUBCONTRACTORS AND ALLIANCES

Please identify any subcontractors that would be directly involved in the delivery of products or services as a
result of this RFP. Please specify the products/services provided by each subcontractor. (A material
subcontractor is defined as a subcontractor performing 25% or more of the contracted Services)

Please describe your company’s process for selecting material subcontractors for transaction processing or
related development.

BUSINESS REQUIREMENTS
Multi Language Support
Multi-Currency Support
Requirements:
a.The system shall support multiple languages through parameters and tables
a.The system shall support multi-currency operations for all transactions and account
balances
b.Please detail all other currencies your system is currently able to recognize
a. The system shall provide for recognition of a unique Customer Account, which uniquely id
 b. A Customer may transact from any one or many of the following accounts:(CORE)
a) Mobile Wallet accounts
b) Bank accounts
System should have capability to support multiple wallets and bank accounts from
customers. It is expected that customer may choose to use the channel for any one of the
following or other services in future: -
Customer Account i. Savings
ii. Loan repayments
iii. Insurance – For insurance and insurance payments
iv. EVD or Top Up wallet- For Agents to sell Top Up/Recharge directly to customer mobile
services interacting with their Bank Accounts

c. A Customer could use the system to interface with one or many of the following
accounts:
a) Banking accounts
b) Mobile Money Wallets
The customer should be able to interact with the various accounts and can move money
from one account to another.
a. Ability to initiate registration of different customer account using an agent POS device,
and validate a customer KYC detail using the national centralised ID system, before
Customer Registration and transmitting the customer registration details to BUBL for further KYC validation and
Account Set Up account set up.
>The system shall provide an
easy-to-use Customer
Registration and Bank
Account set up process with
the following capabilities:

b. Ability to register a customer for an account using a Phone interface and validate a
customer KYC detail using the national centralised ID system, before transmitting the
customer registration details to BUBL for further KYC validation and account set up.

c. Ability to customize requirements, screens, and workflow by BUBL (KYC documentation,

procedures, etc.).
d. Ability for the customer to immediately begin using the system when registration is
completed and validated by BUBL.
e. Ability to interface with external compliance systems to flag any problems and halt the
registration or set up of a customer/agent account
Mobile phone Interface:
a. The system shall support the following mobile phone interfaces:
• SIM card (STK based application)
• USSD based application

User Interface
The primary user interface to i. Registrations
the system will be through
the web interface and the
Mobile web/wap
applications, Agent POS or
M-POS device. However,
other interface options must
also be supported
Agent Administration
Transaction Accounts
Web Interface:
b. The system shall provide a configurable way to present different versions of the Web
user interface depending on the category of user. For example, the menus, screens, and
transactions presented to an agent can be different from what is presented to any BUBL
user, Master-Agent 0r Super-Agent.
c. The system shall allow BUBL authorized users to do their transactions via web
d. The system shall support or have an option of disabling transactions via the web
e. The system shall allow authorized users to use all the administrative functionality via
web, including but not limited to:
ii. Adjustments
iii. View transactions history
iv. View and execute all alerts and notification functionality
v. Generate reports, accounting files, and MIS
f. The system should also have following function on Web-Portal:
a) Agent Management (Adding various agent, master agents and super-agent accounts,
deleting/Modifying those accounts, checking individual sub agent balance).
b) Fraud Management (Checking fraud against daily thresholds, money transfers and PIN
changes and Audit trails)
g. A WAP based version of the application shall be available to run on any WAP supported
hand set model, to perform all phone based functionality
h. A Java (J2ME) based version of the application shall be available to run on downloadable
Java capable device, to perform all phone based functionality (please describe the
operating systems that your applications could be installed on. (e.g. I-phone, Android,
Symbian, Windows CE), particularly for agent transaction interfaces.
The system should be able to support the following under Agent Administration:
• Agent On boarding and Management (web and mobile),
• Liquidity Management
• Commission Payments
• Agent Hierarchy
• Agent Geolocation
• Secure agent biometric authentication
• Advanced reporting
• Agent needs to be able to login to use the application in both online and offline mode.
• The platform should support biometric authentication of customer credentials.
• The platform should support Mobile initiated transactions
Agent Network Management
a. The system shall allow for different types of accounts, with different limits and fee
schedules as set out by BUBL
 b. The system shall process and transmit all transactions to BUBL and/or Switch Provider
(as the transaction processing may require) in real time. No batch processing must be
required. No "shadow balances" should be maintained

Transaction Accounts c. The system shall not allow for partial transactions (Only allow transactions where the
source account has 100% of the funds available and the destination account has 100% of
the limit available).

1. The system shall first validate an agent transaction device (POS, M-POS or Web/Wap
Application) before transmitting a transaction request originating from the agent, at every
instance.

d. The system shall allow the customer/Agent to purchase airtime credit ("Top-Up") using
funds in their bank account, in real time.
• For their own phone
• For another phone (The BUBL should be able to turn this option off)

Top up Airtime
e. The system shall be able to interface to Mobile Network Operators (MNOs), ESB or BUBL
top-up systems as necessary to affect the real-time credit process. (CORE)

f. The system shall notify the customer/agent the status of the top-up request, whether
successful or not.
g. The system shall allow the customer to pay bills using funds in their bank account.
h. The system shall have up to five preregistered payees that will be included on the agent
menu. These shall be displayed and easily selectable by the user.
i. The system shall have the ability to pay the following Paybill Service:
• Utility bills
• Taxes
• Pay TV
• School fees
• Other corporate collection categories

Pay Bills j. The system should validate the invoice number format before performing the
transaction. (validation rules provided by each payee)
k. The system should be able to send a debit transaction request to the respective account
and generate and export a file to an external entity using one of the following file formats:
a) File formats - XML, CSV, Excel, fixed records, etc.
b) Transmission method – FTP, Web services, SOAP, REST, etc.
c) This shall be easily configurable, using a non-procedural configuration technique in most
cases (such as XML)

l. The system shall reflect the new agent bank balance, as transmitted by BUBL as a result
of a withdrawal immediately.
m. The system shall have the capability to notify the agent user of a withdrawal via SMS or
other means in order to detect fraudulent activity
Cash Out
n. The system shall permit the customer to make withdrawals through the Agency
Network. (Who will receive a P2P transaction crediting their agent transaction account)

o. The system shall permit the customer to make deposits through the Agent Network
Cash In (Who will send a P2P transaction debiting their agent transaction account).
Cash In p. The system shall have the capability to notify the agent user of a deposit via SMS or
other means in order to detect fraudulent activity
q. The system shall allow for a rich set of adjustment transactions to be performed by a
designated staff, as needed. (using Web user interface). The Rollback/Reverse should be
Adjustments and Reversals partial or full based on the request by BUBL and should call for approval in case it’s not
system generated.

r. The system shall provide various levels of transaction authority so that sensitive
transactions require higher authorization levels. Refer to the Use Cases in the BRD shared.
s. The system shall provide audit trail and control reports detailing access and adjustment
activity.
t. The system shall permit groups of agent (and/or sub-agent) transaction accounts
associated with the same owner to be linked to another single Master-
Agent/concentration account, provided these agent (and/or sub-agent) accounts and the
Master-Agent/concentration account are held at BUBL. This could mean that a single
Master-Agent could potentially handle and control a maximum of one hundred agent/sub-
agent account operations, using a single consolidated bank account, and
user/administration interface.

t. The system shall permit groups of agent (and/or sub-agent) transaction accounts
associated with the same owner to be linked to another single Master-
Agent/concentration account, provided these agent (and/or sub-agent) accounts and the
Link to a “Master- Master-Agent/concentration account are held at BUBL. This could mean that a single
Agent/concentration” Master-Agent could potentially handle and control a maximum of one hundred agent/sub-
account agent account operations, using a single consolidated bank account, and
user/administration interface.

u. The system shall provide balancing and control reports regarding the various agent/sub-
agent accounts and the associated Master-Agent/concentration account.

v. The system shall support an unlimited number of concentration accounts at different

financial institutions. Upon registration, an agent transaction account may be linked to a
specific concentration account.

w. The system shall be able to connect real-time with the bank’s application using an end-
to-end encrypted messages or a VPN network
x. The system shall be able to connect real-time with the bank’s application to gather
defined agent and/or customer information, limited historical transactions, and balance
information. The system will not store locally information on transactions or balances or
customers. System should be able to perform CASHIN and CASHOUT services with bank
Linking to bank accounts integration.

y. The system shall permit easily configuration and/or customization of the message
format used to transmit message to/from the bank.
z. The system shall be able to obtain error or validation messages from the bank
application and present them to the agent.
 aa. The system shall collect and transmit the authentication information and allow the
bank application to do the user verification which consists of multiple factors. The system
will not store information locally.
User Validation
bb. The system shall be able to send a message to the bank application to register and set
up an account for a customer.
cc. The System must transmit all transactions to the bank in real time, and receive
confirmation in real-time. This will be done by calling Web Services from the bank
Transactions
platform. The system will not store locally any transactional information

dd. The system shall obtain the balance by accessing the bank's system in real-time and
present it to the user
ee. The system shall support and identify various balances maintained by the bank,
including but not limited to:
a) Actual balance (cleared)
b) Available balance
Balance c) Last statement balance
d) Mini Statement and Full Statement

ff. The overhead of a balance inquiry shall be extremely small, as it is anticipated that this
will be a very frequent transaction.

gg. The system shall allow the customer to query their transaction history via the agent by
accessing the bank's application.
Transaction History
hh. The system shall support and identify both cleared and pending transactions.
ii. The system shall be able to trigger a transfer for the bank account to any other allowed
Transfer funds to other account within “the system” (Close loop transfers)
accounts
jj. The system shall immediately trigger a debit to the sending Bank account of the
principle amount plus any fees and taxes
kk. The system should support the following Transfers: (Preferably on-us)
• Bank Account to Bank Account
• Bank Account to Wallet
• Wallet to Bank Account

ll. The system shall be able to trigger the purchase of airtime credit for customers ("Top-
Up") via the agent interface using agent or customer funds in their bank account, in real
Top-Up Airtime time.

mm. The system shall be able to interface to MNO top-up systems as necessary to achieve
a real-time credit process
nn. The system shall notify the agent the status of the top-up request, whether successful
or not
oo. The system shall be able to trigger a bill payment for end-user customer via an agent
Bill payment using funds in the bank account, of either the agent or the customer.
pp. The system shall request the bank application for registered Payees and present them
to the agent.

qq. The bank application will handle the Bill settlement payment process.
 a. The system shall be able to support the integration with all possible NFC API calls for the
Agency Banking Services.
b. The system shall support NFC chipped devices, NFC apps, NFC based stickers, SD cards
and embedded antennae devices and NFC enabled POS terminals.
NFC compatibility c. The service response for NFC request should be quick in nature and follow industry
Requirements standards.
d. The system should adhere the NFC security standards required for Agency Banking
services

Notifications and Alerts

a. The system shall contain a Notification and Alert engine, which interfaces with other
components to provide a generalized messaging platform.
b. The system shall log all messages sent. (in the centralized database)
c. The notification system shall allow internal users (Customer Service, Marketing, Agent
Management Team etc.) to send individual and/or bulk messages to agents that have
accounts domiciled in the respective banks / Financial Service Providers. A user interface
shall be provided to facilitate this function.

d. Transaction specific notifications. Including, but not limited to

a) Money transfer received / sent (including confirmation number)
b) Bill payment (including confirmation number)
c) Transaction amount exceeds a certain threshold, set by the respective FSP
d) Number of transactions during a period of time (e.g., daily) exceeds a certain threshold,
set by BUBL

e. Change in account information, including, but not limited to, that has been originated
through the agent channel, in the first instance;
a) National Identity Number
b) Mailing address
c) Email address
d) Phone Number
e) Account access
f) Occupation
General g) First and last name.

f. The system shall be easily configured to send an alert when the agent transaction
Balance is below a minimum threshold, set by user (Master-Agent, in respect of its own
agents/sub-agents) or Financial Service providers.

g. The system shall notify agents/users in plain language, when transactions fail, including
but not limited to. Messaging shall be table driven (CORE)
a) Due to technical or communication error
b) Due to data error (unrecognized /closed destination account)
c) Due to limits validation at source and destination accounts

h. System should be capable of sending notifications and/or Alarms whenever there is a

disturbance/connection loss discovered with any third party integration like USSD, Bank
Application and VPN etc. Please describe any additional notifications that your system can
handle.

BUBL will use their existing
Customer Service
Relationship (CSR) system
that handles calls, queues,
tickets, etc. This chapter talks
about the system that will
contain the information the
CSRs will use to provide the
support.
i. The system shall comply with the Payment Application Data Security Standard (PA-DSS)
j. They system shall be compliant by Visa and Master Card standards. (If your company is
currently certified please provide details on the certification type, and dates obtained)
Customer Service Subsystem
a. The system shall provide a user friendly web interface to allow all Customer Service (SC)
Agents to enquire information and perform specific transactions.
b. The system shall provide an interface which is configurable at the user or group level.
These configurations include, but are not limited to, the following:(CORE)
i. Identify the language and currency to be used throughout the user interface
ii. Identify what privileges the user or group has. The system shall provide a method by
which the access for each atomic business function, as listed below, can be specified by a
user or group.
 Cannot access
 Read Only
 Update
 Submit for approval
 Approval authority
c. The system shall provide a set of user friendly screens to allow the setup of the
customer support functionality. The setup features shall include, but are not limited to, the
following.
i. Designate multiple levels within the organization
ii. The system shall allow each sub-level to inherit or override the settings of the level
below.
iii. The system shall allow the ability to create or Reset the username or password of each
Customer Service
d. The system shallAgent.
provide the functionality to allow customer support to properly
identify/authenticate the customer. How a customer is identified/authenticated can be
configured by BUBL or using a standardised approach. (CORE)
e. The system shall provide the ability to display all Master-Agent related agent/sub-agent
accounts at the same time
f. The system shall allow BUBL Customer Service (CS) Agent with the proper authority to
update customer data (CORE)
g. The system shall allow a CS Agent the appropriate user friendly screens to open,
inactivate/activate, close, or re-open an sub-agent/agent/master or super-agent account.
h. The system shall provide intuitive and user-friendly screens to allow the sub-
agent/agent/master/super agent account profile to be set up and maintained.
Pricing Subsystem
a. The system will provide web based "Pricing Subsystem", where all pricing and fees for
any and all transactions originating through the system are maintained
 b. The system shall be able to calculate pricing in any of the following ways, for different
types of transactions:(CORE)
a) Percentage
b) Fixed amount
c) Percentage with minimum amounts.

c. The system shall provide a web interface to build pricing plans for individual or groups
of BUBL or agents. (CORE)
d. The system shall provide pricing rates that can be based on geographical regions,
including rural vs urban pricing:
e. The system shall provide pricing rates by transaction type. (CORE)
f. The system shall provide pricing rates by vendor, BUBL, or merchant/payee.
g. The system shall provide a means for setting start and end dates for when pricing plans
are effective
h. The pricing(CORE)
sub-system shall interface all transactions and appropriate functions within
the respective accounts to calculate the correct fees associated with a transaction. The
Pricing Sub-system shall provide the ability to calculate fees real-time while the transaction
or business function is being executed.

i. Ability to associate deferent accounts (from different users) in a hierarchical structure for
commission earning purposes
j. The system shall allow for certain accounts to be flagged as commission earning
accounts.
k. The system shall be able to provide pricing based on time, including, but not limited to
a) Time of day
b) Day of month
c) Specific dates
d) Holidays
e) Weekends vs. weekdays

l. The system shall be able to provide pricing rates by linking to a Loyalty program.
m. The system shall provide an interface to allow BUBL to define promotions. These
promotions include, but are not limited to the following features which may be grouped
together in various combinations to create unique promotional offerings:
a) Discounts for new customers including but not limited to
b) Free or reduced fees for a period of time
c) Rebates of varying amounts based on criteria included type of account, amount of initial
deposit, commitment to keep account, number of services purchased.
d) Rebates for new customer referrals
e) Rebates or fee discounts for activities including deposit amounts, deposits on a period
of time, using certain transactions, using transactions with certain vendors.

Commissions or Revenue Sharing Subsystem

i. Percentage of total transaction amounts based on total amount of transactions over a
specified time frame. The percentage can apply to the total amount (tiered) or can vary for
specified amount ranges (banded)
a. The system shall provide a
web interface to build
revenue sharing plans for
vendors, master-agents/sub-
agents/agents, billers, or
partners. These plans
include, but are not limited
a. The system shall provide a
web interface to build ii. Percentage of a specific transaction type or set of transaction types based on volume of
revenue sharing plans for transactions over a specified time frame. This can be tiered or banded as above
vendors, master-agents/sub-
agents/agents, billers, or
partners. These plans iii. Specified amount based on total transaction volume over a specified time frame. The
include, but are not limited total amount may be calculated on a tiered or banded basis.
to, the following features
which may be grouped iv. Tiered or banded rates may be specified by region, market, or product line
together in various
v. Tiers or banded rates may vary between different vendors, billers, or partners
combinations to create
unique revenue sharing plans vi. Rates may have start and end dates specified.

b. The system shall provide the capability to calculate the percentage of revenue to collect
or send to any sub-agent/agent/master-agent, biller, vendor, or partner.
a. The system shall provide the capability to define and customize agent commissions
through web interface
b. The system shall provide the capability to define commissions based on agent hierarchy
and type (Super, Master or Agent or Sub-Agent)
c. The system shall provide the capability to define commissions based on Dynamic and
Static definitions based on various parameters, including:
i. Based on transaction pattern and history
ii. Based on location
iii. Based on interface used
iv. Based on month, week, day or time
Agent Payment/Commission v. Ability to offer promotional schemes
Management

d. The system shall provide automated pay-outs of commissions with ability to define and
customize frequency
i. Real-time payments
ii. End of the day, week or month payments

e. The system shall provide the capability to define and effect applicable Tax deductions/
adjustments based on prevailing rate and rules relating to agent transaction commissions

a. The system shall interface with an external General Ledger (GL) system using industry
standard messages
b. The system shall support batch and real-time GL feeds.
c. The system shall support detail and summary entry GL feeds. These may be specified by
Connectivity with accounting account.
systems
d. The GL interface shall be maintained via tables or other non-programming configuration
parameters.
e. The system shall produce appropriate control and balance reports regarding the GL
interface. (CORE)
a. The system shall provide a rich set of easy-to-access management information, using a
web, real time facility.
a) The system shall provide summary, intermediate, and detail reports/screens.
b) The system shall provide an easy-to-use drill-down capability.
c) The system shall provide appropriate, error, balancing, and control reports.
 b. The system shall allow exporting of selected information to common formats, such as:
a) Excel
b) Word
c) XML
d) Fixed field.

Management Information c. The system shall keep all information, including all transactions, for a minimum of 10
years. (CORE)
d. The system shall provide a means to automatically and manually archive reports in such
a manner that they cannot be changed.
e. The system shall support generation of reports in PDF format.
f. They system shall be able to allow for masking of data for certain fields.
g. The system shall allow for printing a statement for a period defined by the user. A
statement shall include a detail of all transactions in the period, and a summary of debits,
credits and personal information of the accountholder
h. The system shall automatically generate required reports on BUBL -defined periodic
basis (such as overnight) so they are instantly available when requested.
i. The system shall be able to export the hierarchical association structure amongst
commission earning flagged accounts.

NON FUNCTIONAL REQUIREMENTS:

a. The system shall be engineered for continuous availability.
i. There shall be no need to shutdown the system for maintenance, enhancement, backup,
etc.
ii. The application should be separated from the database server to enhance security and
performance.
Reliability, Availability, iii. The system will use clustering or other technology to ensure no single point of
Serviceability hardware failure.
iv. The system shall allow changes to be rolled back without the need for shutdown or
restarting.

b. In the rare event of a system failure, the system shall be able to restart in less than 10
minutes.
c. The system shall allow for failover to remote locations (Disaster Recover Site (DR))

d. The vendor shall be able to demonstrate availability in excess of 99.999%

Please suggest the technology that will be used to achieve this
e. The system will provide early warnings of potential issues which may indicate an
integrity problem
f. The system shall log all errors and minor failures, including software exceptions so that
they may be analyzed by the FSPs.
g. The system shall include a robust data backup and archiving system.
h. The system shall support SNMP and generate traps to an external Network
Management System
i. The system shall for any
provide issues
a fast detected.
backout capability when system changes cause problems.
(The system shall be hot-fixable)

Security

The system will support
financial transactions and
as such requires the
highest level of end-to-end
security.
a. The system shall maintain agent transaction PIN for each user.
a) The system shall require the PIN to be structured in such a way as defined by BUBL. .
b) The system shall require the user to change the PIN on a FSP-defined schedule.
c) The system shall encrypt the PIN in such a way that it may never be displayed or
determined.
d) The system shall allow respective Customer Service to reset the PIN, and then require
the agent to change the PIN on first use
b. The system shall allow a secondary layer of security (user-generated password) to the
agent.
c. The system should support Strong multi-factor authentication and authorization, PSD2
and GDPR compliance, and an out-of-the box support for a number. (Use of Biometrics,
Card, USSD or OTP)
d. The system should have dual controls – maker and approver.
e. The system should be able to Issue SMS alert to the customer for every transaction they
complete; both on their account and on a third party’s account.
f. Each level of user in the hierarchy within the Agency solution should be able to create
users only one level below them
g. It should support approval limits at different levels / hierarchies
h. The system shall support connections to third parties using virtual private networks
(VPN).
i. Transactions performed on the public domain must be done within a secure socket layer
(SSL) environment
j. The system shall conform to the latest PCI DSS security standard
k. The system shall use AES or 3DES encryption when transmitting data over
communications facilities. If the system uses any other type of encryption, please list it
l. Please explain if your system supports and/or is compliant the following protocols:
a) 3-D Secure
b) MasterCard SecureCode
c) Verified by Visa
d) J/Secure
m. The system shall have the ability to encrypt messages and use USSD as a
communication channel
n. The system shall log all customer logons, logoffs, and failed access attempts.
o. The system shall log all Administrator logons, logoffs, and failed access attempts.
p. The system shall log all administrator activities. Clearly showing the date, User ID, User
Name, change description, previous value and new value, then approver’s details to list
but a few.
q. The system shall disable an agent's or other user’s access if an invalid PIN or password is
supplied in excess of a defined limit
r.The system shallnot allow concurrent multiple logins to the same account
 The system should be able to support the following under Agent Administration:
• Agent On boarding and Management (web and mobile),
• Liquidity Management
• Commission Payments
• Agent Hierarchy
Minimum Length of passwords should be 8 characters.
• Agent Geolocation
• Secure
The password
agentmust
biometric
have at
authentication
least one uppercase letter, lowercase one number and one
special character
The password must be changed on first access.
The password must be changed every 30 days.
The password cannot be re-used (at least 6 previous passwords).
When the password is entered, a mask should be used to hide it.
Policy Settings The user must have the option to change the password upon successful logon.
A notification or message with information of the last time accessed and number of failed
attempt should be displayed at logon.
A User ID cannot logon to more than one session at the same time.
A User ID with three failed logon attempts must be disabled.
A User ID that has been inactive for 10 minutes must be locked
A User ID that has been inactive for 30 days must be disabled.
t. Are passwords for applications encrypted during storage and transmission?
u. Field Level Security: Does your system support Field Level Security for specific functions
(e.g. User A can view an Account Balance and Credit Limit, whereas User B can view only
the Balance)?

v. Audit Trail: Do applications have audit log tracking built in and enabled?
w. Encryption: Do applications support encryption of data transmitted over the Internet or
other open networks?
x. Verification: Please describe the processes in place to verify that application source code
is secure and not susceptible to known application security vulnerabilities.

y. Updates: Please describe how updates to applications are typically handled, and how
often?
z. Updates: Please state if your solution supports Hardware Security Modules?
aa. Updates: Please describe the limitations of applications?

Performance
a. The system shall be vertically scalable to support up to several million customers, with
sub-second response time.
i. At the core, the system shall provide a high-speed transaction processing engine.
ii. The system shall be able to handle up to several thousand transactions per second

Please indicate the total processing volumes (accounts and transactions) that your
proposed solution currently manages and the maximum volume capable of managing.
b. The system shall be scalable horizontally (using multiple servers) if desired with minimal
overhead.

c. The system shall leverage multiple processers and generally be built using multi-
threading techniques.
d. If the system shall become overloaded, it will not crash, but will reject new transactions
with an appropriate error message or code.
e. System must be able to guarantee its response times to the users - for example, if a
node or logic is taking too long to respond during an active transaction, the user should get
back a message stating “Our servers are busy at this time. If you do not receive a
successful notification, please try again”.

f. System should have timers in place so that it doesn’t wait indefinitely for external nodes
to respond.

Extensibility
a. The system shall be extensible by the respective FSPs using own programming resources
or outside organizations.
i. This extensibility should be performed using common programming languages,
preferably Java or .Net (C#).
ii. The system will use standard databases which should be directly accessible by the
company, if needed (Oracle, SQL Server, etc.)

b. The system should come with extensive, detailed technical documentation so that the
respective FSPs may enhance and otherwise modify the system, as it sees fit.
c. The vendor shall offer customization services at an agreed upon rate. These services
shall be readily available.
d. Please inform if your company can supply the source code for all core business
processes and functions.

e. The vendor shall maintain source code and detailed technical documentation of all
components in a suitable escrow facility. This may be accessed by the participating FSPs
and/or partners, as may be agreed, in the event of failure by the vendor to perform.

Audit and Control

a. All transactions shall be timestamped
b. The system shall keep detailed audit and control information.
c. The system shall log all transactions, messages, and changes in a form suitable for
research, inquiry, debugging, investigation, etc.
d. The system shall identify all transactions with a unique number.
e. The system shall log the origin of all messages and transactions.
f. The system shall produce audit and control reports as required by law or generally
accepted best practices, and as defined by the company.
g. The system shall be capable of comprehensively managing risks and
detecting/preventing fraud.
Reporting Requirements
Network monitoring via standard reports is a key requirement. The Agency solution should
be able to generate these categories of reports. Refer to the RFP for the list of report.
System would be able to provide all the reports above. Please specify which of the reports
are supported and those that are not.

Technology
a. The system shall be developed using modern programming techniques, such as:
i. Object orientation
ii. Relational databases
iii. Model-driven architectures
iv. Loosely-coupled components
v. Web services
vi. XML

b. The system shall provide all computer user interfaces using a web browser.
i. No client-side code should be necessary
ii. The system shall support Internet Explorer and Firefox browser

c. The system shall run on Commercial Off-The-Shelf (COTS) hardware, preferably:

i. UNIX servers, such as Sun, IBM, and HP
ii. Windows servers, such as Dell, IBM, and HP
iii. Please provide the technical requirements for your system, Server Operation System,
database type and how many servers are required

d. The system shall support clustering.

e. The system shall support database replication or an equivalent technique.
f. The system shall come with documented development, enhancement, and testing
processes.
g. The system shall interface with common FSP and MNO systems
h. The system shall have a set of APIs for it to interface with different systems and
applications.

i. The Agency solution should be able to Connect any Core Banking System (CBS) especially
ORBIT R, existing or third-party system.
j. Should support cloud and hosted environments and should contain a platform-
independent storage system
k. The Agency Solution is required to provide the ability to perform Store and Forward of
messages between the various services and clients of the Connecting Bridge, both in
synchronous or asynchronous mode.

l. Support for reusability of common services.

m. Integration Support for 3rd party services
n. Load Balancing, Audit, System and History logs
o. Service switching and routing is key ―enabling service of the Connecting bridge which
ensures that a service is accessed in most efficient and performing manner.
p. Support for multiple protocols such as: HTTPS, Relational databases, SMTP, TCP/IP, flat
files, FTP, etc.
q. Should have scalable capacity and system resiliency; vertical and horizontal scalability
thus Limited CRs.
r. Encryption / decrypting and digitally signing of business data / messages across the
boundaries of the transaction.
s. Support for the fundamental Web and Web services standards, including URIs, XML,
SOAP and WSDL.
t. Data integration. Adapters for a range of source types beyond relational database
management systems and legacy databases, including packaged applications and Web
services, that extend the potential reach of the technology.

u. Communication between core application and agencies/partners should be secured,

even if secured network is used for the connection. SSL and/or WS-Security will be applied
as appropriate.

v. Setting standards for the integration & SOA platform to adopt a fully integrated
environment.
w. Centralised integration solution to provide a faster turn-around time to meet the
business demands.
x. Faster integration of the solution with the core banking system with new channels.
y. Standardization on Integration and SOA Platform.
z. Ease of implementation and development for future integration (reduce development
and integration effort).
aa. Should provide for Open APIs Partner with anyone in your ecosystem
a. Provide a high-level physical diagram and component diagram for the solution
(elaborate on module interactivity and contextual model showing all interactions with
functional modules)

b. Include definitions of all the tiers described in the physical diagrams and component
diagrams for the solution. Articulate the roles performed by each tier

c. Provide a diagram of the recommended Architecture distribution, and explain at a high

level.
d. Provide a Disaster Recovery Solution (DR) for the agency banking services. The DR setup
should be designed to be used as Reporting server also. Disaster Recovery solution should
use industry standard functionality.

Hardware Interface Requirements

As this is a multifaceted system with different channels and hardware requirements, this
will be broken down into the specific parts.
i. POS Devices
ii. POS Devices (Smart)
o The POS devices must all be EMV compliant and be PCI-DSS certified
o The devices will allow APNS to be configured on at least two SIMs
o Allow use of NFC and EMV cards.
iii. Mobile Phone (Smart)
iv. Mobile Phone (Feature)
v. Server hardware
vi. Security Hardware
vii. Network, database and Data centre hardware
viii. Cloud Configuration(s)
Does your company comply with all of the above assumptions regarding the hardware
interface requirements?
 If no, please describe which of the above may not apply to the proposal, explain why and
suggest an alternate arrangement

IMPLEMENTATION& MIGRATION
d. Implementation Penalties: the Project Stakeholders will have the right to assess credits in favour of themselves, jointly
and/or individually, if the Supplier fails to meet the mutually agreed implementation timeline.
Will your company comply with this requirement?

If no, please explain why and suggest an alternate arrangement.

e.Implementation Dependencies: Please respond if you foresee any major dependencies with other technologies.
If yes, please provide high-level information

SERVICE LEVEL AGREEMENT

a. Minimum Service Levels: The Supplier's level of performance shall be equal to the Service Levels and to standards
maintained by well-managed, world-class operations performing similar services:
Will your company comply with this requirement?

If yes, please explain. If no, explain why and suggest an alternate arrangement.
b. Development Service Levels: With the exception of regulatory compliance development Supplier will implement any
custom developments, requested by this RFP and Project stakeholders, in accordance with an annually published and
mutually agreed release schedule.
Will your company comply with this requirement?

If no, please explain why and suggest an alternate arrangement.

c. Development Service Levels: Supplier will implement any custom developments, requested by BUBL to meet
Regulatory compliance. If Supplier fails to comply on the requested date or by a regulator approved date supplier will
mitigate any penalty assessed to the Stakeholders by the Regulating entity.
Will your company comply with this requirement?

If no, please explain why and suggest an alternate arrangement.

d. Development Service Levels: Please provide a copy of your company’s documented process to manage custom
developments. Please include both your company’s own project responsibilities and the Project Stakeholders’
responsibilities during the process:

e. New Product Service Levels: Please provide a copy of your company’s documented process to implement new
products. Include both your company’s own project responsibilities and Project Stakeholder’s responsibilities during the
process:
SLA Management: The Supplier will have in place monitoring tools and procedures to measure SLA performance, and
will provide SLA performance reports (hard copy and electronic) at no additional cost.
Will your company comply with this requirement?
If yes, please provide templates of documentation to be used. If no, please state why and offer an alternative approach
below.
f. Root Cause Analyses: If Supplier fails to meet any Service Level, Supplier shall promptly: (a) investigate, assemble,
preserve and provide pertinent information; (b) perform a root cause analysis of the problem; (c) advise the relevant
Project Stakeholders of the status of remedial efforts being undertaken with respect to such problem; (d) minimize the
impact of and correct the problem; and (e) take appropriate preventive measures so that the problem does not recur.
Will your company comply with this requirement?

If yes, please provide templates of documentation to be used. If no, please state why and offer an alternative approach
below.
g. Periodic Reviews. On a quarterly basis, or such other time frame as the Project Stakeholders and Supplier agree, will
review the Service Levels and will make adjustments to them as appropriate. The parties expect and understand that the
Service Levels will be improved over time without impacting the agreed pricing.
Will your company comply with this requirement?

If no, please state why and offer an alternative approach below.

AUDIT
a. Audit: At any time during the Contract Term, in the event BUBL wish to conduct an audit regarding (A) the security
and integrity of an FSP’s Account data, (B) the amounts of fees or expenses charged, (C) or Supplier’ measurement,
monitoring, reporting process and success in achieving the Service Levels, Supplier shall allow BUBL or the relevant
project stakeholder to review their policies, practices, procedures and other appropriate documentation and make
inquiries which relate to the specific issues identified during the audit.
Will your company comply with this requirement?

If no, please explain why and suggest an alternate arrangement.

b.Results of Audit: If an audit reveals an overcharge or any other service deficiency, Supplier shall promptly refund such
overcharge and will either remedy the deficiency or provide a remediation plan outlining the steps it will take to remedy
the deficiency depending on the nature of that deficiency within six (6) months of the discovery of the service deficiency.
Will your company comply with this requirement?

If no, please explain why and suggest an alternate arrangement.

c. Regulators Audit: Supplier shall understand that the business practices are subject to review and audit by Regulators.
Supplier shall fully cooperate with the Regulator in accordance with applicable law in conjunction with an audit of
Supplier by the Regulator. Furthermore, in conjunction with an audit of any stakeholder by a Regulator, Supplier shall
cooperate with any request of the Regulators to review the Services, including, without limitation, providing any
information or material lawfully requested by the Regulator, and permitting the Regulator to inspect or audit Supplier as
to the Services in accordance with applicable law.
Will your company comply with this requirement?

If no, please explain why and suggest an alternate arrangement.

d. Records Retention: Supplier shall retain all relevant information, records and including documents relating to the
provision of the Services for as long as Services continue to be provided under the Agreement and thereafter for as long
as is required by applicable law or regulation. Supplier shall comply with Regulator's record retention policies and
maintain and provide access upon request to the records, documents and other information required to meet the
Stakeholder's audit rights.
Will your company comply with this requirement?

If no, please explain why and suggest an alternate arrangement.

 Responsed / Comments

All required certification and

hardware is PADSS certified

Not Including any 3rd parties

Responsed / Comments
nd tables Supports upto 8 languages
ons and account

ecognize supports multicurrency

ount, which uniquely idAvailed in the agency banking module
ccounts:(CORE)

accounts from
nel for any one of the

to customer mobile

the following

nd can move money

an agent POS device,

system, before
C validation and

ce and validate a
transmitting the
account set up.

(KYC documentation,

hen registration is

roblems and halt the

ersions of the Web
menus, screens, and
sented to any BUBL

ons via web

ns via the web
ve functionality via

er-agent accounts,
lance).
ey transfers and PIN

n any WAP supported

o run on downloadable
e describe the
-phone, Android,
only supported android agent
application as smart pos and
mobile are android based
ministration:

e and offline mode.

credentials.

nt limits and fee

d/or Switch Provider
ocessing must be

sactions where the

account has 100% of

-POS or Web/Wap
m the agent, at every

edit ("Top-Up") using

s (MNOs), ESB or BUBL

ORE)

p request, whether

ir bank account.
included on the agent

e:

orming the

he respective account
following file formats:

tion technique in most

d by BUBL as a result

withdrawal via SMS or

gh the Agency
ransaction account)

he Agent Network
ount).
 eposit via SMS or

be performed by a
k/Reverse should be
oval in case it’s not

that sensitive
es in the BRD shared.
ccess and adjustment

ction accounts
er-
nt) accounts and the
mean that a single
e hundred agent/sub-
and

ction accounts
er-
nt) accounts and the
mean that a single
e hundred agent/sub-
and

he various agent/sub-
ount.

counts at different
nt may be linked to a

lication using an end-

ication to gather
ctions, and balance
tions or balances or
services with bank

of the message

m the bank
tion and allow the
e factors. The system

on to register and set

e, and receive
rom the bank
tion

em in real-time and

d by the bank,

anticipated that this

story via the agent by

ransactions.
to any other allowed

ccount of the

n-us)

or customers ("Top-
ank account, in real

s necessary to achieve

t, whether successful

stomer via an agent

.
ees and present them

cess.
 e NFC API calls for the

ed stickers, SD cards

d follow industry

Agency Banking

erfaces with other

e)
e, Marketing, Agent
agents that have
ers. A user interface

tive FSP
ds a certain threshold,

has been originated

ent transaction
n respect of its own

actions fail, including

whenever there is a
tion like USSD, Bank
that your system can
ty Standard (PA-DSS)

. (If your company is

d dates obtained)

Customer Service (SC)

user or group level.

ORE)
interface
ovide a method by
can be specified by a

setup of the
are not limited to, the

ttings of the level

or password of each
ort to properly
thenticated can be

ated agent/sub-agent

proper authority to

eens to open,
super-agent account.

w the sub-
aintained.

pricing and fees for

ed
g ways, for different

individual or groups

aphical regions,

nt/payee.
or when pricing plans
iate functions within
a transaction. The
e while the transaction

erarchical structure for

ssion earning

g, but not limited to

alty program.
omotions. These
ch may be grouped
ings:

ount, amount of initial

d.

deposits on a period
ndors.

transactions over a
(tiered) or can vary for
s based on volume of
d as above

fied time frame. The

duct line
or partners

e of revenue to collect
ner.
ent commissions

ed on agent hierarchy

ed on Dynamic and

h ability to define and

able Tax deductions/

saction commissions

stem using industry

se may be specified by

amming configuration

regarding the GL

information, using a

ts/screens.

l reports.
 on formats, such as:

r a minimum of 10

rchive reports in such

elds.
d by the user. A
a summary of debits,

-defined periodic
ted.
cture amongst

nhancement, backup,

enhance security and

ngle point of

d for shutdown or

start in less than 10

ecover Site (DR)) refer to DR document for

details
9.999% Weblogic clustering and DB
clustering can be achieved
may indicate an
Suspicious txn monitoring
module
e exceptions so that can be accessed in the back
end portal
m.
Network
anges cause problems. refer to DR document for
details
 defined by BUBL. .
ned schedule.
e displayed or

N, and then require

Sytems supports Dual

authentication
ed password) to the Sytems supports Dual
authentication
authorization, PSD2
(Use of Biometrics,

every transaction they

ld be able to create

private networks

a secure socket layer

ta over
ption, please list it
owing protocols:

SD as a

attempts.
cess attempts.
Reply given to failed support
all options
e date, User ID, User
over’s details to list

alid PIN or password is

ccount
ministration:

e number and one

sful logon.
and number of failed

mission?
for specific functions
User B can view only

bled?
d over the Internet or

pplication source code

lities.

handled, and how

Modules?

System all features and

functionality supported by
core banking system

ion customers, with

essing engine.
tions per second

ons) that your

able of managing. Number of txns not
specificied
desired with minimal

lt using multi-
 ject new transactions Number of txns not
specificied
- for example, if a
on, the user should get
not receive a

ely for external nodes

rogramming resources

g languages,

ccessible by the

entation so that the

sees fit.
te. These services

ore business
We cannot provide source
codes for any module but we
support escrow facility
umentation of all
e participating FSPs
dor to perform.

orm suitable for

law or generally

nd

Agency solution should

the list of report.
y which of the reports
ques, such as:

browser.

e, preferably:

r Operation System,
More to be discussed based
on the TPS requirement by
the bank team

hnique.
ent, and testing

500+ 3rd party intergrations

t systems and

ystem (CBS) especially

n a platform-
support both cloud and
campus hosted environment
tore and Forward of
g Bridge, both in
intergrate with existing sms
gateway

necting bridge which

anner.
es, SMTP, TCP/IP, flat

orizontal scalability

sages across the

luding URIs, XML,

tional database
lications and Web

should be secured,
ecurity will be applied

lly integrated

me to meet the

th new channels.

educe development

tem
the solution
interactions with

ms and component
r

and explain at a high

services. The DR setup

overy solution should

e requirements, this

ed

ding the hardware

osal, explain why and

Responses

of themselves, jointly

r technologies.

and to standards

er will implement any

ally published and

UBL to meet
d date supplier will

anage custom
keholders’

plement new
onsibilities during the
performance, and

alternative approach
tigate, assemble,
dvise the relevant
m; (d) minimize the
em does not recur.

alternative approach

Supplier agree, will

d understand that the

ing (A) the security

’ measurement,
or the relevant
ation and make

promptly refund such

it will take to remedy
the service deficiency.

d audit by Regulators.
with an audit of
ator, Supplier shall
providing any
ct or audit Supplier as

nts relating to the

thereafter for as long
on policies and
ed to meet the
 Vendor 1 Vendor 2
Score Scale (1-5) Score Scale (1-5)
1 Ease of use
Are important features accesible with few clicks
Do field labels and application content speak the
language of the industry
Are colors and visuals easy on the eyes and provide
visual clues for intuitive navigation
Do all screens share a common organization and
styles to create familiarity for users?
Is contextually appropriate help available at important
decision points?

2 Application interface
Ability to run on USSD and Mobile App
Ability to integrate with the Switch for Cardless
Transactions
Ability to use Biometric POS

Ability to work with different POS devices in the market

3 Customer registration
Registration using POS
Registration using Mobile
Fields required to open account;First and last
Name,Gender,Date of birth and ID
Preconfirmation window for all
Account delivery time>20 secs

4 Agent Transaction use cases(App/USSD/POS)

Account Opening
Cash out ,Cash in
Agent balance
Bill payments
Mobile Top up for all networks
funds transfer
User validation
Loan Application
SMS Alerts

5 Customer Interface-USSD/POS
Initiate cash cash out
Balance inquiry
mini statement
 funds transfer

6 Agent admnistration
Agent On boarding and Management -web
Master agent registration and user creation
limit password trials
• Liquidity Management
• Commission Payments
• Agent Hierarchy
• Agent Geolocation
• Agent needs to be able to login to use the application
in both online and offline mode.

7 Pricing Subsystem
The system shall be able to calculate pricing in any of
the following ways, for different types of transactions:
(CORE)
Percentage ,tiered,flat
Pricing plans for individual or groups of BUBL or
agents. (CORE)
Pricing rates that can be based on geographical
regions, including rural vs urban
Pricing rates by transaction type.pricing:
(CORE)
Pricing rates by vendor, BUBL, or merchant/payee.

8 Agent Payment/Commission Management

b. The system shall provide the capability to calculate
the percentage of revenue to collect or send to any
sub-agent/agent/master-agent, biller, vendor, or
partner.
a. The system shall provide the capability to define and
customize agent commissions through web interface

9 Reporting
Report generation in different formats
Agent creation reports
Account opening reports
commission reports

10 Security
change the PIN on a FSP-defined schedule.
support Strong multi-factor authentication(Use of
Biometrics, Card, USSD or OTP)
The system should have dual controls – maker and approver.
encrypt messages
The system shall log all administrator activities
 concurrent multiple logins to the same account

11 Non functional requirements

Reliability, Availability, Serviceability
The system shall include a robust data backup and archiving system.

TOTAL 0 0

Scale to be used for each question:

0 = Non compliance
1 = Relatively low levels of compliance
2 = Partially compliant
3 = Relatively high levels of compliance
4 = Advanced levels of compliance
5 = Fully compliant
Vendor 3
Score Scale (1-5) 1
2
3

5
0
References TECHNOLOGY ELEMENTS %
Usability/Ease of Use: UX – User and Customer
5
Demo guide 1 Experience?
Demo guide 2 User Interface/Visuals: UI (Look and Feel) 5
Flexibility: Does the system allow changes in
6,7,8 based on demo score workflows and process flows requested by different 5
guide users

If we are intergrating e- Extensible? Customizable?: - Is the system modular? Is

systems , how easily can this 5
it easily adapted to existing/new processes
be done ?Add modules for
Mobile banking,merchant,
health, insurance ,money
transfersmodules?
Compatibility with common APIs: Adherence to
common protocols for connectivity and data exchange 5
Thirdparty billers between players

Security: Demonstrate security measures taken

against common threats (virus, malware, DDOS,
5
phishing, etc). General and/or Specific fraud
refer to the security Demo
detection and reporting
guide

Non functional Backups: Demonstrate procedure for data and

reqmts;availability ,scalability 3
application backups
and reliability
Features: Does the system provide at least 90% of
10
4,security , reporting features requested?
SUB-TOTAL 43
GENERAL IMPRESSIONS (Interview members of demo team)
Responsiveness(subject matter knowledge): Does the
5
scored at the end team really understand what the solution entails?

Experience/Skill Level: Does the team have the

necessary skillset(s), experience and capacity to 5
deliver?
were they the same people
implementing on the
reference sites;Number of
projects involved in

Actual Project Team: Is the team on the Cvs the same

3
as those who will implement?

Refer to the team members

shared in the bid document
SUB-TOTAL 13
 PRODUCT STABILITY

Performance Levels: What is the expected

performance of the system with n number of users?
4
Any performance degradation due to poor
connectivity, surge in users, etc
Judged by the reference
contacts and as they speak

Uptime Percentage: This is probably a verbal/written

guarantee by vendor based on previous 2
This will be based on number (similar)projects
of txns and vols

Load/Capacity: What are the results of load

tests(throughput and latency). How horizontally 5
This will be based on number scalable is the solution?
of txns and vols
SUB-TOTAL 11

TIME-FRAME FOR DEPLOYMENT (This is based on the development/implementati

methodology used by the vendor. e.g Agile development)

Phase 1: How is the project phased? Does phase 1 fit

2
into BRAC's project timelines
Brac's 90days timeline
,presentation is expected

Phase 2: Does phase 2 (if it exists) fit into BRAC's

2
project timelines
Brac's 90days timeline
,presentation is expected

Project Completion: Does the vendor’s plan fit into

2
the overall project plan?
Brac's 90days timeline
,presentation is expected

Training: How will knowledge transfer occur? Will

there be a trainer-of-trainers programme within the 3
Brac's 90days timeline project
,presentation is expected
SUB-TOTAL 9
OTHER CONSIDERATIONS

Hosting (Local/Cloud): Explain the hosting plan for the

solution. Will the application and data be distributed? 5
Preference to have local Data has to be hosted within Uganda (Sovereignty)
hosting

Additional Equipment: Describe the hardware and

equipment required for successful project
4
implementation. e.g servers and POS devices, printers,
etc
Each Vendor is required to
describe reqmts
 Platform Considerations: Operating System and/or
application containers ecosystem requirements. How
3
sustainable and maintainable is the solution in terms
How many pple are required
of TCO and human resource requirements?
to man it

Locked In to Vendor Solution? : Is the vendor the only

3
option for Support and is the technology Open source?
Based on presentation
Support: Explain support structure, SLAs and
3
Based on presentation escalation matrix
SUB-TOTAL 18
SECURITY & BACKUPS

Vendor will have to explain Backup Policies: Proven model and policy
but also present how to (documented and explained)
2
handle

Vendor will have to explain Recovery Procedures:Proven model and policy

but also present how to (documented and explained)
2
handle

Vendor will have to explain Security: Proven model and policy (documented and
but also present how to 2
explained)
handle
SUB-TOTAL 6
TOTAL 100
 Vendor 1 Vendor 2 Vendor 3 Comments

emo team)
 the development/implementation
lopment)

Need for 2 application servers at headoffice in a

clustered,database server different from application
servers for security issues.DR has to have 1 appln
server,DB server .In addition,there is need for a test
server.POS devices shld be smart or use of tabs .How
does one print i.e infrared,wifi,bluetooth and or USB