How to read this page. multipll is a pre-product seed-stage company. This page describes the security posture we have built into the platform, the controls we operate today, and the items that are on the path toward formal certification. We’d rather be specific and accurate than aspirational. Banks evaluating multipll should request our security questionnaire and architecture documentation directly.
On this page
1. Our approach
multipll handles two categories of sensitive information: business financial records on the borrower side, and confirmed credit-decision outcomes on the bank side. We design the platform around three principles:
- Least privilege by default. Every service, every operator, and every API call gets the minimum access required.
- Auditability over speed. Every credit-decision-relevant action is logged with the context needed to reconstruct it later. Decisions are reproducible.
- Per-institution isolation. Data is secured per institution and never shared across banks.
2. Data handling
Encryption in transit
All connections to the platform use TLS 1.2 or higher. Internal service-to-service traffic within our cluster is also encrypted. We use Cloudflare’s Full (Strict) SSL mode for public endpoints.
Encryption at rest
Customer data stored in our PostgreSQL databases and in our object storage is encrypted at rest using platform-managed keys. Database snapshots and backups inherit the same encryption.
Secrets management
Application secrets, API tokens, and database credentials are stored in Azure Key Vault and surfaced into workloads through the Azure Key Vault CSI driver. Secrets are not committed to source control. Operator access to secrets is logged.
Data minimization
We collect the data that is necessary to evaluate a credit profile. Credentials for third-party data sources (such as accounting systems and bank-statement aggregators) are held by the underlying aggregator wherever possible; we do not store bank login passwords.
3. Infrastructure
The platform runs on Microsoft Azure in a hardened production tenancy. Core components include:
- Azure Kubernetes Service for application workloads, with namespace isolation between platform components.
- Azure Database for PostgreSQL (Flexible Server, version 16) for the primary data store, with point-in-time recovery enabled.
- Azure Container Registry with private endpoints and image scanning.
- Cloudflare in front of all public traffic, with WAF rules and rate limiting on authentication endpoints.
Production infrastructure is separated from development and staging environments. Production database access is limited to a small, named set of operators; access is logged and reviewed.
4. Access controls
- Identity. Single sign-on through Azure Entra ID for operator access to production systems.
- Multi-factor authentication. Required for all operator accounts and recommended for customer accounts.
- Role-based access. Operator roles are scoped to the minimum needed (read-only by default; write access requires elevation and is time-bounded).
- Joiner / mover / leaver process. Access is provisioned at hire, reviewed when roles change, and revoked when an operator leaves or a contract ends.
5. Tenancy and data isolation
multipll is a multi-tenant platform with strict per-tenant scoping. The tenant_id for every request is derived server-side from a master organization lookup; it is never trusted from a client-side payload. Database queries are scoped by tenant at the application layer, and audit logs record the tenant context for every credit-decision-relevant action.
6. Secure development lifecycle
- Source code is hosted in private GitHub repositories with branch protection, required code review, and required CI checks before merge.
- Every change is reviewed by an engineer other than the author before it reaches the main branch.
- Deployments are automated through GitHub Actions and Helm; manual production access is limited and logged.
- Database migrations are reviewed and applied before any code that depends on them is deployed.
- Dependencies are scanned for known vulnerabilities; critical issues are patched promptly.
7. Monitoring and incident response
Production systems emit application logs, infrastructure logs, and audit events. We monitor for unusual access patterns, authentication failures, and anomalous query volumes. When we detect a potential incident, we follow a documented response playbook: contain, investigate, remediate, communicate with affected customers, and conduct a post-incident review.
If we determine that a security incident has resulted in unauthorized access to customer data, we will notify affected customers without undue delay and in accordance with applicable law.
8. Reporting a vulnerability
We welcome reports from security researchers. If you believe you have found a vulnerability, please email admin@multipll.com with a clear description and reproduction steps. We commit to:
- Acknowledging your report within three business days.
- Working with you in good faith to understand and remediate the issue.
- Not pursuing legal action against researchers who follow this process and act in good faith (no data exfiltration, no disruption of service, no access to data beyond what is needed to demonstrate the issue).
9. Compliance roadmap
We are not yet certified under SOC 2, ISO 27001, or similar third-party frameworks. As we move toward production deployments with partner banks, we are building out the controls, evidence, and documentation required for SOC 2 Type II readiness. Banks and customers can request our current security questionnaire, architecture documentation, and data-flow diagrams under NDA at admin@multipll.com.
10. Contact
Security reports and questions: admin@multipll.com
Privacy questions: admin@multipll.com
Everything else: founders@multipll.com