Security and compliance architecture for lenders who answer to examiners.
Prism Layer is designed with the controls your security team, model risk committee, and examiners will ask about. This page covers our data handling, access controls, model governance posture, and compliance alignment.
Tenant isolation
No cross-tenant data access. Logical isolation at the data layer.
SOC 2-designed
Controls designed with SOC 2 Type II principles in mind.
SR 11-7 posture
Model documentation aligned with Fed SR 11-7 guidance.
Data Handling
Tenant isolation is enforced at the data layer — no model training data from one lender is used for another. Application data submitted for decisioning is retained for 90 days post-decision and is fully deletable on request. Encryption at rest uses AES-256. All data in transit is protected by TLS 1.3. No application-level data is stored in external third-party analytics tools without a documented data processing agreement.
Access Controls
Role-based access control (RBAC) is enforced at the API and application layer. SSO/SAML integration is available at the Professional and Enterprise tiers. Multi-factor authentication (MFA) is enforced for all user accounts. Row-level access controls support multi-branch lending institutions where different teams should see different segments of the origination population. Every API call and every Rules Studio policy change is written to an append-only audit log.
Model Governance Posture
All model artifacts — scoring model versions, feature definitions, threshold parameters — are version-controlled. When a challenger model runs in Shadow Mode, it operates read-only: it receives a copy of live application data but writes only to the analytics store, never to the LOS or production decision record. This is a foundational design principle, not a configuration flag. SR 11-7-aligned model documentation packages are available on request at the Enterprise tier.
Compliance Posture
Prism Layer is designed with the SOC 2 Type II controls catalog as design reference. We do not claim current SOC 2 certification — we are a bootstrapped company in early operation and have not yet completed a SOC 2 Type II audit. What we can represent: our architecture was designed from the beginning with the Trust Service Criteria as a guide, and we will complete an independent audit as we scale. On model governance: we ship the documentation and shadow-mode infrastructure a model validation team needs to work with SR 11-7 guidance — we are not claiming SR 11-7 model validation certification, which is an audit outcome, not a product feature. ECOA/Reg B adverse action output is native — every decision includes a ranked factor list mapped to statutory adverse action codes. GLBA data handling practices are aligned with the requirements applicable to our role as a service provider. Annual penetration testing by a third-party firm is our standard practice.
Request a security overview for your vendor due diligence.
We provide a security overview document, data flow diagram, and third-party penetration test summary for qualified lenders completing vendor due diligence. Use the contact form to request access.