REQUEST - IAPSO - Money Transfer Solution R… · Web view5.15.2 Forex Management module. 5.15.3...

REQUEST FOR PROPOSAL (RFP)

Date: 19 October, 2006Dear Sir/Madam,

Subject: RFP for the supply, installation, implementation and maintenance of an online money transfer solution for Somali Money Transmitters

You are requested to submit a proposal for the supply of a solution, as per the enclosed Terms of Reference (TOR). To enable you to submit a proposal, attached are:

Instructions to Offerors ..................(Annex I)General Conditions of Contract..........(Annex II)Proposal Submission Form.................(Annex III)Price Schedule....................................(Annex IV)Performance Security Form................(Annex V)Terms of Reference (TOR).................(Annex VI)

Your offer comprising of technical and financial proposals, in separate sealed envelopes, should reach the following address no later than 12:30 PM on 10 November 2006.

David Allen, Deputy Resident Representative for Operations, United Nations Development Programme – Somalia, Springtree Properties, Lower Kabete Road,P.O. Box 28832, 00200, NairobiKenyaTel: +254-20-4255000 Facsimile: +254-20-4255101 e-mail: [email protected]

If you request additional information, we will endeavour to provide it expeditiously. However, any delay in providing such information will not be considered a reason for extending the submission date of your proposal.

You are requested to acknowledge receipt of this letter and indicate whether or not you intend to submit a proposal.

Yours sincerely,

KNS Nair

1

Programme ManagerPoverty Reduction and Sustainable Livelihoods ProgrammeUNDP Somalia

2

Annex I

INSTRUCTIONS TO OFFERORS

A. Introduction

1. General

Purpose of RFP: To supply, install, implement and maintain an online money transfer solution for Somali money transmitters.

2. Cost of proposal

The Offeror shall bear all costs associated with the preparation and submission of the Proposal. UNDP Somalia and the Somali Money Transmitters Association (SOMTA), the Purchaser, will in no case be responsible or liable for those costs, regardless of the conduct or outcome of the solicitation.

B. Solicitation Documents

3. Contents of solicitation documents

Proposals must offer services for the total requirement. Proposals offering only part of the requirement will be rejected. The Offeror is expected to examine all corresponding instructions, forms, terms and specifications contained in the Solicitation Documents. Failure to comply with these documents will be at the Offeror’s risk and may affect the evaluation of the Proposal.

4. Clarification of solicitation documents

A prospective Offeror requiring any clarification of the Solicitation Documents may notify the Purchaser in writing at the organisation’s mailing address or fax number indicated in the RFP. The Purchaser will respond in writing to any request for clarification of the Solicitation Documents that it receives earlier than one week prior to the deadline for the submission of Proposals. Written copies of the organisation’s response (including an explanation of the query but without identifying the source of inquiry) will be sent to all prospective Offerors that have received the Solicitation Documents.

5. Amendments of solicitation documents

At any time prior to the deadline for the submission of Proposals, the Purchaser may, for any reason, whether at its own initiative or in response to a clarification requested by a prospective Offeror, modify the Solicitation Documents by amendment.

1

All prospective Offerors that have received the Solicitation Documents will be notified in writing of all amendments to the Solicitation Documents.

In order to afford prospective Offerors reasonable time in which to take the amendments into account in preparing their offers, the Purchaser may, at its discretion, extend the deadline for the submission of Proposals.

C. Preparation of Proposals

6. Language of the proposal

The Proposals prepared by the Offeror and all correspondence and documents relating to the Proposal exchanged by the Offeror and the Purchaser shall be written in English. Any printed literature furnished by the Offeror may be written in another language so long as it is accompanied by an English translation of its pertinent passages in which case, for purposes of interpretation of the Proposal, the English translation shall govern.

7. Documents comprising the proposal

The Proposal shall comprise the following components:

Technical Proposal Contents:

(a) Proposal submission form;

(b) Technical Proposal, including documentation to demonstrate that the Offeror meets all requirements;

(c) Copies of certifications wherever the vendor claims that their products have been certified by leading regulatory agencies.

Financial Proposal Contents:

(a) Financial Proposal, including a Price Schedule completed in accordance with clauses 8 and 9.

8. Proposal form

The Offeror shall structure the Technical Proposal and Financial Proposal as described in Section 2 of the Terms of Reference (Annex VI).

The Technical Proposal should not contain any pricing information whatsoever. Pricing information shall only appear in the appropriate Price Schedules forming the Financial Proposal.

2

It is mandatory that the Offeror’s Proposal numbering system corresponds with the numbering system used in the body of the Terms of Reference (Annex VI). All references to descriptive material and brochures should be included in the appropriate response paragraph, though the material and documents themselves may be provided as annexes to the Proposal.

Information which the Offeror considers proprietary, if any, should be clearly marked “proprietary” next to the relevant part of the text and it will then be treated as such.

9. Proposal prices

The format of the Financial Proposal should be as outlined in Section 2 of the Terms of Reference (Annex VI). The Offeror shall indicate on an appropriate Price Schedule, an example of which is contained in these Solicitation Documents, the prices of the solution it proposes to supply under the contract.

10. Proposal currencies

All prices shall be quoted in US dollars or any convertible currency.

11. Period of validity of proposals

Proposals shall remain valid for sixty (60) days after the date of Proposal submission prescribed by the Purchaser, pursuant to the deadline clause. A Proposal valid for a shorter period may be rejected by the Purchaser on the grounds that it is non-responsive.

In exceptional circumstances, the Purchaser may solicit the Offeror’s consent to an extension of the period of validity. The request and the responses thereto shall be made in writing. An Offeror granting the request will not be required nor permitted to modify its Proposal.

12. Format and signing of proposals

The Offeror shall prepare three copies of the Proposal, clearly marking each “Original Proposal” and “Copy of Proposal” as appropriate. In the event of any discrepancy between them, the original shall govern.

The three copies of the Proposal shall be typed or written in indelible ink and shall be signed by the Offeror or a person or persons duly authorised to bind the Offeror to the contract. The latter authorisation shall be indicated by written power-of-attorney accompanying the Proposal.

A Proposal shall contain no interlineations, erasures, or overwriting except, as necessary to correct errors made by the Offeror, in which case such corrections shall be initialled by the person or persons signing the Proposal.

13. Payment

It is proposed that a "progress payment" schedule be negotiated with the successful vendor. Planning of payments will be based on the number of sites that will commit to the

3

implementation of the proposed system in the initial phases. It is anticipated that the payments will be made over a 3 to 6 month period. The number of Somali Money Transmitters (SMTs) that will participate in the initial implementation phases will be finalized during the contract negotiations. The Purchaser shall effect payments to the Contractor after acceptance of the invoices submitted by the vendor, upon achievement of the corresponding milestones.

D. Submission of Proposals

14. Sealing and marking of proposals

The Offeror shall seal the Proposal in one outer and two inner envelopes, as detailed below.

(a) The outer envelope shall be:

addressed to –

David Allen, Deputy Resident Representative for Operations, United Nations Development Programme – Somalia, Springtree Properties, Lower Kabete Road,P.O. Box 28832, 00200, NairobiKenyaTel: +254-20-4255000 Facsimile: +254-20-4255101

and,

marked with –

“RFP: Provision of money transfer solution to Somali Money Transmitters”

(b) Both inner envelopes shall indicate the name and address of the Offeror. The first inner envelope shall contain the information specified in Clause 8 (Proposal form) above i.e. the Technical Proposal, with the copies duly marked “Original” and “Copy”. The second inner envelope shall include the price schedule duly identified as such i.e. the Financial Proposal.

Note: if the inner envelopes are not sealed and marked as per the instructions in this clause, the Purchaser will not assume responsibility for the Proposal’s misplacement or premature opening.

15. Deadline for submission of proposals

Proposals must be received by the Purchaser at the address specified under clause Sealing and marking of Proposals no later than 12:30 PM on 10 November 2006. Please note that the time mentioned here is Kenyan time.

4

The Purchaser may, at its own discretion, extend this deadline for the submission of Proposals by amending the solicitation documents in accordance with clause Amendments of Solicitation Documents, in which case all rights and obligations of the Purchaser and Offerors previously subject to the deadline will thereafter be subject to the deadline as extended.

16. Late Proposals

Any Proposal received by the Purchaser after the deadline for submission of proposals, pursuant to clause Deadline for the submission of proposals, will be rejected.

17. Modification and withdrawal of Proposals

The Offeror may withdraw its Proposal after the Proposal’s submission, provided that written notice of the withdrawal is received by the Purchaser prior to the deadline prescribed for submission of Proposals.

The Offeror’s withdrawal notice shall be prepared, sealed, marked, and dispatched in accordance with the provisions of clause Deadline for Submission of Proposals. The withdrawal notice may also be sent by telex or fax but followed by a signed confirmation copy.

No Proposal may be modified subsequent to the deadline for submission of proposals.

No Proposal may be withdrawn in the interval between the deadline for submission of proposals and the expiration of the period of proposal validity specified by the Offeror on the Proposal Submission Form.

E. Opening and Evaluation of Proposals

18. Opening of proposals

The Purchaser will open the Proposals in the presence of a Committee formed by SOMTA and UNDP Somalia.

19. Clarification of proposals

To assist in the examination, evaluation and comparison of Proposals, the Purchaser may, at its discretion, ask the Offeror for clarification of its Proposal. The request for clarification and the response shall be in writing and no change in price or substance of the Proposal shall be sought, offered or permitted.

20. Preliminary examination

The Purchaser will examine the Proposals to determine whether they are complete, whether any computational errors have been made, whether the documents have been properly signed, and whether the Proposals are generally in order, and in the format prescribed.

5

Arithmetical errors will be rectified on the following basis: If there is a discrepancy between the unit price and the total price that is obtained by multiplying the unit price and quantity, the unit price shall prevail and the total price shall be corrected. If the Offeror does not accept the correction of errors, its Proposal will be rejected. If there is a discrepancy between words and figures the amount in words will prevail.

Prior to the detailed evaluation, the Purchaser will determine the substantial responsiveness of each Proposal to the Request for Proposals (RFP). For purposes of these Clauses, a substantially responsive Proposal is one which conforms to all the terms and conditions of the RFP without material deviations. The Purchaser’s determination of a Proposal’s responsiveness is based on the contents of the Proposal itself without recourse to extrinsic evidence.

A Proposal determined as not substantially responsive will be rejected by the Purchaser and may not subsequently be made responsive by the Offeror by correction of the non-conformity.

21. Evaluation and comparison of proposals

Proposals will be evaluated by members of a Steering Committee comprised of representatives from SOMTA and UNDP Somalia. Responses will be evaluated based on point awards derived from the vendor response weighted by the relative importance of the feature or question. The evaluation categories in the Technical Proposal are functionality, systems, and vendor viability. The overall evaluation of the responses will take into account the costs submitted in the Price Proposal, although cost carries a lower weight than the technical components.

The following evaluation process will be used:

A two-stage procedure is utilised in evaluating the proposals, with evaluation of the Technical Proposals will be evaluated before any price proposals are opened and compared. The Financial proposal of the Proposals will be opened only for submissions that pass the minimum technical score of 75% out of 700 points (i.e. 525) in the evaluation of the Technical proposals.

Technical Proposals will be evaluated on the basis of their responsiveness to the Terms of Reference (Annex VI).

In the second stage, the price proposal of all contractors that have received at least 75% score in the technical evaluation will be compared. Financial Proposals will be evaluated based on a merit point system. The Technical Proposal will be weighted at 70% and the Financial Proposal at 30%.

The contract will be awarded to the Contractor with the highest combined score in both the Technical and Financial Proposals, after the full evaluation process is completed. Contract awards are subject to satisfactory completion of network testing of the test site provided by the vendor and satisfactory outcome of User Acceptance Testing by SMTs.

6

Technical Evaluation Criteria

Summary of Technical Proposal Evaluation Components

Score Weight

Points Obtainable

Company / Other EntityA B C D E

1. Vendor Viability 20% 1402. System Functionality

&Usability60% 420

3. Systems Support & Implementation Management

20% 140

Total 700

Evaluation forms for each of the three components of the technical proposals are outlined below. The obtainable number of points specified for each evaluation criterion indicates the relative significance or weight of the item in the overall evaluation process.

