Everything you wanted to know
about us and our platform

Do you enforce HTTPS for all connections?

Yes. All web traffic is redirected from HTTP to HTTPS using 301 redirection. Additionally, HSTS (HTTP Strict Transport Security) is enabled to ensure browsers only communicate over secure channels. This prevents SSL stripping attacks.

What TLS versions are supported?

Only TLS 1.2 and TLS 1.3 are supported. Older versions like SSLv2, SSLv3, TLS 1.0, and TLS 1.1 are disabled due to known vulnerabilities like POODLE and BEAST.

Are SSL certificates auto-renewed and monitored?

Yes. Certificates are managed by ACM (AWS Certificate Manager) with auto-renewal and CloudWatch monitoring.

How do you prevent Cross-Site Scripting (XSS)?

We apply client-side and server-side protection including Angular’s sanitization, HTML escaping, and enforcement of Content Security Policy (CSP). Input fields are validated and encoded before rendering.

Is Content Security Policy (CSP) enforced?

Yes. CSP restricts the loading of scripts, styles, and other resources to our trusted domains. Inline scripts and eval() are blocked to mitigate XSS risks.

Do you allow i-frame embedding?

No. We set X-Frame-Options: DENY and also use frame-ancestors ‘none’ in CSP headers to prevent clickjacking.

How are session cookies secured?

Session cookies are marked as Secure, HttpOnly, and SameSite=Strict to prevent JavaScript access, man-in-the-middle interception, and CSRF.

How do you prevent Cross-Site Request Forgery (CSRF)?

CSRF tokens are issued per session and required for all state-changing HTTP methods (POST, PUT, DELETE). Tokens are validated server-side.

Are sensitive inputs protected from browser caching?

Yes. Fields like passwords and OTPs use autocomplete=”off”. Responses containing sensitive data are sent with Cache-Control: no-store, no-cache, must-revalidate. Sensitive data is also protected using payload level encryption over and above HTTPS.

Is MIME-type sniffing disabled?

Yes. X-Content-Type-Options: nosniff header is enabled to instruct browsers not to override the declared content-type.

Do you use strong cookie policies?

Yes. All cookies are domain-scoped, encrypted where applicable, and adhere to strict attributes (Secure, HttpOnly, SameSite).

How is error handling secured in production?

Client-facing errors are generalized (e.g., “Invalid request”). Detailed stack traces and logs are securely stored on the backend with access controls.

Is local storage or session storage used for sensitive information?

No. LocalStorage and SessionStorage are never used to store PII, tokens, or credentials. Only non-sensitive preferences like theme or language are stored.

Are web responses protected from cache exposure?

Yes. Dynamic content (API responses with user data) uses Cache-Control: no-store. Static assets (JS, CSS) use long-term cache headers for performance.

How do you handle file uploads in the web interface?

File uploads are restricted by type (PDF, PNG, JPG) and size (<10MB). Files are virus-scanned, metadata is stripped and uploaded to a secure S3 bucket.

Is user input validated on both client and server side?

Yes. We apply format validation, length checks, and whitelist patterns. Inputs are escaped to prevent injection attacks (XSS, SQLi).

Do you strip server signature and version info?

Yes. All headers revealing the server info are removed. This limits information leakage about server infrastructure.

Are WebSocket connections secured?

Yes. All WebSocket traffic uses wss:// with TLS 1.2+. Idle connections timeout after 60 seconds to reduce misuse.

Is automated bot traffic controlled?

Yes. We deny access to common malicious User-Agents and rate-limit IPs using web servers and WAF rules. CAPTCHA can be enabled for forms if required. You can also enable MFA using SMS OTP

Are all APIs served over HTTPS?

Yes. All API endpoints are only accessible via HTTPS. TLS 1.2 or higher is enforced to prevent man-in-the-middle and protocol downgrade attacks.

How is authentication handled for APIs?

We support two types of APIs: user-level APIs and system-level APIs.

• User-Level APIs: Users log in using their username and password. We support multiple authentication mechanisms, including native (our own), LDAP, ADFS, and Azure AD. Upon successful authentication, an encrypted session token is generated and issued to the client. This token has a configurable expiry time and is stored in a secure, HttpOnly cookie .
• System-Level APIs: These APIs are used by other systems or services. Authentication is done using an API Key and API Secret. The client must compute an HMAC signature using the secret and timestamp, and send the key, signature, and timestamp in the header. The server validates the HMAC signature to authenticate the system client. APIs use HMAC-based authentication with API Key, Secret, Timestamp, and Signature.

How is API rate limiting implemented?

