Skip to content

Security & Trust

Security built for lender teams and examiners

Loan servicing handles sensitive financial and identity data. LendEasy masks data by default, minimizes what AI models receive, closes API access by default, and keeps tamper-evident audit records for human and AI actions.

Request a demoHow AI data boundaries work

Data minimization & PII protection

Access starts closed

Borrower identity is revealed only to people or systems with the required permission and a case-related reason. Screens, free text, and AI task packets are designed to limit sensitive data.

Masked by default

Sensitive borrower data is masked by default across the platform. Unmasked access is a separate permission — granted deliberately, and audited every time it is used.

PII minimized before model calls

Configured data policies remove or tokenize PII before a model call, and each AI task receives only the information it needs.

Minimal AI task context

An AI task receives the facts needed for that work, not the borrower's entire file.

Unmasked access leaves a trail

Each unmasked view records who accessed the data, what they viewed, and the case or task that required it.

Model options & AI data boundaries

Your data does not train someone else's model

Before borrower-data AI work goes live, provider terms must prohibit training on tenant data and define retention limits. You can also run supported models inside your cloud or on your own infrastructure.

Hosted models with no-training terms

Use supported hosted models under enterprise terms that prohibit training on tenant data and define retention limits.

Inside your cloud boundary

Use supported deployment options that keep model processing within the cloud boundary your team governs.

Self-hosted open weights

Operate open-weight models on your own infrastructure while keeping the same policy checks, ledger-backed facts, version history, and audit trail.

Whichever option you choose, the same platform-side boundaries apply: each AI task receives only the facts it needs, and every output records the model and prompt version that produced it.

Access control

Access is readable, scoped, and reviewable

There is no application-level superuser bypass through servicing. Permissions are granted per action, AI-proposed money movements can require human approval, and every actor — person, agent, or integration — operates inside a recorded context.

Permission per action

Grant permissions for specific actions instead of broad module access. People, AI agents, and integrations receive only the access their work requires.

Human approval controls

AI-proposed financial actions can require human approval before execution. Policies that require separation of duties can assign an independent human approver.

Role-scoped service accounts

Every integration runs as its own service account with a role scoped to its job. No shared admin credentials, no integration that can do everything.

Every action has a reason

Each action is tied to a case, an approved exception, or a system event. The record shows why the action was requested.

Audit & evidence

Trace each action from request to ledger outcome

Linked, hash-chained records capture the facts, rule versions, approvals, and outcome for each action, including the command sent to the lending core.

Hash-chained decision records

Each decision record includes the previous record's hash, so a later edit breaks the chain and becomes visible.

Searchable decision history

Search account actions by date, facts used, rule versions, approvals, and outcomes.

Litigation and exam exports

Export the decisions, rules, approvals, and outcomes tied to an account for litigation or examination review.

Linked to core commands

The audit trail links each servicing decision to the command that reached the lending core and its final outcome.

Platform controls

Closed by default, append-only, and tenant-isolated

API access requires explicit permission, audit records cannot be quietly rewritten, and tenant separation is enforced at the database level.

Deny-by-default API surface

Every endpoint is explicitly allowed, gated, or blocked — and CI tests prove the classification. A new upstream endpoint cannot appear in production unclassified.

Retention & legal hold

Evidence records are append-only and carry retention and legal-hold states. Records under hold cannot be removed through the standard retention process.

Cloud-native deployment

The platform is cloud-native and API-first. We work with design partners on deployment models that fit their security and data-residency requirements.

Tenant isolation at the database level

Tenants are isolated at the database level — not by a filter clause in application code. Your portfolio's data lives apart from everyone else's.

Open, auditable foundation

The lending core uses an open-source foundation your team can inspect. Documented APIs and a standard database provide a practical exit path.

Recorded exceptions

Non-overridable controls remain blocked. Where policy allows an exception, the record includes the approver, reason, evidence, and expiry.

Our security posture, stated plainly

LendEasy includes action-level access, human approval for sensitive AI-proposed actions, data minimization, tamper-evident audit records, retention and legal hold, and explicit AI data boundaries. We can walk through each control against your security questionnaire.

FAQ

What security reviewers ask first

In a cloud-native deployment with tenant isolation enforced at the database level — your portfolio's data is structurally separated from every other tenant's, not filtered apart in application code. We work with design partners on deployment models that fit their security and data-residency requirements, and the open-source foundation means your auditors can inspect the core that holds the ledger.

Bring your security questionnaire

Review the controls with the founding team: data boundaries, access model, evidence trail, and the deny-by-default API surface.

Partner with usHow the compliance engine works