For licensed brokers · payments and fintech next

Unusual trades and payments. One reviewable case.

Trade, payment and customer records often sit in separate systems. Marqib checks selected broker risk patterns, brings the supporting records into a case and helps your team record its decision and reporting draft.

Capabilities and roadmap →

Monitor → reviewfrom records to a case
Role-based reviewanalysts propose; MLROs review
EN · AR · TRthree interface languages
Start with your firm’s workflow:Brokers →Payment and e-money firms →
Synthetic example · not a live run · AL-2609-014 · WASH TRADINGSCORE 0.94
E1Prepared sample — linked trade, client and payment records
E2Rule hit — 58 matched trades <2 s, same UBO
E3Linked accounts — accounts 40917 / 41203 share beneficial-owner reference UBO-17
E4Funding lookup — both funded by LT61… on 19 Sep
E5⚑ IB reference — P-118 appears in the trade records; commission is not calculated
E6Screening — no match on UN, OFAC, EU, UK lists
E7Internal hold — WR-88213 marked held in Marqib; external payout requires integration
Illustrated output · evidence rows and an STR draft for review
Operating model

Connect the records. Review the case.

Rules highlight selected patterns and keep their supporting records together. Your team checks the explanation and decides what to do.

01

Connect your data

Start with customer, trade and payment files. Optional adapters are tested with your firm’s accounts.

02

See what needs attention

Rules and screening identify selected patterns. Each case shows the records and thresholds behind the alert.

03

Review and document

Review the evidence and record the decision. An analyst’s proposal is reviewed by a different MLRO. Your authorised team checks and submits the reporting draft.

A clear view of the product.

See what you can review in the pilot and what we are planning next.

In the pilot build

Monitor, investigate, document

Selected risk rules, source records, case decisions and an audit trail. Analysts propose; a different MLRO reviews.

Locally checked · awaiting release

Keep decision-time evidence

Saved evidence versions, data-quality controls and changed-proposal review have local checks. Release and final verification are pending.

Validate with your firm

Connect your existing systems

Trading, KYC and crypto adapters need validation with your own accounts. Reporting exports are drafts.

Planned

Complete more of the investigation

Feed reconciliation, document requests, deeper relationship review and rule observation before decisions.

Capabilities and roadmap →

Coverage

Typologies relevant to brokerage and fintech activity.

Parameters are configurable and can be tested on loaded history. Data availability, thresholds and reporting fields are agreed and checked during the pilot.

Market abuseWash tradingOpposite trades of equal size and instrument between accounts with the same beneficial-owner reference. Shared device or funding details provide investigation context.
Market abuseSpoofing & layeringSelected cancellation-rate and opposite-side execution patterns from the loaded orders and trades. Full order-book replay is a planned extension.
Platform abuseBonus abuseLinked accounts that received bonuses open opposite positions of similar size in the same instrument, repeatedly; the winning side's pending withdrawal is marked held inside Marqib. Restricting an external payout requires integration.
Platform abuseLatency arbitrageMany round trips held for seconds, mostly profitable, beating other clients in the same instrument; high severity right after sharp price moves.
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 screeningClients and payment counterparties against UN, OFAC, EU and UK lists, plus UAE and MASAK lists by upload; a potential match marks pending withdrawals held inside Marqib for review. Restricting an external payout requires integration.
OnboardingThird-party fundingPayer name mismatch, relationship not documented.
Due diligenceActivity beyond declared profileDeposits over 90 days far above the turnover the client declared, with a stricter test for students, the unemployed and retirees. Default outcome: updated KYC and source of funds, not an STR.
FraudAccount takeoverDormant reactivation, new device, bank change, immediate withdrawal.
Crypto · KYTGate (beta)Wallet exposureFor firms that screen crypto with KYTGate: blocked or held deposits and withdrawals raise the client's risk and open a review case, with KYTGate's findings as evidence.

See everything the platform does →

Deployment

