Most candidates who fail a bank modeling test didn’t fail because they couldn’t build a DCF. They failed because the file looked like it was built by someone who’d never worked in a transaction environment.
That’s a different problem — and it requires a different kind of preparation.
At Financial-Modeling.com, we’ve built models under real deal pressure and trained analysts who’ve gone through IB processes at firms across the US, UK, and Europe. What follows is what we actually observe: what banks test, what trips candidates up, and what separates a submission that moves forward from one that doesn’t.
What Investment Banks Actually Put in a Modeling Test
The format varies by bank, by team, and by seniority level. But the underlying logic is consistent enough to prepare for systematically.
The take-home test (48–72 hours). The most common format at the analyst and associate level. You receive a CIM or information package, a set of instructions, and a deadline. The output is typically a fully integrated three-statement model, a valuation (DCF, comps, or both), and a short write-up or model summary. Some banks add an LBO overlay.
Whether to go deeper on LBO versus DCF depends on the team. Coverage and M&A roles lean toward DCF and comps. Leveraged finance and PE-style tests weight the LBO. If you’re not told explicitly — build the three-statement first and add whatever valuation methodology fits the company type.
The timed in-person or virtual test (60–90 minutes). Shorter, more constrained. Banks are testing speed and accuracy under pressure, not depth. What gets cut: extensive scenario analysis, heavy formatting. What cannot be cut: a model that closes, a balance sheet that balances, and assumptions that are visible and traceable.
The case study + model hybrid. Common at VP and above, or in boutique processes. You build a model and then defend it in a follow-up conversation. The model is a starting point for the discussion — which means every assumption needs to be yours and you need to be able to explain it without the file in front of you.
The Structural Errors That Fail Candidates — Not the Formulas
What we see consistently when reviewing candidate submissions: the formulas are usually right. The architecture is usually wrong.
Hardcoded numbers inside formulas. A senior reviewer opens a model and the first thing they do is hit Ctrl+` to show formulas. If they find a number sitting inside a formula — not in a clearly labeled input cell — that’s an immediate signal: this person doesn’t build models for other people to use. In a transaction environment, that’s disqualifying.
No separation between inputs and outputs. A bank-grade model has a clearly defined input layer — assumptions visible, labeled, and editable in one place — and an output layer that flows mechanically from those inputs. A model where assumptions are embedded throughout the calculation engine is not reviewable under deal pressure. Banks know this. The test is partly designed to surface whether you know it too.
A balance sheet that doesn’t balance. This sounds basic. It eliminates more candidates than any other single error. Not because the math is hard — but because candidates under time pressure skip the reconciliation step and submit before checking. The cash plug, the revolver mechanics, the retained earnings rollforward: these need to work before you submit, not after.
No scenario or sensitivity structure. Even a simple data table on key assumptions signals that you understand models are tools for decision-making, not just calculation engines. A model with no scenario layer is a finished product. A model with a scenario layer is a working instrument. Banks hire people who build working instruments.
What “Bank-Grade” Actually Means — In a Test Context
The phrase gets used loosely. Here’s what it means in practice, specifically in a modeling test submission.
Auditability. Every number in your output is traceable back to a source — an assumption cell, a formula, or an explicitly stated external input. A reviewer should be able to follow the logic of your model from any output cell backward to its driver without asking you a question.
Assumption visibility. Inputs are grouped, labeled, and color-coded or separated from the calculation engine. The standard convention — blue for hardcoded inputs, black for formulas — exists because it works. If you use your own system, it needs to be internally consistent and immediately legible to someone who’s never seen your file.
Error-proofing. That means: no circular references you haven’t disclosed and controlled, no range errors that surface under different input scenarios, and no links to external files. A model that works under the base case but breaks under a stress scenario is not a model — it’s a liability.
Structural integrity under stress. This is the actual test. Not whether the base case is right, but whether the model holds when assumptions are changed. If a reviewer moves your revenue growth rate from 5% to -5% and the P&L, balance sheet, and cash flow statement all update correctly and consistently — that’s a model. If something breaks, that’s a problem.
We deliberately don’t build models with merged cells, hidden rows used as calculation workarounds, or sheet structures that require a guided tour to navigate. These are habits that look like shortcuts and read as inexperience to anyone who reviews models for a living. In a test submission, they signal the same thing.
If you’re preparing for a test in the next 48–72 hours and you want a structured framework for what to build and how to structure it — that’s exactly what we can help with.
How to Prepare in 48 Hours or Less
The most useful thing you can do in the first two hours is not to open Excel. It’s to understand the business you’re modeling.
Read the CIM or case materials as if you’re going to defend an investment recommendation — not as if you’re looking for numbers to plug in. What drives revenue? What are the key cost variables? What does the balance sheet look like structurally? What’s the debt situation? The answers to these questions determine your assumption architecture before you’ve built a single formula.
Hour 1–2: Read and map. Understand the business. Identify the three to five assumptions that will drive 80% of the model output. Note what’s given and what you’ll need to estimate.
Hour 3–8: Build the three-statement skeleton. Revenue build → P&L → working capital assumptions → capex → debt schedule → balance sheet → cash flow statement. Don’t start with formatting. Build the logic first, confirm it integrates, then clean it up.
Hour 9–12: Add valuation. DCF: unlevered free cash flow, WACC, terminal value. Keep the WACC build transparent — discount rate, equity risk premium, beta, capital structure all visible and labeled. Add comps if requested or if the CIM gives enough data to build a reasonable peer set.
Final two hours: stress test, then format. Run your own scenario — cut revenue 15%, increase capex 20%, stress the debt schedule. Does the model hold? If not, fix it before you submit it. Formatting is the last step, not the first.
If you only have 60–90 minutes — as in a timed test — the order of priority is: a model that closes, assumptions that are visible, and a balance sheet that balances. Everything else — scenario tables, detailed comps, elaborate formatting — is secondary. A clean, closed model with clear assumptions beats an ambitious model that doesn’t balance.
Frequently Asked Questions
What do investment banks actually test in a financial modeling test?
Most tests center on three-statement model integration, DCF valuation, and — depending on the group — LBO mechanics. The underlying evaluation is model architecture: are assumptions visible, is the file auditable, and does it hold under changed inputs?
How long does an investment banking modeling test typically take?
Take-home tests run 48–72 hours. Timed in-person or virtual tests are typically 60–90 minutes. Case study formats vary. The time constraint is part of the test — pace accordingly.
Do I need to know LBO modeling for an IB test?
It depends on the group. Leveraged finance, restructuring, and sponsor coverage roles weight LBO heavily. M&A and coverage roles focus more on DCF and comps. If the instructions don’t specify — ask, or default to whatever valuation methodology fits the company’s capital structure.
What is the most common reason candidates fail a bank modeling test?
File architecture, not formula errors. Hardcoded numbers inside formulas, no input/output separation, and a balance sheet that doesn’t close are the structural failures that eliminate submissions before a senior reviewer finishes the first tab.
If you’re working toward a modeling test and want to close the gap between what you know and what banks actually expect — that’s the problem our training is built to solve.