One Property, Two Lenders: Why Collateral Needs an Identity, Not Just Documents

he collapse of UK mortgage lender Market Financial Solutions has put an old secured-lending problem under a modern spotlight: documents can describe collateral without proving that the same economic asset has not already been pledged elsewhere. Allegations of double pledging, disputes over mortgage registration and a new Solicitors Regulation Authority investigation into work connected with MFS show why loan identity, collateral identity, security registration, priority and professional attestat

One Property, Two Lenders: Why Collateral Needs an Identity, Not Just Documents
Create a structured secured-loan record

This starts a temporary private draft. It is not public, listed for sale or shared automatically.

A secured-lending package links a loan, a security document and a property to an expected recovery route. Each link needs evidence: the loan may have been assigned, the property may support another facility, the mortgage may be unregistered or unperfected, and a corporate group may have overlapping financing. A lender may hold a participation rather than direct title, while a professional certificate may cover document execution without confirming every economic representation. The same collateral can also appear in more than one financing package. The 2026 collapse of UK mortgage lender Market Financial Solutions Limited, or MFS, has brought these distinctions into unusually sharp focus.

MFS entered administration on 25 February 2026. The Financial Conduct Authority confirmed on 20 March that it had opened an enforcement investigation. The FCA also clarified that MFS was registered with it as an Annex 1 business for anti-money-laundering supervision and was not otherwise FCA-authorised. FCA: Investigation into Market Financial Solutions Limited The administration itself is recorded at Companies House and in the London Gazette. Companies House: Market Financial Solutions Limited insolvency The Gazette: Market Financial Solutions Limited—Appointment of Administrators What happened before the administration is the subject of continuing litigation, insolvency work and regulatory investigation.

Creditors have alleged that MFS used the same collateral or mortgage assets to support multiple financing arrangements—a practice commonly described as double pledging. Bloomberg reported in February that creditors alleged a potential £930 million collateral shortfall against approximately £1.2 billion of relevant debts. Bloomberg: MFS Creditors Warn of £930 Million Shortfall in Collateral Reuters subsequently described the collapse as raising wider questions about asset-backed and private-credit due diligence. Reuters: Wall Street hit by UK mortgage lender collapse, raising fears of more credit 'cockroaches'

In June, court filings reported by Bloomberg indicated that a roughly £300 million portfolio of mortgages linked to Twinwin appeared not to have been registered in public property records, potentially complicating attempts to establish creditor rights and priority. The Edge: Collapsed lender MFS said to have never registered £300m of mortgages

Then on 28 August, the Financial Times reported that the Solicitors Regulation Authority was investigating law firm Gunnercooke over work involving companies linked to MFS, including Twinwin. According to the report, insolvency practitioners have made allegations concerning certified debt documentation and the use of Twinwin in the wider MFS structure. Gunnercooke denies wrongdoing and has said, among other things, that certain documents may have been fraudulently reproduced without its involvement. Paresh Raja, MFS’s founder, has denied wrongdoing. Financial Times: Watchdog probes law firm over work linked to collapsed lender MFS These are allegations and investigations, not findings that this article can resolve. But they expose a very important infrastructure question:

How does a lender know that this exact economic asset, this exact security interest and this exact priority position have not already been represented somewhere else?

A folder of documents is not enough to answer that. The specialist records and lifecycle models below describe review requirements and illustrations. They should not be read as claims that software has verified the rights or that every proposed field and relationship is an existing DaDepo feature.

Distinguish the loan, property, security and priority position

The first distinction is basic. A mortgage deed is a document. The property is an asset. The mortgage or charge is a legal right over that asset. The loan is the obligation being secured. The lender’s position may therefore be represented as:

Illustrative sequence: Borrower obligation to Priority
  1. Borrower obligation
  2. Loan agreement
  3. Security agreement / mortgage
  4. Specific property
  5. Registration / perfection
  6. Priority