Technical Proposal EvaluationComponent 1

Points obtainable


Vendor Viability

1.1 Reputation of Organisation and Staff (Competence / Reliability) and overall ability to provide solution

25

1.2 Litigation and Arbitration history 10

1.3 General Organisational Capability which is likely to affect implementation (i.e., loose consortium, holding company or one firm, size of the firm / organisation, strength of project management support)

25

1.4 Financial standing 10

1.5 Quality assurance procedures, warranty 20

1.6 Quality of Customer Portfolio and Site References:- Current and potential customer base- References provided globally- References provided in Middle East /

East Africa

50

Total – Component 1 140

7


Points Obtainable


System Functionality & Usability

2.1 To what degree does the product offered conform to overall requirements (state-of-the-art, flexible & adaptable)

50

2.2 Have the important/mandatory aspects of the specifications been addressed in sufficient detail?

150

2.3 Have the specific functional requirements been addressed?

75

2.4 Are the hardware requirements adequately addressed?

75

2.5 Are the alternative solution architectures addressed?

30

2.6 Does the solution meet the current and future needs of Somali Money Transmitters?

40



Points Obtainable


Systems Support and Implementation Management

3.1 Systems Support : Software license updates; fixes and security alerts; disaster recovery; legal and regulatory updates

70

3.2 Implementation management : data conversion, training, documentation

70


8

Financial Evaluation Criteria

Price Proposal Evaluation Form Score Weight

Points Obtainable


1. Money transfer solution costs 50% 150

2. Data Service Provider costs 30% 90

3. Qualitative (conditions) 20% 60

Total 300

F. Award of Contract

22. Award criteria, award of contract

The Purchaser reserves the right to accept or reject any Proposal, and to annul the solicitation process and reject all Proposals at any time prior to the award of a contract, without thereby incurring any liability or obligation to defend this decision to the affected Offeror or Offerors.

Prior to the expiration of the period of proposal validity, the procuring entity will award the contract to the qualified Offeror whose Proposal after being evaluated is the most responsive to the needs of SOMTA.

23. Purchaser’s right to vary requirements at time of award

The Purchaser reserves the right at the time of award of contract to vary the quantity of services and goods specified in the RFP, without any change in price or other terms and conditions.

24. Signing of the contract

Within 30 days of receipt of the contract the successful Offeror shall sign and date the contract and return it to the Purchaser.

25. Performance security

Within 30 days of the receipt of the Contract from the Purchaser, the successful Offeror shall provide the performance security on the Performance Security Form (Annex III) provided in the Solicitation Documents and in accordance with the Special Conditions of Contract.

9

Failure of the successful Offeror to comply with the requirement of Clause 24 above, or the present Clause 25, shall constitute sufficient grounds for the annulment of the award and forfeiture of the Proposal security if any, in which event the Purchaser may make the award to the next best evaluated Offeror or call for new Proposals.

10

Annex II

GENERAL CONDITIONS OF CONTRACT

1. LEGAL STATUS

The Contractor shall be considered as having the legal status of an independent contractor vis-à-vis SOMTA and/or its members (i.e. the Somali Money Transmitters). The Contractor's personnel and sub-contractors shall not be considered in any respect as being the employees or agents of SOMTA or the Somali Money Transmitters or UNDP.

2. SOURCE OF INSTRUCTIONS

The Contractor shall neither seek nor accept instructions from any authority external to SOMTA or UNDP in connection with the performance of its services under this Contract. The Contractor shall refrain from any action which may adversely affect the Purchaser and shall fulfil its commitments with the fullest regard to the interests of SOMTA and UNDP.

3. CONTRACTOR'S RESPONSIBILITY FOR EMPLOYEES

The Contractor shall be responsible for the professional and technical competence of its employees and will select, for work under this Contract, reliable individuals who will perform effectively in the implementation of this Contract, respect the local customs, and conform to a high standard of moral and ethical conduct.

4. ASSIGNMENT

The Contractor shall not assign, transfer, pledge or make other disposition of this Contract or any part thereof, or any of the Contractor's rights, claims or obligations under this Contract, except with the prior written consent of SOMTA.

5. SUB-CONTRACTING

In the event the Contractor requires the services of sub-contractors, the Contractor shall obtain the prior written approval and clearance of SOMTA for all sub-contractors. The approval of SOMTA of a sub-contractor shall not relieve the Contractor of any of its obligations under this Contract. The terms of any sub-contract shall be subject to and conform to the provisions of this Contract.

6. OFFICIALS NOT TO BENEFIT

11

The Contractor warrants that no official of SOMTA, UNDP or the United Nations has received or will be offered by the Contractor any direct or indirect benefit arising from this Contract or the award thereof. The Contractor agrees that breach of this provision is a breach of an essential term of this Contract.

7. INDEMNIFICATION

The Contractor shall indemnify, hold and save harmless, and defend, at its own expense, UNDP and SOMTA, its officials, agents, servants and employees from and against all suits, claims, demands, and liability of any nature or kind, including their costs and expenses, arising out of acts or omissions of the Contractor, or the Contractor's employees, officers, agents or sub-contractors, in the performance of this Contract. This provision shall extend, inter alia, to claims and liability in the nature of workmen's compensation, products liability and liability arising out of the use of patented inventions or devices, copyrighted material or other intellectual property by the Contractor, its employees, officers, agents, servants or sub-contractors. The obligations under this Article do not lapse upon termination of this Contract.

8. INSURANCE AND LIABILITIES TO THIRD PARTIES

8.1 The Contractor shall provide and thereafter maintain insurance against all risks in respect of its property and any equipment used for the execution of this Contract.

8.2 The Contractor shall provide and thereafter maintain all appropriate workmen's compensation insurance, or its equivalent, with respect to its employees to cover claims for personal injury or death in connection with this Contract.

8.3 The Contractor shall also provide and thereafter maintain liability insurance in an adequate amount to cover third party claims for death or bodily injury, or loss of or damage to property, arising from or in connection with the provision of services under this Contract or the operation of any vehicles, boats, airplanes or other equipment owned or leased by the Contractor or its agents, servants, employees or sub-contractors performing work or services in connection with this Contract.

8.4 Except for the workmen's compensation insurance, the insurance policies under this Article shall:

(i) Name UNDP as additional insured;

(ii) Include a waiver of subrogation of the Contractor's rights to the insurance carrier against UNDP;

(iii) Provide that UNDP shall receive thirty (30) days written notice from the insurers prior to any cancellation or change of coverage.

8.5 The Contractor shall, upon request, provide UNDP with satisfactory evidence of the insurance required under this Article.

12

9. ENCUMBRANCES/LIENS

The Contractor shall not cause or permit any lien, attachment or other encumbrance by any person to be placed on file or to remain on file in any public office or on file with UNDP against any monies due or to become due for any work done or materials furnished under this Contract, or by reason of any other claim or demand against the Contractor.

10. TITLE TO EQUIPMENT

Title to any equipment and supplies that may be furnished by UNDP shall rest with UNDP and any such equipment shall be returned to UNDP at the conclusion of this Contract or when no longer needed by the Contractor. Such equipment, when returned to UNDP, shall be in the same condition as when delivered to the Contractor, subject to normal wear and tear. The Contractor shall be liable to compensate UNDP for equipment determined to be damaged or degraded beyond normal wear and tear.

11. COPYRIGHT, PATENTS AND OTHER PROPRIETARY RIGHTS

SOMTA shall be entitled to all intellectual property and other proprietary rights including but not limited to patents, copyrights, and trademarks, with regard to products, or documents and other materials which bear a direct relation to or are produced or prepared or collected in consequence of or in the course of the execution of this Contract. At the SOMTA’s request, the Contractor shall take all necessary steps, execute all necessary documents and generally assist in securing such proprietary rights and transferring them to SOMTA in compliance with the requirements of the applicable law.

12. USE OF NAME, EMBLEM OR OFFICIAL SEAL OF UNDP OR THE UNITED NATIONS

The Contractor shall not advertise or otherwise make public the fact that it is a Contractor with UNDP, nor shall the Contractor, in any manner whatsoever use the name, emblem or official seal of UNDP or the United Nations, or any abbreviation of the name of UNDP or the United Nations in connection with its business or otherwise.

13. CONFIDENTIAL NATURE OF DOCUMENTS AND INFORMATION

13.1 All maps, drawings, photographs, mosaics, plans, reports, recommendations, estimates, documents and all other data compiled by or received by the Contractor under this Contract shall be the property of SOMTA, shall be treated as confidential and shall be delivered only to SOMTA authorized officials on completion of work under this Contract.

13.2 The Contractor may not communicate at any time to any other person, Government or authority external to SOMTA and UNDP, any information known to it by reason of its association with SOMTA and UNDP which has not been made public except with the authorization of SOMTA and UNDP; nor shall the Contractor at any time use such information to private advantage. These obligations do not lapse upon termination of this Contract.

13

14. FORCE MAJEURE; OTHER CHANGES IN CONDITIONS

14.1 Force majeure, as used in this Article, means acts of God, war (whether declared or not), invasion, revolution, insurrection, or other acts of a similar nature or force which are beyond the control of the Parties.

14.2 In the event of and as soon as possible after the occurrence of any cause constituting force majeure, the Contractor shall give notice and full particulars in writing to SOMTA, of such occurrence or change if the Contractor is thereby rendered unable, wholly or in part, to perform its obligations and meet its responsibilities under this Contract. The Contractor shall also notify SOMTA of any other changes in conditions or the occurrence of any event which interferes or threatens to interfere with its performance of this Contract. The notice shall include steps proposed by the Contractor to be taken including any reasonable alternative means for performance that is not prevented by force majeure. On receipt of the notice required under this Article, SOMTA shall take such action as, in its sole discretion, it considers to be appropriate or necessary in the circumstances, including the granting to the Contractor of a reasonable extension of time in which to perform its obligations under this Contract.

14.3 If the Contractor is rendered permanently unable, wholly, or in part, by reason of force majeure to perform its obligations and meet its responsibilities under this Contract, SOMTA shall have the right to suspend or terminate this Contract on the same terms and conditions as are provided for in Article 15, "Termination", except that the period of notice shall be seven (7) days instead of thirty (30) days.

15. TERMINATION

15.1 Either party may terminate this Contract for cause, in whole or in part, upon thirty days notice, in writing, to the other party. The initiation of arbitral proceedings in accordance with Article 16 "Settlement of Disputes" below shall not be deemed a termination of this Contract.

15.2 SOMTA reserves the right to terminate without cause this Contract at any time upon 15 days prior written notice to the Contractor, in which case SOMTA shall reimburse the Contractor for all reasonable costs incurred by the Contractor prior to receipt of the notice of termination.

15.3 In the event of any termination by SOMTA under this Article, no payment shall be due from SOMTA to the Contractor except for work and services satisfactorily performed in conformity with the express terms of this Contract. The Contractor shall take immediate steps to terminate the work and services in a prompt and orderly manner and to minimize losses and further expenditures.

15.4 Should the Contractor be adjudged bankrupt, or be liquidated or become insolvent, or should the Contractor make an assignment for the benefit of its creditors, or should a Receiver be appointed on account of the insolvency of the Contractor, SOMTA may, without prejudice to any other right or remedy it may have, terminate this Contract forthwith. The Contractor shall immediately inform SOMTA of the occurrence of any of the above events.

14

16. SETTLEMENT OF DISPUTES

16.1. Amicable Settlement

The Parties shall use their best efforts to settle amicably any dispute, controversy or claim arising out of, or relating to this Contract or the breach, termination or invalidity thereof. Where the parties wish to seek such an amicable settlement through conciliation, the conciliation shall take place in accordance with the UNCITRAL Conciliation Rules then obtaining, or according to such other procedure as may be agreed between the parties.

16.2. Arbitration

Unless, any such dispute, controversy or claim between the Parties arising out of or relating to this Contract or the breach, termination or invalidity thereof is settled amicably under the preceding paragraph of this Article within sixty (60) days after receipt by one Party of the other Party's request for such amicable settlement, such dispute, controversy or claim shall be referred by either Party to arbitration in accordance with the UNCITRAL Arbitration Rules then obtaining, including its provisions on applicable law. The arbitral tribunal shall have no authority to award punitive damages. The Parties shall be bound by any arbitration award rendered as a result of such arbitration as the final adjudication of any such controversy, claim or dispute.

