EIN Verify: Your First Step to Fraud-Proof Lending

EIN verification is not a tax-ops afterthought for lenders. It is a first-pass fraud gate. When an applicant provides a legal business name and an Employer Identification Number, the core question is simple: does that name and number pair match IRS records? The IRS describes TIN Matching as a pre-filing service that lets authorized payers validate name and TIN combinations before submitting information returns, using interactive or bulk matching options. IRS TIN Matching

Why should lenders treat EIN verification as a fraud signal?

Alternative lenders move fast, and fast workflows are vulnerable to identity shortcuts. A fabricated merchant profile can borrow a real company name, invent an EIN, or reuse a number that belongs to another entity. Secretary of State data tells you whether an entity exists. EIN verification tells you whether the applicant's tax identity belongs with the name they submitted.

• Code 0 should advance. A name and TIN match is not a credit approval, but it is a clean identity gate.
• A not-issued result should stop the file. If the TIN has not been issued, downstream underwriting spend is hard to justify.
• A name mismatch should route to exception review. It may be fraud, or it may be a legal-name, DBA, punctuation, or recent-change issue.

Cobalt's product documentation frames the same distinction plainly: TIN/EIN Verification is validation, not discovery. The customer provides both fields, and the API returns whether the pair matches. It does not discover unknown EINs or enrich the applicant profile.

Where does EIN verification belong in the underwriting waterfall?

The best placement is near the front, after basic application normalization and before expensive checks. If a lender waits until after bureau pulls, bank statement analysis, UCC searches, and manual review, the EIN result is still useful, but the cost-saving opportunity is gone.

What does a good lender policy do with IRS-style match outcomes?

A practical policy maps each result to a routing action. It should not force underwriters to re-interpret the same flags on every file.

• Match. Continue to state registration and risk checks.
• TIN not issued. Decline or ask for corrected W-9 documentation before any paid downstream checks.
• Name does not match. Hold for W-9, legal-name review, or DBA reconciliation.
• IRS unavailable or inconclusive. Queue the application, retry, and prevent funding until the identity gate completes.

The IRS Backup Withholding B Program page explains that CP2100 and CP2100A notices are tied to missing, incorrect, or nonmatching name and TIN combinations on information returns. IRS Backup Withholding B Program Lenders do not need to wait for tax-season cleanup to care about the same mismatch pattern.

How does name control create false alarms?

The IRS says name control is created from the legal name listed on Form SS-4. IRS name control guidance That matters because applicants often submit a trade name, a shortened brand name, or a punctuation variant. A mismatch can be a fraud signal, but it can also mean the applicant entered the wrong version of its name.

What should the exception queue ask for?

The exception workflow should be narrow. Ask for Form W-9, the IRS EIN confirmation letter if available, and the state registration record. Compare legal name, DBA, address, and responsible-party context. If the mismatch resolves to a formatting issue, continue. If it resolves to a different taxpayer, decline.

How should lenders explain this to engineering?

Engineering does not need a black-box risk rule. The integration is a two-field validation call: send normalized TIN and legal business name, receive status, code, reason, IRS service status, and timestamp. Store the response with the application audit trail. Use retry logic for temporary service issues. Never let a missing identity result silently pass into funding.

What fraud patterns show up when EIN verification runs first?

The most useful fraud signal is not a dramatic red flag. It is the quiet mismatch that appears before a file becomes expensive. A borrower submits a plausible legal name, an active website, bank statements, and a tax number. Without a front-loaded IRS-backed check, the file can look ordinary enough to move into the next queue. The EIN result forces the first question to stay narrow: does this taxpayer identity belong to this legal name?

Invented entity with invented EIN

This is the cleanest stop. The applicant may have copied the format of an EIN, but the number was never issued. If that result arrives before state lookup, bureau work, or manual analysis, the lender avoids spending on a file that cannot pass identity policy. The exception process can ask for corrected tax documentation, but the system should not keep underwriting while the identity question is unresolved.

Real entity name with wrong EIN

This pattern is more subtle. The company name may exist in state records, but the submitted number belongs elsewhere or does not match the IRS name control. The applicant may have mistyped, used an old owner record, or submitted a DBA instead of the legal taxpayer name. That ambiguity is exactly why the rule should route to documentation rather than force an underwriter to guess.

Borrowed EIN with thin business history

A fraudster can make a newer operating profile look more credible by pairing it with a number that appears familiar in other records. TIN matching makes that tactic harder because the match depends on the name and number pair, not the number alone. This is also why the API should not be positioned as enrichment. It is a pass, fail, or exception signal on a specific submitted pair.

How should the waterfall handle volume and latency?

High-volume lenders need deterministic routing. If every EIN exception becomes an analyst debate, the workflow will not scale. Build the rules before volume arrives. Code 0 moves forward. A not-issued result stops. A name mismatch routes to a specific documentation queue. IRS service unavailability goes to retry. The underwriter sees only the files where judgment is actually needed.

The queue design matters because identity failures are often discovered at the worst possible time, when a sales or funding team is already pushing the application forward. A system-level hold prevents operational pressure from turning a verification failure into a policy exception. That is the difference between using EIN verification as a dashboard widget and using it as a control.

What does audit-ready implementation look like?

An audit-ready implementation stores the raw request, the normalized request, the response code, the human-readable reason, the IRS service status, the timestamp, and the routing action. It should also preserve who overrode a hold, why, and what supporting document resolved it. The goal is not to prove that every mismatch was fraud. The goal is to prove that every mismatch was handled consistently.

For lenders, that consistency is also a management control. If a month of files shows a spike in Code 2 results from one broker, one vertical, or one traffic source, risk leadership can investigate the source of bad intake data before it turns into losses. EIN verification is a file-level gate, but the pattern data becomes portfolio intelligence.

How should Cobalt be positioned honestly?

Cobalt is not replacing a KYB platform, a credit model, or a tax reporting workflow. The TIN/EIN Verification API gives lenders a direct validation layer for a submitted name and tax ID pair. The strongest use case is pairing it with Cobalt's Secretary of State data so the lender gets two different identity checks: federal tax identity and state registration reality. If both pass, the file deserves the next layer of underwriting. If either fails, the file deserves a hold.