Rate limiting is enforced using web server and WAF to protect against brute force and denial-of-service attacks. Custom thresholds are applied per IP.

Are sensitive API responses cached?

No. API responses with sensitive data have Cache-Control: no-store, no-cache headers to prevent browser or proxy caching.

How is access to admin-level APIs controlled?

Role-Based Access Control (RBAC) is implemented at the API level. Only users with specific roles (Admin) can access administrative endpoints.

Are APIs protected from injection attacks?

Yes. All inputs are validated and sanitized. APIs are built using frameworks with ORM (like Hibernate) and parameterized queries.

Is input validation enforced at API level?

Yes. Input validation includes checks on length, type, format, and patterns to ensure compliance with expected values.

Are error responses from APIs sanitized?

Yes. API errors are returned with generic messages. Stack traces, internal logic, or sensitive data are never exposed in API responses.

How are tokens managed and secured?

Authentication tokens are generated using SHA-256, encrypted with AES, and stored in Redis with expiry. Tokens are HttpOnly and Secure in cookies or custom headers. Tokens have a fixed expiry duration per client type (web, mobile) and are invalidated on logout or inactivity.

Is CORS handled securely for APIs?

Yes. Cross-Origin Resource Sharing (CORS) headers are configured to allow only specific domains to access APIs. Preflight (OPTIONS) requests are restricted.

Is versioning supported in the API?

Yes. All APIs are versioned (e.g., /v1/, /v2/) to ensure backward compatibility and safe rollout of new features.

Are APIs protected from unauthorized IP access?

Yes. IP whitelisting is available for sensitive endpoints and admin APIs. Unauthorized IPs receive 403 Forbidden.

Are file upload APIs secure?

Yes. File APIs validate MIME types, scan content, restrict file size, and do not allow execution of uploaded content.

How are mobile-specific APIs protected?

Mobile clients have unique ClientID’s. OTP-based endpoints include hash validation. Expiry, retry limits, and device fingerprints are used for protection. Mobile clients also have API key/secret and need to send the HMAC signature to server.  So we authenticate first the client using HMAC signature and then user using username/password

Are outbound API calls authenticated?

Yes. Outbound calls (e.g., to bank APIs) use their own authentication mechanism and API contracts. These calls go out of infrastructure via Network Firewall and Proxy.

How often are APIs audited?

All APIs undergo annually VAPT (Vulnerability Assessment and Penetration Testing) and code review to ensure compliance with OWASP API Security Top 10.

How is data secured in transit?

All data in transit is secured using HTTPS with TLS 1.2 or higher. This ensures protection from man-in-the-middle and downgrade attacks. Additionally, for sensitive operations, we use payload-level encryption: critical fields (e.g., PAN, mobile numbers, tokens) are encrypted at the application layer using RSA public key encryption before transmission. This dual-layer security ensures confidentiality even if the transport layer is compromised. Yes. All API endpoints are only accessible via HTTPS. TLS 1.2 or higher is enforced to prevent man-in-the-middle and protocol downgrade attacks.

How is sensitive customer data (PII) protected during transmission and storage?

We use a layered approach to protect customer PII during transmission and storage. Payload-level encryption is applied in addition to HTTPS to ensure that both request and response bodies are encrypted in transit. At the application level, data is encrypted before being stored in the database, ensuring even DBAs cannot view it. Standard AWS encryption at rest is also enabled for MySQL, S3, Redis, and OpenSearch.

Is data encrypted at rest?

Yes. All sensitive data is encrypted at rest using AES-256 encryption. This applies to structured data (MySQL), unstructured data (S3), and in-memory storage (Redis). We use KMS for key management.

How is key management handled?

We use AWS KMS (Key Management Service) for storing, rotating, and auditing encryption keys. Customer-specific keys are used when applicable.

Are files stored securely in S3?

Yes. Files stored in S3 are encrypted using AWS S3 Server-Side Encryption (SSE-S3) or KMS-managed keys (SSE-KMS), depending on data sensitivity.

Are credentials stored securely?

Yes. Passwords are hashed using AES 256 with a unique salt. API secrets, SMTP credentials, and other sensitive configs are stored encrypted in AWS Secrets Manager.

Is Redis data encrypted?

Yes. Redis data is encrypted both in transit (TLS enabled) and at rest using KMS-managed keys. PII data stored in Redis is encrypted using application level AES encryption.

Are backups encrypted?

Yes. All full and incremental backups are encrypted with AES-256 using AWS Backup and stored securely in S3 with versioning and access control.

Is access to sensitive data controlled?

Yes. Access is restricted by IAM roles and network-level security (VPC, security groups). Only authorized services and personnel can access encrypted datasets.

