Executive Summary: An EIN verification API helps lenders confirm whether a business name and Employer Identification Number match IRS records before a deal is funded. That sounds narrow, but it closes one of the most important gaps in business underwriting: a Secretary of State filing can prove that an entity exists, and a credit report can show payment history, but neither confirms that the applicant's claimed legal name belongs to the tax ID on the application. For alternative lenders, MCA funders, embedded finance platforms, and commercial credit teams, 2026 is a good year to treat EIN verification as a core identity check rather than an accounting backstop. IRS guidance still frames TIN Matching as a pre-filing tool for validating name/TIN combinations before eligible information returns are submitted.[1] Lending teams can use that same name/TIN logic earlier in the workflow to reduce tax reporting errors, spot mismatches, and route suspicious applications before money leaves the door.
What Is an EIN Verification API?
An EIN verification API is a programmatic interface that checks whether a submitted business name and EIN match the IRS record for that taxpayer identification number. In Cobalt's product language, this is the TIN/EIN Verification API: a validation endpoint that accepts a business name and a nine-digit TIN, then returns whether the name/TIN combination matches IRS records.
This matters because an EIN by itself is not proof of identity. A fraudster can type nine digits into an application. A legitimate applicant can enter a DBA instead of the legal name on file with the IRS. A business can change its state filing name without updating tax records. The lender needs a direct way to test the specific name plus tax ID pair.
Jordan Hansen summarized the product cleanly in a 2026 demo call: "We can verify EIN against the IRS database. So if they submit EIN and business name, then we'll return back like a boolean and say, yes, these match or no, they don't." That is the core value of an EIN verification API. It does not replace underwriting. It gives the underwriting system a federal identity signal that can be routed automatically.
The simplest distinction is this:
• EIN lookup asks, "What business is associated with this EIN?"
• EIN verification asks, "Does this business name match this EIN?"
Cobalt's TIN/EIN Verification API is the second type. It is validation, not search or discovery. The customer must provide both `tin` and `businessName`.
Why Does EIN Verification Matter for Lenders in 2026?
Lenders care about EIN verification for three practical reasons: fraud prevention, tax reporting accuracy, and underwriting speed.
First, the fraud pattern has changed. Synthetic business fraud does not always fail a Secretary of State check. A shell entity can be registered with a state and still use a tax ID that belongs to another company, a dormant business, or a fabricated application record. Federal Reserve Financial Services has warned financial institutions to apply lessons from synthetic identity fraud to synthetic business fraud, especially where business formation and onboarding processes can be abused.[2]
Second, name/TIN mismatches create downstream tax operations work. IRS 2026 information return instructions state that TIN Matching allows eligible payers or authorized agents to match TIN and name combinations with IRS records before filing certain 1099 forms.[3] If a lender waits until tax season to discover incorrect payee records, the correction work hits finance and compliance long after the underwriting team has moved on.
Third, speed is part of risk management in alternative lending. Manual verification creates a bad choice: slow down approvals while analysts check IRS or state systems, or skip steps to keep pace with deal volume. An API-based workflow lets the lender run the check in the same decision path as bank data, credit pulls, Secretary of State verification, sanctions screening, and internal fraud rules.
FinCEN's CDD Rule still expects covered financial institutions to maintain written procedures for customer identification, beneficial ownership identification, customer risk profiles, and ongoing monitoring.[4] FinCEN's February 13, 2026 exceptive relief changed how repeatedly covered institutions may handle beneficial ownership verification at each new account opening, but it did not remove broader AML/CFT program, recordkeeping, or reporting obligations.[5] That makes automated identity evidence more useful, not less.
How Does IRS TIN Matching Work?
IRS TIN Matching validates a taxpayer identification number and name combination against IRS records. The IRS page describes the service as a pre-filing tool for payers and authorized agents that submit information returns, with interactive and bulk options available.[1]
IRS Instructions for the Requester of Form W-9 explain that TIN matching can reduce backup withholding notices and penalty notices when payers validate name/TIN combinations before filing information returns.[6] For lenders evaluating API behavior, two details matter:
• Portal workflows are not underwriting workflows. IRS e-Services access is built around eligible payers and authorized agents. It is not designed to sit inside a lender's loan origination decision path.
• Batch workflows create timing gaps. Periodic matching helps accounting and tax operations, but it does not give an underwriter an immediate application-level routing signal.
Those limits make direct portal workflows useful for periodic accounting operations, but awkward for high-volume lending. A lender processing applications in real time does not want an analyst typing 25 rows at a time into a portal or waiting for a bulk result after the applicant expected a same-day decision.
An API adds the missing operational layer: a lender can call the IRS-backed validation flow from the loan origination system, store the result in the loan file, and route decisions without manual rekeying.
What Does the API Request and Response Look Like?
Cobalt's TIN/EIN Verification API uses a simple GET request:
curl --location 'https://apigateway.cobaltintelligence.com/tinVerification?tin=123456789&businessName=Acme%20Corp' \
--header 'Accept: application/json' \
--header 'x-api-key: Your_API_Key'The endpoint requires:
• `tin`: the nine-digit EIN or TIN, formatted without dashes
• `businessName`: the legal business name to match against IRS records
• `x-api-key`: the Cobalt Intelligence API key
A match response returns the name, TIN, match status, IRS code, IRS reason, IRS service status, and the timestamp of the IRS check:
{
"name": "ACME CORPORATION",
"tin": "123456789",
"status": "Match",
"irsCode": 0,
"irsReason": "TIN and Name combination match IRS records",
"irsServiceStatus": "Available",
"lastIRSCheckDate": "2026-01-21T14:30:00Z"
}This is enough data to build deterministic underwriting rules. A lender can preserve the raw response, display a short message to analysts, and store the IRS code as a structured field in the application record.
The API is especially useful when paired with Cobalt's TIN/EIN verification API resource, which explains the broader business identity use case. For a technical implementation, the fields above are the minimum that matter: submitted name, submitted TIN, IRS result code, human-readable reason, system availability, and timestamp.
How Should Lenders Route IRS Response Codes?
The biggest mistake is treating EIN verification as a vague pass/fail check. IRS response codes have different operational meanings, and a lender should map each one to a specific action.
Cobalt's product documentation maps IRS response code detail to practical lender actions this way:
| IRS code | Meaning | Lender action |
|---|---|---|
| 0 | TIN and name match | Proceed with normal verification |
| 1 | TIN not issued | Treat as a hard stop or request corrected tax documentation |
| 2 | TIN issued, name does not match | Request W-9, check legal suffixes, investigate before funding |
| 3 | TIN not matched or IRS records incomplete | Route to manual review |
| 4 to 8 | IRS-specific match conditions | Review returned reason and route based on policy |
A code 2 mismatch is not automatically fraud. It may be a legitimate name-control issue, a DBA entered instead of the legal name, a missing legal suffix, or a recent name change. But it is never a clean pass. A risk team should ask for the W-9, compare the state-registered legal name, and document the explanation before funding.
IRS CP2100 and CP2100A guidance shows why this matters beyond the credit decision. When payee records do not match IRS records, payers may need to send B notices, correct records, and begin backup withholding if the payee does not respond within the required window.[7] The IRS page lists the current backup withholding rate as 24%.[7]
Add real-time IRS name/TIN matching to your underwriting flow before funding. Cobalt's TIN/EIN Verification API returns structured IRS code detail your team can route automatically. Start with Cobalt's free consultation guide.
What Does EIN Verification Not Do?
An EIN verification API is powerful because it is narrow. It answers one question: does this name match this TIN according to IRS records?
It does not answer:
• Who owns this business?
• Is the entity active with the Secretary of State?
• What is the company's registered agent?
• Does the company have UCC liens?
• Is the business sanctioned?
• What EIN belongs to this business if the applicant did not provide one?
That distinction came up repeatedly in Cobalt demo calls. In one May 2026 call, Jordan clarified: "If you have a name and an ein, we can come back to you and say, yes, these do match." In another call, he said, "It's only a verification between the two. We need both fields, and we can verify they match. That's it."
That is a buying criterion, not a drawback. If a vendor claims broad EIN discovery from public records, ask exactly where the data comes from, how current it is, and what coverage rate they can prove. Cobalt's posture is narrower and more defensible: validate the supplied name and EIN pair against IRS records, then use other primary-source checks for the rest of the KYB file.
How Should EIN Verification Pair With Secretary of State Verification?
The strongest lender workflow uses two independent government sources:
• Secretary of State verification confirms the entity exists, status is active or acceptable, formation data is plausible, and officers or registered agent details align with the application.
• EIN verification confirms the business name and federal tax ID belong together.
The recommended sequence is SOS first, EIN second. A real-time Secretary of State API verification check gives the lender the state-registered legal name. That legal name is often a better input for TIN matching than the applicant's free-text business name. The lender can then submit the exact legal name and EIN to the TIN/EIN endpoint.
This sequence catches different failure modes:
• Entity does not exist. SOS fails before the lender spends time on tax ID validation.
• Entity exists, but EIN does not match. SOS passes, TIN fails, which points to identity mismatch rather than registration failure.
• Entity exists under a similar name. SOS returns a normalized legal name that can be used to reduce false TIN mismatches.
• Entity network risk appears. The lender can add a Find Related Businesses workflow after the identity match to identify connected entities.
For lenders operating across multiple jurisdictions, the 50-state business entity verification guide is the broader state-level foundation. EIN verification adds the federal tax identity layer that state databases do not provide consistently.
How Do You Choose an EIN Verification API Vendor?
Start with the workflow, not the vendor pitch. A lender should evaluate an EIN verification API against six criteria.
1. Does it validate against IRS records? The source matters. A cached or consortium-derived signal is not the same as IRS name/TIN matching.
2. Does it require both name and EIN? If the vendor implies it can discover any EIN by business name with complete coverage, ask for coverage proof and source documentation.
3. Does it return response code detail? A binary pass/fail result hides important routing differences between invalid TIN, name mismatch, incomplete IRS records, and system unavailability.
4. Does it expose system availability? The lender needs to distinguish a true mismatch from an IRS availability problem.
5. Can it pair with SOS verification? A standalone TIN tool may solve a tax workflow but still leave the lender managing a second integration for entity verification.
6. Is pricing clear enough for per-application unit economics? Cobalt's TIN/EIN Verification API uses 3 credits per lookup, reflecting the cost of the IRS-backed check.
Middesk is a good comparison point because it offers TIN matching as part of a broader business identity platform.[8] That can be the right fit for teams that want an all-in-one KYB platform. A lender that already owns its underwriting workflow may prefer a direct API that can be inserted into existing decision rules without replacing the rest of the stack.
What Implementation Checklist Should Lenders Use?
Before putting an EIN verification API into production, define the workflow in writing. The key is to make every result actionable.
Use this checklist:
• Normalize input. Strip dashes from EINs and reject anything that is not nine digits before calling the API.
• Use the legal name. Prefer the state-registered legal name from the SOS result over the applicant's trade name or DBA.
• Store the raw response. Save IRS code, reason, timestamp, and service status in the loan file.
• Define code routing. Code 0 proceeds. Code 1 stops or requests corrected documentation. Code 2 routes to W-9 review. Code 3 routes to manual review. IRS unavailable queues for retry.
• Create analyst copy. Give underwriters plain-language reasons, not raw codes only.
• Add retry policy. Do not treat IRS system unavailability as a mismatch or a pass.
• Retest renewals. Re-run verification for renewals, increased credit lines, and material ownership or name changes.
• Audit monthly. Review mismatch rates by broker, channel, state, and entity age. A spike in code 2 or code 1 results can reveal application quality issues or fraud patterns.
The goal is not to add another checkbox. The goal is to make business identity evidence machine-readable and audit-ready.
What Is the Bottom Line for Lenders?
An EIN verification API belongs in the lender's pre-funding identity stack. It confirms that the business name and tax ID pairing is legitimate according to IRS records, gives risk teams structured routing signals, and reduces manual tax ID cleanup after the fact.
Cobalt's TIN/EIN Verification API is intentionally specific: provide the business name and EIN, receive IRS match status and response code detail. Pair it with Secretary of State verification for entity existence, OFAC screening for sanctions risk, and related-business checks for network risk. That combination gives lenders a practical KYB workflow that is fast enough for alternative lending and specific enough for audit review.
.jpg){kind=small}
.png)