Those are related objects. They are not interchangeable. A PDF called Mortgage.pdf does not prove by itself that: the property exists; the chargor owns it; the document was validly executed; the mortgage was registered; the lender has first priority; no earlier charge exists; the security has not been released; the secured debt remains outstanding; or another lender has not been shown a different document describing the same collateral. The document provides evidence; the secured position remains a legal and economic state. A lender may receive a report saying: “Security: First legal charge”. That sounds precise. It is incomplete without context. First charge over what? Registered where? In favour of whom? Securing which debt?

Created on what date? Registered on what date? Was any prior charge discharged? Has a later intercreditor agreement changed enforcement priority? Has the loan been assigned? Has the security agent changed? Has the property been sold? Has the charge been released? Priority is not a permanent adjective attached to a PDF. It is a state produced by documents, registration, law and later events. A useful record should say more like:

Illustrative record field Description or value
Property [stable property identity]
Security type Legal charge / mortgage
Chargor [legal entity]
Secured party [legal entity / security trustee]
Underlying facility [stable loan identity]
Creation date [date]
Registration reference [reference]
Registration date [date]
Priority basis [source]
Intercreditor arrangement [if any]
Release status Active / Part released / Released
As-of date [date]

Now the statement can be tested. Double pledging is often described as fraud risk. It can be. But from an infrastructure perspective, it is also an identity problem. Suppose a borrower has one property: “17 Example Street”. Lender A receives Loan A, Security package A, Property valuation A and Mortgage document A. Lender B receives Loan B, Security package B, Property valuation B and Mortgage document B. If both financing systems assign their own internal collateral IDs, each lender may see a unique record. Lender A may use collateral ID COL-8871 while Lender B uses PROP-22419. The identifiers are unique even though the economic collateral is the same. This is the same problem that appears in receivables finance.

Two files can be different while the underlying asset is the same. A hash, database primary key or blockchain token cannot establish economic uniqueness by itself. The system needs economic asset identity.

Keep property identity and registration events traceable

One property can be described in many ways. A financing file may contain postal address, title number, land registry reference, lot number, cadastral reference, local authority identifier, valuation report address, borrower’s internal property code, lender collateral ID, solicitor matter number, security document description, insurance address, and SPV schedule reference. They may not match textually. For example: 17-19 High Street, London; 17 High St; Units 1-4, 17 High Street; Title ABC123456; and Property 07 in Facility Schedule. These can all refer to the same economic asset. A collateral platform should link identifiers rather than choose one filename as truth. The same principle applies to mortgage loans.

One loan may have lender loan number, broker reference, borrower reference, facility agreement ID, servicing ID, warehouse ID, securitisation ID, and investor tape ID. A durable identity layer connects them. A property can secure more than one loan lawfully. That fact is important. The existence of two lenders does not automatically mean something is wrong. There may be first mortgage and second mortgage, senior and mezzanine facilities, pari passu lenders, syndicated lending, intercreditor agreements, security trustees, shared collateral pools, cross-collateralisation, revolving facilities, refinancings, bridge-to-term structures, or permitted additional debt. The problem is not simply: “Two loans -> One property”. The problem is when the rights and priorities are unclear, inconsistent or misrepresented.

That means the data model should permit: Property P1 supporting two separate chains: Security S1, Loan L1 and Lender A; and Security S2, Loan L2 and Lender B and then record the legal relationship between S1 and S2. For example:

Illustrative record field Description or value
S1 priority First
S2 priority Second
Intercreditor agreement Present

or S1 and S2 could rank pari passu under Security Trustee X. A system that assumes one property can have only one financing relationship will fail on legitimate structures. A system that permits unlimited relationships without priority provenance will fail on risk control. Secured lending often reduces registration to “Registered: Yes”. That is not enough. Registration has a lifecycle. A charge may be created, submitted, rejected, corrected, registered, amended, assigned, partially released, fully released, or discharged. The relevant registry may differ depending on asset and jurisdiction. A UK property transaction can involve Land Registry records and company-charge filings, while other jurisdictions have different perfection and priority systems. The key design principle is universal:

