IFAD 2015 020 RFP Lot 1 Terms of Reference

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

Contents

Technical Requirements .......................................................................................................................4

A. Background......................................................................................................................................4

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

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

3.0 Supplier’s 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 .....................................................................................................................21Comprehensive Reporting ........................................................................................................................... 21Access to Key Documents ............................................................................................................................ 25Withdrawal Application for Disbursements ................................................................................................ 26Manage Banking information ..................................................................................................................... 33Link to No objection System ........................................................................................................................ 34

Phase 1.5 Functionality ..................................................................................................................35Add French and Spanish Support in the Portal ............................................................................................ 35

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

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

E. Service Specifications.....................................................................................................................45

F. Title, Copyright and Use Rights....................................................................................................55

G. Supplier’s Experience Requirements and Client References....................................................55

H. Hardware and Software requirements .......................................................................................56

I. Implementation Schedule ..............................................................................................................60

J. Required Format for Supplier’s 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.....................................811.2. Background...........................................................................................................................811.3. Features ................................................................................................................................81


1.4. WA submission options ........................................................................................................811.4.1. Options.......................................................................................................................................... 811.4.2. Current forms................................................................................................................................ 81

1.5. Input screen for external user (B/R) for online approval .....................................................821.5.1. Header – search function .............................................................................................................. 821.5.2. Advances for start-up costs........................................................................................................... 861.5.3. Withdrawal application form (Form 100) ..................................................................................... 861.5.4. Specific information to be requested depending upon type of disbursement request: ................ 90

1.6. Input screen for FA where paper WA submitted .................................................................921.7. Input screen for FA for projects where Cooperating Institution is used ..............................921.8. System validations of withdrawal application request ........................................................921.9. Cancellation or modification of a WA...................................................................................941.10. Communication of issues to IFAD.........................................................................................941.11. Creation of Notification form for approval...........................................................................951.12. List of notifications for review..............................................................................................981.13. Workflow for approval of request........................................................................................98

1.13.1. Approval of request online ....................................................................................................... 981.13.2. Approval of paper forms .......................................................................................................... 99

1.14. Submission to IFAD in an internal review system ................................................................991.15. IFAD users to be able to view and review information submitted in a user-friendly manner

..............................................................................................................................................991.15.1. Form: ........................................................................................................................................ 991.15.2. Warning messages................................................................................................................. 100

1.16. Routing to CPM for review and/or approval ......................................................................1051.17. Risk-based disbursement methodology to be applied to routing of request: ...................1061.18. Straight-through processing ...............................................................................................1071.19. Comparison of information with standing data and routing of requests for review based

upon decision trees inherent within the system................................................................1071.20. Amendment of WA by B/R .................................................................................................1091.21. Second Validation ...............................................................................................................1091.22. Approval stage....................................................................................................................1091.23. Creation of record in Records Management System .........................................................1091.24. Interface into Flexcube.......................................................................................................1101.25. Integration with Flexcube...................................................................................................1101.26. Communication of payment to B/R....................................................................................1101.27. Reporting ............................................................................................................................1111.28. Forms (Phase 2) ..................................................................................................................1111.29. Overview (Phase 2) .............................................................................................................1111.30. Input Screens (Phase 2) ......................................................................................................1111.31. Special cases (Phase 2) .......................................................................................................112Attachment 1 – Standing data......................................................................................................114Attachment 2 – status of withdrawal application........................................................................117Attachment 3 - Mapping of information on WA to information in FX.........................................118Attachment 4 – Mapping of product codes, description and categories in FX............................119Attachment 5 – Withdrawal Application forms: 100, Summary of Expenditure, 101, 102, 104 and

105 ......................................................................................................................................120

Appendix 2 - Submission of Banking Instructions - (detail description) .....................................1321. Process .............................................................................................................................................. 133

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

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


Appendix 5 – Reallocation of Category - (detail description) .......................................................1421. Background....................................................................................................................................... 1432. Functionality for portal ..................................................................................................................... 143

Appendix 6 – Increase/Decrease in Special Account Allocation - (detail description) ...............1461. Background....................................................................................................................................... 1472. Functionality for portal ..................................................................................................................... 147

Appendix 7 – Contract Monitoring - (detail description)..............................................................1491. Background....................................................................................................................................... 1492. Functionality for portal ..................................................................................................................... 149

Appendix 8 – Submission of Recovery Schedule - (detail description) ........................................1521. Background....................................................................................................................................... 1522. Functionality ..................................................................................................................................... 152

Appendix 9 –Reporting Requirements............................................................................................1551. Background....................................................................................................................................... 1552. General Requirements ...................................................................................................................... 1553. Overview of pages in portal and links ............................................................................................... 1564. My portfolio ...................................................................................................................................... 1585. Project at a glance ............................................................................................................................ 1656. Financing overview ........................................................................................................................... 1667. Disbursements ..................................................................................................................................1698. Debit Advice ...................................................................................................................................... 1719. Designated Account or Advance Account ......................................................................................... 17110. Total IFAD disbursements to borrower or recipient......................................................................... 17411. Financing Status .............................................................................................................................. 17512. Individual Loan Status...................................................................................................................... 17813. Generation of Billing Statement ...................................................................................................... 18014. Instalment Schedule ........................................................................................................................ 180

Appendix 10 –Site Structure ............................................................................................................182Graphical representation .......................................................................................................................... 182

Appendix 11 – Reference Documents..............................................................................................184Financial Reference Documents ................................................................................................................ 185Operational Reference Documents ........................................................................................................... 186Documents from the B/R........................................................................................................................... 186

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


Technical Requirements

A. Background

1.0 Glossary of Terms and Acronyms

2FA Two-factor authenticationAA Authorised AllocationAPI Application Programming InterfaceAWPB Annual Work Plan and BudgetBI Oracle Business IntelligenceBPM Business Process ManagementB/R Borrower or RecipientBorrower Portal Refers to the Borrower/Recipient PortalChecker The role in FX which approves a transactionCFS Controller’s and Financial Services DivisionCGIAR Consultative Group for International Agricultural ResearchCPM Country Programme ManagerDC IFAD Data CenterDRC Disaster Recovery CenterEJB Enterprise Java BeansEUR EuroDSBL DisbursableDW DatawarehouseEC European CommissionEOD End of Day closure process in FXFA Finance AssistantFMA Financial Management Application (currently under development)FO Finance OfficerFX Flexcube – the system used for recording withdrawals from loans and grants.GARTS/ARTS Grant Audit Report Tracking System / Audit Report Tracking SystemGRIPS Grant and Investment Projects SystemGTC General Terms and Conditions for the Procurement of ServicesGUI Graphical User InterfaceHIPC Heavily Indebted Poor CountriesICOs IFAD Country OfficesIFAD International Fund for Agricultural DevelopmentICT Information and Communications Technology DivisionMaker The role in FX which initiates a transactionNCSC National Computer Security CenterNGO Non-Governmental OrganizationOFID OPEC Fund for International DevelopmentOPEC Organization of Petroleum Exporting CountriesPDF Portable Document Format


PID Project Initiation DocumentPLF Project Life FilePMD Programme Management DepartmentPMU Project Management UnitPortal Refers to the Borrower/Recipient PortalPurchaser IFADPS PeoplesoftRBD Risk Based DisbursementsRFD Request for DisbursementRFP Request for ProposalRMS Records Management SystemRIMS Results and Impact Management SystemSDR Special Drawing RightsSOA Service Oriented ArchitectureSOAP Simple Object Access ProtocolSOE Statement of ExpenditureSupplier The contractor who is awarded the contract as an outcome of this RFP Lot 1.USD United States DollarsVAMI Value-dated Amendment InitiationWA Withdrawal ApplicationWATS Withdrawal Application Tracking System


2.0 The Purchaser

About IFAD

The International Fund for Agricultural Development (IFAD) is a specialized agency of theUnited 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 agriculturaldevelopment projects primarily for food production in the developing countries. IFAD's missionis to enable poor rural people to overcome poverty and is dedicated to eradicating ruralpoverty in developing countries. Working with rural poor people, governments, donors, non-governmental organizations and many other partners, IFAD focuses on country-specificsolutions, 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 whichrelies on funding from its Member States.

More detailed information regarding IFAD is available in the Organization’s website(http://www.ifad.org). In particular, the latest IFAD Annual Report and The AgreementEstablishing IFAD can be downloaded from the website.

In order to fully understand the business requirements for this Borrower/Recipient (B/R) Portalproject it is important to be familiar with the terminology used within this document. Theattached link provides information in an eLearning platform on Financial Management ofprojects. Key stages within the project as well as the overview of certain procedures areprovided. 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 theimplementation of a secure, single-window IFAD Borrower/Recipient Portal for providingaccess to B/R specific information and transacting business with IFAD that will integrate withseveral underlying IFAD systems. The RFP seeks a software supplier that has the capacity andknowledge to conduct requirements analysis, detailed design, development, testing, andtraining 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 FactorAuthentication; 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 businessfunctionality of the IFAD Borrower/Recipient Portal system and its components;

2. Bidder proposal on suitable technology choice for the IFAD Borrower/RecipientPortal platform – either IBM Websphere or Oracle Webcenter and relatedcomponents.

3. Sizing, licensing, supply and installation of the required processing capacity(hardware), system software, middleware, backup and associated systemmanagement tools at the IFAD Data Center and Disaster Recovery sites;

4. Confirmation of business and technical requirements as specified in this biddocument;


5. Detail design, development, integration, testing, and implementation of therequired application software and integration linkages; the Portal softwarefunctionality is to be delivered in three phases (Phase 1, Phase 1.5, and Phase 2) asdetailed in this document;

6. Integration of the application software with the identity/access managementsolution identified as part of Lot 1;

7. Integration of the application software with the two factor authentication solution inLot 2;

8. Integration with other internal IFAD systems as specified. IFAD will build and exposethe web services for the IFAD systems to integrate with the new applicationsoftware, the supplier shall use the web services provided to integrate the solutionwith 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 technicaldocumentation to IFAD as part of knowledge transfer plan;

10. Support of the application systems and related IT infrastructure for a period of atleast 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.5of the project, after the go live of Phase 1. The Supplier shall provide the costing foradding Spanish and French as languages to the Portal as a separate line item in thecost table. In addition, the Supplier shall provide the cost of adding Arabic to thePortal after Phase 2 go live.

No CommitmentThis RFP does not commit IFAD to award a contract or to pay any costs incurred in thepreparations or submission of proposals, or costs incurred in making necessary studies forthe preparation thereof or to procure or contract for services or supplies. IFAD reserves theright to award only a portion of the requirements and to award separate or multiplecontracts for the elements covered by this RFP in any combination it may deem appropriate.

3.0 Supplier’s Mandatory CriteriaSupplier’s Financial Capability

The Supplier shall furnish documentary evidence that it meets the following financialrequirement(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 bankassets and lines of credit, etc.) of at least two (2) million USD or equivalent.

Supplier’s Experience and Technical Capacity

During the past five (5) Years, the Supplier must have successfully completed the full projectcycle for at least two (2) successful contracts worth over one (1) million USD or equivalenteach involving the supply, implementation and support of a large-scale custom developed,secure, web-based transaction processing and reporting application that supports over 3000users across the internet and intranet;


Minimum required experience of project manager

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

and

2. At least five (5) years of industry experience in a web applicationdevelopment/development team leadership capacity.

Joint Venture

In the case of a Joint Venture, the partner responsible for application software developmentmust be designated the lead partner and the financial figures for all joint venture partnersshall be added together to determine the Supplier’s compliance with the minimumqualification criteria for financial and technical capability. For a Joint Venture to qualify, thelead partner must meet at least 50 percent of the financial capability (turnover andliquidity).

Regarding experience and technical capability, each Joint Venture member must by itselfhave completed at least two (2) successful contracts involving exercise of the skills for whichit has been included in the Joint Venture, preferably concerning the supply, implementationand support of a large-scale web application of similar functional/technical characteristicsand of a comparable scale. The lead partner must demonstrate at least one (1) successfulexperience with a large scale web application deployment.

Failure to comply with these requirements shall result in the rejection of the Joint Venture’sbid. Subcontractors’ experience and resources shall not be taken into consideration.

4.0 Business Objectives of the PurchaserGeneral

The IFAD Borrrower/Recipient Portal concerns the development of a secure partner websitefor IFAD’s 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 transactionsincluding the uploading of documents.

The partners of IFAD who will use the Portal comprise the countries to which IFAD providesfinancing, 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 thelives of rural people. The implementation of projects is generally undertaken by agovernment- appointed Project Management Unit or by an Implementing partner (oftenwhere specialist knowledge is required). There are currently approximately 250 activeprojects in over 100 countries which are financed by loans or grants to country recipients aswell 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, servicecharge and/or principal). The average value of an investment project is USD 33 million for anaverage period of 7 years, whereas the average value of a non-country grant is USD 1 millionfor an average period of 2 years. Furthermore IFAD provides supervision support to projectswhich are not financed by IFAD (e.g OFID financed) and receives supervision support fromother organizations (Cooperating Institution) for a limited number of projects.

It is planned that the Portal will be available through the internet to all country borrowersand 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:


Those concerned with the implementation of projects (project management unit,implementing partners, Ministry of Agriculture, Ministry of InternationalCooperation, 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 toloans and grants. This is interfaced directly to Peoplesoft for the accounting of thetransactions and the recording of cash management transactions. In addition, reporting isprovided through ad-hoc reports designed in Oracle Business Intelligence.

The Borrower/Recipient Portal will provide a suitable platform that can be integrated withFlexcube through a web-based front end to facilitate B/R self-service and submission ofrequests.

Furthermore, given that the Portal will be used by Borrowers and Recipients to request drawdowns on loans and grants (i.e. request payments) it is critical that the Portal is establishedon a secure platform with access security arrangements that will be fully tested andapproved by the IFAD technical team.

The Portal is expected to deliver functionality to route requests for review and approval toappropriate roles both external and internal to IFAD, also based upon information held inother systems internal to IFAD. Any routing of requests will need to be completelyconfigurable in order to ensure that the system is sufficiently flexible to allow for thedevelopment of IFAD processes. Currently IFAD uses an in-house developed system for therouting of withdrawal applications (Withdrawal Application Tracking System – WATS) and itis 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 ofconnectivity and bandwidth even within a country. Hence it is important that anyfunctionality available to external users be light on bandwidth and does not require the userto stay on line for extended periods of time.


Access to the system

Access to the Portal will be from computer based browsers initially. The Portal shall be browseragnostic, and support at least Chrome, Firefox and Microsoft IE. The portal architecture and designshould accommodate a responsive design with regard to access from tablets and smart phones. Theaccess from mobile devices will be limited to approval functions and to viewing reporting. There willbe no requirement to upload information from mobile devices. Access from tablets and smartphones is not in scope for this contract. However, it should be taken into consideration in theSupplier's proposal.

Users

The Portal will be accessed by two distinct sets of users: 1. IFAD users; 2. External parties. Theexternal 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


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 thosecountries or projects which they are authorised to access. For example, the staff at the project level willonly have access to the information on a project (and probably not the debt-servicing area), while at theMinistry 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 andnotifications 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 thesecondary data center (in Europe) to be used for business continuity and disaster recovery purposesby 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.


5.0 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 ofsystems vi) maintainability of applications.

c) Functional and Business Requirements for Phase 1, Phase 1.5 and Phase 2 will be evaluatedbased 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 withIFAD 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 user-experience ii) Allow for future application delivery through mobile channels iii) Enable shift toCloud 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 andmethodology proposed for the project and on-going support.

f) Supplier Experience and Client References will be evaluated based on the relevance of theexperience, and the comparability of the client systems to IFAD's Borrower/Recipient Portalrequirements.

g) Hardware and Software bids will be evaluated based on alignment with existing IFADinfrastructure and market positioning.

6.0 Proposed Payment Schedule

The Purchaser shall pay the Contract Price to the Supplier in the manner specified below. Except asotherwise noted, all payments shall be made for the portion of the Contract Price corresponding tothe goods or services actually Delivered, Installed, or Operationally Accepted, per the ContractImplementation Schedule, at unit prices and in the currencies specified in the Price Schedules of theContract Agreement. Payments will be made after Purchaser's approval of the goods or servicesdelivered 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 allRecurrent Costs, shall be paid at inception of project against Supplier’s Bank Guarantee. The Suppliershall provide a Bank Guarantee equal in amount and currency to the advance payment, and validuntil the Borrower Portal System is Operationally Accepted (see GTC clause 17 for Bank Guaranteerequirements).

(b) Progress Payments

Payments for the remaining Contract Price, exclusive of all Recurrent Costs, will be paid againstachievement of project milestones as follows:

(i) Hardware

1. Physical delivery of hardware onsite at IFAD Data Center: 50%


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 afterPurchaser’s 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 asagreed upon between the Supplier and Purchaser at contract signing time.


B. Application Development Requirements

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

Application Integration platform: Application Integration platform provides software for SOAenvironments that enables dynamic, interconnected business processes, and deliverseffective application infrastructures for all business situations. Integration software platformshould include the entire middleware infrastructure, including servers, services, and tools,needed to create, deploy, run, and monitor round-the-clock, enterprise-wide webapplications and cross-platform, cross-product solutions.

Business process management is all about collaborating between business and IT to buildbetter processes to increase business agility and improve customer satisfaction. These BPMtools should enable IFAD to optimize business performance by documenting, deploying andcontinuously 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 industryvendor product lines:

1. IBM WebSphere2. Oracle WebCenter

Supplier should ensure that their proposed solution and technology choices cover the full range ofsoftware components required to build and support the IFAD Borrower/Recipient portal includingapplication servers, web servers, business process management, identity and access management,information security and integration with IFAD’s existing IT infrastructure.

Note that the Purchaser reserves the right to award only a portion of the requirements and to awardseparate or multiple contracts for the elements covered by this RFP in any combination it may deemappropriate.

Application Design Requirements

1-ADR General Application Design Requirements

1-ADR-01 IFAD requires a web-based custom solution that will meet its businessneeds and be built on the proposed IFAD technology platform. Allmodules should be fully and seamlessly integrated with one-time dataentry. The Borrower/Recipient Portal should have a high level ofusability with a common “look and feel” achieved through an intuitivegraphical user interface (GUI).

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 tabletsand smart phones. (Though access from tablets and smart phones arenot part of the Lot 1 contract, this aspect should be considered indesign.)

1-ADR-02 The Portal must be fully integrated with IFAD internal systems includingFlexcube, PeopleSoft, Sharepoint, DataWarehouse and other systemslisted under integration requirements.

1-ADR-03 The Portal must provide General flexibility, through configurableparameters, support automated workflow and provide systematiccontrols based on IFAD processes, rules and thresholds. The systemshould be configurable and allow authorized personnel to change thebusiness process flow through the setting of parameters in processcontrol tables.

System management functions must be fully integrated. For example,setting any parameter that may be applicable to all system componentsmust be set only once. All system information moving betweencomponents must be transparent to system operations.

1-ADR-04 Multi-Language: The Portal must provide flexibility for Multi-languagesupport 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 Spanishand French to the Portal. The Supplier should estimate the cost ofsupporting Spanish and French, in addition to English, after Phase 1 golive. Language support applies to labels and other presentationelements, help, FAQs and such in the Portal, error/warning messages,and supplier provided documentation available to Portal end-users. TheSupplier is responsible for translation to Spanish and French. Data inthe system will be shown as is, i.e. if textual data in backend systems isin English, it will be shown as English in the Portal.

Adding French and Spanish support to the Portal is referred to as Phase1.5 in this document.

Adding Arabic support to the Portal after Phase 2 is also aconsideration. The design of the Portal should take right to leftlanguages (e.g. Arabic) into consideration.

1-ADR-05 IFAD Borrower/Recipient Portal Upgrade and Patches: The systemmust provide for managing upgrades and system patching for allcomponents as recommended by the manufacturer.

1-ADR-06 End User Help Functionality: The Portal shall provide End-user helpfunctionality including online context sensitive help, documentation offunctionality,and extended help for error/warning messages for all userand operator functions. The Supplier is responsible for creating the helpmaterials, 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, withauthorized IFAD staff being able to update/publish help informationdirectly to the Portal.


On each page there shall be links to Help information, Glossary of terms, How to contact IFAD, Policy documents, and Frequently AskedQuestions (FAQs).

The user must be able to submit a request for help to the Portal end-user helpdesk. The Portal shall provide a form for the user to submitthe help request.

1-ADR-07 WorkFlow & Messaging: The Portal shall provide workflow and alerts tousers who need to take action within the system. The Portal shallprovide for managing workflow processes including escalation andexception alerts.

1-ADR-08 Document Management: The Portal shall provide the ability to accessand display from, and upload documents to, the IFAD documentmanagement repositories based on Microsoft SharePoint technology.

1-ADR-09 Internet Access: The Portal shall provide secure internet accesscapability to users.

The platform shall be stable and not be subject to interruptions orunplanned downtime.

1-ADR-10 Security: The Portal solution shall meet C2 information securityclassification of the US National Computer Security Center (NCSC). Thesystem 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 systemsincluding Flexcube, PeopleSoft, Sharepoint, DataWarehouse and otherIFAD systems.

Transactions and files must not be duplicated and the system mustensure that they are not left undelivered.

Interoperability: The Portal solution shall be designed forinteroperability using industry standard protocols. The System shalladhere to a Service Oriented Architecture (SOA) and support exchangeof data through multiple protocols including Web Services andApplication Programming Interface (API).

The system must comply with industry standard conventions andinterfaces which allow the system to be interfaced easily with othersystems, 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 andPassword and it must integrate with the 2-Factor authenticationsolution in Lot 2. The system must be able to support a singlesignon experience for internal IFAD users by integrating withMicrosoft AD.

b. The system shall provide users a self-service facility to resetpasswords, while adhering to best practice security principles.

c. The system shall enforce sound password management that


includes: enforcing the use of ‘strong’ passwords; forced expiry ofpasswords at parameter-defined intervals; disablement of accountsafter a parameter-defined number of unsuccessful log-in attempts;and not permitting the re-use of a parameter-defined number ofpreviously used passwords.

d. Users shall not be able to see menu options for those functionsthey are not authorized to use.

e. Application workstations shall be logged off automatically if idle formore than a specified – but variable – period, to prevent access byunauthorized third parties if left unattended.

f. The system shall provide full audit trails for all activities within thesystem, including system accesses and messages sent and receivedand reports.

g. The system shall provide consistent and regular reporting forfinancial processing, security logs, batch and file numbersprocessed etc. which can be reported to prove system integrity andcomplete system-wide reconciliation.

h. The system shall have the ability to track and disallow theassignment 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 andalerts such as:

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.

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

user identification network terminal identification date and time kind of data accessed or transaction executed.

1-ADR-13 Reporting and Analytical Functions

A major consideration for the IFAD Borrower/Recipient Portal system isits reporting capabilities. IFAD wants to ensure that the system providesfull flexibility in report production and that running large reports doesnot impact system performance.

A comprehensive suite of reports shall be provided as indicated in theReports business functionality section. All standard reports shall beparameter driven and provide for a range of data selection, grouping,aggregation, and sorting.


Data shall be available for downloading to excel for analytical andformatting purposes.

The user shall be able to request a report execution to be run on theserver, with the system notifying the requestor when the report isavailable for viewing. This provides a better user experience for longrunning reports.

1-ADR-14 Identity Management: The system shall have the ability to distributeand delegate user administration between several administrators sothat each administrator is responsible for a particular set of users andfor a limited set of roles. For example, you can designate one useradministrator for each borrower in a country or recipient. Each useradministrator can then only create, modify, delete, inactivate andactivate users for the borrower or recipient that he or she is responsiblefor. Additionally each administrator shall be able to assign only aspecific set of roles.

The administrator role will have the ability to update and maintainemail addresses for the distribution of debit advices and billingstatements. These email address updates should be propagated toFlexcube to ensure that email address information in Flexcube stays insync with the Portal.

1-ADR-15 User Experience with data entry: The system should automatically saveany data entered by the user at frequent intervals (say every 30seconds). This auto save and any saves made by the user during inputwill not cause data validations to take place. Where data validationsexist within a process, the user will be required to submit the requestfor 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 ahigh-level design and systems architecture of application andintegration components. The architecture must clearly depict allcomponents 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 thesupplier 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 ofintegration technologies that are imposed by the proposed solution.

Requests which interface to Flexcube (FX) may be submitted at anytime during the day, however, given that there are certain times of theday or month where transactions cannot be processed by FX in order toallow other processes to execute, it is envisaged that the requests arefirst stored in a staging area in the Portal environment before beingsubmitted to Flexcube. The individual processes where this is applicableare noted in the Appendices.

2-HDR-03 The Supplier should provide an integration architecture based on thefollowing integration requirements:


1. Oracle Flexcube (FX): The Portal will have a number ofinteractions/interfaces with FX. These interfaces need to invoke FXWeb Services (SOAP or EJB) to get data from FX and to update datain FX. The updates can create, modify, delete FX data.

2. Microsoft Sharepoint: Sharepoint provides the infrastructure forIFAD's document and records management systems. The Portal willaccess Sharepoint for the following requirements: a) access anexisting document in Sharepoint and make it available to the Portaluser; b) submit a new document to Sharepoint for storage, and beable to access it later; c) delete an existing document fromSharepoint; d) retrieve a list of documents from Sharepoint anddisplay the list in the Portal. The user can then select a documentfrom the list. Different Sharepoint based systems need to beaccessed 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 underdevelopment using Ruby on Rails and PostgreSQL. Web Services willexpose the services needed by the Portal.

5. GARTS/ARTS (Audit Tracking System): Built using Ruby on Railsweb technology with PostgreSQL as the database. Web Services willbe provided for accessing data and documents. The Portal will needto access a particular document or retrieve a list of documents.Certain documents submitted in the portal will require to beinterfaced 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 accessedeither directly from Oracle tables or using procedures developed bythe Supplier.

7. People: This system contains information about IFAD staff roles,and assignments to region, country etc. The system uses Ruby onRails and PostgreSQL. As the solution for roles and identifymanagement is implemented for the Portal, there will be a need tohave an interface with People to keep the data in "People" updatedand current.

8. Two Factor Authentication (2-FA): The Portal solution mustintegrate with the 2FA solution in Lot 2.

9. Identity Management: Provided by the Supplier, this system will beused to identify the users and assign roles and privileges acrosssystems.

