Executive Summary: A TIN response received today can describe a match checked earlier. Cobalt's current API reference defines lastIRSCheckDate as the IRS check date of the cached result.[1] Keep that date separate from local receipt time, then apply the lender's stated evidence policy before reusing the match.
Which date belongs in the lending decision?
Start with the question the reviewer needs to answer. “Did this submitted name and TIN match?” is different from “When was the supporting IRS check performed?” The file should show both the result and the relevant observation date.
Cobalt documents status, irsCode, irsReason, irsServiceStatus and lastIRSCheckDate as separate response fields.[2] Do not collapse them into one “Verified today” label merely because the application received a successful response today.
What does local receipt time prove?
Record when your system received and stored the response. That timestamp helps reconstruct the application workflow. It does not establish when the underlying IRS check occurred if the returned evidence points to an earlier date.
For example, an illustrative file could show a response received Wednesday with an IRS check date from Monday. Neither date needs to be hidden. The reviewer needs to know what each means and whether the evidence satisfies the policy for the decision being made.
Does an older check automatically fail?
No universal age limit follows from the documented field. Define acceptance according to the relevant lending process and applicable requirements, rather than inventing a vendor or legal expiration period.
An older observation can still be relevant evidence. The operational error is treating it as newly checked without support, or reusing it without considering changed inputs and the purpose of the current review.
What does the API documentation permit you to claim?
The current reference explicitly describes a cached-result check date.[3] That supports a narrow statement: the response exposes a date associated with the underlying check, and a new response alone does not prove a new IRS interaction.
It does not establish a universal cache lifetime, a maximum evidence age, or a guarantee that every repeated request forces a new check. The documented TIN request parameters are tin and businessName; no force-fresh parameter is listed for that endpoint.[4]
What should engineering avoid assuming?
Do not add an undocumented refresh=true or liveData=true parameter to the TIN endpoint because a different Cobalt product uses a similar option. Confirm the supported behavior for this endpoint directly.
Also avoid calculating source age from an unrelated application field such as “last saved.” Use the field whose meaning is documented, and preserve uncertainty if its value is unavailable or cannot be interpreted reliably.
What should the analyst avoid assuming?
A matched name/TIN pair is one specific form of identity evidence. IRS describes its TIN matching service as validating name/TIN combinations before information-return submission.[5] It is not a complete assessment of the borrower's current business condition or repayment ability.
A more recent date does not expand that scope. Keep the rest of the underwriting evidence separate, even when the match is both successful and acceptable under the selected age policy.
How should the application store the evidence?
Bind the result to the exact submitted name/TIN pair and application revision. Preserve the source response and create a separate record of the lender's evaluation. That makes it possible to explain why the evidence was accepted without changing what Cobalt returned.
A practical evidence record should include:
• Submitted pair reference. Identify the name and TIN version used for the request, with access limited according to your policy.
• Matching outcome. Retain the documented status, IRS code and reason rather than storing only a boolean.[6]
• Underlying check date. Preserve lastIRSCheckDate with its original representation and documented meaning.
• Local receipt time. Record when your application obtained the result.
• Evaluation policy. Identify the rule version, review purpose and evidence-age requirement applied.
• Disposition. Record accepted evidence, additional check required, or unresolved age, with the responsible owner.
Should every user see the complete TIN?
Show only the information each role needs under your organization's access policy. An analyst may need a masked reference and the source-result details, while an authorized investigation may require access to the original input. Avoid exposing full identifiers in routine logs or broad support screenshots.
How should a missing date appear?
Use an explicit “Underlying check date unavailable” state. A blank display can invite the reviewer to substitute today's date mentally. Do not populate the missing source date with the request time just to satisfy a required field in the loan origination system.
If the system cannot represent uncertainty, add a separate evidence attachment or review task. The limitation should remain visible until the responsible team resolves it.
How can a policy distinguish acceptable age from unknown age?
Define the rule around the decision being supported. A preliminary intake screen and a final funding condition may require different evidence handling. Document those requirements with the responsible underwriting or compliance owner.
The following is illustrative customer-side logic after dates have been parsed and their meaning established. The threshold comes from the lender's own policy, not from a Cobalt or IRS guarantee.
def evaluate_check_age(received_at, irs_checked_at, allowed_age):
if irs_checked_at is None:
return "check_date_unresolved"
if irs_checked_at > received_at:
return "timestamp_review"
if received_at - irs_checked_at > allowed_age:
return "additional_evidence_required"
return "age_within_selected_policy"What else must the decision consider?
This function evaluates only age. It does not evaluate the matching status, whether the request was valid, whether the submitted pair is still current, or whether the lender has obtained every other required item.
Cobalt's documented IRS code table distinguishes a matching pair from input problems, an unissued TIN, a mismatch and other request outcomes.[7] A recent unsuccessful result should not become accepted match evidence just because it passes the date calculation.
What if the timestamp appears to be in the future?
Route it to review rather than calculating a negative age and automatically passing the rule. Check parsing, timezone interpretation and clock assumptions. Retain the original value so the investigation can distinguish a display problem from a source-data question.
No age calculation should create certainty from an ambiguous value. If the format cannot be established, the right output is an unresolved evidence state.
What should happen when the borrower changes its details?
Treat changed inputs as a separate issue from age. A recent match for an earlier name/TIN pair does not automatically answer a request about a corrected pair. Preserve the relationship between each result and the inputs it evaluated.
Cobalt requires both tin and businessName for the documented request.[8] Your application should therefore retain that pair as a unit when deciding whether a prior result can support a later review.
Does a name correction always mean a new entity?
Do not infer that from the text change alone. Establish what changed and why, then determine which evidence needs to be updated. IRS name-control guidance explains how the legal-name information associated with an EIN affects its matching convention.[9]
The analyst's task is to resolve the relevant identity evidence, not to make an unsupported entity-change conclusion. Record the source of the correction and the resulting submitted pair.
What if an older response arrives afterward?
Attach it to the earlier application revision. Do not let arrival order determine which result becomes the current evidence. A valid response for old inputs remains evidence about those old inputs, even if it arrives after a newer request.
Our guide to common TIN verification failures provides broader result-handling context. For evidence reuse, the additional control is the explicit link between the result, its date and the input version.
What would a pre-funding review look like?
Consider a hypothetical working-capital application where a name/TIN match was obtained during intake. Before funding, the reviewer opens a new API response and sees that its underlying IRS check date still points to the earlier check. These are illustrative facts, not an observed Cobalt customer outcome.
The correct next step depends on the lender's selected policy. If the earlier check is acceptable for the current input pair and review purpose, record that evaluation. If a newer check is required, confirm a supported way to obtain the needed evidence rather than assuming repeated requests changed the underlying date.
What should the review note say?
Identify the current decision, submitted pair reference, check date, response receipt time and policy applied. State whether the evidence was accepted or what remains unresolved. Keep the note specific enough that another reviewer can understand it without repeating the request.
For example: “Current application pair unchanged; underlying check date retained; evidence accepted under the stated policy for this decision.” If an exception is involved, identify the authorized owner and the exact scope of that exception instead of describing it as a new IRS match.
What if service status raises another issue?
Keep it separate. Cobalt documents irsServiceStatus independently of the cached-result date.[10] The status of a service at request time is not the same fact as the age of a prior matching result.
The IRS TIN matching outage workflow addresses service-related next steps. An unavailable service should not cause an analyst to change the source date, and an available service should not cause the interface to claim that an older cached check occurred today.
A reuse decision should explain why the existing evidence is sufficient, without changing when that evidence was obtained.
How should engineering and underwriting test this together?
Use synthetic response fixtures with explicit expected outcomes. Include a successful match within the selected age policy, a successful match outside it, a missing check date, an ambiguous timestamp, a future timestamp, a current nonmatch and a response for a superseded input pair.
Require two outputs for each fixture: the internal disposition and the sentence shown to the reviewer. The display should communicate both the result and its limitation without forcing the analyst to inspect raw fields.
What should repeated requests demonstrate?
Test the possibility that a later response carries the same underlying check date. The application should preserve the new receipt time without relabeling the IRS check as newly performed. This follows the documented distinction between the returned cached-result date and the application's own observation.[11]
Also test a later response with a genuinely different documented check date. Preserve both observations and make the policy evaluation traceable to the one actually used. Do not overwrite the earlier evidence history just because a more recent result is available.
What should operations measure?
Measure the frequency of missing dates, age-policy exceptions, repeated responses with unchanged check dates, and unresolved input-version problems in your own workflow. Keep these separate from ordinary name/TIN mismatches.
Review the reasons with the appropriate owners. A missing-date problem may need a provider clarification. A parsing problem belongs with engineering. A rule that produces unnecessary manual work may need policy review. Counting them all as “TIN failures” obscures the next action.
What should a Cobalt evaluation establish?
Bring the evidence-age requirement your team wants to implement and ask how the current TIN response supports it. Confirm timestamp meaning, format, available behavior for another check and handling when the required evidence cannot be supplied.
When comparing providers, inspect their actual field definitions. Middesk's TIN object, for example, documents created_at and updated_at as object timestamps.[12] Do not assume a similarly named field from a different provider necessarily means “last IRS check.”
Ask the reviewer to evaluate a sample evidence view alongside engineering. The acceptance criterion should be that the reader can identify the matched pair, the relevant check date, the local receipt time and the policy decision without guessing.
Schedule a Cobalt demo with that workflow. The objective is a traceable reuse decision and a supported next step when the available date does not meet the lending file's requirement.
.jpg){kind=small}
.png)