Scope of Work – Three Lot Tender
This Scope of Work includes the following lots:
- Provision of open-loop card (or other biometric) solution – ATM/POS cards
- Provision of closed-loop card (or other biometric) solution. (Including e-voucher cards)
- Transfer to a named beneficiary via local money agent / post office.
This is likely to be applicable to: Banks
Card Providers
International/Domestic Remittance agents
Closed Loop payment system providers
Block Chain technology providers
Scope of Work – Lot One – Open loop electronic transfers (Bank Cards)
1Core Activities:
1.1Provision of ATM’s cards, Primary account for LRC, Sub-accounts for LRC and funding partners, proxy accounts for beneficiaries
1.2Provision of physical ATM cards and any other related hardware needed to implement the programme i.e. POS terminals
1.3Detailed reporting as described below and preferably access to an online platform (online banking) for reporting and reconciliation
2In detail, services required will include (but not be limited to):
2.1Provision of producing reloadable, personalized (names or number) standard-sized ATM cards, that can be used at ATM’s and POS devices, transactions should be limited to only Lebanon (the card should not be able to work in other countries) and with a 3 year validity.
2.2Cards should have a chip and a magnetic stripe.
2.3All issued cards must have the ability to be used at ATM’s
2.4All issued cards must have the ability to be used at POS terminals
2.5All issued cards must have the ability to be restricted to either ATM or POS.
2.6Each card should be linked and secured by a unique PIN number.
2.7The ability to de-activate cards upon the request of LRC.
2.8The ability to re-issue cards and pin numbers to LRC if reported as damaged or stolen.
2.9Cards should be delivered deactivated in sealed envelopes. The PIN numbers should be in sealed envelopes, with a unique reference number on the envelope
2.10For contingency and emergency planning purposes, a stockpile of non-personalized ATM cards (instant issuances) will need to be pre-positioned.
2.11For ATMs, cards need to be able to be used in multiple bank branches as well on bank’s proprietary network/ATMs or interoperable at other bank ATMs (Master Card, Visa).
3Card/ Account Administration:
3.1Preferably Cards will have a certain barcode which will be linked to a LRC’s database for tracking of card distributions to facilitate the accountability as well as bank and card transfers’ reconciliations.
3.2Cards must be able to accommodate multiple funding sources usingFirst-In First-Out (FIFO)in order to allow cash transfers to the same beneficiaries on a single card. Provision of virtual accounts (sub-account) for beneficiaries under the main LRC account shall be ensured. The virtual accounts must be linked to an individual or family number as advised by LRC and other organizations using the services. Banking system should have the ability to provide full traceability of sources of funds and the utilization of funds e.g. by using the First in First Out (FIFO) system.
3.3Fees, other transaction or withdrawal charges and all related costs should be covered only by LRC and/ or the organization providing funds and not by end users themselves.
4Reporting:
4.1Periodic submission (as close to real time as possible, minimum of daily or 24/hours) of reports and uploaded transactions (both to the donor accounts and the beneficiaries’ accounts) and the statement of LRC account shall be made available.
4.2Card incidents. The Financial Service Provider (FSP) to report weekly on the list of lost cards and replacements, PIN resets and other card incidents.
4.3Financial movements and balances on the cards: FSP to report of all proxy account activity including expenditures, credits and balances.
4.4LRC must have the ability to send back any unspent balances remaining on cards to LRC’s account.
4.5FSP reconciliation: The FSP to send weekly update on the details for the account in order for LRC finance to do the reconciliation.
4.6The use of LRC case number or equivalent in all instructions, reporting and reconciliation of funds as part of Data Protection and privacy.
4.7Provision of online information management systems accessible to LRC (internet banking).
5Coverage of services
5.1Country-wide coverage of ATMs to all parties and individual beneficiaries. Where ATMs do not exist, LRC might request service provider to increase coverage through installation of additional infrastructure or mobile ATMs.
6Other requirements
6.1Fraud proof/anti-corruption features in the cards and the system as well as secure transmission of data (i.e. use of HASH and VPN) compliance with Payment Card Industry Data Security Standards).
6.2As close to 24/7 hours as possible - accessible and toll-free hotline reachable by phone and online by the LRCand the individual beneficiaries. The FSP call centre will handle common cardholder queries (PIN reset, card inactivation in case of loss/ theft/ replacement, etc.).
6.3Centralized management by the Financial Service Provider of the financial administration of transactions, including other services such as detailed reporting on refunds (using First-In First-Out method), ownership of the not withdrawn funds, monthly calculation of charges, etc.
6.4SMS notifications will be required to be sent to all cardholders, once payments are uploaded and have been approved by the FSP. Automated SMS standard message should be delivered to refugee mobile SIM cards for e.g.: “You have just received your monthly financial assistance of X amount from LRC. Please go to the nearest ATM to collect your entitlement. For any issues, please call X number’. LRC would require that a unique identifier (name and/or card/registration number) is used on the text. Duplicate messages will not be sent where duplicate numbers are provided. This must also be available in Arabic.
6.5Unspent and unused amounts will be refunded to LRC or other organization whose funds were transferred originally based on SOPs that will be developed by LRC.
The above scope of work covers the provision of the services that are required by LRC but does not cover all aspects of the relationship between the service provider and LRC.
Issues relating to fees, terms and conditions, performance metrics will be covered in the bidder response document.
Scope of Work – Lot Two – Closed loop electronic transfers (e-vouchers)
Core Activities:
- Set-up the e-vouchers system according to the below minimum system functionalities
- Supply all necessary hardware, including customization (with beneficiary information) smart cards
- Design/make available back-end management platform
- Provide technical oversight and trouble-shooting, as well as training for staff and vendors
Minimum requirements
1.1Summary of Product Needs:
1.1.1An electronic voucher platform shall deliver functionality in a number of key areas, and will specifically:
1.1.2Enable voucher distribution to program participants.
1.1.3Enable transactions between participants and approved vendors, permitting the exchange of electronic vouchers for locally available goods, according to program rules.
1.1.4Provide access to a centralized management platform that supports LRC administration of voucher programs.
1.2Hardware
1.2.1Vendor terminal: LRC will accept NFC enabled Android devices to serve as vendor terminal hardware and transaction process used by participants and local vendors for voucher redemption. The minimum specification of the android device must be provided to LRC so that they can determine whether or not it is preferableto purchase from the service provider or on the local market.
1.2.2Receipt printers: LRC is willing to accept any printer that meets the requirements of the system.
1.2.3Cards: LRC is willing to accept a card which is the most comfortable for the Service Provider, as long as it meets the needs of the system. This could include cards with magnetic strips or chips redeemed at vendor terminal.
1.2.4Platform: proposals must include a centralized management platform that is accessible online and provides easy and quick access to voucher transaction data.
2Minimum Specifications:Selectedelectronic voucher systems will be able to meet the following requirements:
2.1Program Set-up Requirements
2.1.1The system must support registration of individual participants and vendors.
2.1.2The system will accept uploads of spreadsheets containing participant and vendor profile data.
2.1.3The system will allow LRC to add or remove additional participant or vendor profiles throughout the program cycle.
2.1.4The system must allow changes and edits to participant and vendor profiles (e.g., add missing data, correct incorrectly entered data, etc.).
2.1.5The system must allow smart cards customization with beneficiary name and picture
2.1.6The system must support definition of voucher content (the value and validity period of each voucher).
2.1.7The system must support batch disbursement of vouchers to participants, including the ability to assign different types of vouchers to participants based upon attributes.
2.1.8The system must support wallet functions, allowing disbursements for different purposes, under different donors
2.1.9All funds will be recorded and tracked in the Commonly Transactional Currency identified for each deployment.
2.1.10The management platform is available in English and Arabic.
2.1.11The android application or transaction interface between Vendor and Participant is available in English and Arabic
2.1.12All receipts must be able to be printed in English and Arabic
2.1.13The system must support the transactions in the off-line environment, as well as be supported by Wi-Fi and 3G connection.
2.1.14The system will allow device-to-device synching
2.1.15The system will allow reports, invoices and receipts print-outs
2.1.16The system will allow negative restrictions forbidding use for designated products (e.g., alcohol).
3Communication Requirements
3.1Error messaging will be provided when transactions fail to process. Error messaging should be visible to the participant and vendor and should include reasons for failure and suggested remedy. Errors should also be logged in the management platform. Specific handling of transaction errors and error messaging should be described in the proposal.
3.2Successful transaction messaging should also be provided, which will notify vendors and participants about successful transactions and remaining account balances.
3.3System is capable of providing transaction and account total updates to vendors and participants upon their request (for participants account total = currency amount or quantity of goods left, for vendors this account total = total amount sold in established billing cycle).
4General Transaction Requirements
4.1Vendors must be provided with a means to authenticate the identity of a participant attempting a transaction.
4.2The system must deduct value from participant accounts following a transaction.
4.3Transactions will be identified by a unique transaction number.
4.4Failed transactions should also be assigned a transaction number.
4.5The system will track transactions by the following attributes: unique transaction number, vendor, participant, date, time, amount/quantity spent and voucher number.
5Reporting Requirements
5.1System can provide both raw, unanalyzed data, and structured reports.
5.2All reporting should be downloadable in an excel data format that can be sorted and analyzed by LRC.
5.3Reporting can be provided through pre-defined scheduled reports and on-demand reports.
5.4Scheduled reports will have defined formats and will be sent to LRC according to a defined timetable. On demand reports will have defined formats and will be available on request.
5.5Proposals should indicate the specific types of reports that are available.
5.6It is preferred that the system has data analytics features in the form of manipulable dashboards that show a variety of demographic, transactional and market information and that the dashboards are customizable to the needs of the programme.
5.7The system must support Arabic language as a minimum on any application being used by field staff and vendors and ideally on the desktop management platform.
6LRC Program Management Requirements
6.1The administrative voucher management system must be accessible by a wide range of LRC staff members. Staff members granted access will be assigned a user ID, password and access level based upon their seniority and approval authority. Ideally, the system should track and capture LRC User Profile information (including user ID) for all system interactions. This information must be able to show which LRC user completed actions within the system (including both file uploading and direct interaction with the system to upload and edit specific records).
6.2Differing levels of access and permissions is desired.
7Program Requirements to be handled outside the system
7.1Cash reconciliation, that is the process of making payments to the vendors, is not in scope, and will be handled off-line. (Although the system must generate reports that will be used to calculate reimbursement amounts).
The above scope of work covers the provision of the services that are required by LRC but does not cover all aspects of the relationship between the service provider and LRC.
Issues relating to fees, terms and conditions, performance metrics will be covered in the bidder response document.
Scope of Work – Lot Three – Wire Transfers (money agents / post offices)
- Core Activities:
1.1To facilitate the transfer of cash grants to individuals nominated by LRC
1.2To ensure agreed volumes of funds are always available for the disposal of LRC at an agreed timeframe.
1.3To ensure a reporting management platform is available to LRC in the form of soft copy reports anda data management system for the purpose of financial reconciliation.
- Minimum Specification: The selected wire transfer system will need to meet the following requirements.
2.1Programme set up requirements
2.1.1The system must facilitate both one-off and regular payments to individuals
2.1.2The system must support the upload of excel format data that will identify the recipients chosen by LRC.
2.1.3The system must allow for LRC nominated participants to collect cash with any form of identification that is nominated by LRC.
2.1.4The system must support batch uploads for bulk transfers to multiple participants in multiple locations simultaneously
2.1.5The system must support the printing of transaction receipts in Arabic and they should be provided to participants at the point of disbursement
2.1.6The system must be able to operate in an offline environment in case data connections are unavailable
2.1.7LRC will require the company to set up new agents in the event that there is insufficient coverage in the areas of intervention
2.1.8LRC will require different levels of cash capital to be available for agents to disperse and require the company to provide adequate insurance for that sum.
2.2Communication requirements
2.2.1System must be able to report transaction errors and provide details of the error to both LRC and the participant
2.2.2System must be able to inform disbursing agents of the value of the transfer that is redeemable by participants.
2.3General transaction requirements
2.3.1Vendors must be provided with a means to authenticate the identity of a participant attempting a transaction.
2.3.2The system must deduct value from participant accounts following a transaction.
2.3.3Transactions will be identified by a unique transaction number.
2.3.4Failed transactions should also be assigned a transaction number.
2.3.5The system will track transactions by the following attributes: unique transaction number, vendor, participant, date, time, amount/quantity spent and voucher number.
2.4Reporting requirements
2.4.1System can provide both raw, unanalyzed data, and structured reports.
2.4.2All reporting should be downloadable in an excel data format that can be sorted and analyzed by LRC.
2.4.3Reporting can be provided through pre-defined scheduled reports and on-demand reports.
2.4.4Scheduled reports will have defined formats and will be sent to LRC according to a defined timetable. On demand reports will have defined formats and will be available on request.
2.4.5Proposals should indicate the specific types of reports that are available.
2.5Programme Management requirements
2.5.1The system shall allow pre-agreedlevels of authorization for LRC staff membersto complete different tasks, including different authorization levels, including authorizing transfers, canceling transfers, and recouping transfers that are not redeemed.
The above scope of work covers the provision of the services that are required by LRC but does not cover all aspects of the relationship between the service provider and LRC.
Issues relating to fees, terms and conditions, performance metrics will be covered in the bidder response document.
.