10. Microsoft AD: This provides userid and password based accesscontrol for IFAD users to existing IFAD systems.

11. Link to "No Objection System". This is a system underdevelopment in IFAD using an in-house workflow tool calledScriptoria. The Portal should provide a single signon experience to


the No Objection System.

12. Link to RIMS. The Results and Impact Management System, usesRuby on Rails and PostgreSQL. The Portal must provide access toRIMS, with a single signon experience.

13. End-User Helpdesk Software: The end user request for help formon the Portal must be submitted to the end-user helpdesksoftware. The helpdesk software will either be BMC Footprintshosted by IFAD or a standard helpdesk system used by the providerof end-user helpdesk services. In the case that the Supplier uses aticketing system other tha Footprints, integration must be providedto pass tier 2/3 issues which need resolution by IFAD staff.

14. IFAD.org Public site, to link to publicly available country and projectinformation.

3-DDR Supplier must provide a Methodology and Approach for DetailedTechnical Design by technology and architecture component. Suppliershould submit their methodology and approach for the detailedtechnical design for each component - presentation layer, businesslogic and rules, business process management, database design, rolesand security. The System Architecture shall include all the componentsdefined for the IFAD Portal platform.

Detail how the Supplier's Architecture and Design approach willfacilitate Portal access from tablets and smartphones in future phases.

4-GTR IFAD Borrower/Recipient Portal Performance in low bandwidthconditions: The supplier must explain how the system will be designedfor specific conditions that exist in IFAD Borrower countries includingpoor connectivity and low bandwidth conditions. IFAD requirement fordeployment the Portal to clients is a minimum of 512kbps connectivity.Please indicate application design features that will ensure goodperformance given existing bandwidth conditions (without using anoffline model). The Supplier shall use bandwidth of 512kbps and alatency of 300 milliseconds to test Portal response times for end-userfunctions. The "time to render" for the login page must be under 3seconds considering 140 concurrent users. The supplier is invited topropose additional performance optimization mechanisms for thesolution.

Testing at IFAD Rome with high bandwidth and low latency shouldshow subsecond response times for screen transaction processing.


C. Functional and Business requirements

Phase 1 Functionality

5-CRPComprehensive Reporting

5-CRP-01 GeneralC05The detailed requirements for Reporting are included in Appendix 9.C10Access to Reporting will be granted through a User/password for basic functionalitywhich do not allow to enter or approve transactions but access mainly reporting.However, 2FA may be required at IFAD discretion for reporting as well.C15The following users will have access to Reporting:

Borrowers – Viewer Borrowers –Author Borrowers – Authorizer Uploader Validator Reviewer - IFAD Approver Administrator

C20The information to be made available should be presented in a modern userfriendly fashion in a dashboard format.C25The reports should be made available so that the user can run and obtain up-todate information.C30There should be links between areas facilitating user navigation.C33Access of users to reports will be limited to projects, countries, recipients, fundingsource or a combination of these three, depending upon the overall access of theuser.C35Once a user has selected a single type of financing, navigation to different areasshould keep the same financing proposed with the option to select another(depending on the access of the individual).C40There should be the possibility to export and download all reports and pages toexcel.C45Where information is generated on a periodic basis (for example the billingstatements and debit advices), notifications should be generated to inform the userthat the information is available on the portal.C47


Some reports currently exist in Oracle BI. If the Supplier proposes to expose BIreports directly to Portal users, then additional BI licensing requirements for Portalusers must be included in the Supplier proposal. Otherwise reports will have to bewritten for the Portal using the reporting tools proposed by the Supplier.

5-CRP-02 My portfolioC55My portfolio will be the point of access of usersC60If a user has access to more than one project or country, there should be thepossibility to search for financing. The results of the search will depend upon theaccess of the user. If the user has access to only one project the information will beshown directly.C65The user will also have the possibility of designating financings as favourites toavoid having to search every time.C70Depending on the access of the user or the search carried out a list of projects willbe presented together with graphs and pie charts comparing financed amount withdisbursed amount.

5-CRP-03 Project at a glanceC72This page is designed to provide an overview on a project by project basis. Fulldetails of the information to be shown has yet to be defined, however an exampleis shown in Appendix 9. Project information is available from Peoplesoft GRIPS.

5-CRP-04 Financing overviewC75This page will provide an overview of the financing accessing standing data(reference data) in FX.C80There will also be the status of funds which is a report currently available in BI. Thereport format has been amended slightly for presentation in the Portal. This reportneeds to be amended to display the status of funds in other currencies if selectedand to include the percentage financed by IFADC85The financing Overview should default to be in the currency in which the financingis denominated, be it SDR, USD, EUR or otherC90The user will have the possibility of changing the currency to one of SDR, EUR, USDor local currency for the country concernedC95Where the currency is changed from the denominated currency all figures will becalculated at the current exchange rate of the date that the information isprovided. A message will be included explaining the exchange rate used.C100In converting the status of funds from the denominated currency to the currencyselected 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


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 allocationand for the disbursed they are available from two tables in Flexcube(current exchange rates and historical).

5-CRP-05 DisbursementsC105This 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 tothe Total Utilized on the Financing Overview page. The current report which existsin BI is the Historic Transaction Report.C110The users will be able to export the information to excel.C115The explanation notes on the Historic Transaction Report will be included as afootnote.C120Once electronic Submission for WA has been implemented any WA processedthrough the Portal will have the link to the WA notification/form used forsubmission.C125Users will be able to sort the WA by any of the header fields.C130From the payment, there will be a link to self-service to generate the relevant debitadviceC135The user will also be able to run the report as of a specific date. This report will beexportable to excel.

5-CRP-06 Debit adviceC140The 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 tochange the financing number and other data in order to use self-service andgenerate the debit advice.

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


DW.C150A customization is required in Flexcube whereby a flag is introduced to the PayeeInstructions form to be able to identify the relevant accounts as designated and/oradvance accounts, in order to overcome the issues noted in C145. This Flexcubecustomisation will be handled by IFADC155Where the B/R uses pooled Treasury accounts for multiple projects, the Portalshould also provide information on an aggregated basis. This information is notmaintained in current IFAD systems, hence the Portal should contain the possibilityfor an IFAD Role ( Validator or Approver) to indicate that Pooled Treasury accountsare used and then select the projects and financing which are linked to that PooledTreasury account. The Validator or Approver will maintain a list of pooled Treasuryaccounts in the Portal for a country and link financings to a pooled account.C160If Pooled accounts are selected then there will be a page with the pooled accountswhich adds up all the information on the bank accounts for C145 and presents it onan aggregated basis. [Note: This report should be reconfirmed before design starts.]

5-CRP-08 Total IFAD disbursements to borrower or recipientC186This page will provide an overview of the total amount that IFAD has disbursed tothe Borrower or Recipient on a year by year basis, cumulative and by currency. Inthis way the borrower or recipient will be able to have an overview of fundsprovided by IFAD to the country/non-country recipient.

C187The information is available in the BI report “Disbursement report”. The report canbe run on a from and to date basis. The graphs to be presented are for eachcurrency and the underlying data is obtained from the disbursement report itself.

5-CRP-09 Financing StatusC165Users should be able to access the Financing Status directly (i.e. as a point ofaccess) as well as from the My portfolio page or the Financing Overview page.C170The purpose of this area is to give Borrowers information on loans and how muchhas been repaid. As a result, access to this page will be more limited and it is notexpected that the PMU will have accessC175The access of Borrowers will be linked to the information for the specific countryand hence accessing the financing status page will cause a summary of all loans tobe generated. There exists a current report in BI “Loan Disbursements andRepayments Report” which provides the information required. However, this willbe presented in a more user-friendly fashion.C180The information will be hyperlinked to the disbursement page for disbursementsand to the Individual Loan Status page (see below) . Amounts billed will hyperlinkto the page for the generation of the billing statement (see separate sectionbelow).C185


The user will also be able to run the reports as at a specific date or for a specificperiod.

5-CRP-10 Individual Loan StatusC190This page provides a summary of the loan (as a header) and the information onamounts billed and repaid for individual loans. The information is available in theHistoric Repayment File – report currently available in BI.C195In addition with being presented with the information, users will also have thepossibility of running the report for any date period they require. This report will beexportable to excel.C200Amounts billed will hyperlink to the page for the generation of the billing statement(see separate section below)

5-CRP-11 Generation of Billing StatementC205Clicking on the Amount billed will allow the user to drilldown to the self-service forthe billing statements. The current report which is in BI is the Billing Advice.

5-CRP-12 Instalment ScheduleC210Borrowers will be able to obtain instalment schedules for each of the loans byclicking on the specific loan and at a total level by Borrower. The report available inBI for the individual loans is Loan Instalment Schedule and this is not available on atotal basis. Furthermore, where loans were in existence at 1 November 2013 (dateof implementation of FX at IFAD) the first instalment represents all the previousinstalments billed as a lump sum. Hence this report will require modification beforebeing presented in the Portal.

6-ADCAccess to Key Documents

6-ADC-01 GeneralD03The detailed requirements for Reference/Key documents are included in Appendix11.D05This area will allow users to view documents which have been made available byIFAD. The Reference documents will be accessible both as a separate tab within thePortal and also as a link from the Financing number in My Portfolio, in FinancingOverview and in Financing status.D10There will be three main categories of documentation:

Financial Reference Documents Operational Reference Documents Documents from the Borrower or Recipient

D15Under Financial Reference Documents there should be directories for the followingdocuments with links to the documents themselves:

Financing agreement and amendments


Letter to the Borrower and amendments Signatories

D20Under the Operational Reference Documents there will be directories for thefollowing documents with links to the documents themselves:

Design documents Supervision reports, mid-term review reports and other official mission

reportsD22Under the Documents from the Borrower or Recipient there will be directories forthe 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 DocumentsD25The 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 forviewing by the B/R.D30There should be the possibility to access previous versions of the documents as wellas maintain an audit trail of the period of relevance of the documents.D35Once documents are uploaded a notification will be sent to the B/R.D40Routing will be based upon role information and additional approval criteria.D45There should be the possibility for new categories and directories to be added andfor the documents to be sorted in order to find the document required.D50Each document will be tagged as to its contents when uploaded and there will be aset of standard tags (Financing agreement, Financing Number, Letter to theBorrower/Recipient) etc.) supported by the IFAD backend system.D55It will be possible to amend the tags by an administrator role.

6-ADC-03 Operational documentsD65The documents required are currently published on the IFAD Internet (public) site.D70The documents should be accessible directly from the relevant project andfinancing as described in D05, through the Operational Reference Documents area.

7-WADWithdrawal Application for Disbursements

7-WAD-01 Submit a requestB01When the user selects submit a request s/he will be directed to a page with optionsfor the different requests which can be submitted. The options will be available if


the underlying functionality is available. If any of the functionality is not availablebecause they are not in Portal Phase 1, the option will not be present on the page.B02The Options (Phase 1 in bold below) will be:

1. Submission of Withdrawal Application2. Submission of Banking Instructions3. Submission of Annual Work Plan and Budget4. Confirmation of Disbursement Conditions5. Reallocation of Categories6. Increase/decrease in Special Account Allocation7. Contract Monitoring8. Submission of Recovery Plan/Schedule9. Procurement plans and bid document submissions

B03Only users with Borrower – Author access will be able to initiate requests in any ofthese areas. Users with Borrowers – Authorizer access will be able to approve therequests 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. Fulldetails on user roles are included in Appendix 12.B04In the various processes, the B/R will be able to upload scanned documents. Thescanned documents do not need to be retained in the Portal, but should be routedto RMS for document management once the transaction is approved. Thedocuments should be accessible from the Portal by the B/R and by IFAD.B06For all requests concerning financing to countries the information on who to routethe notification to in IFAD will be based on the user's profile, country and role.B08The system should have the ability to track the status (including the actor who isholding 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 isrequired in order to be able to report on the time for processing. For WithdrawalApplication see Appendix 1 – 1.27.

7-WAD-02 Process - Submission of WAB10In order to submit a WA the banking instructions need to have been inserted andapproved in FX. In this way only approved banking instructions will be available tothe B/R.B12The proposed process flow for the submission of Withdrawal Applications and thedetailed requirements for the submission of Withdrawal Applications is included inAppendix 1.B14In order to submit a Withdrawal Application the B/R is required to complete certainmandatory forms. These are Form 100, Summary Sheet, Form 101, 102, 104 (A orB), 105. Recipients of non-country grants are required to submit a statement ofexpenditure as well as Form 100. An example of each of these forms is provided inAttachment 5 to Appendix 1. The standard Form 100 has been modified for the e-Submission of WA in the Portal for ease of presentation of data. Only the Form 100


will be required to be completed in the system in Phase 1 of the project: theremaining forms will be uploaded as scanned documentsB16As part of the WA process documents will be uploaded. The system should be ableto support the upload of scanned documents of an average size of 10 MB.B18Any scanned documents are to be routed to RMS for storage, once approved byIFAD, however should be accessible from the Portal by the B/R and by IFAD.B20Information 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 beaccessible from multiple locations with workflows being cross-locations.B23There will be 2 options available for the submission of a Withdrawal Application:

Through the Portal Not through the Portal

o Papero Scanned

B25Where the WA is submitted through the Portal, information on WA (Form 100 inPhase 1 and with options for Forms 101, 102, 104 and 105 in Phase 2) will beinserted into the Portal and scanned supporting documentation will be uploaded.Application is approved in the system and submitted to IFAD for processingWhere 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 thesystem by IFAD staff.B27There will need to be a separate process for projects which are not supervised byIFAD. The information transmitted by the Cooperating Institution will be inserted inthe Form 100 by IFAD staff, with no certifications or approvals required. Thenotification form will be created as for other WAs and the internal system checkswill be performed. The notification will be routed directly to the Approver. Projectswhich will follow this process can be identified from the User-defined field:Cooperating Institution in Flexcube. If this field contains a value then this processwill be followed. The full details are explained in paragraph 1.7 of Appendix 1.B28When submitting a Withdrawal Application, it should be possible to request morethan one application type (e.g. Direct payment and a replenishment or areplenishment and justification) which are expected to create multiple transactionsin FX.B29One WA may contain several requests for payment or justification. The Validatorand Approvers will need to have the possibility to treat these separately andapprove, reduce or reject individual transactions.B30Only the Validator will have the possibility of reducing the total amount of the WAas well as the allocation to categories. When the WA has been reduced thetransactions created in FX will be for the reduced amount. At the same time, oncethe transaction is approved, information on the amount reduced will be interfacedto FMA as ineligible expenditure.B32


Access to the Withdrawal Application process will be granted through a two-factorauthentication process.B35The following users will have access to the submission of WA:

a) Borrowers – Viewerb) Borrowers –Authorc) Borrowers – Authorizerd) Uploadere) Validatorf) Reviewer - IFADg) Approverh) Administrator

B40Access 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 interactionswith FX. The design of the Portal must ensure that the Portal data remains in syncwith FX, and any and all responses from FX are processed correctly within thePortal.

7-WAD-03 Common steps for all submission methodsB45

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

system4. A user-friendly ‘notification’ is created for review and approval by IFAD

with additional information. This will also contain warning messages forareas 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 maintainingtables in order to define the routing under RBD and hence change asnecessary and as the framework evolves.

6. There will be the possibility to add documentation or amend the WA ifrequired by IFAD

7. The WA will be routed for approval.8. Once approved, the relevant transactions will be created in Flexcube9. 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 methodsB50A mandatory Form 100 is to be available for the Author or Uploader to insertinformation on the WA. This will reference to certain standing data in FX.B55The Form will contain specific areas for the upload of scanned documents. Theareas will be labelled and will be available for review by the Authorizer, Validatorand Approver.


B60Various system validation checks will take place to ensure the completeness andaccuracy of information included. These validation checks are all currently availablein FX. Some are currently activated in FX at the point of entry of data and some areat the point in which a transaction is saved. These system checks are detailed in theeSubmission of Withdrawal Applications Appendix 1.B70User friendly notification will be created to summarise the information on themandatory form for review and approval.B75The Portal will include automatic routing:

To an external approver (Authorizer) if Form 100 is initiated by an externaluser and is to be approved online.

To IFAD if Form 100 is initiated by an IFAD user (i.e. there should be thepossibility for IFAD user to insert data in Form 100 – from the paper formand this will not require to be approved by the Authorizer)

B80The Portal will include workflow to route the request as necessary between thevarious actors. Any notification needs to be completely traceable. The request willpass through different stages and statuses in the workflow and the B/R view of thePortal must include the current status of the request.B83Where online approval is used, there will be a workflow for initiation and approvalat the borrower/recipient level prior to submission to IFAD. This approval will takeplace within the Portal.B85It should be possible to amend the routing rules associated with workflow requestsshould it be decided that certain value/type or risk of WAs need to be routeddifferently. This is particularly valid for the certification by the CPM (Reviewer –IFAD role). Hence this routing needs to be completely configurable. Full details ofthe routing required is defined in paragraphs 1.16, 1.17 and 1.18 in Appendix 1.B95Form 100 is to be fully printable also as a pdf.B105Any request submitted will pass through a series of predefined validation checkswhich may give rise to warning messages being created.B110The notification for review by IFAD will differ to that of the B/R in that additionalinformation will be included (from BI, Financial Management Application - FMA) aswell as any warning messages arising from the point above.B115The Validator and Approvers will have the possibility to insert comments, routethem back to the B/R or forward to the Approver.B120The Validator only will have the possibility of reducing the total amount of the WAas well as the allocation to categories. When the WA has been reduced thetransactions created in FX will be for the reduced amount. At the same time, oncethe transaction is approved information on the amount reduced will be interfacedto FMA as ineligible expenditure.B125The Portal will include a completely configurable workflow for risk based


disbursements. The routing of the request will depend upon the risk rating (whichwill be interfaced from the FMA), materiality both relative to the underlyingfinancing and in absolute terms, type of payment e.g. first disbursement. If the riskcategory changes, this should automatically change the process checks and flowsassociated with subsequent WAs.B130The Portal will include a completely configurable workflow for straight throughprocessing1. This will be a future option for IFAD and so the system should bedesigned in such a way to allow straight-through processing of withdrawalapplications based upon certain criteria in the workflow (see B125)B135It will only be possible for the B/R to amend or add information to a WA which hasbeen submitted if it is released for editing by IFAD. The WA will require reapprovalif any of the input fields are changed. If the only change is to upload additionalscanned documents the WA will not be routed for reapproval but it will be possibleto submit directly to IFAD.B140The B/R will be able to delete or modify any WA prior to being submitted to IFAD.B145There will be a workflow for up to two stages of approval by IFAD depending on therisk, type and value of the WAB150Upon final approval by the Approver of the WA an approved transaction will becreated within FX. [This assumes that the maker and checker functionality can becombined in FX for transactions generated by the system. If this is not possible anunapproved transaction will be created in FX for approval by the Checker]. Giventhat there are certain periods of the day or month in which transactions cannot beinput into FX (i.e. during EOD or the billing cycle), requests will be staged pendinginterface into FX. If it is not possible to create an approved transaction in FX thennotifications will be generated for any transactions which remain unapproved formore than 6 hours and a list will need to be available to the Checker to be able totrace the transaction in FX.B155Where the withdrawal application has been submitted at the project level, thereneeds to be as many transactions in FX as the FX Accounts which have beenselected. Where more than one request for payment has been made in a WA, therewill be as many transactions created in FX as different bank accounts to whichpayments are to be made..B160There will be reports available in order to ensure that the interface to FX hasworked correctly and to allow IFAD staff to follow up on any transactions whichhave failed the interface. The system should provide a set of control and trackingreports of which this is one.B165Risk ratings will not be initially visible to B/R, however there should be thepossibility 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 willauto-approve, a transaction is created in FX and the payment is processed, with no intervention from IFADstaff.


At each stage in the approval workflow, the notification will capture the names ofthe people who have approved and their role as well as the time and date of theaction taken.B173There 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 foraudit purposes.B175Worklists will be available to IFAD users of notifications to be actioned with keyinformation for each notification. The list will be completely searchable to allownotifications to be retrieved easily.B180At certain key steps within the process email notifications will be sent to emailaddresses of the B/R. At the same time there will be an area within the Portal forcommunication and a short description of the notification will be included.B185The Portal is expected to integrate with current IFAD systems as follows:

With Flexcube: to obtain standing data – see separate attachment 1 toAppendix 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.

B187Certain data will be required to be referenced which is not currently maintained inany IFAD system, nor is it planned that the data will be maintained in a structurewhich would allow the data to be referenced by a system. As a result a database ofadditional information will need to be created/defined. For each FX account thefollowing information will be required: SOE thresholds per category, Start-up costs,Percentage of AWPB which is to be financed (for revolving funds), Retroactivefinancing, Minimum WA amount, Percentage of each category financed by IFAD.This database must include information from Flexcube to allow cross referencinge.g. for the SOE thresholds per category, the reference data would be the categorynumber and description. It is not mandatory that all the fields are completed.B188The data at B187 would be input by the Uploader or Validator role and would beapproved by the Approver roleB190At the relevant point (after confirmation of execution of payment by the bank) thedebit advice is generated and is sent to the B/R via email. This is a current processavailable within the IFAD systems. The functionality required to be delivered is thatthe B/R will be able to generate the debit advice through self-service available inthe Portal (see C140). An alert in the Portal should trigger an email notification tothe user(s) who needs to view the alert. It should be possible for the user to turn


such email notifications of alerts off in his/her profile in the Portal. This will allowusers to control the number of emails they receive about alerts. [ A final decision isstill to be made on whether the sole form of communication will be through alertsor notifications in the Portal or whether emails will also be sent. So discuss with theIFAD Project Manager at the appropriate time.]

7-WAD-05 Specific functionality for non-portal processB195The 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 automaticrecognition of characters from a scanned document for IFAD staff and the variousfields in the Portal will be populated by the system thus creating an eForm. TheUploader will review the eForm against the scanned documentation, will correctwhere necessary and then will submit the eForm. Optical Character Recognition isnot to be delivered in Phase 1, but will be required in Phase 2.

7-WAD-06 Specific steps in online approval processB210

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/R4. B/R approves the WA and submits to IFAD. This will require the positive

certification of certain conditions by the Authorizer. These conditions willvary according to nature of the recipient (Non-country) and according tothe type of finding (i.e. if funding = EU).

7-WAD-07 Specific functionality for online approval processB220Where online approval is used the Form 100 will include certification boxes whichrequire to be ticked as confirmation of the conditions.B225The Portal will allow the upload of scanned documents in specific fields.

8-MBIManage Banking information

8-MBI-01 B251The proposed process flow and the detailed requirements for the submission ofBanking Information are included in Appendix 2.B255Access to the banking information process will be granted through a two-factorauthentication process.The following users will have access to Banking information functionality in thePortal:

Borrowers – Viewer Borrowers –Author Borrowers – Authorizer Uploader Validator Approver


B260There will be a form for the submission of banking information.B265The form will have the possibility to upload scanned documents – mandatory fieldB270There will be an approval workflow whereby the form is routed to the Authorizer.B275At each stage in the approval workflow, the notification will capture the names ofthe people who have approved and their roleB280Once approved the workflow will route the form to the Validator2. The Validatorwill insert the banking instructions into FX (Payee Instructions). (Portal Phase 2 willrequire the use of Optical character recognition to facilitate the insertion of data inFX. Refer requirements under Phase 2.)B285The banking information in FX will require to be validated by an Approver before itis available to the B/R for use within the WA process.B287There will need to be the possibility to reject the BI back to B/R with request foradditional information.B290Notifications will be generated informing the B/R (by email and online) of the statusof the request

8-MBI-02 The supplier shall provide advice on how to control and manage the security of theBanking Information process in the Portal to mitigate as much as possible the risksof fraud and subversion of funds.

9-LNOLink to No objection System

9-LNO-01 B637There is no appendix in which the detailed requirements for this functionality aredefined.B640The requirement in Phase 1 is to be able to access another system (underdevelopment). The Portal should provide a single sign-on experience to the NoObjection System. For Phase 2, the functionality is detailed under 10-SDC andother Phase 2 functionality.

B665IFAD is in the process of developing a workflow for No-Objections within theScriptoria system. The acceptance of the procurement information (but notnecessarily the procurement plan) will fall into this workflow. To the extent thatthis functionality is developed and delivered before the Portal, the minimumrequirements for the first phase of the Portal are that the No-Objection system beaccessible from the Portal via links with a single signon. It is preferable that the lookand feel of the Portal and the No-Objection be similar.

2 Currently the update of banking instructions is performed by CFS and hence this would be included in theaccess 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.


B670The detailed requirements for Portal Phase 2 need to be clarified, however thesecould include the linkage between the AWPB, the procurement plan, No-objectionsprovided on individual procurement actions and the contract monitoring formfunctionality.

Phase 1.5 Functionality

27-LANAdd 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 besupported in Phase 1 of the project.

IFAD is considering providing Spanish and French support in the Portal, after Phase1 go live. Supplier shall estimate the cost of supporting Spanish and French, inaddition to English. Language support applies to labels and other presentationelements, number formats, help, FAQs and such in the Portal, error/warningmessages, and supplier provided documentation available to Portal end-users. Thesupplier is responsible for translation to Spanish and French. Data in the system willbe shown as is, e.g. if textual data in backend systems is in English, it will be shownas English in the Portal.

IFAD is also considering adding Arabic support to the Portal after Phase 2. Suppliershall provide the cost of adding Arabic to the Portal after Phase 2 go live. Thedesign of the Portal shall take into account right to left languages considerations.

[Note: the discontinuity in the numbering of requirements is deliberate. Afterrequirement 9-LNO, it jumps to 27-LAN and back to 10-SDC.]

Phase 2 FunctionalityIFAD 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-SDCSubmission of Documents by Borrowers and WorkFlow

10-SDC-01 Process - Submission of AWPBB295The proposed process flow and the detailed requirements for the submission ofthe AWPB are included in Appendix 3.B300Access to the AWPB process will be granted through a two-factor authenticationprocess.The following users will have access to the submission of WA:

Borrowers – Viewer Borrowers –Author Uploader Validator Reviewer - IFAD


Approver Administrator

B305There will be a form for the submission of the Annual Work Plan and Budget. Therewill be 3 fields for data entry and a requirement to upload a scanned documentB310There will be no approval workflow at the B/R level; once completed the AWPBwill be submitted to IFADB3153

