You are on page 1of 190

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

Contents
Technical Requirements .......................................................................................................................4
A. Background......................................................................................................................................4
1.0

Glossary of Terms and Acronyms.......................................................................................4

2.0

The Purchaser .......................................................................................................................6

3.0

Suppliers Mandatory Criteria............................................................................................7

4.0

Business Objectives of the Purchaser .................................................................................8

5.0

Bid Evaluation and Scoring System..................................................................................12

6.0

Proposed Payment Schedule..............................................................................................12

B. Application Development Requirements.....................................................................................14


C. Functional and Business requirements ........................................................................................21
Phase 1 Functionality .....................................................................................................................21

Comprehensive Reporting ........................................................................................................................... 21


Access to Key Documents ............................................................................................................................ 25
Withdrawal Application for Disbursements ................................................................................................ 26
Manage Banking information ..................................................................................................................... 33
Link to No objection System ........................................................................................................................ 34

Phase 1.5 Functionality ..................................................................................................................35

Add French and Spanish Support in the Portal ............................................................................................ 35

Phase 2 Functionality .....................................................................................................................35

Submission of Documents by Borrowers and WorkFlow ............................................................................. 35


Link to Project Results and Impact Management System ........................................................................... 36
Integration of Withdrawal Application System with AWPB, Bid documents, Procurement plan etc .......... 36
Confirmation of Disbursement Conditions .................................................................................................. 38
Access to Reference documents from B/R (financial statements, implementation agreements, subsidiary
loan agreements, signatories)..................................................................................................................... 39
Reallocation of categories, special account changes, submission of recovery schedule............................. 39
Withdrawal Application Enhancements, Reporting .................................................................................... 42

D. Strategic Alignment with IFAD IT Directions ...........................................................................44


E. Service Specifications .....................................................................................................................45
F. Title, Copyright and Use Rights....................................................................................................55
G. Suppliers Experience Requirements and Client References....................................................55
H. Hardware and Software requirements .......................................................................................56
I. Implementation Schedule ..............................................................................................................60
J. Required Format for Suppliers Response and Checklist...........................................................64
Annex 1-Site Table..............................................................................................................................72
Annex 2- Holidays and Other Non-Working Days: .........................................................................74
Annex 3 - Volume - Estimates of number of users...........................................................................75
Annex 4 - Volumes Size of Documents Uploaded into IFAD Borrower Portal ..........................78
Appendix 1 Submission of WA (detail description) ......................................................................80
1.1. e-Submission of withdrawal applications detailed requirements.....................................81
1.2. Background...........................................................................................................................81
1.3. Features ................................................................................................................................81

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

1.4. WA submission options ........................................................................................................81


1.4.1.
1.4.2.

Options.......................................................................................................................................... 81
Current forms ................................................................................................................................ 81

1.5.1.
1.5.2.
1.5.3.
1.5.4.

Header search function .............................................................................................................. 82


Advances for start-up costs........................................................................................................... 86
Withdrawal application form (Form 100) ..................................................................................... 86
Specific information to be requested depending upon type of disbursement request: ................ 90

1.5. Input screen for external user (B/R) for online approval .....................................................82

1.6.
1.7.
1.8.
1.9.
1.10.
1.11.
1.12.
1.13.

Input screen for FA where paper WA submitted .................................................................92


Input screen for FA for projects where Cooperating Institution is used ..............................92
System validations of withdrawal application request ........................................................92
Cancellation or modification of a WA...................................................................................94
Communication of issues to IFAD.........................................................................................94
Creation of Notification form for approval...........................................................................95
List of notifications for review ..............................................................................................98
Workflow for approval of request........................................................................................98

1.13.1.
1.13.2.

Approval of request online ....................................................................................................... 98


Approval of paper forms .......................................................................................................... 99

1.15.1.
1.15.2.

Form: ........................................................................................................................................ 99
Warning messages................................................................................................................. 100

1.14. Submission to IFAD in an internal review system ................................................................99


1.15. IFAD users to be able to view and review information submitted in a user-friendly manner
..............................................................................................................................................99
1.16.
1.17.
1.18.
1.19.

Routing to CPM for review and/or approval ......................................................................105


Risk-based disbursement methodology to be applied to routing of request: ...................106
Straight-through processing ...............................................................................................107
Comparison of information with standing data and routing of requests for review based
upon decision trees inherent within the system................................................................107
1.20. Amendment of WA by B/R .................................................................................................109
1.21. Second Validation ...............................................................................................................109
1.22. Approval stage ....................................................................................................................109
1.23. Creation of record in Records Management System .........................................................109
1.24. Interface into Flexcube .......................................................................................................110
1.25. Integration with Flexcube...................................................................................................110
1.26. Communication of payment to B/R....................................................................................110
1.27. Reporting ............................................................................................................................111
1.28. Forms (Phase 2) ..................................................................................................................111
1.29. Overview (Phase 2).............................................................................................................111
1.30. Input Screens (Phase 2) ......................................................................................................111
1.31. Special cases (Phase 2) .......................................................................................................112
Attachment 1 Standing data......................................................................................................114
Attachment 2 status of withdrawal application........................................................................117
Attachment 3 - Mapping of information on WA to information in FX.........................................118
Attachment 4 Mapping of product codes, description and categories in FX ............................119
Attachment 5 Withdrawal Application forms: 100, Summary of Expenditure, 101, 102, 104 and
105 ......................................................................................................................................120
Appendix 2 - Submission of Banking Instructions - (detail description) .....................................132
1.

Process .............................................................................................................................................. 133

Appendix 3 Submission of AWPB - (detail description).............................................................136


Appendix 4 Confirmation of disbursement conditions - (detail description) ...........................139

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

Appendix 5 Reallocation of Category - (detail description) .......................................................142


1.
2.

Background....................................................................................................................................... 143
Functionality for portal ..................................................................................................................... 143

Appendix 6 Increase/Decrease in Special Account Allocation - (detail description) ...............146


1.
2.

Background....................................................................................................................................... 147
Functionality for portal ..................................................................................................................... 147

Appendix 7 Contract Monitoring - (detail description)..............................................................149


1.
2.

Background....................................................................................................................................... 149
Functionality for portal ..................................................................................................................... 149

Appendix 8 Submission of Recovery Schedule - (detail description) ........................................152


1.
2.

Background....................................................................................................................................... 152
Functionality ..................................................................................................................................... 152

Appendix 9 Reporting Requirements............................................................................................155


1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.

Background....................................................................................................................................... 155
General Requirements ...................................................................................................................... 155
Overview of pages in portal and links ............................................................................................... 156
My portfolio ...................................................................................................................................... 158
Project at a glance ............................................................................................................................ 165
Financing overview ........................................................................................................................... 166
Disbursements .................................................................................................................................. 169
Debit Advice ...................................................................................................................................... 171
Designated Account or Advance Account ......................................................................................... 171
Total IFAD disbursements to borrower or recipient......................................................................... 174
Financing Status .............................................................................................................................. 175
Individual Loan Status...................................................................................................................... 178
Generation of Billing Statement ...................................................................................................... 180
Instalment Schedule ........................................................................................................................ 180

Appendix 10 Site Structure ............................................................................................................182


Graphical representation .......................................................................................................................... 182

Appendix 11 Reference Documents..............................................................................................184


Financial Reference Documents ................................................................................................................ 185
Operational Reference Documents ........................................................................................................... 186
Documents from the B/R........................................................................................................................... 186

Appendix 12 Roles..........................................................................................................................187

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

Technical Requirements
A. Background
1.0

Glossary of Terms and Acronyms

2FA
Two-factor authentication
AA
Authorised Allocation
API
Application Programming Interface
AWPB
Annual Work Plan and Budget
BI
Oracle Business Intelligence
BPM
Business Process Management
B/R
Borrower or Recipient
Borrower Portal Refers to the Borrower/Recipient Portal
Checker
The role in FX which approves a transaction
CFS
Controllers and Financial Services Division
CGIAR
Consultative Group for International Agricultural Research
CPM
Country Programme Manager
DC
IFAD Data Center
DRC
Disaster Recovery Center
EJB
Enterprise Java Beans
EUR
Euro
DSBL
Disbursable
DW
Datawarehouse
EC
European Commission
EOD
End of Day closure process in FX
FA
Finance Assistant
FMA
Financial Management Application (currently under development)
FO
Finance Officer
FX
Flexcube the system used for recording withdrawals from loans and grants.
GARTS/ARTS Grant Audit Report Tracking System / Audit Report Tracking System
GRIPS
Grant and Investment Projects System
GTC
General Terms and Conditions for the Procurement of Services
GUI
Graphical User Interface
HIPC
Heavily Indebted Poor Countries
ICOs
IFAD Country Offices
IFAD
International Fund for Agricultural Development
ICT
Information and Communications Technology Division
Maker
The role in FX which initiates a transaction
NCSC
National Computer Security Center
NGO
Non-Governmental Organization
OFID
OPEC Fund for International Development
OPEC
Organization of Petroleum Exporting Countries
PDF
Portable Document Format

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

PID
PLF
PMD
PMU
Portal
Purchaser
PS
RBD
RFD
RFP
RMS
RIMS
SDR
SOA
SOAP
SOE
Supplier
USD
VAMI
WA
WATS

Project Initiation Document


Project Life File
Programme Management Department
Project Management Unit
Refers to the Borrower/Recipient Portal
IFAD
Peoplesoft
Risk Based Disbursements
Request for Disbursement
Request for Proposal
Records Management System
Results and Impact Management System
Special Drawing Rights
Service Oriented Architecture
Simple Object Access Protocol
Statement of Expenditure
The contractor who is awarded the contract as an outcome of this RFP Lot 1.
United States Dollars
Value-dated Amendment Initiation
Withdrawal Application
Withdrawal Application Tracking System

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

2.0

The Purchaser

About IFAD
The International Fund for Agricultural Development (IFAD) is a specialized agency of the
United Nations with its Headquarters in Rome, Via Paolo di Dono 44, 00142 Rome, Italy.
IFAD was established as an international financial institution in 1977 to finance agricultural
development projects primarily for food production in the developing countries. IFAD's mission
is to enable poor rural people to overcome poverty and is dedicated to eradicating rural
poverty in developing countries. Working with rural poor people, governments, donors, nongovernmental organizations and many other partners, IFAD focuses on country-specific
solutions, which can involve increasing rural poor peoples' access to financial services,
markets, technology, land and other natural resources. It is a not-for-profit institution which
relies on funding from its Member States.
More detailed information regarding IFAD is available in the Organizations website
(http://www.ifad.org). In particular, the latest IFAD Annual Report and The Agreement
Establishing IFAD can be downloaded from the website.
In order to fully understand the business requirements for this Borrower/Recipient (B/R) Portal
project it is important to be familiar with the terminology used within this document. The
attached link provides information in an eLearning platform on Financial Management of
projects. Key stages within the project as well as the overview of certain procedures are
provided. http://www.ifad.org/elearning_cfs/index.html
Objectives of this RFP
The purpose of this RFP Lot 1 is to engage a software development supplier for the
implementation of a secure, single-window IFAD Borrower/Recipient Portal for providing
access to B/R specific information and transacting business with IFAD that will integrate with
several underlying IFAD systems. The RFP seeks a software supplier that has the capacity and
knowledge to conduct requirements analysis, detailed design, development, testing, and
training of IFAD staff, deployment and support for the IFAD Borrower/Recipient Portal System.
(Note that this RFP has four lots: Lot 1 The Borrower/Recipient Portal; Lot 2 Two Factor
Authentication; Lot 3 End User Helpdesk; Lot 4 Rollout Support.)
IFAD now invites sealed bids from eligible Suppliers for the Lot 1 project for:
Supply, Implementation, Rollout and Support of the IFAD Borrower/Recipient Portal system.
The project includes:
1.

Supply of integrated application software to cover the required business


functionality of the IFAD Borrower/Recipient Portal system and its components;

2.

Bidder proposal on suitable technology choice for the IFAD Borrower/Recipient


Portal platform either IBM Websphere or Oracle Webcenter and related
components.

3.

Sizing, licensing, supply and installation of the required processing capacity


(hardware), system software, middleware, backup and associated system
management tools at the IFAD Data Center and Disaster Recovery sites;

4.

Confirmation of business and technical requirements as specified in this bid


document;

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

5.

Detail design, development, integration, testing, and implementation of the


required application software and integration linkages; the Portal software
functionality is to be delivered in three phases (Phase 1, Phase 1.5, and Phase 2) as
detailed in this document;

6.

Integration of the application software with the identity/access management


solution identified as part of Lot 1;

7.

Integration of the application software with the two factor authentication solution in
Lot 2;

8.

Integration with other internal IFAD systems as specified. IFAD will build and expose
the web services for the IFAD systems to integrate with the new application
software, the supplier shall use the web services provided to integrate the solution
with the IFAD systems;

9.

Development of training materials for the different roles in the Borrower Portal;
conduct training for internal IFAD staff; provision of system and technical
documentation to IFAD as part of knowledge transfer plan;

10.

Support of the application systems and related IT infrastructure for a period of at


least two (2) years after go live, with possible extensions of support for another two
(2) years;

11.

Implementing Spanish and French as additional languages in the Portal in Phase 1.5
of the project, after the go live of Phase 1. The Supplier shall provide the costing for
adding Spanish and French as languages to the Portal as a separate line item in the
cost table. In addition, the Supplier shall provide the cost of adding Arabic to the
Portal after Phase 2 go live.

No Commitment
This RFP does not commit IFAD to award a contract or to pay any costs incurred in the
preparations or submission of proposals, or costs incurred in making necessary studies for
the preparation thereof or to procure or contract for services or supplies. IFAD reserves the
right to award only a portion of the requirements and to award separate or multiple
contracts for the elements covered by this RFP in any combination it may deem appropriate.
3.0

Suppliers Mandatory Criteria


Suppliers Financial Capability
The Supplier shall furnish documentary evidence that it meets the following financial
requirement(s): average Annual Turnover within the last three (3) years of not less than fifty
(50) million USD or equivalent; and access to liquidity (financial resources such as bank
assets and lines of credit, etc.) of at least two (2) million USD or equivalent.
Suppliers Experience and Technical Capacity
During the past five (5) Years, the Supplier must have successfully completed the full project
cycle for at least two (2) successful contracts worth over one (1) million USD or equivalent
each involving the supply, implementation and support of a large-scale custom developed,
secure, web-based transaction processing and reporting application that supports over 3000
users across the internet and intranet;

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

Minimum required experience of project manager


1.

The Supplier's Project Manager must have a minimum of ten (10) years experience in a
project manager role with at least two (2) successfully completed projects of similar size
and technology as project manager,
and

2.

At least five (5) years of industry experience in a web application


development/development team leadership capacity.

Joint Venture
In the case of a Joint Venture, the partner responsible for application software development
must be designated the lead partner and the financial figures for all joint venture partners
shall be added together to determine the Suppliers compliance with the minimum
qualification criteria for financial and technical capability. For a Joint Venture to qualify, the
lead partner must meet at least 50 percent of the financial capability (turnover and
liquidity).
Regarding experience and technical capability, each Joint Venture member must by itself
have completed at least two (2) successful contracts involving exercise of the skills for which
it has been included in the Joint Venture, preferably concerning the supply, implementation
and support of a large-scale web application of similar functional/technical characteristics
and of a comparable scale. The lead partner must demonstrate at least one (1) successful
experience with a large scale web application deployment.
Failure to comply with these requirements shall result in the rejection of the Joint Ventures
bid. Subcontractors experience and resources shall not be taken into consideration.
4.0

Business Objectives of the Purchaser


General
The IFAD Borrrower/Recipient Portal concerns the development of a secure partner website
for IFADs stakeholders. The website is intended to be the tool used by stakeholders
(partners) to obtain information from IFAD and to be able to initiate financial transactions
including the uploading of documents.
The partners of IFAD who will use the Portal comprise the countries to which IFAD provides
financing, be it through loans or grants as well as non-country recipients (NGOs) of grants.
The financing is provided in order to implement projects with the objective of improving the
lives of rural people. The implementation of projects is generally undertaken by a
government- appointed Project Management Unit or by an Implementing partner (often
where specialist knowledge is required). There are currently approximately 250 active
projects in over 100 countries which are financed by loans or grants to country recipients as
well as some 420 projects to almost 200 grant recipients financed by non-country grants.
There are also approximately 800-850 loans which are being repaid (be it interest, service
charge and/or principal). The average value of an investment project is USD 33 million for an
average period of 7 years, whereas the average value of a non-country grant is USD 1 million
for an average period of 2 years. Furthermore IFAD provides supervision support to projects
which are not financed by IFAD (e.g OFID financed) and receives supervision support from
other organizations (Cooperating Institution) for a limited number of projects.
It is planned that the Portal will be available through the internet to all country borrowers
and recipients as well as the principal recipients of non-country grants.
The partners who are expected to use the site fall broadly into two categories:

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

Those concerned with the implementation of projects (project management unit,


implementing partners, Ministry of Agriculture, Ministry of International
Cooperation, Cooperating Institutions etc.) and

Those concerned with the management of the borrowing (e.g. Ministry of Finance)

Over time it is expected that the number of users of the Portal will be in the region of 4,000.
IFAD currently uses Oracle Flexcube for the recording of financial transactions related to
loans and grants. This is interfaced directly to Peoplesoft for the accounting of the
transactions and the recording of cash management transactions. In addition, reporting is
provided through ad-hoc reports designed in Oracle Business Intelligence.
The Borrower/Recipient Portal will provide a suitable platform that can be integrated with
Flexcube through a web-based front end to facilitate B/R self-service and submission of
requests.
Furthermore, given that the Portal will be used by Borrowers and Recipients to request draw
downs on loans and grants (i.e. request payments) it is critical that the Portal is established
on a secure platform with access security arrangements that will be fully tested and
approved by the IFAD technical team.
The Portal is expected to deliver functionality to route requests for review and approval to
appropriate roles both external and internal to IFAD, also based upon information held in
other systems internal to IFAD. Any routing of requests will need to be completely
configurable in order to ensure that the system is sufficiently flexible to allow for the
development of IFAD processes. Currently IFAD uses an in-house developed system for the
routing of withdrawal applications (Withdrawal Application Tracking System WATS) and it
is expected that this will be replaced by the functionality in the Portal.
The Portal will be accessed by users in a large number of countries with varying levels of
connectivity and bandwidth even within a country. Hence it is important that any
functionality available to external users be light on bandwidth and does not require the user
to stay on line for extended periods of time.

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

10

Access to the system


Access to the Portal will be from computer based browsers initially. The Portal shall be browser
agnostic, and support at least Chrome, Firefox and Microsoft IE. The portal architecture and design
should accommodate a responsive design with regard to access from tablets and smart phones. The
access from mobile devices will be limited to approval functions and to viewing reporting. There will
be no requirement to upload information from mobile devices. Access from tablets and smart
phones is not in scope for this contract. However, it should be taken into consideration in the
Supplier's proposal.
Users
The Portal will be accessed by two distinct sets of users: 1. IFAD users; 2. External parties. The
external parties include:
-

Borrowers or Recipients (Ministry, Permanent Representative to IFAD)


Implementer (Project Management Unit, Implementing Agency)
OFID
Cooperating Institution
Grant Recipient (Finance department)

Roles
The Portal will require the creation of the following user roles:

Viewer-B/R:
Author

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

11

Authorizer:
Validator:
Uploader:
Reviewer IFAD:
Approver:
Viewer IFAD.
Access Administrator Borrower/Recipient:
Administrator IFAD

Additional roles may be added as required.


The access of Borrower/Recipient for viewing and for the submission of requests will be limited to those
countries or projects which they are authorised to access. For example, the staff at the project level will
only have access to the information on a project (and probably not the debt-servicing area), while at the
Ministry level the user will have access to all the projects for a country and the debt-servicing area.
There will be no restriction on access to data for IFAD roles, however the routing of requests and
notifications will depend on staff assignments by country and other parameters.
IFAD IT Infrastructure
All hardware and software for the Borrower/Recipient Portal will be hosted at the IFAD Data Centers
(DC) based in Rome, Italy and Geneva, Switzerland (UNICC premises). IFAD will designate later the
secondary data center (in Europe) to be used for business continuity and disaster recovery purposes
by the supplier.
Supported hardware and software at the IFAD Data Center (DC) are:
1. Software
Virtualization Infrastructure
VmWare Enterprise 5.5 or greater
2. OS
Oracle Linux 6.6 or greater
OpenSuse 13.1
Suse Linux Enterprise Server 12 or greater
Windows Server 2008R2 or greater
3. DB
Oracle 11R2 or greater
4. Hardware
HP Chassis, blades and servers
Cisco switches and routers
Connectivity for corporate applications between Geneva and Rome are through Cisco ASA routers,
with an average latency of 18ms.

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

5.0

12

Bid Evaluation and Scoring System

a) Evaluation of bid responses will be undertaken in accordance with the evaluation criteria sheet.
b) Application Design and Development Requirements will be evaluated based on i)
comprehensiveness of response ii) demonstration of technical depth iii) simplicity of design iv)
leveraging out of the box functionality of underlying tool components v) configurability of
systems vi) maintainability of applications.
c) Functional and Business Requirements for Phase 1, Phase 1.5 and Phase 2 will be evaluated
based on i) comprehensiveness of the solution ii) understanding of business functionality iii)
elegance of proposed solution iv) integration approach.
d) Strategic Alignment with IFAD IT Directions will be evaluated on the degree of alignment with
IFAD IT Directions and market positioning including i) Enable IFAD to build future proofed,
secure, expandable large-scale web-based applications with a high degree of usability or userexperience ii) Allow for future application delivery through mobile channels iii) Enable shift to
Cloud Computing iv) Enable Social networking for IFAD staff and external actors (Borrowers,
International Financial Institutions, experts) v) Enable seamless integration without complexity.
e) Supplier Services will be evaluated based on the quality of the team and the approach and
methodology proposed for the project and on-going support.
f) Supplier Experience and Client References will be evaluated based on the relevance of the
experience, and the comparability of the client systems to IFAD's Borrower/Recipient Portal
requirements.
g) Hardware and Software bids will be evaluated based on alignment with existing IFAD
infrastructure and market positioning.

6.0

Proposed Payment Schedule

The Purchaser shall pay the Contract Price to the Supplier in the manner specified below. Except as
otherwise noted, all payments shall be made for the portion of the Contract Price corresponding to
the goods or services actually Delivered, Installed, or Operationally Accepted, per the Contract
Implementation Schedule, at unit prices and in the currencies specified in the Price Schedules of the
Contract Agreement. Payments will be made after Purchaser's approval of the goods or services
delivered and as per GTC Clause 7.
(a)

Advance Payment

A maximum of ten percent (10%) of the Contract Price for Phase 1 and Hardware, exclusive of all
Recurrent Costs, shall be paid at inception of project against Suppliers Bank Guarantee. The Supplier
shall provide a Bank Guarantee equal in amount and currency to the advance payment, and valid
until the Borrower Portal System is Operationally Accepted (see GTC clause 17 for Bank Guarantee
requirements).
(b)

Progress Payments

Payments for the remaining Contract Price, exclusive of all Recurrent Costs, will be paid against
achievement of project milestones as follows:
(i) Hardware
1. Physical delivery of hardware onsite at IFAD Data Center: 50%

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

13

2. Installation and acceptance of all system environments (development, test, production,


training/support)
: 20%
3. Completion of Go live Phase 1: 20%

(ii) Phase 1 - Software and services:


1. Acceptance of software requirements specifications Phase 1: 30%
2. Completion of user acceptance testing Phase 1: 30%
3. Completion of Go Live - Phase 1: 20%
4. Operational Acceptance Phase 1: 10%

(iii) Phase 1.5 Software and services for adding French and Spanish to the Portal:
1. Operational Acceptance Phase 1.5: 100%

(iv) Phase 2 - Software and services:


1. Advance Payment for Phase 2: 10%
2. Acceptance of software requirements specifications Phase 2: 30%
3. Completion of user acceptance testing Phase 2: 30%
4. Completion of Go Live Phase 2:

20%

5. Operational Acceptance Phase 2: 10%

(d) Recurring Costs


One hundred percent (100%) of the price of the services actually delivered will be paid after
Purchasers approval of the services delivered.
The implementation of Phase 1, Phase 1.5 and Phase 2 is to be confirmed by the Purchaser.
Project Kickoff
The project kickoff is expected to take place within four (4) weeks after the contract is signed or as
agreed upon between the Supplier and Purchaser at contract signing time.

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

14

B. Application Development Requirements


The Supplier will be required to design and implement the new IFAD Borrower/Recipient Portal. The
technology platform consists of the following components:

Application Integration platform: Application Integration platform provides software for SOA
environments that enables dynamic, interconnected business processes, and delivers
effective application infrastructures for all business situations. Integration software platform
should include the entire middleware infrastructure, including servers, services, and tools,
needed to create, deploy, run, and monitor round-the-clock, enterprise-wide web
applications and cross-platform, cross-product solutions.
Business process management is all about collaborating between business and IT to build
better processes to increase business agility and improve customer satisfaction. These BPM
tools should enable IFAD to optimize business performance by documenting, deploying and
continuously improving end-to-end business processes.
Identity and Access Manager.
Relational Database: Oracle RDBMS is the IFAD standard.
Reporting and Analytics: A flexible reporting tool that enables easy to use report generator
with drill-down capability and
Security integration with an industry standard Two Factor Authentication (2-FA) solution
able to be leveraged and integrated with other corporate platforms.

IFAD has narrowed down the technology choices for Lot 1 to the following two leading industry
vendor product lines:
1. IBM WebSphere
2. Oracle WebCenter
Supplier should ensure that their proposed solution and technology choices cover the full range of
software components required to build and support the IFAD Borrower/Recipient portal including
application servers, web servers, business process management, identity and access management,
information security and integration with IFADs existing IT infrastructure.
Note that the Purchaser reserves the right to award only a portion of the requirements and to award
separate or multiple contracts for the elements covered by this RFP in any combination it may deem
appropriate.
Application Design Requirements
1-ADR

General Application Design Requirements

1-ADR-01

IFAD requires a web-based custom solution that will meet its business
needs and be built on the proposed IFAD technology platform. All
modules should be fully and seamlessly integrated with one-time data
entry. The Borrower/Recipient Portal should have a high level of
usability with a common look and feel achieved through an intuitive
graphical user interface (GUI).
The Portal shall be browser agnostic, and support at least Chrome,
Firefox and Microsoft IE. The portal architecture and design should

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

accommodate a responsive design with regard to access from tablets


and smart phones. (Though access from tablets and smart phones are
not part of the Lot 1 contract, this aspect should be considered in
design.)
1-ADR-02

The Portal must be fully integrated with IFAD internal systems including
Flexcube, PeopleSoft, Sharepoint, DataWarehouse and other systems
listed under integration requirements.

1-ADR-03

The Portal must provide General flexibility, through configurable


parameters, support automated workflow and provide systematic
controls based on IFAD processes, rules and thresholds. The system
should be configurable and allow authorized personnel to change the
business process flow through the setting of parameters in process
control tables.
System management functions must be fully integrated. For example,
setting any parameter that may be applicable to all system components
must be set only once. All system information moving between
components must be transparent to system operations.

1-ADR-04

Multi-Language: The Portal must provide flexibility for Multi-language


support for IFAD official languages (English, French, Spanish and Arabic.
Only English will be supported in Phase 1 of the project.
After Phase 1 go live, IFAD is considering adding support for Spanish
and French to the Portal. The Supplier should estimate the cost of
supporting Spanish and French, in addition to English, after Phase 1 go
live. Language support applies to labels and other presentation
elements, help, FAQs and such in the Portal, error/warning messages,
and supplier provided documentation available to Portal end-users. The
Supplier is responsible for translation to Spanish and French. Data in
the system will be shown as is, i.e. if textual data in backend systems is
in English, it will be shown as English in the Portal.
Adding French and Spanish support to the Portal is referred to as Phase
1.5 in this document.
Adding Arabic support to the Portal after Phase 2 is also a
consideration. The design of the Portal should take right to left
languages (e.g. Arabic) into consideration.

1-ADR-05

IFAD Borrower/Recipient Portal Upgrade and Patches: The system


must provide for managing upgrades and system patching for all
components as recommended by the manufacturer.

1-ADR-06

End User Help Functionality: The Portal shall provide End-user help
functionality including online context sensitive help, documentation of
functionality,and extended help for error/warning messages for all user
and operator functions. The Supplier is responsible for creating the help
materials, in consultation with Purchaser's subject matter experts.
The Portal shall provide the ability to publish help information (FAQs,
definitions, ) that are easily accessible from the Portal by users, with
authorized IFAD staff being able to update/publish help information
directly to the Portal.

15

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

On each page there shall be links to Help information, Glossary of terms


, How to contact IFAD, Policy documents, and Frequently Asked
Questions (FAQs).
The user must be able to submit a request for help to the Portal enduser helpdesk. The Portal shall provide a form for the user to submit
the help request.
1-ADR-07

WorkFlow & Messaging: The Portal shall provide workflow and alerts to
users who need to take action within the system. The Portal shall
provide for managing workflow processes including escalation and
exception alerts.

1-ADR-08

Document Management: The Portal shall provide the ability to access


and display from, and upload documents to, the IFAD document
management repositories based on Microsoft SharePoint technology.

1-ADR-09

Internet Access: The Portal shall provide secure internet access


capability to users.
The platform shall be stable and not be subject to interruptions or
unplanned downtime.

1-ADR-10

Security: The Portal solution shall meet C2 information security


classification of the US National Computer Security Center (NCSC). The
system shall support encryption of data in transit.
The system must integrate with an industry standard 2-FA solution.

1-ADR-11

Interoperability, System Interfaces & Exchange of Data


IFAD requires controlled exchange of data with internal systems
including Flexcube, PeopleSoft, Sharepoint, DataWarehouse and other
IFAD systems.
Transactions and files must not be duplicated and the system must
ensure that they are not left undelivered.
Interoperability: The Portal solution shall be designed for
interoperability using industry standard protocols. The System shall
adhere to a Service Oriented Architecture (SOA) and support exchange
of data through multiple protocols including Web Services and
Application Programming Interface (API).
The system must comply with industry standard conventions and
interfaces which allow the system to be interfaced easily with other
systems, and/or expanded by either functional module or capacity.

1-ADR-12

Access Control
a. The Portal solution shall require a logon with a valid user ID and
Password and it must integrate with the 2-Factor authentication
solution in Lot 2. The system must be able to support a single
signon experience for internal IFAD users by integrating with
Microsoft AD.
b. The system shall provide users a self-service facility to reset
passwords, while adhering to best practice security principles.
c. The system shall enforce sound password management that

16

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

includes: enforcing the use of strong passwords; forced expiry of


passwords at parameter-defined intervals; disablement of accounts
after a parameter-defined number of unsuccessful log-in attempts;
and not permitting the re-use of a parameter-defined number of
previously used passwords.
d. Users shall not be able to see menu options for those functions
they are not authorized to use.
e. Application workstations shall be logged off automatically if idle for
more than a specified but variable period, to prevent access by
unauthorized third parties if left unattended.
f.

The system shall provide full audit trails for all activities within the
system, including system accesses and messages sent and received
and reports.

g. The system shall provide consistent and regular reporting for


financial processing, security logs, batch and file numbers
processed etc. which can be reported to prove system integrity and
complete system-wide reconciliation.
h. The system shall have the ability to track and disallow the
assignment of incompatible roles.
i.

The system shall provide for the management of all Portal users
(both internal to IFAD and external) and their access privileges and
alerts such as:

j.

1-ADR-13

Invalid access attempts at workstations;


The number, frequency and source of invalid transactions and
files;
Any unusual behavior patterns by an authorized user, indicating
increased risk and/or attempted fraud.

The system shall have the ability to restrict access to critical data
based on user-roles to prevent unauthorized use and to audit
changes to data within the system. The system should provide audit
trails for transaction updates and retrieval of designated critical
data. Audit trails will identify all information by:

user identification
network terminal identification
date and time
kind of data accessed or transaction executed.
Reporting and Analytical Functions
A major consideration for the IFAD Borrower/Recipient Portal system is
its reporting capabilities. IFAD wants to ensure that the system provides
full flexibility in report production and that running large reports does
not impact system performance.
A comprehensive suite of reports shall be provided as indicated in the
Reports business functionality section. All standard reports shall be
parameter driven and provide for a range of data selection, grouping,
aggregation, and sorting.

17

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

Data shall be available for downloading to excel for analytical and


formatting purposes.
The user shall be able to request a report execution to be run on the
server, with the system notifying the requestor when the report is
available for viewing. This provides a better user experience for long
running reports.
1-ADR-14

Identity Management: The system shall have the ability to distribute


and delegate user administration between several administrators so
that each administrator is responsible for a particular set of users and
for a limited set of roles. For example, you can designate one user
administrator for each borrower in a country or recipient. Each user
administrator can then only create, modify, delete, inactivate and
activate users for the borrower or recipient that he or she is responsible
for. Additionally each administrator shall be able to assign only a
specific set of roles.
The administrator role will have the ability to update and maintain
email addresses for the distribution of debit advices and billing
statements. These email address updates should be propagated to
Flexcube to ensure that email address information in Flexcube stays in
sync with the Portal.

1-ADR-15

User Experience with data entry: The system should automatically save
any data entered by the user at frequent intervals (say every 30
seconds). This auto save and any saves made by the user during input
will not cause data validations to take place. Where data validations
exist within a process, the user will be required to submit the request
for validation as a separate step.

2-HDR

High level design and architecture

2-HDR-01

High level design and systems architecture: The Supplier shall submit a
high-level design and systems architecture of application and
integration components. The architecture must clearly depict all
components and show integration points with internal systems.

2-HDR-02

Integration with existing IFAD systems


The Portal will need to integrate with several IFAD systems. Once the
supplier identifies the integration points in collaboration with IFAD,
IFAD will provide the integration routines to be invoked from the Portal.
The supplier shall identify in the proposal any constraints in the type of
integration technologies that are imposed by the proposed solution.
Requests which interface to Flexcube (FX) may be submitted at any
time during the day, however, given that there are certain times of the
day or month where transactions cannot be processed by FX in order to
allow other processes to execute, it is envisaged that the requests are
first stored in a staging area in the Portal environment before being
submitted to Flexcube. The individual processes where this is applicable
are noted in the Appendices.

2-HDR-03

The Supplier should provide an integration architecture based on the


following integration requirements:

18

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

1. Oracle Flexcube (FX): The Portal will have a number of


interactions/interfaces with FX. These interfaces need to invoke FX
Web Services (SOAP or EJB) to get data from FX and to update data
in FX. The updates can create, modify, delete FX data.
2. Microsoft Sharepoint: Sharepoint provides the infrastructure for
IFAD's document and records management systems. The Portal will
access Sharepoint for the following requirements: a) access an
existing document in Sharepoint and make it available to the Portal
user; b) submit a new document to Sharepoint for storage, and be
able to access it later; c) delete an existing document from
Sharepoint; d) retrieve a list of documents from Sharepoint and
display the list in the Portal. The user can then select a document
from the list. Different Sharepoint based systems need to be
accessed like the RMS (Records Management System) and the PLF
(Project Life File folder in xdesk).
3. GRIPS (Peoplesoft): Project information is stored in PeopleSoft.
Integration with Peoplesoft will be via Peoplesoft Web Services.
4. FMA (Financial Management Application): This is a system under
development using Ruby on Rails and PostgreSQL. Web Services will
expose the services needed by the Portal.
5. GARTS/ARTS (Audit Tracking System): Built using Ruby on Rails
web technology with PostgreSQL as the database. Web Services will
be provided for accessing data and documents. The Portal will need
to access a particular document or retrieve a list of documents.
Certain documents submitted in the portal will require to be
interfaced to (submitted to) GARTS/ARTS.
6. Data Warehouse (DW): The data warehouse (Oracle RDBMS)
contains a lot of the data used for reporting. Data will be accessed
either directly from Oracle tables or using procedures developed by
the Supplier.
7. People: This system contains information about IFAD staff roles,
and assignments to region, country etc. The system uses Ruby on
Rails and PostgreSQL. As the solution for roles and identify
management is implemented for the Portal, there will be a need to
have an interface with People to keep the data in "People" updated
and current.
8. Two Factor Authentication (2-FA): The Portal solution must
integrate with the 2FA solution in Lot 2.
9. Identity Management: Provided by the Supplier, this system will be
used to identify the users and assign roles and privileges across
systems.
10. Microsoft AD: This provides userid and password based access
control for IFAD users to existing IFAD systems.
11. Link to "No Objection System". This is a system under
development in IFAD using an in-house workflow tool called
Scriptoria. The Portal should provide a single signon experience to

