​

Trust & Security

Sumvin operates a single, US-only platform. All customer data is stored, processed, and served from data centres in the United States, on a small and deliberately chosen set of vendors. This page is the canonical answer to the questions partners and procurement teams ask most often.

​

The short answer

• Hosting: Google Cloud Platform, in the United States.
• Primary region: Northern Virginia (us-east4).
• Data residency: All customer data — including personally identifiable information, KYC records, transactional history, and cryptographic key material — is stored and processed in the United States. We do not replicate customer data outside the US.
• Sub-processors: A small list of US-hosted vendors, each chosen for a specific function. The full list is here.
• Encryption: Encrypted in transit (TLS 1.2+) and at rest (AES-256). Sensitive fields receive an additional layer of application-level encryption with hardware-backed keys.
• Key custody: Cryptographic keys for signing and encryption are held in FIPS 140-2 Level 3 hardware security modules. They never leave the hardware.
• Compliance posture: SOC 2 audit programme in progress. GDPR-aligned data handling. PCI scope minimised by design — we do not store card numbers; card issuing runs on Visa Intelligent Commerce, with issuing and processing handled by our regulated issuance partner.

​

Where data lives

Sumvin’s production environment runs on Google Kubernetes Engine in us-east4 (Northern Virginia). The cluster is single-region; customer data is not served from, processed in, or replicated to non-US regions. The same US-only commitment extends to every sub-processor that holds or processes customer data:

• Our database provider (PlanetScale) hosts our production cluster in the US.
• Our cache and durable workflow provider (Upstash) hosts our production data in the US.
• Our key management (Google Cloud HSM) keys are provisioned in US key rings.
• Our identity verification provider (Sumsub) processes US users on US infrastructure.

Two vendors — Cloudflare and Pimlico — operate globally distributed networks and are scoped to traffic that does not contain customer data: public blockchain RPC calls, short-lived authentication nonces, and already-signed ERC-4337 bundler operations bound for a public mempool. They are listed under Edge services on the subprocessors page so the scope is explicit. If your contract or regulatory framework requires a written commitment to US-only processing of customer data, we are able to provide one.

​

What we hold

The data Sumvin holds about your end-users falls into a few categories:

• Account and profile data — email, phone number, display name, and the timestamps and identifiers Sumvin needs to operate the account.
• Identity verification data — the structured outputs of KYC (status, attestation claims, document references). The underlying identity documents themselves are held by our KYC provider, not by Sumvin directly.
• Wallet and transaction data — wallet addresses, on-chain transaction history, balances, and the metadata Sumvin enriches transactions with.
• Authorisation records — the cryptographic credentials (PINTs) issued on a user’s behalf and the audit trail of how each was used.
• Operational logs — metrics, traces, and logs Sumvin needs to operate the service. Sensitive payloads are redacted before they reach the logging system.

We do not hold raw payment card numbers, passwords (authentication is delegated to specialist providers), or unverified personal data uploaded by end-users.

​

How data is protected

Sumvin runs on a defence-in-depth model. No single control is the answer; protection comes from layering controls so that compromising one does not compromise the user’s data. The high-leverage controls are:

• Encryption everywhere. Data is encrypted in transit using mutually-authenticated TLS, including between internal services. Data at rest is encrypted with AES-256 using customer-managed keys. The most sensitive fields (private identifiers, key material) carry an additional layer of application-level encryption.
• Hardware-backed key custody. Signing keys, encryption keys, and the keys used to issue authorisation tokens are held in FIPS 140-2 Level 3 hardware security modules. The keys never leave the hardware; the platform asks the hardware to perform an operation, never to disclose the key.
• Hardware-attested signing environments. The most sensitive operations — agent signing, authorisation token issuance, transaction policy evaluation — run inside confidential computing enclaves (AMD SEV-SNP). The hardware itself attests, cryptographically, that the code running inside has not been tampered with.
• Least-privilege access. Every internal service has its own identity and is permitted to access only the secrets and resources it specifically needs. Engineers do not have standing access to production data; access is brokered through audited, time-bound paths.
• Mutual authentication between every internal service. Services do not trust the network. Every internal call is mutually authenticated and authorised by an explicit, default-deny policy.
• Web Application Firewall and DDoS protection on every public endpoint, with geographic and rate-based controls.
• Signed deployment artefacts. Only code that has been built by our automated pipeline, scanned, and cryptographically signed can be deployed to production.