17. OBSERVANCE OF THE LAW

The Contractor shall comply with all laws, ordinances, rules, and regulations bearing upon the performance of its obligations under the terms of this Contract.

18. AUTHORITY TO MODIFY

No modification or change in this Contract, no waiver of any of its provisions or any additional contractual relationship of any kind with the Contractor shall be valid and enforceable against SOMTA unless provided by an amendment to this Contract signed by the authorized official of SOMTA.

15

Annex III

PROPOSAL SUBMISSION FORM

To: Somali Money Transmitters AssociationDear Sir / Madam,

Having examined the Solicitation Documents, the receipt of which is hereby duly acknowledged, we, the undersigned, offer to provide the money transfer solution (specify product offered) for Somali Money Transmitters for the sum as may be ascertained in accordance with the Price Schedule attached herewith and made part of this Proposal.

We undertake, if our Proposal is accepted, to commence and complete delivery of all services specified in the contract within the time frame stipulated.

We agree to abide by this Proposal for a period of 60 days from the date fixed for opening of Proposals in the Invitation for Proposal, and it shall remain binding upon us and may be accepted at any time before the expiration of that period.

We understand that you are not bound to accept any Proposal you may receive.

Dated this day /month of year _____________

Signature

(In the capacity of)

Duly authorised to sign Proposal for and on behalf of

16

Annex IV

PRICE SCHEDULE

The Contractor is asked to prepare the Price Schedule as a separate envelope from the rest of the RFP response as indicated in Section D paragraph 14 (b) of the Instruction to Offerors.

All prices/rates quoted must be inclusive of all taxes.

The Price Schedule must provide a detailed cost breakdown. Provide separate figures for each functional grouping or category.

Estimates for cost-reimbursable items, if any, such as travel and out of pocket expenses, should be listed separately.

The format shown on the following pages should be used in preparing the Price Schedule. The format includes specific expenditures, which may or may not be required or applicable but are indicated to serve as examples.

In addition to the hard copy, if possible please also provide the information on diskette (IBM compatible).

17

Price Schedule: Option A

Request for Proposals for Provision of Money Transfer Solution for Somali Money Transmitters

Description of Activity/Item Price (US$)

Frequency Details/Comments

1. License fee- Mandatory modules- Optional modulesThe above fee should be for minimum 10 SMTs and indicate fee for every additional SMT that may join SOMTA in the future

2. Installation and implementation3. Data Centre Hosting Services (at Dubai )4. Training and documentation5. Annual maintenance and support (years 1

– 5) including upgrades and bug-fixes:Year 1Year 2Year 3Year 4Year 5

6. Third Party Systems7. Additional Costs (specify)

Note: Option 1 includes the costs of Data Centre Hosting Services (at Dubai), which will be arranged for by the Offeror, and should be included in the cost of the Proposal.

18

Price Schedule: Option B

Request for Proposals for Provision of Money Transfer Solution for Somali Money Transmitters

Description of Activity/Item Price (US$)

Frequency Details/Comments

1. License fee- Mandatory modules- Optional modulesThe above fee should be for minimum 10 SMTs and indicate fee for every additional SMT that may join SOMTA in the future

2. Installation and implementation3. Training and documentation4. Annual maintenance and support (years 1

– 5) including upgrades and bug-fixes:Year 1Year 2Year 3Year 4Year 5

5. Third Party Systems6. Additional Costs (specify)

Note: Option 2 excludes the costs of Data Centre Hosting Services, which will be arranged for and paid by SOMTA.

19

Annex V

PERFORMANCE SECURITY FORM

To: Somali Money Transmitters Association

WHEREAS [name and address of Contractor] (hereinafter called “the Contractor”) has undertaken, in pursuance of Contract No. ……………. dated ………. , to execute Services ……………..

(hereinafter called “the Contract”):

AND WHEREAS it has been stipulated by you in the said Contract that the Contractor shall furnish you with a Bank Guarantee by a recognised bank for the sum specified therein as security for compliance with his obligations in accordance with the Contract:

AND WHEREAS we have agreed to give the Contractor such a Bank Guarantee:

NOW THEREFORE we hereby affirm that we are the Guarantor and responsible to you, on behalf of the Contractor, up to a total of [amount of guarantee] [in words], such sum being payable in the types and proportions of currencies in which the Contract Price is payable, and we undertake to pay you, upon your first written demand and without cavil or argument, any sum or sums within the limits of [amount of guarantee as aforesaid] without your needing to prove or to show grounds or reasons for your demand for the sum specified therein.

The guarantee shall be valid until a date 30 days from the date of issue of a satisfactory certificate of inspection and testing by the procuring UN entity.

SIGNATURE AND SEAL OF THE GUARANTOR

Date ......................................................................................................................

Name of Bank .........................................................................................................

Address .................................................................................................................

21

Annex VI

TERMS OF REFERENCE (TOR)

22

UNDP Somalia / SOMTA IT Solution for Somali Money Transmitters Request for Proposal

Overview – Terms of Reference

This document is a detailed description of the terms of reference forming part of the Request for Proposal from UNDP Somalia for Contractors interested in providing a complete money transfer processing solution to the Somali Money Transmitters Association (SOMTA).

SOMTA is seeking a shared software and data centre solution that will meet its members’ current and future needs. SOMTA proposes to be the customer of the software and an outsourced data centre operator for the benefit of the participating Somali Money Transmitters (SMTs). Each individual SMT will require a proprietary set of parameters and strong proof that their customer data is secure. Each SMT will independently manage its data, customer base, and its headquarters and agent network terminals.

In the preparation of the RFP, UNDP Somalia working in conjunction with SOMTA has employed the services of an advisor.

Summary of Opportunity

To improve transparency and accountability, and ensure compliance with financial regulations, particularly in relation to anti-money laundering (AML) and combating terrorist financing (CFT), Somali Money Transmitters (SMTs) have identified the need to implement an electronic money transfer platform with in-built compliance processes. In addition to ensuring compliance, it is anticipated that the system will enable more efficient transaction processing with automated and standardized workflows in line with best practices.

To support this initiative, UNDP Somalia, in co-ordination with and through the Somali Money Transmitters Association, is in the process of assisting eligible SMTs adopt an industry ‘best in class’ and secure integrated, end-to-end ICT Solution that provides for efficient processing of money transfer transactions with capabilities of automated regulatory compliance in multiple Originating countries (Point-of-Service) and Destination countries.

UNDP Somalia now requests Proposals from eligible solution providers. The detailed guidelines, brief requirements, procurement process, scheduled dates and the required documents are described in this document. Considering the prevalent conditions in Somalia and the structure under which the SMTs are functioning right now, it is visualized that there are two possible options for the solution architecture as follows:

Option A – Licensed Model with the solution hosted at the Contractor’s data service provider’s site which should be in Dubai (and which is subject to SOMTA’s approval);

or

Option B – Licensed Model with the solution hosted at a third party data service provider’s site chosen, managed, and paid for by SOMTA.

The response to the RFP should be based on the above two options.

Annex VI: Terms of Reference Page 1 of 4747


1 INTRODUCTION

1.1 PurposeThis document presents specifications and related information for the delivery, installation, implementation, and maintenance of an integrated Electronic Money Transfer Management System for the Money Transfer Operators of Somalia. The software is to be installed over a 3-6 month period depending on the readiness of the application users, i.e., the Somali Money Transmitters (SMTs). The system must support financial regulations in the various countries that the SMTs, their agents and sub-agents operate. This Request for Proposals (RFP) has been developed through the cooperative efforts of the Somali Money Transmitters Association (SOMTA), whose members are the Somali Money Transmitters (SMTs), UNDP Somalia and employed advisors.

1.2 Background and project historySMTs, whose major clients are Somalis and other migrants from the Horn of Africa in the Diaspora, as well as businesses in Somalia, transfer approximately five hundred million to one billion dollars annually. They have come under close regulatory scrutiny since the September 11th terrorist attacks. As a result, SMTs have taken strides to comply with relevant regulations, including registering and legalizing their operations. However, SMTs continue to face challenges associated with maintaining bank accounts and high bond deposit requirements, as well as complying with increasingly complex regulations concerning anti-money laundering (AML) and countering terrorist financing (CFT). The challenges faced by these SMTs at present include:

Legal compliance in the host countries of their business presence Conforming to AML / CFT requirements Secure, efficient and speedy processing of transactions Adopting ‘best practice’ processes in their business activities Maintaining adequate audit trails Integrating automated settlement of accounts Adopting better risk management and risk mitigation principles

The SMTs and UNDP Somalia perceive that the solution to these challenges is to implement a more modern integrated money transfer technology solution. With this objective, on behalf of the eligible SMTs that operate through the SOMTA, UNDP Somalia now invites Proposals from eligible Contractors who are able to supply the solution with the above capabilities. The detailed guidelines relating to submission of proposals are set out below.

1.2.1 Overview of SOMTA

Somali Money Transmitters Association (SOMTA) is a United Kingdom registered apex body whose vision is “To secure the future of the Somali remittance industry through a safe and healthy sector comprising fully compliant money transmitters who are able to operate and compete globally, and to promote the image of the industry”. Its members, a number of SMTs, operate in Somalia and in many other



countries worldwide. Collectively, they are the leading operators facilitating transactions of more than 75% of the money transfers by Somalis around the world. They have offices (head office and agents / sub-agents locations) in many cities in the USA, Europe, Middle East and Africa apart from other countries of the world. A brief overview of data in relation to SOMTA and its members is as follows:

Currently SOMTA has 10 major SMTs as members with potential for expanding to 15.

Each SMT has head offices either inside or outside Somalia. Each SMT operates through an exclusive agent/sub-agent network. The smallest SMT operates in more than 10 countries, while the largest operates in

over 30 countries. The smallest SMT operates through a network of more than 50 agents/sub-agents,

while the largest has over 200 agents/sub-agents. The average number of transactions for the smallest SMT is approximately 10,000

per month. The largest SMT transfers approximately 200,000 remittances per month. Collectively, the members of SOMTA process more than 4 million transactions annually valued at approximately 500 million to 1 billion in US dollars.

Approximately 1-2 staff per each agent and 1 staff per sub agent are currently employed.

The client base per agent/sub-agent ranges from 100 to 5,000. The smaller SMTs serve more than 10,000 clients while the larger SMTs serve over 200,000 clients.

All SMTs currently use in-house Money Transfer Systems.

1.2.2 Role of UNDP Somalia

UNDP Somalia’s role is to support the strengthening of the SMTs, particularly in relation to accountability, transparency and compliance with Anti Money Laundering and Combating the Financing of Terrorism regulations, in order to ensure the continued flow of migrant remittances to Somalia through formal channels. Towards this, UNDP is willing to support the implementation of a modern efficient money transfer system that enforces SMTs to follow the industry best practices. In effect, UNDP Somalia will make some funds available to implement a shared IT solution for the SOMTA members. Given the funds available, it is also expected that the SMTs will contribute their own funds directly or through SOMTA. To ensure proper use of its funds, UNDP Somalia will be integral to the entire process of procuring and implementing the IT Solution.

1.3 ObjectivesTowards its vision, SOMTA aims to provide a common electronic platform for all its members which, in turn, will enable the members to provide state-of-the-art money transfer services to the Somalis around the world. The solution should be an industry ‘best in class’, cost effective, secure and efficient. Particularly important are automated regulatory compliance in multiple originating and destination countries. In particular, the system must provide:



A state-of-the-art integrated money transfer system that provides access to accounting, commission settlements, payments netting and customer relationship management functions.

Best-in-class compliance functions including AML/CFT and the regulatory requirements of over 30 countries where SMTs operate.

The ability for SOMTA to implement the system for its member SMTs. SMTs operation in various countries with a corporate structure of head office (HO), agents and sub-agents.

A system that enables each SMT head office and agent/sub-agent to view and maintain its own data with control of user profile and security configurations.

Speedy transmission of money from originating country to destination country.

Multi-channel remittance mediums such as Debit cards, Credit Cards, Cash and Cheques.

Excellent performance for all participating SMTs and their combined transaction load.

Real-time mirroring of essential data. The ability to effectively convert data from the existing money

transfer systems into the new format as required by the system. The ability to exploit emerging technologies and information

