1. Define the financed service before sizing debt
AI infrastructure can be financed at several layers. A borrower may own a powered shell, lease a fitted data hall, operate servers for a customer, provide a managed cloud platform or combine these services. The revenue contract can relate to megawatts, racks, accelerators, clusters, reserved GPU-hours, tokens, storage, network throughput, managed software or a broader outcome. Each layer creates a different asset base, cost exposure, acceptance test and lender remedy.
The financing perimeter should therefore identify every entity, asset, licence, lease, supply agreement and customer obligation that produces the modelled cash. The perimeter should show who owns the land, power connection, cooling plant, network, servers and software; who contracts with the customer; who pays operating costs; and which assets and receivables can be pledged. Related-party services and cross-defaults require explicit treatment because the project can depend on an affiliate that sits outside the security package.
The service definition needs a measurable unit and location. A contractual promise of “AI capacity” can conceal architecture, quantity, power density, interconnect, availability, data-residency and software requirements. The lender should be able to reconcile the signed order to a physical capacity block and a billable service. If the operator can substitute equipment or sites, the substitution conditions, performance equivalence, regulatory requirements and customer consent should be documented.
Term alignment is a first bankability test. Customer commitment, property control, power rights, equipment support, network contracts, insurance and debt maturity should cover compatible periods. A five-year compute contract supported by a three-year site lease or an expiring power reservation creates a gap. A long data-centre lease can also outlast the useful commercial life of the installed compute, creating refresh capital before debt matures.
The project model should use one data dictionary across commercial, technical and finance teams. Capacity identifiers, service commencement, availability, price, credits, capex and cash need common definitions. This prevents a term sheet from describing capacity in one unit while the engineering schedule and debt model use another. It also creates the basis for lender reporting after closing.
2. Build a workload register that separates demand from obligation
Forecast AI demand should be decomposed into customer, workload, model stage, service type, geography, start date, duration, quantity, performance class and contractual status. Training, fine-tuning, inference, data processing and simulation can have different utilisation profiles. A customer can also move workloads between owned infrastructure, hyperscalers and specialised providers. The register should preserve these distinctions before aggregating demand.
Commercial pipelines should be classified by evidence. An expression of interest, forecast, reservation request, signed term sheet, cancellable order, committed contract and accepted capacity are different states. Only the enforceable payment obligation should enter contracted lender revenue. Other states can support a separate upside case when their conversion assumptions are disclosed and tested.
Time granularity matters. Annual capacity can hide monthly ramps, delayed model launches, seasonal inference, burst demand and migration. The register should show the minimum contracted quantity, expected actual use and maximum option quantity for each period. Where the customer pays for reserved capacity regardless of use, the model should still test whether credits, delay or termination can reduce the payment.
Customer concentration should be visible at the capacity, revenue, EBITDA and cash levels. CoreWeave disclosed that its largest customer represented 62 per cent of 2024 revenue and continued to identify material concentration risk in later filings. High concentration can coexist with strong credit, yet the financing remains exposed to one customer's strategy, delivery approvals and willingness or ability to perform. A lender should therefore assess both obligor quality and dependency.
The register should reconcile to infrastructure. Each workload row links to a site, hall, cluster, power block, equipment generation and network path. Capacity without allocated infrastructure can create double booking. Infrastructure without committed workloads creates merchant exposure. A combined register shows when customer ramp and physical delivery diverge and quantifies the cash effect.

