Vendor assessment and third-party risk

What access controls does Aaim implement to protect institutional data? How is privileged access managed, and what authentication mechanisms are required?

Role-based access control (RBAC) enforces the principle of least privilege across all platform services. Institutional partners configure their own role hierarchies and permission sets through the administrative portal. Multi-factor authentication is required for all administrative access. Privileged access to production infrastructure requires additional approval workflows with time-limited access grants. All access events are logged in an immutable audit trail with actor identification, timestamp, resource accessed, and action taken. Session management includes configurable timeout policies per institutional partner. Service-to-service authentication uses mutual TLS with certificate rotation. API authentication uses short-lived tokens with institution-scoped claims.

What are Aaim's business continuity and disaster recovery capabilities? What are the defined RTO and RPO targets, and how frequently are recovery procedures tested?

The platform operates on multi-region cloud infrastructure with automated failover capabilities. Recovery Time Objective (RTO) is 4 hours for critical systems; Recovery Point Objective (RPO) is 1 hour. Database replication provides near-real-time data synchronization across availability zones. Automated backup procedures execute on defined schedules with backup integrity verification. Disaster recovery procedures are documented and tested annually with results available for institutional partner and examiner review. The business continuity plan covers personnel continuity, communication procedures, vendor dependency management, and return-to-normal-operations procedures. Critical system dependencies are identified with defined alternatives for each single point of failure.

What regulatory compliance frameworks does Aaim align with? How does Aaim support institutional partners in meeting their own regulatory obligations?

Aaim maintains alignment with SOC 2 Type II Trust Services Criteria (certification in progress, targeting Q2 2026), FFIEC IT Examination Handbook, OCC Bulletins 2011-12 (Model Risk Management) and 2013-29 (Third-Party Risk Management), NCUA Letter 18-CU-03, GLBA Safeguards Rule, CCPA/CPRA, FCRA, ECOA, and BSA/AML compliance support infrastructure. True Lender compliance is achieved through structural separation satisfying all 50 state frameworks. Platform architecture supports institutional compliance through audit trails, regulatory reporting infrastructure, examiner-ready documentation, and configurable compliance workflows. Documentation packages are available for examiner review and can be tailored to specific regulatory inquiry scope.

How does Aaim handle, store, and process institutional member data? What data classification framework is used, and what controls exist for each classification level?

Aaim processes institutional member data exclusively on behalf of and under the direction of the partner institution. Data is classified into four tiers: public, internal, confidential, and restricted. Nonpublic personal information (NPI) and personally identifiable information (PII) are classified as restricted and subject to the highest control requirements including encryption at rest (AES-256), encryption in transit (TLS 1.3), access logging, and tenant-level logical isolation. All data processing purposes are defined in the Data Processing Addendum. No cross-tenant data access, analytics, or commingling occurs at any layer. Data retention periods are configurable per institutional partner policy with automated purge workflows for expired data.

What encryption standards does Aaim use for data at rest and in transit? How are encryption keys managed, rotated, and protected?

Data at rest is encrypted using AES-256. Data in transit is protected by TLS 1.3 for all external communications and mutual TLS for internal service-to-service communication. Key management follows NIST SP 800-57 guidelines with hardware security module (HSM) protection for critical key material. Encryption keys are rotated on a defined schedule with automated rotation procedures. Database encryption uses transparent data encryption at the storage layer. Application-level encryption is applied to sensitive fields including SSN, account numbers, and identity verification documents before storage. Backup data is encrypted with separate key hierarchies from production data.

What incident response procedures does Aaim maintain? What are the notification timelines for security incidents affecting institutional partner data?

Documented incident response procedures define classification criteria, escalation paths, containment procedures, and communication protocols. Security incidents are classified by severity (critical, high, medium, low) with defined response timelines for each level. Institutional partners receive notification of confirmed security incidents affecting their data within 72 hours, consistent with regulatory expectations and contractual commitments. Critical incidents trigger immediate notification through pre-established communication channels. Post-incident review procedures include root cause analysis, remediation tracking, and lessons-learned documentation. Incident response procedures are tested through tabletop exercises and simulated incident scenarios. Public incident timeline is maintained on the Trust Center for transparency reporting.

What insurance coverage does Aaim maintain? Are coverage levels sufficient for the services provided to financial institutions?

Aaim maintains commercial insurance coverage including general liability, professional liability (errors and omissions), cyber liability, and technology errors and omissions. Coverage levels meet or exceed standard requirements for technology service providers serving regulated financial institutions. Certificates of insurance are available to institutional partners and prospective partners under NDA. Coverage is reviewed annually and adjusted as the business scales. Insurance carrier ratings meet minimum financial strength requirements. Additional insured endorsements are available upon request as part of institutional partnership agreements.

Does Aaim use subcontractors or sub-processors for data processing? How are subcontractor relationships managed and how are institutional partners notified of changes?

Aaim uses cloud infrastructure providers (Google Cloud Platform) and select third-party services for specific platform capabilities. All sub-processors are documented in the Data Processing Addendum with their processing purpose, data categories handled, and geographic location. Institutional partners are notified of material changes to sub-processor relationships within contractual timeframes, including additions, removals, or changes in processing scope. Sub-processors are subject to contractual data protection obligations consistent with the commitments made to institutional partners. Periodic assessment of sub-processor security posture is conducted for critical vendors, with results factored into ongoing risk management procedures.