Is audit logging enabled for data access?

Yes. Data access and modification logs are captured using AWS CloudTrail and RDS logs. Logs are immutable and retained per compliance requirements.

How is sensitive data handled in logs?

Sensitive fields (PAN, mobile, PII) are masked or excluded in application logs. Logs are stored in encrypted storage with limited access.

Do you support field-level encryption?

Yes. PII data stored in MySQL is encrypted using application-level encryption.

Is data classification used to determine encryption strategy?

Yes. Data is classified as public, internal, confidential, or sensitive. Encryption levels and access policies are applied accordingly.

Can users download sensitive data?

Only authorized roles with download permissions can access export features.

Are deleted records recoverable?

Yes. S3 versioning and RDS point-in-time recovery allow restoration of deleted records within the retention window. In case companies have preferred purging option, in that data is not recoverable as its permanently deleted.

How often is data security reviewed?

Data encryption, key management, access logs, and secrets storage are reviewed quarterly as part of VAPT and compliance audits.

What encryption technologies are used?

We use both symmetric and asymmetric encryption:

• AES 256 is used for application-level encryption via AWS KMS
• RSA 2048 is used for payload-level encryption
• We also support Bring Your Own Key (BYOK) for enterprises that wish to use their own keys

Do you follow an enterprise-grade AWS architecture?

Yes. We follow an enterprise multi-account architecture using AWS Control Tower. It includes separate accounts for network, application, and shared services to enforce security boundaries and governance.

How is the master account used in Control Tower?

The master (management) account is used to define and enforce organization-wide policies, user provisioning, billing, and account lifecycle management through AWS Organizations and Service Control Policies (SCPs).

What is the role of the network account?

The network account contains the internet-facing infrastructure, including public Application Load Balancers (ALBs), NAT Gateways, Internet Gateways, and AWS Network Firewall. It also hosts the VPN termination and Bastion host.

How do developers or administrators access the infrastructure?

Access is granted through a Bastion Host in the network account. Users connect over a secure VPN from their laptops, which then allows access to private VPCs in application accounts.

How are multiple VPCs interconnected?

We use AWS Transit Gateway for scalable, transitive connectivity between private VPCs across different accounts. This enables central control and monitoring of east-west traffic.

How is the application VPC structured?

Each application account contains a private VPC with a layered architecture—Web, Application, and Database subnets. Subnet isolation and access control are enforced using NACLs and Security Groups.

What traffic controls are implemented within the application VPC?

Internal traffic is strictly controlled using Network ACLs (NACLs) and EC2-level Security Groups. Each layer (Web/App/DB) has its own policy.

Are public-facing components segregated from backend systems?

Yes. Public-facing services such as ALBs reside in the network account. Backend systems like EC2, RDS, and ElastiCache are hosted in private subnets within the application VPC.

How is intrusion detection and prevention handled?

The Network Firewall in the network account includes Intrusion Detection and Prevention Systems (IDS/IPS) to monitor and block malicious traffic.

Is IAM access centrally controlled?

Yes. IAM users, roles, and permissions are centrally managed from the Control Tower management account using AWS SSO or IAM Identity Centre.

Are Security Groups and NACLs reviewed periodically?

Yes. All Security Group rules and NACLs are regularly reviewed and audited to ensure least-privilege and deny-by-default configurations.

Are resources automatically discovered and tagged?

Yes. AWS Config and custom tagging policies are used to discover, categorize, and monitor all infrastructure resources.

How is network segmentation maintained across environments?

Separate Transit Gateway route tables and subnet isolation are used to segregate development, staging, and production environments.

Are network logs captured and monitored?

Yes. VPC Flow Logs, Transit Gateway logs, NAT Gateway logs, and ALB access logs are all enabled and streamed to CloudWatch and S3.

Are patch updates automated in the infrastructure?

Yes. EC2 instances are patched using AWS Systems Manager (SSM) Patch Manager. Notifications and patch reports are enabled.

Is DNS centrally managed?

Yes. Route 53 is used for DNS management across all accounts. Hosted zones and routing policies are centrally managed.

Is S3 access controlled from private VPCs?

Yes. S3 buckets use VPC endpoints and bucket policies to ensure access only from authorized VPCs or IAM roles.

How are Load Balancers secured?

All ALBs and NLBs enforce HTTPS with TLS 1.2+, WAF rules, and are integrated with Shield and CloudFront if needed.

Are internal service communications encrypted?

Yes. All communications between microservices and AWS-managed services use TLS and authentication via IAM roles or service-linked roles.

How is compliance enforced across AWS accounts?

