Consultant: PIRI Regional Regulatory Sandbox Digital Portal

1. Alliance for Financial Inclusion (AFI) & Project Background

The Alliance for Financial Inclusion (AFI) is a unique international network of central banks, ministries of finance and economy, and other regulatory bodies which hold the mandate to develop and implement financial inclusion policies. Our aim is to do so through our mission of empowering financial regulators and policymakers to increase access and usage to quality financial services for the most underserved and unserved populations.

The Pacific Islands Regional Initiative (PIRI), made up of 8 central banks within the Alliance for Financial Inclusion (AFI) network launched the fintech for financial inclusion regional workstream at the 4th high-level PIRI meeting in Samoa in June 2018. As part of the workstream, PIRI members committed to the development and collective operation of a regional regulatory sandbox dedicated to promoting financial inclusion through innovative approaches to the design, promotion and delivery of digital financial services and technology-led solutions to the availability, access, usage and quality of financial services across all segments, but particularly, the vulnerable including women, youth, elderly, and MSMEs in market and industry segments such as farming, tourism, retail shopping and commerce, fishing, etc.

To this end, the PIRI regional regulatory sandbox will be established and provisioned on a portal – a web service. Where interested, potential and active applicants from across the world can access relevant information, submit enquiries, initiate their applications, receive updates, and engage with the participating central banks. The portal would also serve as a platform for the participating central banks to share and collaborate with one another, collectively engage and formally communicate with prospective applicants as a regional body.

2. Overall Objective:

The PIRI Regional Regulatory Sandbox Digital Portal (referred to as “Sandbox Portal”) is a common regional and synchronous platform developed and deployed over the web with the aim to facilitate the exchange between 3 categories of users, namely:

• General Public – be a depository with relevant yet succinct information about the regulatory sandbox, the participating countries and their key areas of interest, and the guidelines for participating in the sandbox
• Applicant – facilitate the seamless enquiry, application, and engagement by prospective applicants to the regional sandbox
• Participating Central banks – To simplify coordination, feedback, communication, and exchange between regulator and applicant, and participating regulators / central banks.

The portal is expected uphold strict data protection standards in managing access rights and user privileges, data retrieval, storage and archiving, by ensuring only appointed, pre-authorized users perform only specifically assigned roles and functions regarding the use of the portal.

The portal should be designed with scale and future integration (via APIs) in mind, highest level of security and should be highly intuitive ensuring ease of navigation and use by both applicants and regulators.

3. Definitions:

The following are definitions for abbreviations and other jargon used in this document:

PIRI – Pacific Islands Regional Initiative representing 8 member countries
AFI – Alliance for Financial Inclusion
Sandbox Portal – PIRI Regional Regulatory Sandbox Digital Portal Application
API – Application Programming Interface
TA – Technical Administrator – Designated portal technical administrator
IIT – In-country Implementation Team
HLSC – High-level Steering Committee
SA – Super Administrator – designated technical administrator
Institution – Member institution and / or participating central banks
Guidelines – PIRI Regional Regulatory Sandbox Guidelines

4. Intended Audience:

This document is targeted for the following audience to have a better overview of Sandbox Portal application.

1. Solution Architect
2. Project Managers
3. Design UX/UI Team
4. Development Team
5. Testing Team

5. User Categories

The Sandbox Portal shall be utilized by the following users based on scope defined in their access privileges.
I. Institutions, Example:
a. Monetary Authority – Primary portal application owner through the technical administrator
b. Observer e.g. Alliance for Financial Inclusion (AFI)
c. Regional Committee – which is made up of selected central banks’ representatives, providing governance, recommendations, and oversight to the operations of the sandbox process

II. Monetary Authority Employees – Assigned to an Institution acting in various roles such as:
a. Technical Administrator – Acts as the administrator and manages the portal on behalf of the institutions with create, read, edit, delete etc functions
b. In-country implementation team: to fulfil application receipt, assessment, evaluation, recommendation etc. with privileges as specifically assigned by the TA

