Surveillance and transaction monitoring for licensed firms

Case files, not alerts.

Marqib monitors trades, deposits and withdrawals overnight within the firm's own environment. Explainable low-risk alerts are closed with a written rationale; the remainder reach the MLRO as complete case files: evidence, reasoning and a regulator-ready draft. No report is filed without a named reviewer's approval.

2–3 h → 10 minreviewer time per alert (pilot target)
In-regionsingle-tenant deployment
100%of filings human-approved
AL-2609-014 · WASH TRADINGSCORE 0.94
00:00Nightly scan — 1,842,310 trades, 3,118 clients
00:03Rule hit — 58 matched trades <2 s, same UBO
00:04KYC lookup — accounts 40917 / 41203 share passport
00:05Funding lookup — both funded by LT61… on 19 Sep
00:06⚑ Rebate — IB P-118 earned USD 6,300 on this volume
00:07Screening — no sanctions / PEP hit
00:08Hold — withdrawal WR-88213 paused; routed to MLRO
→ Evidence pack (14 p) + STR draft ready for review
Operating model

Deterministic detection. Governed drafting.

Alerts are produced by rules and statistics the firm can read, tune and evidence to an auditor. Where a language model is used, it writes only from the evidence the rules have already collected, and every sentence it produces must cite a record.

01

Ingest

End-of-day trades, orders, deposits, withdrawals and KYC changes are received from the trading platform, CRM and payment providers. File-based delivery at the outset; API connectors as required.

02

Detect and score

Typology rules run against the full book. Each hit is scored on volume, profile consistency, screening results and history. Low-risk, explainable hits are closed automatically with a recorded rationale.

03

Investigate

For each open alert the platform assembles the linked records: beneficial ownership, funding sources, counterparties, rebate ledgers, screening results, on-chain exposure. Read-only access under the firm's existing permissions.

04

Draft

A hashed evidence pack and a narrative in the FIU's format, or an explicit recommendation not to report with the proposed action. Each statement in the draft references the record that supports it.

05

Review

The MLRO works from a risk-ranked queue: approve, edit, request information or close as a false positive. Holds on withdrawals are placed and released from the same case file.

06

Audit

Every action, by the platform or by a reviewer, is written to an append-only, hash-chained log. The record of why a matter was, or was not, reported exists before the regulator asks.

Coverage

Typologies relevant to brokerage and fintech activity.

Each typology is delivered with calibrated thresholds, a reasoning template and the applicable filing format. Firm-specific rules are added within the same framework.

Market abuseWash tradingOffsetting trades across accounts sharing a UBO, device or funding source; rebate abuse.
Market abuseSpoofing & layeringCancel ratios, order-book pressure opposite to executed side.
AMLStructuringDeposits hugging EDD thresholds across cards, wallets and on-ramps.
AMLPass-throughFund in, no trading, fund out to a different institution or self-custody wallet.
AML / TFSanctions proximityCounterparty and beneficial-owner matches, list updates re-screened nightly.
OnboardingThird-party fundingPayer name mismatch, relationship not documented.
FraudAccount takeoverDormant reactivation, new device, bank change, immediate withdrawal.
CryptoWallet exposureMixer, darknet and sanctioned-address exposure on inbound and outbound stablecoin flows.
Deployment

Installed in the firm's environment. Client data does not leave it.

  • Single-tenant, in-region. Marqib is delivered as a container package into the firm's own cloud account (UAE, Bahrain or Saudi regions) or onto a dedicated instance operated in-region. There is no shared database.
  • Permissions inherited. The platform reads through the firm's existing roles and cannot write to source systems.
  • Hash-chained audit log. Append-only; each entry is linked to the previous one, making alteration detectable.
  • No client data held by the vendor. Marqib delivers rule, typology and schema updates. It does not receive the firm's records.
Firm systemsMT5 / cTrader · CRM and KYC · PSPs and banks · screening provider · chain analytics
↓ end-of-day feeds, read-only
Marqib corerule engine · scoring · investigation · evidence packs · case management · audit log
↓ optional narrative model, in-region or on-premise, pseudonymised input
Review and filingMLRO queue · approvals · goAML XML · regulator notifications
↑ rule and schema updates only · no data flows to the vendor
Marqib (vendor)typology library · filing schemas · releases
Data and model governance

How the platform uses, and does not use, artificial intelligence.

Regulated firms are right to ask what leaves their environment and what a model is allowed to decide. The answers are designed into the platform rather than left to policy.

Detection is not a model decision.

Whether a matter is flagged is determined by rules and statistics that the firm can inspect and tune. A language model never decides what is suspicious.

Drafting is optional and evidence-bound.

Where enabled, a model rewrites the reasoning and the report narrative from the same evidence table the rule produced. Every sentence must cite a record; sentences without a valid citation are removed before the reviewer sees them. Rule text and model text are shown side by side.

Identifiers never reach the model.

Before any model call, client identifiers, names, account numbers, card and wallet references are replaced by tokens and restored only after the response is received. The record of what was sent is auditable.

The model runs where the firm decides.

The same platform operates with a model endpoint in the firm's region (for example Azure OpenAI in the UAE or AWS Bedrock in Bahrain), with an open-weights model on the firm's own servers, or with no model at all, in which case the rule-generated draft is the narrative.

Every generation is logged.

Provider, model, prompt hash and the number of pseudonymised tokens are written to the audit log for each draft.

Jurisdictions and filing formats

One platform. The filing format of each regulator.

The detection engine is common to all deployments; the filing adapter and typology thresholds follow the jurisdiction. Adapters marked as live are in use; others are scheduled with the first deployment in that market.

UAE · DFSA / FSRA / VARA · goAMLUAE · SCA · goAMLTürkiye · SPK / MASAKSaudi Arabia · CMA / SAMA · goAML (roadmap)Qatar · QFCRA (roadmap)Bahrain · CBB (roadmap)Mauritius · FSC (roadmap)
Pilot programme

A ninety-day pilot on the firm's own data.

Marqib is installed in the firm's environment and operated alongside the existing process for one quarter. Three measures are agreed in advance and reported at the end: reviewer hours per alert, STR turnaround, and matters identified that the existing process did not.

  1. Weeks 1–2: installation in the firm's cloud account; connection of end-of-day feeds.
  2. Weeks 3–6: threshold calibration against the firm's history; parallel review by the MLRO.
  3. Weeks 7–12: live queue, weekly review, closing report for the board and the auditor.

Fixed pilot fee
Credited against the first-year licence on continuation.

Opens a pre-filled email. Alternatively, write to anilabbak@gmail.com.

Management

Built by practitioners from the regulated side of the industry.

Marqib is led by Anıl Abbak, who spent eighteen years in licensed brokerage: Managing Director for international markets at a leading Turkish investment house; Deputy Chief Executive of a listed investment holding; Chairman of its United Kingdom, Montenegro and Mauritius subsidiaries; and an FCA-approved Senior Manager (SMF3). He has held the review responsibility the platform is designed to support.

The platform is developed by Nordera, with delivery partners in Dubai and Istanbul.

"The alert is not the work. The case file is the work."