Trust & AI governance

You're an AI — isn't uploading borrower data to you the same as putting it into a public chatbot?

No — and the difference is concrete:

1. It's the commercial Anthropic API, not a consumer chatbot.
2. Under the commercial terms, your inputs are never used to train models.
3. There's no shared chat history — each document is a separate, isolated request.
4. Documents are retained only as long as needed for processing.

Are our borrower documents used to train AI models?

No. Processing occurs under Anthropic's commercial API terms, which prohibit using inputs or outputs to train models.

Could a data-sharing setting change that?

No such setting is enabled. LoanLoom sets no data-sharing option, and none applies to this service.

Does a human read the documents that are processed?

No human-review step exists. Documents are read by the extraction service to pull the loan fields; they are not routed to any reviewer or queue.

Is there a chat history of borrower data on the AI service?

No. Each document is a separate, stateless request. No conversation, thread, or history is assembled or retained on the service.

Does LoanLoom copy files out of our Google Drive?

No. The Google Drive integration reads file content on demand; it does not copy or store the file body. The document record holds references and extracted fields, not the source bytes.

How are Social Security numbers handled?

SSNs are masked to the last four digits on all operator-facing surfaces. Full values are used only for MISMO output and identity verification, and the unmasked change history is owner-gated.

Is one workspace's stored data reachable from another?

No. Every record is scoped to a single workspace and isolated by database row-level security, force-enabled on every table holding borrower data.

Are sensitive identifiers masked where staff can see them?

Yes. Social Security and tax identifiers are masked to the last four digits on every operator-facing surface; the unmasked change history is owner-gated.

Is stored data encrypted at rest?

At rest, encryption is provided by the hosting platform rather than by LoanLoom. Railway attests to provider-managed encryption in its SOC 2 Type 2 report — see AI Governance, section 3 (Hosting), for the full attestation and its scope.

How are documents shown for review without leaving copies behind?

Document pages are rendered on demand for review and are not persisted to the database. For the Google Drive channel, files are fetched from Google each time rather than copied.

How is one broker's data kept separate from another's?

Every record is scoped to a single workspace and isolated by database row-level security, enabled and force-enabled on every table holding borrower data. Isolation is enforced at the database, not just in application code. A query without a valid workspace context returns nothing — the system fails closed.

What database privileges does the application run with?

The application connects with a least-privilege database role that is not a superuser and cannot bypass row-level security. That is what makes isolation enforceable rather than advisory.

Who on our team can see what?

Access is owner-scoped. The account owner holds administrative capabilities — user management, integrations, settings, and access to the unmasked field-change history — that team members do not. Every borrower-data access is permission-checked per request.

What happens when someone leaves the team?

The audit trail preserves the acting user's identity even after they're removed, so the chain of custody survives personnel changes.

Is every action on a loan recorded?

Yes. Every action — who did it, what they did, which document or field, and when — is written to an audit log in the same database transaction as the change itself, so a change cannot be recorded without its audit entry.

Can the audit log be edited or deleted?

No. The audit log is append-only, enforced at the database: any attempt to modify or delete a record is rejected by the database, and the application role is not granted the ability to update or delete audit records.

Can you show which field changed, by whom, and from what to what?

Yes. For each corrected field, LoanLoom records the specific field, the person who changed it, and the before-and-after values. The full before/after is access-controlled to the account owner; the general trail shows a masked summary.

How do you track which extracted values a human has verified?

Each field carries a verification state. When an operator confirms a value against its source document, that verification is recorded per field, and the count of still-unverified fields is surfaced as a supervision measure before export.

Are reads of borrower documents recorded, or only changes?

Both. Fetching or rendering a document's content writes its own audit entry, alongside the entries for changes.

Is a view of extracted borrower data recorded, or only changes?

Both. Every render of a loan's or a document's extracted detail writes its own audit entry — the actor and the time, marked as containing borrower data — on the same read path that returns the values. The trail records views at loan and document level, not per individual field, and repeated views are collapsed for display so they cannot bury changes.

Can a compliance record be altered after the fact?

No. The audit log is append-only, enforced by the database itself: any UPDATE or DELETE against it is rejected outright.

How long are records kept, and on what schedule?

No retention schedule is implemented. The audit log carries a retention class per record, but nothing enforces or expires on it yet, so LoanLoom makes no retention-period claim.

If you delete a loan, what actually gets removed?

The borrower's personal information, everywhere it is stored — not just the loan record:

1. The loan, its documents, and every extracted field — including the full Social Security number held for the 1003 and for identity matching.
2. The source files themselves, on disk, and every rendered page image made from them.
3. The borrower's contact record — name, phone, email — and their name where it appears inside mirrored file and folder names.
4. The queued processing events, which carry field values in their payloads.
5. Deletion is verified after the fact by a scan that shares no code with the deletion itself, and the operation fails loudly if anything is found still standing.

Is anything kept after a deletion?

Yes, and deliberately — two things, neither of which contains the borrower's personal information:

1. The audit trail: who did what, when, and to which record. It is append-only and holds references and masked hints only — never a full Social Security number or account number.
2. The change record behind a disputed figure: which field changed, who changed it, and when. The before-and-after values are removed; the record that a change happened is kept.

Can you prove a deletion happened?

Yes. Each deletion writes its own audit entry recording who ran it, which loans were affected, and the per-table counts the database reported — and, like every other audit entry, it contains no borrower information itself.

You're an AI — isn't this the same as a public LLM?

No. Documents are processed through the commercial Anthropic API, not a consumer chatbot: inputs aren't used for training, and no shared chat history is assembled.

Does anyone at LoanLoom read the documents?

No. No human-review step exists in the pipeline; documents are read by the extraction service and are not routed to a reviewer or a queue.

Is each request isolated to my workspace?

Yes. Every extraction is scoped to your workspace and recorded in your audit trail.

Are our borrower documents used to train AI?

No. Processing is under commercial API terms that prohibit training on inputs or outputs.

How are SSNs handled?

Masked to the last four digits on every operator-facing surface; full values are used only for MISMO output and identity verification, and unmasked change history is owner-gated.

How is my data kept separate from other brokers?

Every record is workspace-scoped and isolated by database row-level security, enforced at the database under a role that cannot bypass it. A query without workspace context returns nothing.

Can the audit log be tampered with?

No. It's append-only, enforced by the database — modifications and deletions are rejected outright.

Is my data reachable from another broker's workspace?

No. Every record is workspace-scoped and isolated by database row-level security, enforced under a role that cannot bypass it.

Are my borrowers' identifiers masked?

Yes — masked to the last four digits on every operator-facing surface, with unmasked history owner-gated.

Is my data encrypted at rest?

At rest, encryption is the hosting platform's. Railway attests to provider-managed encryption in its SOC 2 Type 2 report; see AI Governance, section 3 (Hosting).