Afis Project Rfp (Revised) -Final

Request for Proposal

For

Nigerian Pension Clients Biometric Data Capture

10 September 2012

http://www.penop.com.ng/index.php

http://www.penop.com.ng/index.php

Request for Proposal (RFP): Nigerian Pension Clients Biometric Data Capture. – September 2012

__________________________________________________________________________________

2 | P a g e

TABLE OF CONTENTS

1. INTRODUCTION 3 2. PROJECT OBJECTIVES 4 3. PROJECT SCOPE 4 4. KEY PROJECT DELIVERABLES 5 5. PROJECT OVERVIEW 6 6. STAKEHOLDERS 6 7. PRE-CONDITIONS 7 8. SOLUTION OVERVIEW AND LAYOUT 8 9. PROCESS FLOW AND OPERATIONAL PROCEDURE 9 10. HARDWARE REQUIREMENTS (GUIDE) 15 11. SOFTWARE REQUIREMENTS (GUIDE) 18 12. FORMAT FOR PROPOSAL RESPONSE 20 13. INTENT TO RESPOND 21 14. TERMS AND CONDITIONS 21 15. ENQUIRIES 22 16. PROPOSAL SUBMISSION FORMAT(S) AND DATE 22 17. SOLUTION REQUIREMENTS LISTING 23 18. APPENDICES 26


__________________________________________________________________________________

3 | P a g e

1. INTRODUCTION

National Pension Commission (PENCOM), the regulators of the Pension Industry in Nigeria, has requested all Pension Fund Administrators (PFAs) to ensure that all Retirement Savings Account (RSA) clients’ profiles are compliant with Automated Finger Identification System (AFIS) standards.

A recent verification exercise carried out on the RSA clients‟ National Databank by PENCOM revealed that over 80% of the current biometric data are not AFIS-compliant. Furthermore, about 10% of the AFIS-compliant profiles were duplicates.

In order to achieve the expected 100% AFIS-compliant level, it became obvious that the biometrics (and bio-data) of all existing RSA clients have to be re-captured, based on PENCOM-approved standards and specifications. Subsequently, all new RSA client registration MUST include mandatory AFIS-compliant biometrics and bio-data capturing. The specifications for capturing of fingerprint images for PENCOM AFIS is attached to this RFP as an appendix.

Furthermore, AFIS-compliant RSA clients profiles is also a key requirement for the commencement of the much-awaited Transfer Window, which enables RSA clients to move their accounts from one PFA to another as they desire. This mean that the Biometrics capturing project is expected to be concluded timely, whilst also ensuring the integrity of the data by eliminating multiple registrations, which has been a serious challenge to the Pension Industry, and which needed to be addressed forthwith.

It is also observed that many of the RSA clients‟ profiles on PFA Databases are out-dated, thereby making it extremely difficult for the PFAs to seamlessly treat transactions on such RSAs or communicate with such RSA clients. Consequently, the PFAs, through the umbrella body – Pension Fund Operators of Nigeria (PENOP), and in conjunction with PENCOM, decided to engage the services of competent professionals to carry out the capturing of the biometrics (and bio-data) of all existing RSA clients in Nigeria. This Request for Proposal (RFP) is therefore prepared to serve as guide to professionals who may be interested in being considered by PENOP to execute the project.


__________________________________________________________________________________

4 | P a g e

2. PROJECT OBJECTIVES

As noted in the introduction, the following are the key objectives of the project:

1. To make all existing RSA clients‟ profiles AFIS-compliant.

2. To make each existing RSA client‟s profile unique.

3. To provide information that will aid the resolution of all historical cases

of duplicate records, multiple registrations under different organisations and/or fake names.

4. To provide the platform for the resolution of all historical cases of duplicate records, multiple registrations under different organisations and/or fake names.

5. To provide the platform for elimination of future occurrence of cases of duplicate records, multiple registrations under different organisations and/or fake names.

6. To provide the platform for subsequent business-as-usual (BAU), AFIS-compliant and unique RSA clients registration.

3. PROJECT SCOPE

The project is designed to cover the capturing of biometric data of all existing RSA Clients as at cut-off date. The date will be specified in the contract award letter. The second aspect of the project is the collection and collation of completed Biometric / Bio-data Update Forms which is MANDATORY for all clients. The basic data for these clients and their geographical spread shall be provided to aid the exercise.


__________________________________________________________________________________

5 | P a g e

4. KEY PROJECT DELIVERABLES

The following are the key project deliverables, though not exhaustive:

1. Unique biometrics per RSA PIN.

2. Biometrics of all existing RSA clients (as provided), consisting of:

Finger prints (10 fingers or as specified)

Photograph

Signature

3. The biometric data capture processis only considered successful when a captured data is loaded unto the Collation Server for verification/validation, successfully verified/validated and successfully passed unto PENCOM‟s database. There will be penalty for rejections, depending on the nature/reasons.

4. Duplication checks on the Collation Server

