Boring on purpose.
Last updated: September 24, 2026
A mortgage platform holds the most sensitive consumer data there is, so we keep our posture conservative and unexciting. We keep secrets off the client, keep data minimal, keep tenants apart, keep records append-only, and fail closed when anything is ambiguous.
Credentials never reach the browser
Every vendor call (credit, pricing, valuation, compliance, loan origination system (LOS)) runs server-side. Application programming interface (API) keys and Open Authorization (OAuth) secrets live in managed environment configuration and vaults, and we never ship a key in client code. The server decides simulated or live, so a misconfigured client can’t fake a live result.
Data minimization
We store references and statuses, and we don’t store vendor payloads. A service order keeps its transaction id, timestamp, actor and status, and the full record lives in your LOS’s document store where it belongs. Analytics events carry outcomes and signals, never Social Security numbers (SSNs) or documents.
Tenant isolation
We run each lender as its own isolated deployment, with its own application, its own database and its own credentials. No lender’s data shares a runtime, a database or a key space with another’s. Inside a deployment, row-level security governs which staff and borrowers can read which rows.
Encryption and staff sign-in
We use Transport Layer Security (TLS) in transit everywhere, and the database and hosting providers encrypt data at rest under their own attestations. Your staff sign in through your own identity provider, so multi-factor authentication (MFA) is yours to set, and the console records what your provider asserts about how each person signed in. A deployment can refuse any sign-in that doesn’t evidence MFA.
Append-only records
We write attribution ledgers and milestone events once. A correction appends a new record and never overwrites the old one. Put that together with deterministic math and you can replay any disclosed scenario and explain any record.
Fail-closed everywhere
We built the same reflex into the whole platform: the disclosure gate holds on ambiguity, scheduled jobs reject unauthenticated callers, and the pre-launch access wall denies by default if its own configuration goes missing.
Compliance path
Our System and Organization Controls (SOC) 2 Type I programme is underway. We monitor the control set continuously against the Trust Services Criteria, and we don’t assemble it for an audit window. No auditor has issued a report yet. We say that here so “SOC 2” doesn’t imply one. Our Trust Center publishes that monitoring live, and it lists only the controls already in place, not the ones we’re still closing. We haven’t had a third-party penetration test yet, and we’ve planned one in the readiness window. We share security review artifacts, architecture documentation and the dated roadmap with serious evaluators under a nondisclosure agreement (NDA). SOC 2 also isn’t an artificial intelligence (AI) audit. Our AI and machine learning (ML) governance posture is its own document, with its own controls. Read it →
Questions we welcome
- Where does each category of borrower data live, and for how long?
- Show us the path of a credit pull. Who holds the credentials at each hop?
- What happens to the file when a vendor errors mid-order?
- How is one lender’s deployment kept apart from another’s, and who can read which rows inside it?
These are the right questions. We answer them in the walkthrough by showing you the actual system. Bring your security team →