resources to raise the level of money transfer services, facilitate an increase in staff productivity, and improve effectiveness.

1.4 Ownership and use of solutionSOMTA is seeking a shared software and data centre solution that will meet its members’ current and future needs. It should be understood that SOMTA will be the acquirer of the software license for the benefit of the participating Somali Money Transmitters. SOMTA will neither implement nor use the solution for its own use. Rather, the SMT members of SOMTA will implement and use the solution. In essence, it is expected that each participating SMT will operate the solution through a ‘user license’. Each individual SMT will require a proprietary set of data, including system-level parameters, agents, sub-agents, customers and transaction. They will require strong proof that their data is secure an inaccessible to other SMTs. There are currently ten SMTs who are eligible to implement the solution, out of a potential total of fifteen. The winning Contractor must install and implement the solution for future new members of SOMTA within the terms and conditions agreed to at the time of finalizing the contract.

The effect of such an arrangement is that the Contractor is likely to have one customer, SOMTA, which has been given the right to multiple licenses. Contractors should consider this as an opportunity of supplying a software solution that could become a standard for the Somali money transfer industry, and access to multiple clients. Therefore, Contractors should consider some form of guaranteed discount from the Contractor's suggested retail prices in effect at the time the purchase is made.



1.5 Assumptions and other general issues UNDP Somalia will support SOMTA’s acquisition of the most

forward-looking, flexible, extensible, and cost efficient solution. The system architecture should be open, Internet based, and uses

a commercial relational or object-oriented database for much of its functionality.

SOMTA will not be an alpha site for a new system. A contract will be awarded on the basis of what is actually in general release at the time of purchase.

SOMTA, in conjunction with UNDP Somalia, will select a system that runs on standard hardware. The chosen system will support the money transfer management system needs of all its members. The system must provide for a range of desired functions that will serve the range of SMTs from the smallest to the largest sized company.

It is assumed that neither SOMTA nor the individual SMTs will build a data centre for housing and managing the shared applications and/or the requisite hardware. Accordingly, SOMTA will consider outsourcing the management of the applications, data, hardware, communication networks and third party services to a competent third party.

Should a Contractor's own product line not be able to meet all of the requirements and support a "total integrated solution", it is assumed the Contractor will propose a solution utilizing other "proven" packages. In this scenario, Contractors are expected to take on the complete project responsibility including interfaces, integration of outside package(s) etc. on a "turn key" basis and should form their proposal on this basis.

This RFP may be considered a software request, however, hardware configurations and associated estimates will assist in this process. Appropriate recommended hardware platforms, technical architecture of the same, including complete configuration specifications with special emphasis on CPU model, memory sizes, and disc capacities are requested.

1.6 Structure of this document

After this introductory section, these terms of reference are organized as follows:

Section 2 describes the formal procedures that bidders will be required to respect in order to comply with UNDP’s purchasing rules. Please note that failure to follow any of the instructions will result in immediate disqualification. This chapter also provides the procedures and timetable that will be adhered to for this particular RFP, and guidelines for proposal preparation that are specific to this RFP and that will allow proposals received to be assessed in the fairest possible way (“apples to apples” comparison).



Section 3 defines the information required in respect of corporate qualifications of the bidder.

Section 4 then defines the mandatory functional requirements of the SMTs and SOMTA.

Section 5 further elaborates on specific functional requirements.

Section 6 finally described the information required in respect of pricing and cost quotes.



2 PROCUREMENT PROCESS

2.1 Minimum Conditions for Qualifying Product Technical proposals will be evaluated on the basis of their responsiveness to these Terms of Reference. As part of the evaluation process the Contractor will be expected to meet the following minimum conditions:

The product offered should be completely developed, tested and ready for immediate implementation. SMTs will not be subjected to Unit Testing, Alpha testing or Beta testing. The product offered should be the general version of release by the Contractor as of 31 October 2006 and all the mandatory specifications mentioned in this RFP should be available in this version.

At least three satisfactory customer references must be obtained by the Purchaser from a list of customer sites provided by the Contractor. The product offered should be the same one used by the customers provided as reference accounts.

Satisfactory verification of a Test Site provided by the Contractor. The product offered should be same as that on the Test Site.

The product should be an Internet based solution.

The product should provide complete and comprehensive compliance with the AML/CFT regulations in all major jurisdictions. The compliance solution can be a third-party solution.

The Contractor should be willing to host the solution in Dubai under Option A.

The submissions must pass the minimum technical score of 75% out of 700 points (i.e., 525) in the preliminary evaluation of the Technical Proposals.

The Contractor should give a guarantee of a minimum of 99.9% uptime with complete security and network infrastructure under option A

2.2 Bidders' product demonstrationThe joint SOMTA/UNDP Somalia Steering Committee may convene a mandatory Bidders' Product Demonstration by those bidders short-listed based on the evaluation criteria. This session will provide Contractors with an opportunity to demonstrate their proposed solution to the Steering Committee, who in turn will also seek clarifications related to the system and the proposal. Any bidder which does not respond to a request to provide such a demonstration will be evaluated as technically non-responsive and summarily rejected.

2.3 Sub-contracting

Contractors can include third party products or services that complement their proposed solutions. These products must be fully



compatible with the proposed solution, tested and implemented in user sites, and be delivered and implemented under the responsibility of the bidding Contractor. Bidders must indicate which parts of the project, if any, will be performed by sub-contractors.

2.4 Acceptance testingAcceptance testing will be contingent on the ability of the mandatory system modules (as outlined in Section 4, Mandatory Specifications) to perform adequately using SMT data at mutually agreed upon installed site(s). SOMTA/UNDP Somalia reserve the right to establish acceptance tests to determine the functionality of the system within the context of SMT environments. The SMTs will work with the winning Contractor to identify an appropriate list of transactions for these final acceptance tests.

At the time of the acceptance test, the entire system must be compliant with the Software License Agreement (SLA).

2.5 Contract duration and extension optionThe initial term of the contract will be 5 years. SOMTA shall have the option to renew for additional 5 year terms at the approval of its members.

2.6 Escrow of essential softwareWithin thirty (30) days following the execution of the contract, the Contractor must either (a) provide source code of all software and all associated manuals to SOMTA, or (b) establish and place in escrow a complete copy of the current source code of all software and all associated manuals, proprietary or otherwise, which are essential to support the system provided by this agreement. SOMTA shall be a party to the escrow agreement and such escrow agreement shall be subject to the approval of all parties. The escrow agreement shall authorize the escrow agent to release the source code to SOMTA in the event a petition in bankruptcy is filed by or against the Contractor, or, if for any reason (except for material breach by SOMTA) the Contractor terminates the Agreement. The Contractor shall pay all costs of providing and maintaining the source code in escrow, including the fees of the escrow agent. SOMTA may at any time during the term of this contract review the deposited software and associated manuals. The Contractor shall replace the deposited software and related documentation with an updated version at least once every six (6) months or upon the Contractor's distribution of a new software release to its customers.

2.7 Taxes Taxes relating to the sale of the IT solution and services herein shall be the responsibility of the Contractor.



2.8 Format of responses to RFPAll responses must be submitted in two parts – the Technical Proposal and the Financial Proposal. Please note that the technical component of the Proposal should not contain any pricing information whatsoever on the services offered. Pricing information shall be separated and only contained in the appropriate Price Schedules as part of the Financial Proposal.

Failure to respect this requirement will result in automatic disqualification.

The format for each proposal is outlined below.

2.8.1 Technical Proposal

The interested parties should submit their Technical Proposal in the following format:

Section A: Introduction

This section indicates that Contractors have read and understood the information provided in these terms of reference. Additionally, Contractors should include a reference table for all the information provided in the Proposal in response to these terms of reference.

Section B: Statement of Capability

This section should include, but not necessarily be limited to:

o Background and Company profile (as per requirements under section 3.0)o Summary of proposed solution product features (functional and technical) – specify

the name and version of the product offeredo Ability to supply the requested hosting options (2 options) o List of References (as per requirements under section 3.0) o Test site URL with necessary user IDs and passwords for the product offered as a

solutiono List of countries for which the product meets the country’s financial regulatory

regulationso Copy of Company incorporation certificateo Financial information (as per requirements under section 3.0)o Copy of Software License Agreement and copy of Annual Maintenance Contract

Section C: Response to the Functional & Technical Requirements

This section should include, but not necessarily be limited to:

o Response to each one of the sub-items under sections 4.0 and 5.0 below, for each of the two proposed hosting solutions

o Present and future customisation termso Ability to perform the required customisationso Methodology and approach including pilot conversion and roll-outo Implementation time plan



o Application processing performance under the required environmento Implementation Support

Section D: Any other matters

2.8.2 Financial Proposal

The interested parties should submit their Financial Proposal in the form of a Price Schedule, an example of which is contained in Annex V. Such a Price Schedule should provide the following as a minimum:

Section A: Costing for Option A (software license plus complete hosting of solution at Contractor’s data service provider’s site) should include, but not be limited to, the following cost categories:

o One time software license costo Installationo Training and documentationo Maintenance, support and upgradeso Cost of Third party systems if applicableo Additional software related costs, including any customization costso Data service provider for the hosting of the solution

Section B: Costing for Option B (software license with solution hosted at a third party data service provider’s site) should include, but not be limited to, the following cost categories:

o One time software license costo Installationo Training and documentationo Maintenance, support and upgradeso Cost of Third party systems if suggestedo Additional software related costs, including any customization costso Under this option, Contractors should provide indicative costs for the

recommended hardware required by the external hosting provider.

2.8.3 Response Requirements

The response must follow the numbering system in these terms of reference. The bid must provide complete and comprehensive responses as requested with a particular focus on concise answers.

2.8.3.1 Technical Proposal

Please note that:



Contractors must indicate their compliance with, and responses to the information provided in Section 2 (Administrative Information).

In relation to Section 3 (Contractor Viability), Contractors are required to respond to each statement with complete information.

Section 4 (Mandatory Specifications) focuses on the minimum system capabilities requirements identified by the SMTs, whereby:

o In relation to Sections 4.1 - 4.3, Contractors are required to state a “Yes” or “No” answer next to each section number. A “Yes” answer indicates compliance with these requirements. If a Contractor answers “Yes” to any mandatory specifications and UNDP Somalia/SOMTA subsequently determines, that these mandatory specifications are not met the proposal will receive no further consideration.

o In relation to Section 4.4 – 4.5, Contractors are required to complete the hardware recommendations based on the proposed hosting alternatives.

Section 5 (Full Functional Specifications) focuses on the individual modules that together make up the integrated system. A point system based on the relative importance of each feature will be used to quantify the responses. Contractors must respond to each statement as indicated here:

o Sections 5.1 – 5.7: Contractors must indicate, next to each section number, the system's state of compliance using the indicators below and provide detailed explanations of the functions or capabilities represented in each specification as requested.

A = Available in current general release as of 31 October, 2006

N = Not available

o Section 5.8 – 5.15: Contractors must provide detailed explanations of the functions or capabilities represented in each specification.

2.8.3.2 Financial Proposal

Please note that:

In relation to Section 6 (Cost Summary) Contractors are required to provide separate cost quotes based on the two hosting alternatives.

Complete costing should be provided for each of the components described in Section 6.

The example Price Schedule format in Annex V should be used.

The Steering Committee may, at its discretion and at no cost to UNDP Somalia/SOMTA, invite any Contractor to appear for clarifications or provide written responses during response evaluation for the purpose of clarifying statements in the response.



The Contractor's Proposal should provide concise and complete descriptions of the Contractor's ability to satisfy the requirements of the RFP. It is expected that the Contractor will provide relevant or essential data needed to complete this requirement. Expensive displays, bindings, or promotional materials are not required unless they provide concise and complete descriptions of the Contractor's capability to satisfy the requirements of the RFP. Responses of "see attached" are not considered sufficient. If attachments are required they must pertain to specific questions. In these cases, indicate on the attachment the section and question number to which it refers and clearly mark on the attachment the relevant information that responds to the question.

The Steering Committee must be able to compare services and their cost across proposals from different bidders in a meaningful way (“apples to apples”). Facilitating this process will only work in the bidder’s favour. Any bidder that submits a proposal that is difficult or impossible to compare with other proposals is likely to be eliminated. Therefore bidders should try to respect the proposed model as much as possible.



