eCBSV Addendum - Including Comments and Responses

Addendum to Supporting Statement for

Electronic Consent Based Social Security Number Verification

20 CFR 401.100

OMB No. 0960-NEW

Section A: Brief Summary of the Banking Bill

On May 24, 2018, the Economic Growth, Regulatory Relief, and Consumer Protection Act, Pub. L. No. 115-174, 132 Stat. 1296 (2018) (Banking Bill), became law. The purpose of section 215 of the Banking Bill titled, “Reducing Identity Fraud,” is to reduce synthetic identity fraud. Section 215 of the Banking Bill requires the Social Security Administration (SSA) to provide a Permitted Entity confirmation (or non-confirmation) of fraud protection data (name, date of birth, and Social Security Number (SSN)) based on the SSN holder’s written consent, including by wet or electronic signature. To meet the requirements of the Banking Bill, SSA must either modify an existing system or develop a new system to perform SSN Verifications for “Permitted Entities” as defined in the Banking Bill. A Permitted Entity is a financial institution or service provider, subsidiary, affiliate, agent, subcontractor, or assignee of a financial institution as defined by section 509 of the Gramm-Leach-Bliley Act. In response, SSA is developing the new electronic Consent Based Social Security Number Verification (eCBSV) service.

Section B: Explanation of How the Banking Bill is Driving this Clearance

The Banking Bill requires SSA to disclose to Permitted Entities, verification of an individual’s name, date of birth, and SSN based on the individual’s electronically signed consent. We are building into the new system, oversight and monitoring features to meet related requirements in the Banking Bill that SSA will use to help ensure the security and integrity of the new system and processes. Accordingly, we are aggressively working to build an efficient, accountable, and secure system – leveraging as much of our existing verification infrastructure as possible – to meet the needs of the financial industry to combat synthetic identity fraud, while preserving the privacy of our data.

We will continue to work diligently on all fronts to implement this law as quickly as possible. In June 2020, we will implement an initial rollout of 10 selected Permitted Entities to begin accepting electronic signatures for consent.

Section C: SSA’s Business Process

Permitted Entities seeking to enroll in eCBSV must have followed the enrollment instructions published in the Federal Register Notice at https://www.federalregister.gov/documents/2019/06/07/2019-11995/notice-of-an-initial-enrollment-period-for-our-electronic-consent-based-social-security-number. SSA selected 10 Permitted Entities to participate in the initial rollout of eCBSV in June 2020. Each selected Permitted Entity signed a reimbursable agreement, and SSA collected its prorated share of 50 percent of the program startup costs, as estimated by SSA, as well as, a non‑refundable $3,693 administrative fee via Pay.gov. Prior to the initial rollout in June 2020, SSA will require each Permitted Entity to submit via email, a signed Permitted Entity certification in accordance with the Banking Bill.

Also, before the initial rollout, each Permitted Entity must sign a User Agreement, agreeing to our terms of use and submit it via email to SSA. Upon receipt of both the User Agreement and the Permitted Entity certifications, SSA will use the Permitted Entity’s estimated transactions to determine its annual transaction tier level. The Permitted Entity must provide SSA with advance payment for the full annual cost of all services rendered under the User Agreement. In addition, SSA will use a tiered subscription-based pricing model.

SSA will apply the initial 50 percent program startup cost the Permitted Entity paid to offset their annual tier-based transaction fee associated with their annual transaction tier level. If any Permitted Entity has a remaining balance after applying the 50 percent program startup costs, SSA will require that Permitted Entity to submit its remaining balance via Pay.gov.

Once all enrollment documents are complete and payments made, the Permitted Entity will follow SSA’s technical requirements to connect via an application programming interface to SSA. SSA will authenticate the Permitted Entity and establish a machine to machine connection. Permitted Entities will be able to submit SSN Verification requests after they have obtained the SSN holder’s written consent via wet or electronic signature. Permitted Entities will store the consent and be subject to a compliance review audit performed by an SSA-designated Certified Public Accountant (CPA) firm in accordance with our User Agreement.

Each Permitted Entity can only submit transactions up to the volume limit of its assigned annual transaction tier level. SSA will monitor and track transactions and notify Permitted Entities when they approach their tier limit. Upon notification, Permitted Entities may elect to move to the next higher tier level, and make an additional payment. If the Permitted Entity runs out of transactions in their tier level without a modification, we will cease providing SSN Verifications until we receive additional advance payment.

We will re-evaluate our costs periodically, adjust the annual tier-based transaction fees as necessary, and notify enrollees in advance of any changes.

Section D: Public Comments

We published the 60-day advance Federal Register Notice on December 5, 2019, at 84 FR 66704, and we received the following public comments:

• Comment #1: A commenter stated that the User Agreement contains several provisions that would grant SSA regulatory and examination authority concerning a Permitted Entity’s treatment of PII. Defining PII exceeds SSA’s statutory authority, as the Banking Bill does not grant any additional authorities to SSA with respect to PII. Commenter agrees with our defining and using the terms, “SSN Verification,” “Written Consent,” and “Consent Form” in the User Agreement.
  
  

  • SSA Response #1: We understand the concern and revised broad and general references of “PII” or “confidential information” in the User Agreement to more specific term such as, “SSN Verification,” or “Written Consent,” where applicable.
    
    

• Comment #2: The User Agreement states, “SSA reserves the right to conduct on-site visits to review . . . protection of and security arrangements for confidential information . . . [and] to protect the Written Consent and information contained therein . . .” The commenter states that SSA may only monitor and audit to ensure proper use of the eCBSV system and deter fraud and misuse of the eCBSV, and therefore SSA must narrow the scope of its provisions.
  
  

  • SSA Response #2: We disagree with the commenter’s interpretation of the Banking Bill. The Banking Bill does not supersede or negate all of SSA’s regulatory obligations with respect to the information (i.e., 20 C.F.R 401.145(a)(3)). Further, the Banking Bill expressly authorizes SSA to conduct audits and monitoring to ensure permitted entities properly use eCBSV and to deter permitted entities’ fraud and misuse of eCBSV.
    
    With that said, we revised references of “confidential information” to “SSN Verification” and “Written Consent”, where applicable, to narrow the scope of this provision in the User Agreement. We also revised the User Agreement to make more clear that audits via on-site visits are in accordance with the statutory language of the Banking Bill, which says that SSA will “audit and monitor to … deter fraud and misuse by permitted entities with respect to the database . . .”
    
    

