OMB No. 0960-0817
Section A: Public Comments
We published the 60-day advance Federal Register Notice on November 30, 2020, at 85 FR 76649, and we received the following public comments from the Better Identity Coalition (BIC):
Comment #1: The BIC noted that we changed the Permitted Entity Certification to eliminate the specific reference for detailed Permitted Entity definition, and only reference the generic “Banking Bill.” This appears to leave Service Providers (SP) in the position of providing sufficient reference for clients to determine eligibility (a search using the term “Banking Bill” performed on 1/12/2021 returned a reference to a 2020 piece of legislation, rather than the one related to eCBSV). Based on that information, the BIC asked is this change intentional? If so, does it affect who can participate in the eCBSV Program?
SSA Response #1: SSA did not make any changes to the Permitted Entity Certification (PEC). The correct PEC template is in Exhibit A in the User Agreement. We are using the same template in the Customer Connection. There was an extra PEC template for the initial rollout only on the eCBSV website; however, we will remove that older version to alleviate any confusion.
Comment #2: The BIC also noted that in the Permitted Entity Certification, items under the “Financial Institution Registration” heading SSA does not specifically state that only Financial Institutions (FI) are eligible to participate. While SSA provides a hyperlink to learn more about Permitted Entity Certification, the documentation provided lacks ability to explore that link. The BIC then asked: does this link provide sufficient detail related to Permitted Entity qualification? In addition, for clarity & simplicity, the BIC suggested that SSA add the requirement that participation through an SP is limited to FIs.
SSA Response #2: SSA thanks the BIC for the suggestion. The link on the screen will direct the user back to the eCBSV Website where there is information about the onboarding process, including the FI Registration process. SSA appreciates the suggestion and will consider it for a future update.
Comment #3: The BIC observed that the FI Registration completion notice provides advice to download and save the completed PE certification, but not the Employer Identification Number (EIN) Consent form, nor does it advise the respondents to share copies with the SP. The BIC’s assumption is that the SP needs the EIN to supply to SSA prior to initiation of traffic to eCBSV. Therefore, giving the advice to share with SP would be helpful here. The BIC requested that SSA provide the full package of documents required by the PE, and advise that if the PE is coming through an SP, that they share those documents SSA will require of the SP.
SSA Response #3: The requirement for SPs to manually provide SSA with the EINs of the FI they serve, prior to submitting traffic, was for the Initial rollout only. In the Expanded rollout, FI will use the FI Registration screen to register their entity with SSA. Once this is complete, that FI will be registered to use eCBSV through an SP. SPs will need to send the EIN associated to the transaction when making a request. It will be on each SP to obtain the FI’s EIN as part of their internal business process when adding on FIs.
Comment #4: The BIC remarked that the online enrollment process for FIs using SP does not require entry of the name of the intended SP. They stated that, because SSA is not requiring that information, it is unclear how the SP will ensure that Item #1 from the current User Agreement is complete. Similarly, there is no obvious mechanism for providing the notice of intended use of SPs by an FI (#11 from User Agreement) via the Portal screens. They are asking SSA to please clarify this.
SSA Response #4: As per our response above to Comment #3, the FI does not need to indicate the SP they plan to use. Once they are registered, they can use whichever SP they choose. The SP is required to provide the EIN of the FI where the transaction is coming from. If that FI has not previously registered, the verification service will not process the transaction.
Comment #5: The BIC pointed out that SSA’s sample Entity Registration email contains a reference to a real entity. They requested that SSA’s samples avoid references to any real corporate entities.
SSA Response #5: SSA appreciates this observation, and we will update the sample to remove the reference. We will avoid making any references to real corporate entities in the future.
Section B: Revision to the User Agreement
We are making the following revisions to the User Agreement for eCBSV:
Change #1: We are adding in new language to Section I.B, Definitions, to include definitions for the Cloud Service Provider and the Managed Service Provider.
Justification #1: Since we are adding language regarding these two service providers, we need to define their roles for eCBSV.
Change #2: We are adding the following new language to Section III.A to discuss the Cloud Service Provider and Managed Service Provider:
22. The Permitted Entity must adopt policies and procedures to ensure that the SSN Verification or Written Consent that is maintained in a Managed Service Provider or Cloud Service Provider is encrypted at rest and in transit. The Permitted Entity must not provide the Managed Service Provider or Cloud Service Provider the key to unencrypt the SSN Verification or Written Consent maintained in their environment. The Permitted Entity must also ensure that the SSN Verification or Written Consent is transferred, stored, or processed within the jurisdiction of the United States (i.e., within the continental United States, Hawaii, Alaska, Puerto Rico, Guam, and the Virgin Islands). The Permitted Entity must adopt additional policies and procedures to ensure the security and confidentiality of the SSN Verification or Written Consent maintained in a cloud environment is in accordance with Federal law. The Permitted Entity must verify the effectiveness of policies and procedures to ensure the security and confidentiality of SSN Verification or Written Consent and retain appropriate evidence.
Justification #2: This language better explains the role of the Permitted Entity when they store information on cloud servers or use a Managed Service Provider. We added this language to ensure Permitted Entities understand their requirements.
Change #3: We added the following new language to Section V, A, #5 Technical Specifications and Systems Security, to include the need for Permitted Entities to adopt policies and procedures to ensure the safety of the SSN Verification or Written Consent:
5. The Permitted Entity must adopt policies and procedures to ensure that the SSN Verification or Written Consent is encrypted at rest and in transit. The Permitted Entity must also ensure that the SSN Verification or Written Consent is transferred, stored or processed within the jurisdiction of the United States (i.e., within the continental United States, Hawaii, Alaska, Puerto Rico, Guam, and the Virgin Islands). The Permitted Entity must verify the effectiveness of policies and procedures to ensure the security and confidentiality of the SSN Verification or Written Consent and retain appropriate evidence.
Justification #3: We are including this language to make it clear that the Permitted Entities must ensure the security and confidentiality of SSN Verifications and Written Consent which they store.
We anticipate the current users will need to resign the updated User Agreement. We will use the updated User Agreement with all eCBSV users.
Section C: Terms of Clearance
Upon approving OMB No. 0960-0718 first phase of eCBSV, OMB assigned the following Term of Clearance:
Term of Service:
“The agency will continue to engage with OMB on developing proposals for minimizing the burden associated with this collection via regulatory and potential legislative solutions.”
SSA remains open to discussions with OMB on relevant legislative and regulatory proposals. As well, we note that as eCBSV usage continues, we continue dialogue with its users and can use that information to determine if further legislative or regulatory changes would be necessary for them. Finally, our continued dialogue enables us to develop better ways to minimize burden for the respondents.