3 CONTRACTOR VIABILITYIn a Statement of Capability, Contractors are required to respond to each statement below with complete information.

3.1 Contractor Information and Company ProfileContractors must provide:

3.1.1 Information about the Contractor's company specific to the Money Transfer Software Product offered in the Proposal:

Name

Home office address

Ownership details (including principal shareholders and the company structure)

Address of nearest sales/customer service office in Middle East and/or East Africa

Name, title, telephone, fax, and e-mail address of contact person

Quality system description (as appropriate to this bid) including any accreditations by third parties and a description of the Quality Assurance (QA) system.

Length of time in business.

Length of time providing the solutions which are requested in this RFP.

Details of any litigation, arbitration history and the present status of the same.

Name and version of the Product offered as solution in the proposal.

List of countries in which your Money Transfer Solution Product is CURRENTLY in USE.

Black Lists your Money Transfer Solution Product CURRENTLY SUPPORTS.

3.1.2 Short- and long-term mission of the organization.

Specify your product development goals, and your vision of the future of money transfer automation.

3.1.3 Information related to staffing:

Number of full-time and part-time staff

Allocation of staff among the following areas:

o Research and development

o Customer service/support

o Sales

o Administration



3.2 ReferencesUNDP Somalia/SOMTA will be relying on Contractor reference accounts from institutions comparable to SMTs to verify both system and Contractor performance. Proposals shall include references allowing the UNDP Somalia/SOMTA to obtain information regarding overall performance and satisfaction with the complete system, as well as for specific modules. Representatives from the Steering Committee may, at their discretion, choose to conduct telephone interviews or site visits with references.

Contractors must provide:

3.2.1 A complete list of clients that have implemented the proposed system, preferably, African/Middle East references, with full contact details of person(s) that the Steering Committee may contact.

3.2.2 Date the customer implemented the proposed system.

3.2.3 Number of client licenses for each customer.

3.2.4 Number of systems scheduled for installation and when.

3.2.5 Results of any customer survey taken during the past year.

3.2.6 Contact information for the system's user groups and addresses of online discussion groups.

Please provide the above information for the product you are proposing which is currently being used.

3.3 Partnering/Test SitesPlease provide your test site URL and necessary user IDs & passwords for us to view the Money Transfer Solution Product offered in your proposal.

Describe any:

3.3.1 Collaborative development efforts with customers.

3.3.2 Use of alpha and beta test sites (how are sites chosen, etc.)



3.4 Financial Information

3.4.1 Provide Company financial information which should include audited financial statements for the last three years.



4 MANDATORY SPECIFICATIONS

Solution Architecture

Considering the structure under which the SMTs are functioning right now, it is visualized that there are two possible options for the solution architecture as follows:

Option A: Licensed Model with the solution hosted at the Contractor’s data service provider’s site which should be in Dubai.

or

Option B: Licensed Model with the solution hosted at a third party data centre service provider’s site chosen, contracted and paid for by SOMTA.

The response to the RFP should be based on the above two different options, although Contractors may additionally include in their response any other options for the solution.

Please note that an ASP model is excluded from this RFP as it is not a suitable solution for consideration. However, systems developed for deployment in the ASP model may be proposed, as long as the system is implemented under one of the above options exclusively for SOMTA’s use.

Please specify the system requirements as mentioned under Sections 4 and 5 with clear classification as to the above two alternate hosting solutions wherever the architecture affects the requirements in terms of functions, hardware, software, cost, implementation, support and maintenance. A brief description of the models is specified below.

Option A:

In this model, the solution is hosted at the Contractor’s data centre service provider’s site which should be in Dubai. The service provider must be approved by SOMTA. The data centre service provider will be responsible for providing the hardware, operating system software, web server, firewall, security services, hosting the solution, and regular system administration maintenance. The Contractor will install the solution with the data centre service provider’s resources allocated for the solution setup and hosting. The solution ideally will have a common database for all the SMTs with privacy of data accessible only by the individual SMTs. The solution will have individual interfaces accessible only by users with appropriate rights and privileges.

Under this option:

The data service provider (or hosting bidder) is expected to provide all hardware, operating systems and non-money transfer software applications that are being proposed. Title to hardware and operating system shall remain with the hosting bidder. The bidder is expected to provide the necessary hardware maintenance, upgrades and fixes as part of the hosting arrangement.



In addition to hardware, ownership, operation and maintenance of the Relational Data Base Management software, performance and management tools, change control software, performance testing tools, helpdesk and other software packages that may be required are to remain with the hosting bidder.

Ownership of the money transfer software and related bundled 3rd Party tools will remain with the SOMTA.

The total hosting services will comprise:

o Technical infrastructure – hardware, operating systems, Internet connectivity

o Storage requirements

o System administration

o Access via the public Internet for SMTs and their agents

o Backup and recovery

o Disaster recovery

o Change control

o System security

o Infrastructure support

Option B:

Option B is similar to that of Option A except that:

The data centre service provider is selected by SOMTA. SOMTA will contract and pay for the support services and the server hardware and

underlying software required to support the Contractor’s system.

4.1 Mandatory - General System FunctionsThe features in this section are required. Contractors must state a Yes or No answer next to each section number. A Yes answer indicates compliance with these requirements.

The implemented system:

4.1.1 Shall consist of software, installation, database conversion programs, on-site/off-site training and documentation, hardware/software maintenance, software support, and ongoing software enhancements necessary for full operation, all of which must be quoted by the Contractor.

4.1.2 Must be fully integrated, with all modules capable of sharing common databases and independent databases as per Options A and B mentioned above and a consistent interface across functions.



4.1.3 Must fully support SOMTA structure that will allow separate sites for each SMT and enable each site to access and maintain its own money transfer data. The money transfer management system and data for each SMT, and each of its agents and sub-agents, must be able to have separate profile and security configurations that are controlled at the SMT level.

4.1.4 Must fully support an SMT structure that enables the data consolidation at 3 levels (SMT, Agent and Sub-agent).

4.1.5 Must be capable of supporting a 50 percent increase in database size, number of terminals/workstations, and/or activity levels without a hardware upgrade or a significant decrease in system response time based on the configurations relevant to Option A & Option B mentioned above.

4.1.6 Provides online Money Transfer Transactions by SMTs’ retail clients paid by credit card/debit card/bank account etc.

4.1.7 Provides a global unique transaction ID within SMT for each remittance.

4.1.8 Flexible charges and commissions.

4.1.9 AML/CFT compliance in accordance with US and UAE regulations, and configurable to support additional regulations based on source and destination countries.

4.1.10 Basic Accounting relating to Money Transfer transactions.

4.1.11 Reconciliation.

4.1.12 Ability to incorporate interfaces to external third party systems if desired by SOMTA.

4.1.13 Must allow separate databases for staff training and testing purposes, preferably one per SMT.

4.1.14 Must operate in a real-time interactive mode with the capability to create, update, maintain, and access all data for money transfer transactions in real-time.

4.1.15 Must provide dynamic indexing for all new and revised data regardless of method of entry into the system.

4.1.16 Must provide daily reporting and updating in the background so that the system can be operated continually.



4.1.17 Must provide continuous backup so all transactions can be recovered to the point of failure. Routine point of failure restoration from software or hardware failure should not exceed four (4) hours.

4.1.18 Must allow for transaction roll-back in case of failure.

4.1.19 Must be fully compliant with the following standards:

HTTP TCP/IP standards. 128 bit SSL data encryption

4.1.20 Must include a report generator to facilitate retrieval of management information. This report writer should allow non-programmers to develop reports themselves. Control options for must be included to protect system resources and response times. In addition to a proprietary report writer, the system must be as SQL compliant as possible. The system must be open for sophisticated data manipulation beyond the limited capabilities of proprietary report writers.

4.1.21 Must include a security/authorisation function that can be maintained easily by money transfer staff without programming expertise. Security will govern which staff will have access to which functions and data across all modules.

4.2 Mandatory ModulesContractors must indicate, next to each section number, the system's state of compliance using these indicators and provide detailed explanations of the functions or capabilities represented in each specification as requested.

A = Available in current general release as of October 31, 2006N = Not available

4.2.1 Mandatory General Modules

The system should have the following modules: Money Transfer Module (end-to-end money transfer transactions) Application Security and Access Module (User Administration) Application Setup (Application parameters setup) AML and CFT configuration at the SMT level, and by source and

destination country Accounting relating to money transfer transactions Client Relationship Management Remittance Tracking Module from transaction entry to payout



Reports Generation Module Online Money Transfer Transaction by Clients with credit

card/debit card/bank account etc.

4.2.2 Specific Modules

The above modules should be available for implementation at 3 different levels (SMT, Agents and Sub-agents). The detailed specification for the level at which individual modules to be implemented is listed below:

4.2.2.1 At SMT Level:

SMT setup

Application System Administration: Agent and Sub-agent setup Setup limits/ceilings for agents/sub-agents Product setup Charge setup Commission setup (options of percentage or flat fees) Currency Setup Setup up of remittance origination mediums, including Cash

(Mandatory), Debit card (mandatory), Credit Card (mandatory), Cheque (Mandatory), Bank Account (optional)

Setup up of remittance payout mediums, including Cash (Mandatory), Cheque (Mandatory), Bank Account (optional)

Accounting related to the remittance transactions and functions Automated Compliance from AML/CFT perspective, including

transaction limits and Know Your Client requirements (i.e., numbers and types of identification)

Remittance Tracking (mandatory at Agent/Sub-agent levels but optional for retail clients’ online access)

Management Information System (MIS) External Interfaces Clearing House Functions related to settlement of commission and

account dues between the agents, sub-agents and SMT (money transfer from agent to HO, from HO to agent and between agents)

Approval of Money Transfer Transactions, agent account settlements, and expenses at the SMT level

Archiving and Purging of transactions with parameters, i.e., dates

4.2.2.2 Agent and Sub-agent Level

Front Office: Remittance origination

o Channel Delivery



o Identification and authentication, and registration of remitter (Know Your Client)

o Validation/approval by a supervisor, if requiredo Routing (Country and City)o Billing and Chargingo Balance check and debit account for remittances funded by an online

paymento Send Remittance Advice to receiving agent (mandatory) and beneficiary

(optional)o Print Remittance Advice

Remittance payouto Receive Payment Adviceo Identification and authentication, and registration of beneficiary o Billing and Chargingo Credit account for remittances paid by an online paymento Send Payment Advice to originatoro Print Payment Advice

ID Capture, including attaching scanned ID documents and photographs for remitters and beneficiaries.

Back-Office:

For Remittance Process:1. Functions:

Automated Compliance (AML/CFT/Fraud detection) Rectification and Reversal of erroneous transactions prior to their payout Accounting relating to the remittance transactions and functions (commissions

and fees, currency exchange) Remittance Tracking Investigation Reconciliation Clearing House Functions related to settlement of commission and account dues

between the agents, sub-agents and SMT Grievance Reporting/Complaints Logging and Tracking Simple Treasury functions such as open/close Teller, teller reports (transaction

summary, cash), cash denomination

2. Reporting

Regulatory Reporting (AML/CFT), including SAR, CTR, and other regulatory reports for the supported jurisdictions

Transaction Reports at the SMT, agent and sub-agent levels by date or other parameters

A report writing facility Export facility to Excel/Word and other common Office documents



3. System Administration User Authorization Exception handling Backup/Restore Security (Encryption) Security (Data Access)

4.3 Mandatory - Requirements for Computer Hardware and Platforms at SMT/Agent/Sub-agent Offices

The features in this section are required. Contractors must state a Yes or No answer next to each section number. A Yes answer indicates compliance with these requirements.

The implemented system by SMTs:

4.3.1 Runs on all current versions of Windows, Mactinosh and Linux operating systems.

4.3.2 Operates on current versions of the most popular web browsers, including Internet Explorer and Firefox.

4.4 Mandatory – Hardware Specifications at SMT/Agent/Sub-agent Offices

In this section the Contractors are required to specify minimum hardware specifications for the application to run at the offices of SMTs (HO), agents and sub-agents. Under this section the Contractors should describe the specifications.

Please provide hardware specifications for:

4.4.1 Client distribution server, if proposed.

4.4.2 Sample workstation configuration for agent’s staff functions.

4.4.3 Sample workstation configuration for retail client online functions.

