All information on the procurement related to the Maldives Payment System Development Project is available on this page.



Request for Proposal (RFP) - Independent Legal Expert

Request for Proposal (RFP) for Independent Legal Expert for the Maldives Payment System Development Project

Maldives Monetary Authority Invites bids for " Independent Legal Expert for the Maldives Payment System Development Project "




Request for Proposal (RFP) - Project Management Advisor

Request for Proposal (RFP) for Project Management Advisor for the Maldives Payment System Development Project

Maldives Monetary Authority Invites bids for " Project Management Advisor for the Maldives Payment System Development Project "




Request for Proposal (RFP) - Payment System Consultants

Request for Proposal (RFP) for Payment System Consultants for the Maldives Payment System Development Project

Maldives Monetary Authority Invites bids for " Payment System Consultants for the Maldives Payment System Development Project "




Request for Offer (RFO)

MMA invites all vendors that registered to the RFI (reference number IL-PRC/2019/09 dated 31st January 2019) to submit proposals to the RFO for the Maldives Payment System Development Project.


A complete set of the RFO containing detailed information is available from MMA’s website and the links below. Vendors may obtain further clarifications regarding the RFO via email until 19th June 2019.



Related Documents



Response to queries from vendors regarding RFO


    Updated 24 June 2019
  1. How does the current ACH and RTGS System work?
  2. Currently, all inter-bank transactions are executed via the Maldives Real Time Gross Settlement (MRTGS) system and Automated Clearing House (ACH) system, which are both operated by the MMA. The MRTGS system processes and settles urgent, high value inter-bank transactions and the ACH system is a session based clearing system for low value batch transactions.


  3. There was implicit reference to applications that support e- wallet. Is that the solution expected for the unbanked population?
  4. The Digital Bank Module must be able to create a wallet (or virtual account) which can be provided to any customer (Maldivian individual, business, expatriate or tourist), including the unbanked. The requirements for the wallets which will be provided by the Digital Bank are detailed in Section 6.5 and Subsection 7.2.5 of the RFO.


  5. How are the mobile applications integrated in the current system (Mobile Payment System working)?
  6. Currently the Mobile Network Operators (MNOs) operate the Mobile Payment Services in the Maldives in a closed loop system. In the new infrastructure the UPG must allow users to make payments via different channels including mobile apps.


  1. Will national registration database have biometric information? Please provide details about its APIs.
  2. The national registration database contains biometric information and will be connected to UPG via APIs for biometric verifications. API details will be provided to the selected vendor.


  3. How does the current bank to bank settlement process work?
  4. Please refer to the answer provided for question number 1.


  5. How to verify international customer details (Know Your Customer - KYC), in order to access e-wallet facilities?
  6. KYC of the tourists will be done on arrival.


  7. What are MMA’s expectation regarding the e-Card balance transfer to international customers?
  8. As per the requirements specified under Subsection 7.2.5, the function to transfer funds back to bank or card must be available. These services will be provided by PSPs to the tourists.


  9. What are the card types to be included in the card payment system? (Elaboration on Card payment system expectations)
  10. Only local scheme cards issued by PSPs will be used for domestic transactions. International schemes will not be used. However, the new system will connect to international schemes via existing banks.


  11. Does the transaction happen in dollars, due to the absence of local payment scheme?
  12. The new system is a local payment scheme and will support single currency (Maldivian Rufiyaa).


  13. Can you provide the full set of documents that are circulated together with RFO if there are any?
  14. There is no additional documentation which is circulated with the RFO. Additional information is available on our website www.payments.mv.


  15. With regard to Subsection 7.2.5 (Collect Money), What function do you mean by saying 'collect money'?
  16. This refers to the Pull Payment function. The local payment scheme which will facilitate transfer of funds between various accounts. These functions will be available for the PSPs to provide payment solutions at lower level to the end user.


  17. With regard to Subsection 7.2.5 (Scan and Pay), What function do you mean by saying 'scan and pay'?
  18. The local payment scheme which will facilitate transfer of funds between various accounts. Functions such as Scan and Pay will be available for the PSPs to provide payment solutions at lower level to the end user.


  19. With regard to Subsection 7.2.4 (The Clearing Module must provide an automated and manual mechanism to top-up or decrease the limits/caps where necessary by reserving/releasing liquidity from the settlement account), What are the circumstances you are referring here for the manual intervention? Does the manual mechanism refer the manual intervention typically owned by the administrator or the supervisor?
  20. Yes. It refers to the controlled administrative rights and accessibility.


  21. Similar projects overseas require processing a transaction within 0.2 seconds. Are you sure that 5 seconds is good enough to be qualified as it would automatically be rejected for the use overseas soon?
  22. Five seconds is the minimum criteria for an end to end transaction. Therefore it does not limit the vendor to propose a system with lesser transaction processing time.


  23. Please note that a similar projects overseas which is likely to be implemented in a few years’ time, which requires 2,000 transactions per second in order to have sufficient capacity to handle “instant” payments. This is because there will be congestion in mobile network which needs to be recovered with more transactions per second. Are you sure that the minimum requirement is only 400 transactions/ second? Or do you mean that the minimum requirement even at the time of congestion at mobile network is 400 transactions/ second? This distinction is important for the Maldives whose weather conditions as well as vulnerability to Tsunami which may cause mobile congestion from time to time.
  24. As mentioned in requirement number MMA-NFR-023, the system must be able to handle operation at a minimum of at least 400 transactions / second. Please note that at a given time, the total population in Maldives is not expected to exceed 1 million which is inclusive of resident foreigners and visiting tourists.


  25. Is this requirement for 20 concurrent users correct? 20 concurrent users are too relaxed and is likely to be obsolete in a few years’ time.
  26. Please refer to the answer provided for question number 15. Please note that the requirement explicitly states that the system must be scalable to add more users in a short period.


  27. If MMA wants to ensure the interoperability to overseas settlement standards, so that the user is able to use the new system overseas, the necessary requirements should be to process a transaction with necessary Risk Controls in < 0.2 seconds.
  28. Since the minimum criteria is less than one second, it does not limit the vendor to propose a system with lesser transaction processing time.


  29. We would like to request MMA to kindly provide duration for which the statistics for the transactions are mentioned in the figure 2 of the RFO.
  30. The statistics given in Figure 2 of the RFO is for one year for the year ended 2018.


  31. We would like to request MMA to kindly provide clarification on the two clauses regarding the TCO as they both contradict each other. Kindly guide if the evaluation would be done considering the TCO for 5 years or 10 years.
  32. The evaluation will be done considering the TCO for 5 years. However, the vendor shall provide price schedule to show total cost of ownership for 10 years.


  33. With regard to Section 6.3 (Smart Addressing), We understand that the requisite APIs for the integration with all the 3rd party application/databases will be made available by MMA to the selected Vendor. Request you to kindly confirm the same.
  34. MMA will make arrangements to get all necessary APIs for the integration with the 3rd party application/databases.


  35. With regard to Section 6.5 (Digital Bank), Request you to kindly elaborate on what all limited services will be accessed by the unbanked customer.
  36. The system must be capable of allowing unbanked customers to access all services. The decision on the services which will not be available to the unbanked customers is to be decided at the scheme rules development stage.


  37. With regard to Subsection 7.2.2 (Unified Payment Gateway), requirement number MMA-FR-UPG-014, Request you to kindly specify what are the data elements based on which the KYC Verification needs to be done?
  38. The UPG must allow KYC verification for new customers during the registration process through the integration with the National Registration databases (including but not limited to: Department of National Registration, Legal entities through Ministry of Economic Development and tourists and expatriates through Maldives Immigration) which contains biographic and biometric information. It will be connected to UPG via APIs for biometric verifications.


  39. With regard to Subsection 7.3.1 (Non-Functional Solution Overview), The Vendor requests to kindly provide clarification, if the Hardware will be procured by MMA and that the Vendor just needs to provide the hardware specifications (Bill of Material).
  40. Yes. Hardware will be procured by MMA and the Vendor needs to provide detailed Bill of Material for the Hardware.


  41. We would like to request MMA to kindly provide the guidelines for the payment terms once the Vendor is selected.
  42. MMA will negotiate the contract terms with the selected vendor which will include payment terms.


  43. Request to kindly provide the details of the location where the Instant Payment solution will be hosted. Also, kindly clarify that the network connectivity, if any, will be provided by MMA.
  44. UPG and other related system components will be installed within MMA premises. MMA will provide the necessary network connectivity.


  45. We request the Bank to let us submit more Pre-bid queries post we have received one round of response from MMA and to extend submission date by two weeks to 2nd July 2019 to enable us to have a better clarity for preparation of response
  46. Given the constricted timeline, MMA will not be able to change the given timeline.


  47. Source code is only released to the MMA under special contractual terms to be later agreed upon: In the case when we are providing the licensed software only the customizations made for you would be provided as source code. Kindly confirm.
  48. Vendor must fully comply with the requirements stated in Subsection 7.5.2 of the RFO.


  49. Considering the complexity of this project, Request you to relax the timelines from 9months to 15 months for the go-live of the application
  50. Given the constricted timeline, MMA will not be able to change the given timeline.


  51. With regard to Subsection 7.1.3, Please modify the clause of Business Analysis Team Lead to minimum experience of 3 years as a Payment System Business Analyst.
  52. Please note that 5 years’ experience is the minimum requirement.


  53. With regard to Subsection 7.1.3, Please modify the clause of Project manager to minimum experience of 3 years as a project manager of payment system projects and relevant industry certification, e.g. PRINCE2 Practitioner/Agile, PMP, PMI-ACP, etc.
  54. Please note that 5 years’ experience is the minimum requirement.


  55. With regard to Subsection 7.1.4, Kindly clarify if it is the mandatory requirement.
  56. The referred subsection does not constitute any mandatory requirement for the submission of stated certificates.


  57. With regard to Subsection 7.4.2 (a) The MMA expects the vendor to offer 24/7/365 post go-live support for the delivered system under terms of a contract for an indefinite period. b) Technical support must be dedicated support, with a 24/7/365 availability.), We understand that that bidder will not be responsible for the issues arising out of infrastructure/hardware.
  58. The Vendor is not expected to be responsible for hardware issues. However, the Vendor must assist the hardware provider in resolving any issues if deemed necessary.


  59. With regard to Subsection 7.4.1 (The vendor must present its proposed training plans that include the following topics as a minimum requirement), Kindly confirm the number of people, batches to be trained and also the location.
  60. As mentioned in subsection 7.4.1, the vendor must provide a full description of the training sessions including the length and the maximum attendees’ number. This must be based on the number of staffs required for the proposed solution.


  61. Final vendor proposal submission deadline: This is a huge proposal and for preparation of proposal a lot of ground work is required. We request MMA to extend the bid submission date by at least 3 weeks. This would enable us to submit a comprehensive and quality proposal.
  62. Given the constricted timeline, MMA will not be able to change the given timeline.


  63. Is MMA open for a custom-built solution?
  64. MMA is open for a custom-built solution.


  65. Kindly send us end-to-end transaction flow between each subsystems and Individual federated systems.
  66. The solution is a local payment scheme which will facilitate transfer of funds between various accounts. The PSPs will provide payment solutions at lower level to the end user.


  67. Are the criterion set in Vendor qualifications like Minimum qualifications of the project staff, organization Certifications, etc. are mandatory features or good to have features
  68. Minimum qualification requirements listed for some of the roles in Subsection 7.1.3 are the minimum requirements. However Subsection 7.1.4 (Certifications) does not constitute any mandatory requirement for the submission of stated certificates.


  69. What is the maximum limit or yearly growth projections in transactions, Transactions per second, concurrent users are MMA expecting?
  70. Please note that the performance targets listed under requirement number MMA-NFR-023 are minimum requirements considering the expected growth in the near future. Hence, the Vendor may propose the solution based on any maximum limit or growth rate.


  71. As per RFO, While evaluating costs, the MMA will consider the total cost of ownership (TCO) projected for 5 years, but during evaluation the weightage will be given to TCO for 10 years? Please clarify the period of engagement?
  72. Please refer to the answer provided for question number 1ndly clarify the TCO to be calculated for a period of how.


  73. As per RFO, Proof of a professional liability insurance that shows coverage of risk that is proportional to both. Kindly provide a detailed explanation on this?
  74. Please refer to point (J) “i’ and “ii” of subsection 7.1.1 of RFO.


  75. As per RFO, The MMA expects the vendor to offer 24/7/365 post go-live support for the delivered system under terms of a contract for an indefinite period. The period must be definite and would be governed by the agreement, kindly clarify this.
  76. The support services will be provided as per the terms of a contract which will be reviewed on an agreed basis. Hence, the terms and period are negotiable.


  77. As per RFO, The vendor is also expected to indicate a man/days fee per professional profile for future additional software development and implementation services. Since this is not mentioned in the pricing table -Appendix B, Kindly state where this information needs to be captured?
  78. The details may be provided separately.


  79. Kindly clarify the TCO to be calculated for a period of how may years? 5/10/any other. Also, confirm whether Post go live support commercials are considered to be part of TCO evaluation.
  80. Please refer to the answer provided for question number 19. Post go live support commercials will be considered.


  81. Kindly state the configuration of currently functioning Internet service provider’s i.e. Network speed and mobile networks 2G / 3G / 4G and confirm on the availability of higher speeds in near future.
  82. At present there is 100% 4G coverage in all populated areas of the country.


  83. Are account holders' bank account number and mobile numbers/email id/ID card etc. linked in a mapper DB at MMA?
  84. There is no such database at present. The Smart addressing function of the new infrastructure will allow customers to make payments using easy-to-remember tokens and identifiers such as national identification numbers, mobile numbers, email addresses and social media handles.


  85. Kindly confirm the availability of high end servers having required configuration at MMA and bank end, for the solution to be developed.
  86. MMA will procure the required hardware as per the Bill of Material for the Hardware submitted by the Vendor.


  87. Which regulations framed by MMA are applicable for current/existing payment system? Do these regulation need to be adhered to by the new payment system. Kindly provide the details of such regulations.
  88. Laws and necessary regulations for the regulatory framework are currently under development.


  89. Kindly Provide details / flow of current KYC verification process.
  90. Currently each financial institution has its own KYC policy.


  91. Kindly provide specific list of all channels to be made available for payments/transactions.
  92. The solution is a local payment scheme which will facilitate transfer of funds between various accounts. It will allow users to make payments via different channels including but not limited to mobile app, web, kiosks, smart devices, and schemes. The PSPs will provide payment solutions at lower level to the end user.


  93. What is the configuration of currently existing servers and databases used in existing payment system at MMA and all Banks?
  94. Currently the servers and databases of MMA and Banks are in accordance with the requirements of the existing MRTGS and ACH systems. MMA will procure the required hardware for the new payment system as per the Bill of Material for the Hardware submitted by the vendor.


  95. Is General Ledger (GL) accounting considered to be a part of the solution?
  96. It is not included in the scope.


  97. Kindly confirm the flow how will PSP make payment on behalf of customer?
  98. The solution is a local payment scheme which will facilitate transfer of funds between various accounts. It will allow users to make payments via different channels including but not limited to mobile app, web, kiosks, smart devices, and schemes. The PSPs will provide payment solutions at lower level to the end user.


  99. Can MMA provide list/details of existing API exposed by various systems with which the UPG system will be required to integrate with, for new solution to work seamlessly?
  100. MMA will provide the details of the APIs and make arrangements to get all necessary APIs for the integration at a later stage.


  101. The Digital Bank mobile application module must allow multi-factor customer authentication (i.e. password, PIN, tokens, biometrics, OTP). Who will provide the biometric devices and Biometric authentication?
  102. The national registration database will provide the identifiers and biometric data to the UPG.


  103. All functionalities available with the Modules should be available through usable, graphical interfaces where internal and external users can effectively, efficiently and securely manage the functions of the system. Vendors should describe in detail how the GUIs of their solutions support the functionalities listed above. Beside the description, the following documentation is expected: a) User manuals to live systems or systems in the testing stage. b) Screenshots on how the GUI of the vendor’s solutions fulfils the requirements above. Is it necessary to send “a” and “b”?
  104. If vendor is proposing a standard solution, the Vendor shall submit the requested details in “a” and “b”.


  105. The RFO does not mention anything about hardware procurement. Does vendor submit only the Bill of Material [BoM] required for UPG or vendor will be responsible for procuring the hardware as well? In the commercial pricing section, where should vendor mention the hardware cost? Does MMA need a BoM for the hardware in Staging, Certification and Testing Environments as well ?
  106. The vendor is required to submit a detailed Bill of Material for the Hardware. Procurement of hardware will be carried out by MMA. Hardware commercials maybe included in a separate section of the proposal. Bill of Material for the hardware in Staging, Certification and Testing Environments must be included.


  107. Does Maldives National Registration Database provide API based interface for KYC validation?
  108. MMA will make arrangements to get all necessary APIs for the integration.


  109. RFO expects a built-in FRM engine with UPG. Success of a FRM rule engine depends on past transaction data [through other payment channels] and past fraud detection measures. Will MMA provide such data? Also will MMA provide the black and white rules?
  110. MMA will cooperate with the selected Vendor to establish proper rules for risk management.


  111. In Section 5.3 on the Evaluation and Award process the Total Cost of Ownership(TCO) is mentioned as 5 years in point (d) and 10 years in the weightage chart. Which should be the support period – 5 years or 10 years?
  112. Please refer to the answer provided for question number 19.


  113. The vendor is also expected to indicate a man/days fee per professional profile for future additional software development and implementation services. Where this will be mentioned? Will this be mentioned along with Pricing Table?
  114. Please provide the details separately.


  115. Implementation Costs - Please provide separate prices for every project phase. The current Pricing Table does not have a phase-wise breakdown. How MMA want this?
  116. Please provide the details separately.


  117. What are the lists of Acceptance Criteria for this project from MMA?
  118. Acceptance Criteria will be provided as a part of contract negotiations.


  119. The system must meet the appropriate cyber security standards. Is there any specific standard defined by MMA or the industry standard will do? What is MMA’s system security and Vulnerability Assessment and Penetration Testing (VAPT) policy?
  120. MMA will coordinate with the selected Vendor to identify the necessary standards in accordance with the Industry standards.


  121. Please let us know the difference between AIPs, PSP and banks. Whether MMA expects UPG to expose separate APIs for AIPs and PSPs?
  122. AIPs include all institutions that hold customer accounts used in the payment process, either directly or indirectly through a third party. PSPs are institutions that provide payment solutions built on top of the payment infrastructure, possibly utilising the information provided by AIPs. MMA expects separate APIs for AIPs and PSPs.


  123. All banks in the Maldives will be directly linked to the system and it will facilitate Account Information Providers (AIPs) to provide account information through the UPG to Payment Service Providers (PSPs) to offer innovative payment services to the customers.: Whether the Banks which are going to connect to the UPG will be doing corresponding changes at their side to provide information about the customers.
  124. All the participating Banks will make the necessary changes.


  125. As a central system, UPG should maintain same message format across the Banks connecting to the System to have a uniformity and convenience in maintaining the system and all the member banks are supposed to connect to the central system in a similar way. Can you please explain why multiple message formats are required here like ISO200022, ISO8583, and SWIFT?
  126. Multiple messaging standards are required to allow all participants to integrate seamlessly with UPG.


  127. Allow PSPs to access to accounts in AIPs network (e.g., Banks, MNOs) to make payments on behalf of customers: Who will take the responsibility of customer authentication when PSP does the payment on behalf of customer? Can you please explain typical workflow?
  128. UPG will allow different identification methods and multiple authentication methods. PSPs will allow customers to conduct transactions based on UPG rules.


    Updated 26 June 2019
  129. More information about the present Disaster Recovery System.
  130. These details will be provided to the selected vendor.


  131. How does the bulk upload process work? What channels/media are used?
  132. Bulk upload functionality is the functionality within the instant payment system that is capable of receiving large numbers of transactions in one bulk that are in turn unbundled and processed as single transactions, then at the end of processing it is capable of sending back the response messages in bulk. PSPs may use different channels for initiating such a transaction.


  133. With regard to Subsection 7.2.5. (Transfer money Account-to-Account), What are the differences among account, wallet and card?
  134. The new system is a local payment scheme which will facilitate transfer of funds between various accounts. The white labelled mobile banking application will allow transactions through the local scheme. These functions will be used by the PSPs to provide payment solutions at lower level to the end user.


  135. With regard to Subsection 7.2.5. (Transfer money Account-to-Wallet), What are the differences among account, wallet and card?
  136. Please refer to the answer provided for question number 70.


  137. With regard to Subsection 7.2.5. (Transfer money Wallet-to-card), What are the differences among account, wallet and card?
  138. Please refer to the answer provided for question number 70.


  139. What information size do you expect the rich and informative messages need to carry? As the size of messages becomes bigger, it may cause the delay.
  140. Rich information means transaction messages that would be sent to payer and payee such as payment confirmation message, payment rejection message and other such short messages not more than 255 characters. It does not necessarily be SMS.


  141. With regard to Subsection 7.1.4 (If the vendor has Certificates of the following standards, it must be enclosed to the Proposal: a) ISO 27001, b) ISO 22301, c) ISO 9001, d) PCI DSS), The IP owners of the system does not own all the certificates required in the RFO. Would it be alright if a sub-contractor or a consortium member or a joint venture partner has the certificates? If in the event that the main contractor needs to own the certificates, would it be possible for us to change the composite of the consortium currently mentioned in our proposal to the RFI?
  142. If the registered vendor has registered as a consortium, proposal may be submitted by the consortium and the certification can be owned by any member. However, during the registration process the vendor is not registered as a consortium, during the proposal submission vendor will not be eligible to submit the proposal as a consortium. The referred subsection does not constitute any mandatory requirement for the submission of stated certificates.


  143. What kind of external Identity Management Services do you expect the UPG need to connect?
    Do you have any protocol requirement? Is Lightweight Directory Access Protocol (LDAP) qualified?
    Can we propose our own Identity Management Services or User Privilege Management Tools?
  144. The vendor may propose their own identity management services for user privilege management.


  145. With regard to Subsection 7.1.1 (Overview and Consortium Information, Point 'j'), We request you to kindly clarify which document needs to be submitted as a proof of a professional liability insurance. Also, kindly suggest if the submission of an Undertaking for providing insurance will suffice the requirement.
  146. Undertaking for providing insurance will be sufficient to meet the requirement.


  147. With regard to Subsection 7.3.2 (Non-Functional Requirements), requirement number MMA-NFR-003, We understand that the requisite APIs for the integration with all the SMS/email/instant messaging will be made available by MMA to the selected Vendor. Request you to kindly confirm the same.
  148. The system must have built in SMS/email/instant messaging capabilities. MMA will facilitate SMPP and SMTP connections to the service providers.


  149. Request you to kindly provide clarification, if MMA is planning to conduct Technical Bid Opening process post the proposal submission deadline.
  150. MMA will conduct Technical Bid Opening process post the proposal submission deadline.


  151. With regard to support capabilities, Does bidder has to factor in the cost for the ticketing or helpdesk tool including licenses, implementation and support cost?
  152. The Subsection 7.4.2 states that the MMA must use the ticketing system of the Vendor, as well as a dedicated hotline for high-priority issues. Hence, the Vendor is expected to facilitate this and Vendor may propose alternate mediums for reporting high-priority issues.


  153. Please clarify which list of deliverables at minimum needs to be submitted along with the proposals, As for example some of the reports like test plan, specifications, QA final report for UAT Start, Performance testing report, penetration test report pertains to the implementation / post implementation stage.
  154. In the subsection 5.7.2 'Deliverables' refers to the deliverables upon completion of the project by the selected vendor. It is given for costing purpose.


  155. As per RFO, the external interfaces includes with AIPs, PSPs, MRTGS/Settlement system. Kindly list any other/all envisaged external interfaces.
  156. All the requirements are detailed in Section 7 of the RFO.


  157. Kindly list all possible overlay services MMA is expecting?
  158. All the overlay services needed to meet the requirements detailed in Section 7 of the RFO must be provided by the Vendor.


  159. As per RFO, If the vendor is a subsidiary, the vendor must disclose the information required above for its parent and/or holding company. Kindly clarify on what information/s are required to be disclosed by the vendor.
  160. Please refer to subsection 7.1.1. Although the statement reads 'above', the list is given 'below'.


  161. What are the Minimum OS versions of Android and iOS to be supported?
  162. Minimum OS versions of Android: Android 4.1
    Minimum OS versions of iOS: iOS 7


  163. Bidder doesn't operate in the given geography as such current insurance does not include Maldives. Can provide copies of existing insurance and give undertaking to have insurance if the Project is awarded. Please confirm
  164. Please refer to the answer provided for question number 76.


  165. In Section 7.4.2 and Section 7.4.3 it is mentioned that the MMA must use the ticketing system for the vendor ' Is there any choice of Ticketing system? At what stage is the demo of Ticketing system expected? Will Hot Line number be provided by MMA? Should vendor bear the cost of Hot line number during warranty support period only?
  166. The Subsection 7.4.2 states that the MMA must use the ticketing system of the Vendor, as well as a dedicated hotline for high-priority issues. This ticketing system and hotline are for MMA to log support requests with Vendor.


  167. What is the integration option with MRTGS System? Is it API based or file based?
  168. Current MRTGS System supports file based integration. However, vendor solution must support both file based and API based integration with third party settlement system.


  169. It has been mentioned that the Clearing Module must allow UPG participants to allocate clearing and settlement limits/caps, where the payment instructions are validated against these limits. Limits will be configured by direct participants through a web-based GUI.
    What will be validation process? Will there be an approval process needed?
  170. Payment instructions are validated against the limits/caps allocated by UPG participants. The approval process must consist of multiple-factor authentication and manual intervention where necessary.


  171. The Clearing Module must support clearing and settlement within the system, without depending on the existing MRTGS system.
    Will this be interparty settlement? Will this be Prefunded? Or deferred Net settlement? How the actual fund transfer will take place?
  172. The Clearing Module must support clearing and settlement within the system, without depending on the existing MRTGS system. Vendor may propose to use MRTGS or alternate solution for settlement.


  173. The system must be able to integrate with external Identity Management Services (or User Privilege Management Tools). What is the tool? Who will provide it?
  174. Please refer to the answer provided for question number 75.


  175. There is a software license cost related to the operating system or database or monitoring tools etc. Will MMA bear the license cost from Year 2 onwards?
  176. As mentioned is Subsection 7.3.1 of the RFO Vendor is only expected to submit a detailed Bill of Material for 3rd party software. Vendor provided software are expected to be included in the commercials.


  177. Our proposed solution runs with certain standard sets of ISO20022 messages. These sets of messages need to be customized as per MMA requirements. Will MMA publish any Processing Specifications, Procedural Guidelines and Operating Regulations to which the selected vendor need to comply? If yes, when these materials will be made available since it has direct impact on the cost and duration of customizing the solution for MMA?
  178. MMA will coordinate with the selected Vendor to identify the customization if deemed necessary.


  179. What is the data backup and archival policy of MMA? What is the projected volume of transaction or data that need to be archived and for what duration? What is data disposal policy / guideline?
  180. As mentioned in the requirement number MMA-FR-UPG-018, the UPG must keep track of every transaction processed by the system with its status for a period of minimum 7 years.
    MMA will coordinate with the selected Vendor with regard to data backup, archiving and disposal policy of MMA


  181. MMA-FR-CL-012 - The Clearing Module must support clearing and settlement within the system, without depending on the existing MRTGS system.
    Is this expected to be an alternative to MRTGS based Clearing? In what circumstances this will be exercised?
  182. The Clearing Module must support clearing and settlement within the system, without depending on the existing MRTGS system. Vendor may propose to use MRTGS or alternate solution for settlement.


  183. Is the Digital Bank mobile application is expected as a separate App than the UPG Reference App?
  184. The Digital Bank will operate like any other bank and will be connected to UPG. The requirement number MMA-FR-DG-005 is to provide a white labelled mobile banking application which can be used by the any PSP.


  185. In the Pricing table, should Implementation Cost include the Hardware Cost?
    Software License Cost [for OS, DB etc.]t typically comes for 3 or 5 years tenure for better price guaranty. Should the vendor mention proportionate 1 year cost only? Also, Software license cost come with support cost? Does Vendor include that cost as well?
  186. As mentioned in Section 7.3.1 a detailed Bill of Material for the Hardware and 3rd party software needs to be submitted. It need not be included in the pricing table.
    Annual maintenance fee must be mentioned. However, bidder is free to add more details to the pricing table.


  187. The vendor is requested to provide two performance and penetration tests during the implementation project:
    a) The first must be conducted on the product final release. Can this be carried out in MMA premise since the product at this point of time is a customized product for MMA?
    b) The second must be conducted at the UAT phase at MMA premises. Will MMA prepare this UAT environment for benchmarking or expects Vendor to do so with hardware provided by MMA?
    c) The penetration tests need to be performed by an independent entity. Who will contract this independent entity, MMA or Vendor? Who will be paying for their Service, MMA or Vendor?
  188. a) The first test can be conducted at MMA.
    b) Vendor must make all arrangements for both the performance and penetration tests, and MMA will provide Hardware.
    c) MMA will contract the independent entity and all associated costs will be borne by MMA.


  189. For topping up the Digital Wallet, a payment gateway would be required. Would MMA provide a payment gateway for the same?
  190. The solution is a local payment scheme which will facilitate transfer of funds between various accounts. Only local scheme cards issued by PSPs will be used for domestic transactions. For International card schemes the gateways of existing commercial banks will be used.


  191. The vendor must give a detailed presentation of its software roadmap for the next five years. Please include any future planned functionalities and support for new technologies, OS, DB, hardware and software updates, with regards to the MMA's future plans.
    Please share MMA's future plans. It is not included in the RFO
  192. MMA will coordinate with the selected Vendor for further development of the roadmap.


  193. Proof of financial viability, including audited financial statements for the past three years for all the Consortium members. '
    What proof is required and what is eligibility criterion?
  194. Submission of the audited financial statements for the past three years would be sufficient to meet the requirement.


  195. The UPG interface layer must be easy to adapt in order to simplify integration with an AIP's back office applications. For integration with AIP's back office applications, UPG is expected to have interface. Can you please explain this with a use case?
  196. For example integration with AIP's systems maintaining account information.


  197. The UPG interface layer must be easy to adapt in order to simplify integration with an AIP's back office applications. Is there any File Transfer expected while integrating with AIPs and PSPs?
  198. AIPs and PSPs will connect to UPG through APIs.


  199. The UPG must allow the management of Corporate Payments. Please specify how the UPG will manage these.
    For management of corporate payments, what is expected out of UPG? According to our understanding the member bank which holds corporate account should be registered with UPG. Is it so?
  200. The UPG will be an open, API-based modular system consisting of an account-based, real-time payment system augmented with the functionality of smart addressing. PSP will provide the services to both retail and corporate customers. The UPG must support any differences in retails and corporate payment messages.


  201. Allow different use cases such as P2P, P2B, P2G, G2P, G2B, B2G, B2P (for example for reimbursements and rebates) and B2B payments. How the payments to the government is anticipated? Is it like government will also be considered as opened an account in a bank which is supposed to be the member of UPG?
  202. Government payments will also be account to account payments via local scheme.


  203. Allow the payment initiator and beneficiary to receive instant confirmation: Instant confirmation of the payment to the initiator and receiver (end-users) should be done from the bank side as the UPG will be having the traceability of the transaction till it reaches the appropriate member banks. Only member banks will route the actual response to the end-points (delivery channels). Please confirm the understanding.
  204. The transactions conducted through the UPG must be transparent with rich and informative messages for both payer and payee. Hence the UPG shall facilitate exchange of rich information.


  205. Allow PSPs and AIPs to do KYC verification by accessing the respective National Registration databases (for individuals and businesses).
    What is the mode of integration of UPG with National Registration Databases? Is it single or multiple databases? Please specify the number, in case of multiple databases. Whether these databases expose API for UPG to connect?
  206. The mode of integration would be API based. It must allow AIPs and PSPs to connect to National Registration databases (for example: information on individuals through Department of National Registration, legal entities through Ministry of Economic Development and tourists and expatriates through Maldives Immigration). The system must have the capacity to connect to more databases in the future.


  207. Allow multi-factor customer authentication (i.e. password, PIN, tokens, biometrics, OTP). For doing customer's multi-factor authentication UPG should have the customer data of all the Banks.
    This means all banks should mirror their customer's data to the central system which normally Banks will never do. Can you please elaborate on this?
  208. UPG will allow different identification methods and multiple authentication methods. PSPs will allow customers to conduct transactions based on UPG rules.


  209. As a central system if UPG can create settlement reports to facilitate settlement to each member banks, can these banks take care of the actual settlement money transfer?
  210. Clearing module must allow the undertaking of clearing and settlement within the system, without depending on the existing MRTGS system.


  211. For integrating to existing ACH what UPG should do exactly?
  212. The core infrastructure, UPG will be an open, API-based modular system consisting of an account-based, real-time payment system augmented with the functionality of smart addressing. Since it is a separate instant payment system, there will be no direct integration with the ACH.


  213. The UPG must interface with the Clearing Module in real time for validation against clearing and settlement limits. Please specify how the UPG will manage the process. Can you please provide an example for clearing and settlement limit validation happening in the clearing module?
  214. Please refer to the answer provided for question number 109.


  215. The UPG must keep track of every transaction processed by the system with its status for a period of minimum 7 years with a unique time stamp. Please specify how transaction information are stored and how queries and reporting on this data does not affect system performance as specified in Requirement Number MMA-NFR-023.:
    As a central system, the transaction will be logged with unique identifier. UPG must keep track of every transaction processed by the system with its status for a period of minimum 7 years with a unique time stamp.
    Can you please elaborate on this?
  216. This means that the UPG must keep track of every transaction processed by the system with its status for a period of minimum 7 years and each transaction must have a unique time stamp. The Vendor is expected to propose how transaction information are stored.


  217. The UPG must provide MMA with a wide set of enquiries to monitor the status of every transaction processed by the system. Please explain what keys are used for enquires, how the MMA can customized the enquires and how these enquiries will not affect system performance as specified in Requirement Number MMA-NFR-023.: The UPG must provide MMA with a wide set of enquiries to monitor the status of every transaction processed by the system. Request MMA to provide an example/typical scenario for the above statement
  218. MMA will coordinate with the selected Vendor with regard to specifications of enquiries to monitor the status of every transaction.


  219. Participant authentication and authorization status: What is the level of authorization that MMA expects from UPG? In the case of a financial transaction the end-users are supposed to be authorized by the Bank.
    Whether Banks have agreed to duplicate their authorization information to UPG for the authorization?
  220. There will be two types of major players: account information providers (AIPs) and payment service providers (PSPs). AIPs include all institutions that hold customer accounts used in the payment process, either directly or indirectly through a third party. PSPs are institutions that provide payment solutions built on top of the payment infrastructure, possibly utilising the information provided by AIPs.
    UPG will allow different identification methods and multiple authentication methods. PSPs will allow customers to conduct transactions based on UPG rules.


  221. Smart addressing module also demands the mirroring of customer data to the UPG system. Whether the banks will agree to the same?
  222. UPG will only facilitate the PSPs to conduct transactions based on UPG rules. Data will be held at banks. All the participating Banks will make changes if necessary.


  223. The Smart Addressing module must provide MMA with web-based tools to proactively track all addresses and activities within the system. What does level of activities refer to? Please elaborate.
  224. The web-based tools will used by MMA for monitoring. The details of the tools will be discussed with the selected Vendor.


  225. The Smart Addressing module must provide MMA with a wide set of customisable reports for monitoring, and statistical analysis purposes. Will MMA provide the report format that is expected?
  226. The reports are for monitoring, and statistical analysis purposes. The details of the reports will be discussed with the selected Vendor.


  227. Does the clearing module expect anything more than the settlement reports provided to each member of UPG to facilitate settlement?
  228. The clearing is expected to allow the undertaking of clearing and settlement within the system, without depending on the existing MRTGS system.


  229. The Clearing Module must be able to generate settlement instructions in SWIFT FIN standard formats to facilitate automated integration with the MRTGS system. Please explain how this integration would be done.
    Will MMA provide the Swift FIN format to generate settlement instructions?
  230. Clearing Module must be able to generate settlement instructions in SWIFT FIN standard formats. MMA will coordinate with the selected Vendor and ensure the availability of all important details for the integration.


  231. The Clearing Module must be able to generate and export settlement instructions in multiple file formats to be further processed manually into the MRTGS system. Which are the multiple files formats expected by MRTGS system?
  232. Clearing Module must be able to generate and export settlement instructions in multiple file formats such as .xml, .ascii and other standard file formats.


  233. Allow direct participation by having a settlement account at MRTGS or indirect participation by having an agreement with a settlement participant in MRTGS.:
    For the indirect participation by having an agreement with a settlement participant in MRTGS, whether UPG will consider this as any other direct member?
  234. Indirect participants can be considered as any other direct member.


  235. The Digital or virtual bank provides a pre-created account for each entity in the Maldives (i.e. individuals and businesses).
    Whether the bidder is expected to propose Merchant Management System to manage the on boarding of Businesses? Or Whether the Prepaid Card Management System should be integrated with any of the 3rd party system?
  236. The Digital Bank will operate like any other bank and will be connected to UPG. The relevant stakeholders will provide necessary information to the UPG (for example: information on individuals through Department of National Registration, legal entities through Ministry of Economic Development and tourists and expatriates through Maldives Immigration). Hence, this information can be utilized.
    Vendor is expected to include all systems that are deemed necessary to meet the requirement.


  237. If a Bank is fully integrated to UPG, it should allow the banks to opt to use the white labelled solution or the bank's own mobile application to provide the services.
    If the Bank has own mobile application, whether the bidder has to consider the scope for integrating the Prepaid Card Management System with Bank's mobile application or whether the Bank will leverage on their existing Card Management System? How many such banks to be considered for integrating with Prepaid Card Management System?
  238. Please note that the Digital Bank will operate like any other bank and will be connected to UPG. The integration will also be done accordingly.
    The proposed white labelled mobile banking application can be used by AIPs and PSPs to provide services to customers.


  239. Whether the scope for Prepaid Card Management System is restricted only to virtual cards?
  240. Please note that the Digital Bank will operate like any other bank and will be connected to UPG. Since the solution is a local payment scheme, any local scheme cards issued by PSPs can be used for domestic transactions.


  241. Whether the bidder is expected to include the card personalization in scope? If in case Physical cards needs to be issued.
  242. Card personalization is not included in the scope.


  243. Does the digital account issued supports Multiple Currency?
  244. The local scheme will support single currency. That is Maldivian Rufiyaa only.


  245. Whether the bidder is expected to integrate with the Forex agencies for managing the multi-currency cards?
  246. The local scheme will support single currency. That is Maldivian Rufiyaa only. Hence integration with forex agencies is not required.


  247. In the RFI, there was mention on the traveller card for the tourist which can be used for domestic payments, where as in the RFO we do not see that reflecting.
    Can the bidder assume that the issuance of physical cards is not in scope? Kindly acknowledge our understanding.
  248. Issuance of physical card is not included in the scope.


  249. Whether the bidder is expected to propose Payment Gateway which shall be used for topping up the travel cards using international scheme? Or the bidder's Prepaid Card Management Solution should integrate with MMA's Payment Gateway solution?
    What all the schemes to be supported?
  250. Topping up of wallet with international card schemes will be done through the existing banks infrastructure.


  251. Whether the Bidder has to include the authentication and authorization of transactions initiated through the digital account in scope?
  252. Please note that the Digital Bank will operate like any other bank and will be connected to UPG.
    UPG will allow different identification methods and multiple authentication methods. PSPs will allow customers to conduct transactions based on UPG rules.


  253. A client-side API is necessary for participants to have access to the modules. The API must handle all security and integrity requirements: Request Bank to brief in detail with a use case.
  254. MMA will coordinate with the selected Vendor regarding development of the security and integrity requirements of the APIs in accordance with the industry standards.


  255. Whether the Bidder is expected to scope the integration with Card Scheme for transaction processing through Digital Account?
  256. The solution is a local payment scheme which will facilitate transfer of funds between various accounts. Only local scheme cards issued by PSPs will be used for domestic transactions. International schemes will not be used. However, the new system will connect to international schemes via existing banks.


  257. What all the card schemes to be considered in scope?
  258. The solution is a local payment scheme which will facilitate transfer of funds between various accounts. Only local scheme cards issued by PSPs will be used for domestic transactions. International schemes will not be used. However, the new system will connect to international schemes via existing banks.


  259. Whether the bidder is required to consider any card base migration for Prepaid Cards as part of the scope?
  260. The solution is a local payment scheme which will facilitate transfer of funds between various accounts. Only local scheme cards issued by PSPs will be used for domestic transactions. International schemes will not be used. However, the new system will connect to international schemes via existing banks.


  261. Requesting Bank to share the Business Volumes for which Virtual or Digital account needs to be created?
    Is there any YoY projection?
  262. The Digital Bank Module must be able to create a wallet (or virtual account) which can be provided to any customer (Maldivian individual, business, expatriate or tourist). MMA will coordinate with the selected vendor for further data sharing.


  263. What is the number of users expected to manage and maintain the proposed application? Total number of active users? Total number of Concurrent users?
  264. The vendor is expected to propose the solution based on the requirements specified in the RFO.


  265. Whether the Bidder is expected to provide the Mobile Wallet app? If Yes please provide the features to be incorporated in the Wallet app.
  266. Please refer to requirement number MMA-FR-DG-005 of the RFO with details of the requirements for the mobile banking application.


  267. Whether the Solution is required to be integrated with any 3rd party systems to perform KYC procedures? Request bank to list down the 3rd party systems involved.
  268. Please refer to requirement number MMA-FR-UPG-014 of the RFO with details of the requirements for UPG to allow KYC verification.


  269. Whether the digital bank account is required to be accessed through Mobile App?
    The white labelled mobile banking application can be used by AIPs and PSPs to provide services to customers.
  270. Please note that the Digital Bank will operate like any other bank and will be connected to UPG.


  271. Figure 2. Details of the existing infrastructure
    Intra-bank transactions
    Account to account transfers: 9,838,177, Cheques: 1,128,805, Card transactions: 21,375,402, Cash withdrawals: 10,480,316, Direct debits / Standing Orders: 177,806.
    Are these given transaction volumes on monthly basis? Kindly clarify.

    Also, requesting the MMA to provide the number of peak daily and peak hourly transaction volume for the below transactions:
    1. Account to account transfers
    2. Cheques
    3. Card transactions
    4. Cash withdrawals
    5. Direct debits / Standing Orders
    6. MRTGS Transactions
    7. Mobile Payments
    8. Bill Payments
    9. Any other transaction types which are in scope
  272. The statistics given in Figure 2 of the RFO is for one year for the year ended 2018. MMA will coordinate with the selected vendor for further data sharing.


  273. Facilitating the creation of different scenarios for AML in addition to the rules; Is implementation of AML capabilities also part of the scope? Or the system should have AML capabilities as well but is not included as part of the current scope. Kindly clarify.
  274. Please refer to Section 6.6 for AML requirements.


  275. Requirement Number: MMA-FR-FDP-003
    The Fraud Detection and Prevention module must monitor in real-time the spending patterns and statistical data of users, wallets, cards and merchants from various channels, applying customisable business rules with the objective rapidly detect and stop fraudulent or suspicious transactions.
    Requesting the MMA to provide the list of transactional source systems which needs to be integrated with fraud management system.
  276. MMA will coordinate with the selected Vendor with regard to the transactional source systems which needs to be integrated with fraud management system.


  277. Requirement Number: MMA-FR-FDP-003
    The Fraud Detection and Prevention module must monitor in real-time the spending patterns and statistical data of users, wallets, cards and merchants from various channels, applying customisable business rules with the objective rapidly detect and stop fraudulent or suspicious transactions. Please clarify whether real-time fraud prevention is also required?

    If yes, please provide separate list of source systems/channels where real-time fraud prevention and fraud monitoring is required.
    Real-time Monitoring: System continuously monitors all transactions and calculates risk score associated with them in real-time. System flags transactions which are potentially fraudulent but system does not interrupt processing of transaction.
    Real-time Fraud Prevention: System continuously monitors all transactions and calculates risk score associated with them in real-time. Based on the risk score system will be configured to allow/decline/block/hold/challenge transactions.
  278. As detailed in requirement number MMA-FR-FDP-003 The Fraud Detection and Prevention module must monitor in real-time the spending patterns and statistical data of users, wallets, cards and merchants from various channels, applying customisable business rules with the objective rapidly detect and stop fraudulent or suspicious transactions.


  279. Requirement Number: MMA-FR-FDP-009
    The Fraud Detection and Prevention module must be a multi-tenant application with strict segregation of data (customer data, audit logs, master data, security elements etc) between the various AIPs/PSPs using the tool.'
    Please provide number of named users logins required for centralized case management/Investigation team of MMA.
  280. MMA will coordinate with the selected Vendor regarding required user logins


  281. Requirement Number: MMA-FR-FDP-009
    The Fraud Detection and Prevention module must be a multi-tenant application with strict segregation of data (customer data, audit logs, master data, security elements etc) between the various AIPs/PSPs using the tool. Is named users access logins required for member entities as well i.e. AIPs/PSPs, member bank for case management system? Please clarify.
    If yes, then requesting the MMA to provide the number of user access required for each member and total number of such members
  282. MMA will coordinate with the selected Vendor regarding required user access.


  283. Requirement Number: MMA-FR-FDP-009
    The Fraud Detection and Prevention module must be a multi-tenant application with strict segregation of data (customer data, audit logs, master data, security elements etc) between the various AIPs/PSPs using the tool.
    Our understanding is that rule creation for monitoring of transactions is required at central level of MMA only. Kindly confirm if our understanding is correct.
  284. Rule creation shall be available at MMA, AIP and PSP level.


  285. Requirement Number: MMA-FR-FDP-009
    The Fraud Detection and Prevention module must be a multi-tenant application with strict segregation of data (customer data, audit logs, master data, security elements etc) between the various AIPs/PSPs using the tool.
    Is tenant specific rule creation required? i.e. separate rules for each of the member. Please clarify.
  286. As mentioned in requirement number MMA-FR-FDP-009 The Fraud Detection and Prevention module must be a multi-tenant application with strict segregation of data. Hence, specific rule creation shall be available.


  287. The minimum requirements of the description of the proposed solution are:
    a) Availability, Scalability and reliability of the system.
    Please confirm if High availability is required at DC?
  288. MMA will coordinate with the selected Vendor to opt the best available option.


  289. The minimum requirements of the description of the proposed solution are:
    a) Availability, Scalability and reliability of the system.
    Please confirm if High availability is required at DR?
  290. MMA will coordinate with the selected Vendor to opt the best available option.


  291. The minimum requirements of the description of the proposed solution are:
    a) Availability, Scalability and reliability of the system.
    In case high availability is required, requesting the MMA to provide the expected RPO and RTO.
  292. MMA will coordinate with the selected Vendor to opt the best available option.


  293. A complete and detailed Bill of Material for the Hardware and 3rd party software needs for the requested performance, with the following minimum details:
    i. Number and type of servers (CPU, memory, disk type and size, etc.);
    ii. Type and Number of licenses for 3rd party Software (license provider, version, licensing model, etc.).
    Please provide the number of years for which hardware is to be sized.
  294. The vendor is expected to provide price schedule to show total cost of ownership for 10 years. Hence, hardware can be sized accordingly.


  295. A complete and detailed Bill of Material for the Hardware and 3rd party software needs for the requested performance, with the following minimum details:
    i. Number and type of servers (CPU, memory, disk type and size, etc.);
    ii. Type and Number of licenses for 3rd party Software (license provider, version, licensing model, etc.).
    Please provide the transaction volumes with projections for which hardware is to be sized.
  296. As mentioned in the requirement number MMA-NFR-023, The system must be able to handle operation at a minimum of at least 400 transactions / second. Hence, hardware can be sized accordingly.


  297. A complete and detailed Bill of Material for the Hardware and 3rd party software needs for the requested performance, with the following minimum details:
    i. Number and type of servers (CPU, memory, disk type and size, etc.);
    ii. Type and Number of licenses for 3rd party Software (license provider, version, licensing model, etc.).
    Requesting MMA to provide the maximum Hardware utilization % expected?
  298. MMA expects the hardware utilization to be under 75% at any given time.


  299. Requirement Number: MMA-NFR-012
    The system must have a complete DRP and BCP process, with the goal of uninterrupted, 24/7 operation. All incidents must be handled by MMA.
    Requesting MMA to confirm whether implementation at DR site is also in the scope.
  300. Implementation at DR site is also in the scope.


  301. Requirement Number: MMA-NFR-012
    The system must have a complete DRP and BCP process, with the goal of uninterrupted, 24/7 operation. All incidents must be handled by MMA.
    Whether DR to be sized at 100% capacity of the DC. Kindly Clarify.
  302. MMA will cooperate with the selected Vendor in selecting the best available option.


  303. Requirement Number: MMA-NFR-018
    a) In case there is no technological barrier to it, the use of Oracle DB (12C or later) is preferred. Deviation from this is possible after thorough reasoning and discussion.
    Has MMA signed up for EULA (Enterprise Unlimited Licensing Agreement) for Oracle?
  304. Currently MMA does not have EULA (Enterprise Unlimited Licensing Agreement) for Oracle.


  305. Requirement Number: MMA-NFR-036
    Data segmentation must be established between production, staging, QA, test and development environments. The database and all application related storage must be able to support encryption and this must be configurable via parameters. The integrity of all data and program code must be protected.
    Requesting the MMA to provide the list of required environments. i.e. Production, DR, staging, test, development etc.
  306. Requirement number MMA-NFR-036 is self-explanatory.


  307. There is no mention of dispute Management and chargeback in the RFO. Kindly let us know how MMA is planning to achieve the same
  308. Dispute management will be part of the consumer protection regulatory framework. Hence, UPG shall support dispute management and chargeback functionality.


  309. When evaluating costs, the MMA will consider the total cost of ownership (TCO) projected for 5 years, wherein the MMA will devote special attention to license related and other legal risks incurring expense risks (e.g. risk of cancellation, penalties, warranty, adherence to law, and maintenance and support expenses
    We assume the TCO is basis the sum of all costs towards Implementation, Software license, annual maintenance fee, onsite support fee. Request the Client to confirm. Other factors related to Penalties, Warranty, Risks etc will be shared along with detailed terms & conditions.
    Hence, request the MMA to consider only the TCO for commercial evaluation and evaluate other parameters on penalty, risk etc separately.
  310. Evaluation will be carried out in accordance with the Section 5.6 (Evaluation and Award Process) provided in the RFO


  311. Please note that this list is not exhaustive and contains the minimum deliverable related content to be included in the Proposal. The MMA reserves the right to expand the list and include a more detailed list of deliverables in the Contract.
    The commercials to be quoted will be basis the list of Deliverables mentioned herein section 5.7.2. Any scope increase or additional deliverable will have additional charges to be mutually discussed and agreed.
  312. A detailed list of deliverables will be finalized and included in the Contract which can only reviewed on an agreed basis.


  313. We assume the MMA will take care of arrangement for the training and bear all the expenses at actuals. Request the MMA to confirm.
  314. MMA will make all arrangement for the training and bear all associated costs.


  315. We assume the MMA will take care of the necessary Hardware such as Servers, Storage, SAN, and Database software's. Request the MMA to confirm.
  316. MMA will procure the necessary Hardware.


  317. Provide onsite support for 6 months. We assume that the MMA will take care of providing the workstation, telephone and other necessary infrastructure for the resources at its own cost. The Bidder will mention the number of resources to be deployed during On-site support. Request the MMA to confirm.
  318. MMA will provide the workstation, telephone and other arrangement of the work space for the onsite support staff.


  319. Provide required training for the functional and technical team. We assume that the MMA will take care of arrangement for the training and bear all the expenses at actuals. Request the MMA to confirm.
  320. MMA will make all the administrative arrangements.


  321. The vendor must provide a full description of the training sessions including the length and the maximum attendee's number. After training sessions, further consultation and on-site support might be needed, please include these options in the Pricing
    We assume the Bidder can create additional rows in Appendix B to quote indicative cost for training.
    Request MMA to confirm.
  322. Yes. Bidder can list down the cost for training in the Pricing Table (Appendix B)


  323. The MMA expects the vendor to offer 24/7/365 post go-live support for the delivered system under terms of a contract for an indefinite period. We assume that the post go-live support can be managed from Bidder's premises in India. Request the MMA to confirm.
  324. With reference to Subsection 7.4.2 The MMA expects the vendor to offer 24/7/365 post go-live support. The requirement can be met from any of the Vendor's establishments.


  325. 6 months Special post go-live support including 4 weeks post go-live on-site presence and off-site priority support
    We assume the post go-live support can be managed from Bidder's premises in India. Request the MMA to confirm.
  326. With reference to Subsection 7.4.2 The MMA expects the vendor to offer 6 months Special post go-live support including 4 weeks post go-live on-site presence and off-site priority support. The requirement can be met from any of the Vendor's establishments.


  327. General post go-live support and maintenance services including, but not limited to providing an online, secure ticketing system, remote troubleshooting, installation and updating assistance, and usability assistance etc. for a period of five (5) years.
    We assume that the MMA bear the costs of establishing connectivity between the MMA networks. Request the MMA to confirm.
  328. MMA will bear the costs of establishing connectivity between the MMA networks.


  329. A hotline service for incident management purposes. We assume that the MMA bear the costs of establishing connectivity between the MMA and Bidders contact centre and the telephone network. Request the MMA to confirm.
  330. The Subsection 7.4.2 requires the support service to include a hotline service for incident management purposes. Hence, the Vendor is expected to facilitate this and the Vendor may propose alternate mediums for incident management. Hotline may not be a toll free number.


  331. A support package covering developments related to minor changes in the system related to functionality, performance, usability or security issues, as well as changes in the regulatory environment. The vendor should define a quarterly FTE-cap for support services under this service element. We assume that the MMA will pay for additional customization basis the man day rates quoted, beyond the quarterly FTE cap.
  332. Fees can be agreed during contract negotiations.


  333. An Account or Support Manager with agreed SLA and escalation procedures to vendor executives. We assume that the Account manager can be at Bidder's premises and this cost has to be included in the support cost. Request the MMA to confirm.
  334. Account or Support Manager can be stationed at Bidder's premises.


  335. The costs will include reimbursable expenses. Request MMA to keep the reimbursable expenses out of TCO calculation as this will be paid at actuals. Also request the MMA to specify the kind of reimbursable expenses. Does the training, travel related expenses considered under this?
  336. Reimbursable expenses include all expenses which must be borne by MMA in accordance with the terms of contract.


  337. The MMA will not be held responsible for any government taxes and/or levies. Vendors are expected to take this into consideration
    Request MMA to consider the commercials excluding the Taxes, as it will be paid at actuals by the MMA.
  338. Under the current tax regime MMA is exempted from paying withholding tax. Hence, no taxes are applicable.


  339. Implementation, software license and support service costs should be presented in different worksheets of Appendix B (Pricing Table).
    The Appendix B shows only TWO tables for Implementation cost, SW license & support fees. Request the MMA to provide illustrate how the TCO will be calculated basis these tables and does it include other expenses such as training, man days rates etc.
  340. The bidder is free to make changes to the template in Appendix B (Pricing Table) and list down any additional details.


  341. Implementation, software license and support service costs should be presented in different worksheets of Appendix B (Pricing Table).
    We assume the Support service cost and Annual maintenance cost includes for the all Software licenses. Request the MMA to confirm
  342. The bidder is free to make changes to the template in Appendix B (Pricing Table) and list down any additional details.


  343. The vendors are expected to propose a turnkey price including all costs (including but not limited to licenses, implementation services, travel and accommodation). The MMA will not accept any hidden and/or additional costs; the financial proposal should be comprehensive and all inclusive. The Appendix B shows only TWO tables for Implementation cost, SW license & support fees. Request the MMA to provide illustrate how the TCO will be calculated basis these tables and does it include other expenses such as training, man days rates etc.
    We assume the Bidder is free to make changes to the Appendix B template to add, modify, delete rows to arrive at the TCO
  344. The bidder is free to make changes to the template in Appendix B (Pricing Table) and list down any additional details.


  345. Please provide separate prices for every project phase.
    We assume this clause corresponds to implementation costs. Request the MMA to consider cost for entire project and not in phases.
  346. Vendor is expected to provide separate prices for every project phase. Evaluation will be carried out in accordance with Section 5.6 (d).


  347. Software license fees should be presented for each year during the period after go-live, under terms of the vendors license policy. The MMA prefers a model where the license fee is invoiced in a single payment.
    While this clause asks for license fees for each year, the invoice is mentioned for single payment. We assume the Bidder can freely quote for any option of term license with annual maintenance fee - for example, the Bidder can quote upfront payable License fee for 5 years and AMC payable annually
  348. Annual maintenance fee must be mentioned. Vendor can freely quote for any other option of term license with annual maintenance fee.


  349. The vendor is expected to present the cost estimation of the delivered solution's software license fee (including customisations) considering that the software source codes, along with consequent versions and patches, as well as all relevant documentation, are placed in custody at a solicitor approved by both the MMA and the vendor. Source code is only released to the MMA under special contractual terms to be later agreed upon. The bidder is agreeing to have the source code at escrow account. Any other detailed terms and legal clauses can be mutually discussed and agreed at later stages of contract
  350. MMA acknowledges the statement.


  351. We assume the Annual maintenance cost includes for all the Software licenses. Request the MMA to confirm
  352. Annual maintenance fee includes the Vendor software only.


  353. We assume the TCO is basis the sum of all costs towards Implementation, Software license, annual maintenance fee, onsite support fee. In other sections of RFP, MMA expects to quote for Training, man/days rates for additional customization. Does the TCO also includes these items, or only the items mentioned in the Appendix B. Request the Client to confirm?
  354. TCO includes the items included in Appendix B only. Vendors are expected to provide other details separately.


  355. We assume any other costs to be incurred towards Interchange fees, card scheme certification etc will be separately billed as per terms to be mutually discussed and agreed.
  356. The solution is a local payment scheme which will facilitate transfer of funds between various accounts. Only local scheme cards issued by PSPs will be used for domestic transactions. For International card schemes the gateways of existing commercial banks will be used.


  357. Request the MMA to share the projected volumes over the next 5 years for the virtual or digital account, number of users.
  358. Please refer to the answer provided for question number 134.


  359. We assume that cards shall be used to top-up the SVA of the Digital Bank using the card payment gateway available on Bank side. What is the reason of supporting the protocol ISO 8583 by the UPG?
  360. Multiple messaging standards are required to allow all participants to integrate seamlessly with UPG.


  361. Is it correct to assume that a single Digital Bank shall be available in the country and configured into the system? The digital bank shall be different from the existing Bank.
  362. Please note that the Digital Bank will operate like any other bank and will be connected to UPG.


  363. Could you please provide the list of Swift FIN messages supported by MRTGS, which can be suitable for the communication with UPG?
  364. MRTGS system supports standard SWIFT FIN messages. MMA will coordinate with the selected vendor and provide details to facilitate integration.


  365. Referring to paragraph 7.5 point d) Could you please indicate what taxes/levies Vendors are expected to take into consideration? Could you please make some example and values of the taxes (i.e. % of invoices)
  366. Under the current tax regime MMA is exempted from paying withholding tax. Hence, no taxes are applicable.


  367. MMA-FR-UPG-007: The UPG must allow the management of Corporate Payments
    Could you please elaborate on what is expected in Corporate payments management feature ' as there are key differences and aspects from retail payments?
    Is the expected solution required to manage the differences in payment message fields, payment message processing (e.g. multi user approval), any other?
  368. The UPG will be an open, API-based modular system consisting of an account-based, real-time payment system augmented with the functionality of smart addressing. PSP will provide the services to both retail and corporate customers. The UPG must support any differences in retails and corporate payment messages.


  369. MMA-FR-DG-008 : The Digital Bank mobile application module must be compatible with Android & iOS Mobile phones.
    Could you please specify from which version (Android and iOS) upwards the mobile app must be compatible?
  370. Please refer to the answer provided for question number 84.


  371. MMA-FR-DG-009 : The Digital Bank mobile application module must allow multi-factor customer authentication (i.e. password, PIN, tokens, biometrics, OTP).
    Please clarify that MMA-FR-DG-009 requires functionality for integration/enablement of multi-factor customer authentication executed by other solutions like OS of Android, iOS, web-bank login solutions and similar user/customer authentication solutions?
  372. It is not a mandatory. However, the Vendor may propose to include multi-factor customer authentication executed by other solutions.


  373. Will you be issuing the response template (pages 29-58) in a Word Format for us to complete or do we need to recreate it ourselves?
  374. The RFO is published in searchable PDF format for ease of use by the Vendor in the preparation of the proposals.


  375. In section 5.4.3: you lay out the requirements for the physical bid submission. How do you want us to replicate that with the soft copies? We could send up to 4 emails with password protected pdf's of the Technical and Financial proposals and respective passwords separately. Would they all go to the same email address or to separate addresses to preserve integrity of process?
  376. The soft copy of only the Technical proposals is required to be sent via email.


  377. You also request searchable pdf formats. We propose to do that via graphic initialization of every page. To do otherwise might affect the image quality and render the pdf unsearchable. Are you content with that?
  378. The soft copy of only the Technical proposals is required to be sent via email. Graphic initialization or digital company seal would be sufficient.


  379. What do you mean by a firm signature in respect of the soft copy? Do you mean a secure electronic signature or simply a scanned signature of the document by an officer of the Company?
  380. The soft copy of only the Technical proposals is required to be sent via email. Graphic initialization or digital company seal would be sufficient.


  381. In section 5.4.3. it is mentioned that the submitted PDF documents need to be in searchable PDF format and that they need to be signed with firm signature and all pages should be initialized. We assume that this means a digital Company Seal is to be placed on the first page of every document and a digital signature is to be placed on all the subsequent pages. Please clarify. For the hard copy there is no such condition. Please clarify.
  382. The soft copy of only the Technical proposals is required to be sent via email. Graphic initialization or digital company seal would be sufficient.


  383. In section 3.3, it is mentioned that MMA expect to launch the first services 9 months after the procurement contract? What are the first services mentioned above?
  384. It means the system must be ready to serve customers in 9 months.


  385. For domestic settlement, does the bank hold settlement (vostro nostro) account in the Central Bank (MMA)?
  386. Each bank maintains a settlement account at the central bank.


  387. Could you share the settlement workflow for MRTGS and ACH in Maldives?
  388. Figure 3 in Subsection 4.3.1 of the RFO shows the Inter-bank Clearing and Settlement System (MRTGS and ACH).


  389. What are the reasons that banks are not yet integrated to the system? And how have they been managing the payments without the integration to the system?
  390. The volume of interbank transactions are comparatively low. Hence, they are able to manage it manually even though systems are not fully integrated with some of the participating banks.


  391. What are the government payments in Maldives? Is it possible to provide a list and type of submission?
  392. Please refer to paragraph 3 under Subsection 4.3.3 for details.


  393. Bill Payment. Considering that Maldives has 100% mobile network coverage, what are the reasons that the residence in island communities do not utilize the existing mobile banking for bill payments?
  394. As mentioned in the RFO the main reason is the limited availability of electronic payment services in the island communities.


  395. What is 'Request to Pay' feature mentioned in section 6.2 and when is it used?
  396. This feature will allow the payee to request instant payments rather than payer initiating the transaction.


  397. To our understanding Settlement is managed by the MRTGS system in Maldives, however there is a contradiction in section 6.4 where it mentioned that 'i) Allow the undertaking of clearing and settlement within the system, without depending on the existing MRTGS system'. Could please elaborate more on this point? (Related to MMA-FR-CL-012 as well)
  398. The Clearing Module must support clearing and settlement within the system, without depending on the existing MRTGS system. Vendor may propose to use MRTGS or alternate solution for settlement.


  399. What kind of liquidity management is expected for the direct participants of Clearing system?
  400. The system must be capable to perform any kind of liquidity management.


  401. In requirement number MMA-FR-UPG-006, ' payments initiated by both the sender (initiator) and the receiver (beneficiary)'. Does this mean that receiver could also initiate payment (similar to direct debit)? If yes, could you please provide us with a use case for this requirement? Are there any specific use cases?
  402. Yes. Pull payments. Please refer to question no 11 for more details


  403. Requirement MMA-FR-UPG-007, how is Corporate Payments different from Consumer Payments? For instance, B2B usually has different requirements, like an extra line on statements for tax details, think level 2 / 3 data in payments terms.
  404. Please refer to the answer provided for question number 187.


  405. Requirement MMA-FR-UPG-011, are the channels provided by PSP, UPG or could be both? Kindly outline the channels available. Please clarify the additional formats. If UPG is expected to provide the channels as well, is it within the scope of the vendor as well?
  406. The solution is a local payment scheme will facilitate transfer of funds between various accounts. It will allow users to make payments via different channels including but not limited to mobile app, web, kiosks, smart devices, and schemes. The PSPs will provide payment solutions at lower level to the end user.


  407. Requirement MMA-FR-UPG-015, what are the 'various interfaces' mentioned in the requirement?
  408. This means it will allow users to access via different channels including but not limited to mobile app, web, kiosks, smart devices, and schemes.


  409. Requirement MMA-FR-UPG-017, is the Clearing Module an existing system or a module that is expected to be delivered in UPG? Kindly outline the process available.
  410. The Clearing Module must allow real-time multilateral net clearing between the participants.


  411. Requirement MMA-FR-CL-008 & MMA-FR-CL-008, is the limit set for the participants (Bank), PSP, or each consumer? If the limit is set to each customer, do the customers have one limit across PSPs?
  412. This will be decided based on the system rules.


  413. Requirement MMA-FR-DG-005
    What is 'Transfer Money Wallet-to-card'? Is it the same as credit card payment? In issuing terms you would attach one or more wallet accounts (mobile payments) to a customer account, with a load option to send money to the wallet / card. If a wallet gets closed the funds need to be unloaded (send back to the account) needs to be qualified
    What is 'Collect Money'? Can method and processes need to be specified?
  414. The new system is a local payment scheme which will facilitate transfer of funds between various accounts. The white labelled mobile banking application will allow transactions through the local scheme. These functions will be used by the PSPs to provide payment solutions at lower level to the end user. Collect money refers to the Pull Payment function.


  415. We did see the fraud detection mentioned in the description, but not in the specifics of the RFO. Only 6.6. mentions fraud, and only in a data security context. Our assumption would be that payment processing may be added at a later stage, since no specific request is included. Is this correct?
  416. Fraud Detection and Prevention is detailed in the Subsection 7.2.6.


  417. Can we answer the RFP in excel format - with the requirement numbers, Solution compliance and description as the fields?
  418. The Vendor may choose to compile the proposal in any format. The submission shall be in accordance with Section 5.4.


  419. For system maintenance and upgrade, do you plan to have any outage times or should the system be Active-Active?
  420. The system be Active-Active.


  421. Depositing the code as part of an escrow, is that part of RFO submission or once the contract is awarded?
  422. The selected has to deposit the source code (source code escrow).


  423. Is this functionality supported via APIs or some Web GUI/ Mobile App -Should support 'Request to Pay' as an overlay, and allow users to add additional information or reason codes such as 'Can't Pay', 'Can only Pay x', 'Will pay on a specific date', so that the requestor is informed why the payment has not been made.
  424. The UPG will be an open, API-based modular system consisting of an account-based, real-time payment system augmented with the functionality of smart addressing. PSPs will connect to UPG via APIs and provide the services to the users. The UPG must allow the PSPs to use the functionality specified in the question.


  425. For Fraud, Security and Monitoring - Does MMA already have a tool for this? Nanopay
  426. The functional requirements for the fraud detection and prevention of the new solution are detailed in Subsection 7.2.6.


  427. For Support - Does MMA already have a tool for this?
  428. Please refer to section 6.7 of the RFO for details related to support and maintenance


  429. For Differed net settlement, would UPG only sending reports to banks and banks will move the actual money end of the day or will UPG also facilitating movement of money between the banks?
  430. Clearing module must allow the undertaking of clearing and settlement within the system, without depending on the existing MRTGS system.


  431. With regard to requirement number MMA-FR-DG-005, what languages are expected to be available in application?
  432. The application shall be in English language and shall support customization to local language.