III. Applicants – which can be classified as a business (but represented by a person) or individual. Examples includes, financial institutions, e-money issuers, non-bank financial institutions, financial technology (FinTechs) entities and any other service provider relevant to the definitions and scope provided in the guidelines.

IV. General Public: This is the general public and stakeholders with access to the general information sections of the website and also interact with the central banks through enquiries and suggestions etc.

6. Delivery Channel:

The Sandbox Portal shall be designed and built as a secured (SSL certificate) web application accessible on any web browser including Chrome, Firefox, Edge / Explorer and any other commonplace browser with the server / database hosted on a trusted cloud service.

7. Technical Requirements:

The platform shall contain modules such as detailed below. We encourage consideration in design to accommodate flexibility to create and add future modules in the future.

i. General Information Webpage
ii. Dashboard
iii. Institution Management
iv. User Management
v. Application Module – General Regional Level Questions and Country Specific Questions Modules
vi. Applicant Management
vii. Application Review Module
viii. Notification
ix. Reporting Module7.1 General Information Webpage

This is the landing webpage and associated sub-pages providing the general public, applicants and visitors to the website with succinct information about the central banks , the regional regulatory sandbox, PIRI, cohorts information – summary information about applicants participating in the sandbox, blogs or news thread etc.

Information on the central banks can be culled from the following sources:
• Reserve Bank of Fiji: https://www.rbf.gov.fj/
• Central Bank of Samoa: https://www.cbs.gov.ws/
• Bank of Papua New Guinea: https://www.bankpng.gov.pg/
• Banco Central de Timor Leste: https://www.bancocentral.tl/en
• Reserve Bank of Vanuatu: https://www.rbv.gov.vu/index.php/en/
• Central Bank of Solomon Islands: http://www.cbsi.com.sb/
• National Reserve Bank of Tonga: http://www.reservebank.to/
• Central Bank of Seychelles: https://www.cbs.sc/

Information describing the regional regulatory sandbox and the guideline can be found here: https://www.afi-global.org/publications/3254/Pacific-Regional-Regulatory…
Information on PIRI can be found here: https://www.afi-global.org/initiatives/pacific-islands-regional-initiati…
Information provided on this page should provide links to sources as much as possible.
Design and images shall reflect the environment, people and culture of the Pacific Island countries and the nuances of innovation / technology.

The general webpage shall be manageable by assigned administrators through a CMS.

7.2 Dashboard

This shall be available for both the institution and applicant presenting information appropriate for the user type. This shall provide a clear summary of the entire functions, information, insights, and actions available to the user.

7.3 Institution Management

This module is used by SA to add/update institutions and nominated default technical administrator for any given institution into the Sandbox Portal platform. Subsequent institution setup and management shall be undertaken by the nominated technical administrator from each institution.
This module must present the following features:

1. SA must be able to create, modify, delete institutions (e.g. Monetary Authority, Observer etc.) and TA (admin user) per country
2. TA must be able to add and provision, setup, edit, change and manage his/her institution profile on the sandbox portal.
3. TA must be able to add and provision, setup, edit, change and manage institution users’ access, roles, privileges and functions for the operations of the sandbox portal.
4. TA must be able to edit, update, disable, suspend, remove, activate and any other operational function, to the institution management (per country) module on the sandbox portal.

7.4 User Management
User Management module must be used by the designated lead TA to manage sandbox portal users – institution employees at the country-level, regional steering committee member at the regional level and applicants. This module shall provide access to functions and features to manage the respective activities, actions, rights and privileges of all user categories.

This module must present following features listed below:

1. Registration – Allow users register to the system by capturing biodata, institution, designation, email (to be verified) etc. TA will approve users per institution setting up rights and access privileges, applicants will have their emails (with scope to have other parameters also) verified
2. Edit / Modify / Change Function – Based on user type, ability to modify select field in profile. For IIT, changes specific changes shall be approved by TA
3. Roles & Privileges: As applied by TA for IITs and HLSC. Applicants shall have ONLY access to their profile, application and application management modules.