Values are hypothetical; the lender case should distinguish minimum commitment, expected use and stress use.
Table 1. Minimum workload-register fields
| Field | Evidence | Principal risk | Lender treatment |
|---|---|---|---|
| customer and guarantor | executed contract and corporate records | weak or wrong obligor | credit approval and support |
| workload and service unit | order form and technical schedule | ambiguous deliverable | objective definition |
| capacity block | site, cluster and power identifier | double booking | eligibility test |
| commencement and ramp | milestone and acceptance schedule | delayed cash | availability gating |
| minimum payment | invoice formula and commitment | usage-dependent revenue | contracted base case |
| options and burst use | option notice and price | speculative upside | excluded or probability case |
| credits and termination | SLA and remedies | revenue erosion | stress adjustment |
| collection account | invoice and cash-control map | leakage or set-off | controlled cash waterfall |
Every revenue row should link a customer obligation to identifiable capacity and cash.
3. Translate a take-or-pay label into enforceable cash
A take-or-pay arrangement usually requires the customer to pay for a reserved quantity whether or not it uses the capacity. Public CoreWeave filings describe committed contracts that reserve capacity for multi-year terms on this basis. Public Core Scientific disclosures describe colocation arrangements with fixed pricing, annual escalation and no unilateral termination by the customer. These examples show how committed revenue can support financing, while their detailed conditions also demonstrate why the label alone does not establish bankability.
The contract must identify the capacity unit, quantity, term, start condition and payment formula. It should state whether the customer pays after capacity is available, after acceptance, after installation of customer assets or on a fixed date. A start condition controlled by the customer can defer revenue even when the project is complete. A fixed date can expose the operator when required infrastructure is late. The allocation should match the party controlling each risk.
Minimum payment should be expressed independently from actual utilisation. The formula should identify reserved quantity, unit price, escalation, taxes, power, pass-through costs, credits and any prepaid amount. The lender model should reconcile the formula to invoices and cash. If unused capacity can be resold, the contract should state who receives resale proceeds and whether they reduce the original customer's payment.
Termination rights require a complete schedule. Convenience termination, repeated service failure, regulatory change, sanctions, force majeure, data breach, delayed delivery, change of control and insolvency can have different payment consequences. A termination fee should be tested for enforceability, calculation, timing and credit support. A nominal fee that is capped below outstanding debt or difficult to collect provides limited protection.
Set-off and dispute provisions also affect cash. A customer may seek to withhold amounts across several services or affiliates. Lenders usually prefer payments to continue for undisputed capacity while a narrow dispute process addresses the contested amount. Broad set-off rights can turn an operational issue into immediate debt-service stress.
4. Make delivery and acceptance objective
Compute contracts often commence after a capacity block satisfies technical, legal and operational conditions. The schedule should specify equipment, architecture, quantity, location, power, cooling, network, security, software, performance, availability and compliance. Each requirement needs a test method, responsible party, evidence, cure period and consequence.
Acceptance should avoid subjective satisfaction where possible. Benchmark thresholds, burn-in periods, cluster-health metrics, network latency, storage throughput, power stability and security controls can be measured. Customer-specific applications may require a test harness and data-handling protocol. The operator should retain evidence that the contracted service passed each criterion.
Partial acceptance can preserve cash when a large deployment arrives in phases. The contract can define capacity blocks with separate readiness and billing dates. This prevents one delayed block from deferring an entire campus. It also supports staged debt drawdowns and allows the lender to match funded capex with accepted revenue.
Delay allocation should distinguish operator delay, customer delay, utility delay, equipment delay and force majeure. Customer-caused delay can trigger deemed acceptance, storage charges or continued minimum payment when the service is ready. Operator-caused delay can trigger credits, liquidated damages or termination. The remedies should connect to the debt model and remain within the project's liquidity capacity.
Change control is critical because AI architectures evolve quickly. The customer may request a newer accelerator, higher density, liquid cooling, network change or software stack before delivery. The change process should identify incremental capex, schedule, price, acceptance and ownership. The operator should avoid absorbing a technology upgrade under a fixed price without a funded adjustment.
5. Design a contract architecture lenders can control
The project structure typically includes the borrower or special-purpose company, sponsors, customer, data-centre owner, utility, equipment suppliers, network providers, operator, insurers and lenders. Bankability depends on the links between them. A long customer commitment cannot support debt when the borrower lacks durable access to the site, power, equipment or service capability needed to perform.
Direct agreements can give lenders notice of default, cure periods and step-in rights under key project documents. A lender may need to preserve the customer contract, site lease, power agreement, equipment support and operating arrangement while enforcing security. Consent requirements and confidentiality restrictions should be resolved before closing.
Cash control should identify every payment path. Customer prepayments, monthly charges, power reimbursements, service credits, insurance proceeds and termination amounts can be directed to controlled accounts. The waterfall then pays taxes and essential operating costs, debt service, reserves and permitted distributions in the agreed order. Public Core Scientific disclosures describe contract cash directed to a lockbox tied to secured notes, illustrating how contract revenue can be integrated into debt security.
Security should match the asset and legal regime. It may include shares, receivables, bank accounts, equipment, insurance, material contracts and rights under leases. Equipment owned by a customer or lessor cannot be assumed to support lender recovery. The lender should verify title, serial-number records, liens, access, removal rights and intercreditor arrangements.
The structure should also address replacement. If the operator fails, a substitute operator may need software, employees, vendor licences, customer data and physical access. Step-in rights without operational capability have limited value. A practical enforcement plan identifies the minimum continuity package and the time required to implement it.

