Security FAQ
Security FAQ: Bank-Owned Deployment Model
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)
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)
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
Last updated