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.
Security & Trust
Security built for lenders — and for the examiners behind them
Loan servicing handles the most sensitive data a consumer has, and AI raises the stakes. LendEasy’s answer is engineering, not assurance theater: data masked by default, PII scrubbed before any model call, deny-by-default APIs proven by CI, and tamper-evident audit evidence for every action — human or AI.
Masked by default
Account ••••4821
unmask = permission + auditAI model boundary
PII scrubbed before the model call — the model reasons over the case, never the identity
Evidence graph
tamper-evident#D-48119
#D-48120
#D-48121
Each record commits to the hash of its predecessor — an after-the-fact edit breaks the chain, visibly.
Deny-by-default APIs · dual control on money movement · isolation at the database
Data minimization & PII protection
The default answer to “who can see this?” is no one
Borrower identity is exposed only where a task genuinely requires it. Everywhere else — screens, free text, AI work packets — the platform minimizes by construction.
PII scrubbed before model calls
Personally identifiable information is scrubbed from free text before anything reaches an AI model — frontier or self-hosted. The model reasons over the case, not the identity.
Minimal AI work packets
An AI work packet carries only the facts that task needs — not the borrower's file. Data minimization is how packets are constructed, not a policy memo about them.
Unmasked access leaves a trail
Every unmasked view is itself an audited event tied to who looked, at what, and in which operational context — so access reviews are queries, not interviews.
Model options & AI data boundaries
Your data does not train someone else's model
LendEasy is model-agnostic, and the data boundary is enforced before the model question is even interesting: provider contracts must prohibit training on tenant data before any borrower-data AI work goes live. That is a launch gate, not a preference.
Frontier APIs, bounded
Use frontier models under zero-training, bounded-retention enterprise agreements — your tenant data never becomes training data, contractually.
Inside your cloud boundary
Run cloud-hosted models inside your own cloud boundary, so borrower-adjacent context never leaves the perimeter you already govern.
Self-hosted open weights
Operate open-weight models on your own infrastructure. The governance — gate, grounding, registry, evidence — lives in the platform, so it travels with whichever option you choose.
Whichever option you choose, the same platform-side boundaries apply: PII scrubbed from free text before the call, work packets carrying only the facts the task needs, and every output pinned to the registered model and prompt version that produced it.
Access control
Access is policy — readable, scoped, and dual-controlled
There is no superuser path through servicing. Permissions are granted per action, money movements take two distinct humans, and every actor — person, agent, or integration — operates inside a recorded context.
Permission per action
Authorization is modeled per action, not per module. A worker — human, AI, or integration — can do exactly what it is permitted to do, and nothing else.
Maker-checker dual control
High-impact financial actions require a second, distinct human. Dual control is enforced by the platform — structurally, not by convention.
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 carries context
Actions execute inside an operational context — a case, an audited exception, or a system trigger. There is no anonymous, context-free path to a borrower or a ledger.
Audit & evidence
Every action can answer for itself, years later
Audit evidence is the substrate of the platform, not an add-on log. Decisions are hash-chained, linked into a queryable graph, and exportable in one click — down to the core command that touched the ledger.
Hash-chained decision records
Each decision record commits to the hash of its predecessor. An after-the-fact edit breaks the chain — visibly. Tamper-evidence is a property, not a promise.
A queryable evidence graph
Decisions link to the facts they saw, the rule versions in force, approvals, and outcomes. "Show every action on this account in March" is a query, not a project.
One-click litigation & exam export
Evidence packages for litigation or examination export in one click — decisions, rules, approvals, and outcomes, ready to hand over.
Core commands, linked
The lending core keeps its own command-level audit, and those entries link to the governance records above them — one story from intent to ledger.
Platform hardening
Deny-by-default, append-only, isolated by construction
The unglamorous controls that decide how a platform behaves under pressure: an API surface where nothing is reachable by accident, records that cannot be quietly rewritten, and tenancy that holds at the database.
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 — so what must be kept is kept, and what must be held cannot quietly disappear.
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 is built on open, bank-grade infrastructure your auditors can inspect line by line. Your exit path never depends on a vendor black box.
Overrides are governed
Hard stops cannot be overridden by anyone. Soft overrides capture the approver, reason, evidence, and an expiry — and become records in the evidence graph.
Our compliance posture, stated plainly
Security at LendEasy is engineered, not promised: the controls examiners and security reviewers ask about — least-privilege access, dual control on financial actions, data minimization, tamper-evident audit trails, retention and legal hold, and explicit AI data boundaries — are built into the platform’s architecture, where you can inspect and test every one of them. Bring your security questionnaire; we would rather answer it with architecture than with adjectives.
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
Walk the controls with the founding team: data boundaries, access model, evidence graph, and the deny-by-default API surface — answered with architecture, not adjectives.