• Comment #3: The breach notification provision in the User Agreement would allow SSA to implement its own breach notification requirement, the authority for which the Banking Bill does not provide, and conflicts with the Banking Bill and GLBA, given the “notwithstanding any other provision of law…” language: “Notwithstanding any other provision of law, including the matter preceding paragraph (1) of section 505(a) of [GLBA], any violation of this section and any certification made under this section shall be enforced in accordance with paragraphs (1) through (7) of such section 505(a) by the agencies in those paragraphs.”
  
  

  • SSA Response #3: We disagree with the commenter’s reading of the statutory language, specifically that the “notwithstanding” language in this section of the Banking Bill applies to violations of the Banking Bill and enforcement of the provisions of the Banking Bill. SSA’s position is that the Banking Bill does not prohibit SSA from requiring Permitted Entities to notify SSA when a breach occurs in their system that maintains the SSN Verification information and Written Consent, in order for SSA to meet its own obligations under OMB Memorandum M-17-12, Preparing for and Responding to a Breach of Personally Identifiable Information.

With that said, we revised the breach notification paragraph to remove the broad references of PII to “SSN Verification” and/or “Written Consent, so the breach notification paragraph is more narrow in scope and applies to the Banking Bill’s specific requirements.

• Comment #4: The User Agreement’s electronic signature requirements are beyond SSA’s authority in the Banking Bill and do not align with ESIGN. The Banking Bill alone governs the terms of the consumer consent needed to access eCBSV.  The commenter explains that the Banking Bill states, “notwithstanding any other provision of law or regulation, a permitted entity may submit a request to the [eCBSV] only . . . pursuant to the written, including electronic, consent . . . and in connection with a credit transaction or circumstance [under FCRA].” The commenter further points out that the Banking Bill states that, “no provision of law or requirement, including section 552a of title 5 . . . shall prevent the use of electronic consent for purposes of this subsection . . .”
  
  

  • SSA Response #4: We disagree with the commenter’s interpretation of the Banking Bill. SSA developed its e-signature standards in accordance with federal guidance, and applicable federal laws, including the Electronic Signatures in Global and National Commerce Act (ESIGN), 15 USC 7001, et seq., and the Government Paperwork Elimination Act. Specifically, in accordance with section 7004(b)(3)(A) of ESIGN, federal agencies have discretion to specify performance standards to ensure accuracy, record integrity, and accessibility of records that are required to be obtained. See also, ESIGN, section 7004(c)(2).  With the above in mind, we revised the language of the electronic signature standards in our User Agreement to make clear we designed the standards to require an e-signature consistent with ESIGN and the level of risk we determined for this type of transaction. Additionally, due to their importance, we incorporated the requisite retention, safeguarding, and audit requirements (consistent with sections IV.B, and VIII of the User Agreement) with respect to electronic signatures into section IV.E of the User Agreement.
    
    

• Comment #5: Commenter has significant operational concerns with electronic consent that is the alternative to form SSA-89: 1) Commenter is confused whether SSA is requiring two check boxes (one for standard terms for a credit application and one for SSA verification) or a single consent, which commenter prefers; 2) lenders likely cannot display all the items we are requiring on one screen; 3) Commenter does not want to display all elements of the request (DOB/name/SSN) on the same screen, for security purposes; and 4) the language on the consent form should meet all other legal regulatory requirements (for example, “plain language” requirements). Commenter also takes issue with SSA requiring that permitted entities not rely entirely on the SSN Verification for authentication purposes.
  
  

  • SSA Response #5: Please see SSA responses 19-21 below for responses to items 1-3 in Comment 5.

Without additional information, we are unable to respond to the comment in Comment #5 (4), which states that “the language on the consent form should meet all other regulatory requirements (for example, “plain language” requirements).” Under the User Agreement, Written Consent must be provided in one of the following ways:

1. Form SSA-89 (Exhibit A, Authorization for SSA to Release SSN Verification) with a wet signature, or

2. Form SSA-89 in “pdf fillable” form with an Electronic Signature, or

3. Electronically with SSA’s consent language as provided in section IV, which is incorporated into the Permitted Entity’s business process.

Form SSA-89 is an agency form that complies with SSA’s plain language requirements. SSA’s consent language template mirrors SSA’s consent policy requirements and complies with SSA’s plain language requirements.

• Comment #6: Section VIII.A.2: Commenter argues that the language in this section is unclear because it subjects insured credit unions to annual audits. As currently drafted, Permitted Entities enrolled in eCBSV are subject to an initial audit within the first year of enrolling. After the initial audit, enrolled Permitted Entities are subject to a subsequent audit. If the Permitted Entity is subject to regulatory enforcement and oversight actions under 12 U.S.C. § 1818, as defined in 12 U.S.C. § 1813(q), and does not have Type I or Type II violations, that Permitted Entity is subject to a subsequent audit once every 5 years after the initial audit. Insured credit unions are not subject to enforcement under 12 U.S.C. § 1818 and § 1813(q). If, however, the Permitted Entity is not subject to regulatory enforcement and oversight actions as described above, that Permitted Entity is subject to an annual audit instead of one every five years.
  
  Commenter suggests that SSA revise this section to use the definition of “Prudential Regulator” from 12 U.S.C. § 5481(24), which includes both the regulatory agencies of financial institutions pursuant to 12 U.S.C. § 1813(q) and National Credit Union Administration which regulates insured credit unions. As currently drafted, insured credit unions would be subject to annual audits because they are not listed in 12 U.S.C. § 1813(q).
  
  

  • SSA Response #6: We considered the comment, and removed the references to 12 U.S.C. 1818 and 12 U.S.C. 1813(q) from this section of the User Agreement, and instead inserted references to section 505(a)(1)-(7) of GLBA. This change more precisely reflects the language of the Banking Bill. We note that the National Credit Union Administration is specifically mentioned in section 505(a)(2) of GLBA.
    
    

• Comment #7: Section VIII.A.2.c: In this section, SSA reserves the right to conduct random audits at SSA’s discretion. Commenter argues that this language “muddies the intent” of the audit section and suggests that if SSA intends to conduct audits in addition to the scheduled audits based on “suspicious activity,” the User Agreement should state that.
  
  

  • SSA Response #7: We have considered this comment, and changed the reference of “random” audits to “audits at SSA’s discretion at any time” in the User Agreement. SSA is specifically authorized to audit Permitted Entities by section 215(g) of the Banking Bill.

• Comment #8: Commenter contends that the Banking Bill is the sole legal authority, which controls the relationship between SSA and a Permitted Entity for the SSN Verification.  As commenter asserts that the Banking Bill is the sole controlling statute, the commenter contends that the Banking Bill overrides the Privacy Act and the Social Security Act requirements as set forth in SSA’s privacy regulations.
  
  

  • SSA Response #8: The Banking Bill, by its own terms, does not override the privacy and disclosure requirements of the Privacy Act and the Social Security Act.  Section 215(f)(1) of the Banking Bill provides:

Notwithstanding any other provision of law or regulation, a Permitted Entity may submit a request to the database…only pursuant to the written, including electronic, consent received by a Permitted Entity from the individual who is the subject of the request. 

This provision does not address any SSA statutory obligation.  This provision speaks specifically to the “Permitted Entity’s” ability “notwithstanding any other law or regulation” to “submit” a request to SSA based on an individual’s written, including electronic, consent.  As this section only refers to the Permitted Entity’s ability to submit a request and not SSA’s obligation to disclose information, we do not believe that this provision overrides SSA’s obligations under the Privacy Act, and the Social Security Act.