It MUST not be possible for a biometric data to be duplicated in the system. That is, one biometric data cannot be used for (attached to) two or more RSA PINs.

It MUST not be possible for a RSA PIN to be verified / validated more than once. For instance, if an RSA holder goes through the exercise more than once at same location or different locations, all subsequent uploads, after the first validated upload, shall be invalidated and flagged for noting by the RSA holder’s PFA.

5. Completed biometric / bio-data update form for all existing RSA clients (as provided) that showed up for the exercise, properly noted by field officers in line with agreed process/SLA.

6. Resolution platform on the Collation Server for the PFAs and PENCOM to access, investigate and resolve all cases of multiple registrations, invalid PINs, single PIN to multiple clients, etc.

7. Daily activity reports, including prompt alerts on suspicious / fraud attempts, in line with agreed process/SLA.


__________________________________________________________________________________

6 | P a g e

5. PROJECT OVERVIEW

In view of the fact that the existing RSA clients are spread all over the country, it is expected that Data Capture Centres will be set up simultaneously nationwide (all 36 states and FCT) where RSA clients can visit to do the Biometric registration and also provide their current details to be used in updating their profiles on the respective PFA Databases and PENCOM‟s database.

The Data Capture Centres are expected to upload captured biometrics into the Collation Server located in PENCOM’s office for appropriate verification and validation. The validated biometrics will in turn be used in updating RSA clients‟ biometrics on PENCOM‟s database and sync with the respective PFA Databases.

The completed Biometric / Bio-data Update Forms, submitted by the clients at the Data Capture Centres, are expected to be collated and handed over to the affected PFAs at agreed intervals and through approved channels (SLA-based). The PFAs are expected to use these forms in updating the bio-data (not Biometrics) of their respective RSA clients on their databases and sync with PENCOM‟s database. This update process must be in accordance with subsisting PENCOM‟s guidelines on bio-data changes for the affected fields. It is expected that the new form, once verified / validated, will supercede any prior bio-data form that may have been submitted to the PFAs by the RSA clients.

Finally, the subsequent registration of new RSA clients MUST follow same process to ensure that multiple and/or double registration is never allowed again in the databases. The process to achieve this will be determined and advised by PENCOM.

6. STAKEHOLDERS

1. PENCOM 2. PENOP 3. All PFAs 4. All existing RSA Clients 5. Appointed professionals (Vendors)


__________________________________________________________________________________

7 | P a g e

7. PRE-CONDITIONS AND ASSUMPTIONS

It is assumed that:

The exercise is limited to the records of existing RSA Clients only i.e the exercise will not be used to capture new RSA clients‟ data.

All existing Clients have valid RSA PINs, Welcome Letters and/or Correspondences from PENCOM and/or their PFAs bearing their RSA PINs and full names. Clients will need to contact their PFAs to obtain copies of these documents, if they do not have them handy.

Only clients who can produce any of Welcome Letter and Correspondence from PENCOM and/or their PFAs bearing their RSA PINs and full names as evidences of their ownership of the RSA accounts will be attended to at the Data Capture Centres.

All existing RSA clients shall mandatorily complete Biometric / Bio-Data Update Form.

Existing RSA clients‟ profile (RSA PIN, Full Names, Photograph, Signature and PFA) will be available at the respective Data Capture Centres to aid the mandatory Documentation and Verification, and the ultimate Biometric Data Capture.

Adequate infrastructure will be provided at the respective Data Capture Centres.

There will be a Collation Server which will perform the Collation, Verification and Validation routine.

All the Data Capture Centres will have robust Internet links that will be used to access the Collation Server Application via Webservice.

There will be functionality to detach the newly uploaded/updated biometric data from an RSA PIN, invalidate the RSA PIN and attach the biometric to the “right” RSA PIN in proven cases of multiple registration, wrong/multiple upload from Data Capture Centre, etc. This will be in accordance with subsisting PENCOM guideline (e.g. Rule of first PIN), and all such activities shall require prior approval by PENCOM and be carried out on the Collation Server by PENCOM‟s authorized users.

Only biometric capture will be done. No bio-data capture. The bio-data update Forms will be used by PFAs for the necessary bio-data capture as deemed appropriate, subject to the appropriate PENCOM-approved governance process.


__________________________________________________________________________________

8 | P a g e

For security purposes, all Data Capture Centres will be registered uniquely on the Collation Server, such that any record not carrying recognised Data Centre Code will be rejected by the Collation Server. All Data Capture Centre codes shall be invalidated upon the completion of the project.

8. SOLUTION OVERVIEW AND LAYOUT

TECHNICAL ARCHITECTURE (BASE CONNECTIVITY)

Captured data from the field systems (36 States and FCT) are transmitted via VPN connection to the Collation Server. The data from the Collation Server are synchronised with PENCOM‟s National Data Bank (NDB) via a URL. There is Webservice connectivity between respective Pension Funds Administrators (PFAs) and the Collation Server.