7.5 Applicant Module – General Regional Level Questions and Country Specific Questions Modules

Application module shall present the core application requirements for the applicants as captured in the Regulatory Sandbox Guidelines Appendix. The Application Form shall be presented in 2 sections:
• General: Application Form with fields as detailed in the Guidelines. Responses shall be shared with all selected “country of interest”
• Country Specific: Based on the “country of interest” selection done by the applicant; country specific information required by the central banks shall be presented. E.g. If applicant A selects Fiji, PNG and Samoa, they will be presented with additional questions (if any) from respective central banks . Responses to country-specific questions shall be shared ONLY with the specific country.
• The Country Specific Questions shall be created by respective countries through designated IIT member or TA. Each institution shall be able to create, edit, delete questions under this module and designate responses as optional, mandatory, text, document upload, selection from a list of options etc.

The application module will allow the SA and TA create, edit, delete questions for the general application form and country-specific questions for prospective FinTechs applying to the regional sandbox.
This module should present the following features listed below (not exhaustive):

1. TA must be able to add new questions in the platform
2. TA must be able to disable question/s in the platform.
3. TA must be able to have option to add/modify the answer types e.g. as Text Entry or choose one or multiple options from a list and /or a combination of both options per question.
4. TA must be able to set any given question as mandatory and / or optional on the application form.
5. TA must be able to add country specific questions (only for their country) which must be answered by the applicant (if set as mandatory), and ONLY IF applicant has indicated interest in the specific country.

7.6 Applicant Management
This module shall be responsible for the management of applicant interested in participating in the sandbox. This module is expected to support and fulfil requirements including:
• Enquires
• Applicant Registration – with user verification
• Applicant Profile Management e.g. modify point of contact details, change password etc. Select mandatory information cannot be modified once an application is submitted without the written notice and approval of the central banks.
• Applicant and associated users’ access and privileges
• Applicant activity history, report on status of application, and any other insights

7.7 Application Review Module

Following the successful submission of an application. The review process should follow the following suggested steps:

• Applicant receives confirmation email for successful application highlighting the country(ies) of interest, area of interest, tentative timelines and next steps.
• Selected participating countries (IIT) get notified of successful submission
• Designated HLSC members get notified of successful submission
• Country-level IIT initiates review and assessment process – access application form, option to download submitted form (available in word, excel or pdf) and also uploaded supporting documents, to proceed with assessment and evaluation offline
• Portal indicates start date and time counting down to estimated duration (based on guidelines) to ONLY IIT members
• Module to present Application Review Dashboard to IIT, with checklist as created by each institution. Each checklist shall be assigned a timeline, and status tracker. Once each item is completed by the regulator, this shall be checked completed.
• Checklist shall be tracked on at the country-level basis and collectively on the regional level with weekly updates on status of application shared with designate HLSC members and IIT.
• Country-level IIT can request additional information to applicant – written request or schedule a physical or virtual meeting – these events and activity should be captured under the Application Review Dashboard per applicant
• Applicant is notified of request for additional information sent via the Portal.
• Each step of review process is captured and displaced on dashboards for regional view
• Automated Bi-weekly (flexible) updates on progress of application shall be sent to the applicant – this shall capture progress at country-level based on checklist and summary at regional level.
• Feedback: The portal must facilitate and allow the seamless collection of feedback, questions and comments from the applicant to selected or all central banks.

7.8 Notification

To encourage local and regional interest and application to the regional sandbox from businesses, financial service providers and innovators, it was recommended that the members actively attract and encourage local and regional financial services providers and FinTechs to participate in the regional sandbox. A mailing list was created with focal points from each member institution with the aim to continuously populate a pool of potential applicants prior to the launch of the regional sandbox.

7.9 Reporting Module