registration should be represented as an attributable external event. A robust record can preserve:

Illustrative record field Description or value
Registry [identified registry]
Registration reference [reference]
Submitted by [party]
Submission date [date]
Registered date [date]
Registered secured party [entity]
Asset reference [registry asset ID]
Status [current status]
Source retrieved [date]
Evidence [document / API / registry extract]

This turns “registered” from a claim into a traceable fact. The June reporting around Twinwin illustrates why this matters. Court filings were reported as indicating that approximately £300 million of mortgages linked to Twinwin appeared not to have been registered in public property records. If correct, that could affect the ability of creditors to establish or protect their claimed interests and priority. The important point for asset infrastructure is not to decide the legal consequences in that particular dispute. It is to recognise that these are different states: “Mortgage document executed”, “Mortgage submitted for registration”, “Mortgage registered”, “Mortgage currently shown as registered”. A document package may support the first state.

Only registry evidence can support the relevant external registration state. The states should not be collapsed.

Read professional certification within its actual scope

The August 2026 Gunnercooke development makes another distinction important. Professional involvement can create confidence. A document may be witnessed, notarised, certified as a copy, accompanied by a legal opinion, signed by a solicitor, produced on law-firm letterhead, or referred to in a completion certificate. Those actions do not all mean the same thing. A reviewer needs to know exactly what was attested. For example: “Certified true copy of document” is not the same as “Legal opinion that security is valid and perfected” which is not the same as “Independent confirmation that the collateral has not been pledged elsewhere” which is not the same as “Registry confirmation of first priority”.

The professional provenance should therefore be attached to the specific assertion, not merely to the whole deal folder. Imagine a due-diligence record saying: “Solicitor verified”. What does that mean? Did the solicitor verify:

  • identity of the signatory;
  • authority of the company;
  • execution formalities;
  • title ownership;
  • mortgage registration;
  • priority;
  • enforceability;
  • copy authenticity;
  • loan balance;
  • or only one signature?

The answer changes the value of the evidence. A better record might say:

Record Detail
Assertion Copy conforms to original.
Attestor [identified professional / firm]
Date and matter [date]; [reference]
Document [specific document version]
Scope Copy certification only.
Reliance [terms if known]
Status Current / superseded / disputed

For a legal opinion:

Record Detail
Assertion Security validly created under specified law.
Opinion provider and date [firm]; [date]
Documents reviewed [list / reference]
Assumptions [reference]
Qualifications [reference]
Addressees [parties]
Reliance rights [terms]

That prevents a narrow attestation from becoming a broad system-level “verified” badge. Document copying is unavoidable in finance.

A mortgage deed may appear in: borrower data room, lender data room, solicitor file, servicer system, warehouse financing file, securitisation file, auditor evidence pack, and investor diligence package. Copies are not inherently suspicious. But once a document leaves its original context, provenance can become weaker. A later reviewer needs to know: where this copy came from, when it was obtained, whether it matches an earlier version, whether it was independently retrieved, who supplied it, which party certified it, and whether newer evidence supersedes it. That is especially important when a dispute concerns whether documents were reproduced, altered or used outside the context in which they were originally created.

A cryptographic hash can help identify identical files. It still needs provenance around the file. Mortgage and loan assets can move. A lender may originate a loan and later: sell it, assign it, contribute it to a warehouse, grant security over it, sell a participation, transfer it to an SPV, securitise it, appoint a security trustee, or transfer servicing. The loan remains economically connected to the borrower. The legal holder or economic beneficiary can change. A useful lifecycle may look like:

  1. Loan originated
  2. Security created
  3. Security registered
  4. Loan funded
  5. Loan assigned to warehouse SPV
  6. Security benefit transferred / held on trust
  7. Loan transferred to securitisation SPV
  8. Servicer retained
  9. Loan repaid
  10. Security released

