What Due Diligence Missed in the Frank Case

JPMorgan acquired student aid startup Frank for $175 million.

The pitch was simple. Millions of users. Rapid growth. Strong adoption.

It did not hold.

Regulators later alleged the company had fewer than 300,000 real users, not the 4.25 million reported. Prosecutors claimed fabricated data was created to satisfy due diligence requests. JPMorgan is now suing early investors, including Aleph. Aleph’s position is that the case is contractual and does not allege prior knowledge of fraud.

This now gets framed as a founder fraud story.

That framing is incomplete.

Because the failure did not start when the data broke.

It started earlier, inside the diligence process that accepted the story.

The Framework

Due diligence breaks when it validates outputs instead of testing how they are produced.

Most processes focus on reported metrics. Users. Growth. Revenue.

That works if the system generating those numbers is real.

It fails when the numbers themselves are constructed to support a narrative.

At that point, going deeper into the same dataset does not reduce risk. It reinforces it.

The shift has to be lateral.

From the numbers to the conditions that make those numbers possible.

Focus on four pressure points.

• Data origin. Where does it actually come from, and can it be independently reconstructed?
• Internal alignment. Do different people describe the system the same way, or does the story change depending on who you ask?
• Organizational friction. Is anyone pushing back internally? In the Frank case, reporting suggested an engineering lead refused to generate synthetic data. That is not noise. It is signal.
• Verification constraints. What limits access to independent validation, and how are those limits handled?

Together, these form the trust architecture behind the metrics.

If that architecture is weak, clean numbers do not mean much.

There is another dynamic that matters.

As more credible actors enter a deal, scrutiny often softens.

The process shifts quietly.

From testing whether the story is true
to checking whether it is consistent.

That is where most diligence gaps appear.

The Application

Enhanced due diligence should introduce friction, not just coverage.

In practice, this means changing how questions are asked.

Not just what are the numbers.

But:

How are these numbers generated?
Who can change them?
What would independent verification actually look like?

It also means paying attention to misalignment.

If answers vary across teams, that matters.

If access is restricted, the response to that restriction matters.

If verification becomes difficult, that difficulty is part of the signal.

None of these points prove misconduct on their own.

But together, they show whether the system can be trusted.

The goal is not to eliminate risk.

It is to avoid reinforcing a narrative that has not been properly tested.

The Hard Stop

Due diligence does not fail because it misses bad data. It fails when it stops challenging the story behind the data.