Structuring an SPV for a GPU-Backed Loan

A GPU-backed loan is only as good as the lender's ability to actually take the GPUs if the borrower stops paying. That sounds obvious. It is also, in practice, the part that most term sheets get wrong, because the collateral in question rarely sits in a warehouse the lender controls. It sits in a rack in someone else's data center, bolted into someone else's power and cooling infrastructure, running someone else's colocation contract. Structuring around that fact is the entire exercise.

Start with what the asset actually is. A GPU is titled personal property under Article 9 of the UCC, same bucket as a fleet of trucks or a manufacturing line. Perfecting a security interest in equipment is, in the textbook case, a filing exercise: you file a UCC-1 financing statement in the debtor's state of organization, you get your priority date, you're done. Lenders who treat H100 and H200 clusters this way are underwriting the paperwork rather than the risk. The textbook case assumes the lender can locate the collateral, inspect it, and repossess it without a third party's cooperation. None of those assumptions hold when the GPUs live inside a colocation facility or a hyperscaler's leased footprint under a services agreement the borrower doesn't own and the lender never signed.

Why the SPV exists in the first place

The special purpose vehicle exists to isolate the GPU asset from the operating company's other liabilities, so that a bankruptcy filing by the parent, or by an affiliate running the actual AI workload, doesn't drag the collateral into a consolidated estate where the lender is fighting a crowd of unsecured creditors for priority. This is the same logic that underpins aircraft finance and railcar securitization: put the depreciating, mobile, hard-to-repossess asset into a bankruptcy-remote entity, have that entity be the sole borrower, and make sure the entity has no other creditors who could file an involuntary petition against it.

The SPV should own the GPUs outright, hold the master lease or services agreement with the data center operator (or, more often, a sublease or capacity contract with an intermediate lessee who holds the master agreement with the hyperscaler), and hold nothing else. No employees, no other debt, no commingled cash. The equity in the SPV is typically pledged to the lender as a second layer of security, so that even if the Article 9 collateral gets messy in a repossession scenario, the lender can foreclose on the equity and simply own the entity that owns the chips.

That equity pledge matters more than people give it credit for. Foreclosing on equity under UCC Article 8 or Article 9 (whichever governs, depending on whether the interests are certificated) is often faster and cleaner than a physical repossession, especially when the physical asset can't easily be moved. Taking control of an LLC requires a foreclosure sale, proper notice under Section 9-611, and a subsequent UCC-1 amendment reflecting the new equity holder, rather than a moving truck. Structuring finance around GPUs without this second layer is a common and expensive mistake.

Filing correctly: the debtor's location problem

Perfection under Article 9 runs off the debtor's jurisdiction of organization, not the location of the collateral, per Section 9-307. So if the SPV is a Delaware LLC, the UCC-1 gets filed with the Delaware Secretary of State, full stop, regardless of whether the GPUs are humming away in a data center in Virginia, Texas, or somewhere in the Nordics. This trips people up because equipment finance intuition says "file where the asset is." That intuition is wrong for anything other than fixtures or as-extracted collateral, and GPUs are neither.

The description on the financing statement needs precision that goes beyond "all equipment." Serial numbers matter here in a way they rarely do for, say, office furniture, because GPUs are fungible in function but individually identifiable, and because the borrower may be swapping units in and out as hardware refreshes happen on an eighteen-to-twenty-four-month cycle. A financing statement describing "all GPUs and related equipment now or hereafter located at [data center address], together with all substitutions, replacements, and proceeds thereof" gives the lender coverage on upgrade cycles without needing to refile every time a rack gets swapped. Miss the "hereafter acquired" and "substitutions" language, and the lender's collateral pool quietly shrinks every time the borrower does a hardware refresh, which, given depreciation schedules on GPU compute, will happen faster than most equipment financings anticipate.

The part the UCC doesn't solve: the data center

Here is where GPU-backed lending diverges hardest from a standard equipment loan. Filing a UCC-1 gives the lender priority against other creditors. It does not give the lender the practical ability to walk into a Tier III or Tier IV colocation facility and pull servers out of a cage. The data center operator has its own contract with the borrower, usually with provisions about access, security clearance, and who's authorized to touch the equipment. Without addressing that contract directly, a "perfected" security interest can be worth very little in an actual default scenario.