Every transfer should preserve a relationship to the same underlying loan and collateral. If each transaction creates a new asset record without linking the previous one, the market loses chain of title.

Examine warehouse eligibility, availability and valuation

Mortgage lenders often finance themselves using warehouse facilities. A warehouse lender may advance against a borrowing base of eligible mortgage loans. The individual loans may continue to be serviced by the originator. The warehouse lender needs confidence that: each loan exists; each borrower exists; the property exists; the mortgage is valid; the required priority exists; the loan satisfies eligibility criteria; the loan has not already been sold or pledged inconsistently; collections are controlled; and later lifecycle events are reported. Now suppose the originator has several warehouses. The same internal mortgage record must not accidentally or deliberately enter two incompatible collateral pools. That requires more than a spreadsheet check. It requires a durable link:

Illustrative sequence: Loan identity to Prior financing history
  1. Loan identity
  2. Current financing pool
  3. Current security / assignment state
  4. Prior financing history

This is exactly the kind of infrastructure question highlighted by alleged double-pledging cases. A warehouse or securitisation tape may say: “Eligible: Yes”. That means the asset satisfies defined criteria. It does not by itself establish ownership. Similarly: “Included in borrowing base: Yes” means the financing calculation includes the asset. It does not independently prove that no other financing calculation includes it. The system should distinguish asset exists, originator owns asset, asset eligible, asset assigned, assignment effective, asset pledged, pledge perfected, asset included in borrowing base, asset released, asset sold, and asset repaid. These are lifecycle states. Suppose a property is worth £2 million. A lender has a £1 million loan. On paper: “LTV = 50%”.

That looks comfortable. But if another lender has a valid prior £1.2 million claim over the same property, the first lender’s effective recovery position is very different. Collateral value answers: “What is the asset worth?” Collateral availability answers: “How much of that value is actually available to this creditor after valid prior claims and costs?” The second question depends on title, priority, prior debt, intercreditor rights, statutory claims, enforcement costs, and other encumbrances. A loan tape containing only property value and loan balance cannot answer it. Consider: a £10m property value, £5m Loan A and reported LTV of 50%. If Loan A has first priority, the position may be straightforward. Now add: “Prior secured debt: £4m”.

The same 50% calculation remains arithmetically correct if it uses only Loan A. Economically, it omits a material claim. A more useful metric might distinguish individual loan LTV, combined secured debt, prior-ranking debt, total encumbrances, net collateral coverage, and stressed recovery value. Asset infrastructure should preserve the inputs rather than rely on one ratio. Registries can reduce uncertainty. They are essential sources of external evidence. They are not complete models of every financing relationship. Depending on jurisdiction and asset type, a registry may show: legal owner, registered charge, company security filing, filing date, secured party, or discharge. It may not show every economic participation, contractual subordination, unregistered right, beneficial interest or data-room representation.

A lender should therefore not choose between “Documents” and “Registry”. The stronger model connects them.

  1. Security document
  2. Registry filing
  3. Current registry state
  4. Loan record
  5. Collateral record

Any mismatch becomes an exception requiring review.

A proposed model for conflicts and collateral uniqueness

A traditional system may try to produce one answer: “Owner: Lender A”. Real-world disputes are sometimes not that clean. During diligence or insolvency, the system may have evidence supporting competing positions. For example:

Competing position Source Support or review state
Claim 1: Lender A asserts a first-ranking mortgage. Executed mortgage deed. Registry support found.
Claim 2: Lender B asserts assignment of the same loan. Assignment agreement. Registry / notice support pending review.

The right system behaviour is not necessarily to choose one immediately. It can preserve both claims and mark the conflict. That makes uncertainty explicit. A false single answer is more dangerous than an honest unresolved exception. For DaDepo, a mortgage-backed asset should not have one generic ID only.

It should connect at least:

Borrower identity