__________________________________________________________________________________

9 | P a g e

9. PROCESS FLOW AND OPERATIONAL PROCEDURE

A. FIELD CAPTURE (please refer to the flowchart)

1. Existing RSA Client (CLIENT) from any PFA visits any location of his/her choice anywhere in the country (any of the 36 States and FCT) to update his/her Biometrics and provide information for Bio-data update.

2. CLIENT collects Biometrics / Bio-data Update Form (see appendix

2), fills it and hand it over to the Documentation Agent for review, along with copy of his/her Welcome Letter and/or Correspondence from PENCOM and/or their PFAs bearing his/her RSA PIN and full names.

3. Documentation Agent will perform the following checks:

RSA PIN on the document submitted tallies with the RSA PIN on the form completed by the client. If not, the client is requested to correct it, else registration is not allowed.

Full names on the document submitted tallies with the Full names

on the form completed by the client. If not, Documentation Agent checks that the client answered YES for the field “Name change required? (NO/YES)”. If not, the client is requested to correct it, else registration is not allowed.

4. Once satisfied with the checks, Documentation Agent will then:

Staple (or clip) the Form and the document submitted together for further processing.

Register the client in the client‟s PFA‟s Biometric / Bio-data

Update Register containing columns for Serial Number, RSA PIN and RSA Holder’s Names.

Stamp the completed Form and the document submitted; noting

the registered serial number on the form. Send the stamped documents to the Verification Agent.

5. Verification Agent will perform the following checks/tasks:

Check the RSA PIN on the “local” Clients Database. If the RSA PIN is not found, the document will be so noted by

ticking YES in the section on the Form “RSA PIN not on local database? (YES/NO)”, and passed to Validation Agent.


__________________________________________________________________________________

10 | P a g e

If the RSA PIN is available on the local database, the client‟s

Picture and Signature will be displayed for verification. Verification Agent performs “reasonable” due diligence check on

the client‟s picture by confirming whether or not the picture displayed reasonable degree of resemblance with the physical appearance of the client.

Verification Agent notes his/her opinion on the document by

ticking the appropriate comment box for Picture Verification (Satisfied, Not Sure or Not Satisfied). Where there is no picture on the local database, Verification Agent ticks the comment box “Picture not on local database”.

Verification Agent then performs “reasonable” due diligence

check on the client‟s signature by confirming whether or not the signature displayed reasonable degree of resemblance with the signature on the Form.

Verification Agent also notes his/her opinion on the document by

ticking the appropriate comment box for Signature Verification (Satisfied, Not Sure or Not Satisfied). Where there is no signature on the local database, Verification Agent ticks the comment box “Signature not on local database”.

Where the Verification Agent has noted “Not Sure”, “Not

Satisfied”, “Picture not on local database” or “Signature not on local database” for Picture and /or Signature Verification, the document will be passed to the Validation Agent for second level check.

Where the Verification Agent has noted “Satisfied” for both

picture and signature the document will be passed straight to the Data Capture Agent for biometric capture.

6. Validation Agent repeats the Picture and/or Signature Verification

due diligence exercise in cases where Verification Agent has noted “Not Sure” or “Not Satisfied” for Picture and /or Signature Verification.

7. Validation Agent also notes his/her opinion on the document by

ticking the appropriate second level comment boxes for Picture and Signature Verification (Satisfied, Not Sure or Not Satisfied). The document will then be passed to the Data Capture Agent, who will take the Validation Agent‟s comments as final, for noting in the system.


__________________________________________________________________________________

11 | P a g e

8. However, where foul play or fraud attempt is suspected, the so-called client should be denied biometric capture, the document kept as evidence and the incidence reported immediately in line with agreed process.

9. Where Picture and / or Signature is noted not to be on the local

database, Validation Agent will recheck the local database and thereafter, if confirmed not found, access the Collation Server.

10. If any or both are still not found on the Collation Server, Validation

Agent ticks the comment boxes “Picture not on Collation Server” and “Signature not on Collation Server” as applicable; and passes the document to Data Capture Agent for biometric capture. Data Capture Agent will note the comment against the client accordingly in the system.

11. Where any or both are found on the Collation Server, Validation

Agent will repeat the Picture and/or Signature Verification due diligence exercise, note his/her opinion on the document by ticking the appropriate second level comment boxes for Picture and Signature Verification (Satisfied, Not Sure or Not Satisfied). The document will then be passed to the Data Capture Agent, who will take the Validation Agent‟s comments as final.

12. Where the RSA PIN is noted not to be on the local database,

Validation Agent will recheck the local database and thereafter, if confirmed not found, access the Collation Server.

13. If the RSA PIN is not found, Validation Agent will note the document

accordingly by ticking YES in the section on the Form “RSA PIN not on Collation Server? (YES/NO)”, and passed to Data Capture Agent for biometric capture. Data Capture Agent will note the information against the client accordingly in the system.

