Security

Executive Summary

This document outlines details of the security architecture, controls, and procedures implemented in Tunic Pay’s APP Prevent SDK and related backend infrastructure and services. The SDK, integrated into a banking application’s payment or payee management flows, securely gathers additional contextual information from end users and delivers dynamic prompts, warnings, and guidance related to potential fraud scenarios.

The security measures described here reflect Tunic Pay’s commitment to a strong security posture. The architecture aligns with our Information Security Policy and implements the controls and procedures detailed in our Business Continuity and Disaster Recovery Plans, which in turn support our ongoing SOC2 and ISO 27001 certification processes. By incorporating industry best practices and building with security-first principles, Tunic Pay ensures robust protection for sensitive financial data while enabling real-time fraud assessment.

Technical Architecture

Security Architecture

The Tunic Pay SDK implements a layered security architecture designed to protect data and ensure system resilience at every level:

1. Client Layer (SDK): Security and resilience of the SDK are paramount as the device is typically untrusted. Controls here focus on protecting data on the device, ensuring secure communication, and minimizing data transmission.
2. Communication Layer: Numerous controls are in place to prevent traffic from being observed and to prevent observed traffic from compromising data security.
3. Backend Services Layer: The backend services and databases are protected through a defense-in-depth approach applying security measures to all layers of the architecture.

The controls and mechanisms implemented at each layer are detailed below.

High Availability & Disaster Recovery

Tunic Pay’s infrastructure is designed with a 99.99% availability target. Comprehensive measures are in place to support resilience and rapid recovery. Key features include:

• Multi-region deployment: Services are deployed active-active across two regions and real-time data replication facilitates automatic failover.
• Multiple availability zones: Services within a region are load balanced among at least three availability zones.
• Backups and recovery: Regular automated backups are stored (encrypted) in at-least two geographically separate locations, with tested disaster recovery procedures.
• Audited, journalled change: All updates to our datastores are logged, timestamped and, where possible, accompanied with some user attestation allowing for point-in-time recovery and rollback.

Collectively these measures support 24-hour Recovery Time Objective (RTO) and Recovery Point Objective (RPO) (for pilots). We aim to triage and respond to incidents within 30 minutes during business hours.

Security Controls and Mechanisms

SDK Security Controls

The SDK implements multiple security controls to protect data and ensure secure communication.

Data Protection

The SDK takes various steps to minimize the risk of data compromise on an untrusted device. These include:

Encryption at rest: All data is encrypted using AES-256. Where available, platform-native secure storage is used (e.g. iOS Keychain, Android Keystore) alongside hardware security modules.

Encryption in transit: In memory, the SDK retains minimal sensitive data and does not access previous user sessions. Buffers which hold sensitive values are zeroed promptly after use.

Network Security

There are numerous mechanisms in place to secure network communication between the SDK and backend services. These protections are available both for users of Prevent Relay and for those connecting directly to the Tunic Pay API.

1. Mututal TLS (mTLS):

   Network communication between the SDK and backend APIs takes place over mTLS so that both client and server authenticate each other’s identity. This prevents malicious intermediaries from impersonating our servers to intercept data.

   Backend servers enforce TLS 1.2+ to ensure that communication is private and that strong cipher suites and up-to-date protocols are used. By default the client uses TLS 1.3 (all ciphers outlined in RFC 8446 are supported). If using TLS 1.2 (e.g. BYO Client, see below), only elliptic-curve ciphers are supported.

2. Certificate Pinning

   The SDK optionally supports pinning of server certificates or public keys. This provides an optional added mitigation for certain classes of attacks such as compromised certificate authorities.

   When enabled, the SDK will reject connections presenting certificates which do not match a configurable pinned value. We encourage pinning multiple keys in parallel around periods where certificates are due to be rotated (in this case the SDK gracefully degrades to secondary values if the primary value does not match).

   Customers using Prevent Relay manage their own certificates and can phase their rotation in line with expiration dates. For connections to the Tunic Pay API, Tunic Pay will provide at least 30 days notice of certificate rotation.

3. BYO Client

   Interfaces are available for the SDK’s host app to inject its own HTTP client. This allows for custom network security controls to be applied outside of the options supported by the SDK. Such injected clients must support the SDK’s baseline security requirements (e.g. TLS 1.2+).

4. BYO Server

   Customers are encouraged to use the Prevent Relay (currently available as a Java/Kotlin package) for full control over all user-facing network traffic and private backhaul to Tunic Pay. This allows for additional customer-managed security controls and logging/monitoring middleware and allows us to restrict traffic by VPC/CIDR range.

Application Security

At the application level, the SDK implements multiple security controls:

• Code obfuscation to hinder reverse-engineering efforts
• Root/jailbreak detection to prevent execution in compromised environments
• Secure random number generation for cryptographic operations

In future we plan to conduct regular penetration testing on the SDK to identify and address potential vulnerabilities.

Backend Security Controls

Perimeter Security

Tunic Pay’s backend services live behind a Web Application Firewall (WAF), and are hosted in a Virtual Private Cloud (VPC) with strict access controls. We limit which services and endpoints are exposed to the public internet, reducing the potential attack surface area in our public API. For customers using the Prevent Relay, we provide no public endpoints as all ingress is proxied through the customer’s infrastructure.

Within our VPC, services operate a zero trust policy and mutually authenticate all requests. This limits the potential for unauthorized access to our services in the unlikely event that perimeter security is breached or that any internal services are compromised.

Tunic Pay’s network is protected from DDoS and other malicious traffic patterns by a third-party provider (currently Cloudflare) to ensure that availability is maintained in the face of attacks.

In future we plan to deploy IDS/IPS systems to detect and block unusual access patterns within our network perimeter, and to perform regular penetration tests to validate our security controls.

