Business Requirements Document BRD
Business Requirements Document BRD
Business Requirements Document BRD
for
Digital Financial Services Data Reporting and
Analytics Platform
Version 1.0
11 December 2018
Table of Contents
Document Purpose ............................................................................................................................................. 2
Sign-offs .......................................................................................................................................................... 3
Document History .......................................................................................................................................... 3
Introduction........................................................................................................................................................ 4
Bank of Zambia ............................................................................................................................................... 4
UNCDF ............................................................................................................................................................ 4
Mobile Money for the Poor (MM4P) ......................................................................................................... 5
Data Reporting and Analytics Platform .............................................................................................................. 6
1. Business Requirements .......................................................................................................................... 6
I. Existing Process (As-Is) ....................................................................................................................... 7
II. Business Objectives (To-Be) ............................................................................................................... 7
III. Operating Environment .................................................................................................................. 8
2. Solution Requirements ........................................................................................................................... 9
I. System Interface ............................................................................................................................... 10
II. Transition Requirements .................................................................................................................. 11
III. Hosting Requirements .................................................................................................................. 11
3. Functional Requirements ..................................................................................................................... 11
I. Access Controls................................................................................................................................. 11
II. User Groups ...................................................................................................................................... 12
III. Data Collection ............................................................................................................................. 12
IV. Data Analytics ............................................................................................................................... 14
V. Outputs – Reporting & Dashboards ................................................................................................. 14
4. Non-Functional Requirements ............................................................................................................. 15
Annexure .......................................................................................................................................................... 18
I. List of Reporting Institutions ............................................................................................................ 18
II. Financial Inclusion Data Sources ...................................................................................................... 18
III. Reporting Templates .................................................................................................................... 19
IV. Key Critical Data Elements ........................................................................................................... 19
V. Output samples ................................................................................................................................ 20
The information has been captured and written through technical support from UNCDF MM4P and signed-
off by the relevant stakeholders at BoZ, validating the requirements meet their core business needs. This
document does not include technical and functional design specifications for the BoZ platform, nor provide
an analysis of requirements related to systems outside BoZ.
28 February 2018
Manager, Payment Systems
Maria Musombo Katepa
Oversight
28 February 2018
Assistant Director, Payment
Miriam Tembo Kamuhuza
Systems Oversight
28 February 2018
Acting Assistant Director, Business
Chella Kalindo
Solutions, ICT Dept.
The Bank is active in promoting financial inclusion policy and is a leading member of the Alliance for Financial
Inclusion. It is also one of the original 17 regulatory institutions to make specific national commitments to
financial inclusion under the Maya Declaration, during the Global Policy Forum, held in Riviera Maya, Mexico
in 2011. BoZ has deployed various policies to ensure that financial services are able to make in-roads in
remote and rural areas. Still, financial services are concentrated in mostly urban and semi-urban areas, with
capital region of Lusaka having the highest concentration.
Zambia was the earliest adopter of digital financial services (DFS) in Africa in 2002, and the country has made
significant improvements over the years in terms of financial services delivery outlets/channels offered
through both formal and informal financial institutions. Despite that, the level of adults Zambians above 18
years who are excluded from financial services remains significant. Data from the Finscope Zambia survey
conducted in 2015 showed that only 59.3 % of the population are financially included.
The Bank of Zambia realizes the important catalytic role that Digital Financial Services (DFS) can play towards
the increased usage of electronic payment mechanisms by the general public. The Bank of Zambia is
therefore working with government and other private and public stakeholders to increase financial inclusion,
by increasing access to formal financial services. To this effect the Bank has amongst its strategic objective
include plans to increase formal financial inclusion.
A number of initiatives have since been put into motion in order to meet this objective. Among others, these
include;
• Working financial institutions and other interested parties in carrying out sensitization campaigns
that highlight the importance of using formal financial services
• Review of regulatory space in order to promote innovation and increase usage of modern payment
mechanisms and financial services, and provide safety and security amidst innovation in the payment
systems in the country
• Working with the commercial banks, electronic money issuers (e.g. mobile money) and other
financial service providers to implement a National Financial Switch
• Establishment of standards and regulation that facilitate for interoperability of retail and large value
payment streams both domestically and across the border.
To ensure integrity of the Digital Financial Services (DFS) sector and enhancing of financial access and usage,
Bank of Zambia recognizes it is important that data and measurement tools are deployed for aiding effective
supervision and policy making.
UNCDF
UNCDF is the UN’s capital investment agency for the world’s 48 least developed countries (LDCs). With its
capital mandate and instruments, UNCDF offers “last mile” finance models that unlock public and private
resources, especially at the domestic level, to reduce poverty and support local economic development.
This last mile is where available resources for development are scarcest; where market failures are most
pronounced; and where benefits from national growth tend to leave people excluded.
In Zambia, MM4P launched its program in March 2015, funded by both MasterCard Foundation, is aimed at
increasing active usage of DFS from the current 3% to 36% by 2019 amongst the adult population. Using the
MM4P theory of change, the program seeks to work with all DFS providers, the regulators and the
government to achieve this mandate.
Consequently, the ‘Banking Currency and Payment Systems Department’ at BoZ, with support from UNCDF
Zambia, seeks to deploy a Data Reporting and Analytics platform that would automate the reporting
processes and provide analytics useful for policy making.
The present reporting process involves providers manually filling the required regulatory reporting data in a
pre-defined excel spreadsheets and emailing it to the BoZ (Banking Currency and Payment Systems
Department) within the first week of every month. Staff at Payment System then collects more than 50
excel files from 34 reporting institutions to manually aggregate the data from these sheets to prepare
monthly, quarterly and yearly performance reports. The monthly reporting process takes a dedicated
resource nearly a week to complete and an additional week is required when quarter and year-end reports
are prepared.
Reporting Institutions
Data manually
Reports manually
aggregated and
disseminated to
analyzed to prepare
relevant stakeholders
yearly reports
Needless to say, the current process of manually entering, extracting, compiling, aggregating, analysing and
reporting data creates numerous challenges for both; BoZ and reporting institutions.
• Process is laborious and time-consuming, requiring investment of substantial time every month
• Process is prone to human errors and data is not always consistent
• Overly dependent on individuals who are trained to submit, compile and analyse data
• Limitations on kind of data analysis that can be conducted manually to support policy making
• Challenges in timely generation and distribution of reports to stakeholders
• Potential security issues as data is shared through emails over internet
• The platform is envisaged to have an internal utility at BOZ and should also provide an external
interface;
• Capability to run analytics, driven mainly by i) Data collected from BOZ reporting from all forms of
financial institutions providing Digital Financial Services, ii) Data collected from other different
sources around mobile networks, poverty levels, population;
• Platform should provide an interface to the financial and non-financial institutions licensed by BOZ
to submit data-set online related to mandatory reporting and related to financial channel;
• A link needs to be established through the Bank of Zambia website to provide data access and login
access;
• Capability to validate data entries and flag data outliers that might indicate data entry errors;
• Mapping of existing digital financial services infrastructure across Zambia by district and province if
possible.;
• The data set should as far as possible be clustered at the lowest administrative level which is the
lowest structure in administrative hierarchy;
• The tool be set-up as a platform with public interface supported with key control measures to
ensure data confidentiality;
• The tool should be open for future changes and integrations based on need
Where the following sections of the BRD are based on more traditional approach, UNCDF is open to explore
solutions that leverage innovative technologies for regulatory reporting, such as blockchain, provided these
meet requirements set by BoZ and offers additional advantages in term of functionality and costs.
1 Adapted from: Data as a critical factor for central banks, 8th IFC Conference on “Statistical implications of the new financial
landscape”
The Bank will also seek to implement greater integration among its information systems by implementing
an Enterprise Resource Planning (ERP) platform. Some of the benefits of the ERP include reduction in
complexity of the Bank's Information Architecture through the establishment of a single platform for the
Bank's business systems.
Development and implement an ICT governance framework: The Bank has plans to an implement ICT
Governance Framework, based on the new COBIT 5, to manage how ICTs are managed in the organization.
COBIT 5 encompasses all stakeholders within BoZ and calls for the establishment of an ICT Steering
Committee at Board that should make ICT-related decisions, such as which ICT investments to make and
what ICT projects to run.
Currently BoZ’s main computing platforms and operating system environment consist of:
2. Solution Requirements
The envisaged Data Reporting and Analytics platform will be developed under the supervision and
leadership of Bank of Zambia. Data will be stored in-house on Bank of Zambia servers, the platform would
be the CAPEX model in nature with minimal ongoing maintenance and service costs.
The platform will be optimised to collect data from various sources, transforming and cleanse the data into
a standardized format, and warehousing the data for analysis and dissemination to users in various
formats. In the ideal scenario the data warehouse could utilize Online Analytical Processing (OLAP)
methodologies for analytical analysis and allowing users to construct queries ad-hoc, or “on-the-fly”.
The expected architecture of a solution should be sufficient to meet all essential business requirements and
offer a coherent set of functionalities. Furthermore, the platform should allow it incorporate more features
as business needs and technology evolves.
• A Capex model solution that can interface with multiple external platforms and data sources;
2 An enterprise architecture framework (EA framework) defines how to create and use an enterprise architecture. An architecture
framework provides principles and practices for creating and using the architecture description of a system - Wikipedia
I. System Interface
The long-term vision of the platform includes straight-through processing of data from reporting
institutions with minimal intervention to ensure data accuracy, integrity and timeliness. This will require
Online and Offline interface with relevant databases and systems using the following major modes;
Requirement Priority
Offline Batch Mode High
FTP File Placement Medium
Application Programming Interface (API Base Connectivity) Low
Online/ Real Time data update Low
To ensure data can be shared effectively with other systems belonging to the reporting financial institutions
of market data repositories, the platform interface should;
Requirement Priority
Interface with BoZ’s internal systems to share generated outputs seamlessly to other Medium
platforms and applications
Requirement Priority
The hardware architecture should be oriented to be integrated into existing BOZ High
infrastructure and should have ability to seamless integration with future
modules/components/applications
Migrate historical data to the platform to generate comparative analysis and reports Medium
Utilise the NetApp technology data storage available at the BOZ Medium
3. Functional Requirements
BoZ seeks to enhance the efficiency of the data collection and analytics to ensure quality and timeliness of
data. To that end, the key operations and activities the Data Reporting and Analytics platform must be able
to perform functions as summarised in sections below:
I. Access Controls
The platform will provide functionality for managing and restricting system access according to each user
group’s access privileges as authorised by BoZ.
Requirement Priority
Limit access to the platform only to authorised and uniquely identified users by enforce High
authentication that can be based on combination of user/password or user certificate
Manage and monitor privileges of users, allowing them access to features, sensitive data and High
outputs as per their privileges. Platform outputs include reports, data display screens and
GUIs, query results, etc
To accommodate the different user groups, the platform will enforce user hierarchies and access controls
to prevent unauthorised access to sensitive data and features.
Requirement Priority
Enforce authorization mechanism for user privilege and profile management, allowing users High
to only use features and menus for which they have access privileges
Configurable to which roles and tasks need ‘2‐eye’ or ‘4‐eye’ principles (maker-checker) High
Maintain all user permissions and activity in a host of logs (including user and event logs), High
which can be used platform audits, user activity assessment, review permissions, privilege
assignment etc
Requirement Priority
Allow manual input of data, through manual data entry and uploading of predefined data High
reporting forms/templates to populate relevant fields (CSV, excel, etc)
• Provide capability to automatically populate required regulatory data through API Low
integration with external systems and data repositories
• Apply defined business rules to input data, and display pre-defined error messages High
with reason displayed to user why entered/uploaded is rejected or declined by the platform
• Enforce tiered maker/checker processes, where data will be entered (or file High
uploaded) by multiple ‘makers’ and validated by nominated ‘checkers’ in different
departments at the reporting institution. The final data set will be transmitted to BoZ after
the final ‘checker’ (compliance officer) at the reporting institution has validated all of the
reporting data
Key critical data elements to be provided to BoZ by reporting institutions can be found in the embedded
excel file in the annexures. These data elements include quantitative reporting on the following financial
services and parameters:
o Access and Usage of Financial Services Report o Point of Sale (POS) Returns
o Trust Account Balances of Mobile Money o International and Domestic Remittances
Providers Report Report
o Mobile Banking Returns o Incidents/ Frauds Reports
o Agency Banking Returns o Unpaid Cheques Report
o Internet Banking Returns o Unpaid Direct Debit and Credit Clearing
o Automatic Teller Machine (ATM) Returns (DDACC) Report
Business rules
To ensure a harmonized model for input data as well as rules for analysis of collected data, the platform
should operate as per the criteria and conditions defined by BoZ in the form of Business Rules. As reporting
requirements can evolve with new regulatory priorities, the platform should provide the capability to
define and modify business rules through the administrator login.
Requirement Priority
Pre-defined in the platform based on business and accounting logic rules High
Applicable to various features across the platform and different input methods High
Based on expandable and configurable private sets of rules that can be based on;
o Scenario logic validations, Red flags; Medium;
o Mandatory/optional validations; High;
o Alphanumeric value validations; High;
o Specific and threshold value validations; Medium;
o Value range and length validation High
At a minimum, the platform should be able to conduct the below types of analysis:
Ad hoc Queries
The platform will provide additional ad-hoc data access functionality to users so they may run custom
queries, according to their access privileges. Methodologies for inclusion of variables in a custom query
should include;
Requirement Priority
Searching by keywords and filtering different data elements (provider, indicator, location Medium
etc.)
Selecting and linking objects for inclusion in a custom query by ‘drag & drop’ and ‘point and Low
click’
Providing summaries and detailed breaks-up of defined data elements/ parameter through Medium
comprehensive and drill-down capabilities
Support dynamic report reformatting upon regrouping and drill-down to detail records High
Requirement Priority
Provide analytics created by the platform in a variety of report and dashboard formats to
users, according to their needs and user privileges
o Reports, based on collected data and generated analytics, should be produced High;
automatically on periodical basis to provide stakeholders reliable, consistent, timely and
useful information
o Dashboards should be user-friendly, providing stakeholders important data and High
information through graphics that are easy to understand at a glance
Provide an integrated data query facility that supports ad-hoc queries Medium
Use visualizations to represent data, indicators and other matrices, such as Graphs, Charts, High
Heat Maps, Tables, Metric Legends, Scatter Plots
Support graphical output display on screen and previews before printing of hardcopies on High
standard paper sizes
Generate extractable data files in multiple predefined electronic formats like PDF, CSVs, TEXT High
and Excel spreadsheets
Notify stakeholders of an output’s availability through e-mail to multiple pre-identified users Low
or groups
It will be highly preferably if the platform supports a report designer tool feature that allows High
designing of reports and dashboards to suit specific stakeholder requirements
Basic report categories and access are summarised in the table below:
Requirement Priority
Send notifications to designated persons at each stakeholder by email when a report is Low
available
Send reminders when data or actions are due Low
Display an appropriate error message if entered data violates the business rules Low
Prompt reporting institution to enter comments when entered data raises a flag (for outliers) Low
Send error message to the reporting institution if uploaded data is rejected by BoZ Low
Send notification of acceptance, and PDF copy of data entered via email, once submitted data Low
has been accepted by BoZ;
4. Non-Functional Requirements
BOZ warrants that the platform be designed and implemented to a high standard of security and reliability,
with the objective of maintaining the integrity, availability and confidentiality of data. Furthermore, the
a) User interface
Accessible through web-browsers, the user interface should be windows-compatible and provide access to
all platform features and modules. The design should have a high level of usability with a common “look
and feel” achieved through consistent Graphical User Interfaces (GUI) for all internal and external users.
Interface consistency includes the use of common command entry syntax, dialog window styles, data entry
structures, and information presentation.
• Provide secure access to sensitive data and different platform features related to the user, including
user management, entering & uploading data, review & approve data, accessing outputs and
downloading & printing these outputs
• Incorporate common Graphical User Interface characteristics to make it easy-to-use and accessible to
users with varying levels of technical knowledge of systems. These could include;
o Mouse activated icons, Buttons, Scroll bars;
o Drop-down lists, Check boxes, Text boxes;
o Menu bars, Resizable windows;
o o Cut, copy, and paste functions
• Incorporate data entry features designed to reduce the amount of direct keying required to enter data.
These could include;
o Copy/paste, drop-down lists, and tab function
o Use of default values, look-up tables
o Automatic data recall where applicable
• Provide the ability to preview reports, analytics and query result before printing
i. Platform will be organized in several independent modules that can be enabled/disabled according
to BOZ’s needs;
ii. Each module can be upgraded independently to extend the platform’s functionality
iii. Each module should provide possibility to be tested/troubleshot individually;
c) Security
The developed cloud-based solution needs to ensure adequate security and maintain strict confidentiality
of all information provided by stakeholders.
To ensure integrity of the platform, all its components should have all required security certifications and
conform to all industry security standards. All sensitive information such as user/passwords in the database
should be stored securely, in encrypted form. Furthermore, the platform should provide full audit trails for
all activities within the system, including system accesses and activities.
e) Availability
At the minimum, the platform has to be available to users with official working hours in Zambia.
f) Concurrency Requirements
The platform should be able to handle at least 60 users concurrently.
g) Response/ Performance
In terms of throughput capacity and response times, the platform should make due allowance for peaks in
usage and general growth.
In the ideal scenario, the platform should be capable of creating required reports within 10 seconds and
allow replacing the back-end queries to be able to override slow performing queries with optimized
queries.
h) Reliability
The platform should provide high reliability and ensure flawless switching of all functionalities to the
Disaster Recovery (DR) site to avoid catastrophic loss of critical information. The switching to DR site should
be automatic without loss of data or service to users
i) Redundancy
The platform should be designed with high redundancy level to ensure no or little impact by failure of one
or more components. All cloud-based components proposed for the platform should be systematically
duplicated to ensure that no single point of failure exists
16 Stanbic Banks 19
17 Standard Chartered Non-Banks 3
18 United Bank of Africa Zambia DFS Providers 5
19 ZANACO Total 27
Financial
Capability Demand Individual 2016 TBD Financial capability World Bank
Survey
Enterprise
Demand Firm 2013 Periodic Access to finance World Bank
Surveys
Informal Sector
Demand Household 2013 Bienniel* Production, employment CSO
Survey
Crop
Forecasting Agricultural production
Demand 2015 Annual* Agricultural production, inputs CSO
/ Post- Harvest unit
Surveys
Reporting
Driver Financial Inclusion Indicator Source Disaggregation
Frequency
% adults financially included (formal & informal) FinScope Trienniel By district
% women financially included (formal & informal) FinScope Trienniel By district
Products
% youth financially included (formal & informal) FinScope Trienniel By district
% rural financially included (formal & informal) FinScope Trienniel By district
Financial Access Index By type of access point
BoZ Biannual
(components listed in 2A-2C) (branch, agent, ATM)
% of total population living in districts with at least one By type of access point
BoZ Biannual
access point (branch, agent, ATM)
FinScope / By gender, age, income,
Products % adults with a store-of-value transaction account Trienniel
Findex rural, district
FinScope / By gender, age, income,
Products % adults using an electronic payment instrument Trienniel
Findex rural, district
Products Cashless retail transactions per capita BoZ Quarterly By type of instrument
FinScope / By gender, age, income,
Products % of adults saving at a regulated financial institution Trienniel
Findex rural, district
FinScope / By gender, age, income,
Products % of adults saving with informal saving groups Trienniel
Findex rural, district
Capability
% of adults with at least one non-mandatory insurance By gender, age, income,
Products Survey Trienniel
product rural, district
2016
By gender, age, income,
Products % of adults with at least one pension product FinScope Trienniel
rural, district
By gender, age, income,
Products % of adults using an investment product FinScope Trienniel
rural, district