Executive Summary: Most lenders run EIN verification somewhere near the bottom of their underwriting process, after they have already pulled Secretary of State records, searched UCC filings, and queued up court record checks. By the time a mismatched EIN flags the deal as fraudulent, the lender has spent real money on a file that should have been declined in the first ten seconds.[1] The fix is not a new tool. It is a sequencing change: move EIN verification to step one in the waterfall, right after the initial application lands.
Why Does EIN Verification Placement Matter More Than Most Lenders Think?
The underwriting waterfall is the sequence of checks a lender runs on every application. Each check costs money, whether that cost comes from API credits, staff time reviewing results, or both. The order in which those checks run determines how much a lender spends on deals that will ultimately be declined.[2]
For alternative lenders processing thousands of files per month, even small per-file cost differences compound into significant operational spend. A lender running 3,000 applications per month who spends an extra two minutes and three API calls on each fraudulent application before catching it is burning resources that a better sequencing decision would eliminate entirely.
What Does a Typical Underwriting Waterfall Look Like Today?
Most alternative lenders and MCA providers run their verification steps in roughly this order:
• Secretary of State lookup. Confirm the business entity is registered and in good standing with the state.
• UCC filing search. Check for existing liens, collateral pledges, and signs of loan stacking.
• Court records check. Look for active litigation, judgments, or bankruptcies that indicate risk.
• Credit bureau pull. Run a commercial or personal credit check on the principal.
• Bank statement analysis. Verify revenue claims and cash flow patterns.
• EIN/TIN verification. Confirm the business name matches IRS records.
In this sequence, EIN verification is the last automated check before a human underwriter touches the file. Every step before it costs credits, time, and analyst attention.[3]
What Happens When a Fraudulent Application Reaches Step Six?
When a bad actor submits a fabricated business name paired with a real or invented EIN, the application often passes through the first five steps without raising a flag. The Secretary of State database may show an active entity with a similar name. UCC filings may come back clean because the synthetic entity has no prior borrowing history. Court records return nothing. Credit reports may even show a thin but clean file, which is a hallmark of synthetic identity fraud.[4]
By the time the EIN check runs and returns IRS Code 1 (TIN not issued) or Code 2 (name does not match), the lender has already consumed credits on five separate data pulls, allocated analyst time to review each result, and moved the file through a pipeline that was never going to end in funding.
How Much Does Running EIN Verification Late Actually Cost?
The per-application cost of a misplaced EIN check depends on the lender's data stack, but the math is consistent: every check that runs before the EIN verification on a fraudulent file is wasted spend.
What Are the Real Numbers?
Consider a lender running the typical waterfall described above:
• SOS lookup: 1 API credit
• UCC search: 1-2 API credits (varies by state)
• Court records search: 1-2 API credits per jurisdiction
• Credit bureau pull: $40-$70 per tri-merge report[5]
• Bank statement analysis: Staff time or third-party service fee
• EIN verification: 3 API credits
If EIN verification runs first and returns a Code 1 or Code 2 result, the lender declines immediately. Total cost: 3 API credits. If EIN verification runs last and the file is fraudulent, the lender has already spent API credits on SOS, UCC, and court records; paid for a credit bureau pull; and allocated staff time to review the results before discovering the identity does not match IRS records.
How Does This Scale Across a Portfolio?
SMB lending fraud grew 13.6% year-over-year in 2023, and 64% of lenders surveyed by LexisNexis Risk Solutions expected further growth in the following 12 months.[6] Only 27% of fraudsters were caught at account origination, down from 32% the year before, meaning more bad applications are penetrating deeper into underwriting pipelines before detection.[7] For a lender processing 3,000 files per month, even a 5% fraud rate means 150 applications per month that will ultimately be declined. If each of those files burns $50-$100 in wasted verification costs before the EIN check catches it, that is $7,500 to $15,000 per month in avoidable spend, or $90,000 to $180,000 annually, on applications that should have been stopped at the gate.
Where Should EIN Verification Sit in the Waterfall?
The answer from the data is clear: EIN verification should be the first automated check after the application is received, before any other paid data pull.
Why Does EIN Verification Work as a First-Pass Filter?
EIN verification has three properties that make it ideal as a front-of-waterfall filter:
• Binary result. The IRS returns a match or no-match. There is no ambiguity to interpret, no score to threshold, no report to review. Code 0 means the business name and EIN match IRS records. Anything else means stop.[8]
• Low cost. At 3 credits per check, EIN verification is one of the cheapest automated checks in the stack. Compare this to credit bureau pulls at $40-$70 or manual bank statement review.
• High signal. A mismatched EIN is one of the strongest fraud indicators available in business lending. Synthetic identity fraud, where a bad actor pairs a real EIN with a fabricated business name, is caught immediately by this check.[9]
What Does the Optimized Waterfall Look Like?
Smart lenders restructure their waterfall to front-load cheap, high-signal checks and back-load expensive, nuanced ones:
• Step 1: EIN/TIN verification. Confirm the business name and EIN match IRS records. Cost: 3 credits. Decision: Code 0 = proceed. Code 1 or 2 = decline or hold for manual review.
• Step 2: Secretary of State lookup. Verify the entity is registered and in good standing. Cost: 1 credit.
• Step 3: UCC filing search. Check for existing liens and collateral pledges. Cost: 1-2 credits.
• Step 4: Court records check. Search for litigation, judgments, or bankruptcies. Cost: 1-2 credits per jurisdiction.
• Step 5: Credit bureau pull. Run commercial or personal credit. Cost: $40-$70.
• Step 6: Bank statement analysis. Verify revenue and cash flow. Cost: Staff time or service fee.
In this sequence, the cheapest and most definitive fraud check runs first. Every file that fails EIN verification is declined before any other cost is incurred. The expensive checks (credit bureau, bank statements) only run on applications that have already passed the identity gate.
How Does Real-Time IRS Matching Work Under the Hood?
Understanding what happens when you send an EIN verification request helps explain why the result is so reliable as a first-pass filter.
What Is the IRS Name Control System?
When a business files Form SS-4 to obtain an EIN, the IRS creates a "name control" derived from the first four characters of the legal business name. Every subsequent TIN match request compares the submitted name against this stored name control.[10] This matching logic means:
• Legal suffixes are significant. "Acme Corp" and "Acme Corporation" may produce different name controls. The IRS matches against the name exactly as filed on the SS-4.
• Abbreviations cause mismatches. A business that filed as "Johnson & Associates LLC" but applies as "Johnson and Associates" may trigger a Code 2 result.
• Only ampersands and hyphens are treated as special characters in the name control. All other special characters are stripped before matching.[11]
What Do the IRS Response Codes Tell You?
The IRS returns numeric response codes that map directly to underwriting actions:
• Code 0: TIN and name match IRS records. Green light. The business identity is confirmed. Proceed to the next verification step.
• Code 1: TIN not issued. The EIN does not exist in IRS records. This is a hard rejection signal. The applicant is using a fabricated or invalid EIN.[12]
• Code 2: TIN issued, but name does not match. The EIN exists but is registered to a different business name. This could indicate a legitimate name change, a DBA filing discrepancy, or a fraud attempt. Route to manual review with a W-9 request.
• Code 3: TIN not matched due to incomplete IRS records. The IRS cannot confirm or deny. Manual verification required.
• Codes 4 through 8: Various IRS-specific conditions covering processing errors, incorrect name types, and system limitations.[13]
For automated decisioning, the routing is simple. Code 0 proceeds. Code 1 auto-declines. Code 2 routes to manual review. Everything else holds for investigation.
Why Does Real-Time Matter?
The distinction between real-time IRS matching and cached database lookups is critical for fraud detection. Cached databases reflect a snapshot in time. A synthetic identity created last week may not appear in a database that was last updated last month. Real-time matching queries the IRS system directly, meaning the result reflects the current state of IRS records at the moment of the check.[14]
What Types of Fraud Does Front-Loaded EIN Verification Catch?
Moving EIN verification to the front of the waterfall catches several fraud patterns that are otherwise expensive to detect downstream.
How Does It Stop Synthetic Identity Fraud?
Synthetic identity fraud is the fastest-growing fraud category in financial services, with fraudulent activity rising 21% between 2024 and 2025.[15] In business lending specifically, cyberattacks on new small business account creations grew 35% in a recent six-month period, and identity spoofing targeting business applications grew 20%.[16] The attack pattern is specific: a bad actor fabricates a business name, obtains or steals an EIN, and applies for funding using the mismatched pair. EIN verification at step one catches this immediately because the fabricated name will not match the EIN on file with the IRS.
How Does It Flag Application Padding?
Some applicants submit legitimate business names with incorrect EINs, either through carelessness or intentional misrepresentation. A Code 2 result (name does not match) at step one flags these applications for manual review before the lender invests in downstream verification. Without this early check, these applications flow through the entire pipeline, consuming resources at every stage.
How Does It Detect Stale or Defunct Entities?
A Code 1 result (TIN not issued) can indicate that the EIN was never assigned, was assigned to a different entity type, or belongs to a dissolved business. While Secretary of State data also catches dissolved entities, the EIN check provides an independent confirmation from a different authoritative source.[20] Running both checks provides two-factor business identity verification.
What Are the Practical Limits of Front-Loading EIN Verification?
Honest positioning requires acknowledging where this approach has boundaries.
When Does a Code 2 Result Not Mean Fraud?
A name mismatch (Code 2) is not always a fraud signal. Legitimate causes include:
• Recent name changes. A business that legally changed its name may not have updated its IRS records yet.
• DBA vs. legal name. Applicants sometimes submit their DBA (doing-business-as) name instead of the legal name on file with the IRS.
• Abbreviation differences. "LLC" vs. "L.L.C." or "Inc." vs. "Incorporated" can trigger a mismatch depending on how the name was originally filed on Form SS-4.
• Ampersand handling. "Smith & Jones" vs. "Smith and Jones" may produce different name controls.
Lenders should treat Code 2 as a "hold and verify" signal, not an automatic decline. Requesting a W-9 from the applicant resolves most legitimate mismatches within one business day.
What About IRS System Availability?
The IRS TIN matching system is available 24 hours a day except Sundays from 12:00 a.m. to 4:00 p.m. ET, when scheduled maintenance runs.[17] Unscheduled outages also occur. For a shop processing thousands of files, the question is what happens to the queue during those windows.
The fallback logic should work in three tiers:
• Tier 1: Queue and hold. Applications received during an IRS outage enter a holding state. They do not advance to step two (SOS lookup) until the EIN check completes. This preserves the cost savings of front-loading but introduces latency.
• Tier 2: Time-boxed bypass with retroactive check. If the IRS is unavailable for more than four hours, allow applications to proceed to step two only, but flag them for mandatory EIN verification before step three. This limits exposure to one additional credit per file rather than the full downstream stack.
• Tier 3: Batch reconciliation. For applications that cleared the full pipeline during an extended outage, run a batch EIN verification as soon as the IRS system returns. Any Code 1 or Code 2 results trigger an immediate hold on funding, even if the file has already been approved.
The key principle: never permanently skip the check. A delayed EIN verification still catches fraud before funding. A skipped one does not.[18]
Does EIN Verification Replace Other Checks?
No. EIN verification confirms one thing: the business name and EIN pairing matches IRS records. It does not verify that the business is in good standing, that it has no liens, that its principals have no judgments, or that its financial statements are accurate. The value of front-loading EIN verification is not that it replaces downstream checks. It is that it prevents wasted spend on downstream checks for applications that should never have progressed past step one.
How Do You Implement This Change in Your Existing Stack?
Restructuring the waterfall requires minimal engineering effort but demands intentional process design.
What Does the API Integration Look Like?
The Cobalt Intelligence TIN/EIN Verification API is a simple GET request with two parameters:
curl --location 'https://apigateway.cobaltintelligence.com/tinVerification?tin=123456789&businessName=Acme%20Corp' \
--header 'Accept: application/json' \
--header 'x-api-key: Your_API_Key'The response returns a match status and IRS code in JSON:
{
"name": "ACME CORPORATION",
"tin": "123456789",
"status": "Match",
"irsCode": 0,
"irsReason": "TIN and Name combination match IRS records"
}Map the `irsCode` field to your decisioning rules: Code 0 proceeds to step two. Code 1 auto-declines. Code 2 routes to manual review.[19]
How Do You Handle the Transition?
Lenders already running EIN verification later in their waterfall can restructure without interrupting active pipelines:
• Run in parallel first. For 30 days, run EIN verification at both the new (step one) and existing positions. Compare results to validate that the front-loaded check catches applications that would otherwise flow through.
• Measure wasted spend. Track how many applications failed EIN verification at the original position and calculate the total credits, bureau pulls, and analyst time consumed before the failure was caught.
• Cut over. Once the data confirms the savings, remove EIN verification from its old position and make step one the only checkpoint.
What About Existing Integrations?
If you already use Cobalt Intelligence for SOS lookups, UCC searches, or court records, adding EIN verification to the front of the waterfall is a single additional API call. The same API key, the same callback infrastructure, the same monitoring. The only change is the order in which calls are triggered.
The principle is straightforward: decline early, decline inexpensively. Every fraudulent file that reaches step six instead of failing at step one represents wasted credits, wasted analyst time, and wasted pipeline capacity that could have gone to fundable deals.
.jpg){kind=small}
.png)