Security Compliance & Data Protection
This page covers the security and compliance posture of the Axys Platform: how the network and authentication controls described elsewhere in this section fit into a broader compliance picture, how digital-asset custody is architected, and what to expect in terms of certifications and operational track record.
This page describes the security architecture and the compliance frameworks the platform operates under. For formal attestations — SOC 2 Type II reports, PCI-DSS Attestation of Compliance, ISO 27001 certificates — contact your Axys account team; these documents are typically shared under NDA as part of your own due-diligence process rather than published publicly.
Defense in depth
The controls covered in this section combine into a layered security model. Each layer addresses a different class of risk, and (as covered on the preceding pages) all layers must pass for a request to succeed:
flowchart TD
L1["Layer 1 — Network<br/>IP allowlisting"]
L2["Layer 2 — Transport<br/>Mutual TLS (mTLS client certificates)"]
L3["Layer 3 — Identity<br/>FCrDNS validation"]
L4["Layer 4 — Application<br/>X-API-Key, scoped to a single Program"]
L5["Layer 5 — Data<br/>TLS in transit; MPC/TSS custody<br/>for digital assets at rest"]
L1 --> L2 --> L3 --> L4 --> L5
Compliance frameworks
| Framework | What it covers |
|---|---|
| PCI-DSS | Security standards for handling payment card data. |
| ISO 27001 | International standard for information security management systems. |
| SOC 2 (Type I & II) | Independent audit of controls over security, availability, and confidentiality of customer data. |
| Uptime Institute | Data center infrastructure reliability and resilience certification (Tier classification). The platform operates to a 99.99% uptime SLA, equivalent to less than 53 minutes of unplanned downtime per year. |
The platform also undergoes regular independent code audits and penetration testing as part of its ongoing security program.
How your integration's controls relate to PCI-DSS
If your own organization is in scope for PCI-DSS (for example, because you handle cardholder data returned by the sensitive-data endpoints), the controls described in this documentation map onto several PCI-DSS requirement areas:
| PCI-DSS requirement area | How it's addressed |
|---|---|
| Network security controls | IP allowlisting restricts which network paths can reach the API |
| Protecting cardholder data in transit with strong cryptography | Mutual TLS encrypts and mutually authenticates every connection |
| Restricting access by business need to know | Program-scoped API keys mean a credential can only ever access one Program's data — see Program Architecture |
| Identifying and authenticating access to system components | The combination of client certificate + API key forms a two-factor machine-to-machine authentication model — see Authentication & Environments |
This table describes how the platform's controls can support your own PCI-DSS scoping and compliance — it isn't a substitute for your own QSA assessment. Handling of PAN/CVV data returned by the sensitive card-details endpoint carries its own obligations regardless of how you authenticate to the API — see Cards: Virtual & Physical.
Digital-asset custody architecture
Given that every card automatically receives digital-asset deposit addresses (see Funding & Deposits), the security of the underlying custody architecture is directly relevant to the funds flowing through your cardholders' Accounts.
Private keys for digital-asset custody are never held in a single location. Instead, the platform uses HSM-backed Multi-Party Computation (MPC) with a Threshold Signature Scheme (TSS):
flowchart TD
A["No single private key ever exists in one place"]
P1["Key share — independent party A<br/>(hardware-isolated, e.g. Intel SGX TEE)"]
P2["Key share — independent party B<br/>(hardware-isolated TEE)"]
P3["Key share — independent party C<br/>(hardware-isolated TEE)"]
TSS["Threshold Signature Scheme<br/>(M-of-N co-signing required)"]
SIG["Valid transaction signature"]
BACKUP["Offline backup share<br/>held by a regulated third-party trustee"]
A -.-> P1
A -.-> P2
A -.-> P3
A -.-> BACKUP
P1 --> TSS
P2 --> TSS
P3 --> TSS
TSS --> SIG
Key properties of this model:
- No single point of failure — compromising one key share (or one party) is insufficient to move funds; a threshold number of independent, regulated parties must co-sign.
- Hardware isolation — each key share is generated and used within a Trusted Execution Environment (TEE), such as Intel SGX, so the share is never exposed even to the operator of that node.
- Offline backup — an additional key share is held offline by a regulated third-party trustee for disaster-recovery scenarios.
Asset segregation and insurance
Cardholder and customer funds are held separately from operating funds, in a structure designed to be bankruptcy-remote — in the event of an operational issue, customer assets are intended to remain protected and separate from the platform operator's own assets. Specie insurance covers catastrophic loss scenarios for digital assets in custody.
Regulatory footprint
The platform operates under regulatory relationships across multiple jurisdictions, including the United States, the European Union, the United Arab Emirates, and Hong Kong. The specific regulatory relationships relevant to your Program depend on your Tenant's own licensing and the jurisdictions you operate in — discuss this with your Axys account team as part of program design.
Operational track record: the platform has processed significant transaction volume across both fiat and digital-asset rails with no reported security incidents to date. If you'd like current, citable figures (volume processed, assets secured, incident history) for your own materials or due-diligence submissions, request the latest figures from your Axys account team — operational statistics like these are kept current centrally rather than republished here, where they would otherwise go stale.
Your responsibilities
The platform's security architecture covers Axys's infrastructure and custody model. On your side:
- Store mTLS private keys and API keys in a secrets manager — see Authentication & Environments and Credentials & Key Rotation.
- Treat any data returned by sensitive endpoints (PAN, CVV, OTPs) as highly sensitive — encrypt at rest, minimize retention, and restrict access on a need-to-know basis within your own systems.
- Apply the principle of least privilege: if your integration only needs program-level access, don't provision or store tenant-level credentials alongside it.
Looking ahead: HSM-backed storage requirements (e.g. FIPS 140-2 Level 3 attestation) for tenant-side mTLS private keys are anticipated as the platform's security requirements evolve. This page will be updated when that becomes a requirement rather than a recommendation.