Legal entity or person, registration number where applicable, group relationship, guarantors, KYC identity, and aliases or prior names.

Loan identity

Lender loan number, facility agreement, origination date, original principal, current balance, currency, interest, maturity, amendments, and servicing identifier.

Property identity

Title number, cadastral or registry identifier, address, legal owner, property type, valuation references, and external registry sources.

Security identity

Mortgage or charge document, chargor, secured party, security trustee, creation date, registration reference, registration state, priority, intercreditor relationship, release state, and enforcement state.

Financing identity

Warehouse, borrowing base, securitisation, assignment, pledge, participation, investor vehicle, and current financing status.

Professional evidence

Law firm, professional, matter reference, certificate or opinion type, exact scope, date, document version, addressee, reliance terms, and later challenge or supersession.

Provenance

Source system, source document, registry retrieval, extracted fact, user-entered fact, externally confirmed fact, reviewer, timestamp, and version history. Now the system can ask whether two lenders are really talking about the same asset. Duplicate-asset risk cannot be solved inside one deal room. If Lender A checks only its own transaction, its file can be internally perfect. Lender B’s file can also be internally perfect. The conflict exists across the two. A useful infrastructure control therefore needs a wider question:

Has this economic asset, loan or security already appeared elsewhere in an incompatible state?

That does not mean exposing confidential portfolios to competitors. Possible technical approaches can preserve confidentiality while checking uniqueness or conflicting state. The design principle is what matters. Uniqueness should be tested at the level of the economic object, not only at the level of the uploaded file. Suppose two lenders receive different mortgage PDFs. The files have different hashes. That proves they are different digital files. It tells us nothing about whether both describe the same property. Suppose they receive identical PDFs. The hashes match. That proves the files are identical. It still does not prove which lender has the valid current right.

Hashing is therefore useful for version control, tamper detection, evidence integrity, and provenance. It is not a substitute for asset identity, chain of title, security registration, priority analysis, or ownership state. This distinction matters as secured lending adopts blockchain and tokenisation. Putting a mortgage-document hash on-chain does not prevent the underlying property from being represented in another financing.

Document integrity does not establish collateral exclusivity

Blockchain can help if the market agrees that a particular ledger is authoritative for a particular state. For example, a shared permissioned registry could record: Collateral P1 with current active pledge S1, Secured Party A and an Active status. A second incompatible pledge could be blocked or require an explicit priority relationship. That can be powerful. But the value comes from governance and authority, not from blockchain alone. If lenders can create tokens independently on different networks, the same property can become Token X on Network A and Token Y on Network B. Both tokens can be technically unique. The collateral is still duplicated economically. The infrastructure therefore needs a trusted bridge to real-world asset identity and legal state.

The Gunnercooke investigation is relevant to DaDepo for another reason. Financial systems often treat professional work as an attachment. Files named Legal opinion.pdf, Certificate.pdf and Solicitor letter.pdf may all appear in the package. That wastes important information. Professional evidence should be modelled as structured provenance. For every material opinion or certification, the system can preserve: who issued it; professional firm; date; matter reference; recipient; exact document reviewed; exact assertion made; assumptions; qualifications; reliance rights; expiry or update conditions; and whether the evidence has later been challenged. This helps prevent a common due-diligence error: treating the existence of a lawyer’s document as proof of everything in the transaction. Lawyers are often asked to provide carefully bounded opinions. The data model should respect those boundaries.

This is another critical distinction. A genuine document can describe: an already-repaid loan, a released charge, an outdated valuation, a superseded facility, an earlier owner, a property later sold, or a security position later changed. Authenticity answers: “Is this really the document it purports to be?” Current relevance answers: “Does it still describe the asset state today?” Both matter. An Asset Passport needs version and lifecycle history so that authentic but superseded documents do not silently remain authoritative.

Follow servicing, repayment and insolvency events

