Data Security Policy
01 // Overview
MEnterprise Firm Inc. handles some of the most sensitive categories of personal and financial information that exist — Social Security numbers, bank account and routing numbers, government-issued identification, and business financial records. We take this responsibility seriously and have implemented security controls appropriate to the sensitivity of the data we handle.
This policy describes those controls in plain terms so that merchants, ISO partners, and acquiring banks can evaluate our security posture before engaging with us.
02 // Data Classification
| Category | Examples | Sensitivity Level |
|---|---|---|
| Critical PII | SSN, government ID number, date of birth | Highest — strictly access-controlled |
| Financial Account Data | Bank routing number, account number, bank statements | Highest — masked in operational systems |
| Business Identity | EIN, business name, owner name, address | High |
| Application Records | MCC, processing volume, chargeback history | High |
| Documents | Uploaded PDFs, images of ID, bank statements | High — stored encrypted, access logged |
| Contact Information | Email, phone, website | Standard |
| Technical Metadata | IP address, submission timestamp, session tokens | Standard |
03 // Security Controls
Encryption in Transit
- All web traffic secured with TLS 1.2 minimum (TLS 1.3 preferred)
- HTTPS enforced across all our domains — HTTP redirects to HTTPS automatically
- SSL certificates issued by Let’s Encrypt, auto-renewed
- API communications between services secured via TLS
Encryption at Rest
- All database data encrypted at rest via Supabase on AWS infrastructure (AES-256)
- Uploaded documents stored in encrypted cloud storage buckets
- ISO package deliveries encrypted with AES-256 before transmission using per-partner pre-shared keys
- Bank account and routing numbers masked in all operational database records — only the last four digits are retained in any system other than the locked application PDF
Access Controls
- Row-Level Security (RLS): All database tables enforce deny-all RLS by default. No data is publicly accessible. All data access requires authenticated service-level credentials.
- Staff authentication: Staff access to the merchant management dashboard requires a secure API key. No username/password combinations are used for system access.
- API proxy: External API calls (including to Supabase) route through our proxy infrastructure which holds credentials server-side. No API keys are exposed in browser-accessible code.
- Principle of least privilege: Each service has access only to the data it specifically needs to function.
Document Security
04 // E-Signature Security
Electronic signatures on merchant applications are authenticated and evidenced through the following:
- The submitter’s IP address is captured at the moment of signature and embedded in the signed PDF
- Submission timestamp is recorded and embedded in the PDF
- A unique verification code (VFY-XXXX) is issued that allows third parties to verify the application was submitted through our system without exposing any PII
- The signed PDF is locked — digitally uneditable after generation
- Application records in our database are marked as immutable upon submission
05 // Third-Party Service Providers
We use the following third-party services that process merchant data on our behalf. Each has been selected based on their security posture:
| Provider | Function | Data Processed | Security Basis |
|---|---|---|---|
| Supabase (AWS us-east-1) | Database and document storage | All application data, uploaded documents | SOC 2 Type II, AES-256 encryption at rest |
| Vercel | Application wizard hosting | Session tokens only — no sensitive data stored | SOC 2 Type II |
| Resend | Transactional email | Email addresses, application reference numbers | SOC 2 Type II |
We do not use third-party analytics, advertising pixels, or tracking tools on pages where merchants submit sensitive information.
06 // Retention and Deletion
Data is retained according to our Privacy Policy retention schedule (generally 7 years for submitted applications per ISO partner agreement requirements). After the retention period, data is purged from all systems.
For draft applications that were started but never submitted: purged automatically after 90 days of inactivity.
For terminated merchant relationships: data retained for the applicable period per ISO requirements, then purged. Merchants may request early deletion where legally permissible by contacting cash@mef.money.
07 // Incident Response
In the event of a suspected or confirmed security incident affecting merchant data:
- Affected systems will be isolated within 2 hours of discovery
- Affected merchants will be notified within 72 hours of confirmed breach
- We will notify relevant authorities as required by applicable law
- A written incident report will be provided to ISO partners and affected merchants upon request
To report a suspected security vulnerability, contact cash@mef.money with subject line “Security Report.”
08 // Contact
For questions about our security practices, to request a copy of this policy, or to report a security concern:
MEnterprise Firm Inc.
Email: cash@mef.money
Subject: “Security / Data Handling”