Security is an infrastructure concern.
Zopio designs enterprise financial infrastructure around explicit responsibility boundaries, controlled access, data protection, operational visibility, and provider independence. This page describes the security principles we can state publicly and how qualified customers can review additional architecture and security information during procurement.
Secure architecture
Systems are designed with clear service boundaries, controlled access, and least-privilege principles. Sensitive configuration and credentials are kept outside application code and managed through secured infrastructure controls. Security, resilience, observability, and change control are treated as infrastructure concerns rather than application-only features.
Deployment and responsibility boundaries
Zopio operates the technology and application layers that form part of the agreed Zopio service. Customers retain responsibility for the systems, users, business rules, and data they control, while connected banks, acquirers, payment service providers, and other financial institutions retain responsibility for the regulated services they provide.
Security is therefore a shared responsibility across Zopio, the customer, connected financial providers, and underlying infrastructure or service providers. The exact boundary depends on the products, integrations, deployment model, and commercial scope in use and can be documented during onboarding or security review.
Access and tenant boundaries
Zopio systems are designed around explicit authorization boundaries and least-privilege access. Administrative and operational access is limited to the access required for the relevant role and operational purpose.
Where customer-specific application data is processed, access and data separation are defined around the relevant tenant, account, and authorization context. The exact isolation model can vary by product and deployment architecture and can be reviewed for the proposed scope during an enterprise security review.
Data protection, retention and key responsibility
We aim to minimize the data required for each workflow and protect data in transit and at rest using industry-standard mechanisms provided by the underlying infrastructure and service providers.
Retention requirements depend on data type, service purpose, contractual scope, and applicable law. Encryption and key-management responsibilities likewise depend on the deployment and service configuration. We do not claim a specific customer-managed-key or key-ownership model unless it applies to the relevant deployment.
Operational security and incident handling
Logging, monitoring, error visibility, and controlled change practices are treated as part of production readiness. The objective is to identify issues quickly and reduce operational uncertainty in payment and financial workflows.
Security events are treated as operational incidents and are handled through defined triage, containment, investigation, remediation, and escalation steps. Customer communication and notification obligations depend on the nature of the incident, the applicable agreement, and legal requirements; we do not publish a universal notification time commitment that may not apply to every deployment.
Third-party infrastructure
Zopio relies on selected infrastructure and service providers for capabilities such as hosting, data storage, communications, and security-related operations. Those providers remain responsible for the services they operate, while Zopio remains responsible for how those services are selected, configured, and used within the Zopio service boundary.
Where relevant to a procurement or security review, information about material infrastructure or service-provider dependencies can be provided for the proposed deployment, subject to confidentiality and contractual constraints.
Funds and processing
Zopio provides financial technology infrastructure and does not hold, receive, or settle customer funds. Payment processing and settlement are handled by licensed banks, acquirers, and payment service providers.
Enterprise security review
Qualified customers can request additional security and architecture information during procurement or technical due diligence. The material provided depends on the proposed products, deployment model, data flows, and confidentiality requirements.
Where relevant and available for the proposed scope, a review may include:
- architecture and deployment-boundary information;
- shared-responsibility and data-flow documentation;
- access-control and tenant-isolation information;
- encryption, key-management, retention, and deletion responsibilities;
- logging, monitoring, incident-handling, and operational-control information;
- material infrastructure or service-provider dependencies; and
- independent security evidence where such evidence has been verified and applies to the relevant service.
Not every artifact applies to every product or deployment, and sensitive security material may require an NDA or other appropriate confidentiality controls before disclosure.
Compliance claims
We do not present certifications, regulatory permissions, audit results, or compliance attestations on this website unless they have been independently verified and are applicable to the relevant service or entity. Where verified independent evidence exists and is relevant to a customer review, it may be shared under appropriate confidentiality controls.
Security contact
For security-related questions, enterprise security review requests, or responsible disclosure, use the contact form.