Federal Case Registry
Social Security Number Submission, Validation, Identification, and Retention Conference Call Notes

Participating States

Purpose of the call

On September 24,2003 a conference call with states was held to discuss issues regarding Social Security numbers (SSNs) on the Federal Case Registry (FCR). Recently, many states have asked questions regarding how the Social Security Administration (SSA) identifies and verifies SSNs.  The purpose of the multi-state conference call was to walk through the routines SSA uses to verify an SSN, and discuss SSN issues.  Forty (40) states participated in the call.

Routines SSA employs to verify SSNs

The discussion began by providing information on the SSA routines that the FCR uses to verify SSNs.  The following processes were reviewed:

• High Group Check – This is the first routine used when an SSN is submitted to the FCR.  This process verifies whether the SSN falls within the valid range of the SSNs issued by SSA.
• Exact SSN/Name Verification – If the SSN passes the High Group check, the next process used is a check for an exact match between what was submitted by the state and what SSA has on file.  Certain name and date of birth tolerances are used for this match.
• Corrected SSNs – If the SSN cannot be verified through the exact match process, 89 different routines are used to check for transposed digits or one incorrect digit.  If the FCR can find an SSN using this method, then the SSN is considered “corrected" and the validity code returned to states is "C".
• Enumeration Verification System (EVS) Alpha Search – If the name and SSN submitted by a state cannot be verified or corrected or if no SSN was submitted, then the EVS Alpha Search routine is used.  A match is based on the following criteria:
  • First name has the same first four letters;
  • Middle name has the same first three letters;
  • Last name has the same first eight letters; and
  • Date of birth matches based on SSA’s date of birth matching rules.
  If an SSN is found through this process, the validity code returned to states is “P".
• Earnings Systems Keyed Applications for SSN Registration Identification (ESKARI) – If the Alpha Search routine fails to identify an SSN, and if the state has provided certain additional key data elements for an ESKARI search, then this process is used to find an SSN.  Key data elements are:
  • Name from Alpha Search,
  • Date of birth,
  • Sex code,
  • State or country of birth,
  And any one of the following combinations:
  • Father’s first name, father’s last name, and city of birth, or
  • Father’s first name, father’s last name, and mother’s maiden name, or
  • Mother’s first name, mother’s maiden name, and city of birth, or
  • City of birth, father’s last name, and mother’s maiden name.
  If an SSN is found through this process, the validity code returned to states is “E".
• Requires Manual Review (RMR) – If more than one SSN is found from the ESKARI process, then the RMR process is initiated.  An FPLS staff member will manually check the list of possible matches generated by the ESKARI process and select the SSN that best matches to the person.  A single SSN selected using RMR will return a validity code “R".
• IRS-U – This process is separate from the SSA routines and requires the NCP’s name and the SSN of the spouse or ex-spouse.  The IRS will try to locate the NCP’s SSN from a joint tax return.  If an SSN is found using this process, the validity code returned to states is “S".

How to handle valid multiples and changing an unverified to a verified SSN

Information on how to handle multiple SSNs was also discussed.  State system designs should allow for multiple SSNs to be recorded for a person. This will prove helpful in situations where an NCP is working under one SSN but has financial accounts under another SSN.  Please note, you must use the SSN verified and returned to the state by the FCR when communicating with the FCR.

Several states are sending an add transaction instead of a change transaction in order to change a participant from an unverified status to a verified status.  This practice will cause the FCR to register the same person twice, as verified and unverified.  It was recommended that these states consider changing their logic to send a change transaction instead of an add transaction.

Proposed enhancement to enable states to change a verified SSN to an unverified SSN when the state knows the FCR SSN is incorrect

Several states have indicated they are interested in a new approach that would allow states to delete a verified Name/SSN from the FCR when a state believes that the FCR has identified the incorrect person.  Currently, if the state has new information that will change the verified SSN to another verified SSN, the state will send in a change transaction.  If the state does not have new information to verify a different SSN, the state will delete the person from the FCR and re-add the person at a later date when new information is available.  However, this process has proven difficult for state systems that are programmed to do an entire sweep of the database for participants not registered on the FCR.  It causes the person record to be re-sent to the FCR with the same incorrect data. This results in the person being added again to the FCR with the same incorrect SSN and the same proactive matching data being sent to the state.  States are asked to provide examples of these records and transactions so the problem can be further researched.

The proposed enhancement would allow states to send a "C" action type code to change a verified SSN registered on the FCR to an unverified SSN. This process will only work if the state has an SSN other than the FCR verified SSN.  If the state has no other known SSN, they should delete the participant from the FCR.

For an in-depth explanation of FCR/SSN processing, see section 5.3.1 of the FCR Interface Guidance Document.

Action Items

1. States should send examples of erroneously identified SSNs to their State TS Liaison.
2. The State TS team will distribute notes from this call to all states.