Additionally, section 215(f)(3) of the Banking Bill, which refers to the Privacy Act, is specific by the title of the section and the language of the section itself to “electronic consent.”  The title of section 215(f)(3) is “Effectuating Electronic Consent.”  This section provides:

No provision of law or requirement, including section 552a of title 5, United States Code, shall prevent the use of electronic consent for purpose of this subsection or for use in any other consent based verification under the discretion of the Commissioner.

As the title and language of this section is narrowly tailored to the use of “electronic consent,” we do not believe that the Banking Bill forbids or limits SSA’s obligations to comply with the Privacy Act and the Social Security Act requirements.  SSA cannot choose which statutes it follows.  The Banking Bill merely ensures that the Permitted Entity may use an “electronic consent” notwithstanding other laws, including the Privacy Act.  The Banking Bill does not override the remainder of the privacy expectations and requirements set forth in the Privacy Act and the Social Security Act, as set forth in SSA’s regulations. Thus, SSA must give the full effect to the Banking Bill, the Privacy Act, and the Social Security Act unless they are in irreconcilable conflict.  Statutes are to be considered irreconcilably conflicting where “there is a positive repugnancy between them” or “they cannot mutually coexist.”  Ranzanower v. Touche Ross & Co., 426 U.S. 148, 155 (1976).  Deeming statutes in conflict is a disfavorable construction.  Halverson v. Slater, 129 F.3d 180, 186 (D.C. Cir. 1997).

We believe if Congress had intended to override completely the Privacy Act and the Social Security Act requirements, Congress would have drafted the language in section 215 to encompass the Privacy Act as a whole, in lieu of referring specifically to electronic consent. Alternatively, if Congress intended SSA to disclose SSN Verifications to a Permitted Entity regardless of the Privacy Act and the Social Security Act considerations, Congress could have drafted the language to authorize SSA to make such disclosures as Congress has in other instances (e.g., the Illegal Immigration Reform and Immigrant Responsibility Act; the Help American Vote Act; the Affordable Care Act). Congress neither drafted the Banking Bill to override all aspects of the Privacy Act or the Social Security Act nor drafted the Banking Bill to obligate SSA to provide a Permitted Entity an SSN Verification. Accordingly, SSA must comply with its obligations under the Privacy Act and the Social Security Act.

• Comment #9: Commenter recommends to remove the definition and use of the term “PII,” (p.3) and use of the term “confidential information,” throughout all draft materials.
  
  

  • SSA Response #9: We understand the concern and revised broad and general references of “PII” or “confidential information” in the User Agreement to more specific term such as, “SSN Verification,” or “Written Consent,” where applicable.
    
    

• Comment #10: Paragraphs III.A.9-10(p.6) misrepresent the nature of financial institutions’ third‑party vendor management regulatory obligations, and III.A.11 exceeds SSA’s authority with regards to data security. SSA should therefore remove or change this language.
  
  

  • SSA Response #10: We considered this comment, and we decline to make the suggested changes. The Banking Bill authorizes SSA to act on SSN Verification requests submitted by Permitted Entities based on electronic consent to disclose. The Banking Bill defines a Permitted Entity as either a financial institution or a service provider, subsidiary, affiliate, agent, subcontractor, or assignee of a financial institution. Thus, the parties with whom SSA can have a legal relationship for the purpose of disclosing SSN Verifications pursuant to the User Agreement are either a) a financial institution (who signs the User Agreement and provides SSN Verification requests on its own behalf), or b) a Permitted Entity that is a service provider, subsidiary, affiliate, agent, subcontractor, or assignee of a financial institution (in which case, the Permitted Entity is submitting SSN Verification requests on behalf of one or more financial institutions). The language in these sections ensures that primary responsibility for complying with the terms of the User Agreement fall upon the Permitted Entity signing the User Agreement.
    
    

• Comment #11: In section IX.A (p.17-18) and Paragraph XV.A.3 (p.20), the term “PII” should be replaced with “SSN Verification.”
  
  

  • SSA Response #11: We understand the concern, and we revised broad and general references of “PII” or “confidential information” in the User Agreement to more specific term such as, “SSN Verification,” or “Written Consent,” where applicable.
    
    

• Comment #12: Audits must be limited to the purposes specified in the Banking Bill. The Banking Bill grants SSA the authority to monitor and audit for the narrow purposes of ensuring proper use of eCBSV and to deter fraud and misuse of the system. SSA does not have the authority to examine the privacy or data security practices of Permitted Entities.
  Therefore:
  
  The following language should be deleted from Paragraph III.A.16 (p.7) of the Draft User Agreement: “SSA reserves the right to conduct on-site visits to review the Permitted Entity’s and each of its Financial Institution’s, if any, documentation and in-house procedures for protection of and security arrangements for confidential information and adherence to terms of this User Agreement.”
  
  

  • SSA Response #12: SSA will not delete the language cited, but has revised this language by narrowing the scope from “confidential information” to “SSN Verification and Written Consent.” Additionally, we note that SSA is specifically authorized to audit Permitted Entities by section 215(g) of the Banking Bill.
    
    

• Comment #13: The following language in Paragraph V.A.3 (p.11) should be deleted: “The Permitted Entity shall process all confidential information under the immediate supervision and control of Authorized Users in a manner that will protect the confidentiality of the records; prevent the unauthorized use of confidential information; and prevent access to the records by Unauthorized Users.”
  
  

  • SSA Response #13: SSA did not delete this paragraph. However, we note that we revised the user agreement to more accurately reflect the scope of this provision by replacing “confidential information” with “SSN Verification and Written Consent,” and we removed references to authorized/unauthorized users.

• Comment #14: The entirety of sections V.B.1 (p.12) of the Draft User Agreement should be deleted. As discussed, regulating the manner in which Permitted Entities manage and secure data exceeds the authorities granted to SSA by the Banking Bill.
  
  With regard to Paragraph V.B.2, SSA does not have authority under the Banking Bill to establish additional breach notification requirements for Permitted Entities. As such, the entirety of this paragraph should be deleted and replaced with the following:

When the Permitted Entity becomes aware or suspects that SSN Verifications have been lost or compromised, the Permitted Entity, in accordance with its incident reporting process, shall provide immediate notification of the incident to the primary SSA contact, or alternate SSA contact (See section XV for the phone numbers of the designated primary and alternate SSA contacts).

• SSA Response #14: We disagree with the commenter’s reading of the statutory language, specifically that the “notwithstanding” language in this section of the Banking Bill applies to violations of the Banking Bill and enforcement of the provisions of the Banking Bill. SSA’s position is that the Banking Bill does not prohibit SSA from requiring Permitted Entities to include certain information regarding the incident/breach when notifying SSA, in order for SSA to meet its own obligations under OMB Memorandum M-17-12, Preparing for and Responding to a Breach of Personally Identifiable Information.