The Portal will include workflow to route and re-route the request as necessarybetween the various actors. Any notification needs to be completely traceable.The request will pass through different stages and statuses in the workflow andthe B/R view of the Portal must include the current status of the request.B320If a certain period of time (30 days) has passed by from submission and no actionhas been taken by IFAD the AWPB will automatically move into the final status ofAcceptedB325At each stage in the approval workflow, the notification will capture the names ofthe people who have approved and their roleB330Once the AWPB has been accepted the fields within the form will be available foruse by the WA submission process.B335Throughout the process notifications will be generated informing the actors whereaction is to be taken. For IFAD users these notifications will not create emails, butthere will be a worklist.B340Notifications will be generated informing the B/R (by email and online) of thestatus of the request

11-RIMSLink to Project Results and Impact Management System

11-RIMS-01 The solution should provide a link to the IFAD Results and Impact ManagementSystem (RIMS). Note that RIMS is scheduled for an upgrade in the coming year.

12-LWAIntegration of Withdrawal Application System with AWPB, Bid documents,Procurement plan etc

12-LWA-01 Process - Contract Monitoring FormB541The proposed process flow and the detailed requirements for the ContractMonitoring Form are included in Appendix 7.B545Access to the contract monitoring form will be granted through a two-factorauthentication process.

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


B550The following users will have access to the process:

Borrowers – Viewer Borrowers –Author Uploader Validator Reviewer - IFAD Approver Administrator

B555The Portal will contain an area which replicates the format of the ContractMonitoring form (C11). There will be the possibility to upload scanned documentsby the B/R. The form will reference data in FX, with picklists and fields for the B/Rto complete.B560The information in the form should be accessible by the B/R and by IFAD staff.B565When inserting payments issued in the contract monitoring area, the initiator willbe invited to select a WA from the list of disbursements in order to link the WA tothe contract monitoring. It will not be mandatory for the payments to be linked toa WA. This means that it will be possible to update the contract monitoring formand then link it to a WA.

If the payment is a direct payment then the contract monitoring areashould be included in the links on Form 100 for review by the approverrole 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 oflinking the contract monitoring to a WA and then either to scanneddocuments (101,102) or to the individual forms

B567Whenever a payment is inserted, the system will compare the total payments withthe total contract value. If the total of the payments is greater than the totalcontract value (including amendments), the following error message will be givento the Author and also included as a warning message on the Contract MonitoringForm:“Warning: the total payments are greater than the value of the contract.”B570The linking of the Contract monitoring and Form 100 will be reciprocal i.e. it will bepossible to link from Form 100 and the subsidiary forms to the Contractmonitoring and from the Contract Monitoring to the WA forms.B575Each user of the Portal be it a B/R, PMU or IFAD user must have the possibility ofnavigating easily between the contract monitoring and the individual WAs.B580It should be possible to link the contract monitoring to more than one WA.B585A contract can be in one of 2 statuses: open or closed. Once all payments havebeen made against the contract or the residual value is zero, the initiator will havethe possibility of changing the status of the contract to closed. The status can onlybe changed to closed once all WAs which reference the contract monitoring havebeen 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.B590There should be the possibility for the initiator to select a contract monitoringform by project, by contractor, by status or insert a new contract monitoringsheet.

12-LWA-02 Links between the WA process and AWPB and procurementB65If 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 andaccepted within the AWPB area in order to perform some of the checks.B90When creating a WA, if there is a contract monitoring area within the Portal, theWA submission and the contract area will be linked to allow the Author to selectthe contract against which payment is being requested.

13-CDBConfirmation of Disbursement Conditions

13-CDB-01 B341The proposed process flow and the detailed requirements for the Confirmation ofDisbursement Conditions are included in Appendix 4.B345Access to the disbursement conditions process will be granted through a two-factor authentication process.B350The following users will have access to the confirmation of disbursementconditions:


B355Disbursement condition data is not currently held in IFAD corporate systems.B360The Portal will contain a form for capturing disbursement conditions. This will beinitiated by the Validator i.e. IFAD. The form will contain boxes for free form textwith the possibility of deciding whether documents are to be uploaded or onlyconfirmation is required.B365The Portal will contain workflow for routing for approval to the various actorsB370Once approved, a page will be available for the B/R to complete and uploadscanned documents as necessaryB372At least one condition will be for verification by IFAD (issuance of Letter to theBorrower). For this condition there will be the possibility to link to the document inthe Reference documents area by IFAD staff.


B375At each stage in the approval workflow, the notification will capture the names ofthe people who have approved and their roleB377The B/R will have the possibility of linking the disbursement conditions todocuments in the Reference documents area, or submitting documents to theReference documents area through the disbursement condition functionality.B380The B/R will have the possibility to submit to IFAD and then the information will berouted to the various actors for review and approval, rejection or for putting on-hold.B385Notifications will be generated informing the B/R (by email and online) of thestatus of the requestB390Throughout the process notifications will be generated informing the actors whereaction is to be taken. For IFAD users these notifications will not create emails, butthere will be an area for notifications.B400Once the notification is approved a transaction will be interfaced to FX to changethe status of the financing to DSBL.

14-ARDAccess to Reference documents from B/R (financial statements,implementation agreements, subsidiary loan agreements, signatories)

14-ARD-01 D80The Portal will also contain an area for the B/R to submit documents to IFAD.There should be an area for:

Audited financial statementsD85There will be an interface with GARTS/ARTS whereby audit reports and interimfinancial statements submitted within the Portal will be interfaced intoGARTS/ARTS.D90There should be the possibility for new areas to be added and for the documentsto be sorted in order to find the document required. It is expected that thefollowing categories will be required:

Interim financial statements Subsidiary Loan Agreement Implementation Agreement

D95The new areas will be configurable in the Portal and will be common for allprojects.D100Once a document is uploaded by the B/R it should be interfaced directly to RMS,leaving a link in the Portal for reference.

15-MSCReallocation of categories, special account changes, submission ofrecovery schedule

15-MSC-01 Process - Reallocation of categories


B402The proposed process flow and the detailed requirements for the Reallocation ofCategories are included in Appendix 5.B405Access to the reallocation of categories process will be granted through a two-factor authentication process.B410The following users will have access to the reallocation of categories:


B415The Portal will contain an area where a request for reallocation can be submittedtogether with a scanned document. The form will reference data in FX, withpicklists and fields for the B/R to complete and a calculation of the final amount.B420Once submitted there will be a workflow for the request routing it to the variousactors and allowing the upload of scanned documentation to support the request.At any stage in the workflow, the request can be accepted or rejected, withrejections flowing back to the Reviewer and with the possibility to add commentswhich can be seen by subsequent roles.B425Once all approved the information is presented to the Validator role for input intoFX. Alternately a transaction will be created in FX for review and approval by theValidator (who will be able to change it) and/or the Approver.B430At each stage in the approval workflow, the notification will capture the names ofthe people who have approved and their role.B435Throughout the process notifications will be generated informing the actors whereaction is to be taken. For IFAD users these notifications will not create emails, butthere will be an area for notifications.B440Notifications will be generated informing the B/R (by email and online) of thestatus of the request.

15-MSC-02 Process - Increase/Decrease in Special Account AllocationB491The proposed process flow and the detailed requirements for theIncrease/Decrease in Special Account Allocation are included in Appendix 6.B495Access to the Special Account Allocation process will be granted through a two-factor authentication process.B500The following users will have access to the submission of WA:

Borrowers – Viewer Borrowers –Author


Uploader Validator Reviewer - IFAD Approver Administrator

B505The Portal will contain an area where a request for the increase or decrease in thespecial 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.B510Once submitted, a notification will be created with the summary of the changebeing requested and scanned document if any.B515This notification will follow a workflow process where each actor will have thepossibility to review the request, approve, reject and add comments.B520At each stage in the approval workflow, the notification will capture the names ofthe people who have approved and their role.B525If at any point in the process the request is rejected, the person rejecting will havethe possibility to insert comments, explaining the rejection. The comments will bevisible to subsequent reviewers.B530Once all approved the information is presented to the Validator role for input intoFX. Alternately a transaction will be created in FX for review and approval by theValidator (who will be able to change it) and the Approver.B535Throughout the process notifications will be generated informing the actors whereaction is to be taken. For IFAD users these notifications will not create emails, butthere will be an area for notifications.B540Notifications will be generated informing the B/R (by email and online) of thestatus of the request

15-MSC-03 Process - Submission of Recovery ScheduleB591The proposed process flow and the detailed requirements for the submission ofthe Recovery Schedule are included in Appendix 8.B600Access to the recovery schedule process will be granted through a two-factorauthentication process.B605The following users will have access to the recovery schedule module:

Borrowers – Viewer Borrowers –Author Uploader Validator Approver Administrator

B610


The Portal will contain a form for the submission of the recovery schedule. This willbe available for all financing. The form will reference data in FX, with picklists andfields for the B/R to complete and a calculation of the final amount.B615The recovery schedule/plan is submitted for each Special or Advance account andnot at the financing level. Hence there will need to be the possibility to submit asmany recovery schedules as advance or special accounts.B620There is no requirement to submit scanned documentation and no "approval"process. Instead the recovery plan is either accepted or rejected by IFAD.B625Once submitted there will be a workflow for the request routing it to the variousactors. At any stage in the workflow, the request can be accepted or rejected, withrejections flowing back to the initiator and with the possibility to add commentswhich can be seen by subsequent rolesB630The input fields will be available for modification by the validator and theApprover.B635Information from FX on Justification transactions related to the specific financingwill be shown at the bottom of the form.

16-WARWithdrawal Application Enhancements, Reporting

16-WAR-01 B225In Phase 2, the Portal will contain the possibility to insert data for certain forms(subsidiary forms) or upload scanned documents. Depending on whether theAuthor selects to submit scanned forms or use the IFAD forms, the Author will beproposed with the forms to complete. This selection is made on Form 100. Withinthe subsidiary forms, certain standing data will be populated from FX.Furthermore, not all fields will be obligatory.B230Excel uploader will be available for the subsidiary forms to facilitate the capture ofinformation by the Author. Where the subsidiary forms are used there will be astep to validate the information. At this point the system will check that thevarious amounts which should cross reference to each other agree and that thereare no anomalies with respect to SOE thresholds (held in database within thePortal). There should be the possibility to develop and change the forms accordingto the categories (in FX) selected. Current requirements are for 2 variations, butthis may increase.B245The subsidiary forms will all be printable.B250If the subsidiary forms are used the Form 100 can only be submitted for approvalonce the subsidiary forms have been validated.

B252Where the B/R submits paper WA the FA (or centralised processing unit) will berequired to insert the data on the paper WA into the eSubmission system insteadof into FX as this will be necessary to take advantage of the logic within theworkflow. All the relevant fields specified in Appendix 1 section 1.5.3 will beavailable for the FA to insert information from the scanned form, except for the


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 capturedautomatically using character-recognition and an electronic Form 100 (eForm)created.

16-WAR-02 HIPC information for borrowersC215Borrowers who are eligible for the Heavily Indebted Poor Countries (HIPC) debtrelief will be able to obtain information on the amount of relief obtained and theoutstanding balance. This requires information to be obtained from a specificAccess database. This will need reengineering. These reports are to be delivered inphase 2

16-WAR-03 Portal Phase 2Optical Character Recognition is required for phase 2 of the Portal.

The FA will review the eForm against the scanned documentation, will correctwhere 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 theinsertion of Banking Information data in FX. The OCR capability should extractrelevant fields from the scanned image of the Banking Instruction form andpopulate the fields on the banking information screen in FX for IFAD staff to reviewand then proceed with updating the information in FX.


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 ITDirections and market position.

17-SAI-01 Supplier should explain how the proposed solution will enable IFAD to buildfuture proofed, secure, expandable large-scale web-based applications with ahigh degree of intuitive user-experience that is easy to use without significanttraining.

17-SAI-02 Supplier should explain how the proposed solution will enable futureapplication delivery through mobile and other channels.

17-SAI-03 Supplier should explain how the proposed solution will enable shift to CloudComputing.

17-SAI-04 Supplier should explain how the proposed solution will enable Socialnetworking for IFAD staff and external actors (Borrowers, IFI, experts).

17-SAI-05 Supplier should explain how the proposed solution will enable seamlessintegration with internal and external systems.

17-SAI-06 Supplier should explain how the proposed solution will enable the delegation ofuser and role administration to the borrower in a secure and transparent waywithout the need of intervention of a technical expert.

17-SAI-07 Ensuring the highest level security of the new platform is essential to protectIFAD reputation and credibility.

Supplier should explain how the security of the new platform will be enforcedat each layer of the solution in order to guarantee the highest level of securityof the current solution and become the cornerstone on which IFAD will buildfuture enhancements. The proposed solution should be able to be leveragedand integrated with other corporate platforms


E. Service Specifications

1.0 Successful implementation of the project will depend on the provision of key servicesdefined below.

Project Management, Implementation and Project Team Project Team Qualification Training and Knowledge Transfer Technical Support

RequirementsID

Description

18-PMR Project Management, Implementation and Project Team

18-PMR-01 IFAD Borrower Portal system is proposed to be implemented in phases asfollows:

Phase 1 implementation is proposed to cover functionality that is automatingmature processes. The scope of Phase I is limited to a fast-track implementationof core functionality of IFAD Borrower Portal system so that IFAD can derivevalue by deploying the system by November 2016.

Phase 1.5 will add support for French and Spanish to the Portal. Theselanguages will be rolled out to production as an enhancement to the Phase 1functionality 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 thecoming year as IFAD gains more experience with the new system. Phase 2should 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 businessfunctionality 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 assessmentand must take into account deployment consideration in over 140 countriesacross the globe, though the initial deployment for phase 1 will be for a limitedset of countries (e.g. 10 countries).

Please note that bid prices must include Phase 1, Phase 1.5 and Phase 2implementation.

18-PMR-PM-01

Supplier shall describe project team management approach, including lines ofauthority, issue identification, escalation and remediation, risk management,meeting schedules and team coordination and reporting.

18-PMR-PM-02

Supplier must clearly identify roles and time needed from IFAD users for asuccessful implementation. Identify business and ICT users time required fordetailed business requirements definition, software requirements specificationsreviews, integration, testing, end-user training and final operationalacceptance.

18-PMR-PM- The Preliminary Project Plan must address the following topics:


03 Supplier’s 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

18-PMR-PM-04

The Supplier shall submit a list of Subcontractors (if any), and detail thesubcontractor scope of work and alignment with the project plan. The Suppliermay 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 thePurchaser for its approval in sufficient time so as not to impede the progress ofwork on the System. The Purchaser shall not withhold such approvalunreasonably. Such approval by the Purchaser of a Subcontractor(s) shall notrelieve the Supplier from any of its obligations, duties, or responsibilities underthe Contract.

18-PMR-PM-05

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

18-PMR-IA Implementation Approach & Methodology

18-PMR-IA-01 Supplier must describe their implementation approach and methodology that issuitable for IFAD. The implementation approach must be grounded in their pastsuccessful experience.

18-PMR-IA-02 Supplier must describe their approach to the design and development ofcustom software and reports.

18-PMR-HN Transition of system support

18-PMR-HN-01

After project implementation, the purchaser reserves the right to transfer thesupport for the Borrower Portal platform to a different vendor. The Supplieragrees to assist the Purchaser and the incoming vendor in a smooth transitionof system support arrangements to the incoming vendor as a part of theSupplier'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 atleast 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 webapplication development/development team leadership capacity.

The Supplier shall guarantee that the named Project Manager will be assigned to


the Lot 1 project.

19-PMT-02 Two (2) Key functional team leads must be identified for the project. Eachfunctional team lead must have at least five (5) years of experience on theproposed solution platform. Experience with Banking & Financial solutions orwith government & development clients is preferred.

The Supplier shall guarantee that these two named functional team leads will beassigned to the Lot 1 project.

19-PMT-03 Project technical team must include Software & System Experts with at least 2years of experience in the recommended technical platform. Supplier mustprovide the following experts:

Senior Technical Architect with at least five (5) years’ experience implementingsolutions 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 andoverall seven (7) years' experience. Candidate should have worked in this rolefor at least two (2) projects, preferable on banking projects.

Senior IT Infrastructure team lead with at least five (5) years’ experienceimplementing 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 beassigned to the Lot 1 project (ideally at the start of the project, but not later than3 months from project kick off, except in case of force-majeure the vendor willhave to communicate it to IFAD).

19-PMT-04 The Supplier shall make available onsite (at IFAD, Rome) senior or key membersof the project team during periods when close interaction with IFAD isnecessary. IFAD expects the Supplier to propose an onsite-offshore model,while ensuring that key Supplier team members are available onsite whenrequired.

20-TRM-TR Training and Knowledge Transfer

20-TRM-TR-01 The Supplier shall provide training for business and technical users so that theycan fully operationalize and run the system. This training is to be providedbefore system go live, ensuring that the trainees have enough time to becomefamiliar with the system before go live.

Business users will be trained on all business processes based on their defineduser-roles and screen navigation requirements.

Technical users will be provided high level training on the overall technologyplatform 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


The Supplier must propose local training in Rome, Italy. Total number ofbusiness trainees is thirty (30) in IFAD.

20-TRM-TR-02 The Supplier shall provide a description of their approach to delivering trainingand a detailed training plan by user-roles for business and technical staff. TheSupplier 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 providingall 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 theSystem and its Subsystems following installation to determine whether theSystem and the Subsystems meet all the requirements mandated forOperational Acceptance.

21-TST-OA-02 The Supplier's testing methodology shall provide for using regression testingusing automated testing tools to verify that new functionality being added tothe Borrower Portal does not break existing functionality in the Portal. TheSupplier shall provide in their proposal how they will define, implement,manage and support automated regression testing, and highlight anylimitations of regression testing.

21-TST-OA-03 Supplier will provide comprehensive documentation and test cases for thepurchaser to conduct the Operational Acceptance Test. All system customsoftware and reports must be delivered for Operational Acceptance test tocommence.

21-TST-OA-04 Business users will review the Supplier provided test cases, and will form a suiteof User Acceptance Test (UAT) Cases which will include test cases designed bythe business team and test cases provided by the Supplier.

Business users will verify that processes are running correctly, reportsgenerated match with previous reports and that data interfaces with othersystems are performing correctly.

21-TST-OA-05 The IFAD technical and business teams (with Suppliers support) will ensure thatsystem 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 forOperational Acceptance of Phase 1, Phase 1.5 and Phase 2 functionality


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 locatedat Supplier premises anywhere. The Supplier shall provide a (Tier 1) helpdeskfor IFAD staff to contact for issues and incidents.

2. Cases which the Application Hotline (and the Supplier) are not responsiblefor shall be transferred to the end user helpdesk (described in Lot 3) for triagingand followup.

3. Tier 2 for technical issues should be transferred to the Suppliertechnical/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, anintegration must be developed to pass tier 2/3 tickets to Footprints for issuesthat need to be resolved by IFAD staff.

5. Application Hotline Tier 1 staff shall produce reports and statistics on aperiodic basis as agreed with the Purchaser.

22-SPT-SP-02 Post Go-Live Active Support: During the period after Go-Live (of Phase 1, Phase1.5, Phase 2) the Supplier shall provide onsite support with a few key resourcesto 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 theBorrower Portal for a period of six months after Phase 1, Phase 1.5 and Phase 2go live respectively, at no incremental cost to the Purchaser. These bug fixesshould be provided without impacting the System Support arrangementdescribed below.

22-SPT-SP-04 System Support after go live: The Supplier shall provide support for running theBorrower/Recipient Portal application and platform and all its instances, andprovide minor enhancements, for a period of two years after go live. ThePurchaser shall have the option of extending the system support arrangementfor another two years after the initial two year period of support. Theextensions 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 thesupport for Phase 1 (and Phase 1.5) so that Phase 2 post go live support ends atthe same time that Phase 1 (and Phase 1.5) support ends.

The support service shall include provision for i) minor enhancements andcorrections not handled by warranty ii) regular support for upgrades/patches tolatest versions of application software, operating system and database iii)provide an application hotline support iv) security alerts and critical patchupgrades, v) performance tuning and vi) all bug fixes.

A minor enhancement is defined as one that takes not more than 40 personhours for the supplier to define, develop and test (Purchaser's testing effort isnot considered). The supplier should provide for four (4) minor enhancementsper month in their Portal support cost proposal.

The following SLA’s will be required for outages and defects. The supplier


should propose a best-practice SLA:

Severity Level 1 – Critical outage disabling the entire system; or thatnegatively affects all users of the system – remediation action withimmediate effect.

Severity Level 2 – Faults affecting an individual business function; or faultsaffecting the performance of the system; or inability to conducttransactions – within 4 hours of notification.

Severity Level 3 – Faults that impact the operational efficiency of anindividual 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 directresponsibility, excluding issues for which the root cause is not under theircontrol. Supplier shall provide a proposal according to industry best practicesincluding potential penalties and reduction in fees in case ofunderperformance.

22-SPT-SP-05 During the Support period, Supplier shall make available its key technical staffonsite or over the phone/email for consultation and shall respond to criticalsystem or hardware failures that prevent business operations as per the SLA.

Given the nature of the platform as the channel to conduct business betweenIFAD and its partners the application needs to be available, secure, responsiveand supported 24/7. This will be achieved by a mix of on-site and off-sitesupport. As a result, the following support guidelines need to be observed.

The Supplier shall provide at a minimum the following technical resourcesonsite 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 bebackfilled. The supplier will propose the relevant profiles.

During Rome non-business hours including weekends, the supplier shall providethe minimum resources to ensure the availability of the portal and relatedservices. Non-business hours support can be achieved through offshoreresources 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 businessprocesses supported, screen navigation and error actions. Scope must cover alluser 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.


22-SPT-SP-07 Technical Documents: Supplier will provide detailed technical documentationincluding systems architecture, labeling and schematics, system design,technical specification and standard operating procedures for operating thesystem.

Overview of operating environment System architecture Hardware and software specifications Infrastructure system document System backup and recovery plan Security configuration

22-SPT-SP-08 Change Control Procedures

Supplier will be responsible for infrastructure configuration for allenvironments. Changes are performed following an internal ChangeManagement process including approval from IFAD.

Changes to the application code or infrastructure configuration are theresponsibility of the Supplier. To deploy changes in Production, IFAD willapprove the deployment after successful testing of the changes in the UATenvironment.

The standard migration path for code and configuration changes should befollowed, 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 forthe 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 beused) to allow for activities which disrupt the availability of the system. Themaintenance window occurs every Thursday from 20:00 to 24:00 CET.

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.22-SPT-SP-09 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


balancers, etc. It is primarily low-level monitoring of components such as powersupplies, fans, disks and memory modules. It is based on best-practices set bythe product vendors as to which components should be monitored.

2. Operating System Resources

This pertains to monitoring the utilization levels for the following systemresources 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 andapplication availability and performance.

Part of this monitoring includes a scheduled task that logs into every Productionsystem on a regular basis, every five minutes or so, using a low-privilegeaccount. The success of such a login implies that much of the IFAD Portalsoftware stack is operating satisfactorily and that users should be able to makeuse of the system.

4. Application Stack availability

This checks the availability of the components in the application stack includingweb servers, applications servers, the Portal programs etc.

Other target metrics are monitored regularly and any alerts are sent to the IFADteam. This allows informational and warning level alerts to be acted upon inorder 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 equivalent monitoring for theBorrower/Recipient Portal Platform.

22-SPT-SP-10 Database and Filesystem Backup Policies

IFAD policies for Production and Pre-Production systems are detailed here. TheSupplier shall choose the appropriate set of procedures to ensure that backupand disaster recovery restoration requirements detailed here are met orexceeded.

Filesystem Server Backup:

Baseline backup – once, first time

Daily backup – incremental

Weekly backup – full server backup


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 currentsoftware versions or hardware infrastructure

Backups for Disaster Recovery:

Backup files are replicated hourly from the IFAD Data Centre (DC) to the IFADDisaster Recovery Center (DRC) using file system synchronization.

The standby database is synchronized in real time from DC to the DRC usingOracle Data Guard.

Database Recovery

In the case that a database recovery is required, it will be completed within 4hours. This is based on current largest database size of roughly 200gb, and mayincrease as the databases grow. A maximum of 4 hours data loss for productiondatabases and maximum 24 hours data loss for Pre-Production databases canoccur.

Failover and Disaster Recovery

A failover to the DRC shall be within 4 hours when the Portal in the IFAD DCbecomes unavailable and a decision to failover to DRC is made.

When a failover is not possible and a disaster is officially declared and disasterrecovery procedures are invoked, the system shall be made available from theDRC environment within 24 hours with a maximum of 4 hours data loss.

The exact mechanism for backing up the databases may change. Oracle offers awide range of techniques for preserving data in Oracle databases.

The Supplier shall choose the appropriate set of procedures to ensure that theabove disaster recovery restoration requirements are met or exceeded.

22-SPT-SP-11 Incident Management

Incident management requirements are detailed under Application Hotline andWarranty Service.


22-SPT-SP-12 Disaster Recovery Testing

Replication from Production to Disaster Recovery site is done by Oracle DataGuard 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 DRsystems cannot be verified without regular DR tests.

Test Times

Disaster recovery tests should be conducted during normal office hours. Teststo be carried out during weekends or official IFAD holidays will require prioragreement from IFAD management and may incur additional costs.

One month’s notice in writing is required prior to carrying out DisasterRecovery tests unless otherwise agreed by IFAD. The Supplier should indicatethe estimated duration of the test and IFAD will send a confirmation of the testschedule.

Two weeks’ notice in writing is required identifying the precise time and scopeof the test, and for any additional resources required.

Disaster Recovery Invocation

IFAD will nominate a number of staff who are authorised to invoke disasterrecovery and keep this list up to date. Procedures for this, and for disasterinvocation, are contained in a separate document entitled “Disaster RecoveryAuthorisation List and Procedures” which will be maintained by IFAD.

22-SPT-SP-13 The Supplier shall provide maintenance and support services for all instances ofthe Portal, including development, test, UAT, training, support and of coursethe production instances in the primary and disaster recovery data centers.

The Supplier shall refresh data in the various instances on a schedule to theagreed with the Purchaser. For example, after system go live, the "support"instance is expected to be refreshed with data from production at least on aweekly 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 externalauditors. The Supplier shall provide system logs, proof of backups, and otherartifacts requested by the auditors.