The financeable chain connects service delivery, customer payment and lender control.
Table 2. Bankable compute-capacity contract matrix
| Clause | Bankability question | Evidence | Model consequence |
|---|---|---|---|
| capacity unit | is the deliverable measurable? | technical schedule | eligible contracted quantity |
| acceptance | who controls commencement? | test protocol and certificate | revenue start date |
| minimum commitment | is payment independent of use? | formula and invoice sample | base revenue |
| price and escalation | does price cover fixed and variable cost? | tariff schedule | margin and coverage |
| availability credits | how much cash can be lost? | SLA and history | credit haircut |
| termination | can the customer exit before debt maturity? | clause and fee schedule | tenor and stress case |
| resale | can unused capacity be remarketed? | consent and proceeds rule | recovery value |
| security and assignment | can lenders preserve the contract? | direct agreement | enforceability gate |
Contract strength depends on the complete clause set and the evidence supporting each clause.
6. Build a price floor from the full service cost
The price floor should begin with the contracted service unit and its full cost. For reserved compute, the schedule may include equipment depreciation or lease cost, power, cooling, network, software, operations, maintenance, insurance, property cost, taxes, security, support, financing, reserves and an agreed return. Costs should be allocated using transparent drivers rather than an average that hides expensive workloads.
Power and cooling can be passed through, embedded in a fixed price or recovered through a hybrid formula. A fixed all-in price gives customer certainty but exposes the operator to energy and efficiency changes. A pure pass-through protects margin but can weaken customer price certainty. A hybrid can set a base allowance, indexed tariff, efficiency benchmark and reconciliation process.
Technology cost requires separate treatment. The service price may remain fixed while new architectures lower unit compute cost. Stanford's AI Index documents rapid declines in the cost of achieving a given inference performance, while NVIDIA disclosures describe frequent product transitions and materially lower token costs for newer platforms. A long fixed price can therefore create operator upside, customer renegotiation pressure or stranded older equipment depending on competitive conditions.
The contract can address this through defined refresh rights, benchmark resets, most-favoured pricing limits, performance bands or shared efficiency gains. Each mechanism changes cash certainty. A benchmark that automatically resets price to an external market index can transmit technology deflation directly to the project. A floor, collar or scheduled review can preserve debt coverage while allowing commercial adjustment.
The lender should test the floor under power escalation, lower utilisation, service credits, equipment refresh and refinancing. The relevant floor is the minimum collected price that covers cash operating cost, maintenance, required refresh, taxes, debt service and reserves. Accounting revenue or EBITDA can overstate available debt-service cash when prepayments, build credits and capital obligations occur at different times.

