Pulse
Security

Financial data protected by layered, tenant-aware controls.

FinQ Pulse is designed for regulated financial data: application infrastructure in AWS Frankfurt, encryption in transit and at rest, strong authentication, role-based access, database-enforced isolation and a detailed audit trail.

AWS Frankfurt region Tenant isolated MFA protected
Application data location

Application data hosted in AWS Frankfurt.

FinQ Technologies and Consulting is registered in the Republic of Armenia. FinQ Pulse application data is hosted in AWS eu-central-1, Frankfurt, Germany; the hosting location does not represent the company’s place of registration.

AWS REGIONeu-central-1Frankfurt, DE
01 · ENCRYPTION AT REST

Infrastructure encryption plus application field encryption.

The production AWS architecture encrypts PostgreSQL storage with AWS KMS and object storage with server-side KMS encryption. FinQ Pulse also encrypts restricted values before they reach the database.

  • Fernet envelopes for parsed upload data and computed scenario outputs
  • Encrypted MFA secrets
  • MultiFernet key-rotation support
  • SHA-256 integrity fingerprints for uploads and generated reports
02 · ENCRYPTION IN TRANSIT

TLS across external and internal transport paths.

The production configuration redirects HTTP to HTTPS, uses a TLS 1.2/1.3 policy at the application edge and requires encrypted connections to PostgreSQL. Redis transport encryption is enabled in the AWS architecture.

  • HSTS security header in the application policy
  • Secure, HttpOnly, SameSite session cookies
  • Database connections configured with sslmode=require
  • TLS required between the application and database proxy
03 · IDENTITY AND ACCESS

Authentication and authorization aligned to defined institutional roles.

Passwords are stored as bcrypt hashes. Time-based one-time-password MFA is required for privileged roles and can be enforced for all users through tenant policy.

  • Roles: analyst, risk manager, CRO, administrator and auditor
  • Eight-hour absolute session lifetime in the current policy
  • Login rate limits and account lockout controls
  • CSRF protection and server-side Redis sessions
04 · TENANT ISOLATION

No data sharing between institutional tenants.

Tenant isolation is enforced in more than one layer. The application binds a tenant identifier to the database transaction, PostgreSQL applies forced row-level security, and object storage keys are prefixed by tenant.

  • Forced RLS on tenant-owned operational tables
  • Safe default when tenant context is absent
  • Tenant-scoped database connections for application queries
05 · AUDITABILITY

Operational and approval history with traceable context.

The audit log captures security-relevant events and workflow actions with tenant, user, resource, IP address, user agent, timestamp and correlation context. Sensitive keys in audit payloads are redacted.

  • Scenario creation, updates, transitions and deletion events
  • Authentication and MFA events
  • Full workflow comment and state history
  • Engine version, input hash and output hash for scenario runs
Defense in depth

Controls remain effective even when one layer is bypassed.

Application authorization does not stand alone. Database policies independently constrain rows, sensitive analytical fields are encrypted before storage, and report generation is gated by workflow state.

01Identitybcrypt · TOTP MFA · sessions
02ApplicationRBAC · CSRF · rate limits
03DataFernet · RLS · checksums
04InfrastructureFrankfurt · KMS · TLS

Security diligence

The controls described here reflect the current FinQ Pulse application and infrastructure code. They do not imply a certification or independent audit that has not yet been completed. Detailed technical review materials can be shared during a qualified pilot discussion.

Start a security review