Access Controls

Access to Tunic Pay’s systems is tightly controlled. By balancing strong authentication, granular authorization, and robust auditing, we prevent data from being exposed to unauthorized parties.

1. Authentication

   Backend systems are accessed by the SDK using mTLS to ensure that both ends validate identity. Optional certificate pinning adds an additional layer of trust.

   Integration options include OAuth 2.0/OpenID Connect and certificate-based for machine-to-machine communication. This ensures that the backend has a high degree of understanding of the identity of any client connecting to it.

2. Authorization

   Access to our systems is role-based and follows the principle of least privilege so that individual accounts are limited in their ability to access sensitive data.

   Tunic Pay operates a model of Zero Developer Access to Production (ZDAP), meaning that no employee has direct access to production systems beyond monitoring their health and providing support. Any access required for maintenance or support is granted on a temporary basis and subject to approval and monitoring. To prevent manual error from impacting service, no routine manual work is performed on production systems or data.

   Tunic Pay plans to conduct regular access reviews to ensure that long-lived permissions are appropriate and to audit temporary elevated privilege use.

3. Administrative Access

   All administrative systems require multi-factor authentication (MFA) to ensure that the damage from account compromise or unauthorized access is minimized and to provide a high degree of authorization confidence for any administrative activity.

Monitoring and Logging

Logs (and telemetry) are centrally collected from all running systems and services, and are encrypted in transit and at rest (though no sensitive data is recorded). This obviates the need for direct access to running systems, reducing the potential scope for security breaches or service impact from manual work.

Logs are maintained for a minimum of 60 days and audit trails are subject to review to support SOC2 readiness. Security events such as elevated access trigger alerts which automatically escalate to our support team so that they can be reviewed.

Data Flows and Protection Measures

The Prevent SDK and backend services maintain secure data flows throughout the user journey. Controls at each stage ensure data integrity, confidentiality, and security.

Data Flow overview

A notional journey through the APP Prevent flow

• Transaction Initiation & Validation: SDK validates the runtime environment, initializes secure storage, and prepares encryption keys before handling any user input.
• Data Minimization & Encryption: Only necessary transaction data is retained; sensitive fields not required for processing are discarded. Data is encrypted at rest (e.g. via platform-native secure storage) and encrypted again before transmission (AES-256, TLS 1.2+ or TLS 1.3 with mTLS).
• Secure Transmission: The SDK uses mTLS to ensure both client and server mutually authenticate. Certificate pinning is optional for additional security. Encrypted data is sent to the backend, where it is decrypted and processed.
• Result Generation & Return: Backend services evaluate user responses, generate results, and re-encrypt responses before returning them to the SDK. The SDK validates the integrity of responses and stores them securely until they are presented to the user or parent app.

Key Protection Measures

End-to-end encryption is maintained throughout the data flow, with keys stored and rotated using secure platform-native keystores and in accordance with best practices. This ensures that data is protected in transit and at rest.

Data minimization is a core principle to minimize the potential impact of data compromise. This is supported by regular security assessments, monitoring, and proactive improvement in line with industry best practices and in support of ongoing certification processes.

Change Management and Incident Response

Change management and incident response frameworks are embedded throughout the development lifecycle, ensuring that new features, updates, and fixes are introduced securely and that vulnerabilities can be effectively detected and remediated.

Secure Software Development Lifecycle (Secure SDLC)

All significant changes to the SDK and backend services undergo security review during planning/scoping stages. The development team receives regular security training and follows secure development guidelines to minimize the introduction of vulnerabilities.

All code changes are reviewed by a second developer and must pass numerous stages of automated and manual testing before reaching a production environment, including unit, integration, performance, and user acceptance tests. These industry best practices for secure development minimize change risk, and are additionally supported by vulnerability and container security scans and continuous security monitoring. Any vulnerabilities identified are triaged and handled according to our policies, which include the introduction of automated tests for future regressions.

All deployments are conducted automatically and accompanied with a rollback plan to ensure that any issues can be quickly addressed. Post-deployment validation checks are performed to confirm that changes are working as expected. Together, these measures ensure that changes are introduced securely and that the impact of changes on stability is minimized.

Incident Response

Tunic Pay operates a continuous improvement approach to incident management. We declare incidents proactively for all service degredations and conduct rigorous root-cause analysis to identify remediations and put in place automated tests or monitoring processes to prevent future regression.

We aim to triage and respond to incidents within 30 minutes during business hours (for pilots).

In future we plan to conduct regular incident response drills to ensure that our processes are effective and that our team is well-prepared to respond to incidents impacting both security and availability.

Compliance and Ongoing Improvements

Tunic Pay remains committed to continuous security enhancements and alignment with recognized standards.

• Working Towards SOC2 & ISO27001: Processes, policies, and controls are developed with these frameworks in mind, ensuring robust governance, risk management, and compliance.
• Continuous Monitoring & Third-Party Assessments: Alongisde automated vulnerability scans, we intend to conduct periodic penetration testing, and third-party reviews to validate our security posture and identify opportunities for improvement.

Conclusion

By integrating the APP Prevent SDK into banking applications and applying layered security measures across client, communication, and backend components, Tunic Pay protects sensitive financial data while delivering flexible, dynamic fraud prevention guidance. Coupled with a robust change management process, comprehensive incident response capabilities, and a roadmap towards SOC2 and ISO27001 certification, Tunic Pay maintains a strong, proactive security posture aligned with evolving industry best practices.

References

1. Information Security Policy
2. Business Continuity Plan
3. Disaster Recovery Plan
4. System Access Control Policy
5. Network Security Policy
6. Encryption Policy
7. Change Management Policy
8. Incident Response Plan