• Comment #15: Section V.C (p.13) should be rewritten as follows to reflect existing regulatory obligations:

The Permitted Entity and all Financial Institutions it services, if any, shall process all SSN Verifications and Consent Forms under the immediate supervision and control of an Authorized User in a manner consistent with the Permitted Entity’s certification of compliance with the Gramm-Leach-Bliley Act.

• SSA Response #15: SSA has not adopted the suggested new language, but has revised the language by narrowing the scope from “confidential information” to “SSN Verifications and Written Consent.”
  
  

• Comment #16: The following changes should be made to Paragraph IX.A.1. (p.17):

- Item 1.A should be rewritten as follows: Multiple failures to comply with this User Agreement.

- Item 1.C should be deleted; and

- Item 1.D should be rewritten as follows: A violation of retaining Written Consents.

• SSA Response #16: We disagree with the commenter’s recommendations, unless they provide support or justification for the changes.
  
  

• Comment #17: The following language should be removed from Paragraph IX.A.3: “either unauthorized disclosure of PII or….”
  
  

  • SSA Response #17: SSA revises this paragraph as follows:

“Type III noncompliance consists of failures that are minor in nature because they would not result in either unauthorized disclosure of SSN Verifications or Written Consents or unauthorized SSN Verification requests being submitted to SSA.”

• Comment #18: There is no need for the Electronic Signatures Requirement document and it, along with any reference to it in the Draft User Agreement, should be removed. As currently drafted, it erroneously conflates the requirements of E-SIGN Act that are applicable to other circumstances (e.g., obtaining a consumer’s consent to receive disclosures electronically), and therefore does not comport with the Banking Bill. The User Agreement must only include a requirement that an individual’s electronic signature, as defined in the E-SIGN Act, is obtained for a valid electronic consent.
  
  

  • SSA Response #18: We disagree with the commenter’s interpretation of the Banking Bill. SSA developed its e-signature standards in accordance with federal guidance and applicable federal laws, including the Electronic Signatures in Global and National Commerce Act (ESIGN), 15 USC 7001, et seq., and the Government Paperwork Elimination Act. Specifically, in accordance with section 7004(b)(3)(A) of ESIGN, federal agencies have discretion to specify performance standards to ensure accuracy, record integrity, and accessibility of records that are required to be obtained. See also, ESIGN, section 7004(c)(2).  With the above in mind, we revised the language of the electronic signature standards in our User Agreement to make clear we designed the standards to require an e-signature consistent with ESIGN and the level of risk we determined for this type of transaction. Additionally, due to their importance, we incorporated the requisite retention, safeguarding, and audit requirements (consistent with sections IV.B, and VIII of the User Agreement) with respect to electronic signatures into section IV.E of the User Agreement.
    
    

• Comment #19: Additional language must be added to clarify that consumer consent for an eCBSV verification does not require its own separate and distinct consent “check box.” A single consent is vastly preferred as it is extremely unlikely that an application would be allowed to go through if a user did not consent to both standard terms and conditions and the eCBSV consent. Stated differently, requiring separate consent or dual consents would frustrate the clear purpose of the Banking Bill. Thus, while the Draft User Agreement states that written, including electronic, consent can be incorporated into existing electronic workflows or business processes, an explicit statement regarding single consent is critical. Therefore, section IV.A.1.c (p.8) of the User Agreement should be rewritten as follows:
  
  

An electronic form of consent, which can be incorporated into the Permitted Entity’s or Financial Institution’s electronic workflow or business process, including any existing process to capture an individual’s consent, signed electronically by the SSN holder with an Electronic Signature. See SSA’s Written Consent Template….”

• SSA Response #19: We understand the industry’s preference that the SSN holder’s consent that SSA verify his or her fraud protection data is included with current consent. However, the industry’s preference heightens the risk that the SSN holder would not provide informed consent for SSA’s SSN Verification. We also have some concerns that one consent checkbox will heighten consumer confusion regarding consent, because the standard terms and conditions for a credit application or other FCRA permissible purpose are not the same as SSA’s requirements for an SSN holder to consent to SSN Verification by SSA. Further, two checkboxes more accurately captures the SSN holder’s intent to apply his or her binding electronic signature to consent to SSA disclosing the SSN Verification.
  
  Further, our recommendation is consistent with SSA’s best practices in assessing consents submitted for disclosure purposes outside the context of CBSV/e-CBSV process.
  
  We disagree with the statement that “requiring separate consent or dual consents would frustrate the clear purpose of the Banking Bill.” SSA reads the Banking Bill in concert with the Social Security Act and the Privacy Act, among other statutes. Therefore, additional requirements exist under the Social Security Act and the Privacy Act to protect from unauthorized disclosures. These additional requirements do not frustrate the intent of section 215 of the Banking Bill, which was enacted to reduce synthetic identity fraud.
  
  Therefore, we considered this comment, but decline to make the recommended changes. The recommended language removes SSA’s consent requirements and replaces them with “any existing process to capture an individual’s consent.” We do not agree with the recommended language because the term “any existing processes” is too vague. There is an unknown number of “existing processes” to capture an individual’s consent for the banking industry, and we are uncertain whether the standards behind those “existing processes” are compatible with SSA’s consent requirements. SSA cannot agree to remove its consent requirements, without assurance that the other “existing processes” meet SSA’s consent requirements and comply with our policies.
  
  

• Comment #20: Paragraph IV.A.2 (p.8-9) of the Draft User Agreement should be deleted. The requirements of this section impose operational challenges (if not impossibilities) and are wholly inconsistent with SSA’s stated intent of allowing Permitted Entities to effectuate electronic consent as part of existing consent workflows and business processes. Further, as described, many of these requirements may run counter to existing financial privacy rules.
  
  

  • SSA Response #20: SSA made a business decision to expand financial institutions’ options beyond completing form SSA-89, and to allow financial institutions to obtain electronic consent through existing business processes. The cited User Agreement paragraph reflects SSA’s current consent policy, which requires at a minimum that a part of the requested records appear immediately above the consenting individual’s signature of the consent document. The electronic nature of electronic consent incorporated into a financial institution’s electronic workflow or business process does not alter the basis for this policy. Not adhering to SSA’s existing policy potentially increases the risk that SSA will disclose an SSN holder’s information without his or her express consent.

To the extent the commenter is concerned that an individual’s fraud protection data is visible on a mobile device or retail point-of-sale environment, we recommend the financial institutions include data shielding for their consumers.

• Comment #21: To ensure that Permitted Entities can incorporate consent for eCBSV into existing workflows and business processes, we recommend the following modifications to Exhibit C:
  
  

- Delete the requirement to include the headline “Authorization for the Social Security Administration to Disclose Your Social Security Number Verification.”