4.4.4 Additional server capacity required for mirroring of files, if proposed.

4.4.5 Proposed network/infrastructure requirements.

4.4.6 Internet speed and bandwidth required for transaction responses within 5 seconds, given the expected transaction volumes documented above.



4.5 Mandatory – Hardware and Software Specifications at the Server Side

Contractors are required to complete the hardware and software recommendations at the server side as outlined in this section.

Considering the structure under which the SMTs are functioning right now, it is visualized that there are two possible options for the solution architecture as follows:

Option A: Licensed Model with the solution hosted at the Contractor’s data service provider’s site which should be in Dubai; or

Option B: Licensed Model with the solution hosted at a third party data centre service provider’s site chosen by SOMTA

It is required that the bidder provide a detailed hardware and software recommendation for the server side based on the two possible solution architectures as described above. Keeping in mind the requirement that the system must be capable of supporting a 50 percent increase in database size, number of terminals/workstations, and/or activity levels without a server upgrade or decrease in response time, appropriate server and storage hardware should be recommended. Note that the hardware is expected to have a useful life of 5 years in the case of servers.

The hardware recommendation should include:

4.5.1 Standard commercially available servers (vendor, model, and configuration); include hardware for the individual SMT databases to have privacy and security considering the options as stated above, if proposed.

4.5.2 Disk storage for servers, including backups.

4.5.3 Peripheral devices for servers including uninterruptible power supply, etc.

4.5.4 Client distribution server, if proposed.

4.5.5 Sample workstation configuration for staff functions.

4.5.6 Sample workstation configuration for online client transaction functions.



4.5.7 Additional server capacity required for mirroring of files, if proposed.

4.5.8 Proposed network/infrastructure requirements.

4.5.9 Proposed Operating System including the name of the product and version.

4.5.10 Proposed web server including the name of the product and version.

4.5.11 Proposed Firewall/Anti-virus/security related software and hardware including the name of the product and version.

4.5.12 Proposed database system including the name of the product (such as standard or enterprise) and version.

4.5.13 Proposed administration software if required including the name of the product and version.



5 FULL FUNCTIONAL SPECIFICATIONSSection 5 (Full Functional Specifications) focuses on the functional requirements of the system. A point system based on the relative importance of each feature will be used to quantify the responses.

The money transfer management system is expected to provide consolidation capabilities at 2 levels (Agent and Sub agent levels) available from any workstation accessing the proposed system, regardless of its location, if its user has the appropriate privileges.

Contractors are required to follow the numbering system in the RFP and must respond to each statement as indicated here: Sections 5.1 - 5.7: Contractors must indicate, next to each

section number, the system's state of compliance using these indicators and provide detailed explanations of the functions or capabilities represented in each specification as requested.

A = Available in current general release as of 31 October, 2006N = Not available

Section 5.8-5.15: Contractors must provide detailed explanations of the functions or capabilities represented in each specification.

All of the following actions are assumed only to be accessible by a user with the appropriate rights, based on what actions they are allowed to perform, and which transactions, clients, sub-agents, or agents they can perform them on.

5.1 At the System Level

5.1.1 General

The system:

5.1.1.1 Is fully integrated with all modules, including AML compliance and reporting, even if these are provided by a third party.

5.1.1.2 Has the ability to setup date, time on the server which can not be altered by any other person.

5.1.1.3 Has the audit functionality to record all records by stamping the date, time and the user id for adding/modifying/deleting functions. Deletions should be “soft deletions,” which set the record to “inactive” or “deleted,” without physically deleting the record. In addition, a copy of important records should be written to an audit trail when they are added, modified and deleted so that a history of their data over time is available.



5.1.1.4 Has the functionality to initiate session for each user and enforce an automatic timeout function after a set period of inactivity has passed.

5.1.1.5 Has the functionality to setup archive parameters to archive data and purge the data based on parameters such as date.

5.1.1.6 Has no limits on the numbers of agents, sub-agents, transactions, accounting entries, or any other data type in the system.

5.2 At SMT (Head Office) Level

5.2.1 General

The system:

5.2.1.1 Has the functionality to setup various countries.

5.2.1.2 Has the functionality to setup various cities under countries.

5.2.1.3 Has ability to setup country specific time zones for various SMTs (optional).

5.2.1.4 Set discretionary client data fields as optional or mandatory (e.g., the number and type of ID required, or security questions such as mother’s maiden name).

5.2.2 Setup SMTs

5.2.2.1 Setup SMTs with the following minimum information:

SMT Code SMT Name Contact details (person/address/phone no, fax no, email) Operation effective dates (from, to)

5.2.2.2 If the system is implemented in such a manner that a common database is shared by multiple SMTs, there is no limit on the number of SMTs.

5.2.3 Setup Agents

5.2.3.1 Setup Agents with the following minimum information:



Agent code under the SMT code Agent Name Contact details (person/address/phone no, fax no, email) Operation effective dates (from, to) Credit Limit (e.g., the value of remittances the agent can accept

before reimbursing the SMT)

5.2.4 Setup Sub-agents

5.2.4.1 Setup Sub-agents with the following minimum information:

Sub-agent code under the SMT code and under Agent code Sub-agent Name Contact details (person/address/phone no, fax no, email) Operation effective dates (from, to) Credit Limit (e.g., the value of remittances the sub-agent can

accept before reimbursing the SMT)

5.2.5 Setup Commissions

5.2.5.1 Setup commissions with the following minimum information:

Commission Code Commission Name Charge frequency (per

transaction/monthly/quarterly/half-yearly/annually) Type of fee (flat or percentage of remittance value), and tiered fee

code (indicating whether tiers are used, and how to interpret them)

Amount of fee or percentage (by tier, if tiers are applicable) Minimum/Maximum Commission/Fee that can be charged at the

user’s discretion if a user overrides the system calculated fee Commission applicable to SMT, agent, and sub-agent Commission effective dates (from, to)

5.2.6 Setup Remittance Payment Mediums

5.2.6.1 Setup payment mediums for the funding and payout of remittances, such as cash, credit card, debit card, bank account, cheque, etc., with the following minimum information:

Remittance medium Code Remittance medium Name Available for funding remittances? Available for payout of remittances? Type of fee (flat/percent)



Charge (percentage) for the specific medium, if any effective dates (from, to)

5.2.7 Setup Products

5.2.7.1 Setup different remittance products that clients can choose with the following minimum information:

Product Code Product Name Product Terms (simple transfer, verify ID, tax etc.) Available funding payment mediums Available payout payment mediums Product Charge type Product effective dates (from, to)

5.2.8 Setup Charge Type for Products

5.2.8.1 Setup different charge types for the products (the charge that clients will pay for using a particular product) with the following minimum information:

Charge Code Charge Name Product Code for which applied (generic or user has the option to

choose at the transaction level) Charge frequency (per

transaction/monthly/quarterly/half-yearly/annually) Type of fee (flat or percentage of remittance value), and tiered fee

code (indicating whether tiers are used, and how to interpret them)

Amount of fee or percentage (by tier, if tiers are applicable) Minimum/Maximum Commission/Fee that can be charged at the

user’s discretion if a user overrides the system calculated fee Charge effective dates (from, to)

5.2.9 Accounting

5.2.9.1 Allow SMT users to enter accounting transactions, providing the following minimum functionality:

Enter banking transactions relating to Remittances – origination and payouts

Enter cash transactions relating to Remittances – origination and payouts

Enter adjustments



5.2.10 Automated Compliance

It is no longer a matter of local operations or process-driven methodologies that meet regulatory requirements in the drive against money laundering. The challenge in anti-money laundering now is to devise and enforce a risk-based strategy with appropriate technology that includes effective standards to protect a financial institution being used as a vehicle by money launderers or being used as a conduit by terrorists.

To meet these challenges, we expect the solution to address the following:

help in implementing appropriate controls and compliance procedures

undertake customisation of AML solutions to meet specific needs of Money Transfer institutions, if not available already in the solution

implement third-party AML solutions and integrate them seamlessly into the system

provide an enterprise-wide, end-to-end solution to meet compliance requirements, from performing due diligence on customers (know your client), generating CTRs and SARs, detecting suspicious activity, using an ontology rule engine, case management, etc.

The standard AML framework should provide standard processes, trigger and risk rules, which can be set at the system, SMT, agent or sub-agent levels. Lower levels should be edited to be equally stringent or more stringent than higher levels to prevent overrides. As well, relevant parameters such as transaction limits should also be assigned based on the jurisdiction of the remittance origination and/or payment. Compliance features include, at a minimum:

5.2.10.1 Setup common definitions for high-risk customers

5.2.10.2 Allow dynamic generation of historical customer transaction profiles.

5.2.10.3 Setup global AML rules, e.g., amounts above which more stringent ID requirements must be met or reporting and authorization rules take effect, and maximum amounts per transaction and time period. Different rules for different jurisdictions should be configurable as well, based on the sending agent’s jurisdiction.

5.2.10.4 Use sophisticated algorithms to detect patterns in addition to transaction/product limits.

5.2.10.5 Setup common triggers/criteria.



5.2.10.6 Leverage investigations expertise already in place through alerts and reports.

5.2.10.7 Interfaces with global reporting systems, e.g., automatic filing of CTRs, and on-demand filing of SARs.

5.2.10.8 Generate analysis and follow-up reports.

5.2.10.9 Generate reports for local regulatory and corporate reporting, e.g., UAE’s monthly, quarterly, and annual reports.

5.2.10.10 Automated processes to block or close accounts where necessary.

5.2.10.11 Alerts about a black-listed client should appear as soon as the customer details are entered by the teller, and the appropriate actions should be initiated based on the compliance settings.

5.2.10.12 The system should immediately send information of such members to the network as per the agreed upon data sharing rules between the SMT, agents and sub-agents.

5.2.11 Remittance Tracking

The system should have a Tracking system to enable the user to track a particular remittance transaction from the point of remittance to the point of payment with the following minimum functionality:

5.2.11.1 Track the remittance with the transaction number.

5.2.11.2 Show the status of the transaction.

5.2.11.3 Enter and show the reasons for any delays.

5.2.11.4 Display the status history from the point of remittance origination to the point of payment.

5.2.11.5 No limitations on the number of transactions for tracking.

5.2.11.6 Transactions can be purged after a specified period of time (e.g., 5 years).

5.2.12 MIS / Reporting

The system should have a full fledged MIS system with the following reports, at a minimum. No limits exist on the number of reports that can be generated:



5.2.12.1 Transaction Listing (Remittance and Payments)

5.2.12.2 Transaction Listing (Remittance and Payments) with commissions

5.2.12.3 Transaction Summary for a period of time by transaction type, by consolidating for SMT and sub-grouped for agents and sub-agents.

5.2.12.4 Transaction Detail for a period of time by transaction type, by consolidating for SMT and sub-grouped for agents and sub-agents.

5.2.12.5 Fee/Commission/Charge Summary for a period of time due from SMT, Agent, and sub-agent.

5.2.12.6 Fee/Commission/Charge Summary for a period of time due from SMT, Agent, and sub-agent, consolidating for SMT and sub-grouped for agents and sub-agents.

5.2.12.7 Teller Summary.

5.2.12.8 Cash flows.

5.2.12.9 Financial Statements such as Trial Balance, General Ledger, Income statement and Balance Sheet relating to the money transfer transactions.

5.2.12.10 Compliance and regulatory reports as required by local laws.

5.2.12.11 Report writer facility for the SMT staff to configure and generate some custom reports.

5.2.12.12 Automatic generation of Exception Reports on AML/CFT/Fraud detection/SAR/CTR.

5.2.13 External Interfaces

The system should have ability to interface to the following external systems, at a minimum:

5.2.13.1 External ACH and other financial settlement systems.

5.2.13.2 External Global AML systems, including OFAC and Black Lists.

5.2.13.3 External accounting systems.



5.3 At Agent/Sub-agent Level

5.3.1 Setup Sub-Agents

5.3.1.1 Agents with appropriate access rights can setup sub-agents with the following minimum information:

Sub-agent code under the SMT and agent code Sub-agent Name Contact details (person/address/phone no, fax no, email) Operation effective dates (from, to)

5.3.2 Customer Relationship Management (CRM) – Setup Clients

5.3.2.1 Agents and sub-agents can setup clients with the following minimum information:

