FAQs

A financial institution as defined by section 509 of the Gramm-Leach-Bliley Act, or a service provider, subsidiary, affiliate, agent, subcontractor, or assignee of a financial institution, who is signing this user agreement as a permitted entity. Generally this includes:

• United States depository institutions, including commercial banks, insured banks, thrift institutions, trust companies, US branches of foreign banks, and all private banks and bankers.
• Credit card issuers or operators.
• Credit unions.
• Brokers or dealers in securities or commodities.
• Currency exchangers or parties involved in the transmission of funds.
• Futures commission merchants, commodity trading advisors, and registered commodity pool operators.
• Investment banks and bankers.
• Insurance companies.
• Loan and finance companies.
• Individuals involved in real estate closings and settlements.
• Dealers in precious metals or gems.
• Gaming establishments with annual revenues exceeding $1 million.
• Other institutions, including travel agencies, and those engaged in the sale of cars, boats, or airplanes.

Yes. Socure offers separate eCBSV provisioning for minors which can be provisioned by your Technical Account Manager. However, in order to be eligible for this specific eCBSV flow, there are certain obligations under which you and your respective customers must abide by.

eCBSV requests can be performed based on Written Consent signed electronically by the legal guardians of adults, and parents or legal guardians of children under age 18 when two criteria are met:

• The parent or legal guardian has signed a Written Consent.
• The parent or legal guardian has submitted documentation to the Permitted Entity that proves the relationship.

If the request is for a minor child under the age of 18, a parent or legal guardian must sign the Written Consent and provide a birth certificate or court documentation proving the relationship.

If the request is for a legally incompetent adult, a legal guardian must sign the Written Consent and provide court documentation proving the relationship.

The Permitted Entity may accept Written Consent signed by a third party with power of attorney only if the SSN holder signs the papers granting the power of attorney and those papers state exactly what information SSA can disclose to the Permitted Entity.

A third party without a power of attorney or with a power of attorney that does not meet the criteria described in this section (for example, a spouse, an appointed representative, or an attorney) is not authorized to execute Written Consent on the SSN holder’s behalf.

eCBSV is also effective for younger applicants. Coverage increases for 18–21 year olds are often 5% higher—and can exceed 12% in thin-file segments.

No, a verification is only good for the immediate transaction, and is not valid for any subsequent transactions.

eCBSV is fast and reliable—most responses land in ~135ms to ~220ms, with 99.999% uptime (excluding planned maintenance). If you’re bundling with KYC, expect sub-500ms end-to-end.

We support last-4 SSN flows—but using all 9 digits is best. Using just 4 digits increases the risk of false matches (especially for common names), so opt for the full SSN when you can.

You can usually find a JSON schema at the bottom of our DevHub docs. If you want a Postman collection or OpenAPI spec for smoother developer handoffs, just reach out—those formats are available too.

Yes, we recommend our clients register ahead of contracts and addenda finalization.

Yes, you must register again but be sure to go through the Financial Institution registration process.

You’ll sign the EIN Consent electronically through SSA’s portal when you register. The form is only valid if done on SSA’s site and lasts two years. SSA’s Data Exchanges site and our DevHub have step-by-step guides.

We support last-4 SSN flows—but using all 9 digits is best. Using just 4 digits increases the risk of false matches (especially for common names), so opt for the full SSN when you can.

We’ve added six fresh reason codes—these help pinpoint exactly which parts of a user’s info (Name, SSN, DOB) matched with SSA records. There’s no need to update your API integration, but you do need to refresh your consent language (six new words). These codes make handling exceptions and audits easier.

Yes! If you’re transitioning vendors or using multiple providers (example: Socure + EWS), list them both—as long as each is active and compliant. Be sure to remove any provider you’re no longer working with.

Use the I998 and R998 codes in your dashboard or reason code explorer to monitor the volume of successful SSA requests. This helps track usage against your quotas or pilots.

eCBSV blocks requests with ITINs or invalid SSNs before sending anything to SSA. You may see reason codes (like R997) if things didn’t go as planned (e.g. SSA outage), but no data is transmitted for “bad” SSNs.

You can usually find a JSON schema at the bottom of our DevHub docs. If you want a Postman collection or OpenAPI spec for smoother developer handoffs, just reach out—those formats are available too.

Use the I998 and R998 codes in your dashboard or reason code explorer to monitor the volume of successful SSA requests. This helps track usage against your quotas or pilots.

No, a verification is only good for the immediate transaction, and is not valid for any subsequent transactions.

eCBSV blocks requests with ITINs or invalid SSNs before sending anything to SSA. You may see reason codes (like R997) if things didn’t go as planned (e.g. SSA outage), but no data is transmitted for “bad” SSNs.