> For the complete documentation index, see [llms.txt](https://docs.uptiq.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.uptiq.ai/security-and-compliance/detailed-security-and-runtime-faq.md). # Security FAQ Building fast shouldn't mean looking over your shoulder. At Qore, we believe that sovereignty is the ultimate feature. That’s why we’ve engineered a "Fortress-First" architecture that places the entire AI runtime and transactional database directly inside your bank’s own cloud infrastructure. We don’t just "support" security; we give you total ownership of it. From AES-256 encryption at rest to automated PII masking that redacts sensitive data before it even hits a model, every layer of our platform is designed to pass the most rigorous technical audits with flying colors. The following FAQ provides the "under-the-hood" details your CTO and compliance teams need to verify that in the Uptiq ecosystem, your data never leaves your perimeter. #### A. Deployment Architecture & Data Residency **Q1.** Where are the AI Agent runtime and transactional database hosted?\ **A1**: Both the AI runtime and its databases (MongoDB Atlas / AWS RDS) are deployed entirely within the bank’s own cloud infrastructure. No traffic or data leaves the bank’s network boundaries. **Q2.** Does any data leave the bank’s cloud?\ **A2:** No. All runtime processing, inference, and database operations occur within the bank’s controlled VPCs. No external data transmission, logging, or telemetry is enabled by default. **Q3.** How is data residency ensured?\ **A3:** All components are provisioned in the bank’s designated regional data centers (e.g., AWS or Azure regions within the same jurisdiction), ensuring compliance with local data sovereignty laws. #### B. Access Control & Authentication **Q4.** How is database access managed?\ **A4:** Access is restricted using the bank’s IAM roles with least-privilege permissions. All connections are secured using TLS 1.2+ with IP allowlisting or private endpoints. **Q5.** Who has administrative access?\ **A5:** Only the bank’s internal administrators. Our deployment team receives time-bound, auditable access strictly for initial setup and support activities under written authorization. **Q6.** How are credentials stored and managed?\ **A6:** All credentials and API keys are stored using the bank’s Secrets Manager or KMS solutions. No secrets are hardcoded or stored in configuration files. #### C. Data Protection & Encryption **Q7.** Is data encrypted at rest and in transit?\ **A7:** Yes. Data is encrypted at rest using AES-256 and in transit using TLS 1.2+. These are implemented at the storage and transport layers respectively, ensuring end-to-end confidentiality. #### D. Model & Runtime Security **Q9.** Where are AI models hosted?\ **A9:** AI models are hosted on the bank’s Azure account and deployed in the same or peered VPC. No calls are made to external or public AI APIs. **Q10.** Can prompts contain confidential data?\ **A10:** Context validation and masking are built into the runtime to redact or exclude sensitive information such as customer identifiers or account details before model processing. #### E. Monitoring, Logging, and Auditability **Q11.** Can activities be audited?\ **A11:** Yes. All runtime and database activities can be logged and exported to the bank’s central SIEM or log management platform. Logging is configurable and disabled by default to prevent data exposure unless required. ## Standard Retention Policy for Document and Database Storage (North America) > Note: Archival is not enabled by default for document or database storage. The bank should define and provide its archival and retention policy during implementation. The platform offers full technical support for integrating and automating these retention policies once defined. ### 1. Document Storage (S3, File Store, DMS) | Category | Typical Retention | Rationale / Regulatory Basis | Recommended Implementation | | ----------------------------------------- | -------------------------------- | ------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------- | | **Customer / Loan Documents** | **7 years** post account closure | Aligns with FFIEC, OCC, SEC Rule 17a-4, CRA, and IRS recordkeeping | Use Object Lock (Compliance Mode) or immutable storage; configure lifecycle to move to Glacier after 1 year, delete after 7 years | | **Operational / System Logs (non-audit)** | **1–2 years** | Forensics & troubleshooting | Store in standard S3 class or log archive bucket with lifecycle deletion after 2 years | | Audit Logs/Security Events | **7–10 years** | Regulatory and internal governance (SOX, GLBA) | Immutable (WORM) storage with Object Lock; retention rule = 7-10 years | | **Temporary Uploads/Draft Attachments** | **30-90 days** | Data minimization and cleanup | Auto-delete after retention period using lifecycle or scheduler | ### 2. Database Storage (RDS, MongoDB, PostgreSQL) | Data Type | Typical Retention | Rationale/Reference | Recommended Implementation | | -------------------------------------------- | -------------------------------------- | --------------------------------------------------- | -------------------------------------------------------------------------- | | **Core transactional data** | **7 years** after relationship closure | IRS, OCC, FDIC, and Sarbanes–Oxley Act requirements | Partition or archive tables; automate purge post- retention | | **User accounts / authentication records** | **Active + 1 year post-deactivation** | Privacy and accountability | Soft-delete with periodic cleanup job | | **Model input/ output logs (AI/ analytics)** | **6–12 months (operational)** | Data minimization under GDPR/CCPA principles | Store in separate schema or S3; purge automatically after retention period | | **Configuration/metadata** | **Until decommissioning** | Required for reproducibility | Retain until system decommissioning or replacement | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.uptiq.ai/security-and-compliance/detailed-security-and-runtime-faq.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.