A tamper-evident seal for your signed loan agreement

A loan agreement is only as good as your ability to prove, later, that the copy in your hand is the copy both people actually signed. Most documents can't clear that bar — a Word file or a printed template can be re-typed, back-dated, or quietly edited, and there's no clean way to show it happened. Every LendRight agreement solves this at the moment of signing: it's sealed with a SHA-256 fingerprint you can check yourself, for free, at any time. This is what that seal is, how it works, and how it lets you tell whether a signed agreement has been changed since.

The quiet weakness in an ordinary document

Picture a dispute two years after the money changed hands. You produce the agreement; the other side produces a version where the amount is smaller, the due date is later, or a repayment clause has vanished. Both look real. Both are on the same letterhead. With a printed template or an emailed file, there is often no reliable way to say which one is the original — and "he changed it" against "no I didn't" is exactly the swamp a written agreement was supposed to keep you out of.

The gap isn't the wording of the contract; it's integrity — the ability to prove a document has not been altered by so much as a comma since it was signed. That is a different problem from having a signature on the page, and it's the one LendRight was built to close.

What SHA-256 actually is, in plain English

SHA-256 is a cryptographic hash function. Feed it any file — a one-line note or a 40-page contract — and it returns a fixed string of 64 characters. Think of it as a fingerprint for data: the same file always produces the same fingerprint, but there is no way to run it backwards and rebuild the document from the code. It reveals nothing about the contents; it only proves whether two files are byte-for-byte identical.

The property that matters is sensitivity. Change one character — a 5 to a 6, a single space, one letter of a name — and the fingerprint doesn't shift slightly. It changes completely, into something that looks unrelated. Here is the same sentence hashed twice, with one digit different:

SHA-256 isn't a LendRight invention — it's a public standard used to secure software downloads, banking systems, and much of the modern internet. What LendRight does is put it to work on your agreement.

How LendRight seals your agreement

The seal is created automatically the instant the second party signs. You don't configure anything:

• Both people review the same final terms and e-sign from their own phones.
• LendRight generates the final agreement PDF, then runs SHA-256 over that finished file to produce its unique 64-character fingerprint.
• The fingerprint is saved to LendRight's signing record and printed onto a separate Certificate of Completion — kept alongside the agreement rather than written back into the file that was hashed, so the recorded fingerprint keeps matching the exact file it describes.
• The confirmation screen shows both signers the fingerprint on the spot — a "document fingerprint" that will differ if even one character of the agreement file is changed afterward.

From that moment your agreement is no longer just signed — it's sealed. The signature says two people agreed; the fingerprint proves the page they agreed to is the exact page you're holding now.

Why altering a sealed agreement gets noticed

Fraud with a normal document works because you can't cheaply prove it happened. The seal changes that. To pass off a doctored agreement as the original, someone would need a different file whose SHA-256 fingerprint still matches the one on record — and finding two meaningfully different files that share a SHA-256 fingerprint is, for practical purposes, computationally infeasible. There's no shortcut and no editing trick; a changed file produces a different fingerprint.

So an edit to the agreement file doesn't slip through unnoticed. Alter the amount or the date, recompute the fingerprint from the changed file, and it no longer matches the recorded one — so the change is detectable by anyone who checks. That's what "tamper-evident" means: not a guarantee that no one will try, but a reliable way to tell that a file differs from the one that was signed — provided the fingerprint is computed directly from the file in question, not just read off the page.

How to verify an agreement yourself

The seal only helps if the fingerprint is computed from the actual document and compared against a trusted record. Two things have to line up: the SHA-256 of the file you're holding, and the fingerprint LendRight recorded when it was signed. A check is only meaningful if it derives the fingerprint from the file itself — typing in a hash and looking it up confirms that fingerprint was issued, not that your copy is unchanged.

Selecting the PDF is the check that actually inspects your file: the browser hashes the exact bytes on your device and compares the result to LendRight's record, so a match means the copy in front of you is unchanged. If you don’t have the signed PDF on hand, the page offers a weaker fallback — typing the reference and the printed fingerprint — but that only confirms the certificate details match a real signing; on its own it can't tell you the PDF you're holding still matches. Because the fingerprint is computed locally, the PDF itself never leaves your device — only the reference number and the calculated fingerprint are sent to LendRight.