To encourage local and regional interest and application to the regional sandbox from businesses, financial service providers and innovators, it was recommended that the members actively attract and encourage local and regional financial services providers and FinTechs to participate in the regional sandbox. A mailing list was created with focal points from each member institution with the aim to continuously populate a pool of potential applicants prior to the launch of the regional sandbox.

7.10 Security Considerations

The vendor must employ, demonstrate and actively practice general secure development principles, some of which include at the minimum (not limited to this list):
• Develop using secure coding principles, with specific actions such as:

• Parameter Validation
• Validate content types
• Validate lengths, structures and schemas
• Perform input validation to sanitize all inputs

• Implement oAuth2 with a combination of other 2FA variants (where applicable)
• Logging of digital footprint of all users / applicants
• Robust encryption and other security measures such as (where applicable):

• Implement public key (SSL) certification
• API connections and data in transit should be encrypted using TLS 1.2 at the minimum
• Use Cipher Suites w/ Perfect Forward Secrecy! e.g. ECDHE_RSA_WITH_AES_256_GCM_SHA256
• Use Extended Validation (EV) Certificates
• Use HMAC signature-based authentication model for API key exchange
• Use RESTful APIs instead of SOAP APIs
• Use of JSON Web Tokens (JWT) as the format for security tokens
• Whitelist and allow only valid entities
• Use Security headers
• Avoid Sensitive information in HTTP requests
  • Extensive and comprehensive threat detection using Web App Firewall (WAF).

8. Timelines:

This work would be undertaken and completed between October and January 2021. The developed portal will then proceed into a comprehensive User Acceptance Test (UAT) for 3 months and extended support of 9 months post-UAT. Key timelines is available in the RFP doc.

9. Travel:

No Travelling is required.

10. Qualification:

• 5+ years’ experience of vendor or consultant firm with development of both front and back-end web services, websites, enterprise web applications and digital portals following best practices of coding standards and frameworks.
• Expertise and experience of the vendor or consultant related to the UI/UX design, cloud hosting services, SEO, with demonstrated range of work and experience with development related to this assignment.
• Demonstrated evidence of firm adoption and use of agile web development principles
• Vendor or consultant must demonstrate adequate team size, team’s core capabilities and technology stack with clear evidence for structured web application framework, security and quality assurance, stress testing and robust support. Experience providing in-person and remote training and guidance for web applications and portals
• Excellent written and presentation skills in the English language.

11. Reporting:

Throughout the contract period, the Consultant will be reporting to AFI’s Policy Specialist for FinTech with oversight function from the Senior Policy Manager for Digital Financial Services. The contract will be with the individual consultant or consulting firm with specific names of the team member(s) that would be working on the assignment. The consultant is expected to have good knowledge of web portal and application development – both front-end and back-end, hosting option, implementation/ operation and support.

12. Criteria for Evaluation:

The proposals submitted will be evaluated based on the following criteria:

• Experience of vendor or consultant firm with development of both front and back-end for websites, enterprise web applications and web portals following best practices of coding standards and frameworks.
• Expertise and experience of the vendor or consultant related to the UI/UX design, cloud hosting services, SEO, with demonstrated range of work and experience with development related to this assignment;
• Proposal Structure and Detailing: If the proposed methodology provided is applicable according to the Terms of Reference and if there are an additional and important suggestions, tools, concepts and/or processes proposed by the vendor or consultant. We expect the following to be clearly articulated; Business requirements, Design, Development, Execution, Testing, Deployment and Support;
• Team size, core capabilities and Technology Stack: The implementation framework of the proposal including a demonstration of logical and clear planning to execute tasks and complete deliverables. Strong proposal should demonstrate structured web application framework, quality assurance, security and stress testing and methods;
• Coding Guideline and Documentation: The vendor must clearly propose coding guidelines, convention and documentation to be furnished highlighting ownership of final code, non-exclusivity i.e. ability for client to expand and edit final code without recourse to vendor, documentation to support migration and scalability and exemption from any copyrights.