- SSA should provide flexibility to Permitted Entities with regard to eCBSV-specific consent language. In addition to the language offered in the Draft User Agreement, additional options for the main consent text should be available that achieve the requisite consent but are more compatible with commonly used consent processes, such as:

I authorize [name of Financial Institution/Permitted Entity] to verify whether the name, Social Security number, and date-of-birth I have provided match with records maintained by the Social Security Administration.

- Add language to the User Agreement providing Permitted Entities the ability to make non-substantive, conforming modifications to the language to ensure its clarity and conformity with existing workflows and business processes.

• SSA Response #21: We considered this comment, and we decline to make the recommended changes. Permitted Entities should incorporate the headline along with the consent language into existing workflows and business processes. We included that language in the consent template as one method to ensure the SSN holder understands the purpose of the consent is to authorize SSA to disclose SSN Verification to the Permitted Entity.
  
  SSA must retain some control over the information a financial institution provides a consumer regarding the consumer’s consent that SSA disclose fraud protection data verification to the consumer’s chosen financial institution. SSA has specific consent requirements. The language in the User Agreement and consent template is consistent with current disclosure policy, which is intended in part to reduce unauthorized disclosures. SSA’s current consent policy requires that an individual give informed consent to SSA disclosing the SSN holder’s SSN Verification. Allowing flexibility to Permitted Entities to develop consent language invites increased risk that the consent given by the consumer is not informed.
  
  Further, the proposed language in comment #21 is insufficient. First, the language is backwards, with the consumer giving the Permitted Entity consent to verify his or her information with SSA. Instead, the consumer must consent to SSA disclosing the SSN Verification to the Permitted Entity. Additionally, the proposed language does not limit the time period for which the consent is valid, and does not explain the consent is for one-time validation.

We also considered and declined to make the recommended change in Comment #21 to provide Permitted Entities the ability to make “non-substantive, conforming modifications to the language to ensure its clarity and conformity with existing workflows and business processes.” We do not agree with the recommended language, because allowing Permitted Entities to modify the language in an unspecified fashion is too vague. Including this language could amount to an unknown number of modifications to capture an individual’s consent, and we are uncertain whether the standards behind those modifications will be compatible with the agency’s consent requirements.

• Comment #22: The first paragraph of section IV.D (p. 10) should be removed and replaced with the following:

If the SSN holder is a minor child (under age 18), the Written Consent must be signed by the child’s parent or legal guardian. If the SSN holder is a legally incompetent adult, the Written Consent must be signed by the individual’s legal guardian.

• SSA Response #22: While we do not agree with amending the language as proposed, we have revised this section of the user agreement.

To accept the proposed language, would be inconsistent with the Office of Inspector General’s 2019 CBSV audit recommendations regarding proof of consent for minors and incompetent adults. Although a parent or legal guardian who is authorized to act on behalf of a minor or legally incompetent adult stands in the shoes of the minor or legally incompetent adult for purposes of disclosure (20 C.F.R. 401.75), the regulations require SSA to verify the relationship between the parent or legal guardian and a minor or legally incompetent adult. See 20 C.F.R. 401.45(b)(6).

We amended the User Agreement to allow a parent or legal guardian to execute Written Consent using any of the methods listed in the User Agreement. However, in addition to Written Consent on behalf of the minor or legally incompetent adult, SSA requires that a Permitted Entity also obtain proof of the relationship between the parent or legal guardian and the minor child or legally incompetent adult before the Permitted Entity makes an SSN Verification request. Because the Permitted Entities, not SSA, are collecting the consent, the Permitted Entities must collect the relationship validation information and preserve it with the consent in order for that consent to be valid.

• Comment #23: Paragraph VIII.A.2.a should be rewritten as follows:

If the Permitted Entity is subject to supervision by a Federal banking agency, as defined in 12 U.S.C. § 1813(q), the Board of the National Credit Union Administration, or the Bureau of Consumer Financial Protection , and has no Type I or Type II violations….”

• SSA Response #23: The agency has considered this comment, and declines to make the suggested change. However, we refer to the modifications we cited in our response to comment #6, above.

• Comment #24: Section VIII.A.2.b should be rewritten as follows:

If the Permitted Entity is not subject to supervision by a Federal banking agency, as defined in 12 U.S.C. § 1813(q), the Board of the National Credit Union Administration, or the Bureau of Consumer Financial Protection,….”

• SSA Response #24: The agency has considered this comment, and declines to make the suggested change. But, we refer to our response to comment 6, above.
  
  

• Comment #25: Section VIII.A.2.c should be rewritten to reflect SSA’s intent to conduct additional audits based on suspected violations of the terms of the User Agreement, such as:

SSA reserves the right to conduct additional audits of a Permitted Entity if SSA has reason to believe the Permitted Entity is in material violation of the terms of the User Agreement.

• SSA Response #25: We have considered this comment, and have changed the reference of “random” audits to “audits at SSA’s discretion at any time” in the User Agreement. SSA is specifically authorized to audit Permitted Entities by section 215(g) of the Banking Bill.

• Comment #26: Section I.C. (p.3) should be deleted and rewritten as follows:

Legal authority for providing SSN Verifications to the Permitted Entity is the SSN holder’s written, including electronic, consent as authorized by the Banking Bill.

• SSA Response #26: The Banking Bill, on its own terms, does not override the privacy and disclosure requirements of the Privacy Act and the Social Security Act.  See section 215(f)(1) and (3). These provisions, as written, do not give SSA legal authority to disclose the SSN Verification.

Section 215(f)(1) speaks specifically to the “Permitted Entity’s” ability “notwithstanding any other law or regulation” to “submit” a request to SSA based on an individual’s written, including electronic, consent.  As this section only refers to the Permitted Entity’s ability to submit a request and not SSA’s obligation to disclose information, we do not believe that this provision overrides SSA’s obligations under the Privacy Act, and the Social Security Act.

Similarly, the plain language of section 215(f)(3) shows that the Banking Bill merely ensures that the Permitted Entity may use an “electronic consent” notwithstanding other laws, including the Privacy Act (specifically, the Privacy Act’s requirement to obtain written consent). As the title and language of this section is narrowly tailored to the use of “electronic consent,” we do not believe that the Banking Bill forbids or limits SSA’s obligations to comply with the Privacy Act and the Social Security Act requirements. 

We believe if Congress had intended to override completely the Privacy Act and the Social Security Act requirements, Congress would have drafted the language in section 215 to encompass the Privacy Act as a whole, in lieu of referring specifically to electronic consent. Alternatively, if Congress intended SSA to disclose SSN Verifications to a Permitted Entity regardless of the Privacy Act and the Social Security Act considerations, Congress could have drafted the language to authorize SSA to make such disclosures, as Congress has in other instances (e.g., the Illegal Immigration Reform and Immigrant Responsibility Act; the Help American Vote Act; the Affordable Care Act). Congress neither drafted the Banking Bill to override all aspects of the Privacy Act or the Social Security Act nor drafted the Banking Bill to obligate SSA to provide a Permitted Entity an SSN Verification. Accordingly, SSA must comply with its obligations under the Privacy Act and the Social Security Act.