Three documents do the work here, and skipping any of them is how lenders end up litigating access rights instead of collecting principal.

A landlord waiver or bailee letter, sometimes called an access and lien waiver in this context, needs to run from the data center operator to the lender. It should state plainly that the operator won't assert its own lien over the GPUs (many colocation agreements include a lien for unpaid fees, similar to a warehouseman's lien under Article 7), and that it will grant the lender or its agent physical access to remove the collateral upon a default notice, without requiring the borrower's separate consent. Data center operators, particularly the large hyperscale and colocation names, don't sign these easily. They view unrestricted third-party access as a security and liability exposure across a shared facility, and they're not wrong to. Negotiating this document often takes longer than negotiating the loan agreement itself, and it is the single most common point where GPU-backed financings stall.

A tri-party or step-in agreement goes further, giving the lender the contractual right to assume the borrower's position under the colocation or hosting agreement directly, stepping into the lease rather than removing the hardware at all. This matters enormously in the GPU context because physically relocating a cluster is expensive, slow, and can damage the asset's earning power. Compute that's offline during a move generates zero revenue and can fall out of whatever inference or training contracts justified the loan in the first place. A step-in right lets the lender keep the cluster running in place, under the existing power and networking commitments, while it finds a buyer or a replacement operator, which is almost always the economically superior outcome to a repossession.

Consent from any upstream landlord or master lessee closes the loop, particularly where the SPV's data center access runs through an intermediate lessee rather than a direct contract with the facility owner. If that intermediate party's own agreement can be terminated without notice to the lender, the entire access structure collapses the moment that party defaults on something unrelated to the GPU loan.

Power and networking as collateral risk

Worth stating plainly: a GPU without power, cooling, and network connectivity has a resale value that's a fraction of its operating value. Any facility contract review needs to confirm the power allocation (often specified in kilowatts per rack, a figure that has climbed sharply as GPU density has increased with each hardware generation) is contractually tied to the specific racks housing the collateral, not to the borrower's account in the aggregate, where an operator could reallocate power to another tenant's higher-priority workload during a capacity crunch.

Lenders who skip this step have, in effect, financed a depreciating asset while assuming a counterparty risk they never priced. The data center operator's own creditworthiness and operational stability become part of the credit analysis, whether the loan documents acknowledge it or not.

Step-in rights and the bankruptcy overlay

If the borrower files for bankruptcy, the automatic stay under Section 362 halts any repossession or foreclosure the moment the petition is filed, full stop, regardless of what the security agreement says. This is why the SPV's bankruptcy-remoteness provisions (independent director requirements, restrictions on voluntary filing, separateness covenants) matter as much as the Article 9 mechanics. A well-structured SPV makes it contractually and, in most circuits, practically difficult for the entity holding the GPUs to file its own petition without the lender's consent, or at minimum without triggering springing rights for the lender under the operating agreement.

Even with a clean SPV, a step-in right negotiated in advance is worth more in a stress scenario than a repossession right the lender has to litigate for. Colocation operators are far more willing to cooperate with an orderly transition, lender assumes the contract, payments continue, workload keeps running, than with a scramble to physically extract racked servers under a sheriff's writ while a bankruptcy court sorts out stay relief. An orderly transition preserves value; a physical extraction destroys it, often faster than the depreciation curve would have anyway.

What good structure actually looks like

Put together, a properly structured GPU-backed loan has four load-bearing elements working at once: a bankruptcy-remote SPV holding clean title to the hardware and nothing else, a UCC-1 filed against that SPV's state of organization with serial-number-level collateral description and forward-looking substitution language, a signed access and lien waiver from the data center operator that survives borrower default, and a step-in right letting the lender assume the hosting contract rather than relocate the asset. Absent any one of these, the lender is holding a security interest that looks sound on paper and folds the moment it's tested.

None of this is exotic law. Aircraft lessors, railcar financiers, and equipment lessors have used these tools for decades. What's new is the asset: a GPU cluster depreciates faster, generates revenue that's more contract-dependent, and sits inside a facility relationship the borrower doesn't fully control in the first place. The legal architecture has to catch up to that reality, and right now, a meaningful share of the financings getting done in this market haven't finished the job.