Bankability and Viability, What They Actually Mean
Two projects arrive at the same funder. Both have a positive net present value at the funder's discount rate. Both show an internal rate of return above the required threshold. Both show a debt service coverage ratio comfortably above one point three. One gets funded and survives. The other gets funded and collapses within eighteen months.
The difference between the two is that one was both bankable and viable. The other was bankable but not viable. Nothing in the metrics on the first page of either submission told the funder that in advance.
Understanding the difference between bankability and viability is one of the most useful things a project sponsor, a board member, or a public-sector infrastructure planner can learn. It reframes the finance question, sharpens the analysis, and stops good money from chasing projects that were never going to work.
Two tests, one project
Bankability is a lender's test. It asks whether a project's cash flows, security, sponsor covenants, and risk allocation are shaped in a way that a debt provider is willing to lend against. It is a question about the financing package: can the deal be closed, will it clear the credit committee, will it survive its documentation.
Viability is an operator's test. It asks whether the project, once funded and built, will generate enough cash on an ongoing basis to service its debt, cover its operating expenses, absorb reasonable shocks, and produce returns for its equity holders. It is a question about the underlying economics: will the plant, the road, the plan, the enterprise actually work under real conditions across the life of the asset.
The two questions overlap but do not collapse into one. A project can be bankable and not viable when its financial engineering satisfies a lender's covenants but its underlying economics do not survive the operating years. This happens more often than sponsors care to admit. It also happens the other way around, less often but more painfully: a genuinely viable project can fail to be bankable if its risk allocation cannot be structured in a way a lender accepts, and it dies without ever getting to the point where its viability could be tested.
The metrics, and what they hide
Every financing decision reaches for the same handful of metrics. Each one answers a real question, and each one hides at least one thing that matters (Brealey, Myers, and Allen, 2020).
Net present value (NPV). The sum of a project's cash flows discounted back to today at a chosen rate, minus the initial investment. A positive NPV means the project creates value; a negative NPV means it destroys it. What NPV hides is that most of the answer is buried in the discount rate. Change the rate by two percentage points and the answer often flips. A project with a positive NPV at eight percent and a negative NPV at ten percent is a project whose viability depends on how confident you are in your cost of capital. Sponsors who use a single "point estimate" discount rate and do not show the sensitivity around it are hiding this from themselves.
Internal rate of return (IRR). The discount rate at which the NPV equals zero. Convenient because it does not require you to pre-select a discount rate. Dangerous because it can produce misleading answers when cash flows change sign more than once (a build phase, an operating phase, and a decommissioning phase can produce two or three IRRs, of which most software returns only one). It also does not tell you the size of the value created, only the rate. A ten percent IRR on a one-million-rand project and a nine percent IRR on a one-billion-rand project are not comparable in any decision-useful way.
Benefit-cost ratio (BCR). The ratio of the present value of benefits to the present value of costs. Standard in public-sector cost-benefit analysis under the South African Treasury framework and in most multilateral development finance institution methodologies (National Treasury, 2010). Answers the question "for every rand of cost, how many rands of benefit are we generating?" The trap is that it is exquisitely sensitive to how benefits are defined and quantified, particularly for socio-economic benefits like time saved, health outcomes improved, or environmental damage avoided. Two analysts can look at the same project and produce BCRs one full number apart depending on the shadow prices they choose.
Debt service coverage ratio (DSCR). The ratio of cash available for debt service to the debt service itself. A DSCR of one point three means the project generates thirty percent more cash than it needs to pay its debt in that period. Lenders live and die on this number, because it is what tells them how much room there is before a covenant breach becomes a default. What DSCR hides is the shape of the cash flows across the whole period. A project with an average DSCR of one point five that goes below one in years three and four is a project with a coming crisis, even if the average looks comfortable.
Bankable but not viable, the failure mode
The most expensive projects in Africa's recent infrastructure history have been bankable but not viable. Their financing packages closed. Their credit committees approved them. Their construction phases were funded and executed. And then, during the operating years, their economics failed to hold.
The mechanism is usually one of three things. Sometimes the demand forecast was wrong (a toll road that assumed traffic growth that never arrived; a power plant with an off-taker whose demand collapsed). Sometimes the operating cost base grew faster than the revenue base (currency mismatches, imported spares, wage growth that outstripped the tariff escalator). Sometimes a critical assumption in the financing package failed (a subsidy that did not renew, a government guarantee that was not honoured, a tariff review that did not deliver).
In each case, the bankability analysis was correct as far as it went. The financing was appropriately structured for the assumptions it was built on. What was missing was a serious viability test: an honest look at whether the assumptions the bankability rested on would themselves survive the operating years.
The reverse failure, viable but not bankable, is less dramatic but equally common. A project with real underlying economics can fail to attract debt if the risk allocation cannot be structured to satisfy a lender. Small independent power producers, for example, often have genuine unit economics that would sustain a going concern, but they cannot secure the off-take contracts that would allow project finance debt (Yescombe and Farquharson, 2018). The project might survive if it could be built. It cannot be built because it cannot be financed.
The workbook approach
Serious analysis of a project's bankability and viability sits in a properly built financial workbook. This is where the actual work happens: where inputs are declared explicitly, where formulas can be inspected and audited, where scenarios can be run and sensitivities tested, and where the metrics on the summary page are reproducible to the cent from the raw inputs below.
CentraSolve's Bankability and Viability module is built on this discipline. The CBA workbook that sits at the heart of the module is not a bespoke tool: it uses the South African National Treasury cost-benefit analysis conventions and standards that inform Budget Facility for Infrastructure submissions (National Treasury, 2019), reproduced in a form that boards, funders, and analysts can inspect. Every KPI on the summary page ties back to the underlying cash flows to the cent. The parity harness in the codebase enforces this: if a change to a formula anywhere in the workbook breaks the tie between the KPIs on the summary and the underlying calculations, the platform will not accept the change.
The reason this matters is defensibility. When a bankability analyst walks into a credit committee, or when a treasury official reviews a BFI submission, the question they will ask is not "what does your NPV say". It is "how did you get to that NPV, and does that number reproduce when I inspect your assumptions". A workbook that cannot answer that question is a workbook that will not pass review.
Sensitivity, not point estimates
Every serious bankability or viability report contains a sensitivity analysis. The sensitivity analysis is often treated as decoration; it should be treated as the most important slide in the pack.
The convention is a tornado chart, showing how the headline metric (usually NPV or DSCR) moves when each input variable is shocked in isolation, one at a time, by a defined percentage. The wider the bar, the more the metric is sensitive to that variable. The variables at the top of the tornado are the ones the project's viability actually depends on. Those are the assumptions that need to be defensible in depth.
A tornado chart done well tells the reader that the project's IRR is robust to a fifteen percent shock in construction cost but collapses on a five percent shock in tariff. That is decision-useful information. It tells the analyst what to focus their remaining due diligence on. It tells the board what to worry about. It tells the funder where to write covenants.
A tornado chart done poorly tests the wrong variables (input costs that are actually contractually fixed, revenue streams that are actually take-or-pay) and gives the false comfort that the project is robust. Everyone reads it, nobody questions it, and the covenant that should have been written is not written.
Where sponsors get it wrong
Three failure patterns show up repeatedly in South African project finance submissions, and they are the failures worth defending against.
Optimistic revenue assumptions. Traffic forecasts, tariff escalation forecasts, demand growth forecasts, all tend to sit at the upper end of what the analysis could reasonably justify. The reason is human, not technical: sponsors want their projects to look good and analysts want the deal to close. The corrective is to demand that revenue assumptions be triangulated against at least two independent sources, one of which is not commissioned by the sponsor.
Optimistic construction cost estimates. Actual construction costs on African infrastructure projects routinely come in above the budgeted figure. The corrective is not just a contingency line; it is an explicit stress case that models the project at construction cost 20 percent above budget and confirms the financing package still holds together.
Underweighted operating cost inflation. Operating expenses in South African infrastructure projects have historically inflated faster than headline CPI, driven by wage settlements, imported spares, and electricity price rises. Sponsors who model opex escalation at CPI systematically understate the true operating cost trajectory. The corrective is a differentiated opex escalation schedule that reflects the actual cost drivers of the project.
A quick self-test
Before a submission goes to a credit committee or a BFI evaluation panel, eight questions are worth answering honestly:
- Does the workbook reproduce every KPI on the summary page from the underlying cash flows without any manual adjustment?
- Is the discount rate defensible against at least two independent benchmarks?
- Does the sensitivity analysis show the project's dependence on the assumptions most likely to move?
- Are revenue assumptions triangulated against at least one independent source?
- Is there a construction-cost stress case at plus twenty percent?
- Does the opex escalation schedule reflect actual cost drivers rather than headline CPI?
- Does the DSCR hold above one point two in every period, not just on average?
- Is there a plausible operating scenario under which the project fails to service its debt, and is it a scenario that can be walked away from, insured against, or covenanted around?
If the answer to any of those is no, the project is not ready for a decision.
The CentraSolve Bankability and Viability module is built to answer those eight questions defensibly, and to produce the kind of report a serious funder or a National Treasury BFI evaluator will treat with respect. Projects that pass that discipline are not necessarily the projects that get funded. But they are the projects that, once funded, are still standing five years later.
References
Statutory and framework sources
National Treasury, Republic of South Africa. (2010). A guide to socio-economic cost-benefit analysis for public investments. Pretoria: National Treasury.
National Treasury, Republic of South Africa. (2019). Budget Facility for Infrastructure: guidelines and templates. Pretoria: National Treasury.
Textbook and practitioner sources
Brealey, R. A., Myers, S. C., and Allen, F. (2020). Principles of corporate finance (13th ed.). New York: McGraw-Hill Education.
Yescombe, E. R., and Farquharson, E. (2018). Public-private partnerships for infrastructure: principles of policy and finance (2nd ed.). Oxford: Butterworth-Heinemann.
Editor's note. The metrics in this article are treated at a conceptual level. Where a live project or a live submission depends on any of them, the calculations should be reproduced in a workbook of the sponsor's own construction, verified against an independent second view, and stress-tested under the sensitivities that matter to that specific project. The CentraSolve Bankability and Viability module supports this discipline; it does not replace it.