GPU-Backed Lending: AI Infrastructure Due Diligence

GPU-backed lending asks a lender to underwrite more than expensive hardware. The recovery case may depend on an operator’s installed servers, the legal path to the collateral, a data-center relationship, and contracted compute revenue—all while the equipment can depreciate faster than traditional infrastructure.

That makes a conventional credit memo too easy to over-trust. A better first artifact is an evidence register: a compact record that distinguishes an asserted fact from a document, an independently verifiable operating signal, and a human approval.

This is a research and diligence workflow, not investment advice, a credit recommendation, or a substitute for legal, technical, or valuation review.

Why the collateral is not the whole credit

On August 28, 2026, Bullish announced a $100 million stablecoin-based liquidity facility for USD.AI to finance high-performance computing assets. The announcement is useful as a current example of a structure that treats compute as financeable infrastructure, but it is not proof that any individual facility is sound. Bullish’s announcement should be read as issuer-supplied information.

USD.AI’s explanation of its own loan process shows why the review has to span a wider chain: a dedicated borrower SPV, equipment and contracts assigned to it, escrowed funding, installation and independent verification, and release conditions before an OEM or supplier is paid. Those are claims about one lender’s process, not a universal market standard. They do, however, make the diligence questions concrete. USD.AI’s financing walkthrough identifies the relevant links in that chain.

The broader market also calls for cross-disciplinary review. KBRA frames AI compute credit considerations across project finance, structured finance, and corporate credit; PIMCO emphasizes enforceable collateral and control of key contracts for AI-infrastructure financing. KBRA and PIMCO are useful independent starting points—not a replacement for deal documents.

The evidence register to build before an approval

Do not ask an AI system whether a loan is “safe.” Ask it to organize what has, and has not, been substantiated. Start with a register such as this one.

Review area	Evidence to request	Verification method	Escalate when
Asset identity	Purchase order, serial-number schedule, supplier invoice	Reconcile serial numbers, supplier, and asset schedule	Hardware list cannot be matched to legal collateral
Security package	SPV chart, pledge documents, assignment notices	Counsel confirms priority, perfection path, and enforcement limits	Parent or operating-company claims can interrupt control
Installation and operations	Data-center agreement, commissioning record, telemetry scope	Independent technical reviewer confirms installed and online status	Uptime, location, or telemetry cannot be independently evidenced
Revenue support	Executed offtake contract or documented on-demand revenue	Review counterparty, term, termination rights, billing, and collections	Revenue depends on revocable, concentrated, or unpriced demand
Cash control	Escrow agreement, release conditions, account-control agreement	Confirm who releases funds and whether tests are documented	Draw proceeds can move before conditions are met
Insurance and continuity	Policies, loss-payee status, replacement and service terms	Confirm coverage, exclusions, and claims process	A material loss leaves no usable replacement path
Recovery	Valuation policy, resale channels, removal plan, timing assumptions	Run a conservative liquidation and downtime scenario	Recovery relies on a single buyer or an untested resale assumption
Technology and compliance	OEM support status, export-control and data-center constraints	Specialist review of product, jurisdiction, and contract restrictions	A restriction can block operation, transfer, or resale

An empty field is not a neutral result. It is a reason to mark the claim as unverified, identify its owner, and set a deadline before a credit committee treats it as support.

A copyable GPU-credit evidence prompt

Use this prompt with a document set that the organization is permitted to process. Remove customer data, security-sensitive infrastructure details, and non-public deal terms unless the system is approved for them.

You are an evidence-register assistant for a proposed GPU-backed credit facility.
You are not approving the facility, estimating returns, or giving legal advice.

For each supplied document, extract only supported facts. Create one row per claim
with these fields:

1. Claim
2. Source document, page/section, and document date
3. Evidence type: contractual / operational / financial / legal / technical
4. Verification status: stated / corroborated / independently verified / unresolved
5. Economic relevance: repayment / collateral control / draw condition / recovery
6. Contradiction or missing dependency
7. Required human reviewer and next evidence request

Test these specific questions:
- Can the legal borrower and secured party be matched to the GPU serial-number schedule?
- What must occur before escrowed funds are released, and who can waive each condition?
- What contract produces cash flow, who can terminate it, and where do collections land?
- What proves installation, configuration, location, and continued operation after closing?
- What operational, legal, or technology event would prevent transfer, removal, or resale?
- Which recovery-time and asset-value assumptions are unsupported by a current source?

Rules:
- Never fill a missing fact from general knowledge or a marketing statement.
- Quote the exact supporting passage or say "not found."
- Separate a company's assertion from independent verification.
- Flag conflicts between documents, stale documents, and information that needs counsel,
  technical diligence, valuation, or credit-committee review.
- End with: unresolved items, owner, deadline, and whether the file is ready for human review.

Three red-team tests for the file

The prompt is useful only if it can surface a reason to slow down. Run it against controlled variations of the same evidence pack.

1. The equipment is real, but control is incomplete

Provide a valid invoice and installed-asset list, but omit an assignment notice or leave a mismatch between the borrower named in the facility and the entity holding the purchase order. A sound output should identify the break in the security chain. It should not infer that a first-priority claim exists.

2. The contract looks long-dated, but cash flow is fragile

Add an offtake agreement with broad termination rights, a customer-concentration issue, or a pricing term that can reset. The model should separate stated contract duration from dependable collections and ask for counterparty and termination analysis.

3. The recovery case assumes a frictionless resale

Give the model a residual-value estimate without a date, buyer evidence, removal plan, or downtime assumption. A useful register labels recovery as unresolved and requests a current valuation method and a realistic execution timeline.

Keep the handoff human

AI can make gaps and contradictions easier to see. It cannot authenticate a filing, perfect a security interest, inspect a server rack, value a secondary market, or approve risk. Define those boundaries before the prompt reaches a real deal team.

For a broader control framework, see AI Financial Analysis Controls: A Practical Checklist for Finance Teams. For a separate workflow focused on an institution’s credit-memo process rather than asset-backed AI infrastructure, see AI Credit Underwriting: Lessons From DBS’s 70-Agent Workflow.

Sources

#gpu-backed lending#ai infrastructure#private credit#due diligence#prompt engineering

GPU-Backed Lending: An AI Infrastructure Evidence Prompt