19

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

the No Objection System.


12. Link to RIMS. The Results and Impact Management System, uses
Ruby on Rails and PostgreSQL. The Portal must provide access to
RIMS, with a single signon experience.
13. End-User Helpdesk Software: The end user request for help form
on the Portal must be submitted to the end-user helpdesk
software. The helpdesk software will either be BMC Footprints
hosted by IFAD or a standard helpdesk system used by the provider
of end-user helpdesk services. In the case that the Supplier uses a
ticketing system other tha Footprints, integration must be provided
to pass tier 2/3 issues which need resolution by IFAD staff.
14. IFAD.org Public site, to link to publicly available country and project
information.
3-DDR

Supplier must provide a Methodology and Approach for Detailed


Technical Design by technology and architecture component. Supplier
should submit their methodology and approach for the detailed
technical design for each component - presentation layer, business
logic and rules, business process management, database design, roles
and security. The System Architecture shall include all the components
defined for the IFAD Portal platform.
Detail how the Supplier's Architecture and Design approach will
facilitate Portal access from tablets and smartphones in future phases.

4-GTR

IFAD Borrower/Recipient Portal Performance in low bandwidth


conditions: The supplier must explain how the system will be designed
for specific conditions that exist in IFAD Borrower countries including
poor connectivity and low bandwidth conditions. IFAD requirement for
deployment the Portal to clients is a minimum of 512kbps connectivity.
Please indicate application design features that will ensure good
performance given existing bandwidth conditions (without using an
offline model). The Supplier shall use bandwidth of 512kbps and a
latency of 300 milliseconds to test Portal response times for end-user
functions. The "time to render" for the login page must be under 3
seconds considering 140 concurrent users. The supplier is invited to
propose additional performance optimization mechanisms for the
solution.
Testing at IFAD Rome with high bandwidth and low latency should
show subsecond response times for screen transaction processing.

20

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

21

C. Functional and Business requirements


Phase 1 Functionality
5-CRP
5-CRP-01

Comprehensive Reporting
General
C05
The detailed requirements for Reporting are included in Appendix 9.
C10
Access to Reporting will be granted through a User/password for basic functionality
which do not allow to enter or approve transactions but access mainly reporting.
However, 2FA may be required at IFAD discretion for reporting as well.
C15
The following users will have access to Reporting:
Borrowers Viewer
Borrowers Author
Borrowers Authorizer
Uploader
Validator
Reviewer - IFAD
Approver
Administrator
C20
The information to be made available should be presented in a modern user
friendly fashion in a dashboard format.
C25
The reports should be made available so that the user can run and obtain up-to
date information.
C30
There should be links between areas facilitating user navigation.
C33
Access of users to reports will be limited to projects, countries, recipients, funding
source or a combination of these three, depending upon the overall access of the
user.
C35
Once a user has selected a single type of financing, navigation to different areas
should keep the same financing proposed with the option to select another
(depending on the access of the individual).
C40
There should be the possibility to export and download all reports and pages to
excel.
C45
Where information is generated on a periodic basis (for example the billing
statements and debit advices), notifications should be generated to inform the user
that the information is available on the portal.
C47

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

5-CRP-02

22

Some reports currently exist in Oracle BI. If the Supplier proposes to expose BI
reports directly to Portal users, then additional BI licensing requirements for Portal
users must be included in the Supplier proposal. Otherwise reports will have to be
written for the Portal using the reporting tools proposed by the Supplier.
My portfolio
C55
My portfolio will be the point of access of users
C60
If a user has access to more than one project or country, there should be the
possibility to search for financing. The results of the search will depend upon the
access of the user. If the user has access to only one project the information will be
shown directly.
C65
The user will also have the possibility of designating financings as favourites to
avoid having to search every time.
C70
Depending on the access of the user or the search carried out a list of projects will
be presented together with graphs and pie charts comparing financed amount with
disbursed amount.

5-CRP-03

Project at a glance
C72
This page is designed to provide an overview on a project by project basis. Full
details of the information to be shown has yet to be defined, however an example
is shown in Appendix 9. Project information is available from Peoplesoft GRIPS.

5-CRP-04

Financing overview
C75
This page will provide an overview of the financing accessing standing data
(reference data) in FX.
C80
There will also be the status of funds which is a report currently available in BI. The
report format has been amended slightly for presentation in the Portal. This report
needs to be amended to display the status of funds in other currencies if selected
and to include the percentage financed by IFAD
C85
The financing Overview should default to be in the currency in which the financing
is denominated, be it SDR, USD, EUR or other
C90
The user will have the possibility of changing the currency to one of SDR, EUR, USD
or local currency for the country concerned
C95
Where the currency is changed from the denominated currency all figures will be
calculated at the current exchange rate of the date that the information is
provided. A message will be included explaining the exchange rate used.
C100
In converting the status of funds from the denominated currency to the currency
selected by the user, the following exchange rates should be used:
Allocation: as at the date of approval
Disbursed: composite of actual exchange rates at the date of disbursement
for conversion to USD. For other currencies to use the exchange rate at the

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

23

date of running of the report.


A note should be included in the status of funds, explaining the exchange rate.
The exchange rates are available in Peoplesoft (GRIPS) for the allocation
and for the disbursed they are available from two tables in Flexcube
(current exchange rates and historical).
5-CRP-05

Disbursements
C105
This page will give details of the disbursements as a dashboard for the financing.
Historic information will be provided and the total of disbursements will agree to
the Total Utilized on the Financing Overview page. The current report which exists
in BI is the Historic Transaction Report.
C110
The users will be able to export the information to excel.
C115
The explanation notes on the Historic Transaction Report will be included as a
footnote.
C120
Once electronic Submission for WA has been implemented any WA processed
through the Portal will have the link to the WA notification/form used for
submission.
C125
Users will be able to sort the WA by any of the header fields.
C130
From the payment, there will be a link to self-service to generate the relevant debit
advice
C135
The user will also be able to run the report as of a specific date. This report will be
exportable to excel.

5-CRP-06

Debit advice
C140
The user will have the ability to re-generate a debit advice. If a payment is selected,
the relevant RFD field will be automatically populated. The user will also be able to
change the financing number and other data in order to use self-service and
generate the debit advice.

5-CRP-07

Designated Account or Advance account


C145
There will be a page available with information on the bank account details for all
designated accounts and Advance Accounts. This will be accessible from a tab.
Different information will be presented depending on whether the account is
managed under the imprest method (Category = SPL) or Revolving Fund (Category
=ADV) method. The information with which this page will be populated is available
in FlexCube, however there is no report currently available which provides the
information. In addition, the ability to identify the data easily is dependent upon a
remarks field, which is not always complete nor is standard text used. Hence it will
be necessary that IFAD users are able to validate this information as each loan or
grant starts to utilise the Portal. Furthermore, where the only payments to the bank
account have been made pre-Flexcube, the banking information data is not held in
FX, but can be obtained from the Query by W/Application, Beneficiary report in

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

24

DW.
C150
A customization is required in Flexcube whereby a flag is introduced to the Payee
Instructions form to be able to identify the relevant accounts as designated and/or
advance accounts, in order to overcome the issues noted in C145. This Flexcube
customisation will be handled by IFAD
C155
Where the B/R uses pooled Treasury accounts for multiple projects, the Portal
should also provide information on an aggregated basis. This information is not
maintained in current IFAD systems, hence the Portal should contain the possibility
for an IFAD Role ( Validator or Approver) to indicate that Pooled Treasury accounts
are used and then select the projects and financing which are linked to that Pooled
Treasury account. The Validator or Approver will maintain a list of pooled Treasury
accounts in the Portal for a country and link financings to a pooled account.
C160
If Pooled accounts are selected then there will be a page with the pooled accounts
which adds up all the information on the bank accounts for C145 and presents it on
an aggregated basis. [Note: This report should be reconfirmed before design starts.]
5-CRP-08

Total IFAD disbursements to borrower or recipient


C186
This page will provide an overview of the total amount that IFAD has disbursed to
the Borrower or Recipient on a year by year basis, cumulative and by currency. In
this way the borrower or recipient will be able to have an overview of funds
provided by IFAD to the country/non-country recipient.
C187
The information is available in the BI report Disbursement report. The report can
be run on a from and to date basis. The graphs to be presented are for each
currency and the underlying data is obtained from the disbursement report itself.

5-CRP-09

Financing Status
C165
Users should be able to access the Financing Status directly (i.e. as a point of
access) as well as from the My portfolio page or the Financing Overview page.
C170
The purpose of this area is to give Borrowers information on loans and how much
has been repaid. As a result, access to this page will be more limited and it is not
expected that the PMU will have access
C175
The access of Borrowers will be linked to the information for the specific country
and hence accessing the financing status page will cause a summary of all loans to
be generated. There exists a current report in BI Loan Disbursements and
Repayments Report which provides the information required. However, this will
be presented in a more user-friendly fashion.
C180
The information will be hyperlinked to the disbursement page for disbursements
and to the Individual Loan Status page (see below) . Amounts billed will hyperlink
to the page for the generation of the billing statement (see separate section
below).
C185

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

25

The user will also be able to run the reports as at a specific date or for a specific
period.
5-CRP-10

Individual Loan Status


C190
This page provides a summary of the loan (as a header) and the information on
amounts billed and repaid for individual loans. The information is available in the
Historic Repayment File report currently available in BI.
C195
In addition with being presented with the information, users will also have the
possibility of running the report for any date period they require. This report will be
exportable to excel.
C200
Amounts billed will hyperlink to the page for the generation of the billing statement
(see separate section below)

5-CRP-11

Generation of Billing Statement


C205
Clicking on the Amount billed will allow the user to drilldown to the self-service for
the billing statements. The current report which is in BI is the Billing Advice.

5-CRP-12

Instalment Schedule
C210
Borrowers will be able to obtain instalment schedules for each of the loans by
clicking on the specific loan and at a total level by Borrower. The report available in
BI for the individual loans is Loan Instalment Schedule and this is not available on a
total basis. Furthermore, where loans were in existence at 1 November 2013 (date
of implementation of FX at IFAD) the first instalment represents all the previous
instalments billed as a lump sum. Hence this report will require modification before
being presented in the Portal.

6-ADC
6-ADC-01

Access to Key Documents


General
D03
The detailed requirements for Reference/Key documents are included in Appendix
11.
D05
This area will allow users to view documents which have been made available by
IFAD. The Reference documents will be accessible both as a separate tab within the
Portal and also as a link from the Financing number in My Portfolio, in Financing
Overview and in Financing status.
D10
There will be three main categories of documentation:
Financial Reference Documents
Operational Reference Documents
Documents from the Borrower or Recipient
D15
Under Financial Reference Documents there should be directories for the following
documents with links to the documents themselves:
Financing agreement and amendments

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

26

Letter to the Borrower and amendments


Signatories

D20
Under the Operational Reference Documents there will be directories for the
following documents with links to the documents themselves:
Design documents
Supervision reports, mid-term review reports and other official mission
reports
D22
Under the Documents from the Borrower or Recipient there will be directories for
the following documents with links to the documents themselves
Audited financial statements
Interim financial statements
Subsidiary Loan Agreement
Implementation Agreement or Memorandum of Understanding
6-ADC-02

Financial Reference Documents


D25
The Portal shall provide a secure facility for the upload and approval of documents,
referenced to the appropriate financing and/or project, to be made available for
viewing by the B/R.
D30
There should be the possibility to access previous versions of the documents as well
as maintain an audit trail of the period of relevance of the documents.
D35
Once documents are uploaded a notification will be sent to the B/R.
D40
Routing will be based upon role information and additional approval criteria.
D45
There should be the possibility for new categories and directories to be added and
for the documents to be sorted in order to find the document required.
D50
Each document will be tagged as to its contents when uploaded and there will be a
set of standard tags (Financing agreement, Financing Number, Letter to the
Borrower/Recipient) etc.) supported by the IFAD backend system.
D55
It will be possible to amend the tags by an administrator role.

6-ADC-03

Operational documents
D65
The documents required are currently published on the IFAD Internet (public) site.
D70
The documents should be accessible directly from the relevant project and
financing as described in D05, through the Operational Reference Documents area.

7-WAD
7-WAD-01

Withdrawal Application for Disbursements


Submit a request
B01
When the user selects submit a request s/he will be directed to a page with options
for the different requests which can be submitted. The options will be available if

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

27

the underlying functionality is available. If any of the functionality is not available


because they are not in Portal Phase 1, the option will not be present on the page.
B02
The Options (Phase 1 in bold below) will be:
1. Submission of Withdrawal Application
2. Submission of Banking Instructions
3. Submission of Annual Work Plan and Budget
4. Confirmation of Disbursement Conditions
5. Reallocation of Categories
6. Increase/decrease in Special Account Allocation
7. Contract Monitoring
8. Submission of Recovery Plan/Schedule
9. Procurement plans and bid document submissions
B03
Only users with Borrower Author access will be able to initiate requests in any of
these areas. Users with Borrowers Authorizer access will be able to approve the
requests and users with access Borrowers- Viewer will be able to view the requests,
to the extent that each of the users are given access to the individual financing. Full
details on user roles are included in Appendix 12.
B04
In the various processes, the B/R will be able to upload scanned documents. The
scanned documents do not need to be retained in the Portal, but should be routed
to RMS for document management once the transaction is approved. The
documents should be accessible from the Portal by the B/R and by IFAD.
B06
For all requests concerning financing to countries the information on who to route
the notification to in IFAD will be based on the user's profile, country and role.
B08
The system should have the ability to track the status (including the actor who is
holding the step) of each request submitted at any point of time in the workflow.
Furthermore the system should track the time of completion of each step. This is
required in order to be able to report on the time for processing. For Withdrawal
Application see Appendix 1 1.27.
7-WAD-02

Process - Submission of WA
B10
In order to submit a WA the banking instructions need to have been inserted and
approved in FX. In this way only approved banking instructions will be available to
the B/R.
B12
The proposed process flow for the submission of Withdrawal Applications and the
detailed requirements for the submission of Withdrawal Applications is included in
Appendix 1.
B14
In order to submit a Withdrawal Application the B/R is required to complete certain
mandatory forms. These are Form 100, Summary Sheet, Form 101, 102, 104 (A or
B), 105. Recipients of non-country grants are required to submit a statement of
expenditure as well as Form 100. An example of each of these forms is provided in
Attachment 5 to Appendix 1. The standard Form 100 has been modified for the eSubmission of WA in the Portal for ease of presentation of data. Only the Form 100

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

28

will be required to be completed in the system in Phase 1 of the project: the


remaining forms will be uploaded as scanned documents
B16
As part of the WA process documents will be uploaded. The system should be able
to support the upload of scanned documents of an average size of 10 MB.
B18
Any scanned documents are to be routed to RMS for storage, once approved by
IFAD, however should be accessible from the Portal by the B/R and by IFAD.
B20
Information in the Portal will need to be available for all IFAD Country Offices (ICOs)
and in particular the areas concerning loan administration will require to be
accessible from multiple locations with workflows being cross-locations.
B23
There will be 2 options available for the submission of a Withdrawal Application:
Through the Portal
Not through the Portal
o Paper
o Scanned
B25
Where the WA is submitted through the Portal, information on WA (Form 100 in
Phase 1 and with options for Forms 101, 102, 104 and 105 in Phase 2) will be
inserted into the Portal and scanned supporting documentation will be uploaded.
Application is approved in the system and submitted to IFAD for processing
Where the WA is not submitted through the Portal, the Form 100 will be
completed by IFAD staff and the scanned documentation will be uploaded to the
system by IFAD staff.
B27
There will need to be a separate process for projects which are not supervised by
IFAD. The information transmitted by the Cooperating Institution will be inserted in
the Form 100 by IFAD staff, with no certifications or approvals required. The
notification form will be created as for other WAs and the internal system checks
will be performed. The notification will be routed directly to the Approver. Projects
which will follow this process can be identified from the User-defined field:
Cooperating Institution in Flexcube. If this field contains a value then this process
will be followed. The full details are explained in paragraph 1.7 of Appendix 1.
B28
When submitting a Withdrawal Application, it should be possible to request more
than one application type (e.g. Direct payment and a replenishment or a
replenishment and justification) which are expected to create multiple transactions
in FX.
B29
One WA may contain several requests for payment or justification. The Validator
and Approvers will need to have the possibility to treat these separately and
approve, reduce or reject individual transactions.
B30
Only the Validator will have the possibility of reducing the total amount of the WA
as well as the allocation to categories. When the WA has been reduced the
transactions created in FX will be for the reduced amount. At the same time, once
the transaction is approved, information on the amount reduced will be interfaced
to FMA as ineligible expenditure.
B32

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

29

Access to the Withdrawal Application process will be granted through a two-factor


authentication process.
B35
The following users will have access to the submission of WA:
a) Borrowers Viewer
b) Borrowers Author
c) Borrowers Authorizer
d) Uploader
e) Validator
f) Reviewer - IFAD
g) Approver
h) Administrator
B40
Access will be limited based upon the user set up to projects, countries, recipients,
funding source.
Note that the Withdrawal Application process in the Portal has many interactions
with FX. The design of the Portal must ensure that the Portal data remains in sync
with FX, and any and all responses from FX are processed correctly within the
Portal.
7-WAD-03

Common steps for all submission methods


B45
1. Information is input to mandatory Form 100.
2. Scanned supporting documentation is uploaded within predefined areas.
3. Validation checks currently performed by FX are performed upfront by the
system
4. A user-friendly notification is created for review and approval by IFAD
with additional information. This will also contain warning messages for
areas to be reviewed.
5. The WA will be routed for review based upon the risk-based disbursements
(RBD) framework of IFAD. There should be the possibility of maintaining
tables in order to define the routing under RBD and hence change as
necessary and as the framework evolves.
6. There will be the possibility to add documentation or amend the WA if
required by IFAD
7. The WA will be routed for approval.
8. Once approved, the relevant transactions will be created in Flexcube
9. At appropriate stages, notifications will be sent to the B/R, CPM, FA, FO
concerning the status of the WA.
10. Reporting will be available on the status of the WA and its history.

7-WAD-04

Required functionality for all submission methods


B50
A mandatory Form 100 is to be available for the Author or Uploader to insert
information on the WA. This will reference to certain standing data in FX.
B55
The Form will contain specific areas for the upload of scanned documents. The
areas will be labelled and will be available for review by the Authorizer, Validator
and Approver.

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

30

B60
Various system validation checks will take place to ensure the completeness and
accuracy of information included. These validation checks are all currently available
in FX. Some are currently activated in FX at the point of entry of data and some are
at the point in which a transaction is saved. These system checks are detailed in the
eSubmission of Withdrawal Applications Appendix 1.
B70
User friendly notification will be created to summarise the information on the
mandatory form for review and approval.
B75
The Portal will include automatic routing:
To an external approver (Authorizer) if Form 100 is initiated by an external
user and is to be approved online.
To IFAD if Form 100 is initiated by an IFAD user (i.e. there should be the
possibility for IFAD user to insert data in Form 100 from the paper form
and this will not require to be approved by the Authorizer)
B80
The Portal will include workflow to route the request as necessary between the
various actors. Any notification needs to be completely traceable. The request will
pass through different stages and statuses in the workflow and the B/R view of the
Portal must include the current status of the request.
B83
Where online approval is used, there will be a workflow for initiation and approval
at the borrower/recipient level prior to submission to IFAD. This approval will take
place within the Portal.
B85
It should be possible to amend the routing rules associated with workflow requests
should it be decided that certain value/type or risk of WAs need to be routed
differently. This is particularly valid for the certification by the CPM (Reviewer
IFAD role). Hence this routing needs to be completely configurable. Full details of
the routing required is defined in paragraphs 1.16, 1.17 and 1.18 in Appendix 1.
B95
Form 100 is to be fully printable also as a pdf.
B105
Any request submitted will pass through a series of predefined validation checks
which may give rise to warning messages being created.
B110
The notification for review by IFAD will differ to that of the B/R in that additional
information will be included (from BI, Financial Management Application - FMA) as
well as any warning messages arising from the point above.
B115
The Validator and Approvers will have the possibility to insert comments, route
them back to the B/R or forward to the Approver.
B120
The Validator only will have the possibility of reducing the total amount of the WA
as well as the allocation to categories. When the WA has been reduced the
transactions created in FX will be for the reduced amount. At the same time, once
the transaction is approved information on the amount reduced will be interfaced
to FMA as ineligible expenditure.
B125
The Portal will include a completely configurable workflow for risk based

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

31

disbursements. The routing of the request will depend upon the risk rating (which
will be interfaced from the FMA), materiality both relative to the underlying
financing and in absolute terms, type of payment e.g. first disbursement. If the risk
category changes, this should automatically change the process checks and flows
associated with subsequent WAs.
B130
The Portal will include a completely configurable workflow for straight through
processing1. This will be a future option for IFAD and so the system should be
designed in such a way to allow straight-through processing of withdrawal
applications based upon certain criteria in the workflow (see B125)
B135
It will only be possible for the B/R to amend or add information to a WA which has
been submitted if it is released for editing by IFAD. The WA will require reapproval
if any of the input fields are changed. If the only change is to upload additional
scanned documents the WA will not be routed for reapproval but it will be possible
to submit directly to IFAD.
B140
The B/R will be able to delete or modify any WA prior to being submitted to IFAD.
B145
There will be a workflow for up to two stages of approval by IFAD depending on the
risk, type and value of the WA
B150
Upon final approval by the Approver of the WA an approved transaction will be
created within FX. [This assumes that the maker and checker functionality can be
combined in FX for transactions generated by the system. If this is not possible an
unapproved transaction will be created in FX for approval by the Checker]. Given
that there are certain periods of the day or month in which transactions cannot be
input into FX (i.e. during EOD or the billing cycle), requests will be staged pending
interface into FX. If it is not possible to create an approved transaction in FX then
notifications will be generated for any transactions which remain unapproved for
more than 6 hours and a list will need to be available to the Checker to be able to
trace the transaction in FX.
B155
Where the withdrawal application has been submitted at the project level, there
needs to be as many transactions in FX as the FX Accounts which have been
selected. Where more than one request for payment has been made in a WA, there
will be as many transactions created in FX as different bank accounts to which
payments are to be made..
B160
There will be reports available in order to ensure that the interface to FX has
worked correctly and to allow IFAD staff to follow up on any transactions which
have failed the interface. The system should provide a set of control and tracking
reports of which this is one.
B165
Risk ratings will not be initially visible to B/R, however there should be the
possibility of making this information available in the future.
B170
1

Straight through processing refers to the process whereby the B/R submits a request to IFAD, the system will
auto-approve, a transaction is created in FX and the payment is processed, with no intervention from IFAD
staff.

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

32

At each stage in the approval workflow, the notification will capture the names of
the people who have approved and their role as well as the time and date of the
action taken.
B173
There should be audit trail for initiation and approvals given within the system.
Such information will need to be maintained and fully accessible by IFAD staff for
audit purposes.
B175
Worklists will be available to IFAD users of notifications to be actioned with key
information for each notification. The list will be completely searchable to allow
notifications to be retrieved easily.
B180
At certain key steps within the process email notifications will be sent to email
addresses of the B/R. At the same time there will be an area within the Portal for
communication and a short description of the notification will be included.
B185
The Portal is expected to integrate with current IFAD systems as follows:
With Flexcube: to obtain standing data see separate attachment 1 to
Appendix 1 - detailed requirements for eSubmission
With Flexcube: to generate transactions: Requests for Disbursements,
Justifications, Category Reallocations
With FMA in order to obtain data: Risk rating, Ineligible expenditure,
With FMA in order to pass data: Ineligible expenditure identified
With GARTS/ARTS: Audit reports pending, Action plan in place and on time
With the identify and access management system to obtain information on
who notifications/requests are to be routed to for country financing;
With GRIPS to obtain information on who notifications/requests are to be
routed to for non-country financing
With Microsoft Sharepoint to access, store, replace documents.
With additional IFAD systems.
B187
Certain data will be required to be referenced which is not currently maintained in
any IFAD system, nor is it planned that the data will be maintained in a structure
which would allow the data to be referenced by a system. As a result a database of
additional information will need to be created/defined. For each FX account the
following information will be required: SOE thresholds per category, Start-up costs,
Percentage of AWPB which is to be financed (for revolving funds), Retroactive
financing, Minimum WA amount, Percentage of each category financed by IFAD.
This database must include information from Flexcube to allow cross referencing
e.g. for the SOE thresholds per category, the reference data would be the category
number and description. It is not mandatory that all the fields are completed.
B188
The data at B187 would be input by the Uploader or Validator role and would be
approved by the Approver role
B190
At the relevant point (after confirmation of execution of payment by the bank) the
debit advice is generated and is sent to the B/R via email. This is a current process
available within the IFAD systems. The functionality required to be delivered is that
the B/R will be able to generate the debit advice through self-service available in
the Portal (see C140). An alert in the Portal should trigger an email notification to
the user(s) who needs to view the alert. It should be possible for the user to turn

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

33

such email notifications of alerts off in his/her profile in the Portal. This will allow
users to control the number of emails they receive about alerts. [ A final decision is
still to be made on whether the sole form of communication will be through alerts
or notifications in the Portal or whether emails will also be sent. So discuss with the
IFAD Project Manager at the appropriate time.]
7-WAD-05

Specific functionality for non-portal process


B195
The Uploader will enter the data into the mandatory Form 100 and submit to IFAD
(i.e. no approval process before submission to IFAD).
For Portal Phase 2: Alternately there will be an option for the automatic
recognition of characters from a scanned document for IFAD staff and the various
fields in the Portal will be populated by the system thus creating an eForm. The
Uploader will review the eForm against the scanned documentation, will correct
where necessary and then will submit the eForm. Optical Character Recognition is
not to be delivered in Phase 1, but will be required in Phase 2.

7-WAD-06

Specific steps in online approval process


B210
1. Author at B/R uploads scanned documents within predefined areas.
2. A user-friendly notification is created for review and approval by the
Authorizer.
3. Workflow automatically routes the request for approval by the B/R
4. B/R approves the WA and submits to IFAD. This will require the positive
certification of certain conditions by the Authorizer. These conditions will
vary according to nature of the recipient (Non-country) and according to
the type of finding (i.e. if funding = EU).

7-WAD-07

Specific functionality for online approval process


B220
Where online approval is used the Form 100 will include certification boxes which
require to be ticked as confirmation of the conditions.
B225
The Portal will allow the upload of scanned documents in specific fields.

8-MBI
8-MBI-01

Manage Banking information

B251
The proposed process flow and the detailed requirements for the submission of
Banking Information are included in Appendix 2.
B255
Access to the banking information process will be granted through a two-factor
authentication process.
The following users will have access to Banking information functionality in the
Portal:
Borrowers Viewer
Borrowers Author
Borrowers Authorizer
Uploader
Validator
Approver

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

34

B260
There will be a form for the submission of banking information.
B265
The form will have the possibility to upload scanned documents mandatory field
B270
There will be an approval workflow whereby the form is routed to the Authorizer.
B275
At each stage in the approval workflow, the notification will capture the names of
the people who have approved and their role
B280
Once approved the workflow will route the form to the Validator2. The Validator
will insert the banking instructions into FX (Payee Instructions). (Portal Phase 2 will
require the use of Optical character recognition to facilitate the insertion of data in
FX. Refer requirements under Phase 2.)
B285
The banking information in FX will require to be validated by an Approver before it
is available to the B/R for use within the WA process.
B287
There will need to be the possibility to reject the BI back to B/R with request for
additional information.
B290
Notifications will be generated informing the B/R (by email and online) of the status
of the request
8-MBI-02
9-LNO
9-LNO-01

The supplier shall provide advice on how to control and manage the security of the
Banking Information process in the Portal to mitigate as much as possible the risks
of fraud and subversion of funds.
Link to No objection System
B637
There is no appendix in which the detailed requirements for this functionality are
defined.
B640
The requirement in Phase 1 is to be able to access another system (under
development). The Portal should provide a single sign-on experience to the No
Objection System. For Phase 2, the functionality is detailed under 10-SDC and
other Phase 2 functionality.
B665
IFAD is in the process of developing a workflow for No-Objections within the
Scriptoria system. The acceptance of the procurement information (but not
necessarily the procurement plan) will fall into this workflow. To the extent that
this functionality is developed and delivered before the Portal, the minimum
requirements for the first phase of the Portal are that the No-Objection system be
accessible from the Portal via links with a single signon. It is preferable that the look
and feel of the Portal and the No-Objection be similar.

Currently the update of banking instructions is performed by CFS and hence this would be included in the
access of the Validator and Approver. To be decided whether this function should remain in CFS. If not,
separate roles will be required for the update and for the approval of banking instructions.

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

35

B670
The detailed requirements for Portal Phase 2 need to be clarified, however these
could include the linkage between the AWPB, the procurement plan, No-objections
provided on individual procurement actions and the contract monitoring form
functionality.

Phase 1.5 Functionality


27-LAN

Add French and Spanish Support in the Portal


Multi-Language: The system must provide flexibility for Multi-language support, i.e.
English, French, Spanish and Arabic Language Support. Only English will be
supported in Phase 1 of the project.
IFAD is considering providing Spanish and French support in the Portal, after Phase
1 go live. Supplier shall estimate the cost of supporting Spanish and French, in
addition to English. Language support applies to labels and other presentation
elements, number formats, help, FAQs and such in the Portal, error/warning
messages, and supplier provided documentation available to Portal end-users. The
supplier is responsible for translation to Spanish and French. Data in the system will
be shown as is, e.g. if textual data in backend systems is in English, it will be shown
as English in the Portal.
IFAD is also considering adding Arabic support to the Portal after Phase 2. Supplier
shall provide the cost of adding Arabic to the Portal after Phase 2 go live. The
design of the Portal shall take into account right to left languages considerations.
[Note: the discontinuity in the numbering of requirements is deliberate.
requirement 9-LNO, it jumps to 27-LAN and back to 10-SDC.]

After

Phase 2 Functionality
IFAD wants to understand the cost of Phase 2 functionality in detail to enable IFAD to make trade offs
based on budget and priority considerations. The cost table lists the level of detail requested.
10-SDC
10-SDC-01

Submission of Documents by Borrowers and WorkFlow


Process - Submission of AWPB
B295
The proposed process flow and the detailed requirements for the submission of
the AWPB are included in Appendix 3.
B300
Access to the AWPB process will be granted through a two-factor authentication
process.
The following users will have access to the submission of WA:
Borrowers Viewer
Borrowers Author
Uploader
Validator
Reviewer - IFAD

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

36

Approver
Administrator

B305
There will be a form for the submission of the Annual Work Plan and Budget. There
will be 3 fields for data entry and a requirement to upload a scanned document
B310
There will be no approval workflow at the B/R level; once completed the AWPB
will be submitted to IFAD
B3153
The Portal will include workflow to route and re-route the request as necessary
between the various actors. Any notification needs to be completely traceable.
The request will pass through different stages and statuses in the workflow and
the B/R view of the Portal must include the current status of the request.
B320
If a certain period of time (30 days) has passed by from submission and no action
has been taken by IFAD the AWPB will automatically move into the final status of
Accepted
B325
At each stage in the approval workflow, the notification will capture the names of
the people who have approved and their role
B330
Once the AWPB has been accepted the fields within the form will be available for
use by the WA submission process.
B335
Throughout the process notifications will be generated informing the actors where
action is to be taken. For IFAD users these notifications will not create emails, but
there will be a worklist.
B340
Notifications will be generated informing the B/R (by email and online) of the
status of the request
11-RIMS
11-RIMS-01
12-LWA
12-LWA-01

Link to Project Results and Impact Management System


The solution should provide a link to the IFAD Results and Impact Management
System (RIMS). Note that RIMS is scheduled for an upgrade in the coming year.
Integration of Withdrawal Application System with AWPB, Bid documents,
Procurement plan etc
Process - Contract Monitoring Form
B541
The proposed process flow and the detailed requirements for the Contract
Monitoring Form are included in Appendix 7.
B545
Access to the contract monitoring form will be granted through a two-factor
authentication process.

For requirements B315 B340, IFAD is in the process of developing a workflow for No-objections within the
Scriptoria in-house platform . The acceptance of the AWPB will fall into this workflow. To the extent that
this functionality is developed and delivered before the Portal, the requirements for Portal Phase 1 are to
link to the No-objection functionality (see 9-LNO).

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

37

B550
The following users will have access to the process:
Borrowers Viewer
Borrowers Author
Uploader
Validator
Reviewer - IFAD
Approver
Administrator
B555
The Portal will contain an area which replicates the format of the Contract
Monitoring form (C11). There will be the possibility to upload scanned documents
by the B/R. The form will reference data in FX, with picklists and fields for the B/R
to complete.
B560
The information in the form should be accessible by the B/R and by IFAD staff.
B565
When inserting payments issued in the contract monitoring area, the initiator will
be invited to select a WA from the list of disbursements in order to link the WA to
the contract monitoring. It will not be mandatory for the payments to be linked to
a WA. This means that it will be possible to update the contract monitoring form
and then link it to a WA.
If the payment is a direct payment then the contract monitoring area
should be included in the links on Form 100 for review by the approver
role at the B/R level and by IFAD staff when reviewing the WA.
If the payment is included in the WA, the user will have the possibility of
linking the contract monitoring to a WA and then either to scanned
documents (101,102) or to the individual forms
B567
Whenever a payment is inserted, the system will compare the total payments with
the total contract value. If the total of the payments is greater than the total
contract value (including amendments), the following error message will be given
to the Author and also included as a warning message on the Contract Monitoring
Form:
Warning: the total payments are greater than the value of the contract.
B570
The linking of the Contract monitoring and Form 100 will be reciprocal i.e. it will be
possible to link from Form 100 and the subsidiary forms to the Contract
monitoring and from the Contract Monitoring to the WA forms.
B575
Each user of the Portal be it a B/R, PMU or IFAD user must have the possibility of
navigating easily between the contract monitoring and the individual WAs.
B580
It should be possible to link the contract monitoring to more than one WA.
B585
A contract can be in one of 2 statuses: open or closed. Once all payments have
been made against the contract or the residual value is zero, the initiator will have
the possibility of changing the status of the contract to closed. The status can only
be changed to closed once all WAs which reference the contract monitoring have
been paid. Once the status is closed, it will not be possible to link to a WA and

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

38

hence will not be proposed in any picklist of contract monitoring.


B590
There should be the possibility for the initiator to select a contract monitoring
form by project, by contractor, by status or insert a new contract monitoring
sheet.
12-LWA-02

13-CDB
13-CDB-01

Links between the WA process and AWPB and procurement


B65
If there is a process for the AWPB (Annual Workplan and Budget) within the Portal,
the system checks on the WA will refer to information which has been input and
accepted within the AWPB area in order to perform some of the checks.
B90
When creating a WA, if there is a contract monitoring area within the Portal, the
WA submission and the contract area will be linked to allow the Author to select
the contract against which payment is being requested.
Confirmation of Disbursement Conditions
B341
The proposed process flow and the detailed requirements for the Confirmation of
Disbursement Conditions are included in Appendix 4.
B345
Access to the disbursement conditions process will be granted through a twofactor authentication process.
B350
The following users will have access to the confirmation of disbursement
conditions:
Borrowers Viewer
Borrowers Author
Uploader
Validator
Reviewer - IFAD
Approver
Administrator
B355
Disbursement condition data is not currently held in IFAD corporate systems.
B360
The Portal will contain a form for capturing disbursement conditions. This will be
initiated by the Validator i.e. IFAD. The form will contain boxes for free form text
with the possibility of deciding whether documents are to be uploaded or only
confirmation is required.
B365
The Portal will contain workflow for routing for approval to the various actors
B370
Once approved, a page will be available for the B/R to complete and upload
scanned documents as necessary
B372
At least one condition will be for verification by IFAD (issuance of Letter to the
Borrower). For this condition there will be the possibility to link to the document in
the Reference documents area by IFAD staff.

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

39

B375
At each stage in the approval workflow, the notification will capture the names of
the people who have approved and their role
B377
The B/R will have the possibility of linking the disbursement conditions to
documents in the Reference documents area, or submitting documents to the
Reference documents area through the disbursement condition functionality.
B380
The B/R will have the possibility to submit to IFAD and then the information will be
routed to the various actors for review and approval, rejection or for putting onhold.
B385
Notifications will be generated informing the B/R (by email and online) of the
status of the request
B390
Throughout the process notifications will be generated informing the actors where
action is to be taken. For IFAD users these notifications will not create emails, but
there will be an area for notifications.
B400
Once the notification is approved a transaction will be interfaced to FX to change
the status of the financing to DSBL.
14-ARD

