What protects the record.
A loan record is only useful if neither side can quietly change it. These are the controls, described plainly.
Controls
What is in place today, in the order a change to a loan passes through them.
Writes happen only on the server
The browser never writes to the database. Every change to a loan, a payment or a document is made by server code that first verifies the session and then checks that the person is a party to that loan with the right role. A borrower cannot mark a loan funded; a lender cannot sign for the borrower.
Database rules deny everything by default
Firestore security rules reject all writes from clients. Reads are allowed only to the parties named on a loan, and only for that loan and its schedule, ledger, payments, documents and events. Anything not explicitly allowed is denied.
The ledger is append-only and hash-chained
Every disbursement, interest posting, late fee and payment is a numbered entry in the loan’s ledger. Each entry carries a SHA-256 hash of its own contents together with the hash of the entry before it. Entries are never edited or deleted. A correction is a new entry that says what it corrects.
Because each hash depends on the one before, altering any posted entry would break the hash of every entry that follows. The chain can be verified from the first entry at any time.
Documents are hashed at signing
When a party signs the note, NoteHouse computes the SHA-256 hash of the PDF bytes at that moment and stores it with the signature. The stored document can be re-hashed later and compared. If the bytes differ, the record shows it.
Electronic signature records
Each signature records the signer’s account, their role, the name they typed, the time, their IP address, their browser, the hash of the document they signed, and the consent text they were shown. A signature certificate listing these facts is generated alongside the executed note.
This follows common practice under the federal ESIGN Act and the Uniform Electronic Transactions Act (UETA), which recognize an electronic signature made with intent to sign and attributable to the signer.
Sessions
Sign-in is handled by Firebase Authentication with email and password or Google. A successful sign-in sets an HTTP-only session cookie that expires after 14 days. The server verifies the cookie on every request, including whether the session has been revoked, and redirects to sign-in when it is absent or invalid.
Hosting and payments
Data is stored in Google Cloud (Firebase) and the application runs on Vercel. Both encrypt data in transit and at rest. Bank debit is processed by Stripe; NoteHouse stores a reference to the payment method, not account numbers.
What NoteHouse does not do
NoteHouse does not lend money, hold funds, or move money on its own behalf.
When bank debit is enabled, the payment travels from the borrower’s bank account to the lender’s through the payment processor. NoteHouse records the result. It is not an intermediary account and does not take custody of the funds.
NoteHouse does not make credit decisions, report to credit bureaus, or verify that a borrower can repay. It does not check whether a rate complies with state usury limits. Those judgements belong to the parties and, where needed, their counsel.
Reporting a problem
If you find a vulnerability, write to the security contact given in the terms of service. Include enough detail to reproduce it. We will acknowledge the report, keep you informed, and not take action against good-faith research.
The record is the product.
Everything above exists so that two people can trust one ledger.