Collateral records should not end at origination. A secured loan can change because of principal repayment, additional advance, interest capitalisation, extension, covenant waiver, new collateral, collateral release, partial discharge, refinancing, assignment, default, receiver appointment, property sale, or final repayment. Suppose a loan secured by three properties is partially repaid and one property is released. The original security schedule remains historically valid. It is no longer the current collateral state. A new lender looking only at the closing documents can be misled. The current Asset Passport should show: the original collateral P1, P2 and P3, the release of P2 on [date], and the remaining collateral P1 and P3. The event history should remain available.

In normal operation, imperfect asset records may look like an administrative issue. In insolvency, they become a recovery issue. Creditors and administrators need to reconstruct: who advanced money, to which entity, under which agreement, against which assets, whether security was created, whether it was perfected, who has priority, whether the loan was assigned, where collections went, whether collateral was duplicated, and what remains recoverable. If that information is fragmented across email, spreadsheets, PDFs, servicing systems, registries, legal files and warehouse reports, reconstruction becomes slower and more expensive. A strong Asset Passport is valuable precisely because it is prepared before distress.

AI support and the bounded DaDepo contribution

AI-assisted preparation

The analytical uses discussed here are possibilities for document review, subject to source access and human judgement. They are not a claim that DaDepo currently performs every proposed check or reaches the resulting legal or financial conclusions. AI can be extremely useful in secured-loan diligence. It can extract: borrower names, company numbers, property addresses, title numbers, lender names, loan amounts, mortgage dates, charge references, valuation dates, legal-opinion dates, assignment references, and release documents.

Across a portfolio, it can flag: the same title number appearing in two loan packages; the same property address with different collateral IDs; two documents claiming first-ranking security; a loan assignment without an obvious corresponding servicing update; a mortgage document without registry evidence; a registry charge not reflected in the loan tape; an old valuation presented as current; inconsistent secured-party names; a certification referring to a different document version; or a security marked active after a discharge document. Those are high-value exceptions.

AI should not independently determine: which competing creditor has legal priority; whether a charge is valid; whether a registration defect is curable; whether an assignment is effective; whether a document is forged; whether a professional acted properly; whether fraud occurred; or how a court will resolve a dispute. The system can surface the conflict. The legal conclusion remains for qualified professionals and relevant authorities.

DaDepo can help prepare a private document-backed asset draft and retain source-linked information for human review. The private Parties and contractual roles table can record source-described party, contract and role rows with document and clause references, optional source dates, and pending, confirmed or rejected review decisions. The same party can appear in different contracts and roles. Where current compatible completed analysis is available, AI may suggest pending role rows; a user reviews and confirms or rejects them. These records do not establish legal title, priority, enforceability, the validity of a reported exposure or the outcome of a dispute.

The specialist information model for secured loans and collateral is a proposed information requirement. A complete relationship graph, automatic exposure reconciliation and automatic cross-contract decisions are not delivered capabilities established by this article. DaDepo’s relevant role is not to decide the MFS dispute. It is to build infrastructure that makes this class of uncertainty harder to hide. A proposed secured-loan record would need to connect:

  1. Borrower
  2. Loan
  3. Property
  4. Security
  5. Registry state
  6. Priority
  7. Financing pool
  8. Professional evidence
  9. Servicing events
  10. Current balance

The proposed model would allow a reviewer to move beyond: “Mortgage documents present: Yes” and ask:

  • Which mortgage?
  • Over which asset?
  • For which loan?
  • In favour of whom?
  • Registered where?
  • With what priority?
  • Still active as of when?
  • Previously pledged where?
  • Certified by whom?
  • What exactly did the certification establish?

That is much closer to the information a secured-credit market actually needs.