Read more

Request for Information (RFI)

RFI Initial Issue


Maldives Monetary Authority (MMA) has issued a Request for Information (RFI) with the objective of obtaining information about prospective vendors’ capabilities, potential solutions and the costs involved to fulfil the vision of the Maldives Payment System Development Project.


MMA invites all interested parties to submit a written response to this RFI. A copy of the RFI is available on MMA's website (www.mma.gov.mv) and from the links below:


First Amendment to the RFI


First Amendment to the RFI was done on 28th February 2019 to extend the deadlines. The revised deadlines for registration and submission of response are as follows:

  • Deadline for registration: Deadline for registration: 21st March 2019, 16:00hrs Maldives time
  • Deadline to submit response to the RFI: 4th April 2019, 16:00hrs Maldives time


Related Documents


  1st Ammendment to RFI  28 February 2019

  Request for Information  31 January 2019

  Presentation Slides with Explanatory Notes  7 March 2019


Frequently Asked Questions from RFI Respondents

This includes responses to all questions received via email and questions asked during the information sessions.


    Updated 25 March 2019
  1. Right now everyone has a national ID? Do you have a separate voters ID?
  2. All Maldivians have a unique national ID which is used as a primary identification to obtain any service from any institution. National ID is used as voters ID.


  3. Is the national ID linked to mobile number?
  4. No


  5. Is the bank account linked to the mobile number?
  6. Bank accounts are not linked to a mobile number.


    Updated 7 March 2019
  7. How is the demographic profile of Maldives?
  8. The population of Maldives is 402,071, which is dispersed across 188 administrative islands. The most densely populated island is Male’, the capital city, with 38% of the population living there. Only two islands have a population of over 10,000 where as a majority of islands have a population of less than 1000 citizens.For more details please visit the following pages:

        The Statistical Yearbook of Maldives

        Visit Maldives


  9. Can the payment providers be as many as you want to? And do they have to be licensed?
  10. Only licensed payment service providers can offer payment services to the Maldivians. And MMA will license these parties in accordance with the necessary regulations.


  11. From the business case point of view, since the (cost of the) system is going to be very high, do you plan to charge back the banks?
  12. The whole project will be funded by MMA. The fees/charges for UPG will be nominal. Revenue from these fees to be shared with the banks could be a potential option.


  13. The final selection of vendors will be purely on the commercial or will it include technical as well?
  14. Final evaluation will be based on the technical as well as the commercial aspect. It will not solely depend on the commercial aspect.


  15. How much time will it take for reviewing the RFI responses?
  16. Based on the RFI responses we are hoping to finalize our requirements and publish a Request for Offer (RFO) by end of April


  17. As the proposal includes some confidential information, can we sign a NDA with the MMA?
  18. Yes. If the vendors request, it can be arranged.


  19. It’s mentioned that all the banks in Maldives will take part in this payment infrastructure, but currently not all the banks are fully integrated to the MRTGS. So is the new infrastructure expected to solve this?
  20. It is open for vendors to propose a solution for settlement, which minimizes the dependency on legacy systems.

  21. Are the insurance companies expected to be integrated into the system as well?
  22. The insurance companies may offer payment service through their selected payment service provider. This is not included in the current scope of RFI


  23. There shall be only one single mobile app for the entire ecosystem or all the banks are enabled to provide their own interoperable mobile apps?
  24. A common white label app can be proposed or the banks may use their own proprietary app. Banks will function as account information service providers. Banks can be both Account Information Service Providers as well as Payment Service Providers.


  25. Is it correct to say that user credentials for authentication and authorization (with exception for the first access) will be checked by the PSP on behalf of the Bank hosting the Account?
  26. Yes. It will be done by the Payment Service Providers via the UPG.


  27. Could you please let us know if you are available to consider both products to be installed in the Maldives and services provided from abroad?
  28. All products must be installed and all services must be provided from Maldives. However, vendors may propose other alternatives.

  29. Our understanding is that the proposed solution should only include the Software layer and that the hardware components are not included in the scope. Could you please confirm the same?
  30. The scope of the RFI is for the software only. However, the vendors may propose the hardware requirements/specifications.


  31. Could you please advise if we need to include the database license in our offer?
  32. No.


  33. Please advise if we will directly integrate with the different Mobile Operators or with an 1 single aggregator.
  34. It is open to vendors to propose an appropriate solution. PSPs are required to integrate with UPG and a mobile operator can act as a PSP. As in RFI, ISO20022 messaging format will be used in the UPG.


  35. Could you please clarify the role and the content of National Registration databases?
  36. The National Registration database was officially launched by the Government 1984. This database will provide the identifiers and biometric data to the Unified Payment Gateway.


  37. Please advice on the 3rd party Biometrics system we will integrate with.
  38. The UPG will be connected to the National Registration Databases (and other registration databases at a later stage) via APIs for biometric verifications.


  39. What is the information already available in the national DBs?
  40. The national registration database is a register of all citizen of Maldives. It contains basic details of all citizens and biometric data is available partially. We are currently working with the relevant authorities to improve the available biometric data.


  41. What is the annual volume projection for the proposed Instant Payments system?
  42. It must be able to handle 31 million transactions per year as an indicative scale. The system should be scalable to cater 10-80 times of the stated transaction volume as it evolves over time.


  43. If I were a member, I’ll be sending the account information to UPG but will the bank still be authorizing the transaction? If the bank is not connected to the UPG, how will the transaction be authorized?
  44. Yes. A bank can act as an AISP and PSP as well. In case where a bank is not integrated to UPG at API level, it can authorize the transactions manually. Vendors may propose a separate interface for that.


  45. So basically you’re building an infrastructure platform that can allow all the different service providers that are already in the market to connect to it? And on top of that you will also introduce a user based accounting, within this network that can allow you to store money and move it freely between different participating bodies?
  46. Yes.

  47. Do you have a digital bank right now?
  48. MMA plans to introduce digital/virtual bank which will have a common stored value account for each entity in the Maldives (i.e. individuals and businesses) which is planned to be operated by an entity designated by MMA


  49. Will the digital bank be used only for those banks that are not integrated with UPG?
  50. It can be used by the banks integrated to UPG as well.


  51. In case of one single mobile app, is it correct to say that all the brand-new Stored Value Accounts will be hosted by the Central Bank?
  52. The stored value accounts will be hosted by a designated entity by MMA.


  53. Can the store value account or wallet top up be done with cash? If not, how to add funds if we don’t have a bank account?
  54. No. Cash top-ups are strongly discouraged. There are other ways to top-up the wallet like receiving incoming funds from other accounts, depositing the social security benefits from the government to this account.


  55. Will the top-up of wallet or Store Value Account be possible from agent shops?
  56. No.


  57. Do you foresee the possibility to recharge the SVA with cash in enabled shops?
  58. No.


  59. Top-up of wallet or Store Value Account will only be done on app using the cards?
  60. It is not limited to cards.


  61. Are there any fees for the consumer at time of a top-up of the SVA with a payment card?
  62. Fees will be decided based on the rules which is yet to be finalized.


  63. For the unbanked customers, if they don’t have a bank account how do they put money in the wallet?
  64. They idea is that they will receive money from another customer to their stored value account in the digital bank. There will be some limitations on type and value of transactions that unbanked customers can make. If an unbanked customer wants to deposit funds and use the full services, a bank account is required to be opened and complete full KYC verification.


  65. What is the main purpose of the tourist solution?
  66. The reason we are interested in tourist solution is that recently a lot of guesthouses has been opened in the local islands (unlike one island one resort concept) mainly targeted for budget travelers. Since these are small scale businesses it is not practical to put POS machines which supports all international schemes in each and every location.


  67. How will the tourist top up their store value account or wallet if they cannot use cash to do that?
  68. Tourists can top up the store value accounts using their international card schemes. Even though UPG is not directly connected to the international card schemes, it will be possible via the existing commercial bank’s card networks.


  69. Does that mean tourist can use the international card to top up the local card and use it within Maldives?
  70. Yes. However, the solution for tourists is not limited to local cards only.


  71. What is the number of tourist per year?
  72. It is around 1.2 million tourists per year which is expected to increase in the coming years. For more details, please visit the following page:
       Statistical Yearbook of Maldives 2018


  73. For topping up the tourists, will you be using international schemes through the existing banks?
  74. Yes. Tourists can top up the store value accounts using their international card schemes via the existing commercial bank’s card networks. At this stage, we don’t have the intention to incorporate the international schemes to the UPG, but at later stage, if the need arises, we will definitely consider that. So the option for international scheme must be available.


  75. For tourist transactions, will MMA be acquiring for all tourist transactions or have multiple banks doing it?
  76. MMA will not be investing in international switch. We will be using existing commercial bank’s card networks.


  77. Will the tourist be enabled to request a SVA/Wallet activation through a full online KYC procedure? (i.e. upload of ID photos, selfie, etc).
  78. No. Our idea is to do the KYC of the tourists on arrival.


  79. At the end of temporary residency period in the Maldives, can the tourist/foreigner request a refund for the remaining amount in the SVA/Wallet? (I.e. through a partial refund on the payment card used for the top-up or cash return)
  80. Yes. It can be enabled.


  81. In our understanding Kiosk is not part of this RFI. Is it?
  82. The scope of the RFI is for the software only.


  83. Can you tell a little bit more about the functionalities of the Kiosk?
  84. The population of Maldives is dispersed across around 200 islands where majority of the islands with a population below 1000. There are no bank branches in each and every island. If we can introduce a Kiosk in each and every Island, people can use it. For example, if they install an app, this Kiosk can be used for KYC verification. This channel can be used to create confidence among the people to the system. Kiosk must accept different kind of identification and authentication. Including biometrics such as fingerprint or even cards. It can also be used to make high value payments. For example people without smart phones can initiate large transfers with multi factor authentication using these machines. In simple terms, Kiosks could be a smart ATM without cash.


  85. Could you please describe in more details the Kiosk use cases?
  86. Self-service terminals / kiosks will be available in all inhabited islands at convenient locations, mainly to facilitate Know-Your-Customer procedures via biometric verification or any other identifiers. Apart from this, all payment services that can be availed from the digital solution will be available through the self-service terminals. Eg: Users registered online or via mobile apps can do the basic KYC through these terminals.


  87. What is the use of a Kiosk for the tourist?
  88. For example, in resorts or islands where people offer services (i.e. sea sports) such as lending surf boards or other sea sports activities, the kiosks can be used select the service and make payment.


  89. Is the kiosk connected to a central repository containing the fingerprint of all Maldivians? If not, could you please clarify what is the repository for the fingerprints?
  90. The Kiosk will be connected to the Unified Payment Gateway (UPG). UPG will get the details of the fingerprints via the National Registration database.


  91. Is the kiosk able to authenticate tourists via biometric verification? (i.e. through the biometric info collected at the airport)
  92. Yes. Such arrangements will be made in the future.


    Updated 20 February 2019
  93. What would be the expected presentation duration?
  94. No specific time duration. Ideally less than an hour.


  95. Will it be possible to demonstrate the solution remotely while our representative is present on site?
  96. Yes. Arrangements can be made.


  97. Will you be able to identify key points that should be covered during this presentation/demonstration?
  98. Key points to be covered are highlighted in Section 8.2 of the RFI.


  99. Will it be possible to receive RFI copy in MS Word format to facilitate answers preparation?
  100. Yes.


  101. If we are restricted in our response to the RFI due to commercial partnerships, can we respond to the RFO if our partner does not get through the RFI stage gate to the RFO phase?
  102. Submission of offer to RFO is limited to the vendors registered through the response to the RFI only.


    Updated 12 February 2019
  103. For the requested payment gateway that will be used for the local internet payment, are you looking for a solution that will manage the international cards like Visa, MasterCard, etc. as well? I.e. card switch system?  
  104. The payment gateway must support all local schemes and should be capable of connecting all international schemes.


  105. For the fingerprint authentication, are you looking for a system to store and validate fingerprints for all customers, or there is a third party that we will connect to and validate the customer? Can you please provide more details on the business case?
  106. The fingerprint verification would be provided by a third party.


  107. For the solution for tourists, what is the business value for giving the tourist smart cards? Can this be replaced by opening a mobile wallet for them?
  108. It is not limited to smart cards. You may propose mobile wallets or any other solution.


  109. For the requested costs, our system is priced in different schemes; can we use our pricing model? And are you only looking for the implementation cost at this point without the licenses cost?
  110. You may use your pricing model. We want to know both the implementation and licenses cost.


  111. The project is divided into three parts and according to the anticipated timeline, the implementation is to be finished in 4 months; Are you looking to implement the three parts within the 4 months?
  112. Yes. Full scope of the RFI is to be implemented in the given time frame. However, you may propose an alternate time frame.


  113. We are an international company that we have many country-wide implementations, will you require a local partner\company in Maldives for the chosen vendor?
  114. A local partner is not required. However there are no restrictions for you to affiliate with a local partner.


  115. We note the opportunity to visit MMA to present our solution. The timeline you provide indicates that that is an opportunity ahead of the RFI response. Please confirm that is the case and whether the opportunity is for a physical visit or a teleconference or both. Please also provide suitable dates.
  116. The opportunity is for both physical visit and teleconference. However, we would prefer if the Vendor visits MMA for the presentation.


  117. I have gone through the RFI today and can see that the tool we provide would certainly fulfil the message validation/transformation side but the tool does not currently offer some other aspects of the solution that you wish to see (i.e. KYC, Clearing, Fraud Detection) that would be performed by a payment solution or orchestration tool that would sit outside of our system. We do work with vendors that use our system as part of their payment solution and would be delighted to give you their details in case you would like them to submit to the RFI (if they already are not being asked) or we are happy to provide information on our system for this RFI but I believe your scope will require more functionality then just the elements in our system.
  118. Appreciate if you could share the details of the RFI with those Vendors so that they may participate in the RFI as well.


  119. Would it be possible to set up a quick call to talk about this in more detail?
  120. We can make arrangements for a conference call if you could please provide your contact details.


Read more