Security Policy

Mint Technology Ltd · Company number 16229672 · ICO ZB872041
288 Bishopsgate, London EC2M 4QP, United Kingdom

1. Purpose and scope

This Security Policy describes how Mint ("Mint", "we", "us", "our") protects sensitive data across the Mint platform, including the website getmint.money, the merchant dashboard, our APIs, SDKs, plugins, webhooks, and the Mint React data‑protection proxy.

It applies to all Mint personnel, contractors, sub‑processors, partners, and systems that process, store, or transmit Mint or Merchant data — including cardholder data, KYB/KYC records, transaction records, and cryptocurrency payment metadata.

2. Avoid handling sensitive data in plaintext

Mint React is Mint's primitive for keeping sensitive fields encrypted across your stack and across third‑party integrations.

React can be called using a Mint server‑side SDK, or a proxy URL. Once created, the proxy can be configured to encrypt or decrypt requests or responses.

Mint's server‑side SDKs can automatically detect and decrypt any Mint‑encrypted strings in requests to third‑party APIs.

mint.enableOutboundReact();
await plaidClient
.transactionsGet({
access_token: 'mint:ZEQwEqLE_YzclnPF_FjorA',
start_date:   '05 Jun 2025',
end_date:     '05 Jun 2026',
});

By proxying sensitive fields through Mint React, you remove them from your application's plaintext surface area, reduce PCI DSS scope, and keep your customer data encrypted at rest in your own database.

3. Get started with the React 

Create your first React and start encrypting data during a network request.

Step 1 — Create a React

You can create a React in the Mint dashboard, pointing at either your own server or a third‑party URL. Proxied requests will be forwarded to the domain you specify, including any encrypted or decrypted fields that you've configured.

Create a React
Where should we forward proxied traffic?
https://

Step 2 — Configure

React can be configured to encrypt or decrypt fields in a request or a response. You can also choose to encrypt or decrypt different fields for different paths.

Configure React

Route: POST /customers

Encrypted fields (Request Body / Headers):

Step 3 — Integrate

Once your React has been configured, you can integrate in a few lines of code. Use the SDK for any requests sent to third‑party APIs, or a proxy URL for requests to your own server.

mint.enableOutboundReact();
// React decrypts data sent to Stripe
await stripe.customers
.create({
address: 'mint:dnamPvA2_O2JGN1534nyGg',
name:    'mint:NkZzNUbfUeo8JByldEAhrw',
});

4. Flexible, performant, and highly secure

React isn't just a network proxy. It's flexible enough to encrypt or decrypt data in any data‑security workflow, without affecting the performance of your product.

5. Adapt React for any security workflow

React can be configured in several different ways, depending on whether you're interacting with your own server or a third‑party API:

• Inbound React — encrypt fields in requests reaching your server before they hit your database.

• Outbound React — decrypt fields just in time as they leave your infrastructure for a trusted third party (e.g. Stripe, Plaid, a card network, a KYB provider, or a blockchain analytics vendor).

• Field‑level policies — apply different encryption, tokenisation, or masking policies (e.g. PCI Data, EU Data, No Policy) per field and per path.

• Browser, server, or third party — the same React can sit between any combination of browser, your server, and external APIs.

6. Compatible with each Mint primitive

Primitives are building blocks for developers. They're fundamental, interoperable products for constructing any data‑security or compliance workflow on Mint — including React, vaults, tokenisation, key management, and enclave‑based functions. React composes with each of these so you can move sensitive data through your stack without ever materialising it in plaintext outside an enclave.

7. Cryptographic standards

Customers retain ciphertext in their own systems; Mint holds only the keys, inside enclaves, with strict use policies.

8. Platform and infrastructure security

• Cloud hosting: primary infrastructure runs in AWS regions in the UK and EU (with failover); production workloads are isolated in dedicated VPCs.

• Network controls: segmentation, security groups, WAF, DDoS protection, private subnets for data stores, VPN/SSO‑gated bastions.

• Secure enclaves: all cryptographic operations and decryption of sensitive fields take place inside hardware‑attested enclaves with reproducible builds and remote attestation.

• Hardening: minimal base images, immutable infrastructure, no SSH into production, just‑in‑time access with full audit trail.

• Backups: encrypted, versioned, geographically redundant; restore tested on a defined cadence.

• Disaster recovery: documented RPO/RTO targets, with regular DR exercises.

• Vulnerability management: automated dependency scanning, container scanning, secret scanning, and SAST/DAST in CI; tracked remediation SLAs by severity (Critical 24h / High 7d / Medium 30d / Low 90d).

• Penetration testing: at least annually by an independent CREST‑accredited firm, plus targeted tests on material changes; summary reports available under NDA.

