Security & Trust

Security is the product, not a checklist.

A payments-adjacent platform fails the moment trust does. Here is exactly how we protect data — what we do, what we don't yet do, and how to report an issue.

Data residency

Primary database and object storage run on managed Postgres in Singapore (ap-southeast-1). Daily encrypted backups with point-in-time recovery (7 days). On request, enterprise customers can be migrated to a Bangladesh or India region.

Encryption

  • In transit: TLS 1.3 enforced on all endpoints, HSTS preload pending domain verification.
  • At rest: AES-256 disk encryption on database and object storage. Document files stored in a private bucket; access is exclusively through short-lived signed URLs (60s).
  • Secrets: Service credentials stored in the platform secret store; never in source, never in client bundles.

Access control

  • Row-Level Security (RLS) on every user-data table. Policies are scoped to auth.uid() and verified by a security-definer has_role() function — no recursive RLS, no role-on-profile anti-pattern.
  • Storage path RLS: Files live under {user_id}/{document_id}/{filename}. The bucket policy denies access when the path's first segment does not match the caller's auth.uid(), independent of any client claims.
  • Service role credentials are server-side only and loaded via dynamic import inside server-function handlers — never reachable from the browser bundle.
  • MFA (TOTP): rolling out in the credibility-layer release.

Audit logging

An append-only audit_events table records every privileged mutation (KYC decision, document delete, role change, suspension, contact submission). Visible to admins and to the actor for their own actions. Insert is restricted to server code.

Application security

  • All inputs validated server-side with Zod. Mime allowlist and 25 MB cap on uploads. Filenames sanitized against path traversal and unicode tricks.
  • Leaked-password protection (HIBP) enabled on signup and password change.
  • Rate limiting on authentication, document upload, and SSO lookup endpoints.
  • Server functions run on Cloudflare Workers — no long-lived process state, no implicit filesystem trust.

Operational security

  • Server function logs available to engineering for forensics.
  • Sentry for error tracking; PostHog for product analytics.
  • Quarterly third-party penetration test scheduled before first paid enterprise contract.

What we do not yet have

Stated plainly because hiding it is the bigger risk:

  • SOC 2 / ISO 27001 — planned, not yet started.
  • External pentest report — not yet commissioned.
  • Real SAML IdP configurations — scaffolded, awaiting first enterprise customer.

Responsible disclosure

Report vulnerabilities to security@merchant.bd. Initial acknowledgement within 48 hours. Please give us 90 days before public disclosure. We do not currently run a bug bounty but will credit researchers in a public hall of fame.

Compliance posture

merchant.bd is not a Bangladesh Bank–licensed PSO/PSP. We operate as a software vendor / ISV on top of licensed partners. Payments are processed by your acquirer of choice. KYC verifications are performed against the verifier you nominate (Porichoy, manual review, etc.).