F. Title, Copyright and Use Rights

The IFAD General Terms and Conditions for the Procurement of Goods and the IFAD General Termsand 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 theContractor (i.e. Supplier) in the course of this contract, including the design, developmentand 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 theBorrower/Recipient Portal solution to the full extent of the usage rights conferred by thelicensor, which shall include the right to use that product for other systems/applicationsmanaged by IFAD.

G. Supplier’s Experience Requirements and Client References

1.0 Supplier’s experience is a key requirement and is defined below.

23-EXP-EX Supplier’s Experience and Client References

23-EXP-EX-01 The Supplier shall provide verifiable client information for their web applicationimplementation experience. While in the mandatory criteria the Supplier has toprovide a minimum of two successful contracts, the Supplier should providedetails of three to four client sites. Supplier shall provide (at the minimum) thefollowing information for each client site:

Name of the Supplier’s 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

24-CLR Client Reference Sites

24-CLR-01 The Purchaser will select two reference sites from the Supplier's client referencelist for verification. Purchaser will request the Supplier to facilitate clientreference contact for an interview, responses to a list of written questions andsite visits.


H. Hardware and Software requirements

IFAD will host the IT Infrastructure to support the Borrower/Recipient Portal at the IFAD Data Centerin Rome, Italy. An illustrative technical architecture is attached below that should inform thesuppliers choice of technology proposed and components that will be required.

IFAD has narrowed down the technology choices to the following two leading industry vendorproduct lines:

3. IBM WebSphere4. Oracle WebCenter

Supplier should ensure that their proposed solution covers web servers, application servers,business process management, identity and access management, database software (OracleRDBMS), reporting tool, information security and integration with IFAD’s existing IT infrastructureand systems, monitoring tools and provide for all components that will be needed to build andsupport the application.


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 customsclearance requirements for the hardware.

The live system shall be installed on servers at both sites. The equipment at each site shall besufficient to run the entire production system should the other site become unavailable, but innormal operation IFAD expects that the systems at the sites will be coupled in such a way that afailure at any site will have no effect on the operation of the system. Bids must containrecommendations as to how the sites will be equipped and coupled to enable the highest levelof availability.

Bids should also contain details of how suitable failover procedures will be developed and testedto 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 andinternal IFAD users.

b. The system must support 1400 simultaneously logged on users of which 140are estimated to be concurrent (zero think time) users. Concurrent usertesting shall be done using zero think time. The "time to render" for thelogin page must be under 3 seconds considering 140 concurrent users. TheSupplier shall use a bandwidth of 512kbps and a latency of 300 millisecondsto test Portal response times for end-user functions. Testing at IFAD Romewith high bandwidth and low latency should show subsecond responsetimes for screen transaction processing. The Supplier shall provide aperformance testing plan which will be executed in a controlledenvironment.

c. The system platform specifications shall provide sufficient processing andcapabilities to support the volume estimates for a period of five (5) years ata 10% annual growth rate.

d. The requirement for data retention for the Portal is the close of financingplus five years for a project financing. The average length of a project isaround seven years. For this contract, the supplier shall provide storage fora 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 termsof throughput capacity and response times, making due allowance for peaksin transaction volumes.

f. Document storage: The official repository for documents submitted throughthe Portal are existing IFAD document and records management systems.The Portal shall manage the transient storage of documents and caching


requirements.

g. The hardware proposed shall have industry best practice warranties of atleast three years for parts and on-site labour. Please explain the rationalefor any lower warranty periods.

25-HAR-02 System Instances: The Borrower Portal is a critical system and shall have at aminimum seven instances - Production, Development, Test, UAT Test, Support,Training, and Disaster Recovery. All instances can be virtualized (e.g. withVMWare).

As highlighted earlier, the Supplier shall provide maintenance and supportservices 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 beassured through demonstration and rigorous testing.

b. High Availability must be available for web servers and app servers onseparate physical hardware, and for storage. Exclude Oracle RAC HighAvailability option given license costs. High Availability is needed only for theproduction system in the primary data center (DC).

c. The Supplier’s solution must provide for full backup, recovery and restorefacilities for the database within the overall solution to enable completefile/data restoration and recovery.

d. The database environment must support the capability for replication of thedatabase and libraries to the Disaster Recovery center.

e. Backup solution must provide the facility to back up data and applicationsoftware using modern tape back-up library technology.

f. The system must be operationally resilient, with high levels of local recoverysupported by an appropriately configured back-up installation and a smoothcut-over between the primary and disaster sites, and back again to theprimary 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 tooperate their proposed solution. All components of the system will be requiredto operate without a need for upgrade for a period of at least three years fromoperational acceptance and the hardware should be sized accordingly. Thehardware shall be from one of the leading manufacturers, with proven record ofhardware support in Rome. Hardware proposals shall include all related services.

25-HAR-05 Servers

The Supplier shall specify in detail all recommended server components, togetherwith any items necessary for connection to IFAD’s existing and plannedtechnology environment.

Suppliers shall describe any operating system options, version/variant, releaselevel, all additional and optional modules required, and (if desired) theirpreferred option.


25-HAR-06 Data Storage

Bids must specify in detail the recommended data storage capacity andequipment. This should be supported by sizing information on the capacityrequired to hold all copies of the system database(s) and any other supportingdata, 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 theirsolution, such as certificate servers, networking and security components such asrouters, firewalls, other security appliances, racks, etc.

25-HAR-07 Power and Rack Space

The Supplier should provide the power (amperage) and rack space requirementsfor all the hardware to be installed in the IFAD Data Center (DC) and the disasterrecovery 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 amongstIBM and Oracle for the IFAD Borrower/Recipient portal. The rationale shallindicate alignment with strategic directions, supplier experience with using thetechnology 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 detailany other system software and middleware items that will be required to run thesystem including Portal software, Business Process Management software,Identify Management software, monitoring software, database managementsoftware etc.

Other

Supplier shall include details of any other software that may be required, such asa 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 thatcan be used for the rapid development of reports to satisfy needs that mightarise on an ad hoc basis.

IFAD currently uses Oracle OBIEE as its standard reporting tool. If Supplierproposes a different reporting solution, then IFAD prefers to use open sourcereporting tools that provide drill-down capabilities and are not licensed pernamed user but at the server level.


I. Implementation Schedule

The following is a proposed Implementation Schedule for the project. The Supplier shall completetheir assessment and propose their own Implementation Schedule. The Gantt chart shows a broadschedule by year for implementation and support. The detailed task table shows key activitiesduring project implementation, for Phase 1, Phase 1.5 and Phase 2. The project kickoff is expectedto take place within four (4) weeks after the contract is signed or as agreed upon between thesupplier and purchaser at contract signing time. The proposed implementation schedule starts fromthe project kickoff date.

Implementation Schedule TableS.No Activity Start

(weekof)

End(week of)

Elapsed Duration(weeks)

Overall Project W1 W91

1 Project Management W1 W91

1.1 Project Planning W1 W3 3

1.2 Infrastructure (hardware) deliveryand setup in the IFAD data center(DC)

W1 W5 5

1.3 Software delivery and installation,configuration – developmentinstance, in the IFAD data center(DC)

W6 W7 2

1.4 Software delivery and installation,configuration – test, production andother instances, in the IFAD datacenter (DC)

W7 W12 6

1.5 Hardware and softwareinfrastructure set in the disasterrecovery centre (RDC)

W16 W25 10

2 Software design and development –Phase 1

2.1 Confirmation of business andtechnical requirements – phase 1, 2

W1 W3 3

2.2 User experience design and testing W2 W5 4

2.2 System architecture definition W1 W3 3


2.3 System technical design includingintegration specs

W2 W5 4

2.4 Develop Software requirementsspecification – Phase 1

W3 W11 9

2.5 Software development (includingunit testing) – Phase 1

W7 W24 18

3 Testing – Phase 13.1 Test Plan – Phase 1 W4 W5 2

3.2 Test case preparation – Phase 1 W6 W19 14

3.2 Module and integration testingcycles - Phase 1

W17 W28 12

3.2 System testing cycles – Phase 1 W29 W35 7

3.3 Performance testing, Failover toRDC testing – Phase 1

W34 W36 3

3.4 Acceptance testing - Phase 1 W36 W42 7

4 Go live Phase 1

4.1 Prepare documentation (technical,end-user, operating instructions .)

W28 W38 11

4.2 Training IFAD business users W38 W40 3

4.3 Go live plan – Phase 1 W35 W40 6

4.4 Go live - Phase 1 W43

4.5 Operational Acceptance – Phase 1 W51 W51

4.6 Production warranty support –Phase 1

W43 Till end ofWarrantysupport

4.7 System and application support –Phase 1

W43 Till end ofsupportcontract

4.8 Add support for French and Spanishand roll out to production. This willhave its own testing and useracceptance steps, operationalacceptance and support contract.

Specify Specify

5 Confirmation of requirements –Phase 2

W35 W40 6

6 Software design and development –Phase 2

6.1 Develop Software requirementsspecifications – Phase 2

W41 W48 8

6.2 Software development (includingunit testing) – Phase 2

W49 W64 16


7 Testing – Phase 2

7.1 Test Plan – Phase 2 W46 W48 3

7.2 Test case preparation – Phase 2 W47 W60 14

7.3 Module and integration testing –Phase 2

W55 W66 12

7.4 System testing cycles – Phase 2 W67 W73 7

7.5 Performance testing – Phase 2 W72 W74 3

7.6 Acceptance testing – Phase 2 W75 W82 8

8 Go live – Phase 2

8.1 Prepare documentation (technical,end-user, operating instructions) –Phase 2

W68 W78 11

8.2 Training IFAD business users W78 W80 3

8.3 Go live Plan – Phase 2 W77 W80 4

8.4 Go live – Phase 2 W83

8.5 Warranty Support – Phase 2 W83 Till End ofWarrantySupport

8.6 Operational Acceptance - Phase 2 W91 W91

8.7 System and application support –Phase 2

W83 Till end ofSupportContract.

9 Lot 2,3,4 Services

9.1 Lot 3 - End-user helpdesk readinessactivities

W37 W42 6

9.2 Lot 3 - End-user helpdesk services W43 Till end ofLot 3contract

9.3 Lot 4 - Rollout Support - planning,training delivery and support

W38 Till end ofLot 4contract

9.4 Lot 2 - Develop plan for Portalaccess credentials provisioning

W5 W8 4

9.5 Lot 2 – Implement, Pilot and then W25 Till end of


support access credentialsprovisioning

Lot 2contract


J. Required Format for Supplier’s Response and Checklist

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

The Supplier must provide detailed descriptions of the essential technical, performance, orother relevant characteristics of all key Information Technologies, Materials, other Goods,and Services offered in the bid (e.g., version, release, and model numbers). Withoutproviding sufficient clear detail, Suppliers run the risk of their bids being declared non-responsive.

To assist in the bid evaluation, the detailed descriptions should be organized and crossreferenced 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 Purchaser’s TechnicalRequirements, demonstrating the substantial responsiveness of the overall design of theSystem and the individual Information Technologies, Goods, and Services offered to thoseRequirements.

3. Preliminary Project Plan

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

4. Confirmation of Responsibility for Integration and Interoperability of InformationTechnologies

The Supplier must submit a written confirmation that, if awarded the Contract, it shallaccept 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 twogroups. 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 responsivenesschecklist, in the order they are listed in Table 1 and Table 2 (excluding of course the costproposal). Label each document as Table number - Item number (e.g. Table 1 - Item 2; Table2 – Item 3).

Group 2: All the documents addressing each item in Table 3, in the order they are listed inTable 3. Label each document as Table number - Item number (e.g. Table 3 - Item 4; Table 3– Item 5).


Technical Responsiveness Checklist

The Supplier must complete the following tables in order to verify that all the RFP responserequirements have been completed as instructed.

Table 1

Item # Document Name Included in submission? Referenceto ProposalResponseSection

1 Price Schedules for Capital and Recurrent Costs,separate from response to TechnicalRequirements.

(Attach Bill of Quantity for hardware to CostProposal.)

YES NO

2 Supplier's Quality certifications

Attach industry certifications like CMMICertification.

YES NO

3 List of Subcontractors, including their roles andresource alignment with the project schedule. YES NO

4 Confirmation of Responsibility for Integrationand Interoperability of InformationTechnologies.

Attach a written confirmation that, if awardedthe Contract, the Supplier shall acceptresponsibility to ensure the application andinfrastructure are properly integrated.

YES NO

Mandatory Criteria Response Checklist

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

Table 2

Item # Mandatory Criteria

Meets Criteria andincluded in

submission?

Reference toProposalResponse

Section

1 Average Annual Turnover for the last three (3) yearsof not less than fifty (50) million USD.

Attach audited financial statements for the lastthree years and highlight the relevant numbers.

YES NO




submission?


Section

2 Access to liquidity financial resources such as bankassets and lines of credit, etc. of at least two (2)million USD.

Attach certified Bank statement indicating theavailability of the required liquidity.

YES NO

3 During the past five (5) Years, the Supplier musthave completed at least two (2) successful contractsworth over one (1) million USD each involving thesupply, implementation and support of a large-scalesecure, web-based application that supports over3000 users across the internet and intranet.

Attach documentation on the two projectscompleted, including a statement from the projectclient/sponsor on the scope and implementation ofthe project.

YES NO

4 Minimum required experience of project manager.

The Project Manager must have a minimum of 10years’ experience with at least two (2) successfullycompleted projects of similar size as project manager.

At least five years of industry experience in a webapplication development/development teamleadership capacity.

Attach CV of the project manager highlighting therequired experience.

The Supplier shall guarantee that this named projectmanager will be assigned to the Lot 1 project.

YES NO




submission?


Section

5 Answer if Joint Venture: In the case of a JointVenture, the partner responsible for applicationsoftware development must be designated the leadpartner and the financial figures for all joint venturepartners shall be added together to determine theSupplier’s compliance with the minimumqualification criteria for financial and technicalcapability. For a Joint Venture to qualify, the leadpartner must meet at least 50 percent of thefinancial capability (turnover and liquidity).

Each Joint Venture member must by itself havecompleted at least two (2) successful contractsinvolving exercise of the skills for which it has beenincluded in the Joint Venture, preferably concerningthe supply, implementation and support of a large-scale web application of similar functional/technicalcharacteristics and of a comparable scale. The leadpartner must demonstrate at least one (1) successfulexperience with a large scale web applicationdeployment.

For each partner attach

a) certified documentation indicatingturnover and liquidity;

b) documentation on at least two successfulcontracts for the skills in scope;

For lead partner attach documentation on a largescale web application that was successfullyimplemented.

Attach documentation on how the financialturnover and liquidity position of all partnerscombined are enough to meet the mandatorycriteria.

YES NO




submission?


Section

6 Answer if Joint Venture:

Bids submitted by a Joint Venture of two or more firms aspartners shall also comply with the followingrequirements:

(a) the bid shall be signed so as to be legally binding onall partners;

(b) one of the partners shall be nominated as being lead( in charge), and this nomination shall be evidencedby submitting a power of attorney signed by legallyauthorized signatories of all the partners;

(c) the partner in charge shall be authorized to incurliabilities and receive instructions for and on behalf ofany and all partners of the Joint Venture, and theentire execution of the Contract, including payment,shall be done exclusively with the partner in charge;

YES NO

Technical Requirements Supplier Response Checklist

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

Table 3 Vendor Detailed Response Checklist

Item # Proposal Response Item

Completed and Providedas Instructed??

Referenceto ProposalResponse

Section

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

Provide documents detailing how the Supplier'sproposal addresses all ADR requirements.

YES NO

2 2-HDR High level design and systemarchitecture, including integration points.

Provide documents detailing how the Supplier'sproposal addresses HDR requirements.

YES NO

3 3-DDR Methodology and approach for Detailedtechnical design by component.

Provide documents detailing how the Supplier'sproposal addresses DDR requirements.

YES NO





Section

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

Provide documents detailing how the Supplier'sproposal addresses GTR requirements.

YES NO

5 5-CRP Comprehensive reporting[Phase 1]

Provide documents detailing how the Supplier'sproposal addresses CRP requirements. Describehow the proposal facilitates the use of tabletsand smartphones in the future.

YES NO

6 6-ADC Access to key documents[Phase1]

Provide documents detailing how the Supplier'sproposal addresses ADC requirements.

YES NO

7 7-WAD Withdrawal Application processing[Phase 1]

Provide documents detailing how the Supplier'sproposal addresses WAD requirements.

YES NO

8 8-MBI Manage Banking information [Phase 1].

Provide documents detailing how the Supplier'sproposal addresses MBI requirements.

Include advice on how to mitigate the risk ofcyber fraud for this function.

YES NO

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

Provide documents detailing how the Supplier'sproposal addresses LNO requirements.

YES NO

10 10-SDC Submission of AWPB and otherdocuments and workflow. [Phase 2]

Provide documents detailing how the Supplier'sproposal addresses SDC requirements.

YES NO

11 11-RIMS Access to RIMS system [Phase 2]

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

YES NO

12 12-LWA Integration of Withdrawal Applicationsystem to other functions like AWPB. [Phase 2]

Provide documents detailing how the Supplier'sproposal addresses LWA requirements.

YES NO





Section

13 13-CDB Confirmation of disbursementconditions [Phase 2]

Provide documents detailing how the Supplier'sproposal addresses CDB requirements.

YES NO

14 14-ARD Reference documents from B/R [Phase2]

Provide documents detailing how the Supplier'sproposal addresses ARD requirements.

YES NO

15 15-MSC Reallocation of categories, specialaccount changes [Phase 2]

Provide documents detailing how the Supplier'sproposal addresses MSC requirements.

YES NO

16 16-WAR Withdrawal Application Enhancements,Reporting . [Phase 2]

Provide documents detailing how the Supplier'sproposal addresses WAR requirements.

YES NO

17 17-SAI Strategic alignment

Provide documents detailing how the Supplier'sproposal addresses SAI requirements.

YES NO

18 18-PMR Project Management, ImplementationApproach and Methodology, Project Plan,Resourcing (including IFAD resources).

Provide documents detailing how the Supplier'sproposal addresses PMR requirements. Indicateany subcontractor use.

YES NO

19 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 anddevelopment team lead

d) One senior infrastructure team lead.

Provide your approach to a cost effectiveresource model using onsite/offshore resources.

The Supplier shall guarantee that these namedtechnical resources will be assigned to the Lot 1project.

YES NO





Section

20 20-TRM Training approach and methodology

Provide documents detailing how the Supplier'sproposal addresses TRM requirements.

YES NO

21 21-TST Testing approach and methodology

Provide documents detailing how the Supplier'sproposal addresses TST requirements.

YES NO

22 22-SPT Approach and methodology forapplication support and IT infrastructuresupport.

Provide documents detailing how the Supplier'sproposal addresses SPT requirements includingthe SLA and system availability.

Provide profiles for the composition of theonsite support team

YES NO

23 23-EXP Supplier's experience

Under mandatory criteria Supplier providedinformation on two projects. Provideinformation on an additional one or twoprojects.

YES NO

24 24-CLR Client references

The purchaser will contact two projects from thesupplier's list for verification. Provide anyinformation that will helpful to the purchaser ingetting feedback from the client including clientpreferences.

YES NO

25 25-HAR Sizing, Supply and Installation ofhardware, high availability, backup, disasterrecovery.

Indicate type of hardware, capacity, proposeduse, power requirements, physical spacerequirements, ..

Provide documents detailing how the Supplier'sproposal addresses HAR requirements. AttachBill of Quantity for hardware to Cost Proposal.

YES NO





Section

26 26-SWR Supply, Licensing and installation.

Provide documents detailing how the Supplier'sproposal addresses SWR requirements.

Provide a clear rationale for the selection of theproduct line from IBM or Oracle (note that forthe RDBMS Oracle is the IFAD standard).

YES NO

27 27-LAN Language support for Spanish, French inPhase 1.5. [Indicate cost separately in costtable.]

Describe the approach and methodology toadding Spanish and French support to the Portal.

Describe the design considerations foraccommodating right to left languages likeArabic.

Describe the effort for adding Arabic support tothe Portal after Lot 1 Phase 2, and provide therelated cost as a separate line item in the costtable.

YES NO

Annex 1-Site Table

IFAD Rome

SiteCode

Site City / Town / Region Primary Contact Phone and StreetAddress

IFAD The InternationalFund for AgriculturalDevelopment (IFAD)is a specializedagency of the UnitedNations with itsHeadquarters inRome, Via Paolo diDono 44, 00142Rome, Italy.

Rome, Italy Tel:+39-0654591Fax:+39-065043463

Via Paolo di Dono 44, 00142 Rome,Italy.


Annex 2- Holidays and Other Non-Working Days:

Supplier must pay due regard to all recognized festivals, official holidays, and religious or othercustoms, and all local laws and regulations pertaining to the employment of labor and factor this inthe 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 andafter consultation with the Executive Committee of the Staff Association, IFAD will observe thefollowing ten official holidays in 2015:

Thursday 1 January New Year’s 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.


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 varioususer profiles which are being proposed are as follows together with a suggested number of users toconsider:

Role Assumption

Borrowers/Recipients –Viewer

5 per country;

5 per project

Borrowers/Recipients –Author

2 per project for 50% of projects


Borrowers/Recipients –Authorizer



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 4

Administrator –Borrower/recipient

2 per country

It is recognised that the requirements of each country and/or project with respect to access will bedifferent: some projects may have very decentralised operations with multiple implementing unitseach requiring access, whereas some projects may be centralised with one PMU with limitedstaffing. An analysis was performed of the current4 financing to countries (i.e. excluding non-countrygrants).

There will be a gradual rollout of the Portal to users. Initially the Portal will be made accessible tothose countries with which consultations on the Portal are taking place and or countries whereelectronic/advanced pilots are already successfully in place. These total approximately 10 -15countries.

Total Pilot

No of countries (ministries) 145 15

No of financings 377 96

No of projects 223 53

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


Role Assumption Total Pilot


5 per country;

5 per project

1 840 340


2 per project for 50% ofprojects


1 115 106




1 115 106

Uploader Number of Finance Assistants 10 10

Validator Number of Finance assistants 10 10

Reviewer - IFAD Number of CPMs or GrantManagers

290 30

Approver Number of Finance Officers 15 15

Viewer - IFAD For each user in IFAD (toinclude CPMS, ICOs,Management). 600

600 600

Administrator - IFAD 4 4 4

Administrator –Borrower/recipient

2 per country 290 30

Total 5,289 1,251Using the estimated numbers for roles above and assuming that there is one CPM per country, thetotal number of roles for the Portal for country loans and grants is at least 5,000. Given the phasingof the functionality, it is expected that there will be approximately 1,200 roles required in the firstphase of the rollout. It is to be recognised that there is a certain amount of overlap in that users mayhave multiple roles. Taking this into account, the users for IFAD are expected to be no more than600. The overlap for countries and projects is less straight-forward to estimate, however areasonable assumption is that half of the viewers at the B/R level will also have access as an Authoror Authorizer i.e. an overlap of approximately 1,000 (of which approximately 170 for the initialrollout).

Non-country grants

Given the vast number of non-country grant recipients and in consideration that many recipientsonly receive one grant from IFAD, it has been decided to limit the number of recipients given accessto the Portal to the top recipients plus the CGIAR centres. Applying the same assumptions as forcountry 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 thePortal will be used by approximately 4,3005 – 4,800 users of which approximately 600 will be internaland approximately 1,0006 will be required in the initial rollout.

55,289-10-10-290-15-4-1,000+600 = 4.5606 1,521-20-30-15-4-170=1,012


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 ofPortal users expected in the first two years after Phase 1 rollout are 2,400 + 600 = 3,000. For licensecosting purposes, we will use 4,000 users as the reference number.


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

#Business Requirement (MainProcess)

Transaction volumemeasured

Average size ofdocument(pages) Comment

1 Withdrawal Application process 200 WA per month;over 300 trxs in FX

Average =90(could be up to1,500)

scanneddocument

2 AWPB 550 per year (45 permonth)

up to 100 excel, word,pdf

3 Contract Management - Form C11-contract monitoring form withupload of scanned contract,amendments, bank guarantees

unknown up to 100 formain contract;amendmentsand bankguarantees -20 pages

scanneddocument

4 Recovery schedule 90 per year (7 permonth)

1 excel

5 Banking information 24 per month 2 scanneddocumentand excel

6 Confirmation of disbursementconditions - for the project to beable to submit all documentationand to allow easy reference

395 for 17 months (23per month) of which172 investmentprojects (10 per month)

20 Multiple pdfdocumentsmay besubmitted -up to 10

7 Reallocation of categories -submission of request andworkflow for approval

128 for 19.5 months(6.6 per month)

10-20 scanneddocument

8 Request for extension ofcompletion date - submission ofrequest and workflow for approval

23 for 17 months (1.3per month)


9 Increase/decrease in specialaccount allocation - submission ofrequest and workflow for approval

46 for 17 months (2.7per month)


10 Submission of Procurement Planand bid documents *

unknown - henceestimated at > 20 permonth

up to 100 scanneddocument

11 Access to reference documents -financing agreement, Letter to theBorrower

650 (2 documents for250 projects plus 1document for 150 non-country grants)

20-30 pdf

12 Access to reference documents -Signatories

400 - 5,000 (1-10documents for 250projects plus 1document for 150 non-

up to 10 scanneddocument


country grants)

13 Access to reference documents -Supervision reports, Designreports **

1-2 supn per projectper yr: 240 projects:20-40 p.m. plus design

200-400 pages pdf

* This covers:

Procurement plan: up to 10 pages

Terms of reference: 20 pagesList of vendors: 1-2 pagesRecommendation of contract committee: 2-4 pagesContract: up to 100 pages

**This covers:

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


Appendix 1 – Submission of WA (detail description)

eSubmission of Withdrawal Application

Borrower/Recipient IFAD

Pⁿ

Start

AuthorManually insertsdata in Form 100and optionallysubsidiary formsAmends forms ifreleased by IFADScanned documentsuploadedSystem validationsof data insertedSubmits forapprovalNotification formcreated1.5.3, 1.6 and 1.8

Authorizer

Review form andverify – nomodification ofdocuments orinformationApprove1.13

Not approved

Start

Receiver

Receives Hardcopy - WACreatesscanneddocument

Start

Uploader

