Marqib helps your team review unusual deposits and withdrawals with the related customer records and a documented decision trail. Reporting outputs are drafts. Refunds, chargebacks and merchant-network monitoring are planned extensions.
For every alert someone opens four systems, copies transactions into a sheet and writes the story. Marqib assembles the file; the reviewer reads and decides.
Configured low-risk patterns can close with a recorded rationale. Reviewers still check the source records and the remaining cases; an internal hold does not execute an external payment restriction.
Keep the supporting records, reasons and reporting draft together. Evidence-reference checks do not prove that a sentence is correct. Your authorised reviewer verifies the content, the applicable report and local format, and submits through the authority’s system.
Run Marqib's rules overnight, or send transactions to the real-time decision API before they are processed: Marqib builds the case file either way.
Marqib reads end-of-day exports the firm already produces from the ledger, the card processor and the KYC system, uploaded or pulled nightly from S3-compatible storage, Azure Blob Storage, HTTPS or SFTP. Praxis Cashier and B2Core (beta) add payer names, masked cards and pending withdrawals; the real-time decision API checks a transaction before it is processed.
Cases ranked by severity; configured low-risk alerts can close with a recorded rationale. Holds are internal records; the payment system must apply any external restriction. Optional notifications carry identifiers and a link.
Why it was flagged, every evidence row, the subject's recent transactions, the questions still open, and the draft narrative. Each reviewer works in English, Arabic or Turkish; the case record itself stays as it was recorded.
Evidence pack and hash-chained decision log, with goAML XML and MASAK ŞİB export drafts. Local schema, indicator codes and sector fields require validation. Submission and receipt reconciliation are outside this workflow.
A transaction sent to the decision API before it is processed gets allow, review or hold, with reasons and evidence, in the same request. Every decision is stored; review and hold open a case. API keys are managed by an MLRO.
Agree the use case, source fields, reporting jurisdiction and named reviewers before starting. Validate connections and deployment with your team. Timing and acceptance measures are set in the pilot proposal; the example tour is not a performance result.
Scope and fee agreed before starting
Timing and commercial terms are set in the written pilot proposal.