Unit costs and margin are hypothetical and should be replaced with project-specific evidence.
Table 3. Price and cost allocation schedule
| Component | Pricing method | Evidence | Principal protection |
|---|---|---|---|
| reserved capacity | fixed minimum charge | order and capacity schedule | take-or-pay obligation |
| electricity | pass-through or indexed band | utility invoice and meter | audit and true-up |
| cooling and efficiency | allowance linked to design | PUE and operating data | measurement protocol |
| network and storage | quantity or committed port | supplier and usage records | minimum plus overage |
| equipment refresh | reserve or customer-funded change | asset plan and quotation | change-control payment |
| service credits | capped against affected service | SLA and incident record | monthly and annual cap |
| inflation and FX | index, collar or hedge | published index and currency | floor and reset date |
| termination amount | debt and break-cost formula | payment schedule | guarantee or security |
The schedule should distinguish fixed, indexed, pass-through and periodically reset components.
7. Distinguish revenue backlog from lender cash
Remaining performance obligations and revenue backlog can be useful evidence of committed business, yet they are accounting and management measures rather than direct debt-service cash. CoreWeave's 2025 annual report disclosed substantial remaining performance obligations and explained that the measure is net of estimated variable consideration, including service credits, delivery delays and capacity that can be resold. The lender should therefore reconstruct the cash schedule from contract terms rather than applying an advance rate to a headline backlog number.
The bridge begins with total contracted consideration. It deducts capacity not yet delivered, options, variable usage, sales taxes, power pass-throughs that fund matching costs, estimated service credits, customer-funded capex offsets and amounts outside the security perimeter. The remaining scheduled billings are then adjusted for payment timing, prepayments, build credits, retainage, disputes and collection assumptions.
Revenue recognition can lead or lag cash. A provider may recognise service revenue before billing, receive prepayment before service, or provide credits against later invoices. Core Scientific disclosures describe customer prepayments and build credits that affect the timing of collection relative to recognised revenue. The project model should use a monthly cash ledger that starts with opening deferred revenue and receivables and reconciles service delivery, invoices, credits and collections.
Prepayments can reduce construction funding but create performance obligations and refund exposure. The cash-control waterfall should distinguish amounts available for project cost from amounts that must remain restricted. If the customer can reclaim a prepayment after delay or termination, the liquidity case should include that contingent outflow.
The lender should also test whether billing depends on customer data, usage reconciliation or acceptance documents. A contract can be committed while invoice issuance is operationally fragile. Billing controls, dispute ageing and collection history become part of credit diligence.
8. Score the counterparty and the dependency
Counterparty analysis should cover the contracting entity, guarantor, parent, customer group and source of payment. An investment-grade parent can strengthen the obligation when the guarantee is direct, enforceable and covers the full term and amount. A well-known group name without a guarantee should not be treated as parent credit.
The scorecard should combine financial capacity, liquidity, leverage, profitability, external ratings where available, ownership, strategy, contract conduct and legal enforceability. Private AI laboratories and start-ups require additional analysis of funding runway, investor support, revenue concentration and future capital needs. Government or sovereign-linked customers require review of authority, budget, procurement and waiver provisions.
Dependency is separate from default probability. A project with one strong customer may have low near-term credit risk and high strategic concentration. The lender should measure the share of revenue, cash, equipment specification and site design controlled by the customer. A bespoke cluster or dedicated site can have limited alternative use after termination.
Circular relationships need transparent treatment. BIS publications discuss structures in which technology companies invest in AI firms or infrastructure providers that then purchase compute, chips or capacity. These arrangements can align interests, yet they may also connect customer demand, supplier credit and sponsor value to the same ecosystem. The lender should map equity, guarantees, supply, offtake and resale relationships and avoid counting one support source twice.
The score should influence advance rate, tenor, concentration limits, reserves and security. It should be updated after rating changes, financing events, material litigation, contract amendments, payment delay or strategic shifts. A static closing score cannot govern a rapidly changing AI customer.