Receives scanneddocumentCaptures dataautomatically andpopulates Form 100Attaches scanneddocumentSystem validationsof data insertedNotification formcreatedReview and submitfor processing1.6, 1.8 and 1.13

Uploader

Receives SWIFTmessage from CIManually insertsdata in Form 100Attaches scanneddocumentSystem validationsof data insertedNotification formcreatedReview and submitfor processing1.7, 1.8 and 1.13

Data fromFMA

Data fromFlexcube

Data fromGARTS

Data fromdatabase in

portal

Approved

Submitted

Submitted

Validator (FA)

Reviews Notificationin accordance withRBD requirementsReduces amountclaimed if required(ineligibleexpenditure)Inserts comment ifrequiredReleases Form 100for modificationValidate or reject1.19

Approver (FO) may be 2see 1.21

Reviews Notificationin accordance withRBD requirementsInserts comment ifrequiredApprove or RejectReleases Form 100for modification1.19

Validate

Ineligibleexpendituredata to FMA1.16 and 1.19

System

Routes to IFAD resource based upon:1. Borrower or Recipient2. Risk assigned to financing3. Type of withdrawal application4. Materiality5. Alert messages

1.15, 1.16, 1.17 and 1.18

Data fromPeople/GRIPS

End

Reviewer (CPM)

Reviews notification formand either subsidiary

forms or scanneddocuments

Depending on risk ratingmay be required to

approve1.16

Approve?Approve?

Approvedtransaction

created in FX1.24

End

YesYes

Routing 1

NoNoReject or open for recycling

Approver (FO) may be 2see 1.21

Reviews Notificationin accordance withRBD requirementsInserts comment ifrequiredApprove or RejectReleases Form 100for modification1.19

Reviewer (CPM)

Reviews notification formand either subsidiary

forms or scanneddocuments

Depending on risk ratingmay be required to

approve1.16

Approve? Approve?

Approvedtransaction

created in FX1.24

YesYes

No No

Approvedtransaction

created in FX1.24

End

End

Request routed toRMS for storage

1.23

Routing 3


1.23


1.23

YesYes

Ineligibleexpendituredata to FMA1.16 and 1.19

EndEndEndEnd

Routing of WA can be one of:1. to CPM and FA for review2. to CPM and FO for approval3. Direct to FX (Straightthrough processing)

Routing 2

Section VI. Technical Requirements 81


1.1. e-Submission of withdrawal applications – detailed requirements

1.2. Backgrounde-Submission of withdrawal applications allows the Borrower or Recipient (B/R) of IFAD financing tosubmit electronically a request for payment. Basic validations on the data which are currentlyperformed by Flexcube will be replicated within the portal. The portal will contain workflowfunctionality at the B/R level to allow the withdrawal application to be approved electronically andbe submitted to IFAD. Once submitted to IFAD a second workflow will route the WA for review andapproval, depending on data such as risk categories and SOE thresholds, to the relevant peoplewithin IFAD. The review of the validity of the WA will take place within the designated workflow andonce approved the data will be interfaced to Flexcube and the relevant transaction will be created inFlexcube for approval by the relevant person (centralized processing may be used). At all stages ofthe process, it should be possible for users (B/R, CPM, CFS) to have information on the status of therequest be this by access to a screen or by notifications.

1.3. Features

1.4. WA submission optionsIn recognition of the different capacities of the Borrowers and Recipients of IFAD, there will bedifferent options for the submission of a withdrawal application.

1.4.1.OptionsThere 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) withoption for Forms 101, 102, 104 and 105 in phase 2) will be inserted into the portal andscanned additional forms and supporting documentation will be uploaded. Application isapproved online and submitted to IFAD for processing

Where the WA is not submitted through the portal, Form 100 will be inserted by IFADstaff and the scanned additional forms and supporting documentation will be uploadedto the system by IFAD staff.

Given that the portal will be a secure site with access being limited to authorized personsonly with cross-validations to initiate access, the submission of scanned forms will beaccepted.

1.4.2.Current formsIFAD will design the portal input pages to be in line with the forms below:



Form 100 – online approval - mandatorySummary sheet – scanned version uploaded (phase 1) or data input into specific forms insystem (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 intospecific forms in system (phase 2)Form 102 - SOE Goods works and services - scanned version uploaded (phase 1) or datainput 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/Ais Designated Account (reconciliation for imprest account) and Form 104/B is DesignatedAccount 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 formsin system (phase 2)Form C10 – Register of contracts – scanned version uploadedForm C11 – Contract Payment Monitoring Form – scanned version uploaded (phase 1) or tobe 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 beavailable to upload from excel into the system. (Phase 2)

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

1.5.1.Header – search function7 Title Options Comments

S Borrower or Recipient Country NamePMUImplementing AgencyRecipient

The options availablewill depend upon theaccess of the user andwill need to be definedby the countries. Alloptions should beavailable to make theaccess as wide orrestricted as necessary

S Financing Type All or drop down list ofoptions from Attachment1

S Status All or drop down listfrom Attachment 1

S Project All or drop down listfrom Attachment 1

To check with users ifthey require name or(alternate) accountnumber (expect name)

7 A = Standing data dependent on accessS = Standing dataI = Data to be input by ‘maker’C = Calculated by the system



S Funding source All or drop down listfrom Attachment 1

To check with users ifneeded

S Financing number(FX Account number)

All or drop down listfrom Attachment 1

Brings back following data for each project with the projects shown as a list with the possibility toclick on a link and open the form for withdrawal applications. The data will be presented in tabularformat



Borrower or Recipient: xxxxxxxxxxxxxx Date: As at 25/5/15

Projectname

Project Number –FinancingNumber

AlternateAccountNumber

Ccy FinancingAmount

Financing Type Status DisbursableDate

Closing date Completiondate

Disbursedamount

Undisbursedamount

Percentagedisbursed

ABCDE 1447

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 COMPONENTGRANTS

Disbursable 21/03/2011 30/09/2018 31/03/2018 74 272.70 555 727.30 11.80%

100000448000 456-B SDR 650 000.00 LOAN COMPONENTGRANTS

Signed 650,000.00 0.00%

Total SDR 39 330 000.00 4 970 571.91 33 709 428.09 12.64%

ABCDE 1376

100000274900 789- SDR 10 050 000.00 LOANS Disbursable 26/06/2008 30/09/2017 31/03/2017 7 551 398.37 2,498,601.63 75.14%

100000275000 910- SDR 635 000.00 LOAN COMPONENTGRANTS

Disbursable 09/07/2008 30/09/2017 31/03/2017 635 000.00 - 100.00%

Total SDR 10 685 000.00 8 186 398.37 0.00 76.62%

ABCDE 1571


100000415100 126 SDR 630 000.00 LOAN COMPONENTGRANTS

Disbursable 12/11/2014 31/12/2020 30/06/2020 128 161.27 501 838.73 20.34%

Total SDR 44 770 000.00 1 835 320.53 501 838.73 4.10%

ABCDE 110000174500

SDR 3 380 000.00 ASAP GRANT Enter intoForce

31/12/2023 30/06/2023 - 3 380 000.00 0.00%


Enter intoForce

31/12/2023 30/06/2023 - 950 000.00 0.00%



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 financingAt the financing levelAt 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 oneWA would be submitted with allocation to the different instruments.



Depending on the status of the financing, if the B/R selects a particular form a warning message willbe displayed. If the financing has a status of APPR, CANC, CLSD, PAID or SIGN the following messageshould be given:

“IFAD does not currently accept withdrawal applications against this financing. Please contact thehelp-desk for assistance or click on the help box”

1.5.2.Advances for start-up costsFor some projects, IFAD may provide advances for the start-up of the project. The financing will notbe in DSBL status. If the financing has a status of ENTF, the B/R can submit the request for anAdvance 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, theFA would change the status to DSBL, FO would approve and the request would be reviewed andprocessed.

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:

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 morethan one application type e.g. Directpayment and a replenishment. For eachof the types of application requestedthe appropriate boxes listed belowshould open for completion.

Results baseddisbursements are notcurrently used in IFAD

Justification If Replenishment is selected a secondoption should open to select whetherthe replenishment will also be used forjustification of the advance or thespecial account. If Yes, then user shouldbe able to input the amount forjustification

S Bank account Drop down list (see Attachment 1). ifmore than one account available for thefinancing and then populate FundingSource.

Bank account details and relevantcorrespondent bank information to be



retrieved from Flexcube for checking byinput person.

If the recipient is a CGIAR centre andthe grant passes through the IBRD trustfund, ‘Beneficiary Bank Name andAddress’ = IBRD TF, bank accountinformation is not to be shown to therecipient.

I Special PaymentInstructions

This field allows the B/R to insertspecific instructions and/or uploadspecific scanned documents (e.g. OFAClicence)

I WA reference number Sequential number

I Application currency Inserted by inputter

I Application Amount Inserted by inputter

S-I

Funding Source If WA is submitted at the Project leveland there is more than one (FX) Accountfor the project, each Account isproposed to the initiator with themessage:

“Please enter the amount or percentageof the WA to be allocated to eachsource of funding”.

Not all financing sources have to beselected by the initiator

Training materials shouldindicate that if there is onebank account with multipletypes of financing, then theWA should be submitted atthe project level.

If WA is submitted at the FX Accountlevel and there is more than one bankaccount (i.e. where there are differentimplementing parties and/or wherebanking instructions are present fordirect payments), the initiator will selectthe relevant bank account

I Retroactive financing The initiator will be given the choice ofbeing able to indicate if any of theexpenditure being claimed relates toretroactive financing and if so theperiod to which it relates

Yes or No and then if Yes

Date from

Date to



I Period of Application Not applicable for advances to imprestaccount, Direct payment, Advance forstart-up costs or Results baseddisbursement

Date from

Date to

System to only propose thisif the WA is

An advance payment; Reimbursement Replenishment Justification

I Source of supply This should be a picklist of countries.With the option to select country for asingle item of expenditure, inpercentage and/or all remaining. Thedefault for each B/R should be thecountry of the B/R.

Generally in inputting WAinto FX, FA will chose thecountry in which theproject is beingimplemented. Differentcountries are only selectedfor direct payments(generally)

System only to propose thisif the WA is

Reimbursement Replenishment Justification Direct Payment

If the WA is for an advancethe default will be“Undetermined”

I Category allocation For all Advance payments categoryallocation will default to that of theadvance.

For: Direct Payment Reimbursement Replenishment Results based disbursement

New area to open:

Boxes to insert amounts for eachcategory. For each box a picklist of theavailable categories should be available.Not all categories will be required,hence require possibility to have morethan one box.

System to total amount of categories

Error message if total of categories isdifferent to that of Application Amount.

Where WA is submitted at the projectlevel the category allocation has to befor each Funding Source which has been



selected. If the split of the funding is ona percentage basis, the initiator will berequired to insert the category detailsfor the 100% and the system willautomatically apply the relevantpercentage for the individual fundingsources.

For all financing except non-countrygrants

For each category to have tick box for:

Includes amounts less than SOEthreshold; and

Includes amounts more than SOEthreshold

Phase 2:

Depending on the boxes ticked theSummary Form in Section 1.28 willinclude Form 101 and/or Form 102section to be compiled. (Form 101 >SOE, Form 102 < SOE).

I Mode of submission ofSOE

Tick box for selection of how SOE will besubmitted:(Phase 1) Scanned documentation(Phase 2) eForms

If eForms is selected new input screensto open. (see Section 1.28)

I Scanneddocumentation

Area where scanned documentation canbe uploaded for the individualwithdrawal application with specificboxes 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:



We hereby apply for withdrawal from the Loan/Grant Account opened under the IFAD FinancingAgreement and hereby certify as follows:

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

The goods and services covered by this application have been or are being purchased and/or procured inaccordance 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 statementof expenditure (SOE) thresholds are correct for the Project as provided in the IFAD Financing Agreement. Wecertify 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 andsection 9.01 of the General Conditions will be complied with, and that the requirements for maintainingrecords and documentation for expenditures disbursed using the Statement of Expenditure modality andoutlined 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 beretained for 10 years after the Closing Date of the IFAD Financing, and that such records and documentationwill be made available to IFAD representatives for review on request.

The undersigned hereby certify that all the supporting documentation to this withdrawal application has beensubmitted 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 immediatelypreceding advance and confirms that the funs withdrawn have been exclusively used in accordance with theGrant Agreement. All documentation authenticating these expenditures has been retained in accordance withparagraph 6.13 of Schedule 6 of the Agreement (the above article does not apply for first withdrawalapplication).

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

There should be the possibility for the B/R to upload scanned documentation (as noted in section1.5.3 above, be it scanned forms 101, 102, 104, 105, C10 and C11 or scanned supportingdocumentation.

1.5.4.Specific information to be requested depending upon type of disbursement request:Disbursement request Specific requirements

Advance payment – imprestaccount

Box to be ticked:

Please confirm that the relevant AWPB has been approved by



[Validation check by system] Fund and that all general and specific conditions precedent towithdrawal as specified in the Financing Agreement have beenmet before submitting your request

Advance payment – revolvingfund – first advance

[Validation check by system]

Box to be ticked:

Please confirm that the relevant AWPB has been approved byFund and that all general and specific conditions precedent towithdrawal as specified in the Financing or Grant Agreementhave been met before submitting your request

Advance payment – revolvingfund – subsequent advance

[Validation check by system]

Warning Message:

Please ensure that previous advances have been justified inaccordance with the Financing or Grant Agreement or Letter tothe Borrower (ass applicable) before submitting your request

Direct Payment New screen to open:(Phase 2) Picklist for contract number (once contract part hasbeen implemented – until then to insert contract number) orNewIf new contract, to provide number and option to upload.8

(Phase 1)Purchase order number – same as for contract number ;Currency of paymentAmountDescription of Goods, Works or ServicesInvoice numbersNet 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 noobjection Supplier’s invoice – duly certified by project director Certificate of delivery or certification of adequate services

being renderedFor 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 2Form to insert information on SOE See attached SOE

Both phases

Scanned supporting documentation to be attached.

8 See Contract management requirements



Checklist of items to be uploaded and possibility to upload: Bank guarantee for advance payments – see comments on

contracts Bank performance guarantee IFAD noobjection Evidence of payment; Supplier’s invoice – duly certified by project director Certificate of delivery or certification of adequate services

being renderedFor 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 submittedWhere the B/R submits paper WA the FA (or centralised processing unit) will be required to insertthe data on the paper WA into the eSubmission system instead of into FX as this will be necessary totake advantage of the logic within the workflow. All the relevant fields specified in 1.5.3 above willbe 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 Form100 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 andthen will submit the eForm.

1.7. Input screen for FA for projects where Cooperating Institution is usedWhere a project is not directly supervised by IFAD i.e. review of Withdrawal Applications isperformed by a Cooperating Institution, the information submitted by the CI will need to be insertedin the eSubmission system by IFAD staff. All the relevant fields specified in 1.5.3 above will beavailable 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 submissionwill not be activated for this kind of request. There will be no routing to CPM and the next step in theprocess will be the creation of the form and the validations at 1.15. Projects which will follow thisprocess can be identified from the User-defined field: Cooperating Institution in Flexcube. If this fieldcontains a value then this process will be followed.

1.8. System validations of withdrawal application requestValidates that the requested amount of the WA converted into denomination currencya.(SDR/USD/EUR) is not greater than the available balance of the financing. The systemblocks the disbursement in case the available loan/grant amount is exceeded. Warningmessage

“The amount requested exceeds the remaining balance in your account by SDR xxx.Please reduce the amount being requested or contact the Help-desk”

Checks that the total of all Categories =total of WAb.



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

Categories are overdrawn

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

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

Warning: “The advances have not been sufficiently justified to allow the payment of asubsequent advance. Click Continue if you wish to proceed, Save if you wish to completethe 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 theoutstanding initial deposit.

Warning: “The balance in the loan account is less than 2 times the initial deposit. If youhave not already done so, you should submit a recovery plan to IFAD in order not todelay future payments. Click Continue if you wish to proceed, Save if you wish tocomplete the application later or Cancel if you wish to withdraw the request”

If the WA is submitted and the balance in the loan account is less than 2 times thee.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”

If the WA is for a revolving fund and the WA is less than 30% of the outstanding advancef.or less than 50% of the AWPB, or if the WA is for an imprest account and the total amountis 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 amountaccepted by IFAD for this financing. Please refer to the Financing Agreement or Letter to theBorrower for the minimum withdrawal applications which IFAD accepts. Click Save if youwish to review further or Cancel if you wish to withdraw the request

Validates that in the case of replenishments, only categories linked to that special accountg.available for disbursement are used.Checks for possible duplication of WA: if a WA has been submitted for the same period ash.this WA and neither of the WA are direct payments

Warning: A withdrawal application has already been submitted for this period. Pleaseensure that this is not a duplicate. Click Continue if you wish to proceed with theapplication, Save if you wish to review further or Cancel if you wish to withdraw therequest

Checks for possible duplication of WA: if a WA has already been submitted for the samei.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



application, Save if you wish to review further or Cancel if you wish to withdraw therequest

Checks for uniqueness of WA number - i.e. no duplicate WA numbers are accepted, hencej.preventing double payments.

Error: This withdrawal application number has already been used. Please modify andresubmit

Validates that in case of replenishments or advances, the system checks that the currencyk.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 exceedthe defined ceiling of the special account.

Error: The amount requested is greater than the ceiling defined. Please amend and resubmit

Validates that payee input instructions available for the payment are only the onesl.maintained in the database.Validates that for supplementary grants, the amount disbursed does not exceed them.amount received from the donor (as interfaced from PeopleSoft into FX). No errormessage will be given to the B/R, however this should be noted on any notifications toFA/FO for follow up

“The amount being requested for payment exceeds the amount received from thedonor. Follow up is required”

If there is a process for AWPB within the portal (defined in separate document) and then.WA is for an advance payment to a revolving fund, the system will check that there is anapproved AWPB for the period of the WA. Where there is no AWPB for the period of theWA

“Warning: Before any advance can be paid from this account the AWPB needs to besubmitted and approved. Please ensure the AWPB has been submitted and approved. ClickContinue if you wish to proceed with the application, Save if you wish to review further orCancel if you wish to withdraw the request

If the WA relates to a direct payment, a help/warning message should be given:o.

“ Please ensure that the currency of the direct payment is the same as that of the contract. Ifit is not, the payment will be delayed”

1.9. Cancellation or modification of a WAThe B/R should be able to withdraw (cancel) a request before it is submitted to IFAD with notrace in the system. The B/R should be able to modify a WA before it is submitted to IFAD. IFa WA has already been approved online, any modification made will require that the WA berouted for approval at the B/R level again.

1.10. Communication of issues to IFADThe B/R has to have the possibility to be able to contact IFAD for assistance, hence therea.should be an area where questions can be raised or a request be raised for the help-desk.



1.11. Creation of Notification form for approvalOnce the data has been input the system will create a notification type form for review: -

FORM 100 - APPLICATION FOR WITHDRAWALIFAD Loan/Grant/Financing No.: xxxxxxxxxxxx Application No.: x

Borrower/Recipient nameAccount number xxxxxx

Project Name xxxxxxEnter into Forcedate xx/xx/xx

Funding Source xxxxxx Completion date xx/xx/xxxxxxxx Closing date xx/xx/xx

To: International Fund for Agricultural Development (IFAD)Via Paolo di Dono, 4400142 Rome, Italy

Application Type xxx xxxAs many types as B/R hasrequested

Amount to be Paid in Figures

xxx xxxAmount to be Justified in Figures

Withdrawal amount: xxx xxxCurrency Name Total Amount in Figures

Payment InstructionPayee’s Name and Address:Xxx The payment instruction section is a list of values

Payee’s Bank Correspondent Bank:Name: (not required when using the Direct Payment procedure)

This will be populated from the LOV above xxx xxxAddress: xxx

xxxAccount No.: Special Payment Instructions and References:

xxx xxx

Retroactive financing Y/Nxx/xx/xx xx/xx/xx

From (dd/mm/yy) To(dd/mm/yy)

Details of ExpenditureCategory Summary

Number Description Currency AmountSource of

supply

%financedby IFAD

xx xx xx xx xx xx



xx xx xx xx xx xxxx xx xx xx xx xxxx xx xx xx xx xx

TOTAL xxDocumentation of Eligible Expenditure

Electronic Statement of Expenditure xxTo include hyperlink to eSOE –Form 102 (Phase 2)

Scanned Statement of Expenditure xx To include hyperlink to Scanned documentScanned documentation fordirect payment

To include hyperlink to Scanned document

Scanned supportingdocumentation xx

To include hyperlink to Scanned document

For direct paymentsName and Address of Contractor or Supplier Procurement Details

(If different from Payee) a) Contract or Purchase Order No. and Date:xxx 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 bythis Application:

xxxCertification for financing to a countryWe 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 obtainfunds 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 relevantGeneral Conditions for Agricultural Development Financing

C. This Application for Withdrawal covers a reporting period:

xx/xx/xx xx/xx/xxFrom (dd/mm/yy) To (dd/mm/yy)

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



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

Certification for non-country grantsWe 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 immediatelypreceding advance and confirms that the funs withdrawn have been exclusively used in accordance withthe Grant Agreement. All documentation authenticating these expenditures has been retained inaccordance with paragraph 6.13 of Schedule 6 of the Agreement (the above article does not apply for firstwithdrawal application).

Additional certification for financing funded by EUA. 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 yearsfollowing Project closure.

xxx xx/xx/xxName of Borrower/Recipient Date (DD/MM/YY)

xxx xxxName(s) and Title(s) of Authorized Representative(s) online approval (s) of Authorized Representative(s)

All sections will be populated from the information inserted by the initiator or from the standingdata. Only the fields with information will be included. Where the field is blank this will not show onthe notification. Where noted there will be hyperlinks either to scanned documentation to enableany 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/Rcan 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 auditpurposes.

Where the WA is submitted at the level of project and there is more than one FX account associatedwith the project and therefore the initiator will need to provide the allocation of the WA to thedifferent types of financing, the Notification will be modified to include the information on thevarious accounts concerned – see sample below. This will also be true for the notification to IFADstaff.



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

1.13. Workflow for approval of request

1.13.1. Approval of request onlineOnce the information has been uploaded to the system and all errors and inconsistencieshave been resolved, the initiator will submit the WA for approval. There may be multiplesteps within the approval process however the workflow will only cater for one finalapprover. 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 unlessspecifically released by IFAD for amendment.

Application Type Total to be paid

Total to be justified

Total amount requested

Split by funding source Account number 1 Proportion for account 1

Proportion for account 1

Account number 2 Proportion for account 2

Proportion for account 2

Payment InstructionPayee’s Name and Address:

Payee’s Bank Correspondent Bank:Name: (not required when using the Direct Payment procedure)

xxxAddress: xxx

Account No.: Special Payment Instructions and References:

Retroactive financing Y/N


Number Description Currency Amount

%financedby IFAD

Account number 1allocation

Accountnumber 2allocation

xx xx xx xx xx xx xx etcxx xx xx xx xx xx xxxx xx xx xx xx xx xxxx xx xx xx xx xx xx


Electronic Statement of Expenditure xx To include hyperlink to eSOEScanned Statement of Expenditure xx To include hyperlink to Scanned documentCopies of records xx To include hyperlink to Scanned document


Withdrawal Amount xxx xxxCurrency Name Total Amount to be Paid in Figures

xxx xxx




xxx

Source ofsupply

xx/xx/xx xx/xx/xxFrom (dd/mm/yy) To (dd/mm/yy)

xxx

xxx

xxx xxx

xxxxxxxx

Amount to be Justified in Figures

xxx xxx

xxx xxxAmount to be Paid in Figures

xxx xxx



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

In the case where the Withdrawal Application has been submitted on paper, thedata will have been inserted/uploaded by a FA. The notification will be routed tothe FO for review and approval that the data inserted agrees with that on thepaper documents.

The FO or FA will have the possibility to reject the request back to the FA (hardcopy) 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 systemOnce 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 bemaintained) and to B/R.

For financing to a country the information on who to route the notification to can beobtained 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-friendlymanner

1.15.1. Form:A sample form for presentation of the data is attached. It is envisaged that this informationbe presented on one screen, possibly as a notification. In addition to the information madeavailable to the B/R the following information will be included:

Authorised allocation for Accounts which are Special Accounts (i.e. imprestaccounts)

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



Special conditions for payment

1.15.2. Warning messagesTo be generated on the form depending on system checks performed:

For financing funded by external donors i.e. supplementary funds, systemchecks that the amount allocated (Donor Amount) to the financing is more thanthe 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 paymentto outstanding advance. If (balance on the financing + current request forpayment) < 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 paymentcheck 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 thenThis project has ineligible expenditure pending

If financing has Category where Category Description = “Unallocated” andbalance on Unallocated > 7% of total financing and current date – completiondate< 1 year

Unallocated category more than 7% of financing and less than one year to projectcompletion

If current date – closing date < 6 monthsThere are less than 6 months to closing date

If available balance less this WA per category <0There are overdrawn categories in this financing

If WA is for an advance to a revolving fund (i.e. where category selected hasCategory Type = ADV), the system needs to compare the relevant percentage ofthe amount approved in the AWPB with the request for advance. The period ofthe WA and the period of the AWPB should be compared in order to select thecorrect AWPB amount. The relevant percentage of financing of the AWPB will beapplied 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) informationon whether the Audit Report has been submitted on a timely basis and whetherit is adequate or an action plan has been put into place. The information whichthe portal requires is



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 overdueThe action plan for the resolution of outstanding audit issues is not being implemented



FORM 100 - APPLICATION FOR WITHDRAWAL - for review

IFAD Loan/Grant/Financing No.: xxxxxxxxxxxx Application No.: x

Borrower/Recipient name xxxxxxxxxxxx

Account number xxxxxx

Project Name xxxxxxEnter into Force

date xx/xx/xx

Funding Sources xxxxxx Completion date xx/xx/xxxxxxxx Closing date xx/xx/xx

Financing Type xxxxxx Authorised Allocation CCY xxxxxxx For special ac

Status xxIneligible expenditure pending Y/N Risk rating xx

Percentage of advance to be recovered xx %AWPB approved Y/N/n/a For revolving fund

Amount of AWPB CCY xxxxxxxPeriod of AWPB dd/mm/yy to dd/mm/yy

Percentage of AWPB to be financed xx %Application Type xxx xx xxx

CurrencyAmount to be Paid in

Figures