14-ARD-01

15-MSC
15-MSC-01

Access to Reference documents from B/R (financial statements,


implementation agreements, subsidiary loan agreements, signatories)
D80
The Portal will also contain an area for the B/R to submit documents to IFAD.
There should be an area for:
Audited financial statements
D85
There will be an interface with GARTS/ARTS whereby audit reports and interim
financial statements submitted within the Portal will be interfaced into
GARTS/ARTS.
D90
There should be the possibility for new areas to be added and for the documents
to be sorted in order to find the document required. It is expected that the
following categories will be required:
Interim financial statements
Subsidiary Loan Agreement
Implementation Agreement
D95
The new areas will be configurable in the Portal and will be common for all
projects.
D100
Once a document is uploaded by the B/R it should be interfaced directly to RMS,
leaving a link in the Portal for reference.
Reallocation of categories, special account changes, submission of
recovery schedule
Process - Reallocation of categories

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

40

B402
The proposed process flow and the detailed requirements for the Reallocation of
Categories are included in Appendix 5.
B405
Access to the reallocation of categories process will be granted through a twofactor authentication process.
B410
The following users will have access to the reallocation of categories:
Borrowers Viewer
Borrowers Author
Uploader
Validator
Reviewer - IFAD
Approver
Administrator
B415
The Portal will contain an area where a request for reallocation can be submitted
together with a scanned document. The form will reference data in FX, with
picklists and fields for the B/R to complete and a calculation of the final amount.
B420
Once submitted there will be a workflow for the request routing it to the various
actors and allowing the upload of scanned documentation to support the request.
At any stage in the workflow, the request can be accepted or rejected, with
rejections flowing back to the Reviewer and with the possibility to add comments
which can be seen by subsequent roles.
B425
Once all approved the information is presented to the Validator role for input into
FX. Alternately a transaction will be created in FX for review and approval by the
Validator (who will be able to change it) and/or the Approver.
B430
At each stage in the approval workflow, the notification will capture the names of
the people who have approved and their role.
B435
Throughout the process notifications will be generated informing the actors where
action is to be taken. For IFAD users these notifications will not create emails, but
there will be an area for notifications.
B440
Notifications will be generated informing the B/R (by email and online) of the
status of the request.
15-MSC-02

Process - Increase/Decrease in Special Account Allocation


B491
The proposed process flow and the detailed requirements for the
Increase/Decrease in Special Account Allocation are included in Appendix 6.
B495
Access to the Special Account Allocation process will be granted through a twofactor authentication process.
B500
The following users will have access to the submission of WA:
Borrowers Viewer
Borrowers Author

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

41

Uploader
Validator
Reviewer - IFAD
Approver
Administrator

B505
The Portal will contain an area where a request for the increase or decrease in the
special account allocation can be submitted together with a scanned document.
The form will reference data in FX, with picklists and fields for the B/R to complete.
B510
Once submitted, a notification will be created with the summary of the change
being requested and scanned document if any.
B515
This notification will follow a workflow process where each actor will have the
possibility to review the request, approve, reject and add comments.
B520
At each stage in the approval workflow, the notification will capture the names of
the people who have approved and their role.
B525
If at any point in the process the request is rejected, the person rejecting will have
the possibility to insert comments, explaining the rejection. The comments will be
visible to subsequent reviewers.
B530
Once all approved the information is presented to the Validator role for input into
FX. Alternately a transaction will be created in FX for review and approval by the
Validator (who will be able to change it) and the Approver.
B535
Throughout the process notifications will be generated informing the actors where
action is to be taken. For IFAD users these notifications will not create emails, but
there will be an area for notifications.
B540
Notifications will be generated informing the B/R (by email and online) of the
status of the request
15-MSC-03

Process - Submission of Recovery Schedule


B591
The proposed process flow and the detailed requirements for the submission of
the Recovery Schedule are included in Appendix 8.
B600
Access to the recovery schedule process will be granted through a two-factor
authentication process.
B605
The following users will have access to the recovery schedule module:
Borrowers Viewer
Borrowers Author
Uploader
Validator
Approver
Administrator
B610

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

16-WAR
16-WAR-01

42

The Portal will contain a form for the submission of the recovery schedule. This will
be available for all financing. The form will reference data in FX, with picklists and
fields for the B/R to complete and a calculation of the final amount.
B615
The recovery schedule/plan is submitted for each Special or Advance account and
not at the financing level. Hence there will need to be the possibility to submit as
many recovery schedules as advance or special accounts.
B620
There is no requirement to submit scanned documentation and no "approval"
process. Instead the recovery plan is either accepted or rejected by IFAD.
B625
Once submitted there will be a workflow for the request routing it to the various
actors. At any stage in the workflow, the request can be accepted or rejected, with
rejections flowing back to the initiator and with the possibility to add comments
which can be seen by subsequent roles
B630
The input fields will be available for modification by the validator and the
Approver.
B635
Information from FX on Justification transactions related to the specific financing
will be shown at the bottom of the form.
Withdrawal Application Enhancements, Reporting
B225
In Phase 2, the Portal will contain the possibility to insert data for certain forms
(subsidiary forms) or upload scanned documents. Depending on whether the
Author selects to submit scanned forms or use the IFAD forms, the Author will be
proposed with the forms to complete. This selection is made on Form 100. Within
the subsidiary forms, certain standing data will be populated from FX.
Furthermore, not all fields will be obligatory.
B230
Excel uploader will be available for the subsidiary forms to facilitate the capture of
information by the Author. Where the subsidiary forms are used there will be a
step to validate the information. At this point the system will check that the
various amounts which should cross reference to each other agree and that there
are no anomalies with respect to SOE thresholds (held in database within the
Portal). There should be the possibility to develop and change the forms according
to the categories (in FX) selected. Current requirements are for 2 variations, but
this may increase.
B245
The subsidiary forms will all be printable.
B250
If the subsidiary forms are used the Form 100 can only be submitted for approval
once the subsidiary forms have been validated.
B252
Where the B/R submits paper WA the FA (or centralised processing unit) will be
required to insert the data on the paper WA into the eSubmission system instead
of into FX as this will be necessary to take advantage of the logic within the
workflow. All the relevant fields specified in Appendix 1 section 1.5.3 will be
available for the FA to insert information from the scanned form, except for the

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

43

confirmations. Appendix 1 section 1.5.4 will not be relevant for a paper WA.
Alternately the information on the scanned Form 100 will be captured
automatically using character-recognition and an electronic Form 100 (eForm)
created.
16-WAR-02

HIPC information for borrowers


C215
Borrowers who are eligible for the Heavily Indebted Poor Countries (HIPC) debt
relief will be able to obtain information on the amount of relief obtained and the
outstanding balance. This requires information to be obtained from a specific
Access database. This will need reengineering. These reports are to be delivered in
phase 2

16-WAR-03

Portal Phase 2
Optical Character Recognition is required for phase 2 of the Portal.
The FA will review the eForm against the scanned documentation, will correct
where necessary and then will submit the eForm.
Manage Banking Information Phase 2
Portal Phase 2 will require the use of Optical character recognition to facilitate the
insertion of Banking Information data in FX. The OCR capability should extract
relevant fields from the scanned image of the Banking Instruction form and
populate the fields on the banking information screen in FX for IFAD staff to review
and then proceed with updating the information in FX.

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

44

D. Strategic Alignment with IFAD IT Directions

Strategic Alignment with IFAD IT Directions


17-SAI

Strategic Alignment with IFAD IT Directions - Degree of alignment with IFAD IT


Directions and market position.

17-SAI-01

Supplier should explain how the proposed solution will enable IFAD to build
future proofed, secure, expandable large-scale web-based applications with a
high degree of intuitive user-experience that is easy to use without significant
training.

17-SAI-02

Supplier should explain how the proposed solution will enable future
application delivery through mobile and other channels.

17-SAI-03

Supplier should explain how the proposed solution will enable shift to Cloud
Computing.

17-SAI-04

Supplier should explain how the proposed solution will enable Social
networking for IFAD staff and external actors (Borrowers, IFI, experts).

17-SAI-05

Supplier should explain how the proposed solution will enable seamless
integration with internal and external systems.

17-SAI-06

Supplier should explain how the proposed solution will enable the delegation of
user and role administration to the borrower in a secure and transparent way
without the need of intervention of a technical expert.

17-SAI-07

Ensuring the highest level security of the new platform is essential to protect
IFAD reputation and credibility.
Supplier should explain how the security of the new platform will be enforced
at each layer of the solution in order to guarantee the highest level of security
of the current solution and become the cornerstone on which IFAD will build
future enhancements. The proposed solution should be able to be leveraged
and integrated with other corporate platforms

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

E. Service Specifications
1.0

Successful implementation of the project will depend on the provision of key services
defined below.

Project Management, Implementation and Project Team


Project Team Qualification
Training and Knowledge Transfer
Technical Support

Requirements
ID

Description

18-PMR

Project Management, Implementation and Project Team

18-PMR-01

IFAD Borrower Portal system is proposed to be implemented in phases as


follows:
Phase 1 implementation is proposed to cover functionality that is automating
mature processes. The scope of Phase I is limited to a fast-track implementation
of core functionality of IFAD Borrower Portal system so that IFAD can derive
value by deploying the system by November 2016.
Phase 1.5 will add support for French and Spanish to the Portal. These
languages will be rolled out to production as an enhancement to the Phase 1
functionality that went live earlier.
Phase 2 proposal covers implementation of additional business functionality.
Phase 2 business functions are largely defined but may be revised during the
coming year as IFAD gains more experience with the new system. Phase 2
should be planned for deployment and Go Live in an additional 9 to 12 months.
Supplier is expected to provide a project plan and full costing of business
functionality included in Phase 1 , Phase 1.5, and Phase 2.
A preliminary implementation schedule is included in this bid document.
Suppliers are expected to propose their project plan as per their assessment
and must take into account deployment consideration in over 140 countries
across the globe, though the initial deployment for phase 1 will be for a limited
set of countries (e.g. 10 countries).
Please note that bid prices must include Phase 1, Phase 1.5 and Phase 2
implementation.

18-PMR-PM01

Supplier shall describe project team management approach, including lines of


authority, issue identification, escalation and remediation, risk management,
meeting schedules and team coordination and reporting.

18-PMR-PM02

Supplier must clearly identify roles and time needed from IFAD users for a
successful implementation. Identify business and ICT users time required for
detailed business requirements definition, software requirements specifications
reviews, integration, testing, end-user training and final operational
acceptance.

18-PMR-PM-

The Preliminary Project Plan must address the following topics:

45

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

03

18-PMR-PM04

Suppliers Project management structure


Project milestones and performance indicators that may be used to
monitor progress
Project communication plan
Change management plan
Training, and knowledge transfer plan
Testing and Quality Assurance plan
Deliverable acceptance plan
All user guides, operation manuals, as-built system drawing and
technical documents handover plan
Risk management plan
Support plan for the Applications Hotline
Warranty Service Plan
The Supplier shall submit a list of Subcontractors (if any), and detail the
subcontractor scope of work and alignment with the project plan. The Supplier
may from time to time propose additions to or deletions from any such list.
The Supplier shall submit any such list or any modification to the list to the
Purchaser for its approval in sufficient time so as not to impede the progress of
work on the System. The Purchaser shall not withhold such approval
unreasonably. Such approval by the Purchaser of a Subcontractor(s) shall not
relieve the Supplier from any of its obligations, duties, or responsibilities under
the Contract.

18-PMR-PM05

The IFAD Project Manager shall have the authority to veto the assignment of
specific Supplier staff and Subcontractor staff to the project on grounds of
inexperience or lack of appropriate skills.

18-PMR-IA

Implementation Approach & Methodology

18-PMR-IA-01

Supplier must describe their implementation approach and methodology that is


suitable for IFAD. The implementation approach must be grounded in their past
successful experience.

18-PMR-IA-02

Supplier must describe their approach to the design and development of


custom software and reports.

18-PMR-HN

Transition of system support

18-PMR-HN01

After project implementation, the purchaser reserves the right to transfer the
support for the Borrower Portal platform to a different vendor. The Supplier
agrees to assist the Purchaser and the incoming vendor in a smooth transition
of system support arrangements to the incoming vendor as a part of the
Supplier's Borrower Portal support contract.

19-PMT

Project Team Qualification and Experience

19-PMT-01

The Project Manager must have a minimum of ten (10) years experience with at
least two (2) successfully completed projects of similar size as project manager,
preferably on banking projects.
Besides, he/she shall have at least five years (5) of industry experience in a web
application development/development team leadership capacity.
The Supplier shall guarantee that the named Project Manager will be assigned to

46

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

the Lot 1 project.


19-PMT-02

Two (2) Key functional team leads must be identified for the project. Each
functional team lead must have at least five (5) years of experience on the
proposed solution platform. Experience with Banking & Financial solutions or
with government & development clients is preferred.
The Supplier shall guarantee that these two named functional team leads will be
assigned to the Lot 1 project.

19-PMT-03

Project technical team must include Software & System Experts with at least 2
years of experience in the recommended technical platform. Supplier must
provide the following experts:
Senior Technical Architect with at least five (5) years experience implementing
solutions on the IFAD software platform and overall seven (7) years experience.
Candidate should have worked in this role for at least two (2) projects,
preferably on banking projects.
Senior Application Designer & Development team lead with at least five (5)
years experience implementing solutions on the IFAD software platform and
overall seven (7) years' experience. Candidate should have worked in this role
for at least two (2) projects, preferable on banking projects.
Senior IT Infrastructure team lead with at least five (5) years experience
implementing solutions on the IFAD software platform and overall five (5)
years. Candidate should have worked in this role for at least two (2) projects.
The Supplier shall guarantee that these named technical resources will be
assigned to the Lot 1 project (ideally at the start of the project, but not later than
3 months from project kick off, except in case of force-majeure the vendor will
have to communicate it to IFAD).

19-PMT-04

The Supplier shall make available onsite (at IFAD, Rome) senior or key members
of the project team during periods when close interaction with IFAD is
necessary. IFAD expects the Supplier to propose an onsite-offshore model,
while ensuring that key Supplier team members are available onsite when
required.

20-TRM-TR

Training and Knowledge Transfer

20-TRM-TR-01

The Supplier shall provide training for business and technical users so that they
can fully operationalize and run the system. This training is to be provided
before system go live, ensuring that the trainees have enough time to become
familiar with the system before go live.
Business users will be trained on all business processes based on their defined
user-roles and screen navigation requirements.
Technical users will be provided high level training on the overall technology
platform and components, with in-depth training on the integration points.
Among training courses to be provided are

IFAD Borrower Portal Overview for IFAD All Staff


IFAD Borrower Portal Overview for Managers
Specific functional training for business users
Train the trainer, to allow IFAD to continue the training program

47

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

The Supplier must propose local training in Rome, Italy. Total number of
business trainees is thirty (30) in IFAD.
20-TRM-TR-02

The Supplier shall provide a description of their approach to delivering training


and a detailed training plan by user-roles for business and technical staff. The
Supplier shall provide a preliminary training plan including details of
Description of training course
Course title
Learning objective
Course duration
Class outline (subject area, topics and critical learning points)
Delivery methods
Training materials

20-TRM-TR-03

Training material & facility: Supplier is responsible for preparing and providing
all training materials customized for this IFAD Borrower Portal implementation.
The training facility (rooms) will be provided by IFAD.

21-TST-OA

Operational Acceptance Test Phase 1, Phase 1.5 and Phase 2

21-TST-OA-01

Purchaser (with the assistance of the Supplier) will perform the tests on the
System and its Subsystems following installation to determine whether the
System and the Subsystems meet all the requirements mandated for
Operational Acceptance.

21-TST-OA-02

The Supplier's testing methodology shall provide for using regression testing
using automated testing tools to verify that new functionality being added to
the Borrower Portal does not break existing functionality in the Portal. The
Supplier shall provide in their proposal how they will define, implement,
manage and support automated regression testing, and highlight any
limitations of regression testing.

21-TST-OA-03

Supplier will provide comprehensive documentation and test cases for the
purchaser to conduct the Operational Acceptance Test. All system custom
software and reports must be delivered for Operational Acceptance test to
commence.

21-TST-OA-04

Business users will review the Supplier provided test cases, and will form a suite
of User Acceptance Test (UAT) Cases which will include test cases designed by
the business team and test cases provided by the Supplier.
Business users will verify that processes are running correctly, reports
generated match with previous reports and that data interfaces with other
systems are performing correctly.

21-TST-OA-05

The IFAD technical and business teams (with Suppliers support) will ensure that
system performance, security tests and documentation is as per requirement.

21-TST-OA-06

The Entire System: Successful operation of the entire system after Phase 1,
Phase 1.5 and Phase 2 Go Live for a period of eight weeks each is required for
Operational Acceptance of Phase 1, Phase 1.5 and Phase 2 functionality

48

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

respectively.
22-SPT

Technical Support Post Go Live

22-SPT-SP-01

Application Hotline (for IFAD staff)


1. Supplier shall provide 24x7 Application Hotline Support that may be located
at Supplier premises anywhere. The Supplier shall provide a (Tier 1) helpdesk
for IFAD staff to contact for issues and incidents.
2. Cases which the Application Hotline (and the Supplier) are not responsible
for shall be transferred to the end user helpdesk (described in Lot 3) for triaging
and followup.
3. Tier 2 for technical issues should be transferred to the Supplier
technical/development team supporting the system.
4. Tier 1 staff shall use helpdesk software to log and track tickets to resolution.
If the helpdesk software to be used differs from IFADs BMC Footprints, an
integration must be developed to pass tier 2/3 tickets to Footprints for issues
that need to be resolved by IFAD staff.
5. Application Hotline Tier 1 staff shall produce reports and statistics on a
periodic basis as agreed with the Purchaser.

22-SPT-SP-02

Post Go-Live Active Support: During the period after Go-Live (of Phase 1, Phase
1.5, Phase 2) the Supplier shall provide onsite support with a few key resources
to help stabilize the system and ensure that the system is performing correctly.

22-SPT-SP-03

Warranty Service: The Supplier shall provide bug fixes for all bugs in the
Borrower Portal for a period of six months after Phase 1, Phase 1.5 and Phase 2
go live respectively, at no incremental cost to the Purchaser. These bug fixes
should be provided without impacting the System Support arrangement
described below.

22-SPT-SP-04

System Support after go live: The Supplier shall provide support for running the
Borrower/Recipient Portal application and platform and all its instances, and
provide minor enhancements, for a period of two years after go live. The
Purchaser shall have the option of extending the system support arrangement
for another two years after the initial two year period of support. The
extensions of support can be done in one or two year increments.
The support period for Phase 2 after Phase 2 go live will be aligned with the
support for Phase 1 (and Phase 1.5) so that Phase 2 post go live support ends at
the same time that Phase 1 (and Phase 1.5) support ends.
The support service shall include provision for i) minor enhancements and
corrections not handled by warranty ii) regular support for upgrades/patches to
latest versions of application software, operating system and database iii)
provide an application hotline support iv) security alerts and critical patch
upgrades, v) performance tuning and vi) all bug fixes.
A minor enhancement is defined as one that takes not more than 40 person
hours for the supplier to define, develop and test (Purchaser's testing effort is
not considered). The supplier should provide for four (4) minor enhancements
per month in their Portal support cost proposal.
The following SLAs will be required for outages and defects. The supplier

49

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

should propose a best-practice SLA:

Severity Level 1 Critical outage disabling the entire system; or that


negatively affects all users of the system remediation action with
immediate effect.

Severity Level 2 Faults affecting an individual business function; or faults


affecting the performance of the system; or inability to conduct
transactions within 4 hours of notification.

Severity Level 3 Faults that impact the operational efficiency of an


individual business function within 24 hours of notification.

Severity Level 4 Minor defects or faults that impact individual users


within 48 hours of notification.

The Supplier will aim towards 99.9% availability of services under their direct
responsibility, excluding issues for which the root cause is not under their
control. Supplier shall provide a proposal according to industry best practices
including potential penalties and reduction in fees in case of
underperformance.
22-SPT-SP-05

During the Support period, Supplier shall make available its key technical staff
onsite or over the phone/email for consultation and shall respond to critical
system or hardware failures that prevent business operations as per the SLA.
Given the nature of the platform as the channel to conduct business between
IFAD and its partners the application needs to be available, secure, responsive
and supported 24/7. This will be achieved by a mix of on-site and off-site
support. As a result, the following support guidelines need to be observed.
The Supplier shall provide at a minimum the following technical resources
onsite as part of the support team:
During Rome office hours,

A system administrator/DBA

A security, identity/access management technical expert

A Portal technical expert

A BPM technical expert

The supplier will ensure that unavailability of the above resources will be
backfilled. The supplier will propose the relevant profiles.
During Rome non-business hours including weekends, the supplier shall provide
the minimum resources to ensure the availability of the portal and related
services. Non-business hours support can be achieved through offshore
resources and the supplier should propose the operational model.
22-SPT-SP-06

Business End-User documents: Supplier will provide end-user documentation


(training documents, user manuals, eLearning modules etc.) detailing business
processes supported, screen navigation and error actions. Scope must cover all
user roles and actions performed including data entry and report generation.
These documents will form the basis of the training which is included in Lot4
Rollout Support for the Borrower/Recipient Portal.

50

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

22-SPT-SP-07

Technical Documents: Supplier will provide detailed technical documentation


including systems architecture, labeling and schematics, system design,
technical specification and standard operating procedures for operating the
system.

22-SPT-SP-08

Overview of operating environment


System architecture
Hardware and software specifications
Infrastructure system document
System backup and recovery plan
Security configuration

Change Control Procedures


Supplier will be responsible for infrastructure configuration for all
environments. Changes are performed following an internal Change
Management process including approval from IFAD.
Changes to the application code or infrastructure configuration are the
responsibility of the Supplier. To deploy changes in Production, IFAD will
approve the deployment after successful testing of the changes in the UAT
environment.
The standard migration path for code and configuration changes should be
followed, except in the case of emergency fixes. The flow is as follows:
DEV

UAT

PROD

In case of emergency fixes approved by IFAD, there can be a different flow for
the changes. This will be agreed upon with the Supplier by IFAD.
Maintenance Window
The IFAD Borrower/Recipient Portal systems are required to be available 24 x 7.
There is a standard planned maintenance window (which may or may not be
used) to allow for activities which disrupt the availability of the system. The
maintenance window occurs every Thursday from 20:00 to 24:00 CET.

22-SPT-SP-09

If required, a longer window may be agreed in advance between the


Supplier and IFAD. During the maintenance window, users are
prevented from accessing the IFAD Borrower/Recipient Portal systems.
Monitoring
There are four distinct tiers of monitoring in the IFAD environment:
1. Infrastructure components
2. Operating system resource utilization
3. Oracle Database components both availability and performance
4. Application stack availability (e.g. application process schedulers)
Each level is described in more detail below.
1. Hardware Monitoring
This pertains to networking hardware, server hardware, storage, load

51

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

52

balancers, etc. It is primarily low-level monitoring of components such as power


supplies, fans, disks and memory modules. It is based on best-practices set by
the product vendors as to which components should be monitored.
2. Operating System Resources
This pertains to monitoring the utilization levels for the following system
resources on the Linux and Windows servers:
Disk space usage
Memory usage
CPU usage
3. Oracle Databases and Applications
Pertains to using Oracle Enterprise Manager to monitor the database and
application availability and performance.
Part of this monitoring includes a scheduled task that logs into every Production
system on a regular basis, every five minutes or so, using a low-privilege
account. The success of such a login implies that much of the IFAD Portal
software stack is operating satisfactorily and that users should be able to make
use of the system.
4. Application Stack availability
This checks the availability of the components in the application stack including
web servers, applications servers, the Portal programs etc.
Other target metrics are monitored regularly and any alerts are sent to the IFAD
team. This allows informational and warning level alerts to be acted upon in
order to prevent critical alerts from happening.
In case of critical Production alerts, the production support will receive an SMS,
on-call phone or email. These alerts are monitored on a 24x7 basis.
The Supplier should implement
Borrower/Recipient Portal Platform.
22-SPT-SP-10

equivalent

monitoring

for

the

Database and Filesystem Backup Policies


IFAD policies for Production and Pre-Production systems are detailed here. The
Supplier shall choose the appropriate set of procedures to ensure that backup
and disaster recovery restoration requirements detailed here are met or
exceeded.
Filesystem Server Backup:

Baseline backup once, first time

Daily backup incremental

Weekly backup full server backup

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

Monthly backup full server backup

Retention daily backup (60 days); monthly backup (5 years)

Database Backup:

Full database backup - daily

Transaction log backup - every 4 hours (Production only)

Retention daily backup (60 days); monthly backup (5 years)

Recovery possible to any point in time in the previous retention period

Long Term Backup:

full backup performed monthly on 1st of each month, retained 5 years


(Production only)

full backup performed yearly on 1st of January, retained 10 years


(Production only)

recovery possible to any of the backup run dates

long term recovery of backups are not guaranteed to run on the current
software versions or hardware infrastructure

Backups for Disaster Recovery:


Backup files are replicated hourly from the IFAD Data Centre (DC) to the IFAD
Disaster Recovery Center (DRC) using file system synchronization.
The standby database is synchronized in real time from DC to the DRC using
Oracle Data Guard.
Database Recovery
In the case that a database recovery is required, it will be completed within 4
hours. This is based on current largest database size of roughly 200gb, and may
increase as the databases grow. A maximum of 4 hours data loss for production
databases and maximum 24 hours data loss for Pre-Production databases can
occur.
Failover and Disaster Recovery
A failover to the DRC shall be within 4 hours when the Portal in the IFAD DC
becomes unavailable and a decision to failover to DRC is made.
When a failover is not possible and a disaster is officially declared and disaster
recovery procedures are invoked, the system shall be made available from the
DRC environment within 24 hours with a maximum of 4 hours data loss.
The exact mechanism for backing up the databases may change. Oracle offers a
wide range of techniques for preserving data in Oracle databases.
The Supplier shall choose the appropriate set of procedures to ensure that the
above disaster recovery restoration requirements are met or exceeded.
22-SPT-SP-11

Incident Management
Incident management requirements are detailed under Application Hotline and
Warranty Service.

53

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

22-SPT-SP-12

Disaster Recovery Testing


Replication from Production to Disaster Recovery site is done by Oracle Data
Guard over a shared leased line between the IFAD DC and the DRC.
Disaster Recovery Test Procedures
Tests should be conducted based on IFAD DR Standard Operating Procedures.
Tests should be conducted regularly, at least yearly. The integrity of the DR
systems cannot be verified without regular DR tests.
Test Times
Disaster recovery tests should be conducted during normal office hours. Tests
to be carried out during weekends or official IFAD holidays will require prior
agreement from IFAD management and may incur additional costs.
One months notice in writing is required prior to carrying out Disaster
Recovery tests unless otherwise agreed by IFAD. The Supplier should indicate
the estimated duration of the test and IFAD will send a confirmation of the test
schedule.
Two weeks notice in writing is required identifying the precise time and scope
of the test, and for any additional resources required.
Disaster Recovery Invocation
IFAD will nominate a number of staff who are authorised to invoke disaster
recovery and keep this list up to date. Procedures for this, and for disaster
invocation, are contained in a separate document entitled Disaster Recovery
Authorisation List and Procedures which will be maintained by IFAD.

22-SPT-SP-13

The Supplier shall provide maintenance and support services for all instances of
the Portal, including development, test, UAT, training, support and of course
the production instances in the primary and disaster recovery data centers.
The Supplier shall refresh data in the various instances on a schedule to the
agreed with the Purchaser. For example, after system go live, the "support"
instance is expected to be refreshed with data from production at least on a
weekly basis (this allows for easier trouble shooting of production issues).

22-SPT-SP-14

Audit support: The Portal is subject to audit by IFAD's internal and external
auditors. The Supplier shall provide system logs, proof of backups, and other
artifacts requested by the auditors.

54

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

55

F. Title, Copyright and Use Rights


The IFAD General Terms and Conditions for the Procurement of Goods and the IFAD General Terms
and Conditions for the Procurement of Services will apply to the contract deriving from this RFP.
In addition, the following provisions shall apply to the contract deriving from this RFP:
a) All software, products and related materials produced, prepared or created by the
Contractor (i.e. Supplier) in the course of this contract, including the design, development
and implementation of the Borrower/Recipient Portal shall be the sole property of IFAD; and
b) IFAD shall have the right to use or dispose of any licensed software that forms part of the
Borrower/Recipient Portal solution to the full extent of the usage rights conferred by the
licensor, which shall include the right to use that product for other systems/applications
managed by IFAD.

G. Suppliers Experience Requirements and Client References


1.0

Suppliers experience is a key requirement and is defined below.

23-EXP-EX

Suppliers Experience and Client References

23-EXP-EX-01

The Supplier shall provide verifiable client information for their web application
implementation experience. While in the mandatory criteria the Supplier has to
provide a minimum of two successful contracts, the Supplier should provide
details of three to four client sites. Supplier shall provide (at the minimum) the
following information for each client site:

24-CLR
24-CLR-01

Name of the Suppliers client, Country and address


Contact name, phone, address
Year web application system was successfully completed
List of functional modules implemented
Hardware and system software
Approximate value of contract
Number of users
Client Reference Sites
The Purchaser will select two reference sites from the Supplier's client reference
list for verification. Purchaser will request the Supplier to facilitate client
reference contact for an interview, responses to a list of written questions and
site visits.

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

56

H. Hardware and Software requirements


IFAD will host the IT Infrastructure to support the Borrower/Recipient Portal at the IFAD Data Center
in Rome, Italy. An illustrative technical architecture is attached below that should inform the
suppliers choice of technology proposed and components that will be required.
IFAD has narrowed down the technology choices to the following two leading industry vendor
product lines:
3. IBM WebSphere
4. Oracle WebCenter
Supplier should ensure that their proposed solution covers web servers, application servers,
business process management, identity and access management, database software (Oracle
RDBMS), reporting tool, information security and integration with IFADs existing IT infrastructure
and systems, monitoring tools and provide for all components that will be needed to build and
support the application.

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

57

Hardware
The system shall run on dedicated hardware to be installed both in the IFAD Data Center (DC)
and in the Disaster Recovery Centre (DRC) sites. The Supplier is responsible for any customs
clearance requirements for the hardware.
The live system shall be installed on servers at both sites. The equipment at each site shall be
sufficient to run the entire production system should the other site become unavailable, but in
normal operation IFAD expects that the systems at the sites will be coupled in such a way that a
failure at any site will have no effect on the operation of the system. Bids must contain
recommendations as to how the sites will be equipped and coupled to enable the highest level
of availability.
Bids should also contain details of how suitable failover procedures will be developed and tested
to allow for situations of multiple failures or complete unavailability of one site.
The Supplier will be required to supply, install and test all hardware, system software,
middleware and any other products and equipment necessary to run the system.

25-HAR

Hardware

25-HAR-01

Hardware Sizing and Computing Performance:

a. The system shall support upto 4000 users from IFAD client countries and
internal IFAD users.

b. The system must support 1400 simultaneously logged on users of which 140

are estimated to be concurrent (zero think time) users. Concurrent user


testing shall be done using zero think time. The "time to render" for the
login page must be under 3 seconds considering 140 concurrent users. The
Supplier shall use a bandwidth of 512kbps and a latency of 300 milliseconds
to test Portal response times for end-user functions. Testing at IFAD Rome
with high bandwidth and low latency should show subsecond response
times for screen transaction processing. The Supplier shall provide a
performance testing plan which will be executed in a controlled
environment.

c. The system platform specifications shall provide sufficient processing and

capabilities to support the volume estimates for a period of five (5) years at
a 10% annual growth rate.

d. The requirement for data retention for the Portal is the close of financing

plus five years for a project financing. The average length of a project is
around seven years. For this contract, the supplier shall provide storage for
a period of twelve years for all instances (production, test etc) of the Portal.

e. The system must be configured to process the expected workload in terms


of throughput capacity and response times, making due allowance for peaks
in transaction volumes.

f. Document storage: The official repository for documents submitted through


the Portal are existing IFAD document and records management systems.
The Portal shall manage the transient storage of documents and caching

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

58

requirements.

g. The hardware proposed shall have industry best practice warranties of at

least three years for parts and on-site labour. Please explain the rationale
for any lower warranty periods.

25-HAR-02

System Instances: The Borrower Portal is a critical system and shall have at a
minimum seven instances - Production, Development, Test, UAT Test, Support,
Training, and Disaster Recovery. All instances can be virtualized (e.g. with
VMWare).
As highlighted earlier, the Supplier shall provide maintenance and support
services for all instances of the Portal.

25-HAR-03

High Availability, Data Backup and Disaster Recovery:


a. The solution must have high levels of service availability which will be
assured through demonstration and rigorous testing.
b. High Availability must be available for web servers and app servers on
separate physical hardware, and for storage. Exclude Oracle RAC High
Availability option given license costs. High Availability is needed only for the
production system in the primary data center (DC).
c. The Suppliers solution must provide for full backup, recovery and restore
facilities for the database within the overall solution to enable complete
file/data restoration and recovery.
d. The database environment must support the capability for replication of the
database and libraries to the Disaster Recovery center.
e. Backup solution must provide the facility to back up data and application
software using modern tape back-up library technology.
f.

The system must be operationally resilient, with high levels of local recovery
supported by an appropriately configured back-up installation and a smooth
cut-over between the primary and disaster sites, and back again to the
primary site when service is restored.

g. A cutover from the primary to the disaster site must be possible within four
(4) hours.
25-HAR-04

Suppliers shall specify full details of all hardware elements recommended to


operate their proposed solution. All components of the system will be required
to operate without a need for upgrade for a period of at least three years from
operational acceptance and the hardware should be sized accordingly. The
hardware shall be from one of the leading manufacturers, with proven record of
hardware support in Rome. Hardware proposals shall include all related services.

25-HAR-05

Servers
The Supplier shall specify in detail all recommended server components, together
with any items necessary for connection to IFADs existing and planned
technology environment.
Suppliers shall describe any operating system options, version/variant, release
level, all additional and optional modules required, and (if desired) their
preferred option.

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

25-HAR-06

59

Data Storage
Bids must specify in detail the recommended data storage capacity and
equipment. This should be supported by sizing information on the capacity
required to hold all copies of the system database(s) and any other supporting
data, based on the current and forecast volumes given in these bid documents.
Bids should estimate storage needs for 12 years.
Other Hardware
Bids should include details of any other hardware required to implement their
solution, such as certificate servers, networking and security components such as
routers, firewalls, other security appliances, racks, etc.

25-HAR-07

Power and Rack Space


The Supplier should provide the power (amperage) and rack space requirements
for all the hardware to be installed in the IFAD Data Center (DC) and the disaster
recovery center (DRC).

26-SWR

Supply, Licensing and installation of system software

26-SWR-01

Choice of technology platform


Supplier should provide a clear rationale for selecting a specific vendor amongst
IBM and Oracle for the IFAD Borrower/Recipient portal. The rationale shall
indicate alignment with strategic directions, supplier experience with using the
technology platform, cost basis and ease of use as a development environment.

26-SWR-02

System Software and Middleware


In addition to server operating system(s), Supplier shall clearly specify in detail
any other system software and middleware items that will be required to run the
system including Portal software, Business Process Management software,
Identify Management software, monitoring software, database management
software etc.
Other
Supplier shall include details of any other software that may be required, such as
a certificate server.
Database Software
IFAD standard is Oracle 12g and Supplier may propose an upgraded version.

26-SWR-03

Report Writer
Bids should describe standard easy-to-use database report generation tools that
can be used for the rapid development of reports to satisfy needs that might
arise on an ad hoc basis.
IFAD currently uses Oracle OBIEE as its standard reporting tool. If Supplier
proposes a different reporting solution, then IFAD prefers to use open source
reporting tools that provide drill-down capabilities and are not licensed per
named user but at the server level.

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

60

I. Implementation Schedule
The following is a proposed Implementation Schedule for the project. The Supplier shall complete
their assessment and propose their own Implementation Schedule. The Gantt chart shows a broad
schedule by year for implementation and support. The detailed task table shows key activities
during project implementation, for Phase 1, Phase 1.5 and Phase 2. The project kickoff is expected
to take place within four (4) weeks after the contract is signed or as agreed upon between the
supplier and purchaser at contract signing time. The proposed implementation schedule starts from
the project kickoff date.

Implementation Schedule Table


S.No
Activity

Start
(week
of)

End
(week of)

Overall Project

W1

W91

Project Management

W1

W91

1.1

Project Planning

W1

W3

1.2