• Comment #27: The following language should be removed from section II of the Draft User Agreement: “Exceeding the scope of the Written Consent as specified in the Written Consent, violates Federal law and subjects the Permitted Entity to civil and criminal liability.” That language should be replaced with the following:

Exceeding the scope of the Written Consent as specified in the Written Consent, violates the terms of this User Agreement and may result in a referral to the appropriate agency as described in the Banking Bill.

• SSA Response #27: SSA rejects this recommendation, as the Banking Bill does not wholly replace other authorities that govern the disclosure of the SSN Verification, including the Privacy Act.

• Comment #28: Paragraph VIII.D.B (p.17) should be deleted.

• SSA Response #28: We have considered this comment, and we disagree. We edited this language to insert “In accordance with Federal law” at the beginning of the sentence to reflect that fact that SSA may make such referrals under Federal law.

• Comment #29: The term “commercially reasonable uptime and availability” in Paragraph III.B.5 (p.8) must be defined as at least an SLA level of 99.9% uptime and availability.
  
  

• SSA Response #29: While we appreciate this expectation and have considered the comment, we decline to make the change. The Banking Bill only requires that SSA provide “commercially reasonable uptime and availability.” It does not specify any figures associated with that standard.

• Comment #30: Language should be added to section V.A. of the Draft User Agreement stating that eCBSV architectures will ensure response time SLA, as measured by request initiation to message receipt, is appropriate to meet real-time objectives. This language should specifically state a target response time of <250ms with 99.9% of all transactions delivered in <400ms.

• SSA Response #30: While we appreciate this expectation and have considered the comment, we decline to make the change. The Banking Bill only requires that SSA provide “commercially reasonable uptime and availability.” It does not specify any figures associated with that standard.

• Comment #31: Language should also be added to section V.A. that clearly articulate maintenance windows and planned outages or period of degraded service.

• SSA Response #31: We reviewed this comment, but decline to make the change. Such information will be provided on SSA’s eCBSV website, and to enrolled Permitted Entities via the eCBSV service.

• Comment #32: Paragraph III.A.3 conflates the intent of the Banking Bill with regard to the real‑time versus batch response time expectation of eCBSV and should be rewritten.

• SSA Response #32: We reviewed this comment and have changed the User Agreement to distinguish between real-time and batch format.

• Comment #33: Section X.2. should be expanded to clarify what types of limited changes Permitted Entities should expect. Permitted Entities should be given at least six months advance notice of substantive or operational changes, including changes that would impact the limits on the number of SSN Verification requests.

• SSA Response #33: We reviewed this comment, but decline to make the change. SSA will provide as much advance notice as is possible for any substantive or operational changes.

• Comment #34: This cost burden includes only the 10 Permitted Entities that were selected in the initial rollout, and estimates that there will be 307 million people whose SSNs SSA will verify. We ask that SSA provide more detail on how it reached the estimate of 307 million, and if that is representative of the 10 Permitted Entities that are part of the initial rollout, or if that estimate includes a broader group of eCBSV participants that will likely be part of the expanded rollout.

• SSA Response #34: We provided in a note below the estimated volume which stated, “The 10 selected Permitted Entities estimated total annual volume at 614M. Since the expanded rollout will occur within 6 months of the initial rollout, we estimated volume at 50% of 614M = 307M.”

• Comment #35: We ask SSA to provide more information regarding this fee schedule and the assumptions used in it.

SSA Response #35: The current published fee schedule reflects the reported estimated annual volumes of the Permitted Entities that applied during the open enrollment period published in the Federal Register, July 2019.  We based the tiers on average volumes within each tier and currently distribute the costs of usage for all users during the initial and expanded rollouts.  Each fiscal year, we will review reported volumes and costs and make necessary changes to the fee schedule to reflect the activity of all Permitted Entities enrolled and adequately distribute costs.  As we expand the eCBSV services to additional users, we will consider adding additional tiers.

• Comment #36: This details the cost burden for only the 10 Permitted Entities involved in the initial rollout; we ask SSA to explain whether additional PRA notices and cost burdens will be provided to reflect the expanded rollout.

• SSA Response #36: SSA will develop another Federal Register Notice prior to the expanded rollout with the applicable cost of all participating Permitted Entities in the expanded rollout.

• Comment #37: A commenter suggested that SSA create additional tiers that more evenly distribute the costs of use of the service. In particular, they suggested SSA consider mitigating the impact of processing more than 200,000 transactions (and less than 50 million) by adding additional tiers in that strata. For example, there might be a tier from 200,001 to 5,000,000 transactions, which may allow SSA to assign a fee more appropriate to the number of transactions (and significantly lower than $276,500). In short, the commenter suggests that additional tiers for the fee categories would allow for a more gradual fee escalation and ensure that costs are more narrowly tailored to a permitted entities' transaction volume.

• SSA Response #37: The current published fee schedule reflects the reported estimated annual volumes of the Permitted Entities that applied during the open enrollment period published in the Federal Register, July 2019. We based the tiers on average volumes within each tier and currently distribute the costs of usage for all users during the initial and expanded rollouts. Each fiscal year, we will review reported volumes and costs and make necessary changes to the fee schedule to reflect the activity of all Permitted Entities enrolled and adequately distribute costs. As we expand the eCBSV services to additional users, we will consider adding additional tiers.

• Comment #38: First, we do not agree with SSA's estimation of time burden. We believe that most permitted entities will require significantly more time than the 80 projected hours for "following SSA requirements to configure application program interface." Between the marshaling of resources, assignment of the task, development of the program, and user testing thereof, time commitment is almost certain to exceed 80 hours.

Second, the average theoretical hourly cost amounts for CPA firms are based on general data, and are not predicated on the financial industry specialists that the SSA would ultimately need to hire given the degree of risk exposure from using the eCBSV service (with its associated sensitive data points). We anticipate that this sort of specialization would require significantly more than the stated average hourly cost of $33.89. Moreover, we note that the costs to the institution would likely include more than just accounting resources; a financial institution's time commitment to support the audit can also be expected to add to the estimated 80 hours, depending on the volume of its eCBSV service usage.

• SSA Response #38: SSA used the best available information to make an educated estimate of the time burden and hourly cost amounts of participants. Once initial rollout participants have completed the requirements, with their assistance, we will be able to update the time burden estimates associated with this Information Collection. Regarding the hourly cost figure cited by the commenter, we also note that this is a theoretical cost, not an actual cost we are requiring. We understand that any figures associated with such an undertaking is an estimate, and that it may not be entirely accurate.

• Comment #39: Are the definitions in the draft User Agreement standard, or did SSA develop them specifically for the purpose of eCBSV?

