What the form is for
The SSA-89 is the number holder’s written authorization for SSA to release a Social Security number verification to a named company. The company submits the name, SSN and date of birth it has on file. SSA responds with whether those elements match its records, and whether its records show the number holder as deceased.
That is the whole product. There is no earnings statement, no benefit amount, no address history. Two service channels exist: Consent Based Social Security Number Verification for enrolled companies, and the electronic eCBSV service established for permitted entities. Most lenders reach one of them through a credit reporting or verification vendor rather than directly.
Completing the form
| Block | What it holds | Where it goes wrong |
|---|---|---|
| Company name and address | The company authorized to receive the verification | Left blank, or naming the broker when the vendor of record is the enrolled company |
| Number holder name | Name as shown on the Social Security card | A current married name where SSA still holds the former name |
| Social Security number | The full nine digits | Transposed digits, or a number taken from a document rather than the card |
| Date of birth | Number holder date of birth | A typo that produces a no-match on an otherwise clean file |
| Reason for request | Why the verification is being sought | Generic wording that does not describe the actual transaction |
| Signature and date | Number holder signature, dated | Undated, or dated outside the consent window at the time of submission |
| Witness | Required where the number holder signs by mark | Omitted on a mark signature |
The signature must belong to the number holder. Where someone signs on the number holder’s behalf, the authority for that has to be documented in the file, and the acceptable evidence for it is a policy question, not a form question.
Reading the response
Three outcomes matter operationally.
- Match. The submitted elements agree with SSA records. This closes the specific control and nothing more.
- No match. One or more elements disagree. The usual cause is a clerical difference, a former name, or a date of birth typo. Resolve and resubmit before treating it as a fraud signal.
- Deceased indicator. SSA records show the number holder as deceased. This is a stop, not a condition, and it should route to the lender’s fraud escalation path rather than to a processor.
Whatever the outcome, the response itself is the evidence. A vendor screen reporting that a verification was ordered is not the same artifact and should not be filed as if it were.
What post-closing QC tests
- Policy consistency. The lender’s written policy says when an SSA-89 is required. QC tests whether the loans that met the trigger actually have one, not whether every loan does.
- Consent validity. Signed, dated, and submitted inside the period stated on the form.
- Element match to the file. The name, SSN and date of birth submitted are the ones on the application, the credit report and the note. A verification of the wrong data proves nothing.
- Resolution of a no-match. Where the first response was a no-match, the file shows what changed and what the corrected submission returned.
- Escalation of a deceased or fraud indicator. Documented, routed to an authorized reviewer, and dispositioned by a person.
- Red flags linkage. Where the identity theft prevention program treats an SSN discrepancy as a red flag, the file shows the program’s required response, not just the verification.
Common defects
| Condition | Typical severity | Why |
|---|---|---|
| Trigger met under lender policy, no SSA-89 in file | Material | A control the lender committed to was skipped |
| No-match response with no resolution documented | Material | An unresolved identity discrepancy at closing |
| Consent signed outside the validity window | Moderate | The verification may not be a valid authorization |
| Verification run on data that differs from the application | Moderate | The control was performed on the wrong subject |
| Vendor status screen retained instead of the response | Low to moderate | The result cannot be reperformed from the file |
Privacy handling
An SSA-89 is a page with a full Social Security number, a date of birth and a signature on it. It deserves stricter handling than most of the file. Keep it inside role-limited storage, do not reproduce the number in finding text, and make sure the retention schedule that governs it is the one counsel approved rather than a vendor default.
For how a verification like this is tracked from request to response, read the reverification workflow guide, and for the surrounding cycle, the post-closing QC checklist.
Keep decisions human and evidence explicit.
Translate guidance into a review record that preserves what happened, who decided, and which source controlled.
Confirm requirements against current source material.
Requirements and vendor capabilities change. These sources were reviewed July 31, 2026. Confirm current source material, product scope, commercial terms, and your approved QC plan before changing a production process.
What mortgage teams usually ask.
What does Form SSA-89 authorize?
It is the number holder's written consent for the Social Security Administration to verify, to a named company, whether a submitted name, Social Security number and date of birth match SSA records. It authorizes a verification, not a release of the borrower's earnings or benefit history.
Does a match on SSA-89 prove the borrower is who they say they are?
No. A match confirms that the name, SSN and date of birth submitted agree with SSA records. It does not establish that the person presenting them is the number holder. Identity verification is a separate control.
How long is a signed SSA-89 valid?
SSA limits how long consent stays usable after signature, a period commonly cited as 90 days. Confirm the current period on the form itself before submitting an aged authorization, because SSA has changed the wording across revisions.
Is an SSA-89 required on every mortgage loan?
No agency requires it universally. Lenders use it where their own policy, an investor overlay, a red flag identified during processing, or a fraud finding calls for independent SSN verification. What matters in QC is whether the lender followed its own written policy consistently.