xxx xx xxx

CurrencyAmount to beJustified in Figures

Withdrawal Amount xxx xxx

CurrencyAmount Requested in

Figures

Status of funds at time of WA submission

Categorycode

Categorydescription

Furthercategorydescription Allocated Disbursed %

Availablebalance SOE threshold

% financed byIFAD

xx xx xx xx xx xx xx xx xxxx xx xx xx xx xx xx xx xx



xx xx xx xx xx xx xx xx xxxx 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 requiredFor financing fundedfrom external donors

The balance in the loan account is less than 2 times the outstanding initial depositThere are less than 6 months to completion dateThere are outstanding advances For revolving fund - request for payment of advanceThis project has ineligible expenditure pendingUnallocated category more than 7% of financing and less than one year to project completionThere are less than 6 months to closing dateThere are overdrawn categories in this financingThe advance being requested exceeds the relevant percentage of the AWPBThe Audit report for this project is overdueThe action plan for the resolution of outstanding audit issues is not being implemented

Payment InstructionPayee’s Name and Address:Xxx Or a link to the uploaded form

Payee’s Bank Correspondent Bank:

Name:(not required when using the Direct Paymentprocedure)

xxx xxxAddress: xxx

xxxAccount No.:

xxx Special Payment Instructions and References:xxx




Number Description Currency AmountSource ofsupply

% financed byIFAD

xx xx xx xx xx xxxx xx xx xx xx xxxx xx xx xx xx xxxx xx xx xx xx xx


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 paymentsName and Address of Contractor or Supplier Procurement Details

(If different from Payee) a) Contract or Purchase Order No. and Date:xxx 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

xxx xx/xx/xxName of Borrower/Recipient Date (DD/MM/YY)

xxx xxxName(s) and Title(s) of Authorized Representative(s) Signature(s) of Authorized Representative(s)



1.16. Routing to CPM for review and/or approvalThe routing of the request based to the CPM needs to be completely configurable by ana.Administrator type role. The conditions below describe the current requirements. It isexpected that the routing will be dependent upon:Type of WA

Risk of project

Type of recipient

Value of WA

All requests, except for WA type Justification where B/R is not a country, are routed to theb.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 categoriesselected have “Category Type” = ADV, the routing is for information purposes. If mediumor high, the CPM will review the documentation submitted.For all WAs routed to CPM there will be the possibility for the CPM to:c.

“Comment”: Insert a comment to explain work performed, or particularcircumstances to subsequent reviewers;

“Ineligible expenditure”: The CPM will be able to note that the value of theWA should be reduced in the case that ineligible expenditure is noted. TheCPM will be required to insert information on the amount of the ineligibleexpenditure and a description. This information will be available forsubsequent reviewers on the review form. If ineligible expenditure is notedthe WA will be routed to the FA for reduction. The amount of the ineligibleexpenditure and the description will be interfaced to the FM tool onceapproved by the FO.

Once reviewed the CPM will have one of three options:d. “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 thepossibility to send notification through portal. If not through portal thenemail will be sent. The CPM will be notified after every 2 days that the WAis on hold. The WA will become available for edit by the B/R (see section1.13);

“Reject”: a notification will be sent to the FA/FO stating that the WA hasbeen rejected by the CPM. The CPM will have the possibility to insertcomments as to why the WA has been rejected and this information will beavailable to FA/FO. Only the FA/FO will be able to reject a WA back to theB/R.

“WA xxx for Financing xxxxxxx has been rejected by the CPM

Comments”

Once all issues with the WA have been resolved by the CPM, clearance is given. Thee.process for the review of the WA by CFS will continue regardless as to whether CPM



clearance is provided or not. However WAs for high or medium risk projects will not beinterfaced 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 Categoryf.Type is “ADV”, the WA will be routed to the CPM for certification that the amountrequested is in line with the AWPB. If functionality is included to upload and approve theAWPB 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:The routing of the request based on risk-based disbursements needs to be completelya.configurable. This includes also determining whether certain error or warning messagesaffect the routing of the WA. The following sections of this paragraph describe the currentrequirements and are included in order to understand the complexity of the routingrequired.Regardless of risk rating of project, the following withdrawal applications will be routedb.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 paymentsIf the risk of the project is low and the WA is for Results based disbursements and thec.Certificate has been received, route to FOIf the risk of the project is low and the WA is a replenishment, reimbursement ord.justification and the Account is an imprest account and the balance on the loan account isgreater than two times the initial deposit route to FOAll other requests route to FA for reviewe.As the risk based disbursement methodology may change over time, the system needs tof.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 Imprestaccount

Balance on loan> 2* initial deposit

Certificatereceived

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 Baseddisbursement

N/a N/a Yes Low FO



1.18. Straight-through processingThere should be the possibility to turn-on straight through processing (STP) for certain types oftransaction. Once turned on the applicable Withdrawal Application will be interfaced directly toFX once submitted by the B/R to IFAD. It is expected that whether STP is turned on for theindividual 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 < USD1million

<30% offinancing

Reimbursement Low Yes < USD1million

<30% offinancing

Justification Low Yes < USD1million

<30% offinancing

Results Baseddisbursement

Low Yes < USD1million

<30% offinancing

1.19. Comparison of information with standing data and routing of requests for reviewbased upon decision trees inherent within the system

One WA may contain several requests for payment . The FA/FO will need to have thea.possibility to treat these separately and approve or reject individual transactions.For all WAs routed to Finance Assistant there will be the possibility for the FA to:b.

“Comment”: Insert a comment to explain work performed, or particularcircumstances to subsequent reviewers;

“Ineligible expenditure”: The FA will be able to decrease the value of theWA in the case that ineligible expenditure is noted. The FA will be requiredto insert information on the amount of the ineligible expenditure and adescription. This information will be available for subsequent reviewers onthe review form. The amount of the ineligible expenditure and thedescription will be interfaced to the FM tool once confirmed by the FO.

Once reviewed the FA will have one of four options:c. “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 thepossibility to send notification through portal. If not through portal thenemail will be sent. The FA will be notified after every 2 days that the WA ison hold. The WA will become available for edit by the B/R (see section1.20).

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



rejected. The B/R and CPM will receive a notification and the WA willbecome 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 additionalinformation”

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

“WA no. xxx has been rejected by IFAD for the following reason”: insert text

For all WAs routed to Finance Officer there will be the possibility for the FO to:d. “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 willbe required to insert information on the amount of the ineligibleexpenditure and a description. This information will be available forsubsequent reviewers on the review form. The amount of the ineligibleexpenditure and the description will be interfaced to the FM tool once theWA is approved by the FO.

Once reviewed the FO will have one of three options:e. “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 asecond FO for review and approval. If the project risk is High or thefinancing is Grant and the amount is greater than USD 500,000 the WA isrouted to a second FO for second review and validation. Otherwise the WApasses to the approval stage;

Put “On hold”: the WA is temporarily suspended. Need to definecommunication with B/R – if through the portal then will require thepossibility to send notification through portal. If not through portal thenemail will be sent. The FO will be notified after every 2 days that the WA ison hold. The WA will become available for edit by the B/R (see section1.20);

“Reject”: the FO will have the possibility to reject back to the FA for followup or back to the B/R. WA will be routed back to the relevant user. The FOwill have the possibility to insert comments as to why the WA has beenrejected. If rejection is to the FA, the FA will receive a notification of therejection. If the rejection is to the B/R, the B/R and CPM will receive anotification 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 additionalinformation”



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

“WA no. xxx has been rejected by IFAD for the following reason”: insert text

1.20. Amendment of WA by B/RIf the WA is put on hold by the CPM, FO or FA, or if it is rejected back to the B/R, the WAa.in the system will become open for editing.If the WA is rejected, the B/R will be able to amend the WA, however it will require to beb.re-approved by the approver before being submitted to IFAD.If the WA is put on hold and if any information in the input boxes of the Form 100 isc.edited then the WA will require to be re-approved. If the change is only to upload scanneddocuments, then no re-approval will be needed.If additional information is uploaded by the B/R this should be easily identifiable by thed.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 ValidationIf the WA requires a second validation it will be routed to the relevant FO who will havea.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 beenrejected.

1.22. Approval stageOnce the WA has been reviewed and validated the system checks whether CPM approvala.has been provided for those financing instruments which require such approval (see 1.16above). If CPM approval has been received, the WA is ready for approval. The FO receivesa notification with a link to the approval page

“WA xxx is ready for approval, click here to approve for payment”

Notification should be sent to the FO if a WA remains in the approval stage for more thanb.2 days:

“WA xxx is ready for approval, click here to approve for payment”

If a WA is in the approval stage and CPM clearance is required and has not been received,c.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 SystemOnce the approval has been given by the FO and by the CPM, a record of the full withdrawalapplication (Form 100 and scanned documents attached or Phase 2 - Form 100, 101, 102, 104, 105



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 FlexcubeThe information on the WA is used to automatically create the relevant approveda.transaction in Flexcube (see Attachment 3 for the Application type). There are certainperiods of the month or times of the day in which it is not possible to process transactionsin Flexcube e.g. during the billing process; during the EOD process. These dates could bebuilt within the system or alternately the approval stage could be used to manuallydetermine when the transaction should be interfaced. The interface will be real-time andnot scheduled.Where a request for replenishment and justification have been submitted on the sameb.WA 2 transactions will be created: a “Request for Disbursement” and a “CategoryReallocation: Justification”.Where the request chosen by the B/R is “Advance or deposit to special Account” thec.system will create the appropriate transaction in FX depending on whether the account isan imprest account or revolving fund (see Attachment 3 for the Application type).Where the withdrawal application has been submitted at the project level, there needs tod.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 manye.transactions created in FX as requests submitted.Reports need to be available of any transactions which have not interfaced into FX forf.follow up and resolution by the Systems Data Officer

1.25. Integration with FlexcubeOn approval by the FO of the WA in the workflow, the WA will be interfaced to FX. Thea.entering of certain transactions in FX requires a maker and checker function. It is notintended that this be removed. Preferably the integration will create an approvedtransaction in FX. Should this not be possible, the FO (or a centralised processing unit) willthen access Flexcube and approve the transactions for payment. The FO needs to be ableto easily retrieve the transactions which are pending approval to avoid, where multipletransactions have been created that any of these are missed. This should be a notificationwith the links to the transactions in FX.

“the following transactions in FX are awaiting your approval:

RFDxxxxxxxxxxxxxx

JUSTxxxxxxxxxxxxx”

The FO should be alerted where there are transactions pending for approvalb.

1.26. Communication of payment to B/RAt the relevant point (after confirmation of execution of payment by the bank) the debita.advice is generated and is sent to the B/R via the email. There will be a link to self-serviceto allow the user to generate the relevant debit advice.



1.27. ReportingReports are to be available which can be downloaded in excel of the status of WAs, ina.order for IFAD to be able to reports on processing times and track WAs. At the same timethe B/R should be able to track the WA request through the workflow. Hence the systemmust have the ability to track the status (including the actor who is holding the step) ofeach WA at any point of time in the workflow. Furthermore the system should track thetime of completion of each stepStandard disbursement reports will be available for the B/R to generate subject to theb.security controls over their access to data. A separate Appendix 4 details thedisbursement 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. Theforms will cascade as follows:

I. Form 100 – total1.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 categoryII. Form 104 (A and B)III. Form 105IV. Form C104.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 beinput from Form 100 is described in detail in section 1.4. This section deals with the remaining formssubmitted by the B/R. Where information is held in the system or from the input of information bythe B/R on Form 100 the form should be automatically populated. All entries in the subsequentforms 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 cellswhich 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:



For all forms:

1. there should be the possibility to upload from excel;2. totals should be calculated and not input3. Buttons for Save, Cancel, Validate and Submit for Approval4. 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;5. 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.6. All forms need to be printable.7. The Forms can be completed in any order8. 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 validationcheck should only take place once all the forms have been updated, thus allowing for partialcompletion of the information before validation.

9. Submission for approval creates a notification which is then routed for approval according to theapprovals set up in the system.

10. 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 thecategory. If an amount is included which is greater than the SOE threshold, the followingerror 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 thesubmission 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 tableshould 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



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 beavailable for the final approver in the workflow of the B/R to approve the form through online approval:1. Statement of Expenditure for financing to country recipients2. Form 1013. Form 102/A Statement of Expenditure: Civil works, Goods and Consultancies4. Form 102/A Statement of Expenditure: Rural Finance, Grants and Subsidies and

Investment Capital5. Form 104/A – Designated Account Reconciliation (Imprest Account) or Form 104/B -

Designated Account Reconciliation (Revolving Fund)6. Form 105 – Checklist7. 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 submitor compile and print, depending on whether full electronic forms are used or whetherscanned forms are uploaded. The example in Attachment 5 shows which fields can bepopulated automatically depending on the type of submission used.



Attachment 1 – Standing data

No Information needed Format Source Status

10 Project Risk * H M L FM tool Data availablebut onlycaptured onspreadsheet.FM tool notyet in place

20 Bank account details fordesignated/special account

* Alphanumeric6 lines

Flexcube Data available

25 Correspondent bankinformation

Alphanumeric6 lines


30 Project name[Project name]

* Alphanumeric Flexcube Data available

40 FX account number andalternate account number

* Numeric for accountnumberAlphanumeric foralternate accountnumber


50 Financing Type * IFAD Loan, Grant,DSF Grant, ASAPgrant, STF loan, etc


60 Status[Work Flow Status]

* APPR -ApprovedCANC – CancelledCLSD - ClosedDSBL - DisbursableENTF – Entered intoForceEXPD - ExpiredPAID - RepaidSIGN - SignedSPND - Suspended


70 Funding Source * IFAD, ASAP, STF,Supplementary, HDR,HIPC, DSF


80 Categories * Number plusdescription


90 SOE threshold for eachcategory

* US$ amount FM tool Data availablebut onlycaptured onspreadsheet.FM tool notyet in place

100 Currency of Special/Advanceaccount

* ISO currency code Flexcube Data available

110 Type of Special/Advanceaccount

* Revolving Fund - ADVImprest Account -




SPL120 Closing date * Date Flexcube Data available130 Completion date * Date Flexcube Data available140 Original Financing amount * Currency and

amount (normallySDR but can be US$,EUR or other)


150 Amounts Disbursed * Currency andamount (normallySDR but can be US$,EUR or other)


160 Amounts undisbursed * Currency andamount (normallySDR but can be US$,EUR or other)


170 Date from which recovery tocommence

Date Data to becaptured

180 Recovery plan Percentages to berecovered for eachWA9

Excelspreadsheets/emails –possibly in FMTool

Data available,however notin one place

190 Start-up costs Currency andamount (normallySDR but can be US$,EUR or other)

Financingagreement –possibly in FMTool

Data to becaptured

200 For revolving fund:percentage which requires tobe justified before nextadvance can be given

Number 1-100 Flexcube Data available

210 For revolving fund:percentage of AWPB which isfinanced

Number 1-100 LTB or grantagreement –possibly in FMTool

Data to becaptured

220 For imprest account –authorised allocation

Currency andamount (normallyUS$, but can be EURor other)


230 Retroactive financing Yes or No andAmount

LTBFM Tool

Data to becaptured

240 Minimum WA amount Currency andamount (normallySDR but can be US$,EUR or other)Or percentage ofadvance or AWPB

This field can also be

LTBFM Tool

Data to becaptured

9 To be investigated further



zero250 Ineligible expenditure

pendingY or N LTB

FM ToolData availableon aspreadsheet.To be includedin FM tool

255 Percentage of each categoryfinanced by IFAD

Number 1-100 LTBFM Tool

Data to becaptured

260 Special conditions forpayment

Yes or No withcomment field

?? Data to becaptured

270 Risk based disbursementslimits

Area where RBD canbe updated anddictates workflow

Portal

*- indicates mandatory data for all projects



Attachment 2 – status of withdrawal application

1. Initiated –steps to 1.13.2. B/R approval – once WA has been submitted internally for B/R approval – step 1.133. Submitted – step 1.14 after final approval step by B/R4. On hold – for those WAs put on hold5. Rejected for those WAs rejected6. Validated after step 1.227. Approved for payment step 1.228. Paid (once the debit advice has been generated)



Attachment 3 - Mapping of information on WA to information in FX

Terminology used Flexcube field/TrxCountry name CountryFinancing Type If Loan then PRODUCT_CATEGORY

If Grant then PRODUCT_DESCIf DSF then PRODUCT_CATEGORY

Status Work Flow StatusProject Project NameFinancing number Account

Alternate Account NumberProject Number Project IDFinancing Amount Amount FinancedDisbursable Date Disbursable dateClosing Date Closing dateCompletion date Project Completion dateDisbursed Amount Total Utilized AmountUndisbursed Amount Total Available Amount

Application type* Advance for start-up costs

Request for Disbursement (RFD)* If Category Type is SPL = DS

If Category Type is ADV =DAAdvance payment or Initial deposit Request for Disbursement (RFD)

* If Category Type is SPL; RFD type is DSIf Category Type is ADV; RFD type is DA

Replenishment RFD - RPDirect Payment RFD - DPReimbursement RFD - DPJustification Category Redistribution – Activity – JustificationImprest Account If one of categories has Category Type SPLRevolving Fund If one of categories has Category Type ADV



Attachment 4 – Mapping of product codes, description and categories in FX

PRODUCT_CODE PRODUCT_DESC PRODUCT_CATEGORYORD1 ORDINARY TERMS SDR LOANSINT1 INTERMEDIARY TERMS SDR LOANSHCN1 HIGHLY CONCESSIONAL TERMS 0.75

pcLOANS

HRD1 HARDENED TERMS LOANSHC00 HIGHLY CONCESSIONAL TERMS 1.00

pcLOANS

IN00 INTERMEDIARY TERMS LOANSIFGR IFAD FUNDED GRANTS GRANTSLCMG LOAN COMPONENT GRANTS GRANTSSUPG SUPPLEMENTARY FUNDS GRANTS GRANTSECDG ECD GRANTS GRANTSOR00 ORDINARY TERMS LOANSDSSG DSF SELF-STANDING GRANTS DSFDHCG DSF HC GRANTS DSFORE1 ORDINARY TERMS EUR LOANSOFID LOAN ADMINISTRATION ONLY ADMIN_LOANSINE1 INTERMEDIARY TERMS EUR LOANSBT01 BLENDED TERMS LOANSASAP ASAP GRANTS GRANTSDSP1 DEBT SETTLEMENT PLAN LOANS



Page | 120

Attachment 5 – Withdrawal Application forms: 100, Summary of Expenditure, 101, 102, 104 and105

1 2 Application No.: x

To: International Fund for Agricultural Development (IFAD)Via Paolo di Dono, 4400142 Rome, Italy

3

Application Type

A.

B.

C.

D.

Details of Expenditure Payment Instruction

7 Payee’s Bank4 Name and Address of Contractor or Supplier Name:

(If different from Payee)

Address: xxx

Account No.:

5 Procurement Detailsa) Contract or Purchase Order No. and Date:

8 Payee’s Name and Address:b) Description of Goods, Works or Services:

c) Currency and Total Amount of Contract:

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

6 Withdrawal Detailsa) Category or Subcategory No.:

b) Percentage of Expenditures to be Financed by IFAD: 10 Special Payment Instructions and References:

11 12

13 14

xxx

xxx

xxx

Invoice Nos. and Net Amount of Invoices Covered by thisApplication:

xxx

xxx

xxx

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

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

Name of Borrower/Recipient

xxx

xxx

xxx

(Use summary sheet(s) if additional space is required or if expenditures relate tomore than one supplier, category or subcategory).

xxx

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

The goods and services covered by this application have been or are being purchased and/or procured in accordance with the terms of theGeneral Conditions for Agricultural Development Financing approved on 29 April 2009.

FORM 100 - APPLICATION FOR WITHDRAWAL

xxxxxxxxxxxxIFAD Loan/Grant/Financing No.:

xxx

xxx

xx/xx/xxFrom (dd/mm/yy)

xx/xx/xxTo (dd/mm/yy)

This Application for Withdrawal covers a reporting period:

Please Pay:

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

Currency Name Amount to be Paid in Figuresxxx

xxx

xxx xxx

xxx

xxx

xx/xx/xxDate (DD/MM/YY)


Project Name xxxxxx

xxx

xxx

xxxAmount to be Paid in Figures

xxx



Page | 121

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 Claimed under 101 Claimed under 102 Total

(Schedule 2)Localcurrency

WA Currency (e.g.USD) Local currency

WA Currency (e.g.USD)

Localcurrency

WA Currency(e.g. USD)

Category 1 Form 101 Form 101 Form 102 Form 102 Form 100Category 2 Form 101 Form 101 Form 102 Form 102 Form 100Category 3 Form 101 Form 101 Form 102 Form 102 Form 100Category 4 Form 101 Form 101 Form 102 Form 102 Form 100Category 5 Form 101 Form 101 Form 102 Form 102 Form 100Category 6 Form 101 Form 101 Form 102 Form 102 Form 100Category 7 Form 101 Form 101 Form 102 Form 102 Form 100

Total

Form 101 Form 101 Form 102 Form 102 Form 100 –Withdrawalamount

AnnotationsWA Currency This is the currency in which the Withdrawal Application is prepared and expenditure claimed for ReplenishmentFinancing number: This is the number of the loan or the grantReporting 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..



Page | 122

Financial reporting standards: The standards followed when preparing the project financial statements e.g. IFRS, IPSAS, IPSAS cash etc..Categories: These are the categories of expenditure as expressed in the Schedule 2 of the financing agreement.Claimed under 101: These are the expenditures above the SOE threshold and subsequently claimed under form 101 and for which supporting

documentation is required.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.



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 forthe proper execution of the Project in accordance with the terms and conditions of theAgreement dated _____________.

Name and Title _____________________________________________

Date _____________________________________________



FORM 101 - APPLICATION SUMMARY SHEET

Mark the procedure beingapplied:

Replenishment to the designated account

Direct PaymentReimbursement

Reporting period: xxxApplication No.:xxx

IFAD Loan/grant/financing No.:xxxx-xx

ItemNo.

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

Reference to therelevant AWPBand budgetline/item

Accountingsoftwarepaymentvoucher number

Reference tobankstatement/pettycash book(transfer check)

Contract orPurchase Order No.and Date

Brief Description ofGoods, Works orServices

Currency TotalAmountofContract

RemarksIncluding Countryof Origin

Net total of all Expenditures/Invoices xxx

% of expenditures to be financed by IFAD for Category xxx

Net amount claimed for this summary sheet Summary sheet

Exchange Rate xxx

Designated Account Currency Equivalent (US$/Other Equivalent): Summary sheet

Proper and complete supporting documentation attached



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, dulyfilled contract monitoring form (C-11) must be included in the Withdrawal Application.

Description ofCategory: Drop down list Date: xx/xx/xx

ReportingPeriod: xx/xx/xx xx/xx/xx xxxxxxxxxx

From(DD/MM/YY)

To(DD/MM/YY)

IFAD Loan/Grant/Financing No.

xxx xxxCategory No. Application No.

15. SOE threshold for the category:

ItemNo.

Full Description ofthe payment

Name of thepayee/Contractor,supplier, serviceprovider

Reference tothe relevantAWPB andbudgetline/item

Contract and/orinvoice number

Accountingsoftwarepaymentvouchernumber

Contractvalueandcurrency

Expenditure(invoiceamount inCurrency ofthepayment)

IFADFinancingPercentage

Date ofPayment

Rate ofExchange

Withdrawal ApplicationCurrencyEquivalent Claimed forReplenishment/justification/reimbursement


Country ofOrigin andother

Total Summary Sheet



*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 incurredare 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 financialmanagement. 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 documentationfor 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 annualaudit 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 for10 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:

Certifiedby: By:

(ProjectAccountant)

(Project Director) (Authorized Representative)



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: Drop down list Date: xx/xx/xx

Reporting Period: xx/xx/xx xx/xx/xx xxxxxxxxxxxxFrom(DD/MM/YY)

To(DD/MM/YY)

IFAD Loan/Grant/Financing No.

xxx xxxCategory No. Application No.

16 SOE threshold for the category:

ItemNo.

Full Description of thepayment

Reference tothe relevantAWPB andbudgetline/item

Accountingsoftwarepaymentvouchernumber

Name of theissuing entity(MFI etc..)

Nameof theclient/beneficiary

agreement/contractnumberbetweenthe LPAand theMFI

Contractvalueandcurrency

Expenditure(Currencyof thepayment)

IFADFinancingPercentage

Date ofPayment Rate of

Exchange

WithdrawalApplicationCurrencyEquivalent ofClaimed forReplenishment


Countryof Originandotherremarks

Total Summarysheet



*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 expendituresincurred 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, regularityand 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 maintainingrecords 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 documentationevidencing 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 reviewon request.

(Borrower/Recipient)

Certified by:Certifiedby: By:

(ProjectAccountant)

(Project Director) (Authorized Representative)



WA No.:

xx/xx/xx to xx/xx/xx

xxx )

1

2

3

4

5 PLUS BALANCE OF THE PROJECT ACCOUNT(S) (LISTED SEPARATELY)PLUS BALANCE OF SUB-ACCOUNTS (LISTED SEPARATELY)PLUS BALANCE OF CASH IN HAND

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

6 PLUS TOTAL AMOUNT CLAIMED IN THIS WA NO. Form 100

7

REASON:

8

DATE US$ AMOUNT

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

9

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

11 EXPLANATION OF ANY DIFFERENCE BETWEEN THE TOTALS APPEARING ON LINES 3 AND 10 US$User to have possibility to add as many rows as necessary and for each one a comment box shouldbe available

12 DATE:Name in Ful l

Ti tle in Ful l

US$

FORM 104/A - DESIGNATED ACCOUNT RECONCILIATION STATEMENT(IMPREST ACCOUNT)

(IN THE DESIGNATED ACCOUNT DENOMINATION CURRENCY – IMPREST ACCOUNT OPTION)

Project Title: xxx

IFAD Financing No.: xxxx - xx

Reporting Period:

xxx