• Bug bounty / responsible disclosure: see section 14.

9. Identity and access management

• Single sign‑on (SSO) with SAML/OIDC for all Mint staff; MFA mandatory.

• Role‑based access control on least‑privilege; access reviewed quarterly and revoked within 24 hours of role change or off‑boarding.

• Production access requires named approval, time‑boxed elevation, and is logged immutably.

• Customer dashboard supports MFA, SSO (on eligible plans), API keys with scoped permissions, IP allow‑listing, and webhook signature verification.

• Secrets are stored in a managed secrets manager; rotation policy enforced.

10. Application security

• Secure SDLC: threat modelling for new features, code review, automated testing, branch protection.

• Mandatory peer review and CI checks before merge to production branches.

• Input validation, output encoding, anti‑CSRF, anti‑SSRF, strict content security policies.

• Webhook signing and replay protection on outbound events.

• Tokenisation and hosted fields used to keep cardholder data and other regulated fields out of Merchant systems wherever possible, minimising PCI DSS scope.

11. Compliance, certifications, and attestations

Mint operates under, and is fully aligned with, the following standards and regulations:

• PCI DSS — for card data flows, with annual assessment by a Qualified Security Assessor (QSA); merchants benefit from significantly reduced scope when using React and hosted fields.

• GDPR / UK GDPR & Data Protection Act 2018 — see Privacy Policy.

• HIPAA — Mint can support BAA‑backed flows for healthcare merchants on eligible plans.

• SOC 2 Type II — controls aligned to the Trust Services Criteria (Security, Availability, Confidentiality); report available under NDA.

• ISO/IEC 27001 — Information Security Management System aligned to ISO 27001:2022 controls.

• Money Laundering Regulations 2017 (MLR 2017) and Proceeds of Crime Act 2002 — for KYB/AML obligations.

• Sanctions — UN, UK OFSI, EU, OFAC; sanctions screening on customers, counterparties, and Transactions.

A current certifications pack (PCI AoC, SOC 2, pen‑test executive summary, ISO 27001 statement of applicability) is available from security@getmint.money -  under NDA.

12. Data lifecycle and residency

• Data minimisation: we collect only what is needed for the purpose disclosed in the Privacy Policy.

• Residency: Merchants on eligible plans can pin sensitive data flows to UK or EU regions; cross‑border transfers use the UK IDTA / Addendum and EU SCCs (see Privacy Policy section 8).

• Retention: per the retention schedule in the Privacy Policy, with AML records held at least 5 years (MLR 2017, reg. 40).

• Deletion: verified deletion on contract end and on valid data‑subject erasure requests, subject to legal hold and AML retention obligations.

• Blockchain caveat: on‑chain data on public blockchains is immutable; Mint will sever the link between identity and on‑chain data in its own systems where required.

13. Incident response

• 24×7 security on‑call.

• Documented incident response plan covering detection, triage, containment, eradication, recovery, and post‑incident review.

• Confirmed personal‑data breaches affecting controllers are notified without undue delay and within 72 hours of awareness, in line with UK GDPR Art. 33.

• Customers are notified of incidents affecting their data via the agreed channel in the Order Form or DPA.

• Lessons learned and remediation actions tracked to closure.

14. Responsible disclosure

We welcome reports from security researchers. Please email security@getmint.money with reproduction steps and any supporting material. Do not access, modify, or delete data belonging to other users; do not run automated scans that affect availability. Provided you act in good faith and within these guidelines, we will not pursue legal action and will publicly acknowledge significant reports where you wish.

15. Personnel security

• Background checks (where lawful) for all staff with access to production or regulated data.

• Confidentiality and acceptable‑use agreements signed at hire.

• Annual security, privacy, AML, and PCI awareness training; targeted training for engineering and operations.

• Joiner/mover/leaver processes integrated with the identity provider.

16. Meet compliance requirements. Build customer trust.

Use Mint's flexible building blocks — React, vaults, tokenisation, and enclave‑backed functions — to keep your customers' data secure and compliant at all times, across cards, wallets, bank methods, and cryptocurrency payments.

17. Contact

• Security incidents & responsible disclosure: security@getmint.money

• Privacy / data protection: privacy@getmint.money

• Compliance / AML / sanctions: compliance@getmint.money 

• Postal: Mint Technology Ltd, 288 Bishopsgate, London EC2M 4QP, United Kingdom

Document control

• Owner: Mint Technology Ltd — Security & Compliance

• Approver: Board of Directors

• Review cycle: at least annually, or on material change to architecture, law, or scheme rules

• Version: 1.0 — 5th June 2026