Scores are hypothetical; lender policy should define evidence, weights and approval thresholds.
9. Allocate availability risk through measurable service levels
Availability commitments can support customer trust and create material revenue leakage. The service-level agreement should define the measured service, measurement point, excluded events, maintenance windows, calculation period, credit formula and maximum liability. Site availability, cluster availability, job completion and application performance are different measures.
The operator should avoid accepting performance risk outside its control without matching rights. Customer software, data pipelines, third-party networks, utilities and force majeure can affect outcomes. Exclusions should be precise and evidence-based. A broad exclusion can weaken the customer contract, while a broad operator obligation can make revenue volatile.
Credits should be modelled using incident history and contractual caps. The lender case should include ordinary credits, a severe incident and repeated failure that triggers termination. Credits that roll forward or apply across services can create larger cash effects than a monthly cap suggests.
Maintenance and refresh require planned downtime. The contract should allow agreed windows and emergency work while protecting critical workloads. If the customer requires continuous service, the project may need redundant capacity or live migration. The associated capital and operating cost belongs in the price floor.
Availability reporting should reconcile monitoring systems, incident tickets, customer notices, root-cause analysis, credit calculations and invoices. The lender can require regular reporting of service levels and credit exposure. A measured deterioration can trigger a reserve, distribution lock or remediation plan before it becomes a termination event.
10. Manage technology refresh and residual value
AI computing equipment can retain functional value while losing commercial competitiveness. New architectures can improve performance, power efficiency and token economics. NVIDIA's public filings describe frequent platform transitions and significant demand and supply commitments; CoreWeave assigns six-year estimated useful lives to technology equipment while acknowledging rapid technological change. Lenders should therefore separate accounting life, technical life, support life and economic life.
The base case should fund required refresh during the contract term. The refresh plan identifies each asset cohort, architecture, installation date, support period, expected performance, maintenance, residual use and replacement trigger. It should link customer obligations to the equipment generation that can satisfy them.
Refresh responsibility can sit with the operator, customer or both. Customer-funded equipment can reduce project capex but complicate ownership, access and security. Operator-funded refresh protects service continuity while exposing the project to future cost. A shared mechanism can use performance bands, change requests or pre-agreed upgrade pricing.
Residual value should receive limited credit unless supported by observable market evidence and a practical removal and resale plan. Bespoke systems, rapid product cycles, export controls, warranties, software licences, transport and de-installation can reduce recovery. A conservative lender case may treat residual value as recovery upside rather than scheduled debt repayment.
Export controls and data rules can also affect utilisation and resale. The project should identify restricted equipment, customer, location and transfer risks. A contract that depends on deploying or moving controlled technology requires current legal review and contingency capacity.
11. Model DSCR from collected cash under multiple contract states
Debt-service coverage should be calculated from cash available for debt service after operating costs, taxes, maintenance, required refresh and reserve funding. The numerator should exclude uncollected revenue, customer-funded pass-through amounts needed for matching costs, and speculative option revenue. The denominator should include scheduled interest, principal and relevant fees.
At least four cases are useful. The committed case assumes accepted capacity and enforceable minimum payments. The delivery-delay case shifts acceptance and revenue while retaining construction and interest costs. The credit-erosion case applies service credits, disputed invoices and delayed collection. The merchant case assumes the customer exits and capacity must be remarketed at a lower price after downtime and reconfiguration.
The model should also test cost shocks. Electricity, cooling, network, insurance and equipment can increase while the minimum price remains fixed. Indexation and pass-through reduce this risk only when the contract and billing process operate as intended. The stress case should apply timing lags and caps.
Debt sizing can use the lower of contracted-cash coverage, asset advance rate and project cost limits. Concentration, construction and technology risks can justify lower leverage, amortisation, cash sweeps and reserves. A strong take-or-pay contract can support longer tenor, yet tenor should remain within the durable contract and asset-control period.
The model needs transparent conversion between service units and cash. Reserved GPU-hours, megawatts and contract value should reconcile to physical capacity, price and invoice periods. This provides an audit trail for lender diligence and later covenant reporting.

