Security at Finality Labs

Last Updated: 30th April 2026

At Finality Labs Private Limited (“Finality”, “we”, “us”, or “our”), the confidentiality, integrity, and availability of our systems and of the data we process are core to our value proposition. This Security Statement describes the technical and organisational measures we use to protect our infrastructure and the information we handle in connection with our USDT ↔ INR and broader crypto ↔ fiat rails for professional operators.

This Security Statement is not a guarantee of absolute security, but a summary of our current practices. We continually review and improve these controls, including in light of evolving regulatory expectations in India, the United Arab Emirates (Dubai), and Singapore.

1. Governance and regulatory alignment

We design our technology and security controls with reference to recognised industry standards and regulatory guidance, including:

• India’s emerging expectations around technology and cyber resilience for financial‑sector and VDA‑related activities.
• Dubai/UAE virtual asset and VASP cybersecurity and technology rulebooks (including VARA expectations around key management, transaction monitoring, and penetration testing, where applicable).
• Singapore’s MAS Technology Risk Management (TRM) Guidelines and related guidance for digital‑asset and payments infrastructure providers.

Security and risk management responsibilities are embedded in our engineering and operations leadership functions, with clear escalation paths and board‑level visibility for significant incidents or structural risks.

2. Infrastructure and network security

• Our core systems are hosted on reputable cloud infrastructure providers that offer robust physical security, network segmentation, and built‑in security tooling.
• We implement layered network security controls, including firewalls, restricted security groups, and network‑level access controls to limit exposure of management interfaces and internal services.
• Administrative access to production environments is tightly controlled, logged, and restricted to authorised personnel on a least‑privilege, need‑to‑perform basis.
• We deploy monitoring and alerting on critical infrastructure components to detect unusual activity, performance anomalies, or potential intrusions in a timely manner.

3. Data protection and encryption

• Encryption in transit: Data transmitted between our systems and to supported browsers or APIs is protected using modern transport‑layer encryption (such as TLS) to mitigate interception and tampering risks.
• Encryption at rest: Where feasible and appropriate, we use strong encryption for stored data at rest, leveraging cloud‑native or application‑level encryption controls.
• Segregation and minimisation: We implement logical separation of environments (development, staging, production) and apply data‑minimisation principles, collecting and retaining only the information reasonably necessary for our B2B operations and regulatory obligations.

We do not provide retail wallets or hold client crypto assets on behalf of end users; where we interact with keys or signing infrastructure in institutional contexts, we design controls to avoid unnecessary key exposure and to support the use of dedicated custody or key‑management solutions selected by our clients.

4. Access control and identity management

• Access to systems and data is granted on a least‑privilege basis, aligned with job responsibilities and reviewed periodically.
• Where technically supported, we use multi‑factor authentication (MFA) for privileged accounts and key administrative tools.
• We maintain role‑based access controls (RBAC) for internal systems and, where applicable, for operator‑facing portals to help ensure that only appropriately authorised users can perform sensitive actions.
• Access logs for critical systems are retained and monitored for indications of unauthorised or anomalous activity.

5. Application security and development practices

• Our engineering teams follow secure development practices, including code review, dependency management, and the use of automated tooling to identify known vulnerabilities in open‑source components.
• We seek to separate publicly exposed components from sensitive internal services, and apply input validation and other controls to reduce the risk of common web application vulnerabilities.
• Where required under local rules or by institutional partners (including Dubai VARA and MAS technology‑risk expectations), we support periodic vulnerability assessments and penetration testing by qualified independent providers, with remediation tracked according to severity.

6. Monitoring, logging, and incident response

We maintain centralised logging and monitoring for key systems and services, and use these logs to detect and investigate anomalies or potential incidents.

Our incident‑response approach is influenced by best practices for SaaS and financial‑sector environments and includes:

• Classification of incidents by severity and impact.
• Defined steps for containment, investigation, remediation, and recovery.
• Internal and external communication protocols, including communication with affected institutional clients and, where required, regulators or other authorities.

We periodically review and refine our incident‑response playbooks to reflect real‑world learnings and changes in threat patterns, including crypto‑specific risks such as key compromise, unauthorised transactions, and API abuse.

7. Vendor and third‑party risk management

• We rely on a limited set of third‑party providers for infrastructure, analytics, communications, and other supporting services.
• Before engaging key vendors, we assess their security posture through publicly available information, contractual commitments, and, where appropriate, additional due‑diligence questions or attestations.
• We include appropriate security and confidentiality provisions in our contracts with providers and review these relationships periodically.

Where our infrastructure integrates with or routes flows through external partners (such as liquidity, banking, or payment providers), those partners will operate under their own security, legal, and regulatory frameworks; our controls do not replace theirs, and we encourage institutional clients to conduct their own due diligence on all counterparties.

8. Organisational measures and training

• We maintain policies covering information security, acceptable use, access control, incident response, and data protection, which are periodically reviewed and updated.
• Staff and contractors with access to systems or data are subject to contractual confidentiality obligations and are expected to follow security and privacy requirements relevant to their roles.
• We provide awareness and training appropriate to the responsibilities of our personnel, including education around phishing, credential hygiene, and handling of sensitive data.

9. Shared responsibility and your role

Security is a shared responsibility between Finality and our institutional clients and partners. To help protect your operations:

• Use strong, unique passwords and enable multi‑factor authentication for any accounts or tools integrated with our infra, where supported.
• Restrict and review access rights for your users and teams.
• Protect API keys, credentials, and signing keys in secure systems, and avoid sharing them over insecure channels.
• Notify us promptly at [email protected] if you suspect unauthorised access, credential compromise, or any other security incident related to Finality’s systems or integrations.

Your internal policies, key‑management practices, and operational controls remain critical to the overall security of your crypto and fiat flows; our controls are designed to complement, not replace, your own obligations and frameworks.

10. Updates to this Security Statement

We may update this Security Statement from time to time to reflect changes in our systems, practices, or regulatory expectations. When we do, we will update the “Last Updated” date at the top of this page and may provide additional notice where appropriate.

For more information about how we handle personal data, please refer to our Privacy Policy; for use‑related terms and limitations, see our Terms of Service.