Security FAQ

Security and compliance handbook for bank-owned deployments.

Overview

• The Security & Compliance Handbook is the definitive guide for technical auditors and security teams.

• It provides a deep dive into the platform's security architecture. This includes row-level permissions, SOC-2 adherence, multi-cloud deployment across AWS, GCP, and Azure, data residency, and private tenancy.

• Use this handbook to confidently integrate Uptiq within highly regulated environments.

Security posture

• 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.

Frequently asked questions

A. Deployment Architecture & Data Residency

Q1. Where are the AI Agent runtime and transactional database hosted?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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.

Retention policy

This standard policy covers document and database storage in 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.

Document storage

Storage types: S3, File Store, and 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

Database storage

Database types: RDS, MongoDB, and 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