Security at Remse

Remse connects travelers and relocators with agents who handle sensitive tasks — visas, housing, and payments — often before the two parties have ever met in person. That only works if the platform underneath is trustworthy. Security isn't a feature we bolt on; it shapes how every part of Remse, from escrow to messaging, is built.

This page explains the practical measures we take to protect your data and funds, in plain language. If you're a security researcher, see the Responsible Disclosure section for how to report a vulnerability.

Remse's backend runs on Google Cloud Platform and Firebase, with primary data centres in the eur3 region. We rely on Google's physical and network-level security rather than maintaining our own servers, which means our infrastructure inherits the same protections used by some of the largest platforms in the world.

• Cloud Functions handle all sensitive business logic — including escrow and wallet operations — server-side, never on the client device
• Firestore stores structured data behind security rules evaluated on every request
• Cloud Storage holds KYC documents and uploaded files in access-restricted buckets
• Automated backups and versioning protect against accidental data loss

Data is encrypted both while it's moving and while it's stored:

Remse never stores your card details. All payment processing — wallet funding, withdrawals, and escrow — is handled by Paystack, a PCI DSS compliant payment provider used across Africa.

Wallet balances and escrow amounts are tracked server-side through Cloud Functions, so a compromised device can't be used to alter your balance or trigger an unauthorised transfer.

Every agent on Remse goes through identity verification (KYC) before they can list services or receive payments. This protects travelers from impersonation and fraudulent listings.

• Government-issued ID and proof of address are required for agent verification
• Verified agents display a badge visible throughout the app
• Accounts showing suspicious activity (rapid location changes, mismatched device fingerprints, repeated failed logins) are automatically flagged for review
• We strongly recommend enabling any available biometric lock (Face ID / fingerprint) on your device for an extra layer of protection

Not every part of the platform is visible to every user — access is scoped tightly by role:

• Firebase Security Rules enforce role-based access control on every database read and write
• Custom claims-based authorization gates admin-only operations, separate from regular user permissions
• Agents can only view data for clients actively engaged with them — not the full user base
• Internal team access to production data is logged and limited to what's required for the task at hand

We treat security as an ongoing process rather than a one-time checklist:

If you're a security researcher and believe you've found a vulnerability in Remse's app, website, or backend, we want to hear from it before anyone else does. Please report it responsibly:

• Email security@remse.app with a clear description and steps to reproduce
• Give us a reasonable window to investigate and patch before any public disclosure
• Do not access, modify, or delete data belonging to other users while testing
• Do not run automated scanners against production systems without prior written permission

We currently review disclosures on a case-by-case basis rather than running a formal paid bug bounty programme. Researchers who report valid, previously-unknown issues in good faith will be credited (with permission) once a fix ships.

If a security incident affecting user data or funds is confirmed, our process is:

1. Contain the issue and stop ongoing exposure as the immediate priority
2. Investigate scope — which accounts, data, or transactions were affected
3. Notify affected users directly, with a clear explanation of what happened and what to do
4. Notify relevant regulators where required under NDPR or applicable law
5. Publish a post-incident summary once the investigation is complete

Most account compromises happen outside our systems — through reused passwords or social engineering. A few habits go a long way:

Remse's security and data-handling practices are built around the following frameworks and requirements:

• NDPR — Nigeria Data Protection Regulation
• GDPR — for users located in the European Economic Area or United Kingdom
• PCI DSS — inherited through our payment processor, Paystack, which handles all card data

For details on what data we collect and how it's used, see our Privacy Policy.

For vulnerability reports, suspected breaches, or general security questions, reach our team directly: