Executive Summary: How lenders can tune internal confidence logic around IRS match results without turning every name variation into a false decline. The point is not to make verification sound larger than it is. The point is to turn a real workflow gap into an evidence route that a VP Risk and compliance lead can defend. The gap is simple: teams want a single confidence number, but the operational question is which mismatch deserves correction, review, or rejection. Cobalt's TIN/EIN Verification API validates a supplied business name and EIN against IRS records. It is a validation product, not a search product, and it should be paired with the lender's routing rules.[1][2] Cobalt remains a data source, not a decisioning engine, so the customer owns credit policy, thresholds, and final decisions.
Why does risk tolerance matter before funding?
What risk does this topic remove?
The lender is not trying to collect decorative data. The lender is trying to remove a specific uncertainty before money leaves the door. In this draft, that uncertainty is that teams want a single confidence number, but the operational question is which mismatch deserves correction, review, or rejection. A defensible workflow turns that uncertainty into four possible routes: clear, correction, retry, or manual review.
For a risk team, the value is repeatability. The same fields, source hierarchy, exception labels, and reviewer routes make it easier to explain why one applicant moved forward and another did not. For engineering, the value is lower maintenance load. A bounded API workflow is easier to test than scattered staff lookups, screenshots, and spreadsheet notes.
Which buyer should care most?
• VP Risk. This buyer needs faster separation between clean files and files that need review.
• Compliance. This buyer needs source evidence, timestamps, response codes, and documented exception handling.
• CTO. This buyer needs a pattern that can be logged, tested, monitored, and changed without rewriting underwriting policy.
• Operations. This buyer needs fewer late-stage corrections and fewer files bouncing between sales, underwriting, and compliance.
The draft should not be read as a promise that one verification step can approve a loan. It should be read as a narrow way to remove one data gap before the lender's own policy takes over.
What should the lender verify first?
What is the minimum viable workflow?
The minimum viable workflow is separate exact matches, name-control issues, missing suffixes, service outages, and confirmed no-match results. The exact order can vary by credit box, but the evidence should be stored in a way that lets a later reviewer see the source, timestamp, applicant input, and policy route. The IRS describes TIN Matching as a way to validate TIN and name combinations, while Form W-9 remains the standard source document for collecting taxpayer identity from a payee or applicant.[2][4]
| Evidence layer | Question answered | Routing value |
|---|---|---|
| Legal name | Does the submitted name match the tax record? | Correction or review route |
| EIN | Is the supplied number valid for the name? | Identity validation |
| IRS code | What response did the source return? | Policy mapping |
| Review route | What should the team do next? | Clear, correct, retry, or review |
Why is one source not enough?
One source can be accurate and still incomplete for the decision in front of the lender. SOS data can confirm the state record while tax identity still needs validation. A clean TIN/EIN result can still leave open lien, ownership, sanctions, or portfolio-risk questions. The stack works because each source answers a different question, not because any source answers every question.[3][6]
Cobalt's existing EIN guide and B-Notice prevention article give this draft its internal-link base.[11][12]
What does the TIN/EIN workflow actually validate?
How does Cobalt fit without overstating the product?
Cobalt's TIN/EIN Verification API validates a supplied business name and EIN against IRS records. It is a validation product, not a search product, and it should be paired with the lender's routing rules.[1][2] The implementation starts with a narrow request and a clear evidence model. For this topic, a representative request or downstream event looks like this:
curl --location 'https://apigateway.cobaltintelligence.com/tinVerification?tin=123456789&businessName=Acme%20Corp' \
--header 'Accept: application/json' \
--header 'x-api-key: YOUR_API_KEY'The request is only the start. The lender should persist the raw response, map the result into internal statuses, and show the reviewer why a file cleared, corrected, retried, or moved to manual review. That discipline matters more than hiding the result behind a vague pass or fail label.
What limitation should stay visible?
Cobalt returns IRS response data. The lender owns the score, threshold, and final decision rule. The right posture is to state that limitation plainly, then design the route around it. A data source is valuable because it gives the lender a cleaner fact pattern. It is not valuable if marketing copy causes the buyer to expect a decision engine.
Strong verification architecture does not hide exceptions. It makes exceptions visible early enough that risk, compliance, and operations can act before funding.
What should engineering build into the first version?
What should be logged?
The first production version should be small, observable, and recoverable. Store external source data and internal policy routes separately. That prevents a later auditor from confusing what the source returned with what the lender decided.
• Input snapshot. Store the raw submitted business name, EIN when applicable, state, and normalized value used for the request.
• Source response. Preserve source mode, status code, source timestamp, and response fields before mapping them into internal labels.
• Policy route. Keep the lender's clear, correction, retry, and manual-review route separate from source data.
• Reviewer action. Log who changed the route, why the route changed, and which document or corrected input supported it.
• Evidence export. Make the final record readable without requiring the next reviewer to rerun the lookup.
What should not be automated first?
Do not start with automatic rejection for every exception. Start with classification. A format problem needs correction. A source outage needs retry. A confirmed mismatch needs policy review. A coverage limitation needs disclosure and an alternate route. Classification before automation protects the team from turning data quality into false declines.
How should exceptions route to manual review?
Which exceptions are operational, not fraud?
Every exception deserves a label. Some are operational, such as missing suffixes, punctuation differences, applicant typos, unsupported coverage, or source unavailability. Some are risk signals, such as a confirmed no-match, a not-issued tax ID, an unexpected secured party, or inconsistent entity evidence. Treating all exceptions as fraud creates unnecessary friction. Treating all exceptions as harmless creates loss exposure.[5][12]
| Result | Likely cause | Recommended route |
|---|---|---|
| Format invalid | Input problem or missing field | Ask applicant to correct input |
| Source unavailable | Source outage or timeout | Retry later with bounded backoff |
| Name or record mismatch | DBA entered, stale record, typo, or identity issue | Request source document or manual review |
| Coverage unsupported | Product does not cover the record needed | Use alternate source or manual review |
| Clean result | Evidence aligns with policy | Continue to next underwriting step |
How do retries stay safe?
Retries should be bounded and tied to technical failures, not to business outcomes. If the source returned a real no-match or a filing that changes risk, the next step is corrected evidence or review, not repeated calls until the answer changes. That distinction keeps the integration honest and reduces noise for the operations team.
What should a buyer ask before approving this workflow?
What questions expose weak implementations?
The buying conversation should focus on source, evidence, and ownership. A polished demo is less important than whether the data route matches the lender's actual underwriting and compliance needs.
1. Which source answers this exact question?
2. What fields are required before the API call can be trusted?
3. What does the response include for clear, mismatch, partial, unsupported, and source-unavailable cases?
4. How are source mode, timestamp, request ID, and reviewer route stored?
5. Which exceptions are automated, and which ones route to manual review?
6. What evidence is available to defend the decision six months later?
How should the final decision be framed?
The final decision should be framed as workflow fit. If the team needs tax identity validation, TIN/EIN verification belongs in the stack. If the team needs entity status, SOS belongs in the stack. If the team needs lien visibility, UCC belongs where coverage exists. If the team needs sanctions screening, OFAC belongs in the compliance lane. Cobalt can provide data layers, but the lender decides how those layers translate into approval, hold, correction, or decline.[7][10]
.jpg){kind=small}
.png)