SOC Type 1
Madhouse Wallet has undergone a SOC 1 Type I self assessment to demonstrate that the controls protecting partner and customer data are suitably designed as of a specific point in time. This page describes the principal control areas evaluated and how the platform addresses each one.
What SOC 1 Type I Covers
A SOC 1 Type I report evaluates whether a service organisation's internal controls relevant to user entities' financial reporting are suitably designed at a specific date. It does not test whether controls operated effectively over a period (that is covered by Type II). The examination covers five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy.
Security
Controls are designed to prevent unauthorised access to systems and data.
API authentication
Every request passes through withExternalAuth — JWT (ES256 / ECDSA) or API key (SHA-256 hash lookup)
API key entropy
128-bit (32-character hex secret); plaintext shown once and never stored
IP allowlisting
Per-key IPv4 /32 restriction available to all partners
Rate limiting
Sliding-window per-key rate limits enforced before handler logic runs
TLS enforcement
TLS 1.2 or higher required on all inbound and outbound connections
Signing key isolation
Secp256k1 keys held in AWS KMS; all signing operations execute inside the HSM — keys never exported
Webhook integrity
RSA-SHA256 signature validation on all outbound webhook deliveries
Intrusion and anomaly detection
AWS-native monitoring and alerting on IAM, network, and database layers
Availability
Controls are designed to ensure the system is available for operation as committed.
Infrastructure
AWS us-east-1 — managed, multi-AZ capable environment
Database resilience
MongoDB with atomic write operations; no single point of failure for state transitions
Stateless API layer
Horizontally scalable request handlers; no session state held in application memory
On-chain monitoring
Parallel monitoring across all supported chains (Arbitrum, Base, Optimism, Polygon, Ethereum Mainnet, Solana) ensures deposit detection is not dependent on a single RPC provider
Incident response
Defined escalation path for infrastructure incidents; SLA commitments communicated to partners via the dashboard
Processing Integrity
Controls are designed to ensure processing is complete, accurate, timely, and authorised.
Immutable state machine
Each transfer progresses through a defined sequence: pending → awaiting_deposit → deposit_sent → processing → completed / failed
Atomic state transitions
findOneAndUpdate operations prevent double-processing and race conditions
Unique deposit addresses
Every transfer receives a unique on-chain deposit address — funds cannot be misrouted to the wrong record
FX rate locking
Rates are locked at quote time for 5 minutes; no rate change occurs after a quote is accepted
Timestamped audit trail
Every state change is written with a timestamp, creating an immutable record of transfer lifecycle events
Idempotency
Duplicate transfer attempts are rejected at the API layer before any state is written
Confidentiality
Controls are designed to protect information designated as confidential.
Data at rest
AES-256-GCM encryption applied to all stored records in MongoDB
Data in transit
TLS 1.2+ enforced on all API traffic and database connections
API key storage
SHA-256 hashed before persistence — plaintext is never written to the database or logs
Dashboard session data
AES-256-GCM encrypted per-session; session tokens validated against signed MongoDB records
Recipient banking details
PII fields (account numbers, IBAN, routing numbers) encrypted at rest and never logged in plaintext
Third-party data sharing
Recipient details are passed only to the settlement rail required to complete the specific transfer; no data is sold or shared for commercial purposes
Access controls
Production data access restricted to authorised personnel via AWS IAM policies; all access is logged
Privacy
Controls are designed to handle personal information in accordance with the organisation's privacy commitments and applicable regulations (GDPR, CCPA).
Data minimisation
Only data necessary to execute and audit a transfer is collected
PII classification
Banking details, email addresses, and identity fields are classified as PII and subject to elevated controls
Short-lived record expiry
OTP codes and deposit challenges are auto-purged via MongoDB TTL indexes
Retention and deletion
Partners subject to GDPR or CCPA may request deletion of personal data via the account dashboard or support channel; requests are fulfilled within the timeframes required by applicable law
Consent and disclosure
Data collection and use is documented in the Privacy Policy
Cross-border transfer controls
Personal data transferred outside the EEA is handled in accordance with GDPR Chapter V requirements
Sub-processor oversight
Third-party processors (AWS, Comply Factor) are contractually bound to equivalent data protection standards
Logical Access and Change Management
Principle of least privilege
IAM roles grant only the permissions required for each service or operator function
Segregation of duties
Production deployments require review and approval; no single engineer can push to production without oversight
Audit logging
All privileged access and configuration changes are logged and retained
Change control
Code changes follow a documented review and approval process before deployment
Dependency management
Third-party libraries are reviewed and pinned; updates are tested before production rollout
Compliance Alignment
The controls described on this page collectively support the following certifications and regulatory obligations:
SOC 1 Type I
Controls suitably designed
SOC 2 Type II
Audit in preparation
GDPR
Compliant
CCPA
Compliant
For questions about the SOC 1 examination, to request a copy of the report, or to discuss control evidence with your compliance team, contact us at compliance@madhousewallet.com.
Last updated
Was this helpful?