Service Control Policies (SCPs), AWS Config, and Security Hub are used to continuously enforce compliance with organizational standards and security baselines.

How do you protect against accidental data deletion?

We have implemented multiple safeguards across key services to prevent and recover from accidental deletions:

• S3: Versioning is enabled on all S3 buckets, allowing recovery of overwritten or deleted objects. Additionally, S3 Object Lock and lifecycle policies are used to enforce retention where required.
• MySQL (RDS): Automated daily snapshots and point-in-time recovery (PITR) are enabled to restore databases to a specific moment before deletion or data corruption.
• ElastiCache: Backup and restore mechanisms are in place. Daily backups are retained and monitored to allow recovery of Redis/Memcached instances if needed.

How is customer data isolated in a multi-tenant setup?

We implement strict logical data isolation between tenants. Access controls, separate encryption key and proper authorizations ensure that no cross-tenant data access is possible.

How does the platform ensure high availability?

We follow a multi-AZ and multi-region architecture. All critical data services are multi-AZ enabled. Compute resources (EC2) and load balancers (ALB) are distributed across availability zones to ensure continuous availability even during failures.

Internal Security Process

How do you ensure ongoing security and risk management?

We follow a formal risk management lifecycle that includes monthly and quarterly security checklists, regular vulnerability assessments, and periodic third-party penetration testing. Risk findings are tracked and mitigated under structured remediation plans.

How is access to production environments managed and audited?

Access to production is strictly controlled using:

• Role-Based Access Control (RBAC)
• Multi-Factor Authentication (MFA)
• VPN-based Bastion Host Access

What measures are in place to prevent insider threats and manage third-party risks?

We implement:

• Detailed access logging and monitoring
• Secure code review processes
• Enforcement of NDAs for vendors
• Strict third-party vendor evaluations before onboarding

How is secure software development (SSDLC) practiced?

We follow a DevSecOps-based SSDLC that includes:

• Threat modelling during design
• Static and dynamic code analysis during build
• Secure coding standards and checklists

How is the platform tested for vulnerabilities?

Yes, both manual and automated testing are performed:

• Manual: Periodic VAPT (Vulnerability Assessment & Penetration Testing) by certified third-party security agencies
• Automated: Continuous scanning using tools like AWS Inspector to find vulnerabilities
  All issues are triaged and resolved under strict timelines.

How is continuous security ensured across all systems?

We adopt a continuous security approach including:

• Real-time threat detection using AWS GuardDuty
• Event correlation and alerting using AWS Security Hub and CloudWatch
• Web traffic inspection via AWS WAF and Network Firewall
• Regular patching of OS, containers, and libraries based on CVE severity

How do you monitor the platform and respond to incidents?

We use:

• AWS CloudWatch for logs and metrics
• Prometheus for custom metric monitoring
• 24×7 incident response support team
• Automated alerting, escalation matrix, and post-incident RCA reporting

What security frameworks and best practices do you follow?

We follow OWASP Top 10 guidelines for application security. For infrastructure security, we rely on AWS-native services such as:

• AWS WAF
• Security Groups
• AWS Guard Duty
• AWS Security Hub
• AWS Inspector
• AWS Network Firewall

What internal processes are in place to ensure ongoing security and risk management?

We maintain both monthly and weekly security checklists. Regular vulnerability assessments are conducted. A formal risk management lifecycle is followed, and periodic penetration testing is performed by certified external security agencies.

What measures are in place to protect against insider threats and third-party risks?

We perform code reviews, maintain detailed access logs, and enforce strict policies such as employee NDAs and vendor security evaluations. We also implement zero standing access for production environments, granting access only when absolutely necessary.

How do you ensure comprehensive security testing across the platform?

The platform is used by 20+ banks, each conducting its own VAPT, code scan, and security audit.
Additionally, the product complies with central bank (RBI) cybersecurity guidelines and undergoes regular reviews by InfoSec teams.
This ensures continuous hardening and extensive test coverage beyond typical SaaS benchmarks.

Can you share your SLA for uptime and support?

We offer 99.99% uptime SLA and provide 24×7 support. Our escalation matrix, incident response times, and root cause analysis (RCA) reports are shared as per the SLA agreements with customers

How do you manage continuous security of systems and respond to threats?

We follow a continuous security management approach across all environments. This includes:

1. Regular patching of OS, libraries, and containers based on CVE severity
2. Real-time security event monitoring via AWS-native tools like:
   
   • WAF (Web Application Firewall)
   • Guard Duty (threat detection)
   • Security Hub and CloudWatch for event correlation and alerting
   • Network Firewall for traffic inspection