Security

How we protect your borrowers' data

LoanCurrent holds the most sensitive parts of a loan file: pay stubs, bank statements, Social Security numbers and credit reports. This page explains, in plain terms, how that data is stored, who can reach it and what we are still working on.

Request our security packet

Borrower documents

  • Borrowers upload through a secure link made of a long random code. Document links expire after 30 days unless the loan officer sets a date, and each upload is checked for size and file type.
  • Files go into private storage. Nothing is public and nothing can be browsed or guessed from a web address.
  • When your team opens a document, LoanCurrent first checks the person's company and role, then issues a download link that stops working after 30 minutes. Signed documents and flood certificates use links that last 60 seconds.
  • Marketing seats cannot open loan files or borrower documents.

Signing in

  • Your team signs in with a password or with Google.
  • Anyone can add two-step sign-in with an authenticator app. A company's owners and admins can require it for everyone, and it is always required for LoanCurrent staff.
  • Once someone has two-step sign-in, every sign in asks for a code before any page or data loads. The database enforces the same rule, so a stolen password alone cannot read your data.
  • If someone loses their phone, an owner or admin in your company resets it, and the reset is recorded.

Who can see what

  • Every record belongs to one company. The database itself blocks one company from seeing another's borrowers, loans or team, on every table.
  • Inside a company, a loan officer sees only their own borrowers, loans and Social Security records, plus loans they co-originate. Processors see the loans assigned to them, team managers see their team's, and owners and admins see everything. A small shop can choose to let everyone see every record.
  • An automated check runs every day and alerts us if any table is missing that protection.
  • Roles set what each person can do: owner, admin, loan officer, processor, viewer and marketing. Viewers can read loan files but cannot change them.
  • When an admin previews the app as another role, that view is read only.

Social Security numbers and credit reports

  • Social Security numbers and credit reports are encrypted with AES-256-GCM before they are saved, using a key kept apart from the database.
  • They are decrypted only on our servers when a task needs them. The app shows the last four digits of a Social Security number, never the full number.
  • Passwords you give us for connected services, such as a credit vendor or your own texting account, are encrypted the same way.
  • All traffic uses HTTPS, and the database and file storage are also encrypted at rest by our hosting providers.

A record of every change

  • Every create, change, delete and sign in is recorded with who did it and when. The record lists which fields changed, never their values, so the log itself holds no borrower data.
  • Exports of borrower data, such as the MISMO lender file, the call report, the HMDA register and year end figures, are limited to people who work loans and are logged.
  • Owners and admins can review this activity in the app.

Integrations and API

  • API keys are shown once when created and stored only in hashed form. Each key belongs to one company and carries only the permissions an admin gives it.
  • The API never returns Social Security numbers, dates of birth, income, assets or credit data.
  • Webhooks we send go only to secure web addresses, are signed so your systems can confirm they came from us, and are never sent to private network addresses.
  • Messages we receive from payment and phone providers are checked for a valid signature before we act on them.

AI

  • AI drafts follow ups, summarizes calls and answers questions about your pipeline, using the loan details the task needs.
  • Social Security numbers and credit reports are never sent to an AI provider.

Hosting

  • The app runs on Vercel. The database, file storage and sign in run on Supabase, which is hosted on Amazon Web Services.
  • Our database service key lives only on our servers and is never sent to a browser. Secrets are kept in the hosting provider's encrypted settings, never in code.
  • Every release is tested and deployed from our main code branch. Database changes are versioned and applied deliberately.

Our commitments to you

  • If an incident affects your data, we tell your company's owner in writing within 36 hours of confirming it, with what happened, what data was involved and what we did.
  • When you leave, we export your data to you and delete it within 90 days, unless the law requires us to keep it longer.
  • Each outside service we use receives only the data its job needs.

What we're still doing

We would rather tell you what is open than have you find it in a review.

  • SOC 2: we do not have a SOC 2 report and have not started the audit.
  • Backups: confirm the backup and point in time recovery settings on our production database, and test a full restore.
  • Uptime monitoring: we have a health check for it; we still need to choose the monitor and set up its alerts.
  • AI providers: get written confirmation of zero data retention and no training on our requests, or move to a direct agreement that guarantees it.
  • Borrower links: signing links are stored hashed today; application and document links will be too. Our limits on repeated attempts will hold across all of our servers, not each one alone.
  • Encryption key: keep an offline backup of the key and document how it is rotated.
  • Training: record that everyone with production access has reviewed our security program each year.

Doing a vendor review?

Our written security program, data flow and incident response plan are available on request.

scott@molluso.ai