14. If the RSA PIN is found, Validation Agent will perform the Picture and

Signature Verification due diligence exercise, note his/her opinion on the document by ticking the appropriate second level comment boxes for Picture and Signature Verification (Satisfied, Not Sure or Not Satisfied). The document will then be passed to the Data Capture Agent, who will take the Validation Agent‟s comments as final.

15. In all cases where there is an issue with RSA PIN or identity (e.g

Client‟s identity cannot be verified due to clearly different passport photograph and signature on the system), and no foul play or fraud attempt is suspected, the Validation Agent MUST politely explain to the affected RSA client the inconsistencies in his/her data and advise the Client to contact his/her PFA.


__________________________________________________________________________________

12 | P a g e

16. Data Capture Agent will finally fetch the customer details from the local database, or type out the details where they do not exist on local database, carry out the biometric capture, taking the finger prints, picture and signature (as prescribed). The comments by the Verification Agent or Validation Agent (as the case may be) will be noted against the client in the system. An RSA PIN that exists on the local database MUST be automatically flagged once used for biometric data capture, to minimise the risk of double capturing and the attendant time wastages.

17. On completion, Data Capture Agent prints out the confirmation

receipt (a slip) for the client. Client (RSA Holder) is advised to confirm the RSA Pin, Full names, picture and signature as captured on the system by examining the details in the printed slip.

18. Once confirmed by the client, the record is put in queue by the Data

Capture Agent for synchronization to the Collation Server. The queuing time MUST be specified by Vendors. That is, it must be possible to have an idea of how long it will take a captured data to get uploaded to the Collation Server. The queuing process MUST also not affect the ability of the Data Capture Agent from continuing the capturing of subsequent data. It is also important to know the average time it will take to do biometric data capture for each client.

19. The Data Capture system MUST have facility to “store” the captured data until they are purged, and also flag any one that has been successfully uploaded. This is to avoid need for data re-capturing in cases of inability to upload unto the Collation Server.

20. At the end of the day‟s work, Data Capture Agent generates a

consolidated activity report for reconciliation with the entries recorded by the Documentation Agent for the day in the respective PFA registers. The registers and the system report, together with reconciliation notes MUST be signed off by all the agents, and sent to the Project Manager on a daily basis.

21. It should be possible to generate reports that will show the summary and details of records processed and records sent to Collation Server for each day.


__________________________________________________________________________________

13 | P a g e

B. COLLATION SERVER 1. Records pushed from various Data Capture Centres are “Collected”

and put on queue for Validation. The queuing time MUST be specified by Vendors. That is, it must be possible to have an idea of how long it will take a captured data to get verified/validated on Collation Server and sync with PENCOM database. It should be possible to generate “collected records” reports for the Project Manager(s) to use in reconciling with Data Centre reports. Any record not carrying a Data Centre Code will be rejected as invalid and junked.

2. Records collected are validated for AFIS compliance, ensuring that no

biometric data or RSA PIN is used more than once. It should also be possible to generate reports that will show the summary and details of records “collected” and records “validated” for each day, per one or more search criteria such as State, Local Govt, PFA, Data Capture Centre, etc.

3. Validated records will be updated as new records. That is, the old record will still be kept.

4. Where newly updated PINs are recaptured (cases of multiple

biometric capture), duplicated record will marked for approval/rejection. This requires investigation by the affected PFA who will advise the valid record with appropriate proof. If approved, it will be validated and updated as the new record while the previous one will be marked old.

5. For the purposes of the investigation and approval, PFA representatives will have access to Collation Server to review and treat RSA clients‟ records that have issues.

6. Old records are stored away in history and approved records are marked as updated.

7. Collation Server activities (Approvals and updates) are then synchronised with PENCOM NDB.


__________________________________________________________________________________

14 | P a g e

8. Other Collation Server Requirements:

i. All PFAs should be able to access the server to see all their RSA Clients and details (captured and outstanding) via a web portal.

ii. PFA can approve changes for data that needs to be updated.

iii. The system should be able to generate full or on request reports for either new RSA Clients, old RSA Clients or both and monitor progress.

iv. The system should be able to generate reports of duplicate records.

v. The system should be able to point out matching records within and amongst the different PFAs.

vi. The approved authorities should be able to view and export duplicate records to file.

vii. Generate file dump for a particular segment of RSA Clients based on entered fields.

viii. File Dump should be encoded to prevent tampering.

ix. Ability to receive records via web service from the capture terminals.

x. De-duplication exercise of biometric data

C. AFIS DUPLICATION CHECK

1. AFIS compliance check is carried out on all updated records by PENCOM.

2. Duplicate records are marked with an ID which would enable easy

identification and trace.

D. CLEAN UP EXERCISE

1. Clean and Duplicate records can be viewed directly by PENCOM. 2. Clean records are then moved over to PENCOM NDB via a URL and

marked as NDB updated.


__________________________________________________________________________________

15 | P a g e