A more detailed technical walkthrough is available on request for partner security teams.

​

Operational practices

• Audit logging. Every signing operation, every administrative action, and every access to sensitive data is logged to an append-only audit trail. The trail is independently retained and cannot be modified by the operating team.
• Separation of duties. The engineers who write code do not have unilateral access to production. Production changes go through code review, automated checks, and an attested deployment pipeline.
• Backups and recovery. Production databases are backed up continuously, with point-in-time recovery available within the retention window. Restore procedures are tested.
• Vulnerability management. Dependencies and base images are scanned on every build. Security-relevant updates are tracked and applied on a defined cadence; critical issues are expedited.
• Penetration testing. External penetration tests are commissioned on a regular cadence. Findings are tracked to closure.

​

Compliance and certifications

• SOC 2 — audit programme in progress. Status letters and (where available) bridge letters can be provided to partners under NDA. Contact your account team for the latest position.
• GDPR — Sumvin’s data handling is aligned with GDPR principles even though the platform’s primary user base is US-based. Data-subject rights (access, deletion, portability) are supported as an operational process: end-users initiate requests through the partner application or via the partner’s support channel, and Sumvin’s team handles them in line with the timeframes set out in the partner DPA. Programmatic data-subject-rights endpoints are on the roadmap and will be published on the API reference when available.
• PCI DSS — Sumvin does not store cardholder data. Card issuing and processing is performed by our regulated banking partner; PCI scope sits with them. Sumvin’s role is reduced to scope-minimised metadata only.
• CCPA / state privacy laws — handled within the same data-subject-rights framework as GDPR.
• Banking compliance — the regulated activity (card issuing, money movement) is performed by partners holding the relevant licences. Sumvin acts as the technology layer and operates under the partners’ regulatory framework where applicable.

If you need a current compliance pack — SOC 2 status letter, security questionnaire response, sub-processor list under DPA, insurance certificate — request one through your account contact and we will provide it under NDA.

​

Data lifecycle

• Collection. We collect only the data needed to operate the account and provide the contracted service. KYC data is collected once and re-used across partners through Sumvin’s portable identity model (Sigil), reducing the volume of identity data any one partner has to handle.
• Retention. Data is retained for the period required by applicable financial regulation and your DPA. KYC records are retained for the regulated minimum (typically five years post-account-closure under US AML rules).
• Deletion. End-users can request deletion through the partner application or the partner’s support channel. Requests are handled by Sumvin’s team under a documented internal procedure and honoured within the regulatory and operational windows that apply. Soft-deletion preserves audit trails; records subject to retention obligations (for example, AML) are retained for the regulated minimum and then hard-deleted on a defined schedule.
• Portability. End-user data can be exported on request through the partner. The export format is set out in the partner DPA.

​

Incident response

Sumvin operates a documented incident-response process. In the event of a confirmed security incident affecting partner or end-user data, we commit to:

• Notify affected partners without undue delay and within the timeframe set out in the partner DPA, with a preliminary description of scope and impact.
• Provide a post-incident report with root cause, remediation, and any required regulatory notifications.
• Maintain regulatory notifications to the appropriate authorities where the incident triggers a notification obligation under applicable law.

Notification timelines and contacts are set out in the partner DPA.

​

Questions and diligence requests

For a security questionnaire response, SOC 2 status letter, DPA, sub-processor list, or any other diligence material, contact your account team. Most partner reviews can be completed within a single round of questions.

​

See also

• Subprocessors — the full list of vendors Sumvin uses, what each does, and where they process data.
• Auth model — how partners and end-users are authenticated.
• Signing keys — the cryptographic keys Sumvin holds and how they rotate.