Borrower data is the whole job. We treat it that way.
Discloser touches live loan files, so the boundaries below are built into how the product works, not bolted on after.
Tenant isolation
Every company's data is separated at the database level with Postgres row-level security, enforced by the database and not just the app. Access is resolved per loan rather than per company: a single function decides which loans a user can reach, and the tables holding borrower data all answer to it.
Access and roles
Role-based access across super admin, company admin, and discloser. Super-admin “view as” a company is re-verified against the real user's role on every read, so a forged session cannot elevate itself.
Audit trail
Sensitive actions are written to an append-only audit log with the actor and timestamp. Credential decryption is itself audit-logged, recording which instance was used and never the secret. Borrower identity is stripped from audit entries by the database itself, so the trail records that a borrower field changed without recording what it said.
Credentials and borrower data
Vendor credentials are never stored as plaintext. We keep only vault secret IDs and decrypt server-side on demand. Webhook payloads are normalized to whitelisted, non-NPI fields, and raw payloads are never stored or forwarded. Borrower details (names, contact details, the property address) are stored only when you switch that on for your own instance, and only through fields we have explicitly mapped and typed. Wherever they are stored, the database limits them to the people who can reach that loan.
Infrastructure and diligence.
Discloser runs on SOC 2 Type II certified hosting and database providers, with data encrypted in transit and at rest. Need to review our architecture or run security diligence before you connect your LOS? That is exactly the conversation we want to have.