eCBSV Consent Requirements: A Comprehensive Guide

SentiLink was the first company to use the SSA's Electronic Consent Based SSN Verification system (eCBSV) to verify a person's name, DOB and SSN combination. This history, combined with our ongoing close working relationship with the SSA and the collective experience of our expanding partner base, has allowed us to finely tune our strategic approach to the consumer consent requirements for the use of eCBSV. 

Overview

The revelation of eCBSV is that consent can now be captured electronically. With the legacy CBSV system, consumer consent had to be captured via a wet ink-on-paper (on an SSA-89 form) signature. Now, consent may be obtained in one of three ways:

Option 1- By using the paper SSA-89 form;

Option 2- With a digital "fillable" PDF version of an SSA-89 form; or

Option 3- Via electronic consent, consistent with the E-SIGN Act, as part of a financial institution's application flow.

While the first two options are similar to existing CBSV processes and remain viable approaches, Option 3 gives organizations more flexibility and control over the user experience, provided they stay within SSA guidelines. This article will focus on successful strategies to leverage Option 3 into digital onboarding experiences.

Components of eCBSV consent

For those seeking to take advantage of Option 3, SSA's consent specifications can be broken down into four component parts:

1) THE HEADLINE

This exact language (without abbreviations) must appear in bold. It can be centered or left justified.

"Authorization for the Social Security Administration to Disclose Your Social Security Number Verification"

2) THE CONSENT BLOCK

"I authorize the Social Security Administration (SSA) to verify and disclose to [FINANCIAL INSTITUTION] through [SERVICE PROVIDER, their service provider, (if applicable)] for the purpose of [SPECIFIC PURPOSE] whether the name, Social Security Number (SSN) and date of birth I have submitted matches information in SSA records. My consent is for a one-time validation within the next [NUMBER OF DAYS]."

3) THE 'INTENT TO SIGN' BLOCK

"By [describe the SIGNING MECHANISM], you are signing the consent for SSA to disclose your SSN Verification to [Permitted Entity and/or Financial Institution]. You agree that your electronic signature has the same legal meaning, validity, and effect as your handwritten signature."

4) THE SIGNING MECHANISM

This is the check box, button labeled "I agree, "I consent" or similar, with which the applicant must interact before an eCBSV request is permitted.

Permissible Purposes

SSA allows that the [SPECIFIC PURPOSE] shown in the Consent Block above can be either static or dynamic. In practical terms, a static purpose would likely read "this transaction," whereas a dynamic purpose would state exactly what product or service the consumer is applying for.

In either case, the specific purpose (evidence of which must be maintained for audit purposes along with the consumer's consent) must be related to a credit transaction or a "Permissible Purpose" as defined in the federal Fair Credit Reporting Act (FCRA). While these purposes are most often associated with the scenarios under which it is legally permissible to obtain a consumer's credit report, SSA recognizes that exact purposes can vary. For example, purposes listed on the SSA-89 form as reasons for authorizing consent include activities like applying for a mortgage, loan or credit card, as well as opening a bank account, which would include obtaining a debit card. (This list isn't exhaustive and these are not the only words that may be used).

Putting it All Together

In its cleanest form, an example of acceptable consent language and formatting when using a static purpose in a standard application flow would look like this:

SentiLink also works with partners who incorporate eCBSV in a post-application/escalation flow. In those scenarios, consent could look like this:

Note that in this example, we recommend re-collecting the PII to be associated with an eCBSV verification request. Since time has likely elapsed (up to a year) since the original application, and since an exception flow is often used to determine if a fat-finger typo was the cause of an eCBSV mismatch, it is a best practice to re-verify the PII being submitted to SSA at this point.

These examples are for illustrative purposes. Financial Institutions may need to make some modifications to the formatting and structure of the consent flow. It is imperative to work collaboratively with a Service Provider like SentiLink to maintain compliance and reduce audit risk.

Conclusions

- Apply the KISS Principle: There may be a tension between UX teams -- which will want to minimize the impact of the consent language requirements on a digital application flow -- and compliance teams who will want to minimize risk. Our recommendation: Keep it simple, follow SSA's clear requirements and don't put yourself in jeopardy of failing an audit.

- Conventional wisdom follows that any amount of friction can increase application abandonment rates. While we don't dispute that the eCBSV consent requirements discussed here add a degree of friction, our experience has not indicated any correlation between these requirements and increased consumer dropouts.

SentiLink believes strongly in fostering a culture of compliance with our partners. Designing an eCBSV consent flow process can be challenging and frustrating, but the benefits of utilizing this service are worth the initial headache.