Client code and password Client Name (first, middle, surname) Client’s mother’s maiden name Client’s ID type and ID relevant to each country of operation, and

other specific regulatory compliance related information Contact details (permanent and present address/nationality/phone

no, email) Source of funds Operation effective dates (from, to)

5.3.3 Remittance Origination Transactions

Agents/sub-agents can enter remittance transactions with the following minimum functionality:

5.3.3.1 Channel Delivery

To choose the product Choose the remittance medium (cash/credit card/debit card/bank

account/cheque)

5.3.3.2 Identification and Authentication

Enter the ID required by the local country regulations Enter the ID of the Remitter as well as the ID of the Receiver The system will automatically initiate the compliance procedures

by checking the ID, black lists, pattern detection, limits and ceilings relevant to the point-of-service (POS) country, destination country, SMT, agents and sub-agents.



The system should automatically enforce the necessary processes such as SAR, CFT etc.

The system should allow the teller to either proceed with the transaction even in the case of suspicion or to stop the transaction based on the relevant business rules setup relevant to the country of operation. An audit trail of suspicious transactions and the override reason must be kept.

5.3.3.3 Validation

Trigger mandatory or on-request validation of the transaction by superiors if required because of a compliance warning or high amount

5.3.3.4 Scan Documents

Allow the user to capture the ID and any other relevant documents for digital storage, and/or retrieval in case of an existing customer

5.3.3.5 Routing

Allow the user to choose the Destination Country, Destination City, wherever applicable

5.3.3.6 Delivery Medium

Allow the user to choose the mode of payment (cash/cheque/bank account/client pick up)

Allow the teller to record what proof of identity is required before paying the receiver

5.3.3.7 Billing and charging

Allow the teller to bill the client for the remittance amount and the charges related to the product/country.

5.3.3.8 Check balance and debit account

Allow the teller to check the balance in the customer’s account if the remittance funds are paid from an online account

Debit the customers account for the total amount of transaction



5.3.3.9 Send Remittance Advice

Allow the teller to complete the transaction, which should initiate the transaction to be saved on the server

Generate a Remittance Advice to the agents/sub-agents in the designated country

In the case of a designated agent the remittance advice should be available only to the designated agent

5.3.3.10 Print Remittance Transaction

Allow the teller to print all the relevant data of the completed transaction, including time and date of transaction, location, gross amount sent, commissions charged, net amount for beneficiary etc.

5.3.4 Remittance Payout Transactions

5.3.4.1 Receive Payment Request

To enter the transaction id To enter the client id (receiver and sender) Choose the payment medium (cash/credit card/debit card/bank

account/cheque)

5.3.4.2 Identification and Authentication

Allow the user to enter the ID required as per the local country regulations

The system will automatically initiate the compliance procedures by checking the ID, black lists, pattern detection, limits and ceilings relevant to the point-of-service (POS) country, destination country, SMT, agents and sub-agents.

The system should automatically enforce the necessary processes such as SAR, CFT etc.

The system should allow the teller to either proceed with the transaction even in the case of suspicion or to stop the transaction based on the relevant business rules setup relevant to the country of operation. An audit trail of suspicious transactions and the override reason must be kept.

5.3.4.3 Validation



Allow the user to validate the transaction by superiors if required to validate the transaction

5.3.4.4 Scan Documents for Proof of Payment

Capture the ID, a signature confirming payment, and any other relevant documents of the recipient for digital storage, and/or retrieval in case of an existing customer

5.3.4.5 Delivery Medium

Allow the user to choose the mode of payment (cash/cheque/bank account/ stored value card/client pick up)

5.3.4.6 Billing and charging

Allow the teller to bill the client for the remittance amount and the charges related to the product, country as setup if charges applicable on payment transactions

5.3.4.7 Credit account

Credit the customer’s account for the total amount of transaction, if an online payment medium is chosen

5.3.4.8 Send Payment Advice

Allow the teller to complete the transaction, which should initiate the transaction to be saved on the server

Make a Payment Advice and Proof of Payment available to the agents/sub-agents in the origination country

5.3.4.9 Print Payment Transaction

Allow the teller to print all the relevant data of the completed transaction, including time and date of transaction, location, gross amount sent, commissions charged, net amount for beneficiary, etc.

5.3.5 Customer Relationship Management (CRM) – Remittance Tracking



5.3.5.1 Allow clients (sender and receiver) to track their remittances through an online retail Remittance Tracking System with following minimum functionality:

with the option of making some processes mandatory: enter the Transaction/Track ID and password/client ID the system should display the status and all the stages it went

through The system should display the reason in case of any

delays/suspension

5.3.5.2 Allow agents/sub-agents to enter transaction status, activities (such as a phoning the recipient), and reasons for delays (e.g., the customer did not answer)

5.3.6 User Setup

5.3.6.1 Allow system administrators of SMTs, agents and sub-agents to setup users relative to their system access levels with the following minimum functionality:

Make some processes mandatory such as change password after first log-in and/or after a particular period of time

Choose the user groups and levels (system administration, management, accounting, teller, super user)

Setup the functions that can be performed by the user Operation effective dates (from, to)

5.3.7 Backup & Restore

5.3.7.1 Very frequent automatic backups (please state the frequency).

5.3.7.2 Frequent delivery of backups to offsite storage (please state the frequency).

5.3.8 Back office Adjustments

5.3.8.1 The accounting staff of agents/sub-agents can make adjustments and rectifications with the following minimum functionality:

with the option of making some processes mandatory :



make changes in the transactions, if mistakes were made by teller

make entries necessary for reversals and rectifications cancel/stop/void transactions before they have been paid Operation effective dates (from, to)

5.3.9 Accounting

5.3.9.1 Agents/sub-agents can enter accounting transactions with the following minimum functionality:

Enter banking transactions relating to Remittances – origination and payouts

Enter cash transactions relating to Remittances – origination and payouts

Enter adjustments

5.3.10 Reconciliations

5.3.10.1 Agents/sub-agents can make reconciliations with the following minimum functionality:

Enter transactions for reconciliations

5.3.11 Automated Commission

The system should have automated commissions between the SMTs, Agents and Sub-agents, but not limited to:

5.3.11.1 Allow the SMTs, Agents, and sub-agents to make entries for adjustments

5.4 Information Technology RequirementsThe system should have the following features, at a minimum:

5.4.1 Transaction number, Track ID should be unique and the field width should be sufficient to support the number of number of agents and number of sub-agents and number of countries of operations.



5.4.2 The system should have sufficient capabilities to handle exceptions.

5.4.3 The database should have proper design to cater to the structure and business requirements.

5.4.4 In the case of Option A, the server should have enough storage capacity to handle the volume and complex nature of the SMT operations.

5.4.5 In the case of Option A, the data transmitted and accessed should have standard encryption with 128 bit SSL standards.

5.4.6 The system should have proper security features with audit trails.

5.4.7 The system should have facility for the users to setup business rules applicable to each country.

5.4.8 The system should allow the system administrators at each level to export the data that they have access to into Excel/Word and other common software.

5.4.9 The Contractor should provide the complete database structure and Entity Relationship diagram.

5.4.10 The system should allow interfaces from other systems to enable data mining.

5.4.11 The system should be simple to operate, flexible and speedy in terms of transaction execution to provide efficient services to clients.

5.4.12 The system should have solutions for online and off-line transactions to provide real-time as well as solution for offices which do not have Internet connection or in cases of Internet being down.

5.4.13 The system should have a mechanism to address the transaction failures such that incomplete transactions are not entered onto the system.

5.4.14 The system should have System Administration module for setting up user rights and privileges and change password enforcement.

5.4.15 The system should begin sessions upon a user’s login, and automatically log them out after a set period of inactivity.

5.4.16 The system should have facilities to import black lists from third party vendors and also support internal black lists.

5.4.17 The system should allow the user to archive data for a specific period and purge data after specific period.



5.4.18 The system should have transactions at minimum 3 levels (SMT, Agent and Sub-agent).

5.4.19 The system provides free text note fields of unlimited length, including, but not limited to:

notes to Receiver at the remittance level notes by System Administrator notes for Compliance at the customer and remittance levels general notes

5.4.20 The system should have an online help facility.

5.4.21 The system should have installation and application manuals for all the modules.

5.4.22 The system should have advanced search facilities for searching for a client name, ID, agent, sub-agent, and country.

5.4.23 The system should have ability to share data as desired by the agents/sub-agents based on specific rules (e.g., custom blacklists).

5.4.24 The system allows quick and easy transaction with a minimum of keystrokes or carriage returns.

5.4.25 The system closes the transaction for payment after it is paid at the destination country to avoid double payments on each transaction.

5.4.26 The system should have complete Teller Management functions with Teller sessions, Teller security, teller limits, teller authorizations etc.

5.4.27 The Contractor should give a guarantee of minimum 99.9% uptime of connectivity with complete security and network infrastructure under option A.

5.5 Printing and Data EntryThe system:

5.5.1 Supplies full and current system documentation in print form.

5.5.2 Supplies full and current system documentation in online form.

5.5.3 Provides formatted templates and default values for online data entry.



5.5.4 Supports full screen editing.

5.5.5 Supports word processing capabilities.

5.5.6 Supports "cut and paste" from one record to another (from both local databases and outside sources).

5.5.7 Supports (accepts, edits, stores, retrieves, and displays)

5.6 Help and "Artificial Intelligence" EnhancementsThe system:

5.6.1 should be designed to anticipate and prevent "errors" from occurring.

5.6.2 provides pull-down lists of options for searching and limiting.

5.6.3 ignores errors in spacing, punctuation, and diacritics.

5.6.4 displays a browse screen with the user's search argument in its proper alphabetical location in the index when a search retrieves no records. Describe the system's ability to suggest to the user possible courses of action.

5.6.5 provides full help system:

brief instructions and examples on search screen. help is contextual. help can be read/scanned in its entirety. help can be printed, downloaded, and e-mailed.

5.6.6 sets no limit on results but alerts user if large set would be retrieved and offers suggestions for refining search.

5.6.7 supports variations in spelling, common abbreviations and acronyms, and singular/plural forms of words (e.g., color/colour, "&"/and, St. /Saint).

5.6.8 provides messages that are clear, concise, and easily understood by all levels of users.



5.7 Website InterfaceThe website interface for each SMT should be designed keeping in view the organizational hierarchy of each SMT. Under this hierarchy, SMT is at the highest level.Under each SMT there will be multiple Agents, which is second level.Under each Agent, there will be multiple Sub-agents, which is third level.

The system should adhere to the following guidelines:

5.7.1 The SMT home page will have links to various Agents, which will be the home page for each agent

5.7.2 The Agent home page will have links to its various Sub-agents, which will be the home page for each sub-agent

5.7.3 The client and the staff will have the access to the transaction screen/page through this hierarchy

In the following sections 5.8 to 5.15, Contractors must provide detailed explanations of the functions or capabilities represented in each specification as requested.

5.8 Systems Administration

5.8.1 General

Describe how the system:5.8.1.1 supports distinct databases that have separate profiles and security configurations. Responses should include but not be limited to use by other sites or separate sites for staff training/testing purposes and to share data files as well as money transfer defined resource files. 5.8.1.2 supports export of data and authority records for an entire database, for selected records, and for records added in a particular timeframe. 5.8.1.3 operates in a fully integrated manner, with all modules sharing a common database (except as sites sharing the system may choose to maintain separate files) and a consistent staff interface across all functions.5.8.1.4 supports real-time system operations and capabilities to create, update, maintain, and access all data for money transfer clients in real-time.5.8.1.5 updates all indexes dynamically.



5.8.1.6 supports system availability for a continual 24 hour schedule.5.8.1.7 supports system availability for staff for 24 hours per day.5.8.1.8 supports continual backup to ensure that no transactions or data are lost.5.8.1.9 allows the option for an unlimited number of concurrent user sessions for all members of SOMTA community. If the system limits concurrent user sessions, describe when they are initiated and terminated and how they are counted. If a staff member opens multiple windows of clients, and this uses multiple licensed logons or sessions, describe how many concurrent sessions would be necessary to support the configuration environments outlined in relation to Option A & Option B as mentioned in section 4.0. 5.8.1.10 allows simple and quick movement between staff applications and Money Transfer System.5.8.1.11 supports customization of the number of records displayed, as a result of a search, at the client level. If this is possible describe how it is done.5.8.1.12 allows menu-driven (GUI) access to the staff side of the system.5.8.1.13 allows the menu-driven approach to be bypassed with shortcut, quick keystrokes.5.8.1.14 supports definition of macros and/or operator-programmed function keys.5.8.1.15 supplies logical system-prompted commands in typical workflow situations if necessary. 5.8.1.16 supports creation of date of record entry into system as well as additional date changes to reflect latest update.