Installed in the firm's own environment, where client data stays.

  • Single-tenant, in-region. Marqib is delivered as a container image with an install guide, for the firm's own cloud account (UAE, Bahrain or Saudi regions) or its own servers. A self-hosted installation makes no calls to any Marqib service. There is no shared database. For a pilot, we can also run a dedicated instance for that firm alone, in a region agreed with it.
  • Permissions inherited. The platform reads through the firm's existing roles and cannot write to source systems.
  • Connectors run inside it. Connections to the trading platform, back office and providers start from the firm's environment, read only, with credentials stored encrypted. Alerts to Teams or Slack carry identifiers, not client data.
  • Interface in English, Arabic and Turkish. Each reviewer chooses the language, and the choice is saved with their account; Arabic runs right to left. Audit entries, case reasons, evidence and narratives stay as they were recorded.
  • Hash-chained audit log. Append-only; each entry is linked to the previous one, making alteration detectable.
  • Self-hosted: no client data held by the vendor. Marqib delivers rule, typology and schema updates and does not receive the firm's records. On a dedicated pilot instance we operate, the firm's data is held only in that instance and deleted at the end of the pilot unless a licence follows.
Firm systemsMT5 / cTrader · back office and PSPs · KYC and screening providers · KYTGate · file storage
↓ files, read-only connectors (beta) and signed webhooks
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 · MASAK ŞİB draft · alerts to Teams, Slack, SIEM
↑ rule and schema updates only · no data flows to the vendor
Marqib (vendor)typology library · filing schemas · releases
Works with

Connectors, webhooks and files for the systems brokers and payment firms already run.

  • MetaTrader 5
  • cTrader
  • Praxis Cashier
  • B2Core
  • Sumsub
  • ComplyAdvantage Mesh
  • Veriff
  • KYTGate
  • Microsoft Teams
  • Slack

Beta connectors are validated with your account during the pilot. All integrations and their status →

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 drafts from the rule’s evidence table. Valid evidence references are checked, but that does not prove that a sentence is true. Rule text and model text are shown side by side for human review.

Identifiers are tokenised before model requests.

Supported identifiers are replaced by tokens before an optional model request. This is pseudonymisation, not a guarantee that every free-text detail is anonymous. The firm reviews the payload, provider and permitted data flow before enabling drafting.

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.

The public demo is a demo.

app.marqib.com runs on synthetic data in a vendor-hosted environment so that prospects can see the product. A pilot is never run there: it gets its own deployment and database, in the firm's own cloud account or on a dedicated instance we operate for that firm alone, with the model endpoint chosen by the firm.

Jurisdictions and filing formats

Reporting drafts, with local validation.

The detection engine is common to all deployments; the filing adapter and typology thresholds follow the jurisdiction. The goAML export is a schema-shaped draft: indicator codes and party fields are mapped to the FIU's current list during the pilot, before any live submission.

UAE · goAML XML draft · schema and FIU fields require validationTürkiye · MASAK ŞİB export draft · local format requires validationSaudi Arabia · CMA / SAMA · goAML (roadmap)Qatar · QFCRA (roadmap)Bahrain · CBB (roadmap)Mauritius · FSC (roadmap)
Pilot programme

Agree a pilot with clear acceptance criteria.

Define a broker use case and representative records, then agree installation, rule checks and reviewer responsibilities. Measures such as review time and reporting turnaround are agreed targets to evaluate, not measured results on this site.

  1. 1. Agree the scope, source fields, permissions and acceptance checks.
  2. 2. Validate the installation and connections; review representative history.
  3. 3. Compare outcomes with the existing process and record unresolved gaps.

Scope and fee agreed before starting
Timing and commercial terms are set in the written pilot proposal.

We keep what you send in our customer-relationship system to reply and to prepare a pilot. Privacy notice

You can also write to hello@marqib.com.

Background

Built by people who have run the regulated side.

Marqib is built by former senior managers of licensed brokerage and investment firms who have run regulated businesses across several jurisdictions, sat on the boards of regulated subsidiaries and answered to regulators for the anti-money-laundering controls this platform automates. The product is shaped by the review work an MLRO actually does, not by a generic model of it.

Marqib is developed by Nordera Works.

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