> For the complete documentation index, see [llms.txt](https://docs.madhousewallet.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.madhousewallet.com/introduction/soc-type-1.md). # 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. | Control | Implementation | | ------------------------------- | ------------------------------------------------------------------------------------------------------ | | 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. | Control | Implementation | | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 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. | Control | Implementation | | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------- | | 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. | Control | Implementation | | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | 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). | Control | Implementation | | ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 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](/legal-policies/privacy.md) | | 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 | Control | Implementation | | ---------------------------- | --------------------------------------------------------------------------------------------------------------- | | 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: | Framework | Status | | ------------- | -------------------------- | | 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 .