Coverage ratios are hypothetical and do not represent a financing recommendation.
Table 4. Lender scenario matrix
| Scenario | Revenue treatment | Cost treatment | Financing response |
|---|---|---|---|
| committed base | accepted minimum payments | contracted operating cost | scheduled amortisation |
| expected use | minimum plus evidenced overage | incremental variable cost | cash sweep upside |
| delivery delay | revenue shifts by milestone | capex and interest continue | liquidity reserve |
| availability stress | credits reduce billings | remediation and redundancy cost | distribution lock |
| counterparty stress | delayed collection or support draw | essential operations continue | debt-service reserve |
| termination | fee plus remarketing after downtime | reconfiguration and sales cost | mandatory prepayment or waiver |
| technology reset | price and use under new architecture | accelerated refresh | sponsor or customer funding |
Each case should use project-specific timing, cost, contract and recovery evidence.
12. Set covenants around evidence states
Financial covenants should be supported by operating evidence. DSCR, leverage and liquidity remain important, while compute projects also benefit from tests for accepted capacity, committed revenue, customer concentration, service credits, project completion, refresh reserves and material contract status.
The borrower can report a monthly capacity certificate that reconciles ordered, installed, commissioned, accepted, reserved and billable capacity. A contract certificate can show minimum payment, expiry, options, amendments, disputes, credits and collection. The lender should be able to trace these schedules to invoices, bank statements and engineering evidence.
Triggers should lead to proportionate actions. A mild coverage decline can increase reporting. A material delay can stop distributions and require a remediation plan. Loss of a key contract, site right or power agreement can trigger mandatory prepayment, sponsor support or an event of default depending on severity and cure.
Concentration covenants should reflect replacement risk. A simple percentage limit may be impractical for a single-customer build-to-suit project. The structure can instead require stronger support, lower leverage, amortisation within the contract term, minimum termination value and remarketing reserves.
Amendments to customer contracts require lender controls when they affect quantity, price, term, termination, credit support, assignment or payment accounts. Ordinary operational changes can remain within agreed baskets. This preserves commercial flexibility while protecting the financed cash architecture.
Table 5. Monitoring, covenant and response schedule
| Indicator | Evidence | Early response | Severe response |
|---|---|---|---|
| accepted capacity | certificates and tests | weekly completion report | drawstop or sponsor cure |
| minimum contracted cash | contract ledger | amendment consent | mandatory prepayment |
| collections | invoices and lockbox | ageing review | reserve draw and cash trap |
| service credits | monitoring and tickets | remediation plan | distribution lock |
| DSCR | controlled-account model | enhanced reporting | cash sweep or default |
| customer credit | rating and financials | support review | additional collateral |
| equipment refresh | asset register and plan | reserve top-up | funded replacement |
| key project rights | notices and compliance | cure plan | step-in or enforcement |
Thresholds should be calibrated to the financed project and documented in the finance agreements.
13. Match credit support to the cash-chain weakness
Credit support should address a defined risk. A prepayment can fund equipment or construction but creates performance and refund obligations. A parent guarantee can support customer payment when the contracting subsidiary is thinly capitalised. A letter of credit can cover a limited period of payment or termination exposure. A debt-service reserve provides timing liquidity but does not cure a structurally weak contract.
The amount and duration should follow the exposure profile. Construction risk may require support through acceptance. Customer credit risk may require support through the debt term. Technology refresh risk may require a funded reserve that grows before the replacement date. Termination exposure can be linked to outstanding debt, break costs and remarketing time.
Guarantees require legal and financial diligence. The lender should verify guarantor identity, authority, scope, cap, term, defences, governing law, enforcement and interaction with amendments. A guarantee that falls away after a corporate event or excludes service disputes may provide less support than its headline amount suggests.
Letters of credit and bank guarantees need issuer, rating, expiry, draw, renewal and replacement rules. The project should have time to draw or replace support before expiry. Automatic extension language, notice periods and acceptable replacement issuers reduce cliff risk.
Sponsor support can cover cost overruns, delay or completion, while permanent debt should rely on sustainable project cash. The completion test should include technical acceptance, minimum contracted revenue, funded reserves, legal rights and a demonstrated operating period. Releasing support after physical completion alone can leave revenue commencement unresolved.
14. Protect the project against circular financing and correlated failure
AI infrastructure increasingly involves overlapping equity, supply, capacity and financing relationships. A chip supplier can invest in a compute provider; a hyperscaler can invest in an AI laboratory; an AI laboratory can commit to capacity; and a private-credit vehicle can finance the infrastructure. These links can create alignment and scale, while they can also make several apparently independent protections sensitive to one commercial cycle.
The diligence map should identify direct and indirect ownership, warrants, revenue commitments, supplier finance, guarantees, exclusivity, resale and related-party transactions. Each relationship should be valued once. An equity investment does not automatically support payment. A capacity commitment financed by an investor in the customer can still depend on continuing external capital.
Correlated stress should be modelled. A decline in AI funding can reduce customer demand, weaken equity values, reduce supplier order books and narrow refinancing markets simultaneously. Merchant remarketing assumptions may also weaken when several projects return capacity to the market at the same time.
The lender can respond through conservative leverage, contract diversification, funded reserves, sponsor equity, amortisation and clear cash controls. A project with concentrated but investment-grade offtake can have a different risk profile from one with several early-stage customers whose funding depends on the same investor group.
Disclosure and governance should identify conflicts. Related-party contract approval, independent pricing evidence and amendment controls help protect the project. The financing documents can require notice of new related-party arrangements and limit value leakage through fees, asset transfers or subordinated claims.
15. Prepare a lender diligence package that can be updated
The diligence package should begin with a concise transaction and structure memorandum. It identifies the borrower, sponsors, customer, assets, jurisdictions, project documents, requested debt, sources and uses, construction state, revenue state and proposed security. Each statement should link to current evidence.
The commercial package includes the workload register, customer strategy, pipeline conversion evidence, market alternatives, pricing, concentration, churn and remarketing analysis. The legal package includes executed contracts, amendments, guarantees, site and power rights, licences, assignment, direct agreements, security, regulatory approvals and disputes. The technical package includes design, equipment, capacity, tests, commissioning, service levels, incidents, cyber controls and refresh plans.
The financial package reconciles project cost, capex paid, remaining commitments, customer contributions, prepayments, operating costs, invoices, collections, accounting revenue, taxes, working capital, reserves and debt service. The model should identify formulas, sources, dates and responsible owners. Sensitivities should be reproducible rather than manually overwritten.
The information should be organised around stable identifiers. Customer, contract, site, cluster, capacity block, asset cohort and invoice references should connect workstreams. A lender question about one capacity block can then be traced from contract through engineering, cost, revenue and cash.
The package remains useful after close. The borrower can update the same schedules for drawdowns, completion tests, covenant certificates and annual review. This reduces reporting friction and makes deterioration visible before a payment default.
16. Use a staged financing and decision process
Early development capital should fund feasibility, land, power applications, design and customer contracting under tight budgets and milestones. Construction debt should become available after site, power, permits, fixed-price scope, equity and customer commitments reach defined states. Equipment finance can follow purchase orders, delivery, title and acceptance. Term debt can follow operating acceptance and demonstrated collection.
Draw conditions should align with physical and contractual progress. A construction draw can require sponsor equity, approved budget, engineer certification, customer milestone, insurance and no default. Equipment draws can require serial numbers, title and installation evidence. This controls the risk that debt funds assets without corresponding revenue readiness.
The completion test should be multidimensional. Physical completion, service acceptance, minimum contracted cash, cost-to-complete, reserves, operating licences, direct agreements and model coverage should all be tested. A project can be physically complete while customer acceptance remains outstanding or while service credits have begun.
Refinancing should not be assumed without an identified path. The term case can use amortisation within the contracted period, residual asset value with evidence, or a tested takeout market. BIS analysis highlights the growing role of debt and private credit in AI infrastructure and the potential for refinancing pressure at special-purpose vehicles. A credible financing plan should remain viable when capital markets tighten.
Investment committee approval should specify the downside that can be absorbed. It should identify the customer, contract and technical events that consume contingency, reserves or sponsor support. Decisions become clearer when the paper distinguishes accepted contracted cash from pipeline and residual value.
17. Limitations and research agenda
Public filings and institutional publications provide evidence of market structures, contractual mechanisms and risk categories. They do not establish the enforceability, credit quality, cost, performance or value of a particular project. Contracts can be confidential and materially different even when they use similar labels. Jurisdiction, insolvency regime, security law, data regulation and export controls can change lender outcomes.
The worked examples deliberately simplify capacity, price, cost, credit and debt. A live model requires project-specific monthly cash flows, tax, currency, accounting, legal and technical assumptions. Service quality and customer behaviour can change faster than historical datasets capture.
Further research should compare observed default, credit, utilisation and remarketing outcomes across AI compute contracts. Useful datasets would track contract term, minimum commitment, prepayment, customer rating, equipment generation, service credits, residual value and refinancing. They should distinguish training, inference and mixed workloads.
Research should also examine whether falling unit compute costs increase total demand enough to preserve contracted prices, how new architectures affect older cluster utilisation, and how sovereign AI and data-residency requirements change contract durability. Lender outcomes after technology refresh and customer migration would improve advance-rate and reserve calibration.
The framework can be tested through post-close variance analysis. Each project can compare contracted, accepted, billed and collected capacity with the underwriting case. The results can refine clause design, stress assumptions and monitoring triggers without relying on generic market optimism.
18. Conclusion
AI workload offtake finance requires a controlled conversion from uncertain demand to enforceable collected cash. A forecast or backlog can support commercial planning, while project debt needs a defined service, objective acceptance, durable minimum payment, adequate price floor, credible counterparty and controlled payment path.
The proposed framework uses five linked controls. The workload register separates interest, commitment and actual use. The contract matrix tests the clauses that determine payment. The price-floor schedule connects revenue to full cash cost. The counterparty scorecard combines obligor quality with project dependency. The lender scenario model tests coverage under delivery, credit, termination and technology stress.
The same system supports execution after close. Capacity identifiers, acceptance evidence, invoices, service credits, collections, refresh and covenants can remain in one lender reporting architecture. This allows management, sponsors and lenders to intervene while problems are operational and curable.
Financeable AI infrastructure therefore depends on disciplined contract engineering. The strongest structure connects every modelled payment to capacity that can be delivered, accepted, billed, collected and preserved through default. Revenue outside that chain belongs in a separately identified upside case rather than the debt base.
References
- International Energy Agency, Energy and AI, 2025. https://www.iea.org/reports/energy-and-ai
- International Energy Agency, Energy and AI: Executive Summary, 2025. https://www.iea.org/reports/energy-and-ai/executive-summary
- International Energy Agency, Energy Supply for AI, 2025. https://www.iea.org/reports/energy-and-ai/energy-supply-for-ai
- International Energy Agency, Electricity 2026: Executive Summary, 2026. https://www.iea.org/reports/electricity-2026/executive-summary
- Bank for International Settlements, Financing the AI Boom: From Cash Flows to Debt, BIS Bulletin No. 120, 2026. https://www.bis.org/publications/bulletin-120-financing-ai-boom-cash-flows-debt
- Bank for International Settlements, Financing the AI Infrastructure Boom: On- and Off-Balance Sheet Borrowing, BIS Quarterly Review, March 2026. https://www.bis.org/publications/financing-ai-infrastructure-boom-on-and-off-balance-sheet-borrowing
- Bank for International Settlements, Annual Economic Report 2026. https://www.bis.org/publ/arpdf/ar2026e.pdf
- CoreWeave, Inc., Form S-1/A, 20 March 2025. https://www.sec.gov/Archives/edgar/data/1769628/000119312525058309/d899798ds1a.htm
- CoreWeave, Inc., Form 10-Q for the period ended 30 June 2025. https://www.sec.gov/Archives/edgar/data/1769628/000176962825000041/crwv-20250630.htm
- CoreWeave, Inc., Form 10-K for the year ended 31 December 2025. https://www.sec.gov/Archives/edgar/data/1769628/000176962826000104/crwv-20251231.htm
- CoreWeave, Inc., Third-Quarter 2025 Earnings Release filed with the SEC. https://www.sec.gov/Archives/edgar/data/1769628/000176962825000059/coreweave3q25earningspress.htm
- Core Scientific, Inc., First-Quarter 2025 Earnings Presentation filed with the SEC. https://www.sec.gov/Archives/edgar/data/1839341/000162828025023161/exhibit992-q12025earning.htm
- Core Scientific, Inc., Form 10-K for the year ended 31 December 2025. https://www.sec.gov/Archives/edgar/data/1839341/000162828026013305/core-20251231.htm
- Core Scientific, Inc., Form 10-Q for the period ended 30 June 2026. https://www.sec.gov/Archives/edgar/data/1839341/000183934126000014/core-20260630.htm
- Digital Realty Trust, Inc., Form 10-K for the year ended 31 December 2025. https://www.sec.gov/Archives/edgar/data/1297996/000110465926015365/dlr-20251231x10k.htm
- NVIDIA Corporation, Form 10-K for the year ended 25 January 2026. https://www.sec.gov/Archives/edgar/data/1045810/000104581026000021/nvda-20260125.htm
- NVIDIA Corporation, Form 10-Q for the period ended 26 July 2026. https://www.sec.gov/Archives/edgar/data/1045810/000104581026000075/nvda-20260726.htm
- Stanford Institute for Human-Centered Artificial Intelligence, Artificial Intelligence Index Report 2025. https://hai.stanford.edu/assets/files/hai_ai_index_report_2025.pdf
- World Bank Group, Public-Private Partnership Manual, Volume 4: Project Finance. https://ppp.worldbank.org/sites/default/files/2024-07/Philippines_NGA-PPP-Manual-VOL-4.pdf
- International Finance Corporation, Project Finance in Developing Countries. https://ppp.worldbank.org/sites/default/files/2022-05/ProjectFinance_DevelopingCountries_IFC.pdf