What tampering looks like when it's caught

Say someone opens the signed PDF, nudges the repayment date out by a year or shaves a zero off the balance, then re-saves it and passes it on as the "real" agreement. Visually it can look flawless. But the edited file now hashes to a completely different 64-character code. Recompute the fingerprint from that file and it won't equal the one on the Certificate of Completion or in LendRight's record. The mismatch is the tell — it doesn't say what was changed, only that the file is no longer the one that was signed, which is enough to call the copy into question.

The reverse is just as useful. A genuine, untouched file recomputes to the same fingerprint every time, which is what lets you hand it to a skeptical relative, a mortgage lender, or a small-claims adjudicator alongside its Certificate of Completion. The hash speaks to one thing — whether the file has changed since signing — and it's strong evidence of exactly that. For the wider picture of why written, provable agreements decide real disputes, see our roundup of family loan court cases in Canada.

Does anyone else do this — LawDepot, eForms, NetLawman?

Plenty of services will hand you a loan-agreement document. Far fewer give you a way to prove, afterwards, that the copy in your hand is unaltered — and that's the part that matters in a fight.

• Template libraries (LawDepot, eForms, NetLawman and similar). These are excellent at generating a document from a questionnaire. But the output is typically a Word or PDF file you download and sign yourself — with no sealing step and no public page where a third party can verify the file hasn't been touched. Once it leaves the site, its integrity is on you.
• General e-signature tools. Enterprise signing platforms do hash and log documents internally as part of an audit trail. That protection lives inside the vendor's system, though — it isn't a free, open verifier that anyone can use to check a specific family loan by pasting in its fingerprint.
• LendRight. Built for private loans between people who know each other: the agreement is sealed with SHA-256 at signing, the fingerprint is printed on the document, and verify.trylendright.com lets anyone confirm it — no login, no fee.

If you're weighing the options in detail, our side-by-side comparison of LawDepot, NetLawman, eForms and LendRight lays out pricing and features, and the LawDepot alternatives guide covers when a template site is enough.

Why AI-generated lookalikes fail exact-document verification

Be clear about what AI can do: it can draft a convincing contract, compute a perfectly valid SHA-256 hash for that fake, reproduce certificate styling, and even copy a real reference number and printed hash into an altered file. So "AI can't fake it" would be too broad. What AI — or any attacker — cannot practically do is take an existing file, change it, and still have it produce the same SHA-256 fingerprint as the original signed file held in a trusted record.

So the protection rests on one condition: the fingerprint must be computed directly from the file. Given that, an AI-generated lookalike fails — its file hashes to a value that won't match LendRight's record for the real agreement, and it can't reverse-engineer a change that collides with that recorded fingerprint. It can imitate the appearance of a certificate; it cannot make an altered file yield the same SHA-256 fingerprint as the genuine signed file. The security isn't secret wording that could be copied — it's the link between a specific recorded fingerprint and the exact bytes of the file that was signed.

The bottom line

A signature records intent; the seal makes any later change to the file detectable. Together they give you a signed agreement plus a reliable way to show it hasn't been altered since. A hash alone won't prove who controlled a phone or that a timestamp was exact — but for the everyday worry with a family loan, "is this the document we both signed?", a tamper-evident seal answers it well. When there's nothing to argue about, there's less to fall out over.

Sources. The SHA-256 algorithm is defined in NIST FIPS 180-4, Secure Hash Standard. Canada's framework for electronic documents and signatures is set out in PIPEDA, Part 2 (Electronic Documents) and the Secure Electronic Signature Regulations. The in-browser hashing described here uses the standard Web Crypto SubtleCrypto.digest API. These are provided for reference and are not legal advice.

This article is general information about how LendRight's document-integrity features work, not legal or security advice. SHA-256 is an industry-standard cryptographic hash function; references to what is "infeasible" mean computationally impractical, not a mathematical guarantee for all time. A hash establishes whether a file has changed relative to a trusted record — it does not by itself prove a signer's identity or intent, the accuracy of a timestamp, or the integrity of the systems that stored the record; those are separate considerations. Integrity checking assumes the fingerprint is computed directly from the file being examined. Feature details may change — check the product for current behaviour.