5.9 Maintenance and SupportBased on the configurations relevant to Option B described in section 4.0:5.9.1 describe options for providing system support that can be administered centrally and in a distributed fashion by SMT staff. See Section 6.3.6 (Cost - Maintenance and Support).5.9.2 estimate the total number of staff required, their required expertise, and the tasks that they would perform locally. For instance, if the proposed system requires local staff to modify and compile software, this should be indicated. If a systems administrator with background as a programmer/analyst is required to manage the system and hardware, this should be indicated. Contractors should indicate who will perform



installations, i.e., what type of SMT staff member or Contractor staff person. Indicate the number of other staff expertise that might be required, either during implementation or in production: Unix administrator, Oracle (etc.) expert, system operator (day, evening, weekend), backup/batch job staff, etc.

Describe the support services including, but not limited to:5.9.3 software upgrades and frequency of new releases. List a history of past release dates.5.9.4 telephone support options (eastern time zone) and hours per day and days per week of service availability. Include support schedule.5.9.5 direct Contractor support of installation and troubleshooting of the system software. Estimate installation support days provided.5.9.6 direct Contractor support of installation and troubleshooting of required third party software such as a commercial relational database package. Specify packages and support. Indicate potential conflicts with release levels between what is used by the system and what is currently marketed by the third party Contractor.5.9.7 how priorities are assigned to customer support requests.

5.10 Software ConsiderationsDescribe:5.10.1 to what extent relational database or object oriented technology is used in the proposed system. Identify any commercial database software and the supported release level used as part of the proposed system.5.10.2 the timeliness of software upgrades with regard to APPLICATION. Explain how software is kept up to date with operating system changes. Are recompiles run by Contractor or money transfer personnel?5.10.3 options for customizing web pages. Describe any limits and restrictions.5.10.4 how the system supports functions including, but not limited to, separate call number systems, separate acquisitions defaults, and ability to profile overlay of imported records by database or separate processing unit within a database. 5.10.5 how the system supports options for either sharing authority control functions within/or among clusters of sites, or having separate authority control functions for a specific SMT.



5.10.6 how new system releases are installed. Indicate what is installed by money transfer systems personnel and by Contractor personnel.5.10.7 how new releases are scheduled. Give current schedule of planned new releases.5.10.8 the capability for unlimited licensing for software. Describe any limits on numbers of client instance licenses and associated costs.

5.11 End-to-end Money Transfer TransactionsDescribe how the system:5.11.1 provides money transmission functionality. SMTs are open to proposals as to the design of the Remittance function. Designs might include an actual database and indexes comprising the individual databases, or a set of common indexes pointing to individual database records. Any proposal requiring double maintenance of records in databases is unacceptable. Considering the SMTs’ operational hierarchy, it may be necessary to design the database specific to its needs.5.11.2 retrieves records that show real-time holdings detail and transaction status.

5.12 Report GenerationDescribe how the system:5.12.1 includes a wide range of standard reports. Include samples of all pre-defined reports. Customized reports can be generated with SQL/Report writer. If report generation is not standard SQL, document this in detail. Describe any third party software required. Include descriptions and samples of all pre-defined reports.5.12.2 supports report generation to be immediate or to be scheduled in background.5.12.3 supports extraction of entire database in a flat, or ASCII defined format. 5.12.4 produces graphical statistical reports.5.12.5 generates location-based reports.5.12.6 allows customized reports by date and record ID parameters.



5.12.7 allows for selection of data for report generation at the entire system level as well as by administrative unit and transaction unit and other levels.

5.13SecurityDescribe how the system:5.13.1 includes a flexible, multilevel, money transfer staff security authorization control capability. 5.13.2 allows an appropriately authorized staff person to examine and alter the authorization levels for other staff persons in a group of sites or a single site without needing the assistance or involvement of the Contractor or central system management personnel.5.13.3 allows each Operator staff or department manager to establish and maintain a separate set of passwords and authorized functions for their staff.5.13.4 allows only authorized staff to view and modify security definitions.5.13.5 grants create and update privileges at the logical record level, so for example, certain staff can be authorized to update item records.5.13.6 restricts work on authority records, transaction records by SMT or by agent/sub-agent5.13.7 prevents unauthorized access (either external or internal) to system management functions and files.

5.14 TrainingTraining for the proposed system will follow a training of the trainer model. Two types of designated staff will be trained: functional support staff will be provided training in the operation of the system for participating SMTs; and system administration support staff will be provided training to operate and maintain the system hardware and software.

5.14.1 Training Methodology



Describe any functional and/or systems administration support training the Contractor requires of money transfer operations staff.

Describe the courses of training provided to enable the staff to become familiar with system functions and operations, including, but not limited to:5.14.1.1 a list of all deliverable training modules. 5.14.1.2 whether instructors are available to train on-site. 5.14.1.3 maximum number of trainees per class and the total number of days of training for each module. 5.14.1.4 whether it is possible to purchase additional training days.5.14.1.5 availability of other training aids such as videos, software tutorials, or Web-based instruction.5.14.1.6 availability of computer-based training.Indicate if training sessions for systems administration cover topics, including, but not limited to:5.14.1.7 appropriate administrative functions including supervisory override procedures such as data backup and restoration. 5.14.1.8 common causes of system failure and the remedy for each.5.14.1.9 how to obtain telephone support for the correction of system problems.5.14.1.10 how to identify and perform all elements of preventive maintenance of the system not routinely performed by the Contractor.5.14.1.11 installation and support of client software applications if any5.14.1.12 how Contractor tracks problems and assigns severity priorities.

5.15Optional Modules

The modules mentioned under this section are desirable to have but not mandatory. If the Contractor’s system includes the following desirable modules please describe the system briefly:5.15.1 Full fledged accounting module5.15.2 Forex Management module5.15.3 Multiple languages, especially Somali and Arabic5.15.4 Offline Transactions for agents who do not have Internet connectivity and/or when Internet is down5.15.5 Date, Time setup for various agents and sub-agents as they operate in different countries and zones



5.15.6 Deposits Management (only deposits and withdrawals)



6 COST SUMMARY

6.1 Separate cost quotes for each Option listed in Section 4.0This Section is structured in the following categories in order to ascertain cost comparisons among the proposed bids. All items in this Section must be completed by insertion of a cost figure, a notation that it is a non-applicable item (N.A.), or furnished at no charge (N.C.). If a particular cost item is bundled, indicate where it is included. Indicate clearly if a particular cost item is not deliverable. Contractors failing to furnish complete cost data will be considered non-responsive.

6.1.1 Cost - Software

6.1.1.1 Functional Mandatory Modules as per section 4.2 6.1.1.2 Functional Optional Modules

6.1.2 Cost – Installation and Implementation

6.1.2.1 Hardware, web server, firewalls (hardware & software), security configurations, database profile6.1.2.2 Application software installation and system initialization6.1.2.3 Implementation cost for the 10 initial SMTs

6.1.3 Cost - Training/Documentation

Quote costs for:

6.1.3.1 providing functional training to 25 support staff. Indicate the type of training to be included and whether training is done on-site or off-site. 6.1.3.2 providing systems administration training to 10 support staff. 6.1.3.3 providing additional functional training. 6.1.3.4 providing additional system administration training. 6.1.3.5 providing a complete set of user and system manuals covering all operations and functions to support configurations relevant to Option A & Option B mentioned in section 4.0. Indicate if format of the documentation (print, CD-ROM, web access) impacts the price.6.1.3.6 each additional set of documentation.6.1.3.7 documentation upgrades.

6.1.4 Cost - Maintenance and Support

The Contractor will be expected to provide direct support to all the SMTs via assigned contacts at each one. Indicate how costs for maintenance and support would be impacted by the different options and provide the following:



6.1.4.1 Describe the different levels of maintenance support (hardware, software, network, telephone, on-site visits, hours of guaranteed emergency response, etc.) and list the associated costs on an hourly, weekly, or flat fee basis.6.1.4.2 Indicate ongoing software enhancements that are provided and any associated recurring or one-time charges.6.1.4.3 Indicate the money transfer management software maintenance costs for years one(1), two (2), three (3), four (4), and five (5).

6.1.5 Cost - Additional Costs

List any additional costs that have not been provided for in the preceding categories. For example, since it is not known exactly how many SMTs will participate in this project UNDP Somalia/SOMTA will need flexible pricing and will need to know when there are other charges that apply to the host sites for servers as well as individual SMT participants. For instance, if there are 4 additional SMTs each with 100-250 agents/sub-agents, are there additional charges?

Please provide costs of third party systems if proposed as part of your solution.

Any cost which is not included as part of Financial proposal will not be allowed if claimed later on during contract negotiations or afterwards.

6.1.6 Cost - Data Centre Service (applicable to Option A only hosted in Dubai)

6.1.6.1 Monthly charges for Internet data centre hosting, server hardware, software and 24x7x365 technical support services, including web server, database server, application server, network routers and switches, load balancers, firewalls, and data storage. The services should include Network firewall, IDS (Intrusion Detection System); Disaster Recovery; Data Backup; Network and Server hardware/software installations, configurations, monitoring and management; Data Recovery in cases of failures.

6.1.7 Warranty

The Contractor is expected to provide a warranty for a minimum period. Please specify the warranty period and terms and conditions associated with it.

6.1.8 Definitions



6.1.8.1 define specific terms or phrases, such as "simultaneous users," stated in the price lists.6.1.8.2 indicate how terms or phrases identified in Section 6 are determined for calculating costs.



Appendix A

Glossary

SOMTA – Somali Money Transmitters AssociationSMT – Somali Money Transmitters, who are members of SOMTAAgent – a representative operating under a SMT as a franchisee and providing money transfer servicesSub-agent – a sub-representative of an Agent providing money transfer servicesAML – Anti Money LaunderingCFT – Combating the Financing of TerrorismSAR – Suspicious Activity ReportCTR – Currency Transaction ReportOFAC – Office of the Foreign Assets Controlbid proposal = bid response.bidder = contractor, offerer, proposer, vendor.deliverable = the software must be shown to be functional both by demonstration and by existing references who have the application in production at their sites.dynamic = in reference to indexing done in real-time, so that all changes are reflected immediately in all modules.product = shall include, without limitation: any piece or component of equipment, hardware, firmware, middleware, custom or commercial software, or internal components or subroutines therein which perform any date/time data recognition function, calculation, comparing or sequencing. Where services are being furnished, e.g., consulting, systems integration, code or data conversion or data entry, the term "product" shall include resulting deliverables.processing unit = technical services unit within a sites' system, which maintains own data records. required = mandatory, must, shall.screens = displays that are generated by the client software and are understood to indicate MS Windows client screens, Web Pages, as appropriate.SC = Steering Committeestaff = staff members of the SMT (and its agents/sub-agents) sites.status codes = codes that indicate conditions such as "open," "in process," or "fully completed."system = proposed integrated money transfer system software implemented in any configuration with any number of participating SOMTA-wide sites.third party product = shall include product manufactured or developed by a corporate entity independent from Contractor and provided by vendor on a non-exclusive licensing or other distribution Agreement with the third party manufacturer. "third party product" does not include product where Contractor is: (a) a corporate subsidiary or affiliate of the third party manufacturer/developer; and/or (b) the



exclusive re-seller or distributor of product manufactured or developed by said corporate entity.user = any money transfer patron accessing the Proposed System or staff functions through workstations within the sites or remotely from offices, homes, and other sites.Contractor's product = shall include all product delivered under the agreement resulting from this RFP by Contractor other than third party products.


REQUEST - IAPSO - Money Transfer Solution R… · Web view5.15.2 Forex Management module. 5.15.3...

Documents

Transcript of REQUEST - IAPSO - Money Transfer Solution R… · Web view5.15.2 Forex Management module. 5.15.3...