Security and data handling
This page answers the questions a compliance or information-security team asks before a pilot. It describes the product as it runs today; where something is planned rather than built, it says so.
Deployment
Production: installed in the firm's own cloud account (AWS, Azure or Google Cloud, in the region the firm chooses) or on its own servers. Trading, transaction and customer data stay in that environment; we do not host or receive them.
Pilot: the same installation, or a dedicated instance we run for the firm in its region. The instance holds only that firm's data and is deleted at the end of the pilot unless a licence follows.
Public sandbox: synthetic data by default. When a visitor uploads their own files, names, account numbers, client ids, devices and IP addresses are replaced by tokens in the browser before anything is sent. Each sandbox is a separate database schema, private to the visitor, and deleted after seven days.
Access and accountability
Named users in two roles: analysts propose decisions, MLROs approve or return them. Nobody can approve their own proposal.
Every action, from case creation to STR filing, is written to an append-only audit log. Each entry carries the hash of the one before it; the chain is re-verified whenever the log is opened, and each case's evidence pack carries its own SHA-256.
A change to a case and its audit entry are committed in the same database transaction. There is no path that changes a case without recording who did it.
Sign-in attempts are rate-limited, sessions are signed and expire after twelve hours, and cross-site requests are refused. Single sign-on (SAML/OIDC) and multi-factor authentication are planned for production installations.
Detection and language models
Detection is rule-based and deterministic: the same data and thresholds always produce the same alerts, and every alert lists the records it rests on.
A language model is optional and only writes text. Before any call, client names, ids, account numbers and wallets are replaced by tokens. Every sentence must cite an evidence row or it is removed, and the reviewer sees the rule text and the model text side by side.
The firm chooses the model endpoint: Azure OpenAI or AWS Bedrock in its own region, or an open-weights model on its own hardware. Marqib does not train models on client data.
Data protection
Data in transit is encrypted with TLS. Databases behind our hosted services (website, sandbox, pilot instances) are encrypted at rest by the provider.
Case files and audit logs are kept for as long as the firm's record-keeping obligations require, for example five years under UAE AML rules and eight years under Turkish MASAK rules. In the firm's own installation, the firm controls retention.
Sub-processors of our hosted services: Vercel (hosting), Neon (database), Resend (e-mail delivery), Namecheap (mailbox) and IPinfo (network look-up for website events). None of them is used inside a firm's own installation.
Reporting a vulnerability
Write to hello@marqib.com with "Security" in the subject. We acknowledge within two business days and keep you informed until the issue is fixed. Our security.txt is at marqib.com/.well-known/security.txt.
For vendor due diligence
- Architecture and data-flow description (PDF, English)
- Data processing agreement (template) (PDF, English)
- Answers to a standard security questionnaire (PDF, English)
- Sub-processor list and change notice (PDF, English)
- Model governance note: tokenisation, evidence binding, endpoints (PDF, English)
Download them here. The data processing agreement is a template; we complete it with the pilot agreement. Questions: hello@marqib.com.