Fannie/Freddie Day 1 Certainty (D1C) loans rely on direct-source data feeds (Plaid, The Work Number, tax transcripts) flowing into DU/LP. When those loans get sold into non-agency whole loan trades or securitizations instead of being delivered to the agencies, the rep & warrant relief doesn’t travel with them. The TPR firm gets a one-page DU “validated” stamp, and nothing to recompute income, assets, reserves, or DTI from. Fitch’s posture (give us the JSON or the PDF report from the verification vendor) is the right floor, but the market needs to push further: the JSON should be a deal-level requirement, not a nice-to-have, and it should be retained for the life of the loan.
The setup
For anyone who hasn’t been close to this: Day 1 Certainty is the program Fannie Mae built around its DU Validation Service. A lender feeds DU income, employment, and asset data sourced directly from an approved third-party vendor: payroll providers via The Work Number, IRS tax transcripts, asset/VOA feeds from Plaid-powered aggregators, etc. If DU validates the components, the lender gets rep & warrant enforcement relief on those components when the loan is delivered to Fannie. Freddie has the analogous construct through LP and AIM.
The whole pitch is: skip the paystubs, skip the W-2s, skip the bank statements. The source data already lives in a system of record the GSE trusts. That works beautifully when the destination is the GSE.
The trap when these loans hit non-agency
Here’s where it breaks. A growing share of D1C-approved loans are not being delivered to Fannie or Freddie. They’re moving into:
• Whole loan sales to private investors
• Non-agency RMBS (jumbo, non-QM, expanded prime, investor-property deals)
• Bank portfolio acquisitions with downstream securitization optionality
When that happens, two things are true at the same time:
- ATR is arguably fine. D1C approval is unconditional once issued. The agencies have effectively blessed the underwriting chain. You can make a credible argument that Ability-to-Repay has been established because the income/employment/asset verification was performed against direct-source data by an approved vendor under an agency-published methodology. Fitch confirmed as much in their response to us. If a loan was approved for D1C and that approval wasn’t conditional, they can get comfortable with proof of D1C approval for ATR purposes.
- You cannot audit the qualification. And this is the part the rating agency response didn’t address when we asked directly. The DU/LP printout in the loan file shows the validated components and the approval, but it does not contain the underlying data records that the validation was performed against. There are no paystubs. There are no bank statements. There is no tax transcript image. There is a stamp saying “this was validated” and a vendor name. The TPR reviewer cannot independently recompute:
• Qualifying income (base, bonus, OT, commission breakdowns; YTD vs. prior year averaging)
• Asset balances and large-deposit sourcing
• Reserves after closing
• DTI, because the income input can’t be tied out
• Whether the validation period (typically 4 months for assets, 12 months for income/employment) was still in force at note date
What Fitch actually said, and what they didn’t
We sent Fitch a direct question on the documentation gap and the inability to recompute. They came back on ATR, which is a different question. Their guidance, quoted from their response:
“From our understanding, if a loan is approved for Day 1 Certainty, the approval is not conditional. If it can be confirmed that Day 1 Certainty approval would not be subject to any conditions we can get comfortable with proof of Day 1 Certainty approval. Our understanding for Day 1 Certainty is that income, assets and employment is confirmed through direct verification and its only for wage earners.
On the non-agency side, if the lender is using direct verification methods such as Plaid, we would want the JSON file or pdf report to be provided to the TPR firm.
Two things stand out.”
First, they want the JSON or the vendor PDF report for the non-agency context. That’s the operative sentence. They are explicitly drawing a distinction between the agency execution (where the DU approval is sufficient) and the non-agency execution (where the underlying verification artifact needs to land in the TPR firm’s hands).
Second, they did not engage with the recomputation problem. Whether the TPR firm can actually re-derive income, DTI, and reserves from what’s provided is a separate question from whether the data was once verified. Fitch’s response implicitly treats the vendor report or JSON as the cure for that but only if it’s actually delivered, retained, and structured in a way that supports re-derivation.
Our position: adopt the Fitch floor, then go further
We’re adopting Fitch’s guidance as the minimum acceptable standard. If you’re putting D1C-approved loans into a non-agency execution, the verification artifact from the third-party vendor, the Plaid VOA, the Work Number VOE/VOI, the tax transcript, has to be in the file. Not the DU summary. The actual vendor report.
But the right operational standard is stronger than that:
Get the PDF and the JSON. Always.
The PDF is a snapshot. It’s a rendering. It’s what a human reviewer can read on day one. The JSON is the underlying data structure. The same payload the vendor sent into DU. The difference matters in three places:
1. Recomputation. With the JSON, a TPR firm or downstream reviewer can reconstruct the income calculation, walk the deposit history, recompute DTI against the actual line-item data, and validate that the values fed into DU match the values represented on the 1003 and in the credit narrative.
2. Repurchase defense. If a repurchase demand comes in three years post-close, the JSON lets you re-derive the qualifying figure from the original direct-source data. The PDF alone might tell you that income was $X. The JSON tells you how it was $X and lets you defend or concede the calculation on its merits.
3. Master-date verification. The validation has a shelf life. If a deal-level rep references “income verified within 120 days of note date,” you need the data record to confirm that timing. The JSON typically carries the verification timestamps natively. The PDF often doesn’t expose them.
Retain it like you’d retain an appraisal
The vendor report should live in the loan file the same way an appraisal does. It should travel with assignments, be in the seller’s custodial file, and be available for any post-close audit or repurchase review for the life of the loan. Treat it as a primary qualification document, not an underwriting artifact.
Build the schema before the volume hits
For aggregators and issuers who are about to scale this: standardize on a MISMO-aligned JSON schema for the verification artifacts now. The vendor ecosystem (FormFree, AccountChek, Finicity, The Work Number, etc.) has been moving toward common structures, but the field names, the way deposits are categorized, the way YTD figures are computed, none of that is fully harmonized. If you ingest five vendors’ JSON without a normalization layer, your TPR firm is going to grade the same income calc five different ways.
The PIW parallel
If this feels familiar, it should. We’ve seen this movie before with Property Inspection Waivers.
PIWs are the collateral-side analog: data-driven valuation confidence. DU/LP looks at Collateral Underwriter data, prior appraisals, public records, AVM signals, and says “we don’t need a new appraisal here.” Inside the agency execution, that’s fine, the GSE owns the model, the data, and the risk, and they grant rep & warrant relief on value.
When a PIW loan gets sold non-agency, TPR firms historically don’t accept the PIW at face value. They drop the value grade to a C and order a secondary valuation product: an AVM, a desk review, sometimes a field review to establish independent value confidence. This is exactly what one of the larger non-agency deals disclosed in SEC filings: on loans approved with a property inspection waiver, the consultant ordered an AVM to test the value, and an initial value grade of “C” was assigned to the PIW loans. The GSE’s data-driven decision is evidence, not substitute, for non-agency due diligence.
D1C is the income/asset/employment version of the same phenomenon. The agency made a data-driven decision and granted itself rep & warrant relief. That decision is meaningful evidence. It is not a substitute for the TPR firm’s independent qualification review when the loan moves into a private execution.
The PIW playbook tells us what the D1C playbook should look like. Side by side:
PIW (collateral)
• Agency-level confidence: AUS issues waiver based on data
• Non-agency TPR treatment: Order secondary valuation (AVM, BPO, desk review)
• Initial grade if no secondary doc: “C” / pending
• What clears it: Independent value evidence within tolerance
D1C (qualification)
• Agency-level confidence: AUS validates based on direct-source data
• Non-agency TPR treatment: Require vendor verification report (PDF + JSON)
• Initial grade if no secondary doc: Should be the same — pending receipt of vendor data
• What clears it: Recomputable income / asset / DTI from vendor data
Treating D1C loans more leniently than PIW loans makes no analytical sense. The risk that an automated income validation got something wrong is structurally the same kind of risk as an automated valuation getting something wrong and arguably higher, because income is more volatile, more time-bounded, and more borrower-specific than property value.
What we’d push for as best practice
For sellers:
• Deliver D1C loans with the full vendor verification package (PDF report + JSON payload) regardless of whether the loan was originated as agency-eligible.
• Update your closing checklist and document custodian instructions to treat the vendor artifact as a required document, not an “if available” item.
• Confirm with your verification vendors that they will deliver the JSON on demand and that you have a retention path for it.
For aggregators and issuers:
• Make the JSON a contractual delivery requirement in your loan purchase agreements for any D1C-approved loan in a non-agency execution.
• Build or contract an ingestion layer that normalizes vendor JSON into a deal-level schema.
• Don’t accept the DU 3.4 file or the DU printout as a substitute for the underlying vendor data.
For TPR firms:
• Grade the qualification “pending” or its equivalent until the vendor data is received and recomputable.
• Develop a recomputation workbook that ties JSON line items back to the 1003 and the credit narrative.
• Flag any D1C loan where the JSON is unavailable as a documentation defect, full stop. That is the actionable signal.
For rating agencies (Fitch, KBRA, S&P, Moody’s, DBRS):
• The Fitch position is the right starting point. The next step is publishing explicit criteria that distinguish between “D1C approval represented in file” and “D1C approval with underlying vendor data delivered in JSON form to TPR.” Those should not be treated as equivalent.
The bottom line
Day 1 Certainty is a great program. The direct-source verification model is genuinely a better way to underwrite than scanned paystubs. But the program was designed for an execution where the agencies own both the validation methodology and the residual credit risk. When the loan is going somewhere else, the data has to go with it, not the stamp that says the data was once looked at.
The Fitch response made the right call by naming the JSON. The industry should make it the default. The PDF is what a human reads. The JSON is what a reviewer reconstructs. In a repurchase fight three years from now, the side with the JSON wins.