Insights
A Data Centre Is Not One Asset: How AI Infrastructure Is Becoming a Stack of Securitisable Cash Flows
AI-driven data-centre investment is pushing securitisation beyond a simple real-estate story. US issuance now exceeds $25 billion annually, Europe is developing quickly, and recent US regulatory guidance shows why a structure described as “ABS” in the market may not be an asset-backed security under the statutory definition. The deeper lesson is that one facility can contain several different investable rights, contracts, receivables and financing layers.
This starts a temporary private draft. It is not public, listed for sale or shared automatically.
A data centre looks like one asset from the road.
There is a site.
A building.
Power infrastructure.
Cooling.
Fibre.
Security.
Rows of equipment.
Perhaps a hyperscaler or AI cloud company occupies most of the capacity.
It is tempting to describe the financing object simply as:
Data centre
That description is becoming inadequate.
The financing market around digital infrastructure is growing quickly enough that the distinctions inside the asset now matter.
On 26 August 2026, Dentons described the United States as the most developed data-centre securitisation market globally, with annual issuance exceeding $25 billion and approximately 20 active issuers. In Europe, four public data-centre securitisations have been completed since the first public transaction in 2024, with issuance totalling approximately €2.2 billion. Dentons: Data centre securitisation explained—US, Europe and Asia
The market is also becoming structurally more interesting.
Some transactions look like commercial real-estate finance.
Others are built around platform-level contractual revenues.
Some are commonly described by market participants as ABS.
Yet on 29 July 2026, the staff of the US Securities and Exchange Commission’s Division of Corporation Finance agreed, based on a specific set of facts and representations submitted by Latham & Watkins, that securities issued in the described data-centre securitisations were not asset-backed securities under Section 3(a)(79) of the Exchange Act. SEC: Latham & Watkins LLP—Certain Data Center Securitizations
Reuters highlighted the clarification on 10 August as a development that could make financing easier as AI-related capital requirements push data-centre owners deeper into the securities markets. Reuters: US SEC exempts certain data center bonds from key securitization rules
This apparent contradiction is the interesting part.
A financing can look like securitisation.
It can be called securitisation.
It can isolate assets inside a special-purpose structure.
It can issue fixed-income securities.
It can use customer revenue to pay investors.
And the legal classification may still depend on what the securitised assets actually are and how the cash is generated.
That is a very useful lesson for any market trying to turn complex real-world assets into investable financial objects.
Before asking how an asset should be financed, traded or tokenised, identify what the investor actually has recourse to and what produces the cash.
A data centre is a particularly good place to see why.
The financing market is no longer only about the building
Traditional real-estate finance starts with a familiar concept.
A borrower owns property.
A lender makes a mortgage loan.
The property secures the loan.
Rental income supports debt service.
If the borrower defaults, the lender may enforce against the property.
Data-centre finance can still work this way.
But modern facilities are unusually operational.
A conventional warehouse can remain useful even if the tenant changes.
A data centre depends on an operating system made from physical and contractual components:
- access to land;
- grid connection;
- electricity supply;
- backup generation;
- transformers and switchgear;
- cooling infrastructure;
- water where relevant;
- fibre connectivity;
- security;
- technical operations;
- permits;
- customer contracts;
- service-level commitments;
- capacity allocation;
- equipment;
- software and monitoring;
- maintenance contracts; and
- the operator’s ability to keep the facility functioning.
The customer may not simply pay “rent”.
Revenue can contain several components.
Dentons’ August 2026 analysis of data-centre ABS structures identifies eligible contractual revenue streams that can include:
- lease or licence payments under occupancy agreements;
- power charges;
- cooling charges;
- connectivity fees;
- maintenance and other service fees;
- reimbursement receivables for capital upgrades or customer-specific fit-outs;
- equipment leasing;
- managed infrastructure charges; and
- subject to eligibility criteria, subscription or usage-based revenue such as GPU-as-a-service or cloud-related services.
Dentons: Data centre securitisation explained—ABS structures
That means one physical facility can generate several legally and economically different payment rights.
The financing object is no longer obvious from a photograph of the building.
The same facility can support very different securities
Consider one stabilised data centre.
It may support a mortgage-backed structure.
It may also sit inside a broader platform financing built around operating revenues.
Those are not merely two labels for the same transaction.
They can represent very different chains of rights.
A simplified commercial mortgage-backed structure may look like:
Data-centre property
->
Mortgage loan
->
Loan principal and interest
->
CMBS issuer
->
Investor security
A platform-level structure may look more like:
Data-centre facilities
+
Customer contracts
+
Operating infrastructure
->
Contractual revenue
-
Operating expenses
->
Net operating cash flow
->
Issuer / master-trust structure
->
Investor security
Those arrows matter.
In the first structure, the securitised financial asset may be the mortgage loan.
In the second, the investor may be exposed much more directly to the continuing operation of the data-centre platform.
The facility is the same.
The asset being financed is not.
CMBS securitises the mortgage loan—not the server hall
Dentons describes data-centre CMBS as typically involving a single-asset, single-borrower mortgage loan secured over a stabilised, income-producing data-centre property.
The primary receivables supporting the securitisation are the principal and interest payments under the mortgage loan.
Customer lease cash flows matter because they support the borrower’s ability to pay.
But the underlying tenant contracts are not necessarily transferred to the CMBS investor.
Dentons: Data centre securitisation explained—CMBS structures
That distinction can be expressed simply:
Customer pays operator
->
Operator services mortgage loan
->
Mortgage loan pays CMBS issuer
->
CMBS issuer pays investors
The investor’s financial asset is not the electricity system.
It is not the tenant’s server rack.
It is not necessarily the tenant contract.
The securitised asset is the mortgage loan, supported by collateral and by the economics of the property underneath it.
That makes familiar real-estate questions central:
- appraised value;
- loan-to-value;
- mortgage enforceability;
- lease term;
- tenant concentration;
- tenant credit quality;
- debt-service coverage;
- property condition;
- replacement cost;
- reletting risk; and
- enforcement value.
This remains recognisable commercial real-estate finance.
Platform securitisation is closer to financing an operating system
The platform structure is more unusual.
The July 2026 Latham & Watkins request to the SEC described a typical data-centre securitisation in which a special-purpose issuer owns, leases or otherwise has rights to asset entities holding one or more data centres, their physical components and the contracts needed to operate them.
The described securitised assets could therefore include:
- buildings;
- data halls;
- electrical systems;
- backup power;
- network infrastructure;
- service contracts;
- leases;
- colocation agreements;
- insurance policies; and
- related operating assets.
Latham & Watkins: Request for Interpretive Guidance Regarding Certain Data Center Securitizations
The structure is not static.
Latham described master trusts allowing future securities issuance, refinancing, additions of data centres, dispositions and, in some circumstances, substitution of assets.
The issuer services the securities using net cash flow generated from the operations of the asset entities.
That cash is influenced not only by what customers are contractually required to pay.
It is also influenced by what it costs to keep the platform running.
That is a different credit object from a portfolio of ordinary receivables.
Why the SEC staff said the described securities were not Exchange Act ABS
The SEC staff response is important partly because it forces the market to ask what an “asset-backed” security is actually backed by.
Section 3(a)(79) of the Exchange Act refers to securities collateralised by self-liquidating financial assets whose holders receive payments that depend primarily on cash flow from those assets.
Latham’s argument was that the data-centre structures it described did not fit that concept.
The physical data-centre assets do not self-liquidate.
A building, electrical system or cooling plant does not convert itself into cash and disappear as investors are repaid.
The facility can remain in operation after the securities have been repaid.
It may even appreciate or support new financing later.
Customer contracts generate revenue, but the cash available to investors also depends on significant operating expenses such as:
- electricity;
- taxes;
- insurance;
- repairs;
- maintenance;
- security;
- staffing;
- equipment;
- and other operating costs.
The manager or operator therefore matters.
Revenue can rise.
Expenses can rise.
Contracts can be renewed.
Customers can be replaced.
New facilities can be added.
Assets can be sold.
The operating business continues.
On the facts presented, the SEC staff agreed with Latham’s conclusion that the described fixed-income or other securities were not Exchange Act ABS.
That should not be translated into:
“Data-centre securities are not ABS.”
The staff response expressly states that it is based on the facts and representations presented.
It is not a Commission rule.
It does not amend the law.
Different structures or facts may produce a different analysis.
That limitation is not a footnote to the story.
It is the story.
Market terminology and legal classification are different data fields
Structured-finance markets use practical labels.
A transaction may be marketed as:
- data-centre ABS;
- CMBS;
- infrastructure debt;
- project finance;
- private credit;
- whole-business securitisation;
- operating-asset securitisation;
- equipment finance;
- lease finance; or
- another familiar category.
Those labels help investors understand broad economics.
They should not replace the legal analysis of the instrument.
A useful asset record should therefore avoid one field such as:
Structure: ABS
without context.
It may need separate fields for:
Market label: Data-centre ABS
Legal classification: [jurisdiction-specific analysis]
Issuer: [identified entity]
Investor security: [identified instrument]
Collateral / recourse: [identified assets and rights]
Primary payment source: [identified cash-flow source]
Regulatory basis: [source and date]
The distinction is particularly important when a transaction crosses jurisdictions.
A structure accepted as one type of instrument under one country’s securities law may not map neatly into another country’s regulatory taxonomy.
A global asset platform should preserve that difference rather than normalise it away.
One data centre can contain several different economic objects
Suppose a large AI-focused data centre is operating under a mixture of occupancy, service and equipment arrangements.
The economic stack may include:
- land ownership or a long lease;
- the physical building;
- grid connection rights;
- electrical infrastructure;
- cooling infrastructure;
- fibre connections;
- customer occupancy agreements;
- licences;
- service agreements;
- power reimbursement rights;
- connectivity charges;
- maintenance charges;
- fit-out reimbursements;
- equipment leases;
- GPU or managed-compute contracts;
- current trade receivables;
- future contracted revenue;
- a mortgage loan;
- equipment financing;
- a private-credit facility;
- security interests over assets or accounts;
- cash reserves;
- equity in asset-owning entities;
- notes issued by a securitisation vehicle; and
- residual equity after debt service.
All of those can be economically connected.
They are not the same asset.
A lender financing equipment may care primarily about:
- equipment ownership;
- serial-number identity;
- depreciation;
- maintenance;
- location;
- insurance;
- remarketing value; and
- security perfection.
A mortgage lender may care primarily about:
- real estate;
- lease income;
- appraised value;
- title;
- priority;
- permitted use;
- construction quality; and
- foreclosure rights.
A platform securitisation investor may care more about:
- customer contracts;
- recurring operating revenue;
- operating expenses;
- concentration;
- churn;
- renewal;
- service performance;
- additions and substitutions to the collateral pool; and
- the operator’s ability to keep the facilities running.
Calling all three exposures data-centre debt is commercially understandable.
It is not sufficient for diligence.
Contracted revenue is not the same thing as a receivable
This distinction becomes especially important in fast-growing infrastructure markets.
A five-year customer contract may create an expectation of future revenue.
That does not mean five years of receivables already exist today.
Future payments may depend on:
- capacity becoming available;
- the customer continuing to occupy the facility;
- usage;
- power consumption;
- service performance;
- contract conditions;
- minimum commitments;
- price escalators;
- renewals;
- credits;
- termination rights;
- force majeure;
- service-level failures;
- disputes;
- or other contractual conditions.
A current invoice is another object.
A currently due receivable is another again.
A structured record should therefore distinguish:
Contracted future revenue
!=
Accrued revenue
!=
Invoiced amount
!=
Current receivable
!=
Cash collected
Those states can coexist.
They answer different questions.
The distinction becomes even more important where usage-based AI infrastructure is involved.
A contract may establish access to computing capacity while actual monthly revenue depends on consumption.
The contract can be valuable without creating a fixed receivable for every future period.
Power is both infrastructure and cash-flow risk
Data centres are unusual because electricity is not simply a utility expense sitting at the edge of the asset.
Power can influence almost every layer of value.
The facility may have:
- a contracted grid connection;
- a maximum available capacity;
- staged energisation;
- backup generation;
- renewable power arrangements;
- power-purchase agreements;
- pass-through arrangements with customers;
- hedging;
- minimum consumption commitments;
- peak-demand charges;
- or other electricity-related economics.
A customer contract may separate:
Occupancy charge
+
Power usage
+
Cooling
+
Connectivity
+
Other services
That creates several questions for a financier.
Is power billed as a pass-through?
Is there margin on it?
Can the operator increase customer pricing if electricity costs rise?
Does a power interruption trigger credits?
Can insufficient grid capacity delay new contracted revenue?
Does the financing model assume capacity that is not yet energised?
Can power rights be transferred with the property in enforcement?
A data-centre asset record that stores only:
Annual rent
can miss a material part of the credit.
Operating performance becomes part of investor credit risk
A portfolio of ordinary receivables can often be analysed by examining the obligors and their payment obligations.
A data-centre platform requires another layer.
The operator must continue to perform.
The Latham submission emphasised that net cash available for investors depends partly on the operator’s ability to generate revenue and manage operating expenses.
That means servicing is not only:
Send invoice
Collect cash
Distribute cash
It may include:
- keeping facilities operational;
- maintaining cooling;
- maintaining power resilience;
- monitoring capacity;
- responding to incidents;
- managing customer contracts;
- negotiating renewals;
- procuring new customers;
- operating billing;
- managing delinquency;
- maintaining insurance;
- managing capital expenditure;
- and complying with permits and legal requirements.
The operating company can therefore be part of the credit story even where the financing structure isolates assets from the operator’s wider corporate activities.
This is a useful reminder for asset-backed finance more generally.
Cash-flow ownership and cash-flow production are not the same thing.
A structure may have strong legal rights to revenue.
It still needs the operating system that produces that revenue to function.
Dynamic pools require stronger asset identity
Traditional securitisations are often imagined as a fixed pool.
The assets are selected.
They enter the vehicle.
Investors receive cash as the pool runs down.
Data-centre master-trust structures can be more dynamic.
Facilities may be:
- added;
- removed;
- substituted;
- refinanced;
- expanded;
- partially released;
- or placed into new asset entities.
New securities may be issued against the structure.
Customer contracts can also change.
New tenants arrive.
Existing customers expand.
Another customer leaves.
A five-year contract becomes a renewed seven-year relationship.
One facility receives a new power allocation.
Another undergoes an expansion.
That means the investor needs more than a closing-date asset list.
The system needs an as-of-time view.
For each material asset or contract, a reviewer may need to know:
- when it entered the financed pool;
- why it was eligible;
- which valuation supported inclusion;
- which contracts were linked to it;
- what changed afterward;
- whether it remains eligible;
- whether it has been released;
- whether another financing now has rights over it; and
- which investor reporting period reflects the change.
A dynamic collateral pool without durable asset identity becomes difficult to audit.
The customer contract is a credit asset with operational clauses
A hyperscale or colocation agreement can look stable because the customer is large and the term is long.
The headline contract value is not enough.
A credit investor may need to understand:
- legal customer entity;
- guarantor;
- contracted capacity;
- facility;
- data hall;
- commencement date;
- expiry;
- extension options;
- termination rights;
- pricing;
- indexation;
- minimum commitments;
- power treatment;
- fit-out obligations;
- service-level agreements;
- credits;
- outages;
- insurance;
- assignment;
- change-of-control provisions;
- confidentiality;
- security requirements;
- cross-defaults;
- and governing law.
A single customer may have several agreements.
An amendment may change only one site.
A new order form may add capacity.
A service schedule may alter performance obligations.
A side letter may change pricing.
The financing record therefore needs contractual provenance.
The question is not merely:
Does a customer contract exist?
It is:
Which current contractual documents create the revenue used in the financing model?
AI infrastructure introduces a faster technology cycle
The AI boom makes the financing opportunity larger.
It also makes some parts of the asset less conventional.
Dentons noted in August 2026 that AI-focused data centres serving specialist AI cloud operators can have risk profiles that diverge from traditional infrastructure.
These may include:
- shorter customer contracts, sometimes around two to five years;
- sub-investment-grade or venture-backed counterparties;
- usage-based revenue;
- rapidly changing technology;
- specialised liquid-cooling infrastructure;
- expensive customer-specific configurations; and
- GPU hardware with relatively short economic lives.
That changes the residual-value question.
A building may have a useful life measured in decades.
The GPUs inside it may become commercially obsolete much faster.
The cooling system may have been designed for a particular generation of hardware.
A customised data hall may be expensive to convert.
The customer may have a shorter financial history than the facility.
A five-year security backed by a twenty-year physical asset can therefore contain technology components whose economic lives are shorter than the debt.
The phrase infrastructure asset can hide this mismatch.
Asset life should be recorded by component
A data-centre financing model should not assume one useful life.
The components may have very different durations:
Land / site rights
-> potentially decades
Building
-> decades
Grid connection
-> long-lived but capacity-constrained
Electrical and cooling systems
-> long-lived with periodic capex
Customer contract
-> years
AI hardware
-> potentially much shorter economic life
Current receivable
-> days or months
Investor security
-> defined tenor
Those durations interact.
A data-centre Asset Passport should therefore allow lifecycle information to attach to the right object.
A replacement of GPUs should not overwrite the building’s identity.
A contract renewal should not look like a new physical facility.
A refinancing should not imply the asset itself was sold.
A customer payment should extinguish a receivable without extinguishing the customer relationship.
The structure becomes much clearer when each layer has its own lifecycle.
A Data Centre Asset Passport should preserve the stack
For DaDepo, the useful response is not to create a single record with:
Asset type: Data centre
Value: $1.2 billion
Status: Active
That may be a useful cover page.
It is not an adequate financing record.
A more useful Asset Passport would preserve the main layers and their relationships.
Physical facility
- facility identifier;
- address and jurisdiction;
- owner;
- operator;
- site area;
- gross and usable capacity;
- data halls;
- construction date;
- expansion phases;
- physical condition;
- major equipment;
- replacement programme;
- insurance;
- permits;
- and source documents.
Site and infrastructure rights
- land title or lease;
- easements;
- grid connection;
- energised capacity;
- planned additional capacity;
- power-supply arrangements;
- backup power;
- water rights where relevant;
- fibre connections;
- access rights;
- environmental constraints;
- and transfer restrictions.
Customer relationships
- customer legal entity;
- guarantor;
- contract type;
- facility;
- contracted capacity;
- commencement;
- expiry;
- renewal;
- termination;
- pricing;
- minimum commitment;
- service-level terms;
- assignment rights;
- change-of-control rights;
- and relevant amendments.
Revenue and receivables
- revenue component;
- invoice;
- debtor;
- billing period;
- amount;
- currency;
- due date;
- current outstanding amount;
- credit;
- dispute;
- payment status;
- collection history;
- and link to the governing contract.
Operating expenses
- electricity;
- cooling;
- maintenance;
- taxes;
- insurance;
- staffing;
- security;
- network costs;
- equipment leases;
- other material operating costs;
- allocation methodology;
- and as-of date.
Financing
- borrower;
- lender;
- principal;
- interest;
- maturity;
- loan-to-value;
- covenants;
- security package;
- guarantees;
- reserve accounts;
- cash-management arrangements;
- default status;
- and amendments.
Securitisation layer
- issuer;
- SPV or master trust;
- asset entities;
- investor securities;
- series or tranche;
- collateral;
- recourse;
- payment waterfall;
- eligibility criteria;
- addition and substitution rules;
- release mechanics;
- servicing;
- reporting period;
- legal classification;
- and supporting legal analysis.
Provenance
- source document;
- source system;
- extracted field;
- user-confirmed field;
- externally confirmed field;
- reviewer;
- review status;
- version;
- effective date;
- superseded document;
- and last updated time.
This does not turn the data centre into one standardised financial product.
It does the opposite.
It makes the different assets visible.
Receivable identity becomes harder when billing is multi-component
A normal invoice may already require careful identity.
Data-centre billing can add another complication.
One invoice may combine:
Base occupancy
+
Power
+
Cooling
+
Connectivity
+
Managed services
+
Equipment
+
One-off fit-out reimbursement
-
Service-level credit
If a financing structure is supported only by certain eligible receivables, the system needs to know which components qualify.
A headline invoice total may not be enough.
Suppose an invoice is $4 million.
Perhaps:
- $2.2 million is eligible contracted occupancy revenue;
- $1.1 million is power reimbursement;
- $400,000 is equipment rental;
- $350,000 is a one-off installation charge;
- and a $50,000 service credit reduces the amount payable.
If the financing documents define eligibility differently for those components, one invoice can contain several asset classifications.
That makes field-level provenance commercially useful.
The investor should be able to understand how the securitisation tape got from the invoice to the eligible balance.
Ownership and security should be explicit
Complex infrastructure finance can contain multiple ownership layers.
A sponsor may own the group.
An issuer may own an asset entity.
The asset entity may own the building.
Equipment may be leased.
A customer may own servers inside the facility.
A separate lender may have security over equipment.
A mortgage lender may have security over the property.
A securitisation may have rights over accounts, contracts, equity interests or other collateral.
Those interests should not be collapsed into:
Owner: SPV
A structured record may instead need to distinguish:
- legal owner of land;
- legal owner of building;
- owner of electrical infrastructure;
- owner of computing equipment;
- lessee;
- customer-owned property;
- borrower;
- security provider;
- secured creditor;
- account bank;
- issuer;
- noteholder rights;
- and enforcement agent or trustee.
This is especially important in distress.
Normal-operation economics can make ownership distinctions look academic.
Default makes them operational.
Enforcement asks a different question from origination
At origination, the financing story may be:
High-quality facility
+
Contracted revenue
+
Growing AI demand
+
Strong utilisation
=
Predictable cash flow
At enforcement, the questions become more granular.
Who owns the site?
Can the secured party enforce against the asset entity?
Can customer contracts be assigned?
Do customers have termination rights on insolvency or change of control?
Can licences and permits transfer?
Does the grid connection remain with the facility?
Who owns the equipment?
Can a replacement operator take over?
Are cash accounts controlled?
Which liabilities remain with the asset entity?
Would a hyperscale customer stay after enforcement?
How much capital expenditure is required to keep the facility competitive?
The value of the asset under normal operation and the value of the enforcement package may be very different.
That is why the Asset Passport should preserve both operational and legal structure.
Valuation needs an object
A data centre can generate many legitimate values.
There may be:
- land value;
- property value;
- replacement cost;
- enterprise value;
- asset-entity equity value;
- mortgage collateral value;
- contracted-revenue value;
- current receivable balance;
- equipment value;
- GPU residual value;
- loan balance;
- securitisation collateral value;
- note price;
- recovery value;
- and sponsor equity value.
These numbers should never be stored as though they were competing estimates of one generic field called Value.
A $1 billion property valuation does not mean the customer contracts are worth $1 billion.
A $600 million note issuance does not mean the facility is worth $600 million.
A $200 million annual revenue run rate does not mean $200 million of receivables exist.
A $50 million equipment valuation does not mean the lender can realise $50 million in enforcement.
The record should identify:
- valuation object;
- method;
- date;
- currency;
- valuer;
- assumptions;
- scenario;
- source;
- and relationship to the financing.
A sophisticated asset class needs sophisticated value identity.
Servicing should include operational events
Receivables servicing normally focuses on collection.
Data-centre finance needs a wider event model.
Material lifecycle events can include:
- facility construction completed;
- grid connection achieved;
- additional capacity energised;
- customer contract signed;
- customer goes live;
- capacity increased;
- pricing amended;
- SLA breach;
- service credit issued;
- outage;
- insurance claim;
- customer downgrade;
- customer default;
- contract renewal;
- contract termination;
- new equipment installed;
- major equipment replaced;
- facility added to securitisation pool;
- facility removed from pool;
- debt refinanced;
- covenant breached;
- reserve drawn;
- payment made;
- enforcement initiated;
- operator replaced; or
- asset sold.
These are not just notes.
They can change the credit.
A system designed for static documents may miss that.
A lifecycle system can preserve it.
AI can organise the infrastructure file—but it should not underwrite the facility
Data-centre financing is extremely document-heavy.
AI-assisted preparation can be useful.
AI can help identify and extract:
- facility names;
- addresses;
- asset entities;
- customer names;
- guarantors;
- contract dates;
- expiry dates;
- renewal options;
- capacity;
- power commitments;
- pricing terms;
- indexation;
- service-level metrics;
- termination clauses;
- assignment provisions;
- invoices;
- payment dates;
- amendments;
- equipment schedules;
- insurance policies;
- loan terms;
- security documents;
- reserve requirements;
- and reporting obligations.
Across a larger portfolio, AI can also flag:
- two different expiry dates for the same contract;
- a customer name that does not match the guarantor record;
- capacity that exceeds the facility’s recorded energised capacity;
- an invoice unsupported by the expected contract;
- a missing amendment;
- a pricing schedule inconsistent with current billing;
- an asset shown in two financing pools;
- a contract marked active after a termination notice;
- a receivable already paid but still shown as outstanding;
- or a facility included in investor reporting without an obvious eligibility record.
That is useful preparation.
It is not authoritative underwriting.
AI should not independently determine:
- whether a contract is enforceable;
- whether revenue qualifies under securitisation eligibility criteria;
- whether security is perfected;
- whether a grid right transfers on enforcement;
- whether a customer will renew;
- whether a neocloud counterparty is creditworthy;
- whether the facility will remain technologically competitive;
- whether equipment is correctly valued;
- whether a data centre is suitable collateral;
- whether a transaction is legally an ABS, CMBS or another regulated instrument;
- what recovery will be in distress; or
- whether an investor should purchase the security.
The documents can be organised.
The legal, technical and investment judgement remains human.
What DaDepo can contribute
DaDepo does not need to become a data-centre lender or a structured-finance arranger for this asset class to be relevant.
The opportunity is upstream.
Data-centre financings connect several kinds of information that are often maintained in separate systems:
- property records;
- technical schedules;
- customer contracts;
- billing;
- receivables;
- equipment;
- operating costs;
- financing documents;
- security;
- investor reporting;
- and lifecycle events.
A new lender or investor has to reconstruct the relationships.
DaDepo can help users create an Asset Passport that connects those layers without pretending they are one asset.
The useful object might be:
Facility
->
Asset entity
->
Customer contract
->
Revenue component
->
Invoice / receivable
->
Cash collection
->
Financing
->
Security / collateral pool
->
Investor instrument
Each arrow should be supported by evidence.
That creates a cleaner foundation for:
- private-credit diligence;
- infrastructure finance;
- refinancing;
- CMBS review;
- platform securitisation;
- portfolio monitoring;
- servicing;
- collateral reporting;
- investor reporting;
- asset sale;
- enforcement;
- and future secondary-market workflows.
The Asset Passport does not make the facility financeable.
It makes the financing object easier to define.
What DaDepo does—and does not do
Creating or reviewing a data-centre or infrastructure Asset Passport does not mean that DaDepo has:
- authenticated every property, contract, invoice or technical document;
- verified land title;
- confirmed grid capacity or future energisation;
- inspected the physical facility;
- verified equipment ownership;
- assessed engineering condition;
- confirmed customer performance;
- established contract enforceability;
- determined assignment rights;
- perfected or ranked security interests;
- confirmed collateral eligibility;
- determined the regulatory classification of a security;
- valued the property, equipment, contracts, receivables or securities;
- assessed borrower or customer creditworthiness;
- predicted occupancy, utilisation or renewal;
- provided a loan;
- arranged private credit;
- originated a mortgage;
- issued CMBS or ABS;
- operated a securitisation vehicle;
- serviced investor securities;
- operated a data centre;
- guaranteed uptime;
- guaranteed repayment or recovery;
- recommended an investment; or
- provided legal, regulatory, engineering, tax, accounting, investment, credit-rating, underwriting or valuation advice.
Important: DaDepo provides technology and information tools. It does not provide legal, financial, investment, tax, accounting, engineering, infrastructure-operating, banking, lending, securitisation, custody, settlement, credit-rating, underwriting or valuation advice or services unless a specific service is expressly identified and lawfully provided. Data-centre financing structures, security rights and regulatory classifications vary by jurisdiction, transaction and facts. Users should review the underlying evidence and obtain appropriate professional advice.
A practical data-centre financing checklist
Before a data-centre asset, contractual cash flow or financing structure is presented to a lender or investor, ask:
- Facility: Which exact physical facility or portfolio is in scope?
- Ownership: Which entity legally owns the land, building and major infrastructure?
- Operator: Which entity operates the facility and under what agreement?
- Power: What capacity is contracted, connected, energised and actually available?
- Customers: Which legal entities are responsible for the contracted revenue?
- Contracts: Which current agreements, schedules and amendments create the customer obligations?
- Capacity: What capacity has each customer contracted and what is currently live?
- Revenue: Which amounts are occupancy, power, cooling, connectivity, equipment, managed service or other revenue?
- Receivables: Which amounts are currently invoiced and outstanding rather than merely expected future revenue?
- Adjustments: Are service credits, disputes, rebates and amendments reflected?
- Operating costs: Which material costs must be paid before cash is available for debt service?
- Equipment: Who owns material computing, electrical and cooling equipment, and what is its useful economic life?
- Financing: Which mortgage, equipment, construction, project-finance or private-credit facilities are outstanding?
- Security: Which assets, equity interests, accounts, contracts or receivables secure each financing?
- Priority: Do different lenders or investors have competing rights?
- Pool eligibility: If a securitisation pool is dynamic, why is each asset or receivable eligible as of the relevant reporting date?
- Transferability: Can the relevant contracts, rights, permits and collateral transfer or survive enforcement?
- Classification: What is the market label of the transaction, and what legal or regulatory classification applies in the relevant jurisdiction?
- Lifecycle: Are additions, releases, substitutions, refinancings, outages, renewals and other material events recorded?
- Provenance: Can every material field in the financing model be traced to the correct document, system, party and version?
If the answer to “what exactly supports the investor’s payment?” is unclear, the structure is not ready to become more complicated.
AI infrastructure is turning one building into several financeable asset classes
The most interesting development in data-centre finance is not simply that AI requires more buildings.
It is that the financing market is separating the economic layers inside those buildings.
One investor can finance:
- the real estate;
- a mortgage loan;
- construction;
- equipment;
- contracted occupancy;
- service receivables;
- operating cash flow;
- a portfolio platform;
- or securities issued against a broader financing structure.
Those exposures may all ultimately depend on the same facility.
They do not represent the same asset.
The SEC staff response in July 2026 makes that distinction unusually visible.
A transaction may use securitisation techniques without fitting a particular statutory definition of an asset-backed security.
A market may use the label ABS while legal analysis asks a more precise question.
A customer contract may support valuation without yet being a receivable.
A physical facility may support investor payments without self-liquidating.
An operator may not own the investor security while still being essential to the cash flow that services it.
AI infrastructure therefore illustrates a broader rule for document-backed finance:
The more sophisticated the financing becomes, the less useful it is to treat the underlying asset as one thing.
The future market infrastructure for private assets will need to preserve the stack:
Physical asset
+
Legal rights
+
Contracts
+
Receivables
+
Operations
+
Security interests
+
Financing
+
Investor instruments
+
Lifecycle
+
Provenance
A data centre may look like one building.
Financially, it can be many assets at once.
Further reading
- Dentons: Data centre securitisation explained—how the US, Europe and Asia are funding digital infrastructure
- Dentons: Data centre securitisation explained—understanding CMBS structures
- Dentons: Data centre securitisation explained—ABS and what they mean for Australia
- SEC Division of Corporation Finance: Latham & Watkins LLP—Certain Data Center Securitizations
- Latham & Watkins: Request for Interpretive Guidance Regarding Certain Data Center Securitizations
- Reuters: US SEC exempts certain data center bonds from key securitization rules
- Dentons: From construction to capital markets—private credit, securitisation and the future of data centre funding