10. HARDWARE REQUIREMENTS (GUIDE)

Note: These are guides only, the Vendor is at liberty to vary the system specifications in order to satisfactorily and efficiently meet the project requirements, whilst clearly indicating all or any variations introduced.

a. Verification System Requirements

- A mini laptop with 10” or 11” screen size

- Processing and memory capacity sufficient enough to handle the daily verification exercise – 4GB RAM

- Storage capacity should be able to hold at least 1 million RSA holders records (RSA Number, Full Name, Signature and Passport Photo) – 1TB HDD

- CD/DVD drive not required

- The laptop should not allow saving of unauthorized data

- Internet access with VPN capability

b. Data Capture System Requirement

- A mini laptop with 10” or 11” screen size

- Processing and memory capacity sufficient enough to handle the daily data capture exercise and upload to of records to central collation server – 4GB RAM

- Storage capacity should be able to hold at least 1 million RSA holders records (RSA Number, Full Name, Signature and Passport Photo) – 1TB HDD

- CD/DVD drive not required

- The laptop should not allow saving of unauthorized data

- Internet access with VPN capability

- Provision for backing up captured data - External HDD or Tape drive


__________________________________________________________________________________

16 | P a g e

c. Collation Server Requirements

- Storage Capacity to hold current RSA DB + generated biometric data of existing RSA holders + at least 300% growth (over 5 years)

- Processing and memory capacity sufficient enough to process transactions from all (1700+) Data Capture Centres and update PENCOM database

- Connectivity to the internet to allow secure connection from the Data Capture Centres

- Provision for daily data backup

- 4x 10 2.4GHz Processor

- 256GB RAM

- 2x 600GB SAS/SATA HDD (internal)

- 40TB SAN storage Space (to store 10,000,000 records each with 12 Binary data fields and 30 x 50 character length fields)

- Tape Library

- Full Server Redundancy (High Availability) using multiple Switches

d. Assumptions:

i. Netbook for Capture of Biometric data.

Each of the system to hold a minimum of 1 million RSA Clients Records database.

The Netbook system will be used to capture existing RSA Clients‟ signature, passport photograph and fingerprint details.

The Netbook system to be fast processing speed commensurate with the use to which it would be put.

Biometric scanners are functional and compatible with the Netbook systems.

The Digital Cameras to be used with the system would be compatible with the Netbook system.

3G/Wi-Fi Internet connectivity to be available on the Netbook system for connection to the Collation Server at PENCOM.

The Signature pad to be used will be compatible with the Netbook system


__________________________________________________________________________________

17 | P a g e

The Minimum storage facility of each system will be 1TB (solid state).

The System should be small and portable (mini).

The Netbook system comes with digital security.

The Netbook system to have removable CD drive.

ii. Netbook for Verification of RSA Clients’ details.

Each System to hold a minimum of 1 million RSA Clients in its database.

The system will be used to verify existing RSA Clients details only.

The Netbook system to be fast processing speed commensurate with the use to which it would be put.

Biometric scanners are functional and compatible with the Netbook systems.

The Digital Cameras to be used with the system would be compatible with the Netbook system.

3G/Wi-Fi Internet connectivity to be available on the Netbook system for connection to the Collation Server at PenCom.

The Signature pad to be used will be compatible with the Netbook system

The Minimum storage facility of each system will be 600GB (solid state).

The System should be small and portable (mini).

The Netbook system comes with digital security.

The Netbook system to have removable CD drive.


__________________________________________________________________________________

18 | P a g e

11. SOFTWARE REQUIREMENTS (GUIDE)

Note: These are guides only, the Vendor is at liberty to vary the software specifications in order to satisfactorily and efficiently meet the project requirements, whilst clearly indicating all or any variations introduced.

1. Biometric specification: capturing/management capability a. Ability to capture 10 fingers

b. Minimum 500dpi

2. Photo Specification: Capturing/management capability

a. The passport should be in a JPEG format with pixel dimensions of 120*140 and resolution of 96pixel/inch (minimum).

b. Full face frontal poses with both eyes and ears visible

c. The full face poses to cover 70-80% of the photo

3. Signature: capture/management capability a. The signature should be in JPEG format with a pixel dimension of

120*140 and the resolution should be 96pixels/inch (minimum)

4. Biodata capture/management capability (for the specified MINIMUM fields listed below) – also contained in the Mandatory Biometric/Biodata Update Form

a. First name b. Surname c. Middle name d. Date of Birth e. Address (1-3 fields Minimum 250 Characters) f. Telephone/mobile number 1 g. Telephone/mobile number 2 h. Email i. Type of identification j. Identification number k. Next of Kin‟s name (First, Middle and Surname) l. Next of Kin‟s telephone/mobile number m. Next of Kin‟s Address (1-3 fields) n. Next of Kin‟s email Address o. Name of Employer organisation p. Address of Employer (1 – 3 fields) q. Salary scale r. Designation s. Level. t. Date of first employment u. Place of Posting


