Inactive

Request for Information: Tokenization of Social Security Numbers on Mailed Documents This is a Request for Information (RFI). This Sources Sought Notice is for informational and planning purposes only... Request for Information: Tokenization of Social Security Numbers on Mailed Documents This is a Request for Information (RFI). This Sources Sought Notice is for informational and planning purposes only and shall not be construed as a solicitation or as an obligation or commitment by the Government. This announcement is not a request for proposals, and the Government is not committed to issue a solicitation or award a contract pursuant to this announcement or based on responses to this announcement. This notice is strictly for market research to assist the Government for planning purposes. The Government will not pay any costs incurred in the preparation of information for responding to this market survey or the Government's use of the information. Purpose The Social Security Administration (SSA) is considering a tokenization solution for replacing the Social Security Number (SSN) and Beneficiary Notice Control (BNC) on mailed correspondence to beneficiaries. The purpose of this Request for Information is to identify potential vendors capable of providing such a solution. Background On September 15, 2017, the President signed into law H.R. 624, the Social Security Number Fraud Prevention Act of 2017, which became Public Law (P.L.) No. 115-59. The law, among other provisions, restricts the inclusion of SSNs on documents the Federal government sends by mail. The Beneficiary Notice Control has been used to replace the SSN on some agency notices. The BNC is a 13-digit alphanumeric value that can be related back to the beneficiary's SSN. The usage of tokenization is being explored to replace the SSN and BNC on mailed documents. Product Requirements • Must be capable of supporting multiple platforms - web, cloud, and mainframe (CICS and Java/COBOL batch). • Must allow for multiple keys when tokenizing an SSN. The same key cannot be used consistently. The same tokenized value should never repeat (even for the same SSN). • Must allow for key management - where certain users can be prohibited from accessing the key(s). • Must be able to control the length of the tokenized value - for printing and mailing the tokenized value can be no more than 13 digits. • The tokenized value must be unique for all time and never repeated. Meaning, the tokenized value printed on the mailed correspondence will be unique for that particular occurrence and will never be repeated again even if the correspondence is being mailed to the same individual or a completely different individual. • Must be capable of processing very high volumes. The table below shows totals for a typical nightly run and a nightly run combined with several large annual mailings. Please note that some annual mailings can process upwards to 65 million notices in one run. Process # Notices # Seconds Minutes Hours Notices Per Second Normal nightly jobs 281,102.00 202 3.37 1,391.00 Normal nightly jobs with several annual mailings 14,660,447.00 24,840 414.00 6.90 590.00 Note: The above table reflects batch transactions that account for the highest overall volumes. Please be aware that thousands of notices are produced interactively daily during peak business hours. Desired Product Features • The tokenized value can be created with special characters (for example, dashes). • The tokenized value can be created with a combination of letters and numbers. • The tokenized value can be created with a specific character always appearing in the same position. • SSA can perform the conversion back to an SSN on its own in perpetuity. Meaning, if the association with the vendor is severed for any reason, the agency can still ‘decode' tokenized values back to the original SSN. • The tokenization process is open and available for inspection so that the agency can ensure that the tokenized value is always unique. Vendor Information Required SSA requests vendors to provide information in as much detail as possible regarding: • Vendor's Current User Support Capabilities: Information regarding implementation of solution on large institutions or government agencies. • Vendor's Maintenance Services: Information regarding maintenance services for procured governance tool. For example, SSA requires the vendor shall include all software patches, software updates and version upgrades during the 12-month period following final installation of the solution. The vendor shall update electronic versions of all software documentation where upgrades, modifications, new releases, improvements, enhancements, extension fixes and other changes to the software will cause the previous versions to become obsolete. • Vendor's Technical Support Services: The vendor shall include the highest level of software technical support equivalent to industry standard services. This shall include onsite, internet and telephone support to software tool administrators and other designated SSA technical personnel who need assistance in using the software license management tool. Support • Product maintenance to include downloadable upgrades, updates, fixes, and patches to the software solution. • Ongoing updates to the software vendor and products catalog. • Product documentation to include guides and manuals for the solution. • Telephone, email, and web based support. • Research and correct problems and issues with the normalization process. Vendor Responses Respondents must submit capability statements and information describing the general approach/solution to addressing the listed requirements. General marketing information or reference to vendor web sites will not be considered responsive to this notice. Interested sources that believe they have the ability to provide the solution and perform the services listed herein should submit a detailed statement of their capabilities electronically via email to Roger.Twigg@ssa.gov. Please reference 28321319RI0000034 in the email subject line. No telephone, mail, or fax responses will be accepted. Responses must be received by 5:00 pm EST on February 8, 2019. In addition to capability statements, vendors must include the following: • Organization Name, Address, Email Address, Website Address, and Telephone Number. • Size and Type of Ownership and Socioeconomic Designation for the organization [i.e. Small Business, Small Disadvantaged Business, 8(a), Women-owned Small Businesses, Veteran-owned Small Businesses, Service Disabled Veteran-owned Small Businesses, Historically Underutilized Business Zone Small Businesses, etc.]. • Availability of products and services on the GSA schedule if applicable. • Business experiences. • A completed Voluntary Product Accessibility Template (VPAT) 2.1 of their solution. Please complete the WCAG A, WCAG AA, and 508 Report tables. A blank VPAT 2.1 can be obtained at: https://www.itic.org/dotAsset/db71ce67-c44a-4925-8d46-f8a76c3a1db2.doc Vendors must identify any proprietary information submitted in response to this Request for Information. The proprietary information must be clearly marked as proprietary. The government will not treat any other information as proprietary. The Government reserves the right to contact, or not contact, any party responding to this notice in order to obtain further information for market research purposes. The government will not notify respondents of the results of the evaluation of the information received and will not return submittals to the sender. All interested sources must respond to any potential future solicitation announcements separately from responses to this Request for Information. This is not a solicitation announcement for proposals and the government will not award a contract resulting directly from this announcement.