Infrastructure (hardware) delivery W1


and setup in the IFAD data center
(DC)
Software delivery and installation, W6
configuration
development
instance, in the IFAD data center
(DC)
Software delivery and installation, W7
configuration test, production and
other instances, in the IFAD data
center (DC)

W5

W7

W12

Hardware
and
software W16
infrastructure set in the disaster
recovery centre (RDC)
Software design and development
Phase 1

W25

10

2.1

Confirmation of business and W1


technical requirements phase 1, 2

W3

2.2

User experience design and testing

W2

W5

2.2

System architecture definition

W1

W3

1.3

1.4

1.5
2

Elapsed Duration
(weeks)

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

2.3
2.4
2.5

System technical design including W2


integration specs
Develop Software requirements W3
specification Phase 1
Software development (including W7
unit testing) Phase 1

61

W5

W11

W24

18

3
3.1

Testing Phase 1
Test Plan Phase 1

W4

W5

3.2

Test case preparation Phase 1

W6

W19

14

3.2

Module and integration testing W17


cycles - Phase 1
System testing cycles Phase 1
W29

W28

12

W35

W36

3.4

Performance testing, Failover to W34


RDC testing Phase 1
Acceptance testing - Phase 1
W36

W42

Go live Phase 1

4.1

W38

11

4.2

Prepare documentation (technical, W28


end-user, operating instructions .)
Training IFAD business users
W38

W40

4.3

Go live plan Phase 1

W35

W40

4.4

Go live - Phase 1

W43

4.5

Operational Acceptance Phase 1

W51

4.6

Production warranty support W43


Phase 1

3.2
3.3

4.7
4.8

W51

Till end of
Warranty
support
System and application support W43
Till end of
Phase 1
support
contract
Add support for French and Spanish Specify Specify
and roll out to production. This will
have its own testing and user
acceptance
steps,
operational
acceptance and support contract.
Confirmation of requirements W35
W40
6
Phase 2

Software design and development


Phase 2

6.1

Develop Software requirements W41


specifications Phase 2

W48

6.2

Software development (including W49


unit testing) Phase 2

W64

16

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

62

Testing Phase 2

7.1

Test Plan Phase 2

W46

W48

7.2

Test case preparation Phase 2

W47

W60

14

7.3

Module and integration testing W55


Phase 2

W66

12

7.4

System testing cycles Phase 2

W67

W73

7.5

Performance testing Phase 2

W72

W74

7.6

Acceptance testing Phase 2

W75

W82

Go live Phase 2

8.1

W78

11

8.2

Prepare documentation (technical, W68


end-user, operating instructions)
Phase 2
Training IFAD business users
W78

W80

8.3

Go live Plan Phase 2

W77

W80

8.4

Go live Phase 2

W83

8.5

Warranty Support Phase 2

W83

8.6

Operational Acceptance - Phase 2

W91

8.7

System and application support W83


Phase 2

Lot 2,3,4 Services

9.1

Lot 3 - End-user helpdesk readiness W37


activities

W42

9.2

Lot 3 - End-user helpdesk services

9.3

Lot 4 - Rollout Support - planning, W38


training delivery and support

9.4

Lot 2 - Develop plan for Portal


access credentials provisioning

Till end of
Lot
3
contract
Till end of
Lot
4
contract
W8
4

9.5

Lot 2 Implement, Pilot and then W25

W43

W5

Till End of
Warranty
Support
W91
Till end of
Support
Contract.

Till end of

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

support
access
provisioning

credentials

Lot
2
contract

63

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

64

J. Required Format for Suppliers Response and Checklist


1.

Description of Information Technologies, Materials, Other Goods, and Services


The Supplier must provide detailed descriptions of the essential technical, performance, or
other relevant characteristics of all key Information Technologies, Materials, other Goods,
and Services offered in the bid (e.g., version, release, and model numbers). Without
providing sufficient clear detail, Suppliers run the risk of their bids being declared nonresponsive.
To assist in the bid evaluation, the detailed descriptions should be organized and cross
referenced in the same order as listed in the Technical Responsiveness Checklist below.

2.

Item-by-Item Commentary on the Technical Requirements


The Supplier must provide an item-by-item commentary on the Purchasers Technical
Requirements, demonstrating the substantial responsiveness of the overall design of the
System and the individual Information Technologies, Goods, and Services offered to those
Requirements.

3.

Preliminary Project Plan


The Supplier must prepare a Preliminary Project Plan describing, among other things, the
methods and human and material resources that the Supplier proposes to employ in the
design, management, coordination, and execution of all its responsibilities, if awarded the
Contract, as well as the estimated duration and completion date for each major activity. The
Preliminary Project Plan must also address the topics and points of emphasis specified in the
Supplier Services section. The Preliminary Project Plan should also state the Suppliers
assessment of the major responsibilities of the Purchaser and any other involved third
parties in System supply and installation, as well as the Supplierss proposed means for
coordinating activities by each of the involved parties to avoid delays or interference.

4.

Confirmation of Responsibility for Integration and Interoperability of Information


Technologies
The Supplier must submit a written confirmation that, if awarded the Contract, it shall
accept responsibility to ensure the application and infrastructure are properly integrated.

5.

Grouping of Supplier's response documents in the bid proposal


Please provide the response documents to the technical requirements in the following two
groups. Note that the cost proposal must be in a separate envelope.
Group 1: All the documents requested in Table 1 and Table 2 of the technical responsiveness
checklist, in the order they are listed in Table 1 and Table 2 (excluding of course the cost
proposal). Label each document as Table number - Item number (e.g. Table 1 - Item 2; Table
2 Item 3).
Group 2: All the documents addressing each item in Table 3, in the order they are listed in
Table 3. Label each document as Table number - Item number (e.g. Table 3 - Item 4; Table 3
Item 5).

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

65

Technical Responsiveness Checklist


The Supplier must complete the following tables in order to verify that all the RFP response
requirements have been completed as instructed.
Table 1
Item #

Document Name

Included in submission?

Price Schedules for Capital and Recurrent Costs,


separate from response
to
Technical
Requirements.

YES

NO

CMMI

YES

NO

List of Subcontractors, including their roles and


resource alignment with the project schedule.

YES

NO

YES

NO

(Attach Bill of Quantity for hardware to Cost


Proposal.)
2

Supplier's Quality certifications


Attach industry
Certification.

3
4

Reference
to Proposal
Response
Section

certifications

like

Confirmation of Responsibility for Integration


and Interoperability of Information
Technologies.
Attach a written confirmation that, if awarded
the Contract, the Supplier shall accept
responsibility to ensure the application and
infrastructure are properly integrated.

Mandatory Criteria Response Checklist


The supplier must complete the following table identifying all the documents supplied as part of the
mandatory criteria.
Table 2

Item #

Mandatory Criteria

Average Annual Turnover for the last three (3) years


of not less than fifty (50) million USD.
Attach audited financial statements for the last
three years and highlight the relevant numbers.

Meets Criteria and


included in
submission?

YES

NO

Reference to
Proposal
Response
Section

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

Item #
2

Mandatory Criteria

Access to liquidity financial resources such as bank


assets and lines of credit, etc. of at least two (2)
million USD.
Attach certified Bank statement indicating the
availability of the required liquidity.

During the past five (5) Years, the Supplier must


have completed at least two (2) successful contracts
worth over one (1) million USD each involving the
supply, implementation and support of a large-scale
secure, web-based application that supports over
3000 users across the internet and intranet.

66

Meets Criteria and


included in
submission?

YES

NO

YES

NO

YES

NO

Attach documentation on the two projects


completed, including a statement from the project
client/sponsor on the scope and implementation of
the project.
4

Minimum required experience of project manager.


The Project Manager must have a minimum of 10
years experience with at least two (2) successfully
completed projects of similar size as project manager.
At least five years of industry experience in a web
application
development/development
team
leadership capacity.
Attach CV of the project manager highlighting the
required experience.
The Supplier shall guarantee that this named project
manager will be assigned to the Lot 1 project.

Reference to
Proposal
Response
Section

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

Item #
5

67

Meets Criteria and


included in
submission?

Mandatory Criteria

Answer if Joint Venture: In the case of a Joint


Venture, the partner responsible for application
software development must be designated the lead
partner and the financial figures for all joint venture
partners shall be added together to determine the
Suppliers compliance with the minimum
qualification criteria for financial and technical
capability. For a Joint Venture to qualify, the lead
partner must meet at least 50 percent of the
financial capability (turnover and liquidity).
Each Joint Venture member must by itself have
completed at least two (2) successful contracts
involving exercise of the skills for which it has been
included in the Joint Venture, preferably concerning
the supply, implementation and support of a largescale web application of similar functional/technical
characteristics and of a comparable scale. The lead
partner must demonstrate at least one (1) successful
experience with a large scale web application
deployment.
For each partner attach
a) certified
documentation
turnover and liquidity;

indicating

b) documentation on at least two successful


contracts for the skills in scope;
For lead partner attach documentation on a large
scale web application that was successfully
implemented.
Attach documentation on how the financial
turnover and liquidity position of all partners
combined are enough to meet the mandatory
criteria.

YES

NO

Reference to
Proposal
Response
Section

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

Item #

68

Meets Criteria and


included in
submission?

Mandatory Criteria

Reference to
Proposal
Response
Section

Answer if Joint Venture:

Bids submitted by a Joint Venture of two or more firms as


partners shall also comply with the following
requirements:
(a) the bid shall be signed so as to be legally binding on
all partners;
(b) one of the partners shall be nominated as being lead
( in charge), and this nomination shall be evidenced
by submitting a power of attorney signed by legally
authorized signatories of all the partners;

YES

NO

(c) the partner in charge shall be authorized to incur


liabilities and receive instructions for and on behalf of
any and all partners of the Joint Venture, and the
entire execution of the Contract, including payment,
shall be done exclusively with the partner in charge;

Technical Requirements Supplier Response Checklist


The Supplier must complete the following table in order to verify that all the RFP responses to
detailed requirements have been completed as instructed. If a requirement is listed in multiple
rows in the table below, please cross-reference that item in your response. For example, ADR* lists
reporting which will be detailed under 5-CRP.
Table 3

Item #
1

Vendor Detailed Response Checklist


Completed and Provided
as Instructed??

Proposal Response Item

1-ADR Response
to
Application
Requirements , 1-ADR* (all ADR items).

Design

Provide documents detailing how the Supplier's


proposal addresses all ADR requirements.
2

NO

YES

NO

YES

NO

2-HDR High level design and system


architecture, including integration points.
Provide documents detailing how the Supplier's
proposal addresses HDR requirements.

YES

3-DDR Methodology and approach for Detailed


technical design by component.
Provide documents detailing how the Supplier's
proposal addresses DDR requirements.

Reference
to Proposal
Response
Section

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

Item #
4

Completed and Provided


as Instructed??

Proposal Response Item

4-GTR Response
to
general
requirements (low bandwidth ..)

technical

Provide documents detailing how the Supplier's


proposal addresses GTR requirements.
5

7-WAD Withdrawal
[Phase 1]

Application

YES

NO

YES

NO

YES

NO

YES

NO

YES

NO

YES

NO

YES

NO

YES

NO

processing

Provide documents detailing how the Supplier's


proposal addresses WAD requirements.
8

NO

6-ADC Access to key documents[Phase1]


Provide documents detailing how the Supplier's
proposal addresses ADC requirements.

YES

5-CRP Comprehensive reporting[Phase 1]


Provide documents detailing how the Supplier's
proposal addresses CRP requirements. Describe
how the proposal facilitates the use of tablets
and smartphones in the future.

69

8-MBI Manage Banking information [Phase 1].


Provide documents detailing how the Supplier's
proposal addresses MBI requirements.
Include advice on how to mitigate the risk of
cyber fraud for this function.

9-LNO Link to No Objection System [Phase 1]


Provide documents detailing how the Supplier's
proposal addresses LNO requirements.

10

10-SDC Submission of AWPB and


documents and workflow. [Phase 2]

other

Provide documents detailing how the Supplier's


proposal addresses SDC requirements.
11

11-RIMS Access to RIMS system [Phase 2]


Provide documents detailing how the Supplier's
proposal addresses RIMS access requirements.

12

12-LWA Integration of Withdrawal Application


system to other functions like AWPB. [Phase 2]
Provide documents detailing how the Supplier's
proposal addresses LWA requirements.

Reference
to Proposal
Response
Section

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

Item #
13

Proposal Response Item

13-CDB
Confirmation
conditions [Phase 2]

of

YES

NO

YES

NO

YES

NO

YES

NO

YES

NO

18-PMR Project Management, Implementation


Approach and Methodology, Project Plan,
Resourcing (including IFAD resources).
Provide documents detailing how the Supplier's
proposal addresses PMR requirements. Indicate
any subcontractor use.

19

NO

17-SAI Strategic alignment


Provide documents detailing how the Supplier's
proposal addresses SAI requirements.

18

YES

16-WAR Withdrawal Application Enhancements,


Reporting . [Phase 2]
Provide documents detailing how the Supplier's
proposal addresses WAR requirements.

17

NO

15-MSC Reallocation of categories, special


account changes [Phase 2]
Provide documents detailing how the Supplier's
proposal addresses MSC requirements.

16

YES

14-ARD Reference documents from B/R [Phase


2]
Provide documents detailing how the Supplier's
proposal addresses ARD requirements.

15

Completed and Provided


as Instructed??

disbursement

Provide documents detailing how the Supplier's


proposal addresses CDB requirements.
14

70

19-PMT Project Team qualification.


Attach CVs for the following key roles.
a) Two functional team leads
b) One senior technical architect
c) One senior application design and
development team lead
d) One senior infrastructure team lead.
Provide your approach to a cost effective
resource model using onsite/offshore resources.
The Supplier shall guarantee that these named
technical resources will be assigned to the Lot 1
project.

Reference
to Proposal
Response
Section

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

Item #
20

Proposal Response Item

YES

NO

YES

NO

YES

NO

YES

NO

YES

NO

YES

NO

21-TST Testing approach and methodology


Provide documents detailing how the Supplier's
proposal addresses TST requirements.

22

Completed and Provided


as Instructed??

20-TRM Training approach and methodology


Provide documents detailing how the Supplier's
proposal addresses TRM requirements.

21

71

22-SPT Approach and methodology for


application support and IT infrastructure
support.
Provide documents detailing how the Supplier's
proposal addresses SPT requirements including
the SLA and system availability.
Provide profiles for the composition of the
onsite support team

23

23-EXP Supplier's experience


Under mandatory criteria Supplier provided
information on two projects. Provide
information on an additional one or two
projects.

24

24-CLR Client references


The purchaser will contact two projects from the
supplier's list for verification. Provide any
information that will helpful to the purchaser in
getting feedback from the client including client
preferences.

25

25-HAR Sizing, Supply and Installation of


hardware, high availability, backup, disaster
recovery.
Indicate type of hardware, capacity, proposed
use, power requirements, physical space
requirements, ..
Provide documents detailing how the Supplier's
proposal addresses HAR requirements. Attach
Bill of Quantity for hardware to Cost Proposal.

Reference
to Proposal
Response
Section

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

Item #
26

Proposal Response Item

Completed and Provided


as Instructed??

Reference
to Proposal
Response
Section

26-SWR Supply, Licensing and installation.


Provide documents detailing how the Supplier's
proposal addresses SWR requirements.
Provide a clear rationale for the selection of the
product line from IBM or Oracle (note that for
the RDBMS Oracle is the IFAD standard).

27

72

YES

NO

YES

NO

27-LAN Language support for Spanish, French in


Phase 1.5. [Indicate cost separately in cost
table.]
Describe the approach and methodology to
adding Spanish and French support to the Portal.
Describe the design considerations for
accommodating right to left languages like
Arabic.
Describe the effort for adding Arabic support to
the Portal after Lot 1 Phase 2, and provide the
related cost as a separate line item in the cost
table.

Annex 1-Site Table


IFAD Rome
Site
Code

Site

City / Town / Region

Primary Contact Phone and Street


Address

IFAD

The International
Fund for Agricultural
Development (IFAD)
is a specialized
agency of the United
Nations with its
Headquarters in
Rome, Via Paolo di
Dono 44, 00142
Rome, Italy.

Rome, Italy

Tel:+39-0654591
Fax:+39-065043463
Via Paolo di Dono 44, 00142 Rome,
Italy.

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

73

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

74

Annex 2- Holidays and Other Non-Working Days:


Supplier must pay due regard to all recognized festivals, official holidays, and religious or other
customs, and all local laws and regulations pertaining to the employment of labor and factor this in
the implementation schedule.
IFAD works a Monday through Friday weekly schedule.
In accordance with chapter 4, para 4.3.3 of the Human Resources Implementing Procedures and
after consultation with the Executive Committee of the Staff Association, IFAD will observe the
following ten official holidays in 2015:
Thursday

1 January

New Years Day

Friday

2 January

Presidential Holiday

Friday

3 April

Good Friday

Monday

6 April

Easter Monday

Friday

1 May

Labour Day

Tuesday

2 June

Festa della Repubblica Italiana

Friday

17 July

In lieu of Eid Al-Fitr* (Saturday, 18 July)

Friday

14 August

In lieu of Ferragosto Public Holiday (Saturday,


15 August)

Wednesday

23 September

Eid Al-Adha*

Friday

25 December

Christmas Day

Monday

28 December

In lieu of Boxing Day (Saturday, 26 December)

The official holidays in 2016 will be available only in December 2015.

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

75

Annex 3 - Volume - Estimates of number of users


Financing to countries
As part of the LGS2 project it is necessary to estimate the number of users of the system. The various
user profiles which are being proposed are as follows together with a suggested number of users to
consider:
Role

Assumption

Borrowers/Recipients
Viewer

5 per country;

Borrowers/Recipients
Author

2 per project for 50% of projects

Borrowers/Recipients
Authorizer

2 per project for 50% of projects

Uploader

Number of Finance Assistants

Validator

Number of Finance Assistants

Reviewer - IFAD

Number of CPMs or Grant Managers

Approver

Number of Finance Officers

Viewer - IFAD

For each user in IFAD (to include CPMS,


ICOs, Management). 600

Administrator - IFAD

Administrator
Borrower/recipient

2 per country

5 per project
8 per project for 50% of projects
8 per project for 50% of projects

It is recognised that the requirements of each country and/or project with respect to access will be
different: some projects may have very decentralised operations with multiple implementing units
each requiring access, whereas some projects may be centralised with one PMU with limited
staffing. An analysis was performed of the current4 financing to countries (i.e. excluding non-country
grants).
There will be a gradual rollout of the Portal to users. Initially the Portal will be made accessible to
those countries with which consultations on the Portal are taking place and or countries where
electronic/advanced pilots are already successfully in place. These total approximately 10 -15
countries.
Total

Pilot

No of countries (ministries)

145

15

No of financings

377

96

No of projects

223

53

Current was defined to be any financing which had a closing date after 31/12/16 on the basis that the portal
would probably not be rolled out to projects which were close to closure, hence a cut-off date of 18
months (rounded to the end of the year) was taken.

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

Role

Assumption

Borrowers/Recipients
Viewer

5 per country;

Borrowers/Recipients
Author

2 per project for 50% of


projects

76

Total

Pilot

1 840

340

1 115

106

1 115

106

5 per project

8 per project for 50% of


projects
Borrowers/Recipients
Authorizer

2 per project for 50% of


projects
8 per project for 50% of
projects

Uploader

Number of Finance Assistants

10

10

Validator

Number of Finance assistants

10

10

Reviewer - IFAD

Number of CPMs or Grant


Managers

290

30

Approver

Number of Finance Officers

15

15

Viewer - IFAD

For each user in IFAD (to


include CPMS, ICOs,
Management). 600

600

600

Administrator - IFAD

Administrator
Borrower/recipient

2 per country

290

30

Total
5,289
1,251
Using the estimated numbers for roles above and assuming that there is one CPM per country, the
total number of roles for the Portal for country loans and grants is at least 5,000. Given the phasing
of the functionality, it is expected that there will be approximately 1,200 roles required in the first
phase of the rollout. It is to be recognised that there is a certain amount of overlap in that users may
have multiple roles. Taking this into account, the users for IFAD are expected to be no more than
600. The overlap for countries and projects is less straight-forward to estimate, however a
reasonable assumption is that half of the viewers at the B/R level will also have access as an Author
or Authorizer i.e. an overlap of approximately 1,000 (of which approximately 170 for the initial
rollout).
Non-country grants
Given the vast number of non-country grant recipients and in consideration that many recipients
only receive one grant from IFAD, it has been decided to limit the number of recipients given access
to the Portal to the top recipients plus the CGIAR centres. Applying the same assumptions as for
country financing will lead to an additional 600 external roles of the system and 100 internal roles
(mainly grant managers included in the calculation of 600).
Conclusion
For estimation purposes, on the basis of the above assumptions, it is reasonable to expect that the
Portal will be used by approximately 4,3005 4,800 users of which approximately 600 will be internal
and approximately 1,0006 will be required in the initial rollout.

5,289-10-10-290-15-4-1,000+600 = 4.560

1,521-20-30-15-4-170=1,012

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

77

Assuming that 50% of the portfolio will use the Borrower Portal in the first two years after rollout,
the maximum number of non-IFAD Portal users are 4,800 * 0.5 = 2,400. So the maximum number of
Portal users expected in the first two years after Phase 1 rollout are 2,400 + 600 = 3,000. For license
costing purposes, we will use 4,000 users as the reference number.

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

78

Annex 4 - Volumes Size of Documents Uploaded into IFAD Borrower Portal

#
1

Withdrawal Application process

200 WA per month;


over 300 trxs in FX

Average =90
(could be up to
1,500)

scanned
document

AWPB

up to 100

Contract Management - Form C11


-contract monitoring form with
upload of scanned contract,
amendments, bank guarantees

550 per year (45 per


month)
unknown

excel, word,
pdf
scanned
document

Recovery schedule

Banking information

90 per year (7 per


month)
24 per month

Confirmation of disbursement
conditions - for the project to be
able to submit all documentation
and to allow easy reference

395 for 17 months (23


per month) of which
172 investment
projects (10 per month)

20

Reallocation of categories submission of request and


workflow for approval
Request for extension of
completion date - submission of
request and workflow for approval
Increase/decrease in special
account allocation - submission of
request and workflow for approval
Submission of Procurement Plan
and bid documents *

128 for 19.5 months


(6.6 per month)

10-20

23 for 17 months (1.3


per month)

10-20

scanned
document

46 for 17 months (2.7


per month)

10-20

scanned
document

unknown - hence
estimated at > 20 per
month
650 (2 documents for
250 projects plus 1
document for 150 noncountry grants)
400 - 5,000 (1-10
documents for 250
projects plus 1
document for 150 non-

up to 100

scanned
document

20-30

pdf

up to 10

scanned
document

8
9
10

Requirement

(Main Transaction
measured

Average size of
volume document
(pages)
Comment

Business
Process)

11

Access to reference documents financing agreement, Letter to the


Borrower

12

Access to reference documents Signatories

up to 100 for
main contract;
amendments
and bank
guarantees 20 pages
1
2

excel
scanned
document
and excel
Multiple pdf
documents
may be
submitted up to 10
scanned
document

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

79

country grants)

13

Access to reference documents Supervision reports, Design


reports **

This covers:

1-2 supn per project


per yr: 240 projects:
20-40 p.m. plus design

200-400 pages

pdf

Procurement plan: up to 10 pages


Terms of reference: 20 pages
List of vendors: 1-2 pages
Recommendation of contract committee: 2-4 pages
Contract: up to 100 pages
**

This covers:
Supervision reports and mid term review: 40-80 pages Design reports: 200-400 pages

Lot 1 Borrower/Recipient Portal Technical Requirements (Aug 21)

80

Appendix 1 Submission of WA (detail description)


eSubmission of Withdrawal Application
Borrower/Recipient

Start

IFAD

Start

Start

Data from
database in
portal

Data from
Flexcube

Not approved

Author
Manually inserts
data in Form 100
and optionally
subsidiary forms
Amends forms if
released by IFAD
Scanned documents
uploaded
System validations
of data inserted
Submits for
approval
Notification form
created
1.5.3, 1.6 and 1.8

Authorizer
Review form and
verify no
modification of
documents or
information
Approve
1.13

Data from
GARTS

Receiver
Receives Hard
copy - WA
Creates
scanned
document

System
Routes to IFAD resource based upon:
1. Borrower or Recipient
2. Risk assigned to financing
3. Type of withdrawal application
4. Materiality
5. Alert messages

Submitted
Routing 1

Uploader
Receives scanned
document
Captures data
automatically and
populates Form 100
Attaches scanned
document
System validations
of data inserted
Notification form
created
Review and submit
for processing
1.6, 1.8 and 1.13

Routing of WA can be one of:


1. to CPM and FA for review
2. to CPM and FO for approval
3. Direct to FX (Straight
through processing)

Submitted

Uploader

Approved
Validator (FA)

Receives SWIFT
message from CI
Manually inserts
data in Form 100
Attaches scanned
document
System validations
of data inserted
Notification form
created
Review and submit
for processing
1.7, 1.8 and 1.13

Reviews Notification
in accordance with
RBD requirements
Reduces amount
claimed if required
(ineligible
expenditure)
Inserts comment if
required
Releases Form 100
for modification
Validate or reject
1.19

Request routed to
RMS for storage
1.23

Reviews notification form


and either subsidiary
forms or scanned
documents
Depending on risk rating
may be required to
approve
1.16

End

Routing 2

Validate

Reviews Notification
in accordance with
RBD requirements
Inserts comment if
required
Approve or Reject
Releases Form 100
for modification
1.19

Reject or open for recycling

Approver (FO) may be 2


see 1.21

Ineligible
expenditure
data to FMA
1.16 and 1.19

End

Request routed to
RMS for storage
1.23
End

Reviews notification form


and either subsidiary
forms or scanned
documents
Depending on risk rating
may be required to
approve
1.16

No

Approve?

Approve?

Approve?

Yes

Yes

Reviewer (CPM)

Reviews Notification
in accordance with
RBD requirements
Inserts comment if
required
Approve or Reject
Releases Form 100
for modification
1.19

No
No

No

Yes

Routing 3

1.15, 1.16, 1.17 and 1.18

Reviewer (CPM)

Approver (FO) may be 2


see 1.21

Data from
People/
GRIPS

Data from
FMA

Yes

Approved
transaction
created in FX
1.24

Ineligible
expenditure
data to FMA
1.16 and 1.19

End

End

Request routed to
RMS for storage
1.23
End

Approve?
Yes

Yes

Approved
transaction
created in FX
1.24

End

Approved
transaction
created in FX
1.24

End

Section VI. Technical Requirements

81

Appendix 1 Submission of WA (detail description)


1.1. e-Submission of withdrawal applications detailed requirements
1.2. Background
e-Submission of withdrawal applications allows the Borrower or Recipient (B/R) of IFAD financing to
submit electronically a request for payment. Basic validations on the data which are currently
performed by Flexcube will be replicated within the portal. The portal will contain workflow
functionality at the B/R level to allow the withdrawal application to be approved electronically and
be submitted to IFAD. Once submitted to IFAD a second workflow will route the WA for review and
approval, depending on data such as risk categories and SOE thresholds, to the relevant people
within IFAD. The review of the validity of the WA will take place within the designated workflow and
once approved the data will be interfaced to Flexcube and the relevant transaction will be created in
Flexcube for approval by the relevant person (centralized processing may be used). At all stages of
the process, it should be possible for users (B/R, CPM, CFS) to have information on the status of the
request be this by access to a screen or by notifications.
1.3. Features
1.4. WA submission options
In recognition of the different capacities of the Borrowers and Recipients of IFAD, there will be
different options for the submission of a withdrawal application.
1.4.1.Options
There will be 2 options available for the submission of a Withdrawal Application:

Through the portal


Not through the portal

Paper

Scanned

Where the WA is submitted through the portal, information on WA (Form 100) with
option for Forms 101, 102, 104 and 105 in phase 2) will be inserted into the portal and
scanned additional forms and supporting documentation will be uploaded. Application is
approved online and submitted to IFAD for processing
Where the WA is not submitted through the portal, Form 100 will be inserted by IFAD
staff and the scanned additional forms and supporting documentation will be uploaded
to the system by IFAD staff.
Given that the portal will be a secure site with access being limited to authorized persons
only with cross-validations to initiate access, the submission of scanned forms will be
accepted.
1.4.2.Current forms
IFAD will design the portal input pages to be in line with the forms below:

Section VI. Technical Requirements

82

Appendix 1 Submission of WA (detail description)


Form 100 online approval - mandatory
Summary sheet scanned version uploaded (phase 1) or data input into specific forms in
system (phase 2)
Form 101 scanned version uploaded (phase 1) or data input into specific forms in system
(phase 2)
Form 102 - SOE Rural Finance - scanned version uploaded (phase 1) or data input into
specific forms in system (phase 2)
Form 102 - SOE Goods works and services - scanned version uploaded (phase 1) or data
input into specific forms in system (phase 2)
Form 104 there are 2 forms which could be used Form 104/A or Form 104/B. Form 104/A
is Designated Account (reconciliation for imprest account) and Form 104/B is Designated
Account Reconciliation Statement (Revolving Fund) - scanned version uploaded (phase 1)
or data input into specific forms in system (phase 2)
Form 105 Checklist - scanned version uploaded (phase 1) or data input into specific forms
in system (phase 2)
Form C10 Register of contracts scanned version uploaded
Form C11 Contract Payment Monitoring Form scanned version uploaded (phase 1) or to
be considered in contract monitoring section of portal (phase 2)
For all those forms where submission can be by input into specific forms, functionality has to be
available to upload from excel into the system. (Phase 2)
1.5. Input screen for external user (B/R) for online approval
7

1.5.1.Header search function


Title

Options

Comments
The options available
will depend upon the
access of the user and
will need to be defined
by the countries. All
options
should
be
available to make the
access as wide or
restricted as necessary

Borrower or Recipient

Country Name
PMU
Implementing Agency
Recipient

Financing Type

Status

Project

All or drop down list of


options from Attachment
1
All or drop down list
from Attachment 1
All or drop down list To check with users if
from Attachment 1
they require name or
(alternate)
account
number (expect name)

A = Standing data dependent on access


S = Standing data
I = Data to be input by maker
C = Calculated by the system

Section VI. Technical Requirements

83

Appendix 1 Submission of WA (detail description)


S

Funding source

All or drop down list To check with users if


from Attachment 1
needed
S Financing number
All or drop down list
(FX Account number)
from Attachment 1
Brings back following data for each project with the projects shown as a list with the possibility to
click on a link and open the form for withdrawal applications. The data will be presented in tabular
format

Section VI. Technical Requirements

84

Appendix 1 Submission of WA (detail description)


Borrower or Recipient: xxxxxxxxxxxxxx
Project
name

Project Number
Financing
Number

ABCDE

1447

Alternate
Account
Number

Ccy

Financing
Amount

Financing Type

Status

Disbursable
Date

Closing date

Completion
date

Disbursed
amount

Undisbursed
amount

Percentage
disbursed

100000363100

123

SDR

19 600 000.00

LOANS

Disbursable

21/03/2011

30/09/2018

31/03/2018

4 896 299.21

14 703 700.79

16.50%

100000447900

123-B

SDR

8 450 000.00

LOANS

Signed

8 450 000.00

0.00%

100000363200

456-

SDR

630 000.00

LOAN
COMPONENT
GRANTS

Disbursable

74 272.70

555 727.30

11.80%

100000448000

456-B

SDR

650 000.00

LOAN
COMPONENT
GRANTS

Signed

650,000.00

0.00%

SDR

39 330 000.00

4 970 571.91

33 709 428.09

12.64%

2,498,601.63

75.14%

Total
ABCDE

30/09/2018

31/03/2018

100000274900

789-

SDR

10 050 000.00

LOANS

Disbursable

26/06/2008

30/09/2017

31/03/2017

7 551 398.37

100000275000

910-

SDR

635 000.00

LOAN
COMPONENT
GRANTS

Disbursable

09/07/2008

30/09/2017

31/03/2017

635 000.00

SDR

10 685 000.00

100.00%

8 186 398.37

0.00

76.62%

1571
100000415000

124

SDR

44 140 000.00

LOANS

Disbursable

12/11/2014

31/12/2020

30/06/2020

1 707 159.26

42 432 840.74

3.87%

100000415100

126

SDR

630 000.00

LOAN
COMPONENT
GRANTS

Disbursable

12/11/2014

31/12/2020

30/06/2020

128 161.27

501 838.73

20.34%

SDR

44 770 000.00

1 835 320.53

501 838.73

4.10%

SDR

3 380 000.00

ASAP GRANT

Enter
Force

into

31/12/2023

30/06/2023

3 380 000.00

0.00%

SDR

950 000.00

LOAN
COMPONENT
GRANTS

Enter
Force

into

31/12/2023

30/06/2023

950 000.00

0.00%

Total
ABCDE

21/03/2011

1376

Total
ABCDE

Date: As at 25/5/15

110000174500

200000095000

200000095000

Section VI. Technical Requirements

85

Appendix 1 Submission of WA (detail description)


Total

SDR

4 330 000.00

0.00

950 000.00

0.00%

The selection of one of the data rows should give the user the option to select the Form 100 or subsidiary forms for input of data.
It will be possible to submit the WA at any of the following levels:
At the project level with percentage split by financing
At the financing level
At the financing level by implementer
Intuitively the PMU will focus on the actual bank accounts and request WA to the bank account. If one bank account is used for multiple financing instruments, it is probable that one
WA would be submitted with allocation to the different instruments.

Section VI. Technical Requirements

86

Appendix 1 Submission of WA (detail description)


Depending on the status of the financing, if the B/R selects a particular form a warning message will
be displayed. If the financing has a status of APPR, CANC, CLSD, PAID or SIGN the following message
should be given:
IFAD does not currently accept withdrawal applications against this financing. Please contact the
help-desk for assistance or click on the help box
1.5.2.Advances for start-up costs
For some projects, IFAD may provide advances for the start-up of the project. The financing will not
be in DSBL status. If the financing has a status of ENTF, the B/R can submit the request for an
Advance for Start-up costs. This is the only request which can be submitted when in ENTF status.
Note: the process for IFAD would be that once the request for start-up costs has been received, the
FA would change the status to DSBL, FO would approve and the request would be reviewed and
processed.
1.5.3.Withdrawal application form (Form 100)
The following explains the information to be submitted in order to complete Form 100.
Box name

Description

Comment

Application type

Drop down list with choice of:

Results
based
disbursements are not
currently used in IFAD

Advance for start-up costs


Advance or initial deposit
Direct Payment
Reimbursement
(including
retroactive financing)
Replenishment
Justification or recovery
Results based disbursement

It should be possible to request more


than one application type e.g. Direct
payment and a replenishment. For each
of the types of application requested
the appropriate boxes listed below
should open for completion.

Justification

If Replenishment is selected a second


option should open to select whether
the replenishment will also be used for
justification of the advance or the
special account. If Yes, then user should
be able to input the amount for
justification

Bank account

Drop down list (see Attachment 1). if


more than one account available for the
financing and then populate Funding
Source.
Bank account details and relevant
correspondent bank information to be

Section VI. Technical Requirements

87

Appendix 1 Submission of WA (detail description)


retrieved from Flexcube for checking by
input person.
If the recipient is a CGIAR centre and
the grant passes through the IBRD trust
fund, Beneficiary Bank Name and
Address = IBRD TF, bank account
information is not to be shown to the
recipient.
I

Special Payment
Instructions

This field allows the B/R to insert


specific instructions and/or upload
specific scanned documents (e.g. OFAC
licence)

WA reference number

Sequential number

Application currency

Inserted by inputter

Application Amount

Inserted by inputter

S- Funding Source
I

If WA is submitted at the Project level


and there is more than one (FX) Account
for the project, each Account is
proposed to the initiator with the
message:
Please enter the amount or percentage
of the WA to be allocated to each
source of funding.
Not all financing sources have to be
selected by the initiator
If WA is submitted at the FX Account
level and there is more than one bank
account (i.e. where there are different
implementing parties and/or where
banking instructions are present for
direct payments), the initiator will select
the relevant bank account

Retroactive financing

The initiator will be given the choice of


being able to indicate if any of the
expenditure being claimed relates to
retroactive financing and if so the
period to which it relates
Yes or No and then if Yes
Date from
Date to

Training materials should


indicate that if there is one
bank account with multiple
types of financing, then the
WA should be submitted at
the project level.

Section VI. Technical Requirements

88

Appendix 1 Submission of WA (detail description)


I

Period of Application

Not applicable for advances to imprest System to only propose this