__________________________________________________________________________________

19 | P a g e

5. The system should be able to identify and indicate already registered

RSA Clients on the field.

6. The local database should be able to store segmented records.

7. Decode dump file of records and upload into local database

8. Dump and encode file from local database

9. Push data over to Collation Server via web services

10. Ability to perform first level (Remote) and second level (Collation Server) AFIS-compliant and uniqueness tests.

11. Allow PFAs to “accept” AFIS-compliant and unique biometric, certified in the Collation Server, before being adopted into the PFA database via PENCOM database. All items okayed by Collation Server but not accepted by the PFAs should be subjected to the “resolution” process.


__________________________________________________________________________________

20 | P a g e

12. FORMAT FOR PROPOSAL RESPONSE

1. Executive Summary - Brief profile of the Company. - Experience in Data Capture Service and/or similar services - List of Client references

2. Technical Information

- Description of the solution methodology/approach - Implementation Process & Timelines: Detailed work plan for the

deployment of the Solution, including timeframes and deliverables.

- Major Milestones & Achievements - Detailed Requirements from PENOPS/PENCOM.

3. Commercials

- Detailed cost model, with separate headers for Hardware (Collation Server and Remote Equipments), Software (for Host Server and Remote systems), HR and Logistics, etc.; including payment terms.

- Training on the Solution. - Integration

4. Support and Maintenance Plans for the Solution 5. References

- Detailed list of at least three (3) Companies or Institutions that similar comprehensive services have been offered including their addresses, Contact Person(s) and Telephone numbers.

6. Appendix

- Any other information e.g. Alternate Solution or Services to achieve results, Additional Benefits, Project Team Staffing (resumes and relevant experience and qualifications of key staff and Management personnel) etc.

- 3-year tax clearance and PENCOM Certificate of Compliance.


__________________________________________________________________________________

21 | P a g e

13. INTENT TO RESPOND

PENOP requests that parties electing to respond to this RFP submit an ‟Intent to Respond‟. The „Intent to Respond‟ must be via email to

[email protected], copying [email protected], and received prior to close of business on Wednesday 19 September 2012.

Included in the „Intent to Respond‟ shall be the following:

- Formal name of the organization responding - Statement indicating intent to respond - Contact information of nominated officer responding, including email

address and GSM numbers.

This information is required for planning of the related briefing meeting to be held on Friday 21 September 2012, and to enable PENOP invite interested vendors to the meeting.

14. TERMS AND CONDITIONS

1. PENOP is not liable for any cost incurred by vendors in their response to this RFP.

2. To be considered, bidders must submit a complete proposal in the format specified in this RFP on or before the date specified in the RFP / advert.

3. Proposals should be prepared simply and economically, providing a straightforward, concise description of the Vendor‟s ability to meet the requirements of the RFP.

4. No portion of the work shall be subcontract to a third-party Vendor without the prior written consent of PENOP.

5. By submitting proposal in response to this RFP, the successful bidder represents that they have read and understand the scope of requirements and have familiarized itself with all the Federal, State and Local laws, ordinances and rules and regulations that in any manner may affect the cost, progress, or performance of the work.

6. All financial information requested with the RFP must be included within the proposal and should provide breakdown of the cost of the project. Failure to include the information may result in automatic disqualification.

mailto:[email protected]





__________________________________________________________________________________

22 | P a g e

7. Short-listed Vendors will be invited for further discussions/negotiations. PENOP is not obliged to respond to interested Vendors that are not short-listed. PENOP is also not obligated to reschedule meetings for invited Vendors who missed the meeting appointments.

15. ENQUIRIES

All enquiries in relation to the RFP should be sent via email to: [email protected], copying [email protected], with subject as „Bio-Capture and Update Application RFP Enquiries‟.

16. PROPOSAL SUBMISSION FORMAT(S) AND DATE

Soft copy proposals should be submitted in PDF format and sent to [email protected], copying [email protected], Please note that PENOP is not responsible for server delivery failures and the non-receipt of the soft copy will lead to disqualification, whether or not it was sent before the deadline expiration. Proposals must reach the above E-mail Addresses no later than 10:00am on Friday, 28 September 2012. Please note that late submissions will be disqualified.






__________________________________________________________________________________

23 | P a g e

17. SOLUTION REQUIREMENTS LISTING

SN Application Requirements Category REQUIREMENT STATUS (MANDATORY OR DESIRABLE)

AVAILABILITY* COMMENTS

FS PS NA

1 Application must be secure and data encrypted

App function MANDATORY

2 Ability to Refresh data without having to log-in again

App Function MANDATORY

3 Ability to access application online or offline and then download data subsequently


4 Ability to Check for AFIS Unique values to avoid duplicates


5 Ability to collect fingerprint images from several stations simultaneuously and send for processing at DB for matching

MANDATORY

6 Ability to decode / detect human finger thread against other types


7 Ability to integrate with PENCOM verification and validation application