Creating or reviewing a mortgage or secured-loan Asset Passport does not mean that DaDepo has authenticated every loan or mortgage document; confirmed borrower identity independently; verified legal title to property; established that a security interest is valid; perfected or registered a charge; determined creditor priority; confirmed that collateral has not been pledged elsewhere; confirmed the effectiveness of an assignment; given a legal opinion; certified a document; verified a professional’s work; determined that fraud or misconduct has occurred; resolved competing creditor claims; valued collateral; predicted enforcement recovery; acted as a lender; acted as security trustee; operated a land or companies registry; acted as a servicer; enforced security; recommended a loan or investment; or provided legal, regulatory, financial, investment, tax, accounting, credit, underwriting, investigation or valuation advice.

Important: DaDepo provides technology and information tools. It does not provide legal, financial, investment, tax, accounting, lending, servicing, security-trustee, investigation, credit-rating, underwriting, enforcement or valuation advice or services unless a specific service is expressly identified and lawfully provided. Security creation, perfection, registration, priority, assignment and enforcement depend on applicable law, transaction documents, registry state and the facts of each case. Allegations discussed in this article remain subject to ongoing legal, insolvency and regulatory processes.

Questions for a collateral-provenance review

Before a mortgage or other secured loan enters a financing portfolio, warehouse or secondary transaction, ask:

  1. Borrower: Is the exact legal borrower correctly identified?
  2. Loan: Does the loan have a stable identity across origination, servicing and financing systems?
  3. Property: Is the collateral linked to a durable title, cadastral or registry identifier rather than only an address?
  4. Ownership: Does external evidence support the chargor’s ownership or ability to grant security?
  5. Security document: Which exact document creates the mortgage or charge?
  6. Execution: Is execution supported by the required evidence?
  7. Registration: Was the security submitted to the relevant registry where required?
  8. Registry state: Is the charge currently visible and active in the relevant external record?
  9. Priority: What supports the claimed first, second, pari passu or other priority?
  10. Prior claims: What other charges or encumbrances exist over the same asset?
  11. Intercreditor terms: If multiple lenders are permitted, how are their rights ordered?
  12. Assignment: Has the loan or benefit of security been sold, assigned or transferred?
  13. Financing history: Has the loan entered another warehouse, borrowing base, securitisation or pledge arrangement?
  14. Uniqueness: Has the same economic loan or collateral appeared elsewhere under another internal identifier?
  15. Release: Has any part of the collateral been released, discharged or substituted?
  16. Professional evidence: Who certified or opined on which exact fact, document or legal issue?
  17. Scope: What did that certification or opinion actually establish—and what did it not establish?
  18. Current state: Are the documents still current, or have later events superseded them?
  19. Conflict: Are competing claims or inconsistent evidence visible rather than overwritten?
  20. Provenance: Can every material ownership, registration and priority statement be traced to its source, date and reviewer?

If the answer to “is this exact collateral already supporting another incompatible claim?” depends on manually searching a folder of PDFs, the control is too weak for scalable private credit.

Make the secured position inspectable

Mortgage lending already produces digital documents. That is not the hard part. The hard part is preserving the relationships among the rights those documents describe. A modern secured-credit system needs to distinguish document identity, loan identity, property identity, security identity, registration state, priority and economic exposure. It also needs to know when those states change. The MFS collapse is still being investigated and litigated. No technology platform can replace the courts, insolvency practitioners, regulators, lawyers or registries that will determine the facts and legal consequences. But the public dispute exposes a market-infrastructure weakness that extends far beyond one lender. Private credit is scaling. Mortgage warehouses are scaling.

Asset-backed finance is scaling. Secondary transactions are scaling. Institutional investors are increasingly several steps removed from the original borrower and property. At that distance, trust cannot depend on recognising a familiar PDF or seeing a professional logo in a data room. The market needs durable collateral identity, chain of title, registry provenance and explicit competing-rights information. The question is no longer merely: Do we have the documents? It is:

Can we prove which real-world asset those documents refer to, which rights are currently attached to it, who holds those rights, how they got them and whether anyone else has a competing claim?

That is the difference between a digital document archive and financial infrastructure.

Further reading