A capability of frIdA.
Data residency, encryption posture, access controls, audit surface, subprocessor disclosure, and regulatory alignment. Everything a compliance committee needs to evaluate Saptiva AI against its existing control framework - stated plainly, including what we do not yet have.
The security posture a customer experiences depends on how their deployment is configured against their policy - not on a fixed property of the platform. A customer running in air-gapped mode has a materially different security envelope than a customer running in public cloud. Both are valid. The platform is the same in each case; the controls that bind it are different.
Everything on this page describes capability. Which capabilities are engaged in a specific deployment is determined by the customer's configuration, applied by frIdA, and reflected in the audit record. Compliance committees evaluating Saptiva AI should read this document alongside the specific deployment configuration proposed for their environment - not as a substitute for it.
Residency is enforced by architecture, not by trust. Each data class is assigned the environments it may run in. frIdA routes accordingly and records the route. The customer defines the classes.
Residency satisfied by architecture. In-country regions and on-premises, inside Mexico.
In-market deployment at MultiMoney. On-premises and private cloud.
Air-gapped deployments for critical infrastructure and the most sensitive financial workloads.
For deployments where residency is a defining requirement, we publish the physical region, the legal jurisdiction, and the contractual residency commitment in the customer agreement. The claim on this page is not the commitment. The commitment is in the MSA.
SAML 2.0 and OIDC. Integrates with the customer's directory (Active Directory, Okta, Azure AD). Saptiva AI does not maintain a separate identity provider for production users of customer deployments.
Roles defined in the customer's directory and configuration. frIdA enforces role → capability mapping on every dispatch. Access decisions appear in the audit record with the role and justification captured.
Application access is scoped to the specific capability needed for the task. A credit officer's copilot session does not see KYC data unless explicitly permitted.
MFA required for administrative access and for production workloads touching regulated data. Enforcement tied to the customer's directory policy.
Saptiva AI personnel do not have standing access to customer production data. Operational intervention requires customer-authorized, time-bounded access tied to a specific incident or work order, with full session audit.
Configurable by the customer. Defaults follow banking-grade expectations. Re-authentication required for privileged operations regardless of session state.
Every frIdA dispatch produces a signed, immutable audit record. The record captures what model ran, on what data, under which configuration version, authorized by which identity, and with what outcome. It is the object a regulator, internal audit, or post-incident investigation examines - not a log file, but a structured record.
We name an authority here only where a workload is running under it today. Everything else is architecture, and architecture is on the rest of this page.
Saptiva AI does not yet hold a completed SOC 2 Type II attestation. We are in the formal readiness and assessment phase with a qualified assessor. We expect completion in the current fiscal year and will publish the attestation date when it is signed.
ISO 27001 is in scope for the following fiscal year. We intend to pursue it because our enterprise customers ask for it - not because it materially changes our production security posture, which is already governed by the controls on this page.
Policy authoring inside the platform and policy-based routing - a rule written once and applied on every route - ship next. Until they ship, routing is configured by your operators and every route is recorded. We say so here so it does not surface at procurement.
If your compliance framework requires a completed SOC 2 or ISO 27001 attestation before a vendor can be onboarded, we can share our current readiness artifacts under NDA and connect your compliance team with our security lead. We prefer to say so up front rather than have the conversation surface at procurement.
We hold the following operational certifications and alignments:
The subprocessor list depends on the deployment mode. Air-gapped deployments have no subprocessors. Public cloud deployments inherit the cloud provider as a subprocessor. In-country and on-premise deployments may or may not involve additional subprocessors depending on the customer's configuration.
For each customer engagement, we publish the active subprocessor list in the DPA and notify the customer in advance of any change. The canonical subprocessor list is available under NDA to prospective customers; active customers receive it as part of their DPA.
Our incident response posture is built around timely customer notification, joint technical response, and post-incident transparency. The specifics are governed by the MSA and DPA for each customer.
For security concerns, vulnerability reports, compliance questions from prospective customers' risk teams, or responsible disclosure - use the address below. It is monitored by our security lead and routed appropriately.
We will not pursue or support a claim against a researcher who acts in good faith. The conditions that define good faith are set out once, in section 011 of the Terms of Use, so that there is a single version of them.
For compliance questionnaires and DPA review from prospective customers, the same address applies.
A Forward Deployed Engineer and our security lead can jointly walk your compliance and security teams through the deployment proposed for your environment - tied to your specific regulatory framework and your existing control posture. Reply within 48 hours.