8 Ability to pull data from database or where capture is done offline, system should generate unique ID number to tag


9 Ability to run AFIS check independently on capture application as first level check on collected data


10 Ability to track processed and stored information on system


11 An ability to provide real time verification and identification services to online/offline verification systems


12 Client app must be able to capture fingerprints (Minimum of 2 fingerprints or all 10), signature and photograph


13 Client app must be able to download and upload to server over telecom network


14 Client app must be fast in search local and remote database


15 Client app must do some verification at point of capture


16 Deploy a software that will capture Biometrics from a Biometric scanning device


17 Flexible architecture to enable standard and adhoc report



__________________________________________________________________________________

24 | P a g e

generation

19 Provision for prompt statistical analysis through report generation


20 The client application should be able to generate a confirmation number which will be issued out to the RSA holder as proof of participation in the exercise.


21 The client application should comply with the resolution as required by PENCOM and should also check for completeness and uniqueness on its local database and should flag exceptions and duplicates.


22 The client should be set up on a mobile system (Netbook with webcam and finger print scanner) and should maintain a local database.


23 The entire solution should be robust enough to handle very large bio database with minimal performance degradation.


24 The software should have the capacity to validate and detect duplicates thump prints at capture level. (should not enforce blocking)


25 The system (capture & Collation Server) should have full support for multi-user operation.


26 The system (capture System) should have the ability to display images immediately they are captured - for verification and validation - before processing


27 There should be an automated routine for importing and exporting data between the client side application and the server side application.


28 User-friendly Data Entry interface for easy data storage


29 Biometric Scanner must be installed with each system

Hardware MANDATORY

30 Provide a common platform for Biometric update

Collation MANDATORY

31 Provide all PFAs with their distinct PINs or based on update status as required.

Collation MANDATORY

32 Collation System should also check intra PFA Biometric duplicate

Collation MANDATORY

33 A multi-tier business architecture Security MANDATORY


__________________________________________________________________________________

25 | P a g e

which offers differentiated access, security and look and feel for different types of users classes

34 Ability to allow data backup Security MANDATORY

35 Ability to conduct user access management on the application, including adding users, unlocking users, expiring users, forgotten password management.

Security MANDATORY

36 Ability to export to MS Office or PDF, CSV & XML directly from the collation server by PFA

Security MANDATORY

37 Ability to log on with a registered user name and password - only registered users can use application

Security MANDATORY

38 Ability to maintain complete audit trail

Security MANDATORY

39 Ability to reset and lock passwords on the capture application (using some secure key)

Security MANDATORY

40 Ability to support multiple level of users (roles and IDs - managers, field users, supervisors etc)

Security MANDATORY

41 Admin role of database must not have default password.

Security MANDATORY

42 Allow separation of Admin Role and Operational roles - admin role should not have access to operations and vice versa.

Security MANDATORY

43 Audit trails of all activities on application should be available

Security MANDATORY

44 Capacity management plan should be submitted by the vendor.

Security MANDATORY

45 Date & Time of Capture / data update to be available on the audit trail

Security MANDATORY

46 Date of Creation (and deletion) of Operator account to be available on audit trail.

Security MANDATORY

47 Dates of user entry and exit, reset, password change, and wrong password attempts to be captured by application.

Security MANDATORY

48 Forced password change at first logon should be enforced.

Security MANDATORY

49 Full tracking of all user activities and all database statements should be available on the database.

Security MANDATORY

50 Indexes should be created on the database for all major searches by the application

Security MANDATORY


__________________________________________________________________________________

26 | P a g e

51 It should be possible to have a User Role that only allows a read only view of the application.

Security MANDATORY

52 License for database server should come with the software or pricing should be explicitly stated as separate.

Security MANDATORY

53 Location of Capture - state and Local Govt. Area to be captured by application

Security MANDATORY

54 Maximum Password Violation Attempts : 3 attempts

Security MANDATORY

55 Minimum Password Length : 8 Security MANDATORY

56 Operator ID Security MANDATORY

57 Password History : 10 – 12 Security MANDATORY

58 Password Life : 30 days Security MANDATORY

59 Password should be Alphanumeric Security MANDATORY

60 Routine Maintenance plan including database management should be submitted by the vendor.

Security MANDATORY

61 Session Time-out : 5 – 15 mins Security MANDATORY

62 Technical Documentation must be complete.

Security MANDATORY

63 The System Admin role should not be without password

Security MANDATORY

64 Users with admin rights should not have access to any operational area of the application (except read-only access)

Security MANDATORY

65 Server app must be able to validate biometrics

Server MANDATORY

66 Server app must have reporting capabilities

Server MANDATORY

67 The server side application, upon the importation of records from the client application, should also carry out the completeness, resolution and uniqueness tests and should flag exceptions and duplicates.

Server MANDATORY

68 The server side solution database should be such that can be easily and seamlessly integrated into each PFA's core application with minimal cost.

Server MANDATORY

