Security & trust

How Moniqo operators (us) handle access to your data, and why you can verify our claims rather than just trust them.

Calls, messages, and emails claiming to be from us

Moniqo will never contact you and ask for any of the following — even if they sound urgent, even if they cite a transaction, even if they show our logo:

  • Bank password
  • OTP (one-time passcode)
  • Card CVV / PIN
  • Full card number

What we do store:the masked last 4 digits of a card (for display only), the card's nickname, and the bank name. The PAN, CVV, and PIN never leave your wallet — Moniqo has no field to type them into.

If you receive a call claiming to be from Moniqo: hang up, then email security@optifitechnologies.com with the caller's number and what they asked for. We log every report.

If someone claims to be from your bank and asks for an OTP that just landed on your phone — they are a scammer. No real bank asks for OTPs they themselves just sent. Hang up.

The short version

  • Moniqo operators can see aggregate system metrics — never the contents of your transactions.
  • To view a specific account, an operator must request a support session — you receive an OTP and explicitly approve.
  • Every operator action is logged in an append-only audit table.
  • You can revoke an active support session at any time from your settings.

1. How operator access works

Moniqo is a software product operated by OptiFi Technologies. Operating it means we keep the service running, fix bugs, edit email templates, and answer support tickets. None of that requires us to look at your transactions or balances. So we built the system so it doesn't.

The operator console (/admin) is a completely separate sign-in, a separate database table of operator identities, and a separate audit log from the customer app. An operator cannot sign in as a customer.

2. Four zones of access

Zone A — system metrics (no customer data)

The operator dashboard shows aggregates: number of users, signups this month, uptime, error rate, regional split. Operators can edit email templates and toggle feature flags. None of this touches your transactions, balances, or receipts.

Zone B — customer metadata only (no money)

When you raise a support ticket, the operator can see the bare minimum needed to identify you: your email, name, signup date, last login, MFA status, and login history. They cannot see transaction amounts, balances, categories, vendor names, receipts, account numbers, or credit-card details.

Zone C — your consent, with OTP (limited time, you can revoke)

If the operator needs to see something inside your account to help, they request a support session. You receive a 6-digit code by email with a plain-English description of what's being requested (for example: “view transactions from the last 30 days to investigate a duplicate charge”). You enter the code in your own account → access is granted for 30 minutes → every record they view is logged → you can revoke instantly.

When the session expires you receive a summary email of everything that was viewed.

This is modelled on the way a bank teller works: they can't look at your account just because they want to. You give them your PIN at the counter, and that PIN is what unlocks your record for that session.

Zone D — break-glass (emergency only)

In rare cases (you've lost MFA AND email access, or there's a security incident affecting many users), operators can invoke break-glass access. This requires:

  • Two operators must approve (the four-eyes principle)
  • A 24-hour cooling-off delay before access activates, OR your explicit consent to skip the delay
  • Auto-expiry after 60 minutes
  • Immediate notification to you

3. What we've done structurally

  • Separate operator identities. The admin_users table is distinct from users. An operator cannot become a customer or vice versa from the same session.
  • Immutable audit log.Every operator action — every dashboard view, every template edit, every support session — is recorded with the operator's ID, IP, user agent, and timestamp. No UPDATE/DELETE handlers exist for these rows in the codebase.
  • CI grep-gates. Our build pipeline runs pattern checks that fail if any /adminroute handler queries customer financial data outside an active support-session scope. The gates can't be skipped without a code review that an external auditor can read.
  • Customer-side approval.The OTP for a support session is sent only to your registered email — never to the operator. Without the OTP, the operator's console literally renders an empty data view for your account.

4. What's on the roadmap

The trust model improves over time. In order of priority:

  • Hardware-token MFA for operators (WebAuthn / YubiKey mandatory before any production access)
  • Field-level encryptionon transaction amounts, descriptions, and MFA secrets — even a database administrator with direct query access won't see plaintext without going through a KMS proxy that logs every decrypt call
  • SOC 2 Type II audit (6-month observation window). External auditors verify our access controls match what this page claims.
  • Annual penetration test by an independent Dubai-based firm
  • Quarterly transparency report — aggregate stats on operator access patterns, customer-consented support sessions, government data requests (always zero, unless a court order makes us)

5. Where to verify

  • See every operator who has ever accessed your account in Settings → Security.
  • See the live list of sub-processors (third parties who may touch infrastructure) at /subprocessors.
  • Read the privacy policy at /privacy for the legal framing.

For specific access questions, security findings, or to revoke a support session you didn't intend to approve, write to security@optifitechnologies.com.


Last updated: 12 May 2026. We'll update this page whenever the access model changes, and announce the change to all users via email.