• SSA Response #39: New terms and concepts that stem from or came after the Banking Bill’s enactment were developed specifically for this purpose. Other terms predated the Banking Bill and were taken from other, existing sources, such as the CBSV manual User Agreement, or the laws, regulations, and formal guidance standards referenced earlier in the discussion (e.g. the Privacy Act, the Social Security Act, OMB Circulars). The majority of the definitions in the eCBSV draft User Agreement are new and stem from the Banking Bill.

• Comment #40: Is SSA confident their proposed eCBSV process will ensure sufficient identity proofing?

• SSA Response #40: SSA’s SSN Verification does not provide proof or confirmation of identity, nor was it intended to do so. eCBSV is designed to confirm for Permitted Entities whether the name, SSN, and DOB they submitted to us matches our records. eCBSV does that by providing a “yes” or “no” response. If SSA’s records show that the SSN holder is deceased, eCBSV returns a death indicator. SSN Verifications do not verify an individual's actual identity. In addition, eCBSV does not verify employment eligibility, nor does it interface with the Department of Homeland Security’s (DHS) verification system or satisfy DHS’s I-9 requirements.

• Comment #41: Is SSA’s death indicator based on SSA’s own records, or on the records of other parties?

• SSA Response #41: SSA receives death information from multiple sources, including States, funeral homes, and reports from family members of the deceased, etc. When SSA’s systems provide a death indicator in response to an SSN Verification request, the system does not indicate the originating source of the death for the SSN holder.

• Comment #42: How long is an eCBSV name-SSN match verification valid for?

• SSA Response #42: A Written Consent is valid for 90 calendar days, and it can only be used for one business purpose, regardless of the time that has lapsed since SSA provided the verification. For example, if a Permitted Entity verifies the fraud protection data of a member of the public who has applied with the institution for a home loan, and that same member of the public later applies at the institution for an auto loan, the Permitted Entity must, if it seeks another SSN Verification from SSA, submit a new request to SSA based on a new Written Consent that specifies the new purpose.

• Comment #43: Why does SSA not recognize power of attorney when it comes to SSN Verification? Why can legal guardians not provide consent on behalf of a minor or adult for whom they have power of attorney?

• SSA Response #43: We have amended the User Agreement to reflect our existing policy regarding power of attorney. Our power of attorney policy is as stringent as our consent policy. The Permitted Entity may accept Written Consent signed by a third party with power of attorney only if the power of attorney meets SSA’s consent policy: the SSN holder granting the power of attorney signs the papers granting the power of attorney and those papers state exactly what information SSA should disclose to the Permitted Entity.

A legal guardian does not need power of attorney to execute Written Consent on behalf of his or her ward. As noted in SSA Response #22, before a Permitted Entity can submit an SSN Verification request on behalf of a minor or legally incompetent adult, a legal guardian must provide a copy of a court order or other competent evidence of guardianship to verify the legal guardian’s relationship with the minor or an adult adjudged to be legally incompetent. 20 C.F.R.  401.45(b)(c).

• Comment #44: A commenter stated they opposed SSA’s statement in the draft User Agreement that companies could only use an SSN Verification for one business purpose, and for a limited time period of 90 days. The comment expressed their understanding based on prior, pre‑PRA Notice publication discussions with SSA was that they would be able to re-use the information.

• SSA Response #44: We considered this comment and decline to make any changes to the User Agreement. Permitted entities must use the SSN Verification only the purpose(s) stated in the Written Consent, which is limited to the purposes stated in the Banking Bill. However, as stated in the User Agreement, section III. A. 20., the Permitted Entity and any Financial Institution(s) it services must not reuse the SSN Verification. The Permitted Entity and any Financial Institution(s) it services may mark their own records as “verified” or “unverified.”

• Comment #45: SSA should distinguish between financial institutions and non-financial institution service providers regarding the obligation to obtain and maintain proof of consent. Commenter said that because non-FI service providers essentially served as the middleman between the FIs and SSA, and do not themselves have contact with consumers, the service providers should not be obligated to obtain or maintain consent.

• SSA Response #45: We considered this comment, and revised the User Agreement to make clearer that whichever entity obtains the Written Consent must maintain proof of consent. Permitted Entities who are the “non-FI service providers” will still need to confirm that the Financial Institutions they service comply with such requirements in the User Agreement.

• Comment #46: SSA should provide, in writing, commitment to having the system meet “commercially reasonable” standards regarding times for the system to be up and running; response time; availability; and reliability. SSA should be specific about the standards we would commit to.

• SSA Response #46: While we understand your expectations and have considered this comment, we decline to make any changes to the User Agreement.

• Comment #47: In the current draft User Agreement, SSA states they can change the method of notification to companies as needed. Commenter would like SSA to commit in writing to providing at least 90 days’ advance notice to companies before changing anything in the User Agreement.

• SSA Response #47: We reviewed this comment but decline to add this to the User Agreement. SSA will provide as much advance notice as is possible for any changes to the User Agreement.

• Comment #48: Should we have a process in place to delete inquiries sent to eCBSV in case of an Identity Theft (send a delete request when bank inform us that a particular application was fraudulent)? The enabling statues’ identity verification under GLBA vs. FCRA use cases. The User Agreement as currently written and available for public comment does not address this question. Will other FCRA impacts/requirements direct what is required to SSA? Please specify use cases for what eCBSV can be used for.

• SSA Response #48: SSA does not require Permitted Entities to delete inquiries identified as fraudulent.

• Comment #49: If we are not able to obtain a response because the system is down or no response received timely, are we allowed to ping SSA multiple times until the system is up and working properly?

• SSA Response #49: We considered this comment, and revised the User Agreement to make clearer that Permitted Entities may continue sending inquiries while the system is down without obtaining new consents each time.

• Comment #50: Will the PII data be returned by eCBSV in the response message or is the Social Security Administration planning to just return a unique identifier? Unique Identifier is preferred.

• SSA Response #50: We considered this comment, and decided to remove the original data sent to us in the output response. The output response format will be updated and shared in the technical specifications documentation.

• Comment #51: Can we store our converted responses? Can we share a previous response if the system is down? With or without details from a previous response?

• SSA Response #51: SSA cannot respond to the commenter’s proposed use case. SSA can note that if the eCBSV system is down, the Permitted Entity may resubmit a proper request to the eCBSV system that conforms to the Banking Bill and User Agreement requirements until it receives a successful response. In addition, SSA notes that the User Agreement states that a Permitted Entity or Financial Institution may mark its records in a separate repository as “verified” or “unverified.”

• However, if a Permitted Entity or Financial Institution relies upon and uses its separately marked data in its own repository to respond to subsequent verification requests unrelated to an eCBSV SSN Verification request, the Permitted Entity or Financial Institution must not represent that such verification from its own repository is an SSA SSN Verification. See section 1140 of the Social Security Act. It is a verification made solely by the Permitted Entity or Financial Institution, based upon its own records and information and the Permitted Entity or Financial Institution bears full responsibility for the accuracy of its verification representations. SSA also notes that SSA’s SSN Verification is limited to the purpose authorized in the Written Consent by the SSN number holder, and which must be limited to the purposes set forth in the Banking Bill. See section 215(f)(1) of the Banking Bill. This requirement remains after the termination of the User Agreement and any changes to a Permitted Entity’s status. SSA has revised the User Agreement to make clear the Permitted Entities’ obligations with respect to already-verified data.

• Comment #52: We would like reuse information to be added to the User Agreement on page 10.

• SSA Response #52: We reviewed this comment and remind the commenter that as stated in the User Agreement, section III. A. 20., the Permitted Entity and any Financial Institution(s) it services must not reuse the SSN Verification. The Permitted Entity and any Financial Institution(s) it services may mark their own records as “verified” or “unverified.”

• Comment #53: Can banks refuse to process an application for the consumer if the consent (electronic or on a hard copy) is not provided?

• SSA Response #53: Permitted Entities must decide whether they should or should not process an application without submitting an SSN Verification request to SSA (because the SSN holder refused to consent to SSA’s disclosure). SSA cannot advise on the Permitted Entity’s process. SSA notes that Permitted Entities must not submit an SSN Verification request to SSA if the SSN holder refused to sign the consent.

• Comment #54: How can evidence of the consent be presented when processing applications over the phone (voice)? Can the bank read the consent language to the consumer and record the conversation and consumer’s explicit consent to send an inquiry to eCBSV? Would recording of the conversation be a sufficient evidence of the consent?

• SSA Response #54: The eCBSV User Agreement identifies that “a sound recording of a person’s voice expressing consent” is an acceptable form of electronic signature and is consistent with section 7006 of the E-SIGN Act so long as all other related requirements in the eCBSV User Agreement are satisfied – see section IV.  For the recording of an individual expressing consent to a Permitted Entity over the telephone to be considered sufficient for evidence purposes from an electronic signature standpoint, the person being recorded must clearly show intent to “sign,” and such recording must be attached to or logically associated with the Consent, and be retained in a manner that preserves its integrity for the period of time specified in the eCBSV User Agreement for auditing purposes, and meet federal or state laws regarding recording consumers.

• Comment #55: Will minors be allowed to consent electronically or would Banks need to obtain a wet signature and then send an inquiry to eCBSV?

• SSA Response #55: We amended the User Agreement to allow a parent or legal guardian of a minor to execute Written Consent using any of the methods listed in the User Agreement. However, in addition to Written Consent on behalf of the minor or legally incompetent adult, SSA requires that a Permitted Entity also obtain proof of the relationship between the parent or legal guardian and the minor child or legally incompetent adult before the Permitted Entity makes an SSN Verification request. Because the Permitted Entities, not SSA, are collecting the consent, the Permitted Entities must collect the relationship validation information and preserve it with the consent in order for that consent to be valid.

• Comment #56: In the User Agreement language, which company name has to be included on the PE certification, the FI or both the FI and the service provider?

• SSA Response #56: Every Permitted Entity must provide SSA with a Permitted Entity Certification with their company information. This includes every financial institution or service provider, subsidiary, affiliate, agent, subcontractor, or assignee of a financial institution entering into and signing a User Agreement with SSA, and every financial institution they service.

• Comment #57: Exhibit B of the User Agreement: do we need to request each bank to complete Exhibit B on the top of requesting banks to execute specific agreements?

• SSA Response #57: Yes, every Permitted Entity must provide SSA with a Permitted Entity Certification with their company information. This includes every financial institution or service provider, subsidiary, affiliate, agent, subcontractor, or assignee of a financial institution entering into and signing a User Agreement with SSA, and every financial institution they service.

Section E: Changes to the Collection Instruments:

• Change #1:  We revised broad and general references of “PII” or “confidential information” in the User Agreement to more specific term such as, “SSN Verification,” or “Written Consent,” where applicable. In addition, we moved details on consent types to Section IV.

Justification #1:  After review of comments we received pertaining to the User Agreement language, specifically comments 1-4 above, we decided to change the language used to more specific terms, and moved details of consent types to Section IV for clarification purposes.

• Change #2: We removed duplicate content in Section II, and renamed it, “SSN Verification Does Not Provide Proof or Confirmation of Identity.”
  
  Justification #2: We made this change to remove duplicate information, as well as change the title to better describe the section.
  
  

• Change #3: We removed duplicate details of Permitted Entity Certification.
  
  Justification #3: After review of the User Agreement, we determined that there was duplicate information that needed to be removed.
  
  

• Change #4: We reordered the Permitted Entity Responsibilities and inserted a new responsibility to provide consent for EIN verification.
  
  Justification #4: We made this change because it is necessary to include responsibilities for EIN verification, and subsequently, we need to renumber and order the previous responsibilities.
  
  

• Change #5: We clarified retention responsibilities.
  
  Justification #5: In response to comments 4 & 18 above, we added clarification to retention responsibilities.
  
  

• Change #6: We provided additional details in III.A.18 with respect to advertising limitations.
  
  Justification #6: After review of the User Agreement, we determined additional details were needed pertaining to advertising limitations.
  
  

• Change #7: We removed the electronic signature requirements document, revised the language of the electronic signature requirements and incorporated them into the User Agreement.
  
  Justification #7: In response to comments 4, 18, and 19, we determined that there did not need to be a separate electronic signature document, and, instead, included the information in section IV.
  
  

• Change #8: We removed items IV.A.5. and IV.A.6.
  
  Justification #8: After review of the User Agreement, we determined that those two statements were unnecessary.
  
  

• Change #9: In section VI, we added language to state that the User Agreement will be in effect for a period of two (2) years from the effective date unless terminated or cancelled for specified reasons.
  
  Justification #9: We added this language to specify duration of the User Agreement unless it is terminated or cancelled for approved reasons.
  
  

• Change #10: We removed the SSA signature line.
  
  Justification #10: After review of the User Agreement, we determined the SSA signature line was unnecessary.
  
  

• Change # 11: We made minor edits to Exhibit B, Permitted Entity Certification.
  
  Justification #11: We determined that minor language edits were necessary to Exhibit B for clarification purposes.

• Change #12: We revised the language in Section IV.D. (relating to consent being given by legal guardians of minors, or by court-appointed guardians of adults).

Justification #12: We revised this language for clarity, in response to comments submitted by the public.

Section F: Next Steps

We will implement Phase 1 of eCBSV collection upon OMB approval.

Future Plans: Approximately 6 months after the initial rollout of eCBSV to the 10 permitted entities, SSA will conduct an expanded rollout open to any qualified Permitted Entity that submitted a complete application during the open enrollment period in July 2019. We will seek OMB approval under a separate Paperwork Reduction Act cycle for that expansion of the user base, which will involve additional new Information Collection instruments.

eCBSV Addendum

Page 16