DESIGNATED ACCOUNT: (Bank Account No.BANK NAME: xxx

TOTAL ADVANCED BY IFAD

LESS TOTAL AMOUNT RECOVERED BY IFAD US$

US$US$US$

EQUALS PRESENT OUSTANDING AMOUNT ADVANCED US$TO THE DESIGNATED ACCOUNT (Line 1 less Line 2)

BALANCE OF DESIGNATED ACCOUNT PER ATTACHEDBANK STATEMENT AS OF [DATE: [day/month/year]

US$

MINUS INTEREST EARNED (to becompleted. If zero, please enter ‘0’) US$

subtotal of 5

US$*

US$

PLUS TOTAL AMOUNT WITHDRAWN FROM THEDESIGNATED /PA/GRANT ACCOUNT AND NOT YET CLAIMED FORREPLENISHMENT) or WAs pending submission US$

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

PLUS AMOUNTS CLAIMED IN PREVIOUS APPLICATIONS BUT NOT YETCREDITED AT THEDATE OF BANK STATEMENT AND/OR CLAIMED AFTER DATE OF BANKSTATEMENT

APPLICATION NO.

US$subtotal of 8

xx/xx/xx SIGNATURE:

US$



WA No. xxx

IFAD Financing No.: xx/xx/xx to xx/xx/xx

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

US$

US$

2user to have possibility to include as manyrows as is requiredYears to be selected from list

US$

3

US$

4

US$

5 US$US$US$

US$

US$*

6 US$ Form 100

7

REASON/S: Eligible amount of expenditure for which a WA has not yet been prepared US$

8

DATE USD AMOUNT

user to have possibility to include as manyrows as is required

US$

9 MINUS INTEREST EARNED (to be completed; if zero please mark "0") US$

10 US$

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

12 DATE: xx/xx/xx SIGNATURE:Name in Ful l

Time in Ful l

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

e.g. non-eligible amount to be refunded to the designated accounte.g. calculation errors/errors in application of % financinge.g. counterpart financial resources to be reimbursed

Subtotal of 11:

WA No. --WA No. --WA No. --

Subtotal of 8

PLUS TOTAL AMOUNT CLAIMED IN THIS WA No. -----

PLUS TOTAL AMOUNT WITHDRAWN FROMTHE DESIGNATED/PA/GRANT/

ACCOUNT AND NOT YET CLAIMED

PLUS AMOUNTS CLAIMED IN PREVIOUS APPLICATIONSBUT NOT YET CREDITED ATDATE OF BANK STATEMENT AND/OR CLAIMED AFTERDATE OF BANK STATEMENT

APPLICATION NO.

PLUS BALANCE OF CASH IN HAND

Subtotal of 5

TOTAL OF BANK BALANCES, DA, PA, SUB-ACCOUNTS, CASH IN HAND (Line 4 + Line 5)

BALANCE OF DESIGNATED ACCOUNT PER ATTACHEDBANK STATEMENT AS OF DATE: [day/month/year]

PLUS BALANCE OF THE PROJECT ACCOUNT(S): [listed separately]PLUS BALANCE OF SUB-ACCOUNTS [listed separately]

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

TOTAL AMOUNT RECOVERED BY IFAD

EQUALS PRESENT OUTSTANDING AMOUNTADVANCEDTO THE DESIGNATED ACCOUNT (Number 1less Number 2)

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

TOTAL AMOUNT ADVANCED BY IFAD

LESS: AMOUNT RECOVERED BY IFADList WA Nos. -------- in 20xx

Designated Account No.: xxxBank Name: xxx

AMOUNT ADVANCED BY IFADFirst Advance in WA -- (VD -------)

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

Project Title: xxx

xxxx -xx Reporting Date:



xxx xxxFinancing No. WA No.

FORM 100 - APPLICATION FOR WITHDRAWAL Yes or NoEsignature andinput of forms insystem

Esignatureandscannedforms

1. Sequential numbering of withdrawal application System System

2. Withdrawal application amount tall ies with sequentially numbered summary sheets System

3. Categories/subcategories charged according to schedule 2 of financing agreement System System4. Percentage of financing applicable for each category or subcategory System System5. Availabil ity of funds in categories and the overall financing amount System System6. Currency of payment System System7. Completeness and accuracy of banking instructions System System8. Complete name and address of correspondent bank System System9. WA is signed by Authorized Representative System System10. Expenditure summary sheet by category attached System System

STATEMENT OF EXPENDITURE1. Eligibil ity of expenditures claimed (a) Within SOE financial ceil ing

(b) Expenditures under specific category [-----] eligibil ity

2. Form 102 signed by designated Project Accountant, Project Director, Authorized Representative System System

3. Form 102 supported by signed Form 101 (for items reported in 2, but over the financial ceil ing)

DESIGNATED ACCOUNT – REPLENISHMENT REQUESTS1. Amount within ceil ing figure agreed as a reasonable l imit [-- 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 used5. Completeness of designated account banking and account details6. Enclosed designated account reconcil iation and bank statements

SUPPORTING DOCUMENTATION (attached when/if required)1. Copy of contract2. Copy of invoice, certified by Project Director3. Copy of bank guarantee and performance guarantee (for advance payment)4. Copy of delivery receipt5. 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 contractnumber, total contract value, date of payment, l ist of supporting documentation, and reference tothe bank/petty cash statement.

PROCUREMENT1. 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 DISBURSEMENT1. In accordance with terms in section E of the Financing Agreement2. In accordance with terms in the Letter to the Borrower/Recipient

EXPENDITURE INCURRED/COMMITTED BEFORE PROJECT COMPLETION DATE1. 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:

FORM 105 CHECKLIST FOR WITHDRAWAL APPLICATION

Prepared by: Project Accountant

Dated: xx/xx/xx

Dated: xx/xx/xx

Certified by: Project Director


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



The integrity of this process is critical to the Withdrawal Application processing. Hence there willneed to be two-factor authentication access and approval of the banking instructions by theAuthorizer

1. Process1. 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 forcertification by the bank of the beneficiary. Alternately, the Author will upload invoice orcontract extract where the banking instructions are clearly identified.

4. The banking instructions to be inserted will follow the same approval process as a request forwithdrawal 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 appropriateAuthorizer 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 toenter a comment explaining why rejected. Rejection means the request will be routed back tothe 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 theaccess/identify management system.

10 Currently the update of banking instructions is performed by CFS and hence this would be included in theaccess 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.



9. The Validator will review the request and manually determine the validity of the bankinginstructions. If the BI are not considered adequate the Validator needs to be able to reject themback 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 capturingtechnology 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 thensubmit the BI for approval.

11. The Approver will review the BI in the system together with the scanned documents and eitherapprove or reject the BI. If rejected the Approver will be able to insert comments and therejection will be back to the Validator.

12. Currently the insertion of BI is in Flexcube. There are certain system validations therein on thelength of the account number, Swift code etc. These validations must be maintained whicheversystem is utilised, however they have not been redefined here, nor is it foreseen that a separatedatabase of rules and validations be created and maintained: the validations within FX must beutilised.

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 anapproved Payee Instruction record will be created in FX. If the insertion and approval is withinFX, the current functionality whereby the maker and checker are combined for PayeeInstructions 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 forthe 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.



Generic Data/Informations Personelles/Datos Generales

Beneficiary name

Financing Account Number

Address/Adresse/Dirección

Post Code/Code Postal/Código Postal City/Ville/Ciudad

Country/Pays/País

Phone Number/Téléphone/Teléfono Fax Number

E-Mail/Adresse electronique/Correo electrónico

Bank details/Detail de Banque/Datos Bancarios

Account Holder Name/Compte au nom de/Cuenta a nombre de

Account Number/Numero du compte/Número de Cuenta

IBAN No. (for European bank accounts)

Bank Name/Nom de la Banque/Nombre del Banco

Bank Address/Adresse bancaire/Dirección del Banco

Bank Branch/Sucursale/Sucursal

City/Ville/Ciudad Country/Pays/País

Swift BIC Code

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

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

Bank Name/Nom de la Banque/Nombre del Banco

City/Ville/Ciudad Country/Pays/País

Swift BIC Code

Date and signature/stamp of bank(Obligatory)

BANKING INSTRUCTIONS FORM

Account Number w ith Correspondent Bank/Numero du compte/Número de Cuenta

CHANGES SHOULD BE COMMUNICATED OFFICIALLY USING THE FORM WITH STAMP/SIGNATURE INCLUDED

PLEASE NOTE THAT ALL FIELDS ARE OBLIGATORY - INSTRUCTIONS WILL BE KEPT CONFIDENTIAL


Appendix 3 – Submission of AWPB - (detail description)

Submission of AWPB process

B/

Rn

CPM

CFS

PMU

Sm

Phase

AWPB prepared/amended

AWPB reviewedand approved

No

AWPB uploaded

Yes

AWPB Submitted

AWPB reviewedand approved

No

CFS role would be to access data:* Period* Amount* Scanned document* Status

Notification toCPM

EndYes

Start

Notification to B/R

< 30 days fromsubmission of

AWPB

Yes

Is AWPB ‘OnHold’, orRejectedNo

Yes

AWPB Accepted

Notification to B/R

End



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 relateso amount of the AWPBo Currency

And will submit the AWPB to IFAD

4. 11The 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 theGeneral Conditions, if no comment is provided to the Borrower/Recipient within 30 days theAWPB shall be deemed to be acceptable to the Fund”

5. The CPM will have the possibility too accept the AWPB oro reject the AWPB back to the PMU and provide comments to the PMU oro 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 withthat 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 Submittedo Acceptedo Rejectedo Draft

7. If the status of the AWPB has not changed status in 10 days the CPM will receive notificationsevery 10 days as follows:

“AWPB for the period xxx to xx for financing xxx was submitted on xx/xx/xxxx and is ready foryour review. In accordance with the General Conditions, if no comment is provided to theBorrower/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 putinto Draft, the status of the AWPB will automatically move to ‘Accepted’ and the CPM willreceive 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 theB/R9.1. On status change to Accepted

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



“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 seebelow 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 belowthe 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 thedocumentation uploaded, unless it is put into Draft status. At that point the B/R will be able tomake changes and resubmit. If the AWPB is rejected then the B/R will be able to delete theuploaded 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 anynumber 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 insertedon the submission of the AWPB to the date information inserted for the WAo AWPB periodo AWPB statuso Amounto Currencyo Uploaded document


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 theportal. 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 canbe up to 10. For each condition there will be an option to indicate that documentation willbe uploaded or that confirmation will be provided. [For example the opening of a bankaccount may be a disbursement condition, however the communication of the details mayfollow a different process and hence requesting the B/R to upload information at this stagecould be duplication]. Disbursement conditions will be set up for each type of financing andnot at the project level.

2. There are general disbursement conditions which derive from the General Conditions forFinancing. Furthermore there will be a mandatory condition that the Letter to the Borrowerhas been issued. These will be proposed for all financing as follows:

Project Name: ABCD XXXXXXXXXXXXXXXXXXXXXXXXX

Financing: 100000363100 L-I--801-

Disbursement conditions CPMapproval

Documentationrequired

Confirmationrequired

Referencedocument tag

First AWPB approved – Section4.02 GC

Y/N 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, oncesubmitted by the B/R if necessary. The FO/FA will select approval by CPM – Y or N for eachsingle condition.

4. Given that the information will be available to the B/R there will be a possibility for reviewand approval by the FO

5. Also for review and approval by the CPM for confirmation that information for which CPMapproval is needed is correct. The CPM will see all disbursement conditions at this stage andwill have the possibility to reject back to CFS for changes.

6. There should be the possibility to link documents submitted in the disbursement conditionsprocess to the Reference documents section and vice versa. This will happen wherever thedisbursement condition refers to a standard tag in the Reference documents. The user willbe required to select the tag from a dropdown list and if a document exists with that tag, toselect the document and link it.

7. Once this information is approved the B/R will be able to access a screen of disbursementconditions where the text inserted is re-proposed, together with either a box to tick (ifconfirmation is needed) or the possibility to upload documentation, (where this has beenindicated by CFS).

Project Name: ABDC XXXXXXXXXXXXXXXXXXX



Financing: 100000363100 L-I--801-

Disbursement conditions Documentationrequired

Confirmationrequired

First AWPB approved – Section4.02 GC

Y – upload here Y

Letter to the Borrower issued Link todocument

Y

Project and PMU staff recruited Y

Draft PIM including FinancialManagement section approved byIFAD

Y upload here Y

Project Account opened Y

Fully-fledged financialmanagement system installed

Y

8. The condition concerning the Letter to the Borrower is the one condition which the B/R willnot 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 totick 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 declarationsfrom the B/R with 3 options for action to take:

o Approve – this creates a transaction in FX whereby the status of the financing ischanged to DSBL

o Reject – goes back to the B/R with a notification explaining the reason for therejection (missing information or additional information needed)

o On hold – minor information which can be resolved in a minimum time period12. 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 besubmitted


Appendix 5 – Reallocation of Category - (detail description)



1. Background1.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 isrequired, the B/R submits an official request which has been approved internally. This is thepoint 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 asfollows:

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 President1.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 withthe attached flowchart and as described briefly in point 2 above. The text of the officememorandum 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 overallautomation of this process requires an approval workflow within IFAD. Consideration mustbe 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 portal1.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 ofWithdrawal Applications (Appendix 1) or by searching directly on the project. In all casesthe 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/Rwill be able to enter/select as many lines as necessary from the financing (i.e. no need toenter all categories). The B/R will also have the possibility of selecting a New Category andnaming it from a dropdown list of standard categories in FX.

Category Name CategoryNumber

Authorisedamount (A)

Reallocation(B)

Revised Amount (A-B)

Drop down list ofcategories from FX– excludingcategories whereCategory Type is

From FX From FX Inserted byB/R

System calculated



SPL or ADV

New category From FX 0 Inserted byB/R

System calculated

1.7. B/R uploads a scanned document giving the reason for the reallocation and the amounts tobe 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 forreallocation (table above) and the scanned document. Key information to be included onthe 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 thepossibility to review the request, approve, reject and add comments. If the notification isrejected then the routing is always back to the CPM for follow up with the B/R. The CPMwill be required to enter specific comments on the reasons for the reallocation [currentprocess is that a 2 page memo is written, hence the area for comments needs to besufficiently large to allow such text to be entered].

1.11. Once the request has been submitted it should be routed for review and approval asfollows:

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”



1.14. If at any point in the process the request is rejected, the person rejecting will havethe possibility to insert comments, explaining the rejection. The comments will be visible tosubsequent reviewers. Furthermore, the reviewer will be able to tick boxes to indicatewhether 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 havingto pass through Legal and CFS.

1.15. In the first routing to the CPM and to CFS, there will be the possibility to amend theamounts inserted by the B/R for reallocation. This is to ensure that the amounts insertedare correct. Once approval has been given by CFS, it will not be possible to change theamounts for reallocation. The role of CPM/CFS will also be to check that the amountsreallocated have been inserted correctly.

1.16. If the reallocation requires the creation of a new category, once all approvals havebeen obtained the CPM will receive the following notification

“Reallocation for financing xxx has been approved, however it requires the creation of a newcategory. 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 requesthas been approved, either a “Category redistribution” or VAMI transaction is createdautomatically 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 yourapproval”

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 dataentered in the system. All future reports for this financing will show the revised allocations.”


Appendix 6 – Increase/Decrease in Special Account Allocation - (detaildescription)

Increase in Special Account allocation

Borrower/Recipient CFS CPM

Determine need foran increase in the

authorisedallocation



Submit request forincrease

Approveincrease in AA



Start Start Start

End

Inform B/R andCPM

Updateinformation

in FX

No

Yes

yes

End

Review request forincrease

Notification to B/R &CPM


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

1. Background1.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 withother experts.

1.3. In reviewing the request the FO takes into account the FM rating of the project as well asthe 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 portal1.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 Header-search function at 1.5.1 in eSubmission of Withdrawal Applications (Appendix 1) or bysearching directly on the project. In all cases the request for reallocation is submitted at thelevel of financing.

1.7. The request can be entered by the B/R, CPM or CFS. If request is entered by CFS, it will bethe FO which enters it. This is only available for imprest accounts i.e. where Category Typeis SPL. If the financing has more than one imprest account, a picklist will be available of eachof 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: 1000000363100Alternate Account number: L-I-801-Project Name: ABCDPicklist: Designated Account – Authorised Allocation

Designated Account – Authorised Allocation – abcDesignated Account – Authorised Allocation – defg

1.8. Once submitted, a notification will be created with the summary of the change beingrequested (table above) and if any scanned document. Key information to be included onthe 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


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 beensubmitted”

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 FO1.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 beenentered in the system and is awaiting your approval”

1.13. Once the VAMI is approved the B/R receives the following notification copying theCPM:

“The special account allocation for account xxx for financing xxx has been changed to CCY xxx xxx.”


Appendix 7 – Contract Monitoring - (detail description)

1. Background1.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 generallycommunicated by email.

1.3. The PMU should maintain a Contract Register (form C10) where all significant contracts arerecorded.

1.4. For each contract the project should maintain a contract monitoring Sheet (C11) detailingthe original contract plus amendments, any guarantees provided as well as a schedule ofpayments made.

1.5. Each time a payment is submitted to IFAD for replenishment, justification or for a directpayment 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 portal1.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 toupload 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 portalas a document management system, but will be interfaced to the document managementsystem of IFAD with a link being retained in the portal to allow the information to beaccessed 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 thelist of disbursements in order to link the WA to the contract monitoring. It will not bemandatory for the payments to be linked to a WA. This means that it will be possible toupdate the contract monitoring form and then link it to a WA.

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

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


Appendix 7 – Contract Monitoring

1.12. Whenever a payment is inserted, the system will compare the total payments withthe 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 alsoincluded 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 bepossible to link from Form 100 and the subsidiary forms to the Contract monitoring andfrom 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 ofnavigating 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 possibilityof changing the status of the contract to closed. The status can only be changed to closedonce all WAs which reference the contract monitoring have been paid. Once the status isclosed, it will not be possible to link to a WA and hence will not be proposed in any picklistof contract monitoring

1.17. There should be the possibility for the initiator to select a contract monitoring byproject, by contractor, by status or insert a new contract monitoring sheet.


Appendix 7 – Contract Monitoring

Comp.:ContractOfficer:

xx/xx/xx

No.

Currency (Default to currency of contract)

Signature Signature

Date(s) of ‘NoObjection’:

Name and Addressof

Supplier:

e-mail:telephone:

Bank Details:

Description ofContract:

ProcurementFile No.: xxx

Amount Dates (start/end)

Contract Summary

(ENTER PROJECT NAME AND ACRONYM)

(Contract Number: as per contract register)

Original Contract

(ENTER CURRENCY)

Document Contract Reference

Amendment (AM-1)Amendment (AM-2)Amendment (AM-3)

0Total Amount

ExpiryDate

Bank Securities orBonds ( -- currency)

Document Name of Financial Institution Date

Advance PaymentPerformance BondOther

Date Invoice No.No.

Amount

PaymentDate

Extension

Monitoring ofPayments

FORM C-11- CONTRACT PAYMENT MONITORING FORM

Programmecoordinator:

Financial Controller:

Notes:

Balance Dueon ContractAmount

Paid

Payments IssuedPayment ScheduleProgress

CertificateChequeor WA

No.

TotalAmount

0 0

Milestone ExpectedAmount


Appendix 8 – Submission of Recovery Schedule - (detail description)

1. Background1.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 isreplenished as WAs are submitted. Towards the end of the financing, the B/R submits arecovery schedule to plan how the advance paid at the beginning of the project will berepaid.

1.2. Generally, towards the end of the financing, for each WA submitted, the project plans thata certain percentage (or amount) will be offset against the advance and a certainpercentage (or amount) will be paid as a replenishment.

1.3. CFS provides an excel spreadsheet to the project in order to plan the recovery. Oncesubmitted by the project this is reviewed by the FO to ensure that the advance will berecovered before closure. If necessary the recovery schedule may be amended by CFS toaccelerate the recovery.

2. Functionality1.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 advanceaccount. Hence where currency is shown as a header in the first section, this should defaultto the currency of the payments made against the Category Type “SPL” or “ADV”. Thecurrency of the Justification area should default to the same currency. DEN is thedenominated currency of the financing and this will be calculated at the historic exchangerate at the date of payment of the tranches which form the outstanding advances or specialaccount.

1.7. There will be a recovery plan for each special or designated account. Thus the initiator willselect the appropriate account from a picklist of accounts for the relevant financing. Thepicklist will contain all those transactions with Category Type “SPL” or “ADV” where thereare outstanding amounts.

1.8. The initiator will be required to complete the information concerning the advance accountand 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 zeroamounts. The initiator will have the possibility to save the recovery schedule or submit toIFAD.



1.10. Once submitted the system will check that the required fields are zero and if not theinitiator will receive the below warning message and will not be able to proceed unless thefields are zero.

“Warning: the recovery schedule does not cover the full amount of the advance. Pleaseadjust and resubmit.”

1.11. On submission the recovery plan will be routed to the FO for acceptance and the FAfor information. The FO will have the possibility of accepting or rejecting the recoveryschedule with the possibility of inserting comments which will be routed back to theinitiator. 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 thecomments 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 theFA and FO during the WA process.

1.13. Once the recovery schedule has been submitted a second area below will show theactual recoveries made. This will be populated by all justification transactions processedagainst 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 particularfinancing.

1.14. The planned recovery schedule together with the actual recoveries will be availablefor the initiator to view. The initiator will be able to amend the area for planned recoveries,but not the actual recoveries information.



IFAD Loan/Grant No.: 0.00

Borrower:DD/MM /YY

Loan Effective DateDD/MM /YY

(Today) Date:MONTHS

$ - WA No. Date LocalCurrency USD DEN

S/N Period covered by WA WA No. (Expected) Date ofreceipt

Estimated valueLocal Currency

Estimated value(USD)

ProposedRecovery %

Recovery Amount(USD)

Cumulative(USD)

1 Nov-13 0.00 0% 0.00 0.00

2 Dec-13 0.00 0% 0.00 0.00

3 Jun-14 0.00 0% 0.00 0.00

4 Oct-14 0.00 0% 0.00 0.00

5 Dec-14 0.00 0% 0.00 0.00

6 Jan-15 0.00 0% 0.00 0.00

7 0.00 0.00

8 0.00 0.00

9 0.00 0.00

10 0.00 0.00

11 0.00 0.00

12 0.00 0.0013 0.00 0.00

0.00 0.00 TRUE

RECOVERY PLANTO THE SPECIAL OR ADVANCE ACCOUNT

IFAD Loan/Grant Amount (SDR)

Loan Completion Date:

Loan Closing Date:

JUSTIFICATION:

TOTAL

REMAINING # OF MONTHS TO CLOSING DATDD/MM /YY

Unjustified balance

USD DEN

Authorized Allocation orOutstanding advance

0.00 0.00

Actual recoveriesAdvance

(USD)Advance (DEN)

WA No. Date Amount recovered(USD)

Amountrecovered (DEN)

Outstanding Advance(USD)

OutstandingAdvance (DEN)


Appendix 9 –Reporting Requirements

1. BackgroundThe 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 obtaininformation 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 fordonors (reporting for donors is not in scope for this contract).

2. General RequirementsThe 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 financingproposed 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 wherespecified, 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 ofbilling 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



3. Overview of pages in portal and linksThe 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 sectionas numbered.

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

Info

Page My portfolio

(4)

Project at aglance

(5)

FinancingOverview

(6)

Disbursements

(7)

DebitAdvice

(8)

Designated &Advance Account

(9)

IFADdisbursementsto B/R(10)

Financingstatus

(11)

Individualloan status

(12)

BillingStatement

(13)

Instalmentschedule

(14)Shortdescription

Entrance pointfor projectinformationSummary of allactivefinancinginstruments byproject

Overalloperationalinformationon a project

Information onindividualfinancingincludingstatus of funds

Alldisbursementsfor a singlefinancing

Self-serviceto runreport forsinglepaymentsmade byIFAD to theproject

Information onall thedesignated andadvanceaccounts foreach financing

This page willgiveinformation onthe history oftotaldisbursementsin a graphicalformat

Entrance pointfor LoaninformationInformation toBorrowers onstatus of allloans – howmuch has beendrawn downand how muchhas been repaid

Informationto Borrowerson individualloans, howmuch hasbeen billed(principaland interest)and howmuch hasbeen repaid

Self-serviceto run billingstatementfor singleamountsbilled byIFAD

Information toBorrowers onfutureinstalments,both forindividual loansand for all

Reportscurrentlyavailable

Report 4.1Report 4.2Report variesdependingupon access ofuserNo reportcurrentlyavailable – infofrom FX

5.1 –Informationfrom GRIPS

6.1 -Informationfrom FX6.2 - Status ofFunds

7.1 - HistoricTransactionreport

8.1 DebitAdvice

Report 9.1 –designated oradvance accountReport 9.2 –Treasury pooledaccountsInformationfrom FX –requirescustomisation

10.1 Graphderived fromDisbursementreport

11.1 LoanDisbursementandRepaymentsReport

12.1 HistoricrepaymentFile

13.1 BillingAdvice

14.1 Instalmentamounts byBorrower anddue dateRequiresmodification asonly has datafrom FX i.e. noanalysis of datapre 11-13

Drilldown To 5.1 –ProjectnumberTo 6.1 –Financing noTo 7.1 –Disbursed

To 7.1 –AmountdisbursedTo 9.1 or 9.2 –Financing noTo referencedocs –

To Withdrawalapplication – WAnoTo 8.1 – WA no

To 7.1 –DisbursedAmountTo 12.1 –AccountnumberTo reference

To 13.1 –AmountBilled



AmountTo 10.1 –Financingnumber –where user hasaccessTo referencedocs –Financingnumber

Financingnumber

docs –Financingnumber

User to beable to runat any dateand exportto excel

No No Yes Export to excelonly

Yes Run at any date No Yes Yes Yes Yes



4. My portfolioMy portfolio will be the point of access of users. If a user has access to more than one project orcountry, there should be the possibility to search for financing. The results of the search will dependupon the access of the user. If the user has access to only one project the information will be showndirectly. The user will also have the possibility of designating financing as favourites to avoid havingto search each time.

Header – search function12 Title Options CommentsS Borrower or Recipient Country Name

PMUImplementing AgencyRecipient

The options availablewill depend upon theaccess of the user andwill need to be definedby the countries. Alloptions should beavailable to make theaccess as wide orrestricted as necessary

S Financing Type All or drop down list ofoptions from Attachment1 to Appendix 1

S Status All or drop down listfrom Attachment 1 toAppendix 1 – multiplechoices are allowed

S Project All or drop down listfrom Attachment 1

To check with users ifthey require name or(alternate) accountnumber (expect name)

S Funding source All or drop down listfrom Attachment 1 toAppendix 1

To check with users ifneeded

S Financing number(FX Account number)

All or drop down listfrom Attachment 1 toAppendix 1

Brings back following data for each project with the projects shown as a list. The data will bepresented in tabular format as shown below together Not only will information be provided onprojects and the financing instruments of the projects but also there will be graphical representationin pie charts and bar charts of the amount financed and disbursed by project and comparing thetotal financing with the total disbursements. Where the denominated currency of the financialinstruments differs, the graphs will be shown by currency.

The different types of access which are envisaged for the various groups of users are:

Borrowers or recipients – view all financing for the country of reference or for the non-country recipient

12 A = Standing data dependent on accessS = Standing data



Implementer (Project Management Unit, Implementing Agency) – view information on allprojects which the PMU or implementing agency is involved in the implementation

Cooperating Institution – view information on all projects which they are involved in theimplementation

OFID – view information on all projects financed by OFID i.e. for which IFAD is thecooperating institution



4.1. Borrowers or RecipientsThe users who will expect to access this type of report are the following: Ministries, Permanent Representative to IFAD, Cooperating Institution, OFID and Non-Country GrantRecipients

Borrower or Recipient: xxxxx Date: As at 25/5/15

Projectname

Project Number –Financing Number

AlternateAccount Number

Ccy Financing Amount Financing Type Status DisbursableDate


Disbursedamount

Undisbursedamount

Percentagedisbursed

ABCDE 1447


100000447900 123B SDR 8 450 000.00 LOANS Signed - 8 450 000.00 0.00%


Disbursable 21/03/2011 30/09/2018 31/03/2018 74 272.70 555 727.30 11.80%

100000448000 456B SDR 650 000.00 LOAN COMPONENTGRANTS

Signed 650,000.00 0.00%

Total SDR 39 330 000.00 4 970 571.91 33 709 428.09 12.64%

ABCDE 1376

100000274900 789 SDR 10 050 000.00 LOANS Disbursable 26/06/2008 30/09/2017 31/03/2017 7 551 398.37 2,498,601.63 75.14%


Disbursable 09/07/2008 30/09/2017 31/03/2017 635 000.00 - 100.00%

Total SDR 10 685 000.00 8 186 398.37 0.00 76.62%

ABCDE 1571



Disbursable 12/11/2014 31/12/2020 30/06/2020 128 161.27 501 838.73 20.34%

Total SDR 44 770 000.00 1 835 320.53 501 838.73 4.10%

ABCDE 110000174500

SDR 3 380 000.00 ASAP GRANT Enter intoForce

31/12/2023 30/06/2023 - 3 380 000.00 0.00%


Enter intoForce

31/12/2023 30/06/2023 - 950 000.00 0.00%



Total SDR 4 330 000.00 0.00 950 000.00 0.00%



Financing Amount (in SDR)

ABCD

EFGH

IJKLM

NOPQR

Disbursed Amount (in SDR)

ABCD

EFGH

IJKLM

NOPQR

0.00

5.00

10.00

15.00

20.00

25.00

30.00

35.00

40.00

45.00

50.00

ABCD EFGH IJKLM NOPQR

Financing Amount compared toDisbursed Amount ( millions of SDR)

Financing Amount (in SDR)

Disbursed Amount (in SDR)



4.2. PMUProject: ABCDE Date: As at 25/5/15

Projectname

Project Number –FinancingNumber

AlternateAccountNumber

Ccy FinancingAmount

Financing Type Status DisbursableDate


Disbursedamount

Undisbursedamount

Percentagedisbursed

ABCDE 1447


100000447900 123-B SDR 8 450 000.00 LOANS Signed - 8 450 000.00 0.00%


Disbursable 21/03/2011 30/09/2018 31/03/2018 74 272.70 555 727.30 11.80%

100000448000 456-B SDR 650 000.00 LOAN COMPONENTGRANTS

Signed 650,000.00 0.00%

Total SDR 39 330 000.00 4 970 571.91 23 709 428.09 12.64%



Financing Amount in SDR

L-I--801-

L-I--801-B

G-I-C-1159-

G-I-C-1159-B

0.005.00

10.0015.0020.0025.0030.0035.00

Mill

ions

Financing Amount compared toDisbursed Amount ( millions of SDR)

Financing Amount

Disbursed amount

Disbursed amount in SDR

L-I--801-

L-I--801-B

G-I-C-1159-

G-I-C-1159-B



5. Project at a glanceBy clicking on the project ID, the user will be directed to a page showing an overview of theproject. Full details of the information to be shown has yet to be defined. An initial example is asfollows:

5.1. Project at a glanceAll the information below is available in GRIPS

Project short name: ABCD Country: XXXXXXXXXXXXXProject name: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXProject number: 1447

Project Overview - Total USD 72 159 083.00Financiers USD Key DatesIFAD Loan 26 999 850.00 Start date 14/05/2007IFAD Additional Loan 12 999 660.00 End-date 30/09/2018IFAD Grant 999 400.00IFAD Additional Grant 998 680.00Total IFAD 41 997 590.00

National Government 15 342 900.00National Government - additional 3 977 351.00Total National Government 19 320 251.00

Beneficiaries 8 814 400.00Beneficiaries - additional 2 026 842.00

10 841 242.00

Environmental and Social classification B

Innovative Features

Project ComponentsCommunity Development

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 userinvolvement from branch canal downward will ensure completion of improvements; (ii) establishmentof 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 localconditions to render it demand- and market driven; and (iv) introduction of a participatory extensionapproach 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 wateruse to the farmers.



6. Financing overviewIf accessed from the My Portfolio page the Financing Overview will show the information for theselected financing instrument. If Financing Overview is used as the point of entry, the usershould be able to select the financing which they wish to see the Overview for.

6.1. Financing Overview HeaderThe financing overview for each type of financing will have the following information:

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 isdenominated, be it XDR, USD or EUR or other. The user will have the possibility of changing thecurrency to one of SDR, EUR, USD or local currency for the country concerned. Where thecurrency is changed from the denominated currency all figures will be calculated at the currentexchange rate of the date that the information is provided. A message will be includedexplaining the exchange rate used.

Project name: ABCDE Country: XXXXXXXXXXXXXXXFinancing: 100000363100 123 Status: Disbursing

Financing OverviewData as of 25/5/15 Currency XDR Key Financing DatesAmount Financed 19 600 000.00 Approval 17/12/2009Cancelled or reduced - Signing 15/02/2010Total Util ized 4 896 299.21 Effective 16/02/2010Total Available Amount 14 703 700.79 Completion 21/02/2018Percent disbursed 24.98% Closing 30/09/2018

In processWithdrawal Applications submitted -Estimated funds available 14 703 700.79

Project name: ABCDE Country: XXXXXXXXXXXXXXXXFinancing: 100000363100 123 Status: Disbursing

Financing OverviewData as of 25/5/15 Currency USD Key Financing DatesAmounts are translated from the financing denominated Approval 17/12/2009Currency at the exchange rate of 0.710769 Signing 15/02/2010Amount Financed 27 575 766.53 Effective 16/02/2010Cancelled or reduced - Completion 21/02/2018Total Util ized 6 888 734.89 Closing 30/09/2018Total Available Amount 20 687 031.64Percent disbursed 24.98%

In processWithdrawal Applications submitted -Estimated funds available 20 687 031.64



6.2. Status of FundsThe Status of Funds will be shown below (see screen shot – the screenshot has been reorganisedand information excluded where it is already included in the above table). This report needs tobe amended to display the status of funds in other currencies where selected in the above tableand 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 theuser, 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 forconversion to USD. For other currencies to use the exchange rate at the date ofrunning of the report.

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



7. Disbursements

7.1. Historic Transaction ReportThis page will give details of the disbursements for the financing. It will be accessible from theDisbursed Amount in My portfolio (section 4) and also from the Amount Utilised in the FinancingOverview (section 6). If Disbursements is used as the point of entry, the user should be able toselect the financing for which they wish to see the Disbursements.

Historic information will be provided and the total of disbursements will agree to the TotalUtilized on the Financing Overview page. The current report which exists in BI is the HistoricTransaction Report. The users will be able to export the information to excel. The explanationnotes on the Historic Transaction Report will be included as a footnote.

Once eSubmission for WA has been implemented any WA processed through the portal willhave 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 userto run reports through BI. This report will be exportable to excel.



8. Debit Advice

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

9. Designated Account or Advance AccountThere will be a page available with information on the bank account details for all designatedaccounts and Advance Accounts. This will be accessible from a tab

Different information will be presented depending on whether the account is managed under theimprest method (Category = ‘SPL’) or Revolving Fund (Category =’ADV’). The information with whichthis page will be populated is available in FlexCube, however there is no report currently availablewhich provides the information. In addition, the ability to identify the data easily is dependent upona remarks field, which is not always complete nor is standard text used. Hence it will be necessary tobe 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 bankinginformation data is not held in FX, but can be obtained from the Query by W/Application, Beneficiaryreport in DW.

Given the difficulties inherent in identifying systematically the designated or advance account, thereare 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.



Two reports are required:

Designated or advance accounts by financing instrument Pooled Treasury accounts (see paragraph below)

9.1. Report of designated or advance accountFor Imprest accountsAccount - 1IFAD Account number 100000363100Account Holder XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXAccount Holder's Bank CENTRAL BANK OF ABCAccount Number 408248526Current Authorized Allocation USD 1 500 000.00

Advance to Account USD 1 500 000.00Justifications USD -

Total deposits USD 3 039 717.61Documented USD 1 539 717.61Outstanding balance USD 1 500 000.00Transactions in process USD -

Account - 2IFAD Account number 100000363100Account Holder XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXAccount Holder's Bank CENTRAL BANK OF ABCAccount Number 19265161257Current Authorized Allocation USD 1 500 000.00

Advance to Account USD 1 500 000.00Justifications USD -

Total deposits USD 1 500 000.00Documented USD -Outstanding balance USD 1 500 000.00Transactions in process USD -



9.2. Pooled Treasury accountsWhere the B/R uses pooled Treasury accounts for multiple projects, the portal should alsoprovide information on an aggregated basis. This information is not maintained in currentIFAD systems, hence the portal should contain the possibility for a Validator or Approver to

For Imprest account with justificationsAccount - 1IFAD Account number 100000248900Account Holder XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXAccount Holder's Bank CENTRAL BANK OF ABCAccount Number 254082177290Current Authorized Allocation USD 1 300 000.00

Advance to Account USD 1 300 000.00Justifications USD 57 JUST (253 642.86)

USD 62 JUST (575 206.44)USD 64 JUST (353 017.24)USD 65 JUST (118 133.46)

Total Justifications USD (1 300 000.00)Balance on Account -

Total deposits USD 12 111 487.07Documented USD 12 111 487.07Outstanding balance USD -Transactions in process USD -

Account - 2IFAD Account number 100000248900Account Holder XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXAccount Holder's Bank BANK OF NEW YORKAccount Number 892569190607Current Authorized Allocation USD

Advance to Account USD -Justifications USD -Balance on Account -

Total deposits USD 6 847 149.30Documented USD 6 847 149.30Outstanding balance USD -Transactions in process USD -

For Revolving Fund account with justificationsAccount - 1IFAD Account number 100000438700Account Holder XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXAccount Holder's Bank EQUITY BANK LIMITEDAccount Number 51022294452827

Advances to Account EUR 1 120 054.00EUR 02 107 073.00

Total Advances 227 127.00Justifications EUR SOE APR 2014 A (120 054.00)

EUR SOE APR 2014 B (7 147.78)Total Justifications EUR (127 201.78)Balance on Account EUR 99 925.22

Total deposits EUR 227 127.00Documented EUR 127 201.78Outstanding balance EUR 99 925.22Transactions in process EUR -



indicate that Pooled Treasury accounts are used and then select the projects and financingwhich are linked to that Pooled Treasury account.

If Pooled accounts are selected then there will be a page with the pooled accounts whichadds up all the information on the bank accounts above and presents it on an aggregatedbasis.

10. Total IFAD disbursements to borrower or recipientThis page will provide an overview of the total amount that IFAD has disbursed to the Borrower orRecipient on a year by year basis, cumulative and by currency. In this way the borrower or recipientwill be able to have an overview of funds provided by IFAD to the country/non-country recipient.

10.1. Total disbursements by IFADThe information is available in the BI report “Disbursement report”. The report can be run on afrom and to date basis. The graphs to be presented are for each currency and the underlyingdata is obtained from the disbursement report itself.

-

20 000 000.00

40 000 000.00

60 000 000.00

80 000 000.00

100 000 000.00

120 000 000.00

140 000 000.00

160 000 000.00

to1990

1991 -1995

1996 -2000

2001 -2005

2006 -2010

2011 2012 2013 2014 2015

Cumulative Disbursements (SDR)

SDR



11. Financing StatusThis page will only be available for loans and not for grants. Users should be able to access theFinancing Status directly (i.e. as a point of access) as well as from the My portfolio page or theFinancing Overview page. From the latter pages the user should be able to access Financing statusinformation 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 haveaccess.

The access of Borrowers will be linked to the information for the specific country and henceaccessing the financing status page will cause a summary of all loans to be generated. There exists acurrent report in BI “Loan Disbursements and Repayments Report” which provides the informationrequired. This will be presented as shown in the following table.

-

100 000.00

200 000.00

300 000.00

400 000.00

500 000.00

600 000.00

700 000.00

800 000.00

900 000.00

1 000 000.00

to 1990 1991 -1995

1996 -2000

2001 -2005

2006 -2010

2011 2012 2013 2014 2015

Cumulative Disbursements (USD)

USD



11.1. Financing status reportCountry: XXXXXXXXXXXXXXXXXXXDate: 25 May 2015

Loan denomination Currency XDR

Account number Alternate Account number Approval date Signing DateEntry into Force

date FinancedAmount

DisbursedAmount Billed Amount

RepaidAmount Outstanding Undisbursed

Percentagedisbursed

Percentagerepaid

1000001970 123 09 December 1982 13 December 1982 28 July 1983 21 940 332.63 21 940 332.63 12 355 801.00 12 355 801.00 9 584 531.63 - 100.00% 56.32%1000002017 456 14 September 1984 09 November 1984 06 December 1985 10 100 000.00 10 100 000.00 10 100 000.00 10 100 000.00 - - 100.00% 100.00%1000002183 789 15 April 1992 11 December 1992 30 December 1993 16 199 058.88 16 199 058.88 16 199 058.88 16 199 058.88 - - 100.00% 100.00%1000002237 123 20 April 1994 30 June 1994 25 January 1995 13 965 596.31 13 965 596.31 5 142 644.00 5 142 644.00 8 822 952.31 - 100.00% 36.82%1000002332 456 05 December 1996 30 March 1998 25 January 1999 17 289 013.55 17 289 013.55 4 901 678.00 4 901 678.00 12 387 335.55 - 100.00% 28.35%1000002380 789 10 September 1998 10 December 1998 18 June 2001 17 891 242.22 17 891 242.22 3 915 961.00 3 915 961.00 13 975 281.22 - 100.00% 21.89%1000002442 123 04 December 1980 10 December 1980 05 August 1981 21 800 000.00 21 800 000.00 13 352 500.00 13 352 500.00 8 447 500.00 - 100.00% 61.25%1000002489 456 23 April 2002 29 May 2002 09 April 2003 14 600 000.00 12 466 359.02 7 300 005.00 7 300 005.00 5 166 354.02 2 133 640.98 85.39% 58.56%1000002514 789 11 December 2002 20 March 2003 13 December 2004 - - - - - - 0.00% 0.00%1000002749 123 14 December 2006 07 March 2007 24 September 2007 9 050 000.00 7 551 398.37 2 345 000.00 2 345 000.00 6 705 000.00 1 498 601.63 83.44% 31.05%1000003631 456 17 December 2009 16 February 2010 16 February 2010 19 600 000.00 5 864 556.33 986 667.00 986 667.00 4 877 889.33 14 722 110.67 29.92% 16.82%1000004150 789 03 December 2012 - - - - - - 0.00% 0.00%1000004451 123 21 January 2013 28 December 2014 16 April 2015 8 450 000.00 - - - - 8 450 000.00 0.00% 0.00%1000004479 456 13 December 2011 10 April 2012 10 April 2012 44 140 000.00 1 707 159.26 - - 1 707 159.26 42 432 840.74 3.87% 0.00%

215 025 243.59 146 774 716.57 76 599 314.88 76 599 314.88 71 674 003.32 69 237 194.02 68.26% 52.19%



In addition with being presented with the information, users will also have the possibility of runningthe 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 Amountrepaid will allow drill down to the Individual Loan status page

12. Individual Loan Status

12.1. Report of Status of individual LoanThis page provides a summary of the loan (as a header) and the information on amounts billedand 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:

In addition with being presented with the information, users will also have the possibility of runningthe 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 separatesection below)

Project name: ABCDE Country: XXXXXXXXXXXXXXXXXXXFinancing: 100000363100 123 Status: Disbursing

Loan Status Key Financing DatesData as of 25/5/15 Currency SDR Approval 17/12/2009Financed Amount 19 600 000.00 Signing 15/02/2010Disbursed Amount 5 864 556.33 Effective 16/02/2010Billed Amount 986 667.00 Completion 21/02/2018Repaid Amount 986 667.00 Closing 30/09/2018Outstanding 4 877 889.33Undisbursed 13 735 443.67 Loan Denomination Currency :SDRPercentage disbursed 20%Percentage repaid 3%

Due Date TypeAmount Billed

(DEN)Amount Billed

USDPayment

DateDelay(Days) Amount Repaid DEN

Under/Over

PaymentDEN

AmountPaid

CurrencyAmount

Repaid USD

Under/OverPayment

USD15/08/2011 I 2 001.59 3 192.66 15/08/2011 0 2 001.59 - USD 3 192.66 -15/02/2012 I 3 068.47 4 953.75 15/02/2012 0 3 068.47 - USD 4 953.75 -15/08/2012 I 3 257.30 5 044.91 15/08/2012 0 3 257.30 - USD 5 044.91 -15/02/2013 I 3 504.15 5 083.46 15/02/2013 0 3 504.15 - USD 5 083.46 -15/08/2013 I 4 992.08 7 573.23 14/08/2013 -1 4 992.08 - USD 7 573.23 -05/11/2013 ADCH_CR_INT (20.62) (31.59) 25/02/2014 112 (20.62) - USD (31.78) (0.19)15/02/2014 I 5 292.91 8 172.84 25/02/2014 10 5 292.91 - USD 8 157.38 (15.46)15/08/2014 I 6 722.72 10 279.38 26/08/2014 11 6 722.72 - USD 10 276.42 (2.96)15/02/2015 L 666 789.00 1 019 554.21 25/02/2015 10 666 789.00 - USD 1 019 554.21 -15/02/2015 I 12 099.53 17 126.88 25/02/2015 10 12 099.53 - USD 17 072.68 (54.20)

707 707.13 1 080 949.73 707 707.13 - 1 080 876.92 (72.81)

Total Interest 40 938.75 61 427.11 40 938.75 61 354.49 (72.62)Total Principal 666 789.00 1 019 554.21 666 789.00 1 019 554.21 -

(20.62) (31.59) (20.62) (31.78) (0.19)Total add'l charges/(credits)



13. Generation of Billing StatementClicking on the Amount billed will allow the user to drilldown to the self-service for the billingstatements. The current report which is in BI is the Billing Advice.

13.1. Billing statement

14. Instalment ScheduleIn addition Borrowers will be able to obtain instalment schedules for each of the loans by clicking onthe specific loan and at a total level by Borrower. The report available in BI for the individual loans isLoan Instalment Schedule and this is not available on a total basis. Furthermore, where loans were inexistence at 1 November 2013 (date of implementation of FX) the first instalment represents all theprevious instalments billed as a lump sum.



14.1. Report for instalment schedule


Appendix 10 –Site Structure

Graphical representation

The following diagram is intended to represent the various areas/pages which would beavailable 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 howthe site will be developed has been determined


Appendix 10 –Site Structure


Appendix 11 – Reference Documents


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 documentswith 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 followingdocuments 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 followingdocuments with links to the documents themselves

Audited financial statements Interim financial statements Subsidiary Loan Agreement Implementation Agreement or Memorandum of Understanding

Financial Reference Documents7. 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 availablewithin the relevant directories than those which the B/R will be required to view. Hence there isthe requirement for the development of a secure system for the upload and approval ofdocuments, referenced to the appropriate financing and/or project, to be made available forviewing by the B/R.

8. There should be the possibility to access previous versions of the documents as well as maintainan 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 willupload the document in the relevant directory and this will be reviewed by the Approver andapproved or rejected. If rejected, the Uploader will be informed through notifications. Ifapproved, the document will be made available for viewing in the portal and a notification willbe sent to the B/R.

10. Routing from the Uploader to the Approver will be based upon information held in theaccess/identity management system.

11. There should be the possibility for new areas to be added and for the documents to be sorted bythe B/R in order to find the document required. Each document will be tagged as to its contentswhen uploaded and there will be a set of standard tags (Financing Agreement, Financing



Number, Letter to the Borrower, Signatories, Start Date, End Date). It will be possible to amendthe tags by an administrator role.

12. There should be the possibility to access previous versions of the documents as well as maintainan audit trail of the period of relevance of the documents

Operational Reference Documents13. 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 asdescribed 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/R16. 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 financialstatements 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 inorder to find the document required. It is expected that the following categories will berequired:

• 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.




The Portal will require the creation of at least the following user roles. Other roles may added as required.

Role Responsibi l ityFunctions

Expectations from the product


View data, runreports;

View WA forms

Ability to view data, obtain meaningful reports


Create withdrawalrequests, submitbanking instructions,confirm disbursementconditions, submitAWPB, access No-objection workflowsubmit request forreallocation ofcategories, Submitrequest for increase inSpecial Accountallocation, Submitrecovery schedule,Contract monitoringForm

Ability to create transactions easily, withoutIFAD intervention


Authorize withdrawalrequests, bankinginstructions, AWPBsubmission,disbursementconditions

Ability to review various forms for accuracy,compliance and to approve, thus authorizingborrower submission to IFAD for approval orno-objection

Uploader Inserts and correctsinput errors towithdrawalapplicationssubmitted on paper,AWPB, Bankinginstructions.,confirmation of

Ability to create WAs easily. No routing toAuthorizer required



disbursementconditions, , requestsfor reallocation ofcategories, requestsfor increase in specialaccount allocation,recovery schedule andcontract monitoring

Validator Review withdrawalsubmission(s), bankinginstructions,confirmation ofdisbursementconditions, requestsfor reallocation ofcategories, requestsfor increase in specialaccount allocation,recovery schedule andcontract monitoring

Review withdrawal submissions in accordancewith project risk rating requirements andvalidate submission for payment. Dependingon Risk Rating and straight through processingset up this is either a system role or CFS staffrole.

Reviewer - IFAD View and review WA,disbursementconditions, AWPB,request forreallocation ofcategories, request forincrease in SpecialAccount allocation,contract monitoring

Review withdrawal submissions in accordancewith project risk rating requirements andvalidate eligibility of expenditure. Dependingon Risk Rating, this is either a system role orCPM staff role.

Review and approve disbursement conditions,AWPB, request for reallocation of categories,request for increase in Special Accountallocation. View contract monitoring

Approver Approve WA, Approvebanking instructionsdisbursementconditions, requestfor reallocation ofcategories, , requestfor increase in SpecialAccount allocation,recovery schedule andcontract monitoring

Approve withdrawal submission for payment.Depending on Risk Rating, this is either asystem role and/or CFS staff role. May also givesecond approval for WAs where not providedfirst approval.

It should be possible to assign the approverrole by function or funding source.

Review and approve disbursement conditions,request for reallocation of categories, , requestfor increase in Special Account allocation,recovery schedule and view contract



monitoring

Viewer - IFAD View data, run reports

View all forms

Access should be to allprojects and financing

Ability to view data, obtain meaningful reportsacross all financing.

Administrator - IFAD AdministrateApplication access byroles; configure oroverride risk ratingcategory, straightthrough processing,CPM routing,categories anddirectories for uploadof referencedocuments.

Phase 2Configure new formsfor SOEs whereneeded

Responsible for assigning certain users to roles,and adding or changing risk rating, straightthrough processing information and CPMrouting information.

Phase 2Also responsible for customising forms toinclude new forms for SOEs and new categoriesfor reference documents.

Depending on the request submitted, this iseither an ICT role and/or CFS staff role.

Access administrator –Borrower/recipient

Administrate limitedapplication access byrole at theBorrower/recipientlevel

Responsible for assigning certain users tolimited roles. This is an administrator role forthe client whereby the granting of certainaccess will be managed by a representative ofthe Borrower/recipient.

The access of users of the Borrower/Recipient for viewing and for the submission of requests will be limited tothose countries or projects which they are authorised to access. For example, the staff at the project level will onlyhave access to the information on a project (and probably not the debt-servicing area), while at the Ministry levelthe 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 willdepend 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 rolesbecomes that particular user's profile. In order to ensure segregation of duties, one user would not be assignedAuthor and Authorizer.

The role of Validator, Uploader, Reviewer-IFAD, Viewer- IFAD, Approver, or Administrator are IFAD internal facing



roles that would be assigned to IFAD staff, and consistent with Segregation of Duties, that precludes the role beingheld by the same person.

• Viewer-B/R: Default role to be issued to all B/R by Organization Liaisons. This permits access to the Fund’swebsite 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. TheOrganization 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 signWAs. 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 mayrequire 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. Thisis 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 thetransactions/requests and providing comments or approving the request. Depending on the process there will bedifferent levels of Reviewer and the workflow should be able to route requests from Reviewer 1 to Reviewer 2 toReviewer 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 beheld 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 beheld 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 atthe Borrower/Recipient level such as the resetting of password, updating of email addresses for the distribution ofdebit advices and billing statements; limited set up of users and association of access for certain roles. It is countryor recipient (for non-country recipients) specific, hence an Administrator-B/R in one country will not be able togive access to information other than the country/recipient to which they are assigned. The role will not be able toassign Authorizer to any user and is incompatible with the Author and Authorizer role.

IFAD 2015 020 RFP Lot 1 Terms of Reference

Documents

Transcript of IFAD 2015 020 RFP Lot 1 Terms of Reference