Legend: FS – Fully Supported, PS – Partially Supported and NA – Not Available

18. APPENDICES Data Capture Flowcharts and PENCOM’s AFIS Specifications

Data Capture Centre Activity WorkflowV

eri

fic

ati

on

de

sk

(Le

ve

l 1

)D

oc

um

en

tati

on

De

sk

(A

ge

nt

1)

Clie

nt Client visits Data

Capture Center and

collects Biometrics/

Bio data update form

Start

The client fills the

Biometrics/Bio

data update form.

The filled Bio data update form is handed

over to the documentation Agent for review

along with a proof of RSA account

(Welcome Letter/RSA Statement).

On receipt, the agent

ensures the availability of

the client‟s proof of RSA

account.

Is Proof

available?

Client is politely advised to

provide a proof of RSA

account before being

attended to.

NO End

The agent subsequently

validates the PIN on the

completed form against

that on the proof of RSA

account.

YES

Is PIN valid?

The client is advised to

correct the PIN on the

form with the PIN on

the proof of RSA

account.

NO

The agent then validates the

client‟s full names on the completed

form against that on the proof of

RSA account.

YES

Does full names

correspond?NO

YES

Both the completed Bio data

update form and proof of RSA

account are collected from the

client and stamped.

The agent registers the Client in

the Client‟s PFA‟s Biometric/Bio-

data Update Register using the

PIN and RSA holder‟s names.

Agent enters the date,

serial number, and

signs off on the

stamped area.

Both documents are

passed on to the

verification agent

A

Client is told to tick

the „name change

required?‟ checkbox

on the form

Is name change

checkbox ticked

YES

Client ticks “name

change required ?”

checkbox.

Data Capture Centre Activity Workflow – Part IID

ata

Ca

ptu

re

de

sk

Ve

rifi

ca

tio

n d

es

k (

Le

ve

l 2) – V

alid

ati

on

/ 2

nd

Le

ve

l V

eri

fic

ati

on

Ag

en

t

Ve

rifi

ca

tio

n d

es

k (

Le

ve

l 1) – 1

st L

ev

el

Ve

rifi

ca

tio

n A

ge

nt

AYES

Clients RSA

PIN found?

The client‟s Picture and

Signature is displayed for

verification

Agent checks on the

“local” Clients‟

Database to verify

client data using RSA

PIN.

Reasonable

degree of

resemblance?

NO

NOClients data

found?

Agent searches on

the collation server

for Client details

The client is

politely told to

contact his PFA.

Both the Bio data update

form and proof of RSA

account are stamped and the

agent‟s satisfaction is

indicated on the stamp.

The client is directed

to the capture agent

for data capture.

YES

Notes his/her opinion on

the document by ticking

the appropriate

comment box for

Picture/Signature

verification (Satisfied,

Not Sure, Not Satisfied).

NO

YES

Reasonable

degree of

resemblance?

NO

YES

Agent notes his/her

opinion on the document

by ticking the appropriate

2nd

Level boxes for

picture/

Signatureverification

Both the Bio data update

form and proof of RSA

account are stamped and the

agent‟s dis-satisfaction is

indicated on the stamp.

If the Client‟s identity cannot

be verified but no foul play is

suspected, the Agent is to

politely explain to the Client the

inconsistencies and advise the

client to contact his/her PFA.

End

The document is passed to

the Data Capture Agent who

notes Validation agent‟s

comment as final on the

system

B

Client is passed to

Validation Agent (2nd

level verification).

Agent ticks „YES‟ in the section

on the form „RSA PIN not on

local database(YES/NO)‟

Is Picture/

Signature on

local system?

The client is directed to the

Validation Agent (2nd

level

Verifier for further

verification.

YES

Agent ticks the comment

box “Picture not on local

database”/”Signature not

on local database”

NO

X

X

Validation agent ticks the comment boxes “Picture not

on collation server” and “Signature not on collation

server” and also tick YES in the section on the Form

“RSA PIN not on Collation Server?(YES/NO)”

Is Picture/

Signature on

local

system?

YES

Agent ticks the

comment box “Picture

not on local database”/

”Signature not on local

database”

NO

Y

Y

Validation agent ticks the 2ND

Level comment boxes for

Picture and Signature

Verification (Satisfied, Not

Sure, Not Satisfied)

Data Capture Centre Activity Workflow – Part III

Da

ta C

ap

ture

de

sk

B

Agent captures

the client‟s

signature.

Agent captures

the client‟s

fingerprints

Agent takes the

client‟s

Photograph

A confirmation

slip is printed and

given to the client

The central database

(collation server) is

updated with the

capture details.

End

The RSA Holder is

advised to confirm the

RSA PIN, Full names,

picture and Signature

by examining the

details on the Slip

Date post:	27-Oct-2014
Category:	Documents
Upload:	ashwin2250
View:	20 times
Download:	0 times

Afis Project Rfp (Revised) -Final

Documents