account, Direct payment, Advance for if the WA is
start-up costs or Results based
An advance payment;
disbursement
Reimbursement
Date from
Replenishment
Justification
Date to

Source of supply

This should be a picklist of countries.


With the option to select country for a
single item of expenditure, in
percentage and/or all remaining. The
default for each B/R should be the
country of the B/R.

Generally in inputting WA
into FX, FA will chose the
country in which the
project
is
being
implemented.
Different
countries are only selected
for
direct
payments
(generally)
System only to propose this
if the WA is
Reimbursement
Replenishment
Justification
Direct Payment
If the WA is for an advance
the
default
will
be
Undetermined

Category allocation

For all Advance payments category


allocation will default to that of the
advance.
For:

Direct Payment
Reimbursement
Replenishment
Results based disbursement
New area to open:
Boxes to insert amounts for each
category. For each box a picklist of the
available categories should be available.
Not all categories will be required,
hence require possibility to have more
than one box.
System to total amount of categories
Error message if total of categories is
different to that of Application Amount.
Where WA is submitted at the project
level the category allocation has to be
for each Funding Source which has been

Section VI. Technical Requirements

89

Appendix 1 Submission of WA (detail description)


selected. If the split of the funding is on
a percentage basis, the initiator will be
required to insert the category details
for the 100% and the system will
automatically apply the relevant
percentage for the individual funding
sources.
For all financing except non-country
grants
For each category to have tick box for:
Includes amounts
threshold; and

less

than

SOE

Includes amounts more than SOE


threshold
Phase 2:
Depending on the boxes ticked the
Summary Form in Section 1.28 will
include Form 101 and/or Form 102
section to be compiled. (Form 101 >
SOE, Form 102 < SOE).
I

Mode of submission of
SOE

Tick box for selection of how SOE will be


submitted:
(Phase 1) Scanned documentation
(Phase 2) eForms
If eForms is selected new input screens
to open. (see Section 1.28)

Scanned
documentation

Area where scanned documentation can


be uploaded for the individual
withdrawal application with specific
boxes for:
Summary of expenditure
Form 101
Form 102
Form 104 (Special account/advance
account reconciliation)
Form 105
Form C10
Form C11
Bank reconciliation and bank
statement
Supporting documentation
Following confirmations to be included with tickbox for each Approver
If the WA relates to a IFAD financing to a country:

Section VI. Technical Requirements

90

Appendix 1 Submission of WA (detail description)


We hereby apply for withdrawal from the Loan/Grant Account opened under the IFAD Financing
Agreement and hereby certify as follows:
The undersigned has not previously withdrawn from the Loan/Grant Account to meet these expenditures and
has not and does not intend to obtain funds for this purpose out of the proceeds of any other
loan/grant/financing.

The goods and services covered by this application have been or are being purchased and/or procured in
accordance with the terms of the applicable General Conditions for Agricultural Development Financing.
The undersigned hereby certify that the expenditures for which replenishment is claimed under the statement
of expenditure (SOE) thresholds are correct for the Project as provided in the IFAD Financing Agreement. We
certify that these expenditures represent resources used in compliance with the principles of legality,
regularity and sound financial management. I certify that the audit requirement outlined in article VIII and
section 9.01 of the General Conditions will be complied with, and that the requirements for maintaining
records and documentation for expenditures disbursed using the Statement of Expenditure modality and
outlined in section 4.04(c) and (d) of the General Conditions, will be complied with. This includes, inter alia,
that an annual audit will be carried out and that the documentation (including purchase orders, invoices,
evidence of payment and delivery and any other relevant documentation evidencing the expenditures) will be
retained for 10 years after the Closing Date of the IFAD Financing, and that such records and documentation
will be made available to IFAD representatives for review on request.
The undersigned hereby certify that all the supporting documentation to this withdrawal application has been
submitted in accordance with the Letter to the Borrower and the Loan Disbursement Handbook

If the WA relates to a non-country grant:

We hereby apply for this withdrawal from the Grant Account and hereby certify and agree as follows:.
The funds covered by this application are required exclusively for the purposes of the Project.
The certified Statement of Expenditures provides detailed information on the utilisation of the immediately
preceding advance and confirms that the funs withdrawn have been exclusively used in accordance with the
Grant Agreement. All documentation authenticating these expenditures has been retained in accordance with
paragraph 6.13 of Schedule 6 of the Agreement (the above article does not apply for first withdrawal
application).

If the financing is funded by supplementary funds from the EC [Donor = EU}, following certification
is also required:
We hereby confirm that an electronic archiving system has been set up in order maintain all the accounting
documentation relating to the project and that this system will be maintained for at least ten years following
Project closure.

There should be the possibility for the B/R to upload scanned documentation (as noted in section
1.5.3 above, be it scanned forms 101, 102, 104, 105, C10 and C11 or scanned supporting
documentation.
1.5.4.Specific information to be requested depending upon type of disbursement request:
Disbursement request
Specific requirements
Advance payment imprest Box to be ticked:
account
Please confirm that the relevant AWPB has been approved by

Section VI. Technical Requirements

91

Appendix 1 Submission of WA (detail description)


[Validation check by system]

Fund and that all general and specific conditions precedent to


withdrawal as specified in the Financing Agreement have been
met before submitting your request

Advance payment revolving Box to be ticked:


fund first advance
Please confirm that the relevant AWPB has been approved by
[Validation check by system]
Fund and that all general and specific conditions precedent to
withdrawal as specified in the Financing or Grant Agreement
have been met before submitting your request
Advance payment revolving Warning Message:
fund subsequent advance
Please ensure that previous advances have been justified in
[Validation check by system]
accordance with the Financing or Grant Agreement or Letter to
the Borrower (ass applicable) before submitting your request
Direct Payment

New screen to open:


(Phase 2) Picklist for contract number (once contract part has
been implemented until then to insert contract number) or
New
If new contract, to provide number and option to upload.8
(Phase 1)
Purchase order number same as for contract number ;
Currency of payment
Amount
Description of Goods, Works or Services
Invoice numbers
Net amount of invoices covered by application
Checklist of items to be uploaded and possibility to upload:
Bank guarantee for advance payments see comments on
contracts
Bank performance guarantee
IFAD no- objection
Suppliers invoice duly certified by project director
Certificate of delivery or certification of adequate services
being rendered
For progress/retention payments:
Claim of the contractor including a financial progress report
Certification that the work performed is satisfactory and that
payment claimed is due
Contract payment monitoring form (see comments on
contracts)

Category greater than SOE

Space to upload scanned SOE.


Phase 2
Form to insert information on SOE See attached SOE
Both phases
Scanned supporting documentation to be attached.

See Contract management requirements

Section VI. Technical Requirements

92

Appendix 1 Submission of WA (detail description)


Checklist of items to be uploaded and possibility to upload:
Bank guarantee for advance payments see comments on
contracts
Bank performance guarantee
IFAD no- objection
Evidence of payment;
Suppliers invoice duly certified by project director
Certificate of delivery or certification of adequate services
being rendered
For progress/retention payments:
Claim of the contractor including a financial progress report
Certification that the work performed is satisfactory and that
payment claimed is due
Contract payment monitoring form (see comments on
contracts)

1.6. Input screen for FA where paper WA submitted


Where the B/R submits paper WA the FA (or centralised processing unit) will be required to insert
the data on the paper WA into the eSubmission system instead of into FX as this will be necessary to
take advantage of the logic within the workflow. All the relevant fields specified in 1.5.3 above will
be available for the FA to insert information from the scanned form, except for the confirmations.
Section 1.5.4 will not be relevant for a paper WA. Alternately the information on the scanned Form
100 will be captured automatically using character-recognition and an electronic Form 100 (eForm)
created. Optical Character Recognition is required for phase 2 of the portal.
The FA will review the eForm against the scanned documentation, will correct where necessary and
then will submit the eForm.
1.7. Input screen for FA for projects where Cooperating Institution is used
Where a project is not directly supervised by IFAD i.e. review of Withdrawal Applications is
performed by a Cooperating Institution, the information submitted by the CI will need to be inserted
in the eSubmission system by IFAD staff. All the relevant fields specified in 1.5.3 above will be
available for the FA to insert information from the swift message, except for the confirmations.
Section 1.5.4 will not be relevant for a WA from a CI. The system validations at 7.8 upon submission
will not be activated for this kind of request. There will be no routing to CPM and the next step in the
process will be the creation of the form and the validations at 1.15. Projects which will follow this
process can be identified from the User-defined field: Cooperating Institution in Flexcube. If this field
contains a value then this process will be followed.
1.8. System validations of withdrawal application request
a. Validates that the requested amount of the WA converted into denomination currency
(SDR/USD/EUR) is not greater than the available balance of the financing. The system
blocks the disbursement in case the available loan/grant amount is exceeded. Warning
message
The amount requested exceeds the remaining balance in your account by SDR xxx.
Please reduce the amount being requested or contact the Help-desk
b. Checks that the total of all Categories =total of WA

Section VI. Technical Requirements

93

Appendix 1 Submission of WA (detail description)


c. Validates the total of source of supply is equal to 100%
d. Displays warnings/overrides where:

Categories are overdrawn


Warning: Please note Category xxx is overdrawn by x%. Click Continue if you wish to
proceed with the application; Save if you wish to review further or submit a request for
reallocation or Cancel if you wish to withdraw the request

% justification (for advance account) is less than the % amount set-up. The
percentage to be justified is included as standing data in FX for each
advance account. Where the field is null, this check is not required.

Warning: The advances have not been sufficiently justified to allow the payment of a
subsequent advance. Click Continue if you wish to proceed, Save if you wish to complete
the application later or Cancel if you wish to withdraw the request

Alerts in case the balance in the loan account is less than 2 times the
outstanding initial deposit.

Warning: The balance in the loan account is less than 2 times the initial deposit. If you
have not already done so, you should submit a recovery plan to IFAD in order not to
delay future payments. Click Continue if you wish to proceed, Save if you wish to
complete the application later or Cancel if you wish to withdraw the request
e. If the WA is submitted and the balance in the loan account is less than 2 times the
outstanding initial deposit (for imprest account), notifications to FA/FO should include
The balance in the loan account is less than 2 times the outstanding initial deposit
f.

If the WA is for a revolving fund and the WA is less than 30% of the outstanding advance
or less than 50% of the AWPB, or if the WA is for an imprest account and the total amount
is less than the minimum withdrawal application amount AND the WA is not the final one:
Warning: the withdrawal application is for an amount less than the minimum amount
accepted by IFAD for this financing. Please refer to the Financing Agreement or Letter to the
Borrower for the minimum withdrawal applications which IFAD accepts. Click Save if you
wish to review further or Cancel if you wish to withdraw the request

g. Validates that in the case of replenishments, only categories linked to that special account
available for disbursement are used.
h. Checks for possible duplication of WA: if a WA has been submitted for the same period as
this WA and neither of the WA are direct payments
Warning: A withdrawal application has already been submitted for this period. Please
ensure that this is not a duplicate. Click Continue if you wish to proceed with the
application, Save if you wish to review further or Cancel if you wish to withdraw the
request
i.

Checks for possible duplication of WA: if a WA has already been submitted for the same
amount as this WA and neither of the WA are direct payments
Warning: A withdrawal application has already been submitted for the same amount.
Please ensure that this is not a duplicate. Click Continue if you wish to proceed with the

Section VI. Technical Requirements

94

Appendix 1 Submission of WA (detail description)


application, Save if you wish to review further or Cancel if you wish to withdraw the
request
j.

Checks for uniqueness of WA number - i.e. no duplicate WA numbers are accepted, hence
preventing double payments.
Error: This withdrawal application number has already been used. Please modify and
resubmit

k. Validates that in case of replenishments or advances, the system checks that the currency
used is the one defined for the special/advance account.
Error: The currency being requested for payment is different from that of the bank account.
Please amend and resubmit. Checks that the advance of the special account does not exceed
the defined ceiling of the special account.
Error: The amount requested is greater than the ceiling defined. Please amend and resubmit
l.

Validates that payee input instructions available for the payment are only the ones
maintained in the database.
m. Validates that for supplementary grants, the amount disbursed does not exceed the
amount received from the donor (as interfaced from PeopleSoft into FX). No error
message will be given to the B/R, however this should be noted on any notifications to
FA/FO for follow up
The amount being requested for payment exceeds the amount received from the
donor. Follow up is required
n. If there is a process for AWPB within the portal (defined in separate document) and the
WA is for an advance payment to a revolving fund, the system will check that there is an
approved AWPB for the period of the WA. Where there is no AWPB for the period of the
WA
Warning: Before any advance can be paid from this account the AWPB needs to be
submitted and approved. Please ensure the AWPB has been submitted and approved. Click
Continue if you wish to proceed with the application, Save if you wish to review further or
Cancel if you wish to withdraw the request
o. If the WA relates to a direct payment, a help/warning message should be given:
Please ensure that the currency of the direct payment is the same as that of the contract. If
it is not, the payment will be delayed
1.9. Cancellation or modification of a WA
The B/R should be able to withdraw (cancel) a request before it is submitted to IFAD with no
trace in the system. The B/R should be able to modify a WA before it is submitted to IFAD. IF
a WA has already been approved online, any modification made will require that the WA be
routed for approval at the B/R level again.
1.10.
Communication of issues to IFAD
a. The B/R has to have the possibility to be able to contact IFAD for assistance, hence there
should be an area where questions can be raised or a request be raised for the help-desk.

Section VI. Technical Requirements

95

Appendix 1 Submission of WA (detail description)


1.11.
Creation of Notification form for approval
Once the data has been input the system will create a notification type form for review: FORM 100 - APPLICATION FOR WITHDRAWAL
IFAD Loan/Grant/Financing No.:
xxxxxxxxxxxx
Application No.: x
Borrower/Recipient name
Account number
xxxxxx
Enter into Force
Project Name
xxxxxx
date
xx/xx/xx
Funding Source
xxxxxx
Completion date
xx/xx/xx
xxxxxx
Closing date
xx/xx/xx
To: International Fund for Agricultural Development (IFAD)
Via Paolo di Dono, 44
00142 Rome, Italy
Application Type

xxx

xxx
Amount to be Paid in Figures

As many types as B/R has


requested

xxx

xxx
Amount to be Justified in Figures

Withdrawal amount:

xxx

xxx

Currency Name

Total Amount in Figures

Payment Instruction
Payees Name and Address:
Xxx The payment instruction section is a list of values

Payees Bank

Correspondent Bank:

Name:
This will be populated from the LOV above xxx

xxx

Address:

(not required when using the Direct Payment procedure)

xxx
xxx

Account No.:

Special Payment Instructions and References:

xxx

xxx

Y/N
xx/xx/xx

Retroactive financing

xx/xx/xx

From (dd/mm/yy)

To
(dd/mm/yy)

Details of Expenditure
Category Summary

Number

xx

Description

xx

Currency

xx

Amount

xx

Source of
supply

%
financed
by IFAD

xx

xx

Section VI. Technical Requirements

96

Appendix 1 Submission of WA (detail description)


xx
xx
xx

xx
xx
xx

xx
xx
xx
TOTAL

xx
xx
xx
xx

xx
xx
xx

Documentation of Eligible Expenditure


Electronic Statement of Expenditure
Scanned Statement of Expenditure
Scanned documentation for
direct payment
Scanned supporting
documentation

xx
xx
xx

To include hyperlink to eSOE


Form 102 (Phase 2)
To include hyperlink to Scanned document
To include hyperlink to Scanned document

xx
xx

To include hyperlink to Scanned document

xx

For direct payments


Name and Address of Contractor or Supplier

Procurement Details

(If different from Payee)

a)

xxx

Contract or Purchase Order No. and Date:

xxx
b)

Description of Goods, Works or Services:

c)

Currency and Total Amount of Contract:

d)

Invoice Nos. and Net Amount of Invoices Covered by


this Application:

xxx
xxx
xxx
Certification for financing to a country

We hereby apply for withdrawal from the Loan/Grant Account opened under the IFAD Financing Agreement and hereby certify as follows:
A.

The undersigned has not previously withdrawn from the Loan/Grant Account to meet these expenditures and has not and does not intend
funds for this purpose out of the proceeds of any other loan/grant/financing.

B.

The goods and services covered by this application have been or are being purchased and/or procured in accordance with the terms of th
General Conditions for Agricultural Development Financing

C.

This Application for Withdrawal covers a reporting period:

D.

xx/xx/xx

xx/xx/xx

From (dd/mm/yy)

To (dd/mm/yy)

The undersigned hereby certify that the expenditures for which replenishment is claimed in Form 102
A and 102 B are correct, for the Project as provided in the IFAD Financing Agreement. We certify
that the expenditures incurred are within the statement of expenditure (SOE) thresholds and represent
resources used in compliance with the principles of legality, regularity and sound financial
management. We certify that the audit requirement outlined in article VIII and section 9.01 of the
General Conditions will be complied with, and that the requirements for maintaining records and
documentation for expenditures disbursed using the Statement of Expenditure (Form 102/A) modality
and outlined in section 4.04(c) and (d) of the General Conditions, will be complied with. This
includes, inter alia, that an annual audit will be carried out and that the documentation (including
purchase orders, invoices, evidence of payment and delivery and any other relevant documentation
evidencing the expenditures) will be retained for 10 years after the Closing Date of the IFAD
Financing, and that such records and documentation will be made available to IFAD representatives
for review on request.

Section VI. Technical Requirements

97

Appendix 1 Submission of WA (detail description)


E.

The undersigned hereby certify that all the supporting documentation to this withdrawal application has
been submitted in accordance with the Letter to the Borrower and the Loan Disbursement Handbook

Certification for non-country grants

We hereby apply for this withdrawal from the Grant Account and hereby certify and agree as follows:.

A. The funds covered by this application are required exclusively for the purposes of the Project.
B. The certified Statement of Expenditures provides detailed information on the utilisation of the immediately
preceding advance and confirms that the funs withdrawn have been exclusively used in accordance with
the Grant Agreement. All documentation authenticating these expenditures has been retained in
accordance with paragraph 6.13 of Schedule 6 of the Agreement (the above article does not apply for first
withdrawal application).

Additional certification for financing funded by EU


A. We hereby confirm that an electronic archiving system has been set up in order maintain all the accounting
documentation relating to the project and that this system will be maintained for at least ten years
following Project closure.

xxx

xx/xx/xx

Name of Borrower/Recipient

Date (DD/MM/YY)

xxx
Name(s) and Title(s) of Authorized Representative(s)

xxx
online approval (s) of Authorized Representative(s)

All sections will be populated from the information inserted by the initiator or from the standing
data. Only the fields with information will be included. Where the field is blank this will not show on
the notification. Where noted there will be hyperlinks either to scanned documentation to enable
any approver within the workflow to review the request and the supporting documentation.
It should also be possible to possible to print the form so that the authorised signatory for the B/R
can sign it and submit in hard copy to IFAD.
Where the form is approved electronically the names of the person approving should be captured.
Approval notifications will need to be maintained and fully accessible by IFAD staff for audit
purposes.
Where the WA is submitted at the level of project and there is more than one FX account associated
with the project and therefore the initiator will need to provide the allocation of the WA to the
different types of financing, the Notification will be modified to include the information on the
various accounts concerned see sample below. This will also be true for the notification to IFAD
staff.

Section VI. Technical Requirements

98

Appendix 1 Submission of WA (detail description)


Application Type

xxx

xxx

Total to be paid

Amount to be Paid in Figures

xxx

xxx

Total to be justified

Amount to be Justified in Figures

Withdrawal Amount
Split by funding source
Account number 1

xxx

xxx

Currency Name

Total Amount to be Paid in Figures

xxx

Total amount requested

xxx

Proportion for account 1

Amount to be Paid in Figures

xxx

xxx

Proportion for account 1

Amount to be Justified in Figures

Account number 2

xxx

xxx

Proportion for account 2

Amount to be Paid in Figures

xxx

xxx

Proportion for account 2

Amount to be Justified in Figures

Payment Instruction
Payees Name and Address:

xxx

Payees Bank

Correspondent Bank:
(not required when using the Direct Payment procedure)

Name:

xxx
xxx

Address:

xxx

xxx

Account No.:

Special Payment Instructions and References:

xxx
Retroactive financing

xxx

Y/N
xx/xx/xx

xx/xx/xx

From (dd/mm/yy)

To (dd/mm/yy)

Details of Expenditure
Category Summary

Number

Description

xx
xx
xx
xx

Currency

xx
xx
xx
xx

xx
xx
xx
xx
TOTAL
Documentation of Eligible Expenditure
Electronic Statement of Expenditure
Scanned Statement of Expenditure
Copies of records

Amount

xx
xx
xx
xx
xx
xx
xx
xx

Source of
supply

%
financed
by IFAD

Account number 1
allocation

Account
number 2
allocation

xx
xx
xx
xx

xx
xx
xx
xx

xx
xx
xx
xx

xx
xx
xx
xx

etc

To include hyperlink to eSOE


To include hyperlink to Scanned document
To include hyperlink to Scanned document

1.12.
List of notifications for review
At all stages in the process, once the notification is created, the users will have a list of outstanding
notifications to be reviewed.
1.13.

Workflow for approval of request

1.13.1. Approval of request online


Once the information has been uploaded to the system and all errors and inconsistencies
have been resolved, the initiator will submit the WA for approval. There may be multiple
steps within the approval process however the workflow will only cater for one final
approver. The final approval stage will include the submission to IFAD.
Once submitted it will not be possible for the WA to be changed by the B/R unless
specifically released by IFAD for amendment.

Section VI. Technical Requirements

99

Appendix 1 Submission of WA (detail description)


1.13.2. Approval of paper forms
Where online approval is not used, whoever initiates the input of the WA into the system
will also be able to Submit the WA to IFAD. The checking that the information inserted in
the system corresponds with that communicated by the B/R will take place during the
review of the WA in order not to duplicate work.

In the case where the Withdrawal Application has been submitted on paper, the
data will have been inserted/uploaded by a FA. The notification will be routed to
the FO for review and approval that the data inserted agrees with that on the
paper documents.
The FO or FA will have the possibility to reject the request back to the FA (hard
copy) with a comment box for communication to the FA

Withdrawal application number xxx for financing xxx has not been accepted by IFAD.
For further information, please see below
Comments
1.14.
Submission to IFAD in an internal review system
Once submitted to IFAD a series of notifications will be generated:
Time, date:
WA xx for project xxx, account number xxx has been submitted to IFAD for processing
To the following users: Finance Assistant, Finance Officer, CPM (if certification is to be
maintained) and to B/R.
For financing to a country the information on who to route the notification to can be
obtained from the Access/Identity management system and by reference to the country.
1.15.
IFAD users to be able to view and review information submitted in a user-friendly
manner
1.15.1. Form:
A sample form for presentation of the data is attached. It is envisaged that this information
be presented on one screen, possibly as a notification. In addition to the information made
available to the B/R the following information will be included:

Authorised allocation for Accounts which are Special Accounts (i.e. imprest
accounts)
Status (see 60 in Attachment 1)
Risk rating
Percentage of advance to be recovered for Accounts which have an Advance
account (for revolving fund only)
AWPB approved (for revolving fund only)
Amount of AWPB (for revolving fund only)
Period of AWPB (for revolving fund only)
Percentage of AWPB to be financed for revolving fund only
Ineligible expenditure pending
Status of funds (BI report)
SOE threshold for each category

Section VI. Technical Requirements

100

Appendix 1 Submission of WA (detail description)

Special conditions for payment

1.15.2. Warning messages


To be generated on the form depending on system checks performed:

For financing funded by external donors i.e. supplementary funds, system


checks that the amount allocated (Donor Amount) to the financing is more than
the amount being requested for disbursement. Where Product Code = SUPG:
Donor Amount - (Total Utilized Amount plus Current WA) >0

The amount being requested for payment exceeds the available amount of donor funds.
Follow up is required

For loans: compare the balance on the financing + current request for payment
to outstanding advance. If (balance on the financing + current request for
payment) < 2 * outstanding advance

The balance in the loan account is less than 2 times the outstanding initial deposit
For all financing: if current date closing date < 6 months
There are less than 6 months to completion date

For revolving fund accounts if withdrawal application is an advance payment


check if there are outstanding advances. If there are:

There are outstanding advances


If the flag for ineligible expenditure pending from the FM tool is set to Y then
This project has ineligible expenditure pending

If financing has Category where Category Description = Unallocated and


balance on Unallocated > 7% of total financing and current date completion
date< 1 year
Unallocated category more than 7% of financing and less than one year to project
completion
If current date closing date < 6 months
There are less than 6 months to closing date
If available balance less this WA per category <0
There are overdrawn categories in this financing
If WA is for an advance to a revolving fund (i.e. where category selected has
Category Type = ADV), the system needs to compare the relevant percentage of
the amount approved in the AWPB with the request for advance. The period of
the WA and the period of the AWPB should be compared in order to select the
correct AWPB amount. The relevant percentage of financing of the AWPB will be
applied to the AWPB amount and if the WA is greater :
The advance being requested exceeds the relevant percentage of the AWPB
Checks whether any of the Accounts for which a withdrawal application is being
submitted is suspended.
The financing for which the WA has been submitted is in Suspended status
The system should pick up (either from GARTS or from the FM tool) information
on whether the Audit Report has been submitted on a timely basis and whether
it is adequate or an action plan has been put into place. The information which
the portal requires is

Section VI. Technical Requirements

101

Appendix 1 Submission of WA (detail description)

Is the audit report overdue? Y or N


If the audit report is not satisfactory, is there an action plan in place and is it on
time.
The Audit report for this project is overdue
The action plan for the resolution of outstanding audit issues is not being implemented

Section VI. Technical Requirements

102

Appendix 1 Submission of WA (detail description)


FORM 100 - APPLICATION FOR WITHDRAWAL - for review
IFAD Loan/Grant/Financing No.:

xxxxxxxxxxxx

Borrower/Recipient name

xxxxxxxxxxxx

Account number

xxxxxx

Project Name

xxxxxx

Funding Sources
Financing Type

Application No.:

xx/xx/xx

xxxxxx

Enter into Force


date
Completion date

xxxxxx

Closing date

xx/xx/xx

xx/xx/xx

Authorised Allocation

xxxxxx

Ineligible expenditure pending

Y/N

CCY xxxxxxx

Status

xx

Risk rating

xx

Percentage of advance to be recovered


AWPB approved

Y/N/n/a

Amount of AWPB

CCY xxxxxxx

Period of AWPB
xxx

xx
Currency

xxx

xx
Currency

Withdrawal Amount

xxx

For special ac

xx %
For revolving fund

dd/mm/yy to dd/mm/yy

Percentage of AWPB to be financed


Application Type

xx %

xxx
Amount to be Paid in
Figures

xxx
Amount
to
be
Justified in Figures

xxx
Currency

Amount Requested in
Figures

Status of funds at time of WA submission


Further
Category Category
category
code
description description Allocated

Disbursed

Available
balance

SOE threshold

% financed by
IFAD

xx

xx

xx

xx

xx

xx

xx

xx

xx

xx

xx

xx

xx

xx

xx

xx

xx

xx

Section VI. Technical Requirements

103

Appendix 1 Submission of WA (detail description)


xx

xx

xx

xx

xx

xx

xx

xx

xx

xx

xx

xx

xx

xx

xx

xx

xx

xx

Warning messages
The amount being requested for payment exceeds the available amount of donor funds. Follow up is required

For financing funded


from external donors

The balance in the loan account is less than 2 times the outstanding initial deposit
There are less than 6 months to completion date
There are outstanding advances

For revolving fund - request for payment of advance

This project has ineligible expenditure pending


Unallocated category more than 7% of financing and less than one year to project completion
There are less than 6 months to closing date
There are overdrawn categories in this financing
The advance being requested exceeds the relevant percentage of the AWPB
The Audit report for this project is overdue
The action plan for the resolution of outstanding audit issues is not being implemented
Payment Instruction
Payees Name and Address:
Xxx Or a link to the uploaded form

Payees Bank
Name:
xxx
Address:

Correspondent Bank:
(not required when using the Direct Payment
procedure)
xxx

xxx

xxx
Account No.:
xxx

Special Payment Instructions and References:


xxx

Section VI. Technical Requirements

104

Appendix 1 Submission of WA (detail description)


Details of Expenditure
Category Summary
Number

Description

Currency

Amount

Source of
supply

% financed by
IFAD

xx

xx

xx

xx

xx

xx

xx

xx

xx

xx

xx

xx

xx

xx

xx

xx

xx

xx

xx

xx

xx
TOTAL

xx

xx

xx

xx

Documentation of Eligible Expenditure


Electronic Statement of Expenditure

xx

To include hyperlink to eSOE

Scanned Statement of Expenditure

xx

To include hyperlink to Scanned document

Copies of records

xx

To include hyperlink to Scanned document

For direct payments


Name and Address of Contractor or Supplier
(If different from Payee)

Procurement Details
a)

xxx

Contract or Purchase Order No. and Date:


xxx

b)

Description of Goods, Works or Services:


xxx

c)

Currency and Total Amount of Contract:

d)

Invoice Nos. and Net Amount of Invoices Covered by this Application:

xxx

xxx
Name of Borrower/Recipient
xxx
Name(s) and Title(s) of Authorized Representative(s)

xxx
xx/xx/xx
Date (DD/MM/YY)
xxx
Signature(s) of Authorized Representative(s)

Section VI. Technical Requirements

105

Appendix 1 Submission of WA (detail description)


1.16.
Routing to CPM for review and/or approval
a. The routing of the request based to the CPM needs to be completely configurable by an
Administrator type role. The conditions below describe the current requirements. It is
expected that the routing will be dependent upon:
Type of WA
Risk of project
Type of recipient
Value of WA
b. All requests, except for WA type Justification where B/R is not a country, are routed to the
CPM and where supervision is by a Cooperating Institution (i.e. where the field
Cooperating Institution in FX is not blank). If project is low risk and none of the categories
selected have Category Type = ADV, the routing is for information purposes. If medium
or high, the CPM will review the documentation submitted.
c. For all WAs routed to CPM there will be the possibility for the CPM to:

Comment: Insert a comment to explain work performed, or particular


circumstances to subsequent reviewers;

Ineligible expenditure: The CPM will be able to note that the value of the
WA should be reduced in the case that ineligible expenditure is noted. The
CPM will be required to insert information on the amount of the ineligible
expenditure and a description. This information will be available for
subsequent reviewers on the review form. If ineligible expenditure is noted
the WA will be routed to the FA for reduction. The amount of the ineligible
expenditure and the description will be interfaced to the FM tool once
approved by the FO.
d. Once reviewed the CPM will have one of three options:

Validate: the WA is routed to the approval stage

Put On hold: the WA is temporarily suspended. Need to define


communication with B/R if through the portal then will require the
possibility to send notification through portal. If not through portal then
email will be sent. The CPM will be notified after every 2 days that the WA
is on hold. The WA will become available for edit by the B/R (see section
1.13);

Reject: a notification will be sent to the FA/FO stating that the WA has
been rejected by the CPM. The CPM will have the possibility to insert
comments as to why the WA has been rejected and this information will be
available to FA/FO. Only the FA/FO will be able to reject a WA back to the
B/R.
WA xxx for Financing xxxxxxx has been rejected by the CPM
Comments
e. Once all issues with the WA have been resolved by the CPM, clearance is given. The
process for the review of the WA by CFS will continue regardless as to whether CPM

Section VI. Technical Requirements

106

Appendix 1 Submission of WA (detail description)

f.

clearance is provided or not. However WAs for high or medium risk projects will not be
interfaced to Flexcube unless the WA has also been certified by the CPM. (see flowchart)
If the WA is for an Advance payment to a revolving fund account i.e. where the Category
Type is ADV, the WA will be routed to the CPM for certification that the amount
requested is in line with the AWPB. If functionality is included to upload and approve the
AWPB then the amount of the AWPB should be included on the review page for CFS.

1.17.
Risk-based disbursement methodology to be applied to routing of request:
a. The routing of the request based on risk-based disbursements needs to be completely
configurable. This includes also determining whether certain error or warning messages
affect the routing of the WA. The following sections of this paragraph describe the current
requirements and are included in order to understand the complexity of the routing
required.
b. Regardless of risk rating of project, the following withdrawal applications will be routed
directly to the FA for verification:

if any warning messages are generated as described in 1.15.2

All advances for start-up costs

All advances and initial deposits

All withdrawal applications against financing in SPND status

Whenever New has been selected for the banking instructions

Wherever special payment conditions have been completed by the B/R

Wherever online approval is not used

Whenever the project or financing has been flagged as having special


conditions for payments
c. If the risk of the project is low and the WA is for Results based disbursements and the
Certificate has been received, route to FO
d. If the risk of the project is low and the WA is a replenishment, reimbursement or
justification and the Account is an imprest account and the balance on the loan account is
greater than two times the initial deposit route to FO
e. All other requests route to FA for review
f. As the risk based disbursement methodology may change over time, the system needs to
allow for the various cases to be defined. Ideally the data will be kept in a table as follows,
which can be updated by an Administrator role:
WA type

Imprest
account

Balance on loan> 2 Certificate


* initial deposit
received

Risk

Routing

Initial deposit

N/a

N/a

N/a

All

FA

Advance

N/a

N/a

N/a

All

FA

Replenishment

Yes

Yes

N/a

Low

FO

Reimbursement

Yes

Yes

N/a

Low

FO

Justification

Yes

Yes

N/a

Low

FO

Results Based
disbursement

N/a

N/a

Yes

Low

FO

Section VI. Technical Requirements

107

Appendix 1 Submission of WA (detail description)


1.18.
Straight-through processing
There should be the possibility to turn-on straight through processing (STP) for certain types of
transaction. Once turned on the applicable Withdrawal Application will be interfaced directly to
FX once submitted by the B/R to IFAD. It is expected that whether STP is turned on for the
individual requests is maintained in a table to be updated by an Administrator role:
WA type

Risk

STP

Materiality
(absolute)

Materiality
(relative)

Initial deposit

All

No

N/a

N/a

Advance

All

No

N/a

N/a

Replenishment

Low

Yes

< USD1
million

<30% of
financing

Reimbursement

Low

Yes

< USD1
million

<30% of
financing

Justification

Low

Yes

< USD1
million

<30% of
financing

Results Based
disbursement

Low

Yes

< USD1
million

<30% of
financing

1.19.
Comparison of information with standing data and routing of requests for review
based upon decision trees inherent within the system
a. One WA may contain several requests for payment . The FA/FO will need to have the
possibility to treat these separately and approve or reject individual transactions.
b. For all WAs routed to Finance Assistant there will be the possibility for the FA to:

Comment: Insert a comment to explain work performed, or particular


circumstances to subsequent reviewers;

Ineligible expenditure: The FA will be able to decrease the value of the


WA in the case that ineligible expenditure is noted. The FA will be required
to insert information on the amount of the ineligible expenditure and a
description. This information will be available for subsequent reviewers on
the review form. The amount of the ineligible expenditure and the
description will be interfaced to the FM tool once confirmed by the FO.
c. Once reviewed the FA will have one of four options:

Validate: the WA is routed to the FO

Put On hold: the WA is temporarily suspended. Need to define


communication with B/R if through the portal then will require the
possibility to send notification through portal. If not through portal then
email will be sent. The FA will be notified after every 2 days that the WA is
on hold. The WA will become available for edit by the B/R (see section
1.20).

Temporarily Reject: the WA will be routed back to the B/R. The FA will
have the possibility to insert comments as to why the WA has been

Section VI. Technical Requirements

108

Appendix 1 Submission of WA (detail description)


rejected. The B/R and CPM will receive a notification and the WA will
become available for edit by the B/R
WA no xxx has been returned for the following reason : insert text
The WA no xxx is now available for editing or for the submission of additional
information

Final rejection: the WA will be routed back to the B/R. The FA will have
the possibility to insert comments as to why the WA has been rejected. The
B/R, FO and CPM will receive a notification. It will not be possible to
resubmit the WA:

WA no. xxx has been rejected by IFAD for the following reason: insert text
d. For all WAs routed to Finance Officer there will be the possibility for the FO to:

Comment: Insert a comment to explain work performed, or particular


circumstances to subsequent reviewers;

Ineligible expenditure: The FO will be able to note that there is ineligible


expenditure and route back to the FA for reduction of the WA. The FO will
be required to insert information on the amount of the ineligible
expenditure and a description. This information will be available for
subsequent reviewers on the review form. The amount of the ineligible
expenditure and the description will be interfaced to the FM tool once the
WA is approved by the FO.
e. Once reviewed the FO will have one of three options:

Validate: if the project risk is low or medium and the financing is not a
Grant and the amount is greater than USD 1 million the WA is routed to a
second FO for review and approval. If the project risk is High or the
financing is Grant and the amount is greater than USD 500,000 the WA is
routed to a second FO for second review and validation. Otherwise the WA
passes to the approval stage;

Put On hold: the WA is temporarily suspended. Need to define


communication with B/R if through the portal then will require the
possibility to send notification through portal. If not through portal then
email will be sent. The FO will be notified after every 2 days that the WA is
on hold. The WA will become available for edit by the B/R (see section
1.20);

Reject: the FO will have the possibility to reject back to the FA for follow
up or back to the B/R. WA will be routed back to the relevant user. The FO
will have the possibility to insert comments as to why the WA has been
rejected. If rejection is to the FA, the FA will receive a notification of the
rejection. If the rejection is to the B/R, the B/R and CPM will receive a
notification and the WA will become available for edit by the B/R
WA no xxx has been returned for the following reason : insert text
The WA no xxx is now available for editing or for the submission of additional
information

Section VI. Technical Requirements

109

Appendix 1 Submission of WA (detail description)

Final rejection: the WA will be routed back to the B/R. The FA will have
the possibility to insert comments as to why the WA has been rejected. The
B/R, FO and CPM will receive a notification. It will not be possible to
resubmit the WA:

WA no. xxx has been rejected by IFAD for the following reason: insert text
1.20.
Amendment of WA by B/R
a. If the WA is put on hold by the CPM, FO or FA, or if it is rejected back to the B/R, the WA
in the system will become open for editing.
b. If the WA is rejected, the B/R will be able to amend the WA, however it will require to be
re-approved by the approver before being submitted to IFAD.
c. If the WA is put on hold and if any information in the input boxes of the Form 100 is
edited then the WA will require to be re-approved. If the change is only to upload scanned
documents, then no re-approval will be needed.
d. If additional information is uploaded by the B/R this should be easily identifiable by the
FA/FO and CPM. A notification should be sent informing FA/FO and CPM
WA xxx for financing xxx has been amended by the B/R
1.21.
Second Validation
a. If the WA requires a second validation it will be routed to the relevant FO who will have
one of three options

Validate: the WA is routed to the Approval stage

Reject: the WA will be routed back to the FO. The second validator will
have the possibility to insert comments as to why the WA has been
rejected.
1.22.
Approval stage
a. Once the WA has been reviewed and validated the system checks whether CPM approval
has been provided for those financing instruments which require such approval (see 1.16
above). If CPM approval has been received, the WA is ready for approval. The FO receives
a notification with a link to the approval page
WA xxx is ready for approval, click here to approve for payment
b. Notification should be sent to the FO if a WA remains in the approval stage for more than
2 days:
WA xxx is ready for approval, click here to approve for payment
c. If a WA is in the approval stage and CPM clearance is required and has not been received,
the CPM will receive a notification every 2 days until resolved
WA xxx is awaiting your clearance, please review and provide clearance
1.23.
Creation of record in Records Management System
Once the approval has been given by the FO and by the CPM, a record of the full withdrawal
application (Form 100 and scanned documents attached or Phase 2 - Form 100, 101, 102, 104, 105

Section VI. Technical Requirements

110

Appendix 1 Submission of WA (detail description)


and scanned documents attached) will be created within the Records Management System (RMS).
This record will include information on all approvals that the WA has gone through.
1.24.
Interface into Flexcube
a. The information on the WA is used to automatically create the relevant approved
transaction in Flexcube (see Attachment 3 for the Application type). There are certain
periods of the month or times of the day in which it is not possible to process transactions
in Flexcube e.g. during the billing process; during the EOD process. These dates could be
built within the system or alternately the approval stage could be used to manually
determine when the transaction should be interfaced. The interface will be real-time and
not scheduled.
b. Where a request for replenishment and justification have been submitted on the same
WA 2 transactions will be created: a Request for Disbursement and a Category
Reallocation: Justification.
c. Where the request chosen by the B/R is Advance or deposit to special Account the
system will create the appropriate transaction in FX depending on whether the account is
an imprest account or revolving fund (see Attachment 3 for the Application type).
d. Where the withdrawal application has been submitted at the project level, there needs to
be as many transactions in FX as the FX Accounts which have been selected.
e. Where more than one request for payment has been made in a WA, there will be as many
transactions created in FX as requests submitted.
f. Reports need to be available of any transactions which have not interfaced into FX for
follow up and resolution by the Systems Data Officer
1.25.
Integration with Flexcube
a. On approval by the FO of the WA in the workflow, the WA will be interfaced to FX. The
entering of certain transactions in FX requires a maker and checker function. It is not
intended that this be removed. Preferably the integration will create an approved
transaction in FX. Should this not be possible, the FO (or a centralised processing unit) will
then access Flexcube and approve the transactions for payment. The FO needs to be able
to easily retrieve the transactions which are pending approval to avoid, where multiple
transactions have been created that any of these are missed. This should be a notification
with the links to the transactions in FX.
the following transactions in FX are awaiting your approval:
RFDxxxxxxxxxxxxxx
JUSTxxxxxxxxxxxxx
b. The FO should be alerted where there are transactions pending for approval
1.26.
Communication of payment to B/R
a. At the relevant point (after confirmation of execution of payment by the bank) the debit
advice is generated and is sent to the B/R via the email. There will be a link to self-service
to allow the user to generate the relevant debit advice.

Section VI. Technical Requirements

111

Appendix 1 Submission of WA (detail description)


1.27.
Reporting
a. Reports are to be available which can be downloaded in excel of the status of WAs, in
order for IFAD to be able to reports on processing times and track WAs. At the same time
the B/R should be able to track the WA request through the workflow. Hence the system
must have the ability to track the status (including the actor who is holding the step) of
each WA at any point of time in the workflow. Furthermore the system should track the
time of completion of each step
b. Standard disbursement reports will be available for the B/R to generate subject to the
security controls over their access to data. A separate Appendix 4 details the
disbursement reporting.
1.28.

Forms (Phase 2)

1.29.
Overview (Phase 2)
There will be the possibility to enter data from the current forms in use in IFAD into the portal. The
forms will cascade as follows:

I.

Form 100 total


1.1.
Summary sheet (one for financing to countries; one for financing to non-country
recipients)
1.1.1. Form 101 (one for each category)
1.1.2. Form 102 SOE Rural Finance or Form 102 SOE Goods works and services with a
separate form for each category
II.
Form 104 (A and B)
III.
Form 105
IV.
Form C10
4.1.
Form C11
1.30.
Input Screens (Phase 2)
The screens for input will follow the basic forms in use in IFAD. The initial information which will be
input from Form 100 is described in detail in section 1.4. This section deals with the remaining forms
submitted by the B/R. Where information is held in the system or from the input of information by
the B/R on Form 100 the form should be automatically populated. All entries in the subsequent
forms which are to be updated automatically are shaded as indicated.

Certain data on the form is should be cross-referenced to the same figure on another form. The cells
which cross-reference are shaded as indicated with the relevant form reference included as text.
Form 100
Certain information is not obligatory, this will depend upon the underlying agreement with the B/R.
These cells are marked as follows:

For the detailed forms, the fields which should be calculated by the system are marked as follows:

Section VI. Technical Requirements

112

Appendix 1 Submission of WA (detail description)


For all forms:
1.
2.
3.
4.
5.
6.
7.
8.

9.
10.

there should be the possibility to upload from excel;


totals should be calculated and not input
Buttons for Save, Cancel, Validate and Submit for Approval
Any cells which the B/R does not need to enter are not available for update i.e. the information
which is picked up directly from the system should not be updateable;
Information can be entered and saved and then amended by the initiator: this means that not all
the information on the forms will need to be entered at the same time.
All forms need to be printable.
The Forms can be completed in any order
The initiator will enter the information and totals will be calculated. The initiator will be
required to validate the information before submitting for approval. Procedurally, the validation
check should only take place once all the forms have been updated, thus allowing for partial
completion of the information before validation.
Submission for approval creates a notification which is then routed for approval according to the
approvals set up in the system.
Validate will cause the information to be validated as follows:
a. That where forms cross-reference to each other the figures agree. If not error message will
be given and boxes will be highlighted in red. as follows:

Total on Form xxx does not agree to Form xxx


b.

That the Forms 102 do not include any amount greater than the SOE threshold for the
category. If an amount is included which is greater than the SOE threshold, the following
error message will be given and the line will be highlighted in red.

Form 102 includes amounts greater than the SOE threshold for this category. Please review the
submission and amend
1.31.
Special cases (Phase 2)
a. If the B/R is a non-country i.e. financing is a non-country grant, the Summary Sheet is in a
different format and the subsequent forms 101, 102, 104 and 105 are not required.
b. If the financing includes a category for Credit and Guarantee Funds, or Grants & Subsidies or
Investment Capital, the SOE form for that line will be the one for Rural Financing. A table
should be maintained of category numbers for which the Rural Financing form is to be used.
This must be updatable by an Administrator function within the system.
Rural Financing categories
Category Number
2000010
2000012
2000030
2000031
2000032

Section VI. Technical Requirements

113

Appendix 1 Submission of WA (detail description)


2000033
2000042
2000043
For all other categories the SOE form is that for Goods, works and Services.
There should be the possibility to develop new standard forms for specific categories.
c. The following forms are required to be Approved by the B/R and hence a button should be
available for the final approver in the workflow of the B/R to approve the form through on
line approval:
1. Statement of Expenditure for financing to country recipients
2. Form 101
3. Form 102/A Statement of Expenditure: Civil works, Goods and Consultancies
4. Form 102/A Statement of Expenditure: Rural Finance, Grants and Subsidies and
Investment Capital
5. Form 104/A Designated Account Reconciliation (Imprest Account) or Form 104/B Designated Account Reconciliation (Revolving Fund)
6. Form 105 Checklist
7. Form C10 Register of contracts (see contract monitoring requirements)
8. Form C11 Contract Monitoring Form (see contract monitoring requirements)

d. If on line approval is used, Form 105 should be available for the B/R to compile and submit
or compile and print, depending on whether full electronic forms are used or whether
scanned forms are uploaded. The example in Attachment 5 shows which fields can be
populated automatically depending on the type of submission used.

Section VI. Technical Requirements

114

Appendix 1 Submission of WA (detail description)


Attachment 1 Standing data
No

Information needed

Format

Source

Status

10

Project Risk

HML

FM tool

Bank account details for


designated/special account
Correspondent bank
information
Project name
[Project name]
FX account number and
alternate account number

Alphanumeric
6 lines
Alphanumeric
6 lines
Alphanumeric

Flexcube

Data available
but only
captured on
spreadsheet.
FM tool not
yet in place
Data available

20

Flexcube

Data available

Flexcube

Data available

Flexcube

Data available

50

Financing Type

Numeric for account


number
Alphanumeric for
alternate account
number
IFAD Loan, Grant,
DSF Grant, ASAP
grant, STF loan, etc

Flexcube

Data available

60

Status
[Work Flow Status]

APPR -Approved
CANC Cancelled
CLSD - Closed
DSBL - Disbursable
ENTF Entered into
Force
EXPD - Expired
PAID - Repaid
SIGN - Signed
SPND - Suspended

Flexcube

Data available

70

Funding Source

Data available

80

Categories

90

SOE threshold for each


category

IFAD, ASAP, STF,


Flexcube
Supplementary, HDR,
HIPC, DSF
Number plus
Flexcube
description
US$ amount
FM tool

100

Currency of Special/Advance
account
Type of Special/Advance
account

ISO currency code

Revolving Fund - ADV Flexcube


Imprest Account -

25
30
40

110

*
*

Flexcube

Data available
Data available
but only
captured on
spreadsheet.
FM tool not
yet in place
Data available
Data available

Section VI. Technical Requirements

115

Appendix 1 Submission of WA (detail description)


120
130
140

Closing date
Completion date
Original Financing amount

*
*
*

150

Amounts Disbursed

160

Amounts undisbursed

170
180

Date from which recovery to


commence
Recovery plan

190

Start-up costs

200

For revolving fund:


percentage which requires to
be justified before next
advance can be given
For revolving fund:
percentage of AWPB which is
financed

210

220

For imprest account


authorised allocation

230

Retroactive financing

240

Minimum WA amount

SPL
Date
Date
Currency and
amount (normally
SDR but can be US$,
EUR or other)
Currency and
amount (normally
SDR but can be US$,
EUR or other)
Currency and
amount (normally
SDR but can be US$,
EUR or other)
Date
Percentages to be
recovered for each
WA9
Currency and
amount (normally
SDR but can be US$,
EUR or other)
Number 1-100

Number 1-100

Currency and
amount (normally
US$, but can be EUR
or other)
Yes or No and
Amount
Currency and
amount (normally
SDR but can be US$,
EUR or other)
Or percentage of
advance or AWPB
This field can also be

To be investigated further

Flexcube
Flexcube
Flexcube

Data available
Data available
Data available

Flexcube

Data available

Flexcube

Data available

Data to be
captured
Excel
Data available,
spreadsheets/
however not
emails
in one place
possibly in FM
Tool
Financing
Data to be
agreement
captured
possibly in FM
Tool
Flexcube
Data available

LTB or grant Data to be


agreement
captured
possibly in FM
Tool
Flexcube
Data available

LTB
FM Tool
LTB
FM Tool

Data to be
captured
Data to be
captured

Section VI. Technical Requirements

116

Appendix 1 Submission of WA (detail description)


250

Ineligible expenditure
pending

255

Percentage of each category


financed by IFAD
Special conditions for
payment
Risk based disbursements
limits

260
270

*- indicates mandatory data for all projects

zero
Y or N

Number 1-100
Yes or No with
comment field
Area where RBD can
be updated and
dictates workflow

LTB
FM Tool

LTB
FM Tool
??
Portal

Data available
on a
spreadsheet.
To be included
in FM tool
Data to be
captured
Data to be
captured

Section VI. Technical Requirements

Appendix 1 Submission of WA (detail description)


Attachment 2 status of withdrawal application
1.
2.
3.
4.
5.
6.
7.
8.

Initiated steps to 1.13.


B/R approval once WA has been submitted internally for B/R approval step 1.13
Submitted step 1.14 after final approval step by B/R
On hold for those WAs put on hold
Rejected for those WAs rejected
Validated after step 1.22
Approved for payment step 1.22
Paid (once the debit advice has been generated)

117

Section VI. Technical Requirements

118

Appendix 1 Submission of WA (detail description)


Attachment 3 - Mapping of information on WA to information in FX
Terminology used
Country name
Financing Type
Status
Project
Financing number
Project Number
Financing Amount
Disbursable Date
Closing Date
Completion date
Disbursed Amount
Undisbursed Amount

Application type
* Advance for start-up costs
Advance payment or Initial deposit

Replenishment
Direct Payment
Reimbursement
Justification
Imprest Account
Revolving Fund

Flexcube field/Trx
Country
If Loan then PRODUCT_CATEGORY
If Grant then PRODUCT_DESC
If DSF then PRODUCT_CATEGORY
Work Flow Status
Project Name
Account
Alternate Account Number
Project ID
Amount Financed
Disbursable date
Closing date
Project Completion date
Total Utilized Amount
Total Available Amount

Request for Disbursement (RFD)


* If Category Type is SPL = DS
If Category Type is ADV =DA
Request for Disbursement (RFD)
* If Category Type is SPL; RFD type is DS
If Category Type is ADV; RFD type is DA
RFD - RP
RFD - DP
RFD - DP
Category Redistribution Activity Justification
If one of categories has Category Type SPL
If one of categories has Category Type ADV

Section VI. Technical Requirements

119

Appendix 1 Submission of WA (detail description)


Attachment 4 Mapping of product codes, description and categories in FX
PRODUCT_CODE
ORD1
INT1
HCN1
HRD1
HC00
IN00
IFGR
LCMG
SUPG
ECDG
OR00
DSSG
DHCG
ORE1
OFID
INE1
BT01
ASAP
DSP1

PRODUCT_DESC
ORDINARY TERMS SDR
INTERMEDIARY TERMS SDR
HIGHLY CONCESSIONAL TERMS 0.75
pc
HARDENED TERMS
HIGHLY CONCESSIONAL TERMS 1.00
pc
INTERMEDIARY TERMS
IFAD FUNDED GRANTS
LOAN COMPONENT GRANTS
SUPPLEMENTARY FUNDS GRANTS
ECD GRANTS
ORDINARY TERMS
DSF SELF-STANDING GRANTS
DSF HC GRANTS
ORDINARY TERMS EUR
LOAN ADMINISTRATION ONLY
INTERMEDIARY TERMS EUR
BLENDED TERMS
ASAP GRANTS
DEBT SETTLEMENT PLAN

PRODUCT_CATEGORY
LOANS
LOANS
LOANS
LOANS
LOANS
LOANS
GRANTS
GRANTS
GRANTS
GRANTS
LOANS
DSF
DSF
LOANS
ADMIN_LOANS
LOANS
LOANS
GRANTS
LOANS

Section VI. Technical Requirements

120

Appendix 1 Submission of WA (detail description)


Attachment 5 Withdrawal Application forms: 100, Summary of Expenditure, 101, 102, 104 and
105
FORM 100 - APPLICATION FOR WITHDRAWAL
IFAD Loan/Grant/Financing No.:
Project Name

xxxxxxxxxxxx
xxxxxx

Application No.: x

To: International Fund for Agricultural Development (IFAD)


Via Paolo di Dono, 44
00142 Rome, Italy
Please Pay:

xxx

xxx

Currency Name

Amount to be Paid in Figures

Application Type

xxx

xxx
Amount to be Paid in Figures

xxx

xxx
Amount to be Paid in Figures

We hereby apply for withdrawal from the Loan/Grant Account opened under the IFAD Financing Agreement and hereby certify as follows:
A. The undersigned has not previously withdrawn from the Loan/Grant Account to meet these expenditures and has not and does not intend to
obtain funds for this purpose out of the proceeds of any other loan/grant/financing.
B. The goods and services covered by this application have been or are being purchased and/or procured in accordance with the terms of the
General Conditions for Agricultural Development Financing approved on 29 April 2009.
C. This Application for Withdrawal covers a reporting period:

xx/xx/xx

xx/xx/xx

From (dd/mm/yy)

To (dd/mm/yy)

D. The undersigned hereby certify that the expenditures for which replenishment is claimed in Form 102
A and 102 B are correct, for the Project as provided in the IFAD Financing Agreement. We certify
that the expenditures incurred are within the statement of expenditure (SOE) thresholds and represent
resources used in compliance with the principles of legality, regularity and sound financial
management. We certify that the audit requirement outlined in article VIII and section 9.01 of the
General Conditions will be complied with, and that the requirements for maintaining records and
documentation for expenditures disbursed using the Statement of Expenditure (Form 102/A) modality
and outlined in section 4.04(c) and (d) of the General Conditions, will be complied with. This
includes, inter alia, that an annual audit will be carried out and that the documentation (including
purchase orders, invoices, evidence of payment and delivery and any other relevant documentation
evidencing the expenditures) will be retained for 10 years after the Closing Date of the IFAD
Financing, and that such records and documentation will be made available to IFAD representatives
for review on request.

Details of Expenditure

Payment Instruction

(Use summary sheet(s) if additional space is required or if expenditures relate to


more than one supplier, category or subcategory).

Name and Address of Contractor or Supplier

Payees Bank
Name:

xxx
xxx
xxx

(If different from Payee)

xxx

Address:
Account No.:

Procurement Details

xxx

a) Contract or Purchase Order No. and Date:

xxx

Payees Name and Address:

xxx

b) Description of Goods, Works or Services:

xxx
c) Currency and Total Amount of Contract:

xxx
d)

Invoice Nos. and Net Amount of Invoices Covered by this


Application:

xxx

Correspondent Bank:
(not required when using the Direct Payment procedure)

xxx
Withdrawal Details

a) Category or Subcategory No.:

xxx
b) Percentage of Expenditures to be Financed by IFAD:

10

xxx

xxx

11

Special Payment Instructions and References:

xxx

12

xx/xx/xx

Name of Borrower/Recipient

13

xxx
Name(s) and Title(s) of Authorized Representative(s)

Page | 120

Date (DD/MM/YY)

14

xxx
Signature(s) of Authorized Representative(s)

Section VI. Technical Requirements

121

Appendix 1 Submission of WA (detail description)


SUMMARY SHEET BY EXPENDITURE CATEGORY for financing to country recipients
SUMMARY SHEET BY EXPENDITURE CATEGORY
Financing number:

Accounting software:

Reporting period:

Accounting basis:

WA no.:

Financial reporting standards:

Category
(Schedule 2)
Category 1
Category 2
Category 3
Category 4
Category 5
Category 6
Category 7

Claimed under 101


Local
WA Currency (e.g.
currency
USD)
Form 101
Form 101

Claimed under 102


Local currency
Form 102

WA Currency
USD)
Form 102

Form 101

Form 101

Form 102

Form 102

Form 101

Form 101

Form 102

Form 102

Form 101

Form 101

Form 102

Form 102

Form 101

Form 101

Form 102

Form 102

Form 101

Form 101

Form 102

Form 102

Form 101

Form 101

Form 102

Form 102

Form 101

Form 101

Form 102

Form 102

