Evidence Before Yield: Designing an Aergo Receivables Pilot UK Lenders Can Review

Start with the underwriting question

Invoice finance is often framed as a lending product. For a UK lender, it is first an evidence product. Before funds move, the lender must be satisfied that a receivable exists, that it is owed by a named debtor, that the right to payment has been validly assigned, and that repayment can be traced and reconciled. Tokenisation can be added later; it cannot substitute for those proofs. An Aergo pilot should therefore be designed around the lender's credit file, not around a token launch.

The practical question is not whether an invoice can be represented on-chain. It is whether a credit committee can review a coherent evidence trail without needing to understand blockchain internals. That standard should shape the pilot from the first workshop.

A pilot perimeter that fits a lender's file

Keep the first phase deliberately narrow: one seller, one lender, a defined debtor cohort and a single invoice type. Avoid mixing domestic and export receivables, or contracted and disputed invoices, in the same pilot. The objective is to prove that the evidence model works under ordinary conditions before introducing edge cases.

The pilot should also avoid creating a parallel economy. The receivable remains a legal claim governed by contract and insolvency law. Aergo provides an event log and a shared source of attestations. It does not replace the invoice, the assignment agreement or the bank statement.

A sensible perimeter includes invoice creation, assignment, debtor notification, status changes, repayment matching and dispute referral. Everything else, including credit scoring and pricing, can remain with the lender's existing systems.

Four evidence registers

A lender-friendly Aergo deployment can be organised around four registers. Each should be readable by a non-technical reviewer and auditable by an independent party.

• Invoice identity. A stable reference, issue date, amount, currency, payment terms and debtor identifier. Documents remain off-chain; hashes and controlled metadata are anchored on Aergo.
• Assignment. The assignment instrument, signatory authority, effective date and any conditions. The ledger records that an assignment event occurred and who attested to it, not the legal effect by itself.
• Status. Issued, accepted, notified, assigned, part-paid, disputed, credited or settled. Status changes should require authorised signatures and should never overwrite earlier states.
• Repayment. Expected date, actual receipt, bank reference, allocation and reconciliation status. This is where lenders will look hardest, because repayment behaviour is the point of the facility.

Each register should have an owner, a permitted writer and a review path. The design should make it obvious when an event is missing, late or inconsistent with the bank record.

UK legal notes: assignment, notice and insolvency

Under English law, a legal assignment of a debt generally requires an absolute assignment in writing and express notice to the debtor under section 136 of the Law of Property Act 1925; otherwise the assignment may take effect in equity. A ledger entry can record that notice was issued and acknowledged, but it does not itself create or perfect the assignment. The pilot should capture the assignment instrument, signatory authority, notice date and delivery evidence as controlled documents, with fingerprints anchored on Aergo.

Debtor notification policy needs care. Some UK facilities use silent assignment; others require notice. The pilot should make the chosen policy explicit and record any acknowledgement without exposing unnecessary debtor data to every participant.

Insolvency risk also deserves candour. If the seller enters administration or liquidation, the lender's position may depend on notice, set-off, counterclaim, retention of title and the debtor's payment behaviour. The pilot should not claim to eliminate those risks. It should make them visible: an exception queue for disputes, a record of part-payments, and a clear link between the legal assignment and the corresponding ledger entry. Lenders will want an insolvency practitioner to be able to follow the same trail without specialist blockchain knowledge.

Data minimisation without losing proof

UK GDPR obligations do not disappear because the ledger is shared. Store debtor personal data off-chain, anchor only hashes and the minimum identifiers needed for reconciliation, and use pseudonymous references where the lender's file allows it. Apply role-based access so that a debtor's contact details are not visible to every node operator.

A retention schedule should cover both on-chain pointers and off-chain documents. If a document is deleted under a retention policy, the hash may remain as evidence that a record existed, but the pilot should explain what can still be verified and what cannot. That distinction matters to auditors and to data protection officers.

Controls, reconciliation and the exit test

The pilot should include segregation of duties, multi-signature approval for material status changes, and a daily reconciliation between expected repayments and bank receipts. Exception handling should be a first-class workflow, not an afterthought. A disputed invoice is not a failed pilot; an unexplained dispute is.

Define success in evidence terms. Useful measures include the percentage of invoices with complete assignment packs, the time from invoice upload to lender decision, the proportion of repayment events reconciled within one banking day, and the number of audit queries that require manual explanation. The exit test should include a handover pack that a new lender or auditor can review without the original build team present.

Aergo is most useful here as a shared, permissioned record of attestations: who confirmed what, when, and against which document. That is a modest claim, but it is the claim a UK lender can underwrite. Build the pilot around receivables evidence first; token design can wait until the credit file is strong enough to survive scrutiny.