(e.g.

Total
Local
currency

Total

WA
Currency
(e.g. USD)
Form 100
Form 100
Form 100
Form 100
Form 100
Form 100
Form 100
Form 100
Withdrawal
amount

Annotations

Page | 121

WA Currency

This is the currency in which the Withdrawal Application is prepared and expenditure claimed for Replenishment

Financing number:

This is the number of the loan or the grant

Reporting period:

The period during which the expenditures were incurred.

WA No:

The number of the withdrawal application.

Accounting software:

The name of the accounting system/software in which all the expenditures are recorded in.

Accounting basis:

The basis used for accounting e.g. cash, modified cash, accrual etc..

Section VI. Technical Requirements

122

Appendix 1 Submission of WA (detail description)

Page | 122

Financial reporting standards:

The standards followed when preparing the project financial statements e.g. IFRS, IPSAS, IPSAS cash etc..

Categories:
Claimed under 101:

These are the categories of expenditure as expressed in the Schedule 2 of the financing agreement.

Claimed under form 102:

These are the expenditures below the SOE threshold and subsequently claimed under form 102 and for which no
supporting documentation is required.

These are the expenditures above the SOE threshold and subsequently claimed under form 101 and for which supporting
documentation is required.

Section VI. Technical Requirements

123

Appendix 1 Submission of WA (detail description)

STATEMENT OF EXPENDITURE for financing to non-country recipients


Name of the Recipient:
Grant No:
Name of Project:
Reporting period from

_____________________________________________
_____________________________________________
_____________________________________________
______________ to ______________ in ____________ (Currency)

Category of Expenditures

Budgeted

Received

Spent

Outstanding

Totals

We hereby certify that the above amounts have been expended for Eligible Expenditures for
the proper execution of the Project in accordance with the terms and conditions of the
Agreement dated _____________.
Name and Title

_____________________________________________

Date

_____________________________________________

Section VI. Technical Requirements

124

Appendix 1 Submission of WA (detail description)


FORM 101 - APPLICATION SUMMARY SHEET
Mark the procedure being
applied:
Replenishment to the designated account
Direct Payment
Reimbursement
Reporting period: xxx

Item
No.

Name
and
Address
Contractor(s) or Supplier(s)

of

Reference to the
relevant AWPB
and
budget
line/item

Accounting
software
payment
voucher number

Reference
to
bank
statement/petty
cash
book
(transfer check)

Application No.:
xxx

IFAD Loan/grant/financing No.:


xxxx-xx

Contract
or
Purchase Order No.
and Date

Brief Description of
Goods, Works or
Services

Net total of all Expenditures/Invoices


% of expenditures to be financed by IFAD for Category
Net amount claimed for this summary sheet
Exchange Rate
Designated Account Currency Equivalent (US$/Other Equivalent):
Proper and complete supporting documentation attached

Currency

Total
Amount
of
Contract

xxx
xxx
Summary sheet
xxx
Summary sheet

Remarks
Including
of Origin

Country

Section VI. Technical Requirements

125

Appendix 1 Submission of WA (detail description)


FORM 102/A - STATEMENT OF EXPENDITURE: Civil works, Goods and Consultancies
(FOR REPLENISHMENT TO THE DESIGNATED ACCOUNT, Justification of advance or reimbursement of prefinanced expenditures)
For the expenditures listed below supporting documentation is not required. However, for all expenditure items part of a contract with more than one disbursement, duly
filled contract monitoring form (C-11) must be included in the Withdrawal Application.

Description of
Category:
Reporting
Period:

Drop down list

Date:

xx/xx/xx
From
(DD/MM/YY)

xx/xx/xx
To
(DD/MM/YY)

xxxxxxxxxx
IFAD Loan/Grant/Financing No.

xxx
Category No.
15.

Item
No.

Total

xx/xx/xx

xxx
Application No.

SOE threshold for the category:

Full Description of
the payment

Name of the
payee/Contractor,
supplier, service
provider

Reference
to
the
relevant
AWPB
and
budget
line/item

Contract and/or
invoice number

Accounti
ng
software
payment
voucher
number

Contra
ct
value
and
curren
cy

Expenditur
e
(invoice
amount in
Currency of
the
payment)

IFAD
Financing
Percentage

Date of
Payment

Rate
of
Exchange

Withdrawal
Application
Currency
Equivalent Claimed for
Replenishment/
justification/reimburseme
nt

Summary Sheet

Reference
to
bank
statement/petty
cash
book
(transfer check)

Country
Origin
other

of
and

Section VI. Technical Requirements

126

Appendix 1 Submission of WA (detail description)

*The undersigned hereby certify that the expenditures for which replenishment is claimed herein are correct, for the Project as provided in the IFAD Financing Agreement. We certify that the expenditures incurred
are within the statement of expenditure (SOE) threshold of equivalent US$XXX or Currency for this Category, and represent resources used in compliance with the principles of legality, regularity and sound financial
management. We certify that the audit requirement outlined in article VIII and section 9.01 of the General Conditions will be complied with, and that the requirements for maintaining records and documentation
for expenditures disbursed using the Statement of Expenditure (Form 102/A) modality and outlined in section 4.04(c) and (d) of the General Conditions, will be complied with. This includes, inter alia, that an annual
audit will be carried out and that the documentation (including purchase orders, invoices, evidence of payment and delivery and any other relevant documentation evidencing the expenditures) will be retained for
10 years after the Closing Date of the IFAD Financing, and that such records and documentation will be made available to IFAD representatives for review on request.

(Borrower/Recipient)

Certif
ied
by:

Certified by:
(Project
Accountant)

By:
(Project Director)

(Authorized Representative)

Section VI. Technical Requirements

127

Appendix 1 Submission of WA (detail description)


FORM 102/A - STATEMENT OF EXPENDITURE: Rural Finance (grants, investment capital, credit, guarantee funds etc.)
(FOR REPLENISHMENT TO THE DESIGNATED ACCOUNT)
For the expenditures listed below supporting documentation is not required. However, for all expenditure items part of a contract with more than one disbursement,
duly filled contract monitoring form (C-11) must be included in the Withdrawal Application.

Description of Category:
Reporting Period:

Drop down list


xx/xx/xx
From
(DD/MM/
YY)

Date:

xx/xx/xx
To
(DD/MM/Y
Y)

xxxxxxxxxxxx
IFAD Loan/Grant/Financing No.

xxx
Category No.
16

Item
No.

Total

xx/xx/xx

xxx
Application No.

SOE threshold for the category:

Full Description of the


payment

Reference to
the relevant
AWPB and
budget
line/item

Accounting
software
payment
voucher
number

Name of the
issuing entity
(MFI etc..)

Name
of the
client/
benefic
iary

agreement/
contract
number
between
the
LPA
and
the
MFI

Contract
value
and
currency

Expenditu
re
(Currency
of
the
payment)

IFAD
Financing
Percentage

Date of
Payment

Rate of
Exchange

Withdrawal
Application
Currency
Equivalent of
Claimed
for
Replenishment

Summary
sheet

Reference
to
bank
statement/petty
cash
book
(transfer check)

Country
of Origin
and
other
remarks

Section VI. Technical Requirements

128

Appendix 1 Submission of WA (detail description)

*The undersigned hereby certify that the expenditures for which replenishment is claimed herein are correct, for the Project as provided in the IFAD Financing Agreement. We certify that the expenditures
incurred are within the statement of expenditure (SOE) threshold of equivalent US$XXX or Currency for this Category, and represent resources used in compliance with the principles of legality, regularity
and sound financial management. We certify that the audit requirement outlined in article VIII and section 9.01 of the General Conditions will be complied with, and that the requirements for maintaining
records and documentation for expenditures disbursed using the Statement of Expenditure (Form 102/A) modality and outlined in section 4.04(c) and (d) of the General Conditions, will be complied with.
This includes, inter alia, that an annual audit will be carried out and that the documentation (including purchase orders, invoices, evidence of payment and delivery and any other relevant documentation
evidencing the expenditures) will be retained for 10 years after the Closing Date of the IFAD Financing, and that such records and documentation will be made available to IFAD representatives for review
on request.

(Borrower/Recipient)

Certified
by:

Certified by:
(Project
Accounta
nt)

By:
(Project Director)

(Authorized Representative)

Section VI. Technical Requirements

129

Appendix 1 Submission of WA (detail description)


FORM 104/A - DESIGNATED ACCOUNT RECONCILIATION STATEMENT
(IMPREST ACCOUNT)
(IN THE DESIGNATED ACCOUNT DENOMINATION CURRENCY IMPREST ACCOUNT OPTION)

WA No.:
xxx

Project Title:

xxx

IFAD Financing No.:

xxxx - xx

DESIGNATED ACCOUNT:

(Bank Account No.

BANK NAME:

xxx

Reporting Period:

xxx

xx/xx/xx

to

1 TOTAL ADVANCED BY IFAD

US$

2 LESS TOTAL AMOUNT RECOVERED BY IFAD

US$

3 EQUALS PRESENT OUSTANDING AMOUNT ADVANCED

US$

TO THE DESIGNATED ACCOUNT (Line 1 less Line 2)

4 BALANCE OF DESIGNATED ACCOUNT PER ATTACHED

US$

BANK STATEMENT AS OF [DATE: [day/month/year]

5 PLUS BALANCE OF THE PROJECT ACCOUNT(S) (LISTED SEPARATELY)


PLUS BALANCE OF SUB-ACCOUNTS (LISTED SEPARATELY)
PLUS BALANCE OF CASH IN HAND

US$
US$
US$
subtotal of 5

TOTAL OF BANK BALANCES [DESIGNATED A/C, PA, SUB-ACCOUNTS & CASH IN HAND BALANCE] (Li ne 4 + Li ne 5)

6 PLUS TOTAL AMOUNT CLAIMED IN THIS WA NO.

US$*

Form 100

US$

7 PLUS TOTAL AMOUNT WITHDRAWN FROM THE


DESIGNATED /PA/GRANT ACCOUNT AND NOT YET CLAIMED FOR
REPLENISHMENT) or WAs pending submission

US$

REASON:

Eligible amount of expenditures for which a WA has not yet been prepared

8 PLUS AMOUNTS CLAIMED IN PREVIOUS APPLICATIONS BUT NOT YET


CREDITED AT THE
DATE OF BANK STATEMENT AND/OR CLAIMED AFTER DATE OF BANK
STATEMENT
APPLICATION NO.

DATE

US$

user to have possibility to include as many


rows as is required

AMOUNT

US$
US$
subtotal of 8

9 MINUS INTEREST EARNED (to be


completed. If zero, please enter 0)

US$

US$

10 TOTAL ADVANCE ACCOUNTED FOR (Line 5 * through Line 9)

US$

11 EXPLANATION OF ANY DIFFERENCE BETWEEN THE TOTALS APPEARING ON LINES 3 AND 10


User to have possibility to add as many rows as necessary and for each one a comment box should
be available

US$

12 DATE:

xx/xx/xx

SIGNATURE:
Na me i n Ful l
Ti tl e i n Ful l

xx/xx/xx

Section VI. Technical Requirements

130

Appendix 1 Submission of WA (detail description)


FORM 104/B - DESIGNATED ACCOUNT RECONCILIATION STATEMENT
(REVOLVING FUND)

Project Title:

xxx

IFAD Financing No.:

xxxx -xx

Designated Account No.:


Bank Name:

WA No.
Reporting Date:

xxx
xx/xx/xx

to

xx/xx/xx

xxx
xxx

1 AMOUNT ADVANCED BY IFAD


user to have possibility to include as manyUS$
rows as is required
US$
US$

First Advance in WA -- (VD -------)


Second Advance by WA -- (VD -------)
Third Advance by WA -- (VD -------)

TOTAL AMOUNT ADVANCED BY IFAD

US$

2 LESS: AMOUNT RECOVERED BY IFAD


List WA Nos. -------- in 20xx
List WA Nos. -------- in 20xx
List WA Nos. -------- in 20xx

user to have possibility to include as many


rows as is required
Years to be selected from list

TOTAL AMOUNT RECOVERED BY IFAD

US$

3 EQUALS PRESENT OUTSTANDING AMOUNT


ADVANCED
TO THE DESIGNATED ACCOUNT (Number 1

US$

less Number 2)

4 BALANCE OF DESIGNATED ACCOUNT PER ATTACHED


BANK STATEMENT AS OF DATE: [day/month/year]

US$

5 PLUS BALANCE OF THE PROJECT ACCOUNT(S): [listed separately]


PLUS BALANCE OF SUB-ACCOUNTS [listed separately]
PLUS BALANCE OF CASH IN HAND

US$
US$
US$
Subtotal of 5

TOTAL OF BANK BALANCES, DA, PA, SUB-ACCOUNTS, CASH IN HAND (Line 4 + Line 5)
6 PLUS TOTAL AMOUNT CLAIMED IN THIS WA No. -----

US$
US$*
US$

7 PLUS TOTAL AMOUNT WITHDRAWN FROM


THE DESIGNATED/PA/GRANT/
ACCOUNT AND NOT YET CLAIMED
REASON/S: Eligible amount of expenditure for which a WA has not yet been prepared

US$

8 PLUS AMOUNTS CLAIMED IN PREVIOUS APPLICATIONS


BUT NOT YET CREDITED AT
DATE OF BANK STATEMENT AND/OR CLAIMED AFTER
DATE OF BANK STATEMENT
APPLICATION NO.
WA No. -WA No. -WA No. --

DATE

USD

AMOUNT

user to have possibility to include as many


rows as is required

Subtotal of 8
9 MINUS INTEREST EARNED (to be completed; if zero please mark "0")
10 TOTAL ADVANCE ACCOUNTED FOR ( Line 5* through Line 9)
11 EXPLANATION OF ANY DIFFERENCE BETWEEN THE TOTALS APPEARING ON LINES 3 AND 10
e.g. non-eligible amount to be refunded to the designated account
e.g. calculation errors/errors in application of % financing
e.g. counterpart financial resources to be reimbursed

US$
US$
US$

Form 100

Section VI. Technical Requirements

131

Appendix 1 Submission of WA (detail description)


FORM 105 CHECKLIST FOR WITHDRAWAL APPLICATION
xxx
Financing No.

xxx
WA No.

1. Sequential numbering of withdrawal application

Esignature
Esignature and
and
input of forms in
scanned
system
forms
System
System

2. Withdrawal application amount tallies with sequentially numbered summary sheets

System

3. Categories/subcategories charged according to schedule 2 of financing agreement

System

System

4. Percentage of financing applicable for each category or subcategory

System

System

5. Availability of funds in categories and the overall financing amount

System

System

6. Currency of payment

System

System

7. Completeness and accuracy of banking instructions

System

System

8. Complete name and address of correspondent bank

System

System

9. WA is signed by Authorized Representative

System

System

10. Expenditure summary sheet by category attached

System

System

System

System

FORM 100 - APPLICATION FOR WITHDRAWAL

Yes or No

STATEMENT OF EXPENDITURE
1. Eligibility of expenditures claimed
(a) Within SOE financial ceiling
(b) Expenditures under specific category [-----] eligibility
2. Form 102 signed by designated Project Accountant, Project Director, Authorized Representative
3. Form 102 supported by signed Form 101 (for items reported in 2, but over the financial ceiling)
DESIGNATED ACCOUNT REPLENISHMENT REQUESTS
1. Amount within ceiling figure agreed as a reasonable limit [-- US$ or --]; or per AWP/B period
2. Amount at least equal to 20 per cent of the agreed limit; or per AWP/B projected requirements
3. Amount agreed sufficient to cover a specific reporting period (revolving fund option)
4. Exchange rate used
5. Completeness of designated account banking and account details
6. Enclosed designated account reconciliation and bank statements
SUPPORTING DOCUMENTATION (attached when/if required)
1. Copy of contract
2. Copy of invoice, certified by Project Director
3. Copy of bank guarantee and performance guarantee (for advance payment)
4. Copy of delivery receipt
5. Copy of evidence of payment
6. Completed Form 101
7. Completed Form 102 (A or B) including reference to AWPB, name of the supplier, invoice contract
number, total contract value, date of payment, list of supporting documentation, and reference to
the bank/petty cash statement.
PROCUREMENT
1. Copy of no objection(s) provided by IFAD (attached)
2. Copy of Contract Payment Monitoring Form(s) -duly Signed (attached)
3. Copy of Register of contracts- duly signed (attached)
COMPLIANCE WITH CONDITION(S) FOR DISBURSEMENT
1. In accordance with terms in section E of the Financing Agreement
2. In accordance with terms in the Letter to the Borrower/Recipient
EXPENDITURE INCURRED/COMMITTED BEFORE PROJECT COMPLETION DATE
1. Expenditure verified as eligible:
(a) contract signed before project completion date
(b) goods delivered before project completion date
(c) services completed and/or rendered before project completion date
Remarks:

Prepared by: Project Accountant


Dated: xx/xx/xx

Certified by: Project Director


Dated: xx/xx/xx

Section VI. Technical Requirements

Appendix 2 - Submission of Banking Instructions - (detail description)

132

Section VI. Technical Requirements

133

Appendix 2 - Submission of Banking Instructions - (detail description)


The integrity of this process is critical to the Withdrawal Application processing. Hence there will
need to be two-factor authentication access and approval of the banking instructions by the
Authorizer
1. Process
1. Within the portal there will be an area which will permit the B/R to communicate banking
instructions to be inserted for direct payments only.
2. The Author will select the financing from those which s/he is authorised to access, for which
banking instructions are to be submitted. The following fields will be populated:
IFAD financing Number
Borrower/Recipient name:
FX Account number
Project names
Funding source
Enter into Force date
Date request submitted
3. The Author will upload the attached form duly completed and stamped by the bank for
certification by the bank of the beneficiary. Alternately, the Author will upload invoice or
contract extract where the banking instructions are clearly identified.
4. The banking instructions to be inserted will follow the same approval process as a request for
withdrawal i.e. the request will be routed to the Authorizer for review and approval or rejection.
5. Once the information has been inserted, the request will be routed to the appropriate
Authorizer as a notification containing the following information:
IFAD financing Number
Borrower/Recipient name:
FX Account number
Project names
Funding source
Enter into Force date
Date request submitted
With the bank certification as an attachment.
6. The Authorizer will have the possibility to approve or reject and if rejected, the possibility to
enter a comment explaining why rejected. Rejection means the request will be routed back to
the Author for amendment.
7. Once approval has been given at the B/R level the request will be routed to the Validator.10 (FA)
for validation.
8. The system will determine who the request is to be routed to depending on information in the
access/identify management system.

10

Currently the update of banking instructions is performed by CFS and hence this would be included in the
access of the Validator and Approver. To be decided whether this function should remain in CFS. If not,
additional roles will be required for the update and for the approval of banking instructions.

Section VI. Technical Requirements

134

Appendix 2 - Submission of Banking Instructions - (detail description)


9. The Validator will review the request and manually determine the validity of the banking
instructions. If the BI are not considered adequate the Validator needs to be able to reject them
back to the Author with an explanation as to the reason for the rejection.
10. Once validated, if possible, the BI will be uploaded into the system using data capturing
technology from scanned documents for confirmation by the FA as to their adequacy.
Alternately the BI will be inserted by the Validator (FA) in the system. The Validator will then
submit the BI for approval.
11. The Approver will review the BI in the system together with the scanned documents and either
approve or reject the BI. If rejected the Approver will be able to insert comments and the
rejection will be back to the Validator.
12. Currently the insertion of BI is in Flexcube. There are certain system validations therein on the
length of the account number, Swift code etc. These validations must be maintained whichever
system is utilised, however they have not been redefined here, nor is it foreseen that a separate
database of rules and validations be created and maintained: the validations within FX must be
utilised.
13. The Validator will only insert the BI once and the Approver will only approve the BI once,
regardless of the system solution adopted. If the insertion and approval is outside of FX, then an
approved Payee Instruction record will be created in FX. If the insertion and approval is within
FX, the current functionality whereby the maker and checker are combined for Payee
Instructions will require to be modified to permit an approval process.
14. Once inserted in FX, a notification will be sent to the B/R indicating that the BI are available for
the B/R to select for direct payments.
Banking instructions for xxx have been inserted and can now be selected
15. Once approved BI have been inserted in FX, the request for update of banking instructions,
together with any attachments will be routed to RMS for storage.

Section VI. Technical Requirements

135

Appendix 2 - Submission of Banking Instructions - (detail description)


BANKING INSTRUCTIONS FORM
Generic Data/Informations Personelles/Datos Generales

Beneficiary nam e

Financing Account Num ber

Address/Adresse/Direccin

Post Code/Code Postal/Cdigo Postal

City/Ville/Ciudad

Country/Pays/Pas

Phone Num ber/Tlphone/Telfono

Fax Num ber

E-Mail/Adresse electronique/Correo electrnico

Bank details/Detail de Banque/Datos Bancarios

Account Holder Nam e/Com pte au nom de/Cuenta a nom bre de

Account Num ber/Num ero du com pte/Nm ero de Cuenta

IBAN No. (for European bank accounts)

Bank Nam e/Nom de la Banque/Nom bre del Banco

Bank Address/Adresse bancaire/Direccin del Banco

Bank Branch/Sucursale/Sucursal

City/Ville/Ciudad

Country/Pays/Pas

Sw ift BIC Code

Bank ID (i.e. ABA # - Fedw ire (USA) - Sort Code (GBP) - Routing No.

Intermediary/Corresponding Bank

(for USD transfers outisde USA and EUR outside EU/EEA area)

Bank Nam e/Nom de la Banque/Nom bre del Banco

City/Ville/Ciudad

Sw ift BIC Code

Country/Pays/Pas

Account Num ber w ith Correspondent Bank/


Num ero du com pte/Nm ero de Cuenta

PLEASE NOTE THAT ALL FIELDS ARE OBLIGATORY - INSTRUCTIONS WILL BE KEPT CONFIDENTIAL
CHANGES SHOULD BE COMMUNICATED OFFICIALLY USING THE FORM WITH STAMP/SIGNATURE INCLUDED
Date and signature/stamp of bank
(Obligatory)

Section VI. Technical Requirements

136

Appendix 3 Submission of AWPB - (detail description)


Submission of AWPB process

PMU

Phase

Start

AWPB prepared/
amended

AWPB uploaded

Notification to
CPM

AWPB Submitted

No

B
R

AWPB reviewed
and approved

Yes

< 30 days from


submission of
AWPB

No

Is AWPB On
Hold, or
Rejected

AWPB Accepted

Notification to B/R
Yes

End

CPM

Yes

AWPB reviewed
and approved

Yes

End

CFS

No

CFS role would be to access data:


* Period
* Amount
* Scanned document
* Status

Notification to B/R

Section VI. Technical Requirements

137

Appendix 3 Submission of AWPB - (detail description)


1. Within the portal there will be a screen which will allow the B/R to upload the AWPB;
2. This will have gone through the internal approval process between the PMU and the B/R. At this
stage the portal will not support the internal workflow between approvers of the B/R.
3. Once approved the PMU will upload the scanned document into the portal specifying:
o
the period to which it relates
o amount of the AWPB
o Currency
And will submit the AWPB to IFAD
4.

11

The CPM will receive a notification that the AWPB has been uploaded:

AWPB for the period xxx to xx for financing xxx is ready for your review. In accordance with the
General Conditions, if no comment is provided to the Borrower/Recipient within 30 days the
AWPB shall be deemed to be acceptable to the Fund
5. The CPM will have the possibility to
o accept the AWPB or
o reject the AWPB back to the PMU and provide comments to the PMU or
o Hold the AWPB in draft status and provide comments to the PMU.
The role of the CPM will also be to ensure that the amount inserted by the B/R agrees with
that in the scanned document and that the period has been reflected correctly.
6. The AWPB will have the possibility of being in one of four statuses:
o Submitted
o Accepted
o Rejected
o Draft
7. If the status of the AWPB has not changed status in 10 days the CPM will receive notifications
every 10 days as follows:
AWPB for the period xxx to xx for financing xxx was submitted on xx/xx/xxxx and is ready for
your review. In accordance with the General Conditions, if no comment is provided to the
Borrower/Recipient within 30 days the AWPB shall be deemed to be acceptable to the Fund
8. If 30 days have gone by from when the AWPB was submitted and it has not been rejected or put
into Draft, the status of the AWPB will automatically move to Accepted and the CPM will
receive the following notification:
AWPB for the period xxx to xx for financing xxx is deemed acceptable to IFAD
9. Once the CPM takes action to change the status of the AWPB, a notification will be sent to the
B/R
9.1. On status change to Accepted
11

For the subsequent requirements, IFAD is in the process of developing a workflow for No-objections within
Scriptoria. The acceptance of the AWPB will fall into this workflow. To the extent that this functionality is
developed and delivered before LGS2, the requirements for this phase of the portal are to link to the Noobjection functionality. Phase 2 will be to build the functionality with the 3 fields noted at paragraph 3
being completed for reference in the WA submission process.

Section VI. Technical Requirements

138

Appendix 3 Submission of AWPB - (detail description)


AWPB for the period xxx to xx for financing xxx is deemed acceptable to IFAD
9.2. On status change to Rejected
AWPB for the period xxx to xx for financing xxx has not been accepted by IFAD. Please see
below the details of the changes required
Include comments from CPM
9.3. On status change to Draft
AWPB for the period xxx to xx for financing xxx is under review by IFAD. Please see below
the additional information which is required
Include comments from CPM
10. Once the AWPB has been submitted the B/R will not be able to make any changes to the
documentation uploaded, unless it is put into Draft status. At that point the B/R will be able to
make changes and resubmit. If the AWPB is rejected then the B/R will be able to delete the
uploaded document and insert a new one, changing any of the input fields for the AWPB.
11. The portal must provide for an iterative process whereby the AWPB is put into Draft status any
number of times and is changed by the B/R any number of times
Information available to CFS during checking process:
12. Given that there may be multiple AWPBs the system will reference the date information inserted
on the submission of the AWPB to the date information inserted for the WA
o AWPB period
o AWPB status
o Amount
o Currency
o Uploaded document

Section VI. Technical Requirements

139

Appendix 4 Confirmation of disbursement conditions - (detail description)

Section VI. Technical Requirements

140

Appendix 4 Confirmation of disbursement conditions - (detail description)


1. At the stage of set up of financing in Flexcube, the information will flow through to the
portal. Within the portal CFS will have the possibility of inserting disbursement conditions
(only for financing which is in the status of APPR, ENTF). These will be free-form text and can
be up to 10. For each condition there will be an option to indicate that documentation will
be uploaded or that confirmation will be provided. [For example the opening of a bank
account may be a disbursement condition, however the communication of the details may
follow a different process and hence requesting the B/R to upload information at this stage
could be duplication]. Disbursement conditions will be set up for each type of financing and
not at the project level.
2. There are general disbursement conditions which derive from the General Conditions for
Financing. Furthermore there will be a mandatory condition that the Letter to the Borrower
has been issued. These will be proposed for all financing as follows:
Project Name:

ABCD

Financing:

100000363100 L-I--801-

Disbursement conditions

XXXXXXXXXXXXXXXXXXXXXXXXX
CPM
approval

Documentation Confirmation
required
required

Reference
document tag

First AWPB approved Section Y/N


4.02 GC

Y/N

Y/N

n/a

Letter to the Borrower issued

n/a

n/a

n/a

LTB

Y/N

Y/N

Y/N

Y/N

Y/N

Y/N

Y/N

Y/N

Y/N

3. There will be the possibility for the information submitted to flow through to the CPM, once
submitted by the B/R if necessary. The FO/FA will select approval by CPM Y or N for each
single condition.
4. Given that the information will be available to the B/R there will be a possibility for review
and approval by the FO
5. Also for review and approval by the CPM for confirmation that information for which CPM
approval is needed is correct. The CPM will see all disbursement conditions at this stage and
will have the possibility to reject back to CFS for changes.
6. There should be the possibility to link documents submitted in the disbursement conditions
process to the Reference documents section and vice versa. This will happen wherever the
disbursement condition refers to a standard tag in the Reference documents. The user will
be required to select the tag from a dropdown list and if a document exists with that tag, to
select the document and link it.
7. Once this information is approved the B/R will be able to access a screen of disbursement
conditions where the text inserted is re-proposed, together with either a box to tick (if
confirmation is needed) or the possibility to upload documentation, (where this has been
indicated by CFS).
Project Name:

ABDC

XXXXXXXXXXXXXXXXXXX

Section VI. Technical Requirements

141

Appendix 4 Confirmation of disbursement conditions - (detail description)


Financing:

100000363100 L-I--801-

Disbursement conditions

Documentation Confirmation
required
required

First AWPB approved Section Y upload here Y


4.02 GC
Letter to the Borrower issued

Link
document

to Y

Project and PMU staff recruited

Draft PIM including Financial Y upload here


Management section approved by
IFAD

Project Account opened

Fully-fledged
financial
management system installed

8. The condition concerning the Letter to the Borrower is the one condition which the B/R will
not be required to update and which is the responsibility of the Finance Assistant or Officer.
This will link with the Reference documents area of the portal.
9. Once all the boxes have been ticked or documentation uploaded, the B/R will be required to
tick a box:
I hereby certify that all the disbursement conditions for financing xxx (from a drop down list,
with the possibility to select more than one financing) have been satisfied.
And then submit
10. Submission will create a notification for the relevant FA/FO and CPM
Please note Name of B/R has declared that all disbursement conditions have been met for
Financing number please review
11. The FA followed by the FO and the CPM will review the documentation and declarations
from the B/R with 3 options for action to take:
o Approve this creates a transaction in FX whereby the status of the financing is
changed to DSBL
o Reject goes back to the B/R with a notification explaining the reason for the
rejection (missing information or additional information needed)
o On hold minor information which can be resolved in a minimum time period
12. Once all parties have approved the documentation there will be an interface to FX to update
the status of the financing to DSBSL. At this stage a notification will be sent to the B/R
Financing number xxxxxxxx is now in disbursable status and withdrawal applications can be
submitted

Section VI. Technical Requirements

142

Appendix 5 Reallocation of Category - (detail description)

Section VI. Technical Requirements

143

Appendix 5 Reallocation of Category - (detail description)


1. Background
1.1. The need for a reallocation of categories can commence from 2 sources: IFAD (CPM and/or
FO) and the Borrower/Recipient (B/R). Once it has been decided that a reallocation is
required, the B/R submits an official request which has been approved internally. This is the
point at which the request could be submitted using the portal.
1.2. Once the request has been submitted it should be routed for review and approval as
follows:

To the CPM

To CFS

If recurrent costs are > 30% of the total financing to CFO

To LEG

To Division Director

If the reallocation is between categories and not just from the unallocated category to
an existing category to the AVP PMD (after approvals a. to f. have been obtained)

If the reallocation requires the creation of a new category, the financing agreement
will require amendment and hence approval of the President
1.3. The current process requires an office memorandum to be prepared explaining the
rationale for the reallocation. This is manually routed internally in IFAD in accordance with
the attached flowchart and as described briefly in point 2 above. The text of the office
memorandum is frequently amended by CFS as incorrect/inaccurate or incomplete.
1.4. Although the client portal could be utilised for the submission of the request, the overall
automation of this process requires an approval workflow within IFAD. Consideration must
be given as to whether:

an automated workflow is required;

the client portal would be the most appropriate place for such workflow;

functionality already available in other systems (e.g. Scriptoria) could be used for the
same purpose.
2. Functionality for portal
1.5. There should be an area within the portal for the submission of a request for reallocation.
This can be arrived at either through the Header-search function at 1.5.1 in eSubmission of
Withdrawal Applications (Appendix 1) or by searching directly on the project. In all cases
the request for reallocation is submitted at the level of financing.
1.6. B/R will be required to select categories and insert the amounts to be reallocated. The B/R
will be able to enter/select as many lines as necessary from the financing (i.e. no need to
enter all categories). The B/R will also have the possibility of selecting a New Category and
naming it from a dropdown list of standard categories in FX.
Category Name

Category
Number

Authorised
amount (A)

Reallocation
(B)

Drop down list of


categories from FX
excluding
categories where
Category Type is

From FX

From FX

Inserted
B/R

Revised Amount (A-B)


by System calculated

Section VI. Technical Requirements

144

Appendix 5 Reallocation of Category - (detail description)


SPL or ADV
New category

From FX

Inserted
B/R

by System calculated

1.7. B/R uploads a scanned document giving the reason for the reallocation and the amounts to
be reallocated and submits request to IFAD.
1.8. B/R receives a notification
Request for reallocation for financing xxx has been submitted to IFAD
1.9. A notification will be created with the summary of the amount being requested for
reallocation (table above) and the scanned document. Key information to be included on
the request is:

IFAD financing Number

Borrower/Recipient name:

FX Account number

Denominated Currency of financing

Project names

Funding source

Enter into Force date

Completion Date

Closing Date

Date request submitted


1.10.
This notification will follow a workflow process where each actor will have the
possibility to review the request, approve, reject and add comments. If the notification is
rejected then the routing is always back to the CPM for follow up with the B/R. The CPM
will be required to enter specific comments on the reasons for the reallocation [current
process is that a 2 page memo is written, hence the area for comments needs to be
sufficiently large to allow such text to be entered].
1.11.
Once the request has been submitted it should be routed for review and approval as
follows:

To the CPM

To CFS

If recurrent costs are > 30% of the total financing to CFO

To LEG

To Division Director

If the reallocation is between categories and not just from the unallocated category to
an existing category, to the AVP PMD (after approvals a. to f. have been obtained)
1.12.
At each stage in the approval workflow, the notification will capture the names of
the people who have approved and their role.
1.13.
Once all approvals have been obtained the notification is routed back to the CPM
and the following text is added:
Request for reallocation for financing xxx has been fully approved, please inform the B/R

Section VI. Technical Requirements

145

Appendix 5 Reallocation of Category - (detail description)


1.14.
If at any point in the process the request is rejected, the person rejecting will have
the possibility to insert comments, explaining the rejection. The comments will be visible to
subsequent reviewers. Furthermore, the reviewer will be able to tick boxes to indicate
whether the previous reviewers need to approve the request again. In this way for example,
the division director can reject back to the CPM and the CPM can resubmit without having
to pass through Legal and CFS.
1.15.
In the first routing to the CPM and to CFS, there will be the possibility to amend the
amounts inserted by the B/R for reallocation. This is to ensure that the amounts inserted
are correct. Once approval has been given by CFS, it will not be possible to change the
amounts for reallocation. The role of CPM/CFS will also be to check that the amounts
reallocated have been inserted correctly.
1.16.
If the reallocation requires the creation of a new category, once all approvals have
been obtained the CPM will receive the following notification
Reallocation for financing xxx has been approved, however it requires the creation of a new
category. Amendment of the financing agreement and approval of the President is required
1.17.
If the reallocation does not require the creation of a new category, once the request
has been approved, either a Category redistribution or VAMI transaction is created
automatically in FX for the approval by the FO, or the FA enters a Category redistribution
or VAMI in FX which is then approved by the FO.
1.18.
If an automatic VAMI is created the FO/FA will receive the following notification:
VAMI for reallocation of financing xxx has been entered in the system and is awaiting your
approval
1.19.

Once the VAMI is approved the B/R receives the following notification:

The request for category reallocation for financing xxx has been approved by IFAD and the data
entered in the system. All future reports for this financing will show the revised allocations.

Section VI. Technical Requirements

146

Appendix 6 Increase/Decrease in Special Account Allocation - (detail


description)
Increase in Special Account allocation
Borrower/Recipient

CFS

CPM

Start

Start

Start

Determine need for


an increase in the
authorised
allocation

Determine need for


an increase in the
authorised
allocation

Determine need for


an increase in the
authorised
allocation

Review request for


increase

Submit request for


increase

yes

Approve
increase in AA

No
End

Yes

Inform B/R and


CPM

Update
information
in FX

End

Notification to B/R &


CPM

Section VI. Technical Requirements

147

Appendix 6 Increase/Decrease in Special Account Allocation - (detail description)


1. Background
1.1. The start of the request for an increase or decrease in the allocation of the Special Account
can be from the borrower or be generated by CFS (FO) or by the CPM.
1.2. The justification for the change is reviewed by CFS and the CPM together. Where necessary
additional information may be obtained by liaison with the borrower or by liaison with
other experts.
1.3. In reviewing the request the FO takes into account the FM rating of the project as well as
the status of submission of audit reports.
1.4. The ultimate decision for the level of the authorised allocation remains with CFS.
1.5. Once the level of the AA has been changed, FO informs the Borrower in a fax signed by the
FO.
2. Functionality for portal
1.6. There should be an area within the portal for the submission of a request for increase or
decrease in the special account allocation. This can be arrived at either through the Headersearch function at 1.5.1 in eSubmission of Withdrawal Applications (Appendix 1) or by
searching directly on the project. In all cases the request for reallocation is submitted at the
level of financing.
1.7. The request can be entered by the B/R, CPM or CFS. If request is entered by CFS, it will be
the FO which enters it. This is only available for imprest accounts i.e. where Category Type
is SPL. If the financing has more than one imprest account, a picklist will be available of each
of the imprest accounts. There will be the possibility to select more than one account
Imprest account

Current authorised allocation

Proposed authorised allocation

Picklist options from FX

From FX DA Amount field

Inserted by user

An example of picklist:
Account number: 1000000363100
Alternate Account number: L-I-801Project Name: ABCD
Picklist:
Designated Account Authorised Allocation
Designated Account Authorised Allocation abc
Designated Account Authorised Allocation defg
1.8. Once submitted, a notification will be created with the summary of the change being
requested (table above) and if any scanned document. Key information to be included on
the request is:

IFAD financing Number

Borrower/Recipient name:

FX Account number

Project name

Denominated Currency of financing

Funding source

Enter into Force date

Closing date

Section VI. Technical Requirements

148

Appendix 6 Increase/Decrease in Special Account Allocation - (detail description)

Completion date

Date request submitted


1.9. The routing of the request will vary according to who has submitted the request:

If FO has submitted, copy is sent for information to FA and CPM

If CPM or B/R has submitted the request then notification routes to FO with copy for
information to FA and CPM
A request for a change in the special account allocation for financing xxx has been
submitted
1.10.
The CPM has the possibility to insert comments in a comment box.
1.11.
An automatic VAMI transaction is created in FX to update the DA Amount field or
the FA enters a VAMI transaction in FX which are then approved by the FO
1.12.
.If automatic VAMI is created the FO/FA will receive the following notification:
VAMIs for change in the authorised allocation of the special account for financing xxx has been
entered in the system and is awaiting your approval
1.13.
Once the VAMI is approved the B/R receives the following notification copying the
CPM:
The special account allocation for account xxx for financing xxx has been changed to CCY xxx xxx.

Section VI. Technical Requirements

149

Appendix 7 Contract Monitoring - (detail description)


1. Background
1.1. The current process for contract monitoring is performed by the project and is manual.
1.2. Where so required by the Letter to the Borrower/Beneficiary (depending upon thresholds
and type of procurement to be undertaken), the project will request a No-Objection (NO,
NOL) from the appropriate CPM. The request for and agreement to NO is generally
communicated by email.
1.3. The PMU should maintain a Contract Register (form C10) where all significant contracts are
recorded.
1.4. For each contract the project should maintain a contract monitoring Sheet (C11) detailing
the original contract plus amendments, any guarantees provided as well as a schedule of
payments made.
1.5. Each time a payment is submitted to IFAD for replenishment, justification or for a direct
payment a copy of the Contract Monitoring Sheet is also submitted.
1.6. The portal should have an area where:

a proposal for a procurement action can be submitted to IFAD for no-objection;

IFAD can record the NO

Project can upload the contract (C10)

Project can monitor the contract (C11)


1.7. This document only relates to the provision of an area for contract monitoring.
Procurement plans and submission of No-Objections will be defined separately.
2. Functionality for portal
1.8. There should be an area available which replicates the format of Form C11 (see
attachment). In each of the shaded areas there should be the possibility for the B/R to
upload scanned documents which can then be accessed both by the B/R and by IFAD staff.
1.9. As with other areas in the portal, the uploaded documents will not be retained in the portal
as a document management system, but will be interfaced to the document management
system of IFAD with a link being retained in the portal to allow the information to be
accessed by users both internal and external to IFAD.
1.10.
The project name and acronym will be a list of values from which the user selects,
with only those Accounts being available to which the user has access.
1.11.
When inserting payments issued, the initiator will be invited to select a WA from the
list of disbursements in order to link the WA to the contract monitoring. It will not be
mandatory for the payments to be linked to a WA. This means that it will be possible to
update the contract monitoring form and then link it to a WA.

If the payment is a direct payment then the contract monitoring area should be
included in the links on Form 100 for review by the approver role at the B/R level and
by IFAD staff when reviewing the WA.

If the payment is included in the WA, the user will have the possibility of linking the
contract monitoring to a WA and then either to scanned documents (101,102) or to
the individual forms

Section VI. Technical Requirements

150

Appendix 7 Contract Monitoring


1.12.
Whenever a payment is inserted, the system will compare the total payments with
the total contract value. If the total of the payments is greater than the total contract value
(including amendments), the following error message will be given to the Author and also
included as a warning message on the Contract Monitoring Form:
Warning: the total payments are greater than the value of the contract.
1.13.
The linking of the Contract monitoring and Form 100 will be reciprocal i.e. it will be
possible to link from Form 100 and the subsidiary forms to the Contract monitoring and
from the Contract Monitoring to the WA forms.
1.14.
Each user of the portal be it a B/R, PMU or IFAD user must have the possibility of
navigating easily between the contract monitoring and the individual WAs.
1.15.
It should be possible to link the contract monitoring to more than one WA.
1.16.
A contract can be in one of 2 statuses: open or closed. Once all payments have been
made against the contract or the residual value is zero, the initiator will have the possibility
of changing the status of the contract to closed. The status can only be changed to closed
once all WAs which reference the contract monitoring have been paid. Once the status is
closed, it will not be possible to link to a WA and hence will not be proposed in any picklist
of contract monitoring
1.17.
There should be the possibility for the initiator to select a contract monitoring by
project, by contractor, by status or insert a new contract monitoring sheet.

Section VI. Technical Requirements

151

Appendix 7 Contract Monitoring


FORM C-11- CONTRACT PAYMENT MONITORING FORM
(ENTER PROJECT NAME AND ACRONYM)
(Contract Number: as per contract register)
Description of
Contract:
Procurement
File No.:

xxx

Date(s) of No
Objection:

Contract
Officer:

Comp.:

xx/xx/xx

Name and Address


of
Supplier:
Bank Details:

e-mail:
telephone:
Contract Summary
(ENTER CURRENCY)
Document
Original Contract
Amendment (AM-1)
Amendment (AM-2)
Amendment (AM-3)
Total Amount

Contract Reference

No.

Amount

Dates (start/end)

Bank Securities or
Bonds ( -- currency)
Document

Name of Financial Institution

Date

Amount

Expiry
Date

Extension

Advance Payment
Performance Bond
Other
Monitoring of
Payments

Payment Schedule
Milestone Expected
Amount

Total
Amount
Notes:

Progress
Certificate
No.

Date

Currency (Default to currency of contract)

Payments Issued
Invoice No.

Payment Amount
Date
Paid

Cheque
or WA
No.

Financial Controller:
Signature

Programme
coordinator:

Signature

Balance Due
on Contract

Section VI. Technical Requirements

152

Appendix 8 Submission of Recovery Schedule - (detail description)


1. Background
1.1. For those Accounts managed as an imprest account, IFAD pays an advance to the account at
the beginning of the loan period. This is used to pay for project expenditure and is
replenished as WAs are submitted. Towards the end of the financing, the B/R submits a
recovery schedule to plan how the advance paid at the beginning of the project will be
repaid.
1.2. Generally, towards the end of the financing, for each WA submitted, the project plans that
a certain percentage (or amount) will be offset against the advance and a certain
percentage (or amount) will be paid as a replenishment.
1.3. CFS provides an excel spreadsheet to the project in order to plan the recovery. Once
submitted by the project this is reviewed by the FO to ensure that the advance will be
recovered before closure. If necessary the recovery schedule may be amended by CFS to
accelerate the recovery.
2. Functionality
1.4. The portal will contain a form for the submission of the recovery schedule. The format of
the form is included in the Appendix.
1.5. The initiator will select the financing from those which s/he has access to. Once selected
the fields shaded as below will be automatically populated from information in FX.
1.6. The recovery schedule will be completed in the currency of the special account or advance
account. Hence where currency is shown as a header in the first section, this should default
to the currency of the payments made against the Category Type SPL or ADV. The
currency of the Justification area should default to the same currency. DEN is the
denominated currency of the financing and this will be calculated at the historic exchange
rate at the date of payment of the tranches which form the outstanding advances or special
account.
1.7. There will be a recovery plan for each special or designated account. Thus the initiator will
select the appropriate account from a picklist of accounts for the relevant financing. The
picklist will contain all those transactions with Category Type SPL or ADV where there
are outstanding amounts.
1.8. The initiator will be required to complete the information concerning the advance account
and the proposed recoveries. The field shaded as below will be calculated automatically

1.9. Once the recovery schedule has been completed the fields shaded as below should be zero
amounts. The initiator will have the possibility to save the recovery schedule or submit to
IFAD.

Section VI. Technical Requirements

153

Appendix 8 Submission of Recovery Schedule - (detail description)


1.10.
Once submitted the system will check that the required fields are zero and if not the
initiator will receive the below warning message and will not be able to proceed unless the
fields are zero.
Warning: the recovery schedule does not cover the full amount of the advance. Please
adjust and resubmit.
1.11.
On submission the recovery plan will be routed to the FO for acceptance and the FA
for information. The FO will have the possibility of accepting or rejecting the recovery
schedule with the possibility of inserting comments which will be routed back to the
initiator. The following notifications will be sent to the initiator:
On acceptance: The recovery schedule for financing xxx has been accepted by IFAD
On rejection: The recovery schedule for financing xxx requires amendment, please see the
comments below for further information, together with the comments provided.
1.12.
The recovery schedule should be available for access to review and to change by the
FA and FO during the WA process.
1.13.
Once the recovery schedule has been submitted a second area below will show the
actual recoveries made. This will be populated by all justification transactions processed
against Category Type SPL and those justification transactions for Category Type ADV
which are processed against the advances selected at point 2.4 above for the particular
financing.
1.14.
The planned recovery schedule together with the actual recoveries will be available
for the initiator to view. The initiator will be able to amend the area for planned recoveries,
but not the actual recoveries information.

Section VI. Technical Requirements

154

Appendix 8 Submission of Recovery Schedule - (detail description)


RECOVERY PLAN
TO THE SPECIAL OR ADVANCE ACCOUNT
IFAD Loan/Grant No.:

IFAD Loan/Grant Amount (SDR)

Borrower:

Loan Completion Date:

0.00

DD/M M /YY

Loan Effective Date

Loan Closing Date:


DD/M M /YY

(Today) Date:

REMAINING # OF MONTHS TO CLOSING DAT


M ONTHS

DD/M M /YY

WA No.

Date

Unjustified balance

Local
Currency

USD

DEN
USD

Authorized Allocation or
Outstanding advance

DEN

0.00

0.00

Recovery Amount
(USD)

Cumulative
(USD)

JUSTIFICATION:
S/N

Period covered by WA

WA No.

(Expected) Date of
receipt

Estimated value
Local Currency

Estimated value
(USD)

Proposed
Recovery %

Nov-13

0.00

0%

0.00

0.00

Dec-13

0.00

0%

0.00

0.00

Jun-14

0.00

0%

0.00

0.00

Oct-14

0.00

0%

0.00

0.00

Dec-14

0.00

0%

0.00

0.00

Jan-15

0.00

0%

0.00

0.00

0.00

0.00

0.00

0.00

0.00

0.00

10

0.00

0.00

11

0.00

0.00

12

0.00

0.00

13

0.00
TOTAL

0.00

0.00

0.00
TRUE

Actual recoveries
Advance
(USD)

WA No.

Advance (DEN)

Date

Amount recovered
(USD)

Amount
Outstanding Advance
recovered (DEN)
(USD)

Outstanding
Advance (DEN)

Section VI. Technical Requirements

155

Appendix 9 Reporting Requirements


1. Background
The reporting requirements for the portal for the B/R concerns three main areas:

Dashboards with drilldown - information which the B/R will query on in order to be able to drill down and obtain
information on the portfolio (i.e. dashboards);
Self-service for access of documents - information which is not currently made available directly to B/R; and
Self-service for running of reports - reports which the B/R will be able to run in order to obtain information

This document concerns only the reporting for the B/R (including debt servicing) and does not deal with reporting for
donors (reporting for donors is not in scope for this contract).
2. General Requirements
The information to be made available should be presented in a modern user friendly fashion in a dashboard format.
There should be links between areas facilitating user navigation.
Access of users to reports will be limited to projects, countries, recipients, funding source or a combination of these,
depending upon the overall access of the user.
Once a user has selected a single type of financing, navigation to different areas should keep the same financing
proposed with the option to select another (depending on the access of the individual).
The reports should be made available so that the user can run and obtain up-to date information as well as where
specified, run the reports at dates selected by the user.
There should be the possibility to export and download reports and pages to excel as required.
Where information is generated on a periodic basis (for example the billing statements and debit advices),
notifications should be generated to inform the user that the information is available on the portal. In the case of
billing statements and debit advices, this means linking with the distribution of these documents by RMT.
On each page there should be links to

Help information
Glossary of terms
How to contact IFAD
Policy documents

Section VI. Technical Requirements

156

Appendix 9 Reporting Requirements


3. Overview of pages in portal and links
The table below provides an overview of the different pages and reports which are required. The detail of each of the pages/reports are shown in the relevant section
as numbered.
Information on projects
Page
Info
Short
description

Reports
currently
available

Drilldown

Information for Borrowers (i.e. on loan status)

My portfolio

Project at a
glance

Financing
Overview

Disbursements

Debit
Advice

Designated
&
Advance Account

(4)
Entrance point
for
project
information
Summary of all
active
financing
instruments by
project

(5)
Overall
operational
information
on a project

(6)
Information on
individual
financing
including
status of funds

(7)
All
disbursements
for a single
financing

(8)
Self-service
to
run
report for
single
payments
made
by
IFAD to the
project

(9)
Information on
all
the
designated and
advance
accounts
for
each financing

Report 4.1
Report 4.2
Report varies
depending
upon access of
user
No report
currently
available info
from FX
To 5.1
Project
number
To 6.1
Financing no
To 7.1
Disbursed

5.1
Information
from GRIPS

6.1 Information
from FX
6.2 - Status of
Funds

7.1 - Historic
Transaction
report

8.1 Debit
Advice

Report 9.1
designated or
advance account
Report 9.2
Treasury pooled
accounts
Information
from FX
requires
customisation

To 7.1
Amount
disbursed
To 9.1 or 9.2
Financing no
To reference
docs

To Withdrawal
application WA
no
To 8.1 WA no

IFAD
disbursements
to B/R
(10)
This page will
give
information on
the history of
total
disbursements
in a graphical
format

10.1 Graph
derived from
Disbursement
report

Financing
status

Individual
loan status

Billing
Statement

Instalment
schedule

(11)
Entrance point
for
Loan
information
Information to
Borrowers on
status of all
loans how
much has been
drawn
down
and how much
has been repaid
11.1 Loan
Disbursement
and
Repayments
Report

(12)
Information
to Borrowers
on individual
loans, how
much
has
been billed
(principal
and interest)
and
how
much
has
been repaid
12.1 Historic
repayment
File

(13)
Self-service
to run billing
statement
for
single
amounts
billed
by
IFAD

(14)
Information to
Borrowers on
future
instalments,
both
for
individual loans
and for all

13.1 Billing
Advice

14.1 Instalment
amounts by
Borrower and
due date
Requires
modification as
only has data
from FX i.e. no
analysis of data
pre 11-13

To 7.1
Disbursed
Amount
To 12.1
Account
number
To reference

To 13.1
Amount
Billed

Section VI. Technical Requirements

157

Appendix 9 Reporting Requirements

User to be
able to run
at any date
and export
to excel

Amount
To 10.1
Financing
number
where user has
access
To reference
docs
Financing
number
No

Financing
number

No

Yes

docs
Financing
number

Export to excel
only

Yes

Run at any date

No

Yes

Yes

Yes

Yes

Section VI. Technical Requirements

158

Appendix 9 Reporting Requirements

4. My portfolio
My portfolio will be the point of access of users. If a user has access to more than one project or
country, there should be the possibility to search for financing. The results of the search will depend
upon the access of the user. If the user has access to only one project the information will be shown
directly. The user will also have the possibility of designating financing as favourites to avoid having
to search each time.
Header search function
12

Title
Borrower or Recipient

Financing Type

Options
Country Name
PMU
Implementing Agency
Recipient

Comments
The options available
will depend upon the
access of the user and
will need to be defined
by the countries. All
options
should
be
available to make the
access as wide or
restricted as necessary

All or drop down list of


options from Attachment
1 to Appendix 1
S Status
All or drop down list
from Attachment 1 to
Appendix 1 multiple
choices are allowed
S Project
All or drop down list To check with users if
from Attachment 1
they require name or
(alternate)
account
number (expect name)
S Funding source
All or drop down list To check with users if
from Attachment 1 to needed
Appendix 1
S Financing number
All or drop down list
(FX Account number)
from Attachment 1 to
Appendix 1
Brings back following data for each project with the projects shown as a list. The data will be
presented in tabular format as shown below together Not only will information be provided on
projects and the financing instruments of the projects but also there will be graphical representation
in pie charts and bar charts of the amount financed and disbursed by project and comparing the
total financing with the total disbursements. Where the denominated currency of the financial
instruments differs, the graphs will be shown by currency.
The different types of access which are envisaged for the various groups of users are:

12

Borrowers or recipients view all financing for the country of reference or for the noncountry recipient

A = Standing data dependent on access


S = Standing data

Section VI. Technical Requirements

159

Appendix 9 Reporting Requirements

Implementer (Project Management Unit, Implementing Agency) view information on all


projects which the PMU or implementing agency is involved in the implementation
Cooperating Institution view information on all projects which they are involved in the
implementation
OFID view information on all projects financed by OFID i.e. for which IFAD is the
cooperating institution

Section VI. Technical Requirements

160

Appendix 9 Reporting Requirements

4.1. Borrowers or Recipients


The users who will expect to access this type of report are the following: Ministries, Permanent Representative to IFAD, Cooperating Institution, OFID and Non-Country Grant
Recipients
Borrower or Recipient: xxxxx
Project
name

Project Number
Financing Number

ABCDE

1447

Alternate
Account Number

Ccy

Financing Amount

Financing Type

Status

Disbursable
Date

Closing date

Completion
date

Disbursed
amount

Undisbursed
amount

Percentage
disbursed

100000363100

123

SDR

19 600 000.00

LOANS

Disbursable

21/03/2011

30/09/2018

31/03/2018

4 896 299.21

14 703 700.79

16.50%

100000447900

123B

SDR

8 450 000.00

LOANS

Signed

8 450 000.00

0.00%

100000363200

456

SDR

630 000.00

74 272.70

555 727.30

11.80%

100000448000

456B

SDR

650 000.00

LOAN
GRANTS
LOAN
GRANTS

650,000.00

0.00%

SDR

39 330 000.00

4 970 571.91

33 709 428.09

12.64%

2,498,601.63

75.14%

Total

ABCDE

100000274900

789

SDR

10 050 000.00

LOANS

100000275000

910

SDR

635 000.00

LOAN
GRANTS

SDR

10 685 000.00

Disbursable

COMPONENT

Signed

21/03/2011

30/09/2018

31/03/2018

COMPONENT

Disbursable

26/06/2008

30/09/2017

31/03/2017

7 551 398.37

Disbursable

09/07/2008

30/09/2017

31/03/2017

635 000.00

100.00%

8 186 398.37

0.00

76.62%

1571
100000415000

124

SDR

44 140 000.00

LOANS

100000415100

126

SDR

630 000.00

LOAN
GRANTS

SDR

44 770 000.00

SDR

3 380 000.00

ASAP GRANT

SDR

950 000.00

LOAN
GRANTS

Total

ABCDE

COMPONENT

1376

Total

ABCDE

Date: As at 25/5/15

COMPONENT

Disbursable

12/11/2014

31/12/2020

30/06/2020

1 707 159.26

42 432 840.74

3.87%

Disbursable

12/11/2014

31/12/2020

30/06/2020

128 161.27

501 838.73

20.34%

1 835 320.53

501 838.73

4.10%

110000174500

200000094500

200000094500

COMPONENT

Enter
Force
Enter
Force

into

31/12/2023

30/06/2023

3 380 000.00

0.00%

into

31/12/2023

30/06/2023

950 000.00

0.00%

Section VI. Technical Requirements

161

Appendix 9 Reporting Requirements


Total

SDR

4 330 000.00

0.00

950 000.00

0.00%

Section VI. Technical Requirements

162

Appendix 9 Reporting Requirements

Financing Amount (in SDR)

ABCD
EFGH
IJKLM
NOPQR

Disbursed Amount (in SDR)

ABCD
EFGH
IJKLM
NOPQR

Financing Amount compared to


Disbursed Amount ( millions of SDR)
50.00
45.00
40.00
35.00
30.00
25.00

Financing Amount (in SDR)

20.00

Disbursed Amount (in SDR)

15.00
10.00
5.00
0.00
ABCD

EFGH

IJKLM

NOPQR

Section VI. Technical Requirements

163

Appendix 9 Reporting Requirements


4.2. PMU
Project: ABCDE
Project
name
ABCDE

Date: As at 25/5/15

Project Number
Financing
Number
1447

Alternate
Account
Number

Ccy

Financing
Amount

Financing Type

Status

Disbursable
Date

Closing date

Completion
date

Disbursed
amount

Undisbursed
amount

Percentage
disbursed

100000363100

123

SDR

19 600 000.00

LOANS

Disbursable

21/03/2011

30/09/2018

31/03/2018

4 896 299.21

14 703 700.79

16.50%

100000447900

123-B

SDR

8 450 000.00

LOANS

Signed

8 450 000.00

0.00%

100000363200

456

SDR

630 000.00

Disbursable

74 272.70

555 727.30

11.80%

100000448000

456-B

SDR

650 000.00

LOAN
COMPONENT
GRANTS
LOAN
COMPONENT
GRANTS

650,000.00

0.00%

SDR

39 330 000.00

23 709 428.09

12.64%

Total

21/03/2011

30/09/2018

31/03/2018

Signed
4 970 571.91

Section VI. Technical Requirements

164

Appendix 9 Reporting Requirements

Financing Amount in SDR

Disbursed amount in SDR

L-I--801-

L-I--801-

L-I--801-B

L-I--801-B

G-I-C-1159-

G-I-C-1159-

G-I-C-1159-B

G-I-C-1159-B

Millions

Financing Amount compared to


Disbursed Amount ( millions of SDR)
35.00
30.00
25.00
20.00
15.00
10.00
5.00
0.00

Financing Amount
Disbursed amount

Section VI. Technical Requirements

165

Appendix 9 Reporting Requirements


5. Project at a glance
By clicking on the project ID, the user will be directed to a page showing an overview of the
project. Full details of the information to be shown has yet to be defined. An initial example is as
follows:
5.1. Project at a glance
All the information below is available in GRIPS
Project short name: ABCD
Country:
Project name: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Project number: 1447

Project Overview - Total

USD

72 159 083.00

Financiers
IFAD Loan
IFAD Additional Loan
IFAD Grant
IFAD Additional Grant
Total IFAD

USD
26 999 850.00
12 999 660.00
999 400.00
998 680.00
41 997 590.00

National Government
National Government - additional
Total National Government

15 342 900.00
3 977 351.00
19 320 251.00

Beneficiaries
Beneficiaries - additional

8 814 400.00
2 026 842.00
10 841 242.00

Environmental and Social classification

XXXXXXXXXXXXX

Key Dates
Start date
End-date

14/05/2007
30/09/2018

Innovative Features
The project has a number of features that are innovative in the context of rural communities (i)
introduction of a new integrated approach to irrigation system improvements in which user
involvement from branch canal downward will ensure completion of improvements; (ii) establishment
of WUOs at the branch canal levels, with links to the farm level water management committees; (iii)
replication of the IFAD-supported farming systems research approach, which is adjusted to local
conditions to render it demand- and market driven; and (iv) introduction of a participatory extension
approach to maximize the benefits of irrigation improvements by bringing together, for the first time,
extension staff from irrigation advisory services to deliver a harmonized message on crop and water
use to the farmers.
Project Components
Community Development

Section VI. Technical Requirements

166

Appendix 9 Reporting Requirements


6. Financing overview
If accessed from the My Portfolio page the Financing Overview will show the information for the
selected financing instrument. If Financing Overview is used as the point of entry, the user
should be able to select the financing which they wish to see the Overview for.
6.1. Financing Overview Header
The financing overview for each type of financing will have the following information:
Project name: ABCDE
Financing:
100000363100
Financing Overview
Data as of 25/5/15

Country: XXXXXXXXXXXXXXX
Status: Disbursing

123

Currency

XDR
19 600 000.00

Amount Financed

Cancelled or reduced

Total Utilized

4 896 299.21

Total Available Amount

14 703 700.79

24.98%

Percent disbursed

Key Financing Dates


Approval
Signing
Effective
Completion
Closing

17/12/2009
15/02/2010
16/02/2010
21/02/2018
30/09/2018

In process
-

Withdrawal Applications submitted

Estimated funds available

14 703 700.79

There will be drilldown from Total utilized to the Disbursements page in section 3.
The financing Overview should default to be in the currency in which the financing is
denominated, be it XDR, USD or EUR or other. The user will have the possibility of changing the
currency to one of SDR, EUR, USD or local currency for the country concerned. Where the
currency is changed from the denominated currency all figures will be calculated at the current
exchange rate of the date that the information is provided. A message will be included
explaining the exchange rate used.
Project name: ABCDE
Financing:
100000363100

Country: XXXXXXXXXXXXXXXX
Status: Disbursing

123

Financing Overview
Data as of 25/5/15
Currency
USD
Amounts are translated from the financing denominated
Currency at the exchange rate of 0.710769
Amount Financed

Cancelled or reduced
Total Utilized

Total Available Amount


Percent disbursed

27 575 766.53

6 888 734.89
20 687 031.64

24.98%

In process
Withdrawal Applications submitted

Estimated funds available

20 687 031.64

Key Financing Dates


Approval
Signing
Effective
Completion
Closing

17/12/2009
15/02/2010
16/02/2010
21/02/2018
30/09/2018

Section VI. Technical Requirements

167

Appendix 9 Reporting Requirements


6.2. Status of Funds
The Status of Funds will be shown below (see screen shot the screenshot has been reorganised
and information excluded where it is already included in the above table). This report needs to
be amended to display the status of funds in other currencies where selected in the above table
and to include the percentage financed by IFAD (Attachment 1 to Appendix 1 item 255).
In converting the status of funds from the denominated currency to the currency selected by the
user, the following exchange rates should be used:

Allocation: as at the date of approval. This information is available in GRIPS


(Peoplesoft)
Disbursed: composite of actual exchange rates at the date of disbursement for
conversion to USD. For other currencies to use the exchange rate at the date of
running of the report.

A note should be included in the status of funds, explaining the exchange rate. The exchange
rates are available in Peoplesoft (GRIPS) for the allocation and for the disbursed from 2 tables in
Flexcube (current exchange rates and historical).

Section VI. Technical Requirements

Appendix 9 Reporting Requirements

168

Section VI. Technical Requirements

169

Appendix 9 Reporting Requirements


7. Disbursements
7.1. Historic Transaction Report
This page will give details of the disbursements for the financing. It will be accessible from the
Disbursed Amount in My portfolio (section 4) and also from the Amount Utilised in the Financing
Overview (section 6). If Disbursements is used as the point of entry, the user should be able to
select the financing for which they wish to see the Disbursements.
Historic information will be provided and the total of disbursements will agree to the Total
Utilized on the Financing Overview page. The current report which exists in BI is the Historic
Transaction Report. The users will be able to export the information to excel. The explanation
notes on the Historic Transaction Report will be included as a footnote.
Once eSubmission for WA has been implemented any WA processed through the portal will
have the link to the WA notification/form used for submission.
Users will be able to sort the WA by any of the header fields.
From the payment, there will be a link to the self-service to generate the relevant debit advice
(Section 8).
The user will also be able to run the report for as at a specific date. This means allowing the user
to run reports through BI. This report will be exportable to excel.

Section VI. Technical Requirements

Appendix 9 Reporting Requirements

170

Section VI. Technical Requirements

171

Appendix 9 Reporting Requirements


8. Debit Advice
8.1. Debit Advice Report
The user will have the possibility of re-generating the relevant debit advice. If a payment is
selected, the relevant RFD field will be automatically populated. The user will also be able to
change the financing number and other data in order to use self-service and generate the debit
advice.

9. Designated Account or Advance Account


There will be a page available with information on the bank account details for all designated
accounts and Advance Accounts. This will be accessible from a tab
Different information will be presented depending on whether the account is managed under the
imprest method (Category = SPL) or Revolving Fund (Category =ADV). The information with which
this page will be populated is available in FlexCube, however there is no report currently available
which provides the information. In addition, the ability to identify the data easily is dependent upon
a remarks field, which is not always complete nor is standard text used. Hence it will be necessary to
be able to validate this information as each loan or grant starts to utilise the portal. Furthermore,
where the only payments to the bank account have been made pre-Flexcube, the banking
information data is not held in FX, but can be obtained from the Query by W/Application, Beneficiary
report in DW.
Given the difficulties inherent in identifying systematically the designated or advance account, there
are 2 alternatives to present this information:

All banking information is presented i.e. including that of beneficiaries of direct payments
Request a customization of Flexcube where by a flag is introduced to be able to flag the
relevant accounts as designated and/or advance accounts.

The information will be presented in the currency of the special or advance account.

Section VI. Technical Requirements

172

Appendix 9 Reporting Requirements


Two reports are required:

Designated or advance accounts by financing instrument


Pooled Treasury accounts (see paragraph below)

9.1. Report of designated or advance account


For Imprest accounts
Account - 1
IFAD Account number
Account Holder
Account Holder's Bank
Account Number
Current Authorized Allocation USD

100000363100
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
CENTRAL BANK OF ABC
408248526
1 500 000.00

Advance to Account
Justifications

USD
USD

1 500 000.00
-

Total deposits
Documented
Outstanding balance
Transactions in process

USD
USD
USD
USD

3 039 717.61
1 539 717.61
1 500 000.00
-

Account - 2
IFAD Account number
Account Holder
Account Holder's Bank
Account Number
Current Authorized Allocation USD

100000363100
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
CENTRAL BANK OF ABC
19265161257
1 500 000.00

Advance to Account
Justifications

USD
USD

1 500 000.00
-

Total deposits
Documented
Outstanding balance
Transactions in process

USD
USD
USD
USD

1 500 000.00
1 500 000.00
-

Section VI. Technical Requirements

173

Appendix 9 Reporting Requirements


For Imprest account with justifications
Account - 1
IFAD Account number
Account Holder
Account Holder's Bank
Account Number
Current Authorized Allocation USD
Advance to Account
Justifications

Total Justifications
Balance on Account
Total deposits
Documented
Outstanding balance
Transactions in process

USD
USD
USD
USD
USD
USD

100000248900
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
CENTRAL BANK OF ABC
254082177290
1 300 000.00
1 300 000.00
(253 642.86)
(575 206.44)
(353 017.24)
(118 133.46)
(1 300 000.00)
-

57 JUST
62 JUST
64 JUST
65 JUST

USD
USD
USD
USD

12 111 487.07
12 111 487.07
-

Account - 2
IFAD Account number
Account Holder
Account Holder's Bank
Account Number
Current Authorized Allocation USD
Advance to Account
Justifications
Balance on Account

USD
USD

Total deposits
Documented
Outstanding balance
Transactions in process

USD
USD
USD
USD

100000248900
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
BANK OF NEW YORK
892569190607

6 847 149.30
6 847 149.30
-

For Revolving Fund account with justifications


Account - 1
IFAD Account number
Account Holder
Account Holder's Bank
Account Number

Advances to Account

100000438700
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
EQUITY BANK LIMITED
51022294452827

EUR
EUR

1
02
SOE APR 2014 A
SOE APR 2014 B

Total Justifications
Balance on Account

EUR
EUR
EUR
EUR

Total deposits
Documented
Outstanding balance
Transactions in process

EUR
EUR
EUR
EUR

Total Advances
Justifications

120 054.00
107 073.00
227 127.00
(120 054.00)
(7 147.78)
(127 201.78)
99 925.22
227 127.00
127 201.78
99 925.22
-

9.2. Pooled Treasury accounts


Where the B/R uses pooled Treasury accounts for multiple projects, the portal should also
provide information on an aggregated basis. This information is not maintained in current
IFAD systems, hence the portal should contain the possibility for a Validator or Approver to

Section VI. Technical Requirements

174

Appendix 9 Reporting Requirements


indicate that Pooled Treasury accounts are used and then select the projects and financing
which are linked to that Pooled Treasury account.
If Pooled accounts are selected then there will be a page with the pooled accounts which
adds up all the information on the bank accounts above and presents it on an aggregated
basis.
10. Total IFAD disbursements to borrower or recipient
This page will provide an overview of the total amount that IFAD has disbursed to the Borrower or
Recipient on a year by year basis, cumulative and by currency. In this way the borrower or recipient
will be able to have an overview of funds provided by IFAD to the country/non-country recipient.
10.1.
Total disbursements by IFAD
The information is available in the BI report Disbursement report. The report can be run on a
from and to date basis. The graphs to be presented are for each currency and the underlying
data is obtained from the disbursement report itself.

Cumulative Disbursements (SDR)


160 000 000.00
140 000 000.00
120 000 000.00
100 000 000.00
80 000 000.00
SDR
60 000 000.00
40 000 000.00
20 000 000.00
to 1991 - 1996 - 2001 - 2006 - 2011
1990 1995 2000 2005 2010

2012

2013

2014

2015

Section VI. Technical Requirements

175

Appendix 9 Reporting Requirements

Cumulative Disbursements (USD)


1 000 000.00
900 000.00
800 000.00
700 000.00
600 000.00
500 000.00
USD
400 000.00
300 000.00
200 000.00
100 000.00
to 1990 1991 - 1996 - 2001 - 2006 - 2011
1995 2000 2005 2010

2012

2013

2014

2015

11. Financing Status


This page will only be available for loans and not for grants. Users should be able to access the
Financing Status directly (i.e. as a point of access) as well as from the My portfolio page or the
Financing Overview page. From the latter pages the user should be able to access Financing status
information from the individual Account numbers.
The purpose of this area is to give Borrowers information on loans and how much has been repaid.
As a result, access to this page will be more limited and it is not expected that the PMU will have
access.
The access of Borrowers will be linked to the information for the specific country and hence
accessing the financing status page will cause a summary of all loans to be generated. There exists a
current report in BI Loan Disbursements and Repayments Report which provides the information
required. This will be presented as shown in the following table.

Section VI. Technical Requirements

176

Appendix 9 Reporting Requirements


11.1.

Financing status report

Country:
Date:

XXXXXXXXXXXXXXXXXXX
25 May 2015

Loan denomination Currency XDR


Account number Alternate Account number Approval date
Signing Date
1000001970
123
09 December 1982
13 December 1982
1000002017
456
14 September 1984
09 November 1984
1000002183
789
15 April 1992
11 December 1992
1000002237
123
20 April 1994
30 June 1994
1000002332
456
05 December 1996
30 March 1998
1000002380
789
10 September 1998
10 December 1998
1000002442
123
04 December 1980
10 December 1980
1000002489
456
23 April 2002
29 May 2002
1000002514
789
11 December 2002
20 March 2003
1000002749
123
14 December 2006
07 March 2007
1000003631
456
17 December 2009
16 February 2010
1000004150
789
03 December 2012
1000004451
123
21 January 2013
28 December 2014
1000004479
456
13 December 2011
10 April 2012

Entry into Force


date
28 July 1983
06 December 1985
30 December 1993
25 January 1995
25 January 1999
18 June 2001
05 August 1981
09 April 2003
13 December 2004
24 September 2007
16 February 2010
16 April 2015
10 April 2012

Financed
Disbursed
Amount
Amount
Billed Amount
21 940 332.63 21 940 332.63 12 355 801.00
10 100 000.00 10 100 000.00 10 100 000.00
16 199 058.88 16 199 058.88 16 199 058.88
13 965 596.31 13 965 596.31
5 142 644.00
17 289 013.55 17 289 013.55
4 901 678.00
17 891 242.22 17 891 242.22
3 915 961.00
21 800 000.00 21 800 000.00 13 352 500.00
14 600 000.00 12 466 359.02
7 300 005.00
9 050 000.00
7 551 398.37
2 345 000.00
19 600 000.00
5 864 556.33
986 667.00
8 450 000.00
44 140 000.00
1 707 159.26
215 025 243.59 146 774 716.57 76 599 314.88

Repaid
Amount
12 355 801.00
10 100 000.00
16 199 058.88
5 142 644.00
4 901 678.00
3 915 961.00
13 352 500.00
7 300 005.00
2 345 000.00
986 667.00
76 599 314.88

Outstanding
9 584 531.63
8 822 952.31
12 387 335.55
13 975 281.22
8 447 500.00
5 166 354.02
6 705 000.00
4 877 889.33
1 707 159.26
71 674 003.32

Undisbursed
2 133 640.98
1 498 601.63
14 722 110.67
8 450 000.00
42 432 840.74
69 237 194.02

Percentage Percentage
disbursed
repaid
100.00%
56.32%
100.00%
100.00%
100.00%
100.00%
100.00%
36.82%
100.00%
28.35%
100.00%
21.89%
100.00%
61.25%
85.39%
58.56%
0.00%
0.00%
83.44%
31.05%
29.92%
16.82%
0.00%
0.00%
0.00%
0.00%
3.87%
0.00%
68.26%
52.19%

Section VI. Technical Requirements

Appendix 9 Reporting Requirements

177

Section VI. Technical Requirements

178

Appendix 9 Reporting Requirements


In addition with being presented with the information, users will also have the possibility of running
the report for any date period they require. This report will be exportable to excel.
Clicking on the disbursed amount field will link to the disbursements page. Clicking on the Amount
repaid will allow drill down to the Individual Loan status page
12. Individual Loan Status
12.1.
Report of Status of individual Loan
This page provides a summary of the loan (as a header) and the information on amounts billed
and repaid for individual loans. The information is available in the Historic Repayment File
report currently available in BI. The information will be presented in the following format:
Project name: ABCDE
Financing:
100000363100
Loan Status
Data as of 25/5/15
Financed Amount
Disbursed Amount
Billed Amount
Repaid Amount
Outstanding
Undisbursed
Percentage disbursed
Percentage repaid

Due Date
Type
15/08/2011
I
15/02/2012
I
15/08/2012
I
15/02/2013
I
15/08/2013
I
05/11/2013 ADCH_CR_INT
15/02/2014
I
15/08/2014
I
15/02/2015
L
15/02/2015
I

Total Interest
Total Principal
Total add'l charges/(credits)

Country:
Status:

123

Currency

SDR
19 600 000.00
5 864 556.33
986 667.00
986 667.00
4 877 889.33
13 735 443.67
20%
3%

XXXXXXXXXXXXXXXXXXX
Disbursing
Key Financing Dates
Approval
Signing
Effective
Completion
Closing

Loan Denomination Currency :SDR

Amount Billed Amount Billed Payment


Delay
(DEN)
USD
Date
(Days)
2 001.59
3 192.66 15/08/2011
0
3 068.47
4 953.75 15/02/2012
0
3 257.30
5 044.91 15/08/2012
0
3 504.15
5 083.46 15/02/2013
0
4 992.08
7 573.23 14/08/2013
-1
(20.62)
(31.59) 25/02/2014
112
5 292.91
8 172.84 25/02/2014
10
6 722.72
10 279.38 26/08/2014
11
666 789.00
1 019 554.21 25/02/2015
10
12 099.53
17 126.88 25/02/2015
10
707 707.13
1 080 949.73
40 938.75
666 789.00
(20.62)

61 427.11
1 019 554.21
(31.59)

17/12/2009
15/02/2010
16/02/2010
21/02/2018
30/09/2018

Amount Repaid DEN


2 001.59
3 068.47
3 257.30
3 504.15
4 992.08
(20.62)
5 292.91
6 722.72
666 789.00
12 099.53
707 707.13
40 938.75
666 789.00
(20.62)

Under/O
ver
Payment
DEN
-

Amount
Under/Over
Paid
Amount
Payment
Currency Repaid USD
USD
USD
3 192.66
USD
4 953.75
USD
5 044.91
USD
5 083.46
USD
7 573.23
USD
(31.78)
(0.19)
USD
8 157.38
(15.46)
USD
10 276.42
(2.96)
USD
1 019 554.21
USD
17 072.68
(54.20)
1 080 876.92
(72.81)
61 354.49
1 019 554.21
(31.78)

(72.62)
(0.19)

In addition with being presented with the information, users will also have the possibility of running
the report for any date period they require. This report will be exportable to excel.
Amounts billed will hyperlink to the page for the generation of the billing statement (see separate
section below)

Section VI. Technical Requirements

Appendix 9 Reporting Requirements

179

Section VI. Technical Requirements

180

Appendix 9 Reporting Requirements


13. Generation of Billing Statement
Clicking on the Amount billed will allow the user to drilldown to the self-service for the billing
statements. The current report which is in BI is the Billing Advice.
13.1.

Billing statement

14. Instalment Schedule


In addition Borrowers will be able to obtain instalment schedules for each of the loans by clicking on
the specific loan and at a total level by Borrower. The report available in BI for the individual loans is
Loan Instalment Schedule and this is not available on a total basis. Furthermore, where loans were in
existence at 1 November 2013 (date of implementation of FX) the first instalment represents all the
previous instalments billed as a lump sum.

Section VI. Technical Requirements

Appendix 9 Reporting Requirements


14.1.

Report for instalment schedule

181

Section VI. Technical Requirements

182

Appendix 10 Site Structure


Graphical representation
The following diagram is intended to represent the various areas/pages which would be
available within the portal together with the links which would be present between the pages.
This is indicative only and it is recognised that it may change once the technical solution for how
the site will be developed has been determined

Section VI. Technical Requirements

Appendix 10 Site Structure

183

Section VI. Technical Requirements

Appendix 11 Reference Documents

184

Section VI. Technical Requirements

185

Appendix 12 Roles
1. This area will allow users to view documents which have been made available by IFAD.
2. The Reference documents will be accessible both as a separate tab within the portal and also as
a link from the Financing number in My Portfolio, in Financing Overview and in Financing status.
3. There will be three main categories of documentation:
Financial Reference Documents
Operational Reference Documents
Documents from the Borrower or Recipient
4. Under Financial Reference Documents there should be directories for the following documents
with links to the documents themselves:
Financing agreement and amendments
Letter to the Borrower and amendments
Signatories
5. Under the Operational Reference Documents there will be directories for the following
documents with links to the documents themselves:
Design documents
Supervision reports, mid-term review reports and other official mission reports
6. Under the Documents from the Borrower or Recipient there will be directories for the following
documents with links to the documents themselves
Audited financial statements
Interim financial statements
Subsidiary Loan Agreement
Implementation Agreement or Memorandum of Understanding
Financial Reference Documents
7. The documents in point 3 are currently stored in RMS or on shared drives in xdesk. Although the
documents are stored in a structured way by project, there are many more documents available
within the relevant directories than those which the B/R will be required to view. Hence there is
the requirement for the development of a secure system for the upload and approval of
documents, referenced to the appropriate financing and/or project, to be made available for
viewing by the B/R.
8. There should be the possibility to access previous versions of the documents as well as maintain
an audit trail of the period of relevance of the documents.
9. The workflow for the upload of the documents is attached and provides that the Uploader will
upload the document in the relevant directory and this will be reviewed by the Approver and
approved or rejected. If rejected, the Uploader will be informed through notifications. If
approved, the document will be made available for viewing in the portal and a notification will
be sent to the B/R.
10. Routing from the Uploader to the Approver will be based upon information held in the
access/identity management system.
11. There should be the possibility for new areas to be added and for the documents to be sorted by
the B/R in order to find the document required. Each document will be tagged as to its contents
when uploaded and there will be a set of standard tags (Financing Agreement, Financing

Section VI. Technical Requirements

186

Appendix 12 Roles
Number, Letter to the Borrower, Signatories, Start Date, End Date). It will be possible to amend
the tags by an administrator role.
12. There should be the possibility to access previous versions of the documents as well as maintain
an audit trail of the period of relevance of the documents
Operational Reference Documents
13. Currently the documents in point 4 are published on the IFAD internet site with the following
structure:
Region
o Country
Project
Design Report
Supervision report 2014
Supervision report 2013
Supervision report 20xx
14. The documents should be accessible directly from the relevant project and financing as
described in paragraph 2, through the Operational Reference Documents area
15. The Concept Note refers to the following documents:
Project Status Report
Results Indicators
RIMS (Results and Impact Monitoring system)
Project Completion Reports with assessment ratings
Documents from the B/R
16. The portal will also contain an area for the B/R to submit documents to IFAD. There should be an
area for:

Audited financial statements

17. There will be an interface with GARTS/ARTS whereby audit reports and interim financial
statements submitted within the portal will be interfaced into GARTS/ARTS.
18. There should be the possibility for new areas to be added and for the documents to be sorted in
order to find the document required. It is expected that the following categories will be
required:

Interim financial statements

Subsidiary Loan Agreement

Implementation Agreement or Memorandum of Understanding


19. The new areas will be configurable in the portal and will be common for all projects.
20. Once a document is uploaded by the B/R it should be interfaced directly to RMS, leaving a link in
the portal for reference.

Section VI. Technical Requirements

187

Appendix 12 Roles

Appendix 12 Roles
The Portal will require the creation of at least the following user roles. Other roles may added as required.

Role
Borrowers/Recipients
Viewer

Responsibility
Functions
View data, run
reports;

Expectatio ns from the product


Ability to view data, obtain meaningful reports

View WA forms
Borrowers/Recipients
Author

Create withdrawal
requests, submit
banking instructions,
confirm disbursement
conditions, submit
AWPB, access Noobjection workflow
submit request for
reallocation of
categories, Submit
request for increase in
Special Account
allocation, Submit
recovery schedule,
Contract monitoring
Form

Ability to create transactions easily, without


IFAD intervention

Borrowers/Recipients
Authorizer

Authorize withdrawal
requests, banking
instructions, AWPB
submission,
disbursement
conditions

Ability to review various forms for accuracy,


compliance and to approve, thus authorizing
borrower submission to IFAD for approval or
no-objection

Uploader

Inserts and corrects


input errors to
withdrawal
applications
submitted on paper,
AWPB, Banking
instructions.,
confirmation of

Ability to create WAs easily. No routing to


Authorizer required

Section VI. Technical Requirements

188

Appendix 12 Roles
disbursement
conditions, , requests
for reallocation of
categories, requests
for increase in special
account allocation,
recovery schedule and
contract monitoring
Validator

Review withdrawal
submission(s), banking
instructions,
confirmation of
disbursement
conditions, requests
for reallocation of
categories, requests
for increase in special
account allocation,
recovery schedule and
contract monitoring

Review withdrawal submissions in accordance


with project risk rating requirements and
validate submission for payment. Depending
on Risk Rating and straight through processing
set up this is either a system role or CFS staff
role.

Reviewer - IFAD

View and review WA,


disbursement
conditions, AWPB,
request for
reallocation of
categories, request for
increase in Special
Account allocation,
contract monitoring

Review withdrawal submissions in accordance


with project risk rating requirements and
validate eligibility of expenditure. Depending
on Risk Rating, this is either a system role or
CPM staff role.

Approve WA, Approve


banking instructions
disbursement
conditions, request
for reallocation of
categories, , request
for increase in Special
Account allocation,
recovery schedule and
contract monitoring

Approve withdrawal submission for payment.


Depending on Risk Rating, this is either a
system role and/or CFS staff role. May also give
second approval for WAs where not provided
first approval.

Approver

Review and approve disbursement conditions,


AWPB, request for reallocation of categories,
request for increase in Special Account
allocation. View contract monitoring

It should be possible to assign the approver


role by function or funding source.
Review and approve disbursement conditions,
request for reallocation of categories, , request
for increase in Special Account allocation,
recovery schedule and view contract

Section VI. Technical Requirements

189

Appendix 12 Roles
monitoring
Viewer - IFAD

View data, run reports


View all forms

Ability to view data, obtain meaningful reports


across all financing.

Access should be to all


projects and financing
Administrator - IFAD

Administrate
Application access by
roles; configure or
override risk rating
category, straight
through processing,
CPM routing,
categories and
directories for upload
of reference
documents.
Phase 2
Configure new forms
for SOEs where
needed

Access administrator
Borrower/recipient

Administrate limited
application access by
role at the
Borrower/recipient
level

Responsible for assigning certain users to roles,


and adding or changing risk rating, straight
through processing information and CPM
routing information.
Phase 2
Also responsible for customising forms to
include new forms for SOEs and new categories
for reference documents.

Depending on the request submitted, this is


either an ICT role and/or CFS staff role.

Responsible for assigning certain users to


limited roles. This is an administrator role for
the client whereby the granting of certain
access will be managed by a representative of
the Borrower/recipient.

The access of users of the Borrower/Recipient for viewing and for the submission of requests will be limited to
those countries or projects which they are authorised to access. For example, the staff at the project level will only
have access to the information on a project (and probably not the debt-servicing area), while at the Ministry level
the user will have access to all the projects for a country and the debt-servicing area.
There will be no restrictions on access to data for IFAD staff, however the routing of requests and notifications will
depend upon the allocation of countries responsibilities to staff.
It should be noted that a borrower can be assigned a combination of external facing roles (i.e., Viewer, Author,
Authoriser), but not Validator, Uploader, Reviewer-IFAD, Approver or Administrator. The combination of roles
becomes that particular user's profile. In order to ensure segregation of duties, one user would not be assigned
Author and Authorizer.
The role of Validator, Uploader, Reviewer-IFAD, Viewer- IFAD, Approver, or Administrator are IFAD internal facing

Section VI. Technical Requirements

190

Appendix 12 Roles
roles that would be assigned to IFAD staff, and consistent with Segregation of Duties, that precludes the role being
held by the same person.
Viewer-B/R: Default role to be issued to all B/R by Organization Liaisons. This permits access to the Funds
website and viewing of financing to which the viewer is authorized to access.
Author: This role issued to borrowers responsible for creating transactions within the WA process. The
Organization Liaison will determine who holds this role.
Authorizer: The allocation of this role will be assigned based on the nominees included in the standard
Authorized Signatory letter which is provided by finance recipients to nominate individuals authorized to sign
WAs. CFS will approve and ICT will set up users with this role.
Validator: This role is responsible for reviewing those WAs that fail the system validation process and may
require human review of the submitted materials. This is a role that would be held by IFAD (Finance Assistant)
and would accommodate manual intervention.
Uploader: This role will be responsible for creating an electronic request when it is submitted in hard copy. This
is a role which is held by IFAD (Finance Assistant or centralised processing unit).
Reviewer IFAD: This role will be allocated to the CPM who will have the possibility of reviewing the
transactions/requests and providing comments or approving the request. Depending on the process there will be
different levels of Reviewer and the workflow should be able to route requests from Reviewer 1 to Reviewer 2 to
Reviewer 3 etc, depending upon the organizational role of the user.
Approver: This role is responsible for Approving certain transactions prior to interface to FX. This role would be
held by CFS in IFAD (Finance Officer).
Viewer IFAD. This role would have access to all forms and all reports in view mode only. This role would be
held by relevant IFAD staff (PMD staff, IFAD Country Offices staff, management)
Administrator - IFAD: This role has the responsibility for various setup tasks such as assigning roles to users,
and/or various data elements, such as project risk rating. This role could be held by CFS or ICT.
Administrator Borrower/Recipient: This role has the responsibility for certain tasks related to system access at
the Borrower/Recipient level such as the resetting of password, updating of email addresses for the distribution of
debit advices and billing statements; limited set up of users and association of access for certain roles. It is country
or recipient (for non-country recipients) specific, hence an Administrator-B/R in one country will not be able to
give access to information other than the country/recipient to which they are assigned. The role will not be able to
assign